JP5172585B2 - オブジェクト・モデルに対するアクセスを制御するシステム、方法、およびプログラム - Google Patents

Description

本発明は、一般的にはコンピュータ上のオブジェクトのアクセス制御に関する。 本発明は特に、複数のモデル要素を備える、サーバ・コンピュータに記憶されたオブジェクト・モデルに対して、複数のユーザからのアクセスを各モデル要素ごとに制御することができるシステム、そのための方法、およびコンピュータ・プログラムに関する。

近年、モデル駆動型の開発プロセスに注目が集まっている。 モデル駆動型の開発プロセスでは、設計フェーズにおいて、モデル編集ツール（例えば、ＲＳＡ（Ｒａｔｉｏｎａｌ Ｓｏｆｔｗａｒｅ Ａｒｃｈｉｔｅｃｔ）など）を用いて、これから作成しようとするソフトウェアやシステムを、ＵＭＬ（Ｕｎｉｆｉｅｄ Ｍｏｄｅｌｉｎｇ Ｌａｎｇｕａｇｅ）やＳｙｓＭＬ（Ｓｙｓｔｅｍｓ Ｍｏｄｅｌｉｎｇ Ｌａｎｇｕａｇｅ）等の、オブジェクト・モデリングのために標準化された仕様記述言語を用いてモデルの記述を行う。 その後、そのソフトウェアやシステムを、記述されたそのモデルに基づいて実装（Ｉｍｐｌｅｍｅｎｔ）したり、そのモデル上で検証したりする工程が行われていく。

ここで、モデルをベースとした開発を行う場合、設計に必要な情報だけでなく、設計事由や検証のための制約式なども含めて、多くの情報がモデル内に記述されることになる。 このようなモデルの記述は、複数のモデル要素としてそのモデルを構成する。 通常、これらモデルの記述は、同一組織・企業内だけで共有されるだけではなく、例えば、後工程のエンジニア、あるいは、発注元のクライアントなどとも共有しなければならない。 しかしながら、モデルを構成する複数のモデル要素の内の１つにでも、機密情報となる情報が含まれていると、そのモデルをそのまま、納品したり共有したりすることができなくなる。

このようなケースは、発注元のクライアントからＯＥＭの供給要求を受け取ったサプライヤが、納品物としてのモデルを記述し、最終的にクライアントに対して納品物を提供するという実際のビジネス上のシナリオにおいてよく発生する問題である。 即ち、サプライヤはモデルを記述するだけでなく、記述したモデルを用いて検証などを行い、モデルの正しさを確認したり、パラメータを決めるための計算をモデルの記述を用いて行ったりしている。 しかしながら、これらの情報（制約条件などサプライヤにとって機密情報となるような情報）は、本来は、サプライヤ内に留めておきたい情報であり、発注元のクライアントには提供したくない情報であるため、これらの情報を隠して提供することが必要となる。

通常、モデル編集ツールでは、モデルの管理単位として、１つのファイルに１つのモデルを記述するように実装されている。 即ち、モデルの管理は、ファイル単位でなされている。 そして、ファイルのバージョン管理ツール（例えば、ＣＶＳ（Ｃｏｎｃｕｒｒｅｎｔ Ｖｅｒｓｉｏｎ Ｓｙｓｔｅｍ）、ＣＣ（Ｒａｔｉｏｎａｌ ＣｌｅａｒＣａｓｅ（商標））など）を用いて、ファイル単位で、複数のユーザ間での共有やバージョン管理がなされている。 したがって、ファイル単位でアクセス権を設定する通常のファイル・システムのアクセス制御を用いたのでは、モデル全体の単位でしかアクセスを制御できないことになる。

ここで、あるバージョンのモデルを発注元に納品または閲覧させるような場合に、そのモデルに含まれる機密情報の部分だけを削除して渡すことも可能である。 しかし、この場合には、納品を受けた発注元が、納品されたモデルを後で編集することは全く考慮されていない。 そのため、以後のモデル上で編集や修正を行わなければならない場合、本来必要な情報を削除してしまっていると、問題を引き起こす。

モデル全体の単位ではなく、モデルを構成するモデル要素等の単位でアクセスを制御する方法も試みられて来ている。
ＳＰＡＲＸ ＳＹＳＴＥＭＳ社の製品、Ｅｎｔｅｒｐｒｉｓｅ Ａｒｃｈｉｔｅｃｔのマニュアル「アクセス権の活用」では、ＵＭＬのパッケージ単位、要素単位、およびダイアログ単位でアクセス権の設定やロックの設定ができる旨が開示されている。
また、ヨーロッパ特許ＥＰ１５３６３０９では、任意のビジネス・データ・オブジェクトに対してＰｅｒｍｉｓｓｉｏｎ Ｄａｔａ Ｏｂｊｅｃｔを適用してアクセスを管理する手法が提案されている。
更に、例えばＲＳＡなどのモデル編集ツールでは、モデル本体を拡張子が .emx であるファイル名で管理し、モデルの一部を分割して、フラグメント・ファイルとして .efx という拡張子のファイル名で管理することが可能である。 即ち、モデルファイル内に、フラグメント・ファイルへの参照情報が記述されるため、モデル編集ツール上では、一つのモデルとして閲覧、編集することが可能となっている。 このように、モデルを分割しフラグメント・ファイルを作成することで、ファイルのバージョン管理ツールの機能を用いて、各フラグメント・ファイルに対してアクセス権を付与し、より小さい単位でアクセス制御をすることも可能ではある。

しかしながら、これらの方法をもってしても、例えば、モデルの構成要素である特定のモデル要素を１つのフラグメント・ファイルに割り当ててユーザ毎のアクセス制御をした場合、このフラグメント・ファイルへのアクセスが許可されないユーザは、この特定のモデル要素についての中身を見ることができないのは勿論のこと、この特定のモデル要素の存在を共有することもできない。 即ち、あるモデル要素について、複数のユーザ間でその存在は共有するが、そのうちの一部のユーザにはその中身は見せないようにすると言った、より有効的なアクセス管理をすることはできない。
更にまた、これらの方法では、あるモデル要素の一部の情報（例えば、検証に必要な寸法情報など）だけを複数のユーザ間で共有するといった、より詳細な情報へのアクセス管理を行うこともできない。
これらの結果、アクセスが許可されないモデル要素の存在を知り得ないあるユーザが、同じモデル要素を重複して設計をするといった好ましくない状況を誘発する。

また、近年、モデルを用いて、プロトタイプを実装する前に、モデル上で検証やシミュレーションを実施する技術が、研究、開発されている。 例えば、あるモデル要素については、あるユーザからは、閲覧は禁止したいが、そのモデル要素に含まれる外部と関連を持つ要素、例えばそのモデル要素の中で定義された特定の数値のみ、を他のモデル要素から参照させて、検証に用いたいような場合がある。 このような場合も、そのモデル要素を１つのフラグメント・ファイルに割り当ててユーザ毎のアクセス制御を行うと、そのフラグメント・ファイルに対するアクセス権がないユーザは、そのモデル要素上で設定された数値に対してもアクセス権がないため、上記のような検証を実施することができない。

よって、従来からある方法によっては、昨今のモデル駆動型の開発プロセスにとって重要な、よりきめ細かで有効的な、モデル要素ごとのアクセス管理をすることはできない。

ＳＰＡＲＸ ＳＹＳＴＥＭＳ社、Ｅｎｔｅｒｐｒｉｓｅ Ａｒｃｈｉｔｅｃｔ日本語版、「アクセス権の活用」ＵＲＬ： http://www.sparxsystems.jp/bin/UseAccessRight.pdf ヨーロッパ特許ＥＰ１５３６３０９

本発明の目的は、モデル駆動型の開発プロセスにおいて、複数のモデル要素を備えるオブジェクト・モデルに対して、複数のユーザからのアクセスを各モデル要素ごとに制御でき、かつその制御は、あるモデル要素について、複数のユーザ間でその存在は共有するが、そのうちの一部のユーザにはその中身は見せないようにすると言ったより細かい有効的なアクセス管理を行うことができるものであるシステム等を提供することである。

上記課題を解決するために、本発明では、それぞれが固有のＩＤを有する複数のモデル要素を備える、サーバ・コンピュータに記憶されたオブジェクト・モデルに対して、複数のユーザからのアクセスを制御するシステムを提供する。
本発明の第１の側面においては、このシステムは、（Ａ）前記複数のモデル要素のそれぞれについて、前記複数のユーザの各々からの当該モデル要素に対するアクセス権限の種類を規定する第１拡張メタデータを当該モデル要素に関連付けて設定し、および、前記第１拡張メタデータおよび自身を修正する権限があるかどうかを示す第２拡張メタデータを当該モデル要素に関連付けて設定し、前記第２拡張メタデータには、各ユーザについて前記第１拡張メタデータを修正する権限があることが初期的に示される、初期設定部と、（Ｂ）第１ユーザからの第１拡張メタデータの編集要求に応じて、１以上のモデル要素のそれぞれについて、１以上のユーザの各々について、前記第２拡張メタデータが、前記第１拡張メタデータを編集する権限があることを示す場合に、前記第１拡張メタデータを編集する、第１拡張メタデータ編集部と、（Ｃ）第２ユーザからの第２拡張メタデータの編集要求に応じて、１以上のモデル要素のそれぞれについて、１以上のユーザの各々について、前記第１拡張メタデータを編集する権限がないことを示すように前記第２拡張メタデータを編集する、第２拡張メタデータ編集部と、（Ｄ）第３ユーザから、前記オブジェクト・モデルを前記第３ユーザのクライアント・コンピュータにローカルなオブジェクト・モデルとして取り込むためのチェックアウト要求があった場合に、前記複数のモデル要素の各々について、前記第３ユーザに関して、（Ｄ−１）読出し可能のアクセス権限または編集可能のアクセス権限があることを当該モデル要素の前記第１拡張メタデータが示す場合は、当該モデル要素をそのまま前記クライアント・コンピュータに提供し、（Ｄ−２）読出し可能のアクセス権限および編集可能権のアクセス権限のいずれも無いことを当該モデル要素の前記第１拡張メタデータが示す場合は、当該モデル要素の代わりに、その内容を取り除いて少なくとも同一のＩＤと第１拡張メタデータのみを付与した、代替モデル要素を前記クライアント・コンピュータに提供する、アクセス管理部と、を備える。

また、本発明の第２の側面においては、本発明の第１の側面におけるシステムにおいて、前記アクセス管理部が、さらに、（Ｅ）第４ユーザから、前記第４ユーザのクライアント・コンピュータにおけるローカルなオブジェクト・モデルを前記オブジェクト・モデルに書き戻すためのチェックイン要求があった場合に、前記ローカルなオブジェクト・モデルが備える複数のローカルなモデル要素の各々について、前記第４ユーザに関して、（Ｅ−１）編集可能のアクセス権限があることを当該ローカルなモデル要素の前記第１拡張メタデータが示す場合は、当該ローカルなモデル要素を前記オブジェクト・モデルに書き戻し、（Ｅ−２）読出し可能のアクセス権限があるが編集可能のアクセス権限が無いことを当該ローカルなモデル要素の前記第１拡張メタデータが示す場合は、当該ローカルなモデル要素の代わりに、当該ローカルなモデル要素のＩＤと同一のＩＤを有する、前記オブジェクト・モデル内の当該ローカルなモデル要素に対応するモデル要素を用い、（Ｅ−３）当該ローカルなモデル要素が代替モデル要素である場合、前記代替モデル要素の代わりに、前記代替モデル要素のＩＤと同一のＩＤを有する、前記オブジェクト・モデル内の前記代替モデル要素に対応するモデル要素を用いる、ことで前記チェックインを完遂する、システムを提供する。

さらに、本発明の第３の側面においては、本発明の第２の側面におけるシステムにおいて、（Ｅ−２）当該ローカルなモデル要素の代わりに、当該ローカルなモデル要素のＩＤと同一のＩＤを有する、前記オブジェクト・モデル内の当該ローカルなモデル要素に対応するモデル要素を用いることは、（ｅ−２）当該ローカルなモデル要素が前記第４ユーザによって編集されていた場合には、チェックインを拒否し、前記第４ユーザに対して、当該ローカルなモデル要素の編集を許容できない旨の通知をすることを含む、システムを提供する。

さらにまた、本発明の第４の側面においては、本発明の第２の側面におけるシステムにおいて、（Ｅ−３）前記代替モデル要素の代わりに、前記代替モデル要素のＩＤと同一のＩＤを有する、前記オブジェクト・モデル内の前記代替モデル要素に対応するモデル要素を用いることは、（ｅ−３）前記代替モデル要素が前記第４ユーザによって編集されていた場合であって、その編集が、他のモデル要素との関係性を追加する変更であった場合に、前記代替モデル要素に対応するモデル要素に、前記他のモデル要素との関係性を追加する前記変更を反映させることを含む、システムを提供する。

以上、本発明の概要を、複数のユーザからのアクセスを制御するシステムとして説明したが、本発明はまた、当該システムによってその機能を実施する方法としても捉えることができる。 また、当該システムにこれら方法を実行させるためのコンピュータ・プログラムとしても捉えることができる。

尚、上記発明の概要は、本発明の必要な特徴の全てを列挙したものではなく、これらの構成要素のコンビネーションまたはサブコンビネーションもまた発明となり得ることに留意されたい。

以下、添付図面を参照して、本発明を実施するための最良の形態（以下、実施形態）について詳細に説明する。 なお、実施形態の説明の全体を通じて同じ要素には同じ番号を付している。

１．システム環境
はじめに、本発明の実施に係るモデル駆動型の開発におけるシステム環境について説明する。
図１は、モデル駆動型の開発におけるシステム環境の例１００を表す。 モデル駆動型の開発においては、その開発対象に関する基準となるオブジェクト・モデルを先に構築し、そのオブジェクト・モデルを参照して開発対象のシステム等の実装（例えば、Ｊａｖａ（商標）やＣ言語等によるソフトウェア構築による実装等）を行う。 また、必要に応じて、そのオブジェクト・モデルに対して随時修正をかけ、基準となるオブジェクト・モデルを常により適正なものに更新していくことも必要となる。

この基準となるオブジェクト・モデルは、サーバ・コンピュータ１０２の記憶装置内にモデル・リポジトリ１０６として記憶される。 サーバ・コンピュータ１０２には、ネットワーク１０８を介して、複数のクライアント・コンピュータ１１０、１１２が通信可能に接続され、各クライアント・コンピュータは、それぞれ、基準となるオブジェクト・モデルにアクセスしてこれを編集するためのモデル編集ツール１１４、１１６とローカルな作業領域１３０、１３２とを備える。 各クライアント・コンピュータはまた、そのそれぞれを複数のユーザ１２０、１２２、ユーザ１２４、１２６が利用することができる。

各ユーザは、自己が利用することができるクライアント・コンピュータ、およびそのクライアント・コンピュータに備わったモデル編集ツールを介して、サーバ・コンピュータ１０２のモデル・リポジトリ１０６に記憶された基準となるオブジェクト・モデルに対して、様々な種類のアクセスを試みる。 これらユーザからの様々なアクセス要求を受けて、実際にサーバ・コンピュータ１０２において、モデル・リポジトリ１０６へのアクセスを制御するのが、本発明に係るモデル要素アクセス制御システム１０４である。

２．オブジェクト・モデルおよびモデル要素の構成
図２は、モデル・リポジトリとしてサーバ・コンピュータ内に記憶される基準となるオブジェクト・モデルの例２００を示す。 図２は、開発対象であるレーダ送受信システムをＳｙｓＭＬ（Ｓｙｓｔｅｍｓ Ｍｏｄｅｌｉｎｇ Ｌａｎｇｕａｇｅ）でモデリングしたものである。 ＳｙｓＭＬとは、システム工学のためのモデリング言語であり、ＵＭＬ（Ｕｎｉｆｉｅｄ Ｍｏｄｅｌｉｎｇ Ｌａｎｇｕａｇｅ）にシステム工学向けの拡張を施したものである。 ＳｙｓＭＬは、各種システムやサブシステムの仕様記述、分析、設計、検証、評価等に使用することができる。

オブジェクト・モデルは、複数のモデル要素から構成される。 モデル要素には、先ずは、開発対象システムの有する有形、無形の構成ブロックで表される情報がこれに該当する。 図２では、ブロック２０２、２０４、２０６、２０８で表されるハードウェア構成部品情報、ブロック２１２、２１４で表されるパワー（電源供給）情報、および、ブロック２２２、２２４で表される要件（Ｒｅｑｕｉｒｅｍｅｎｔ）情報がこれに相当する。

また、各ブロック間の関係を表す情報についても、モデル要素として扱うことが可能である。 図２では、ライン２３２〜２５２で表される、条件満足（Ｓａｔｉｓｆｙ）を示す情報等がこれに該当する。 さらには、上記ブロック内で定義される属性や操作などの要素についても、モデル要素（即ち、これらブロックのモデル要素のサブ・モデル要素）として取り扱うことができる。

図３は、本発明の実施に関して、オブジェクト・モデルの各モデル要素の内部構成の例を示す。
まず、各モデル要素には、その内部に、ＩＤ３０２が付与されていることが前提となる。 即ち、ユーザのクライアント・コンピュータに導入されたモデル編集ツールを用いて、基準となるオブジェクト・モデルのモデリングを行う場合、各モデル要素にはＩＤが付与される。 これにより、バージョンの異なるモデル間で、モデル要素名やプロパティ（属性）等が変更されたとしても、どのモデル要素が互いに対応するモデル要素であるかが特定可能となる。
ＩＤの他にモデル要素を構成するものとしては、一般に、モデル要素名３０４、プロパティ３０６、およびそのモデル要素の主要部である動作記述（または、機能記述）３０８等がある。
なお、これらプロパティや動作記述等といったそれぞれの要素もまた、モデル要素（即ち、あるモデル要素の下位階層のモデル要素）として取り扱うことができる。

オブジェクト・モデルを表すＵＭＬやＳｙｓＭＬ等のモデリング言語は、そのモデル要素の役割や用法上の違い等をそのモデル要素に修飾するための拡張機能を有する。 この拡張機能は、そのモデル要素を修飾する各種の拡張メタデータをそのモデル要素に付随して備えることによって可能となる。 これらの拡張機能としては、例えば、ＵＭＬやＳｙｓＭＬの場合には、「ステレオタイプ」と呼ばれるものがある。 ステレオタイプ自身については、既存技術であるので、その詳細の説明は省略する。
本発明の実施のためには、各モデル要素を構成するＩＤ３０２、モデル要素名３０４、プロパティ３０６、動作記述３０８等の他に、モデル要素の拡張機能として、所定のフォーマットを有する第１拡張メタデータ３１０および第２拡張メタデータ３１２を備えることが必要である。

第１拡張メタデータ３１０は、このオブジェクト・モデルにアクセスする複数のユーザの各々を示すユーザ識別子と、各ユーザからのこのモデル要素に対するアクセス権限の種類との対応付けを示したテーブル３２２を規定したものである。 アクセス権限の種類としては、最低限、編集（Ｅｄｉｔ）可能かどうか、読出し（Ｒｅａｄ）可能かどうか、実行（Ｅｘｅｃ）可能かどうか、の３種類を規定する。 テーブル３２２に現れていないユーザ識別子に係るユーザについては、省略時解釈（デフォルト）で、全ての種類のアクセスが可能であるものと規定することができる。
図３の例では、例えばユーザ１はこのモデル要素に対して実行、読出し、編集の全ての種類のアクセスが可能であることを示す。 また、ユーザ２は、このモデル要素に対する編集は不可だが、実行および読出しは可能であることを示す。 更に、ユーザ３は、このモデル要素に対する編集も読出しも不可だが、実行および読出しのアクセスは可能であることを示す。 原則は、最も強いアクセスである編集が可能であれば、他のアクセス（読出し、実行）も当然に可能となる。

第２拡張メタデータ３１２は、このオブジェクト・モデルにアクセスする複数のユーザの各々を示すユーザ識別子と、各ユーザが第１拡張メタデータ３１０および第２拡張メタデータ３１２自身を修正する権限があるかどうかの情報との対応付けを示したテーブル３２４を規定したものである。 図３の例では、ユーザ１およびユーザ２は、それぞれ、このモデル要素についての第１拡張メタデータ３１０および第２拡張メタデータ３１２自身を修正する権限があることを示している。 また、ユーザ３は、このモデル要素についての第１拡張メタデータ３１０および第２拡張メタデータ３１２自身を修正する権限がないことを示している。 ユーザ１は、このモデル要素についての第１拡張メタデータ３１０にアクセスして、ユーザ２やユーザ３のアクセス権限はもちろんのこと、ユーザ１自身のアクセス権限も書き換えることができる。 ユーザ１はまた、このモデル要素についての第２拡張メタデータ３１２にアクセスして、ユーザ２が第１拡張メタデータ３１０および第２拡張メタデータ３１２を修正できないように書き換えることができる。 ユーザ１はまた、第２拡張メタデータ３１２にアクセスして、自分自身がこれ以降、第１拡張メタデータ３１０および第２拡張メタデータ３１２を修正できないように書き換えることも可能である。

３．本発明の実施に係るシステムの構成と機能
図４は、本発明の実施に係る、サーバ・コンピュータ１０２等に備わるモデル要素アクセス制御システム１０４の構成とその機能を模式的に示す。
モデル要素アクセス制御システム１０４は、モデル・リポジトリ１０６に記憶されたオブジェクト・モデル４２０を構成する各モデル要素に対するユーザからのアクセス要求を受けて、当該モデル要素に対するアクセスを制御する。 モデル要素アクセス制御システム１０４は、初期設定部４０２、第１拡張メタデータ編集部４０４、第２拡張メタデータ編集部４０６、およびアクセス管理部４０８の４つの機能ブロックを備える。

初期設定部４０２は、各モデル要素について、その第１拡張メタデータおよび第２拡張メタデータの値の初期設定を行う。 即ち、各モデル要素ごとに、図３のテーブル３２２のように、このオブジェクト・モデル４２０にアクセスする複数のユーザのそれぞれが、このモデル要素に対して行うことのできるアクセス権限の種類について、その初期値を設定する。
初期値としては、全てのユーザについて、全てのアクセス権限を付与するように定めることができる。

第１拡張メタデータ編集部４０４は、このオブジェクト・モデル４２０にアクセスする複数のユーザのうちの１のユーザから、あるモデル要素について、その第１拡張メタデータを編集したいとの要求があった場合に、この編集要求に応答して、この第１拡張メタデータの編集をしたり、あるいは場合によっては編集を拒否したりする。
第１拡張メタデータ編集部４０４は、この１のユーザからのあるモデル要素の第１拡張メタデータに対する編集要求があった場合に、先ず、このモデル要素の第２拡張メタデータを参照する（図４の線４２２）。 この参照の結果、このユーザがこのモデル要素の第１拡張メタデータを編集できる旨を、第２拡張メタデータが示す場合は、この第１拡張メタデータの編集要求を許可し、この１のユーザの要求通りにこの第１拡張メタデータを編集する。

第２拡張メタデータ編集部４０６は、このオブジェクト・モデル４２０にアクセスする複数のユーザのうちの１のユーザから、あるモデル要素について、その第２拡張メタデータを編集したいとの要求があった場合に、この編集要求に応答して、この第２拡張メタデータの編集をしたり、あるいは場合によっては編集を拒否したりする。
第２拡張メタデータ編集部４０６は、この１のユーザからのあるモデル要素の第２拡張メタデータに対する編集要求があった場合に、先ず、その第２拡張メタデータ自身を参照する（図４の線４２４）。 この参照の結果、このユーザがこのモデル要素の第２拡張メタデータ自身を編集できる旨を、第２拡張メタデータが示す場合は、この第２拡張メタデータの編集要求を許可し、この１のユーザの要求通りにこの第２拡張メタデータを編集する。

アクセス管理部４０８は、このオブジェクト・モデル４２０にアクセスする複数のユーザのうちの１のユーザから、オブジェクト・モデル４２０についてのチェックアウト要求、チェックイン要求、モデル検証要求等の、オブジェクト・モデル４２０全体に対するアクセス要求があった場合に、このアクセス要求に応答して、オブジェクト・モデル４２０に含まれる個々のモデル要素に対するアクセスを制御する。

４．チェックアウト要求
あるユーザから、オブジェクト・モデル４２０についてのチェックアウト要求があった場合の、アクセス管理部４０８の動作について説明する。
一般にチェックアウトとは、ユーザが、サーバ・コンピュータにおける基準となるオブジェクト・モデルに基づいて開発等の作業を行っている状態から離れて、自身のローカルな環境において作業を行うために、基準となるオブジェクト・モデルを自身のローカルな作業領域に取り込むことである。

例えば、図１の環境において、ユーザ１２０がクライアント・コンピュータ１１０のモデル編集ツール１１４を介して、サーバ・コンピュータ１０２のモデル・リポジトリ１０６に保管されたオブジェクト・モデルに対してチェックアウト要求を発した場合を考える。
この場合、このチェックアウト要求をサーバ・コンピュータ１０２のモデル要素アクセス制御システム１０４が、即ち、モデル要素アクセス制御システム１０４内のアクセス管理部４０８が受ける。 アクセス管理部４０８は、モデル・リポジトリ１０６内に保管されたオブジェクト・モデルの各モデル要素ごとに、クライアント・コンピュータ１１０にそのモデル要素を提供するかどうか、提供する場合はどのような形態で提供するかを判断し、それを実行する。
チェックアウトが完了すると、クライアント・コンピュータ１１０に提供されたオブジェクト・モデルの各モデル要素は、ローカルな作業領域１３０に保管され、ユーザ１２０はローカルな作業環境において提供されたオブジェクト・モデルに基づいて自己の開発等の作業を遂行することができる。

図５は、あるユーザからのチェックアウト要求があった場合の、本発明の実施に係る処理の流れを模式的に示したものである。
ユーザがチェックアウト要求（処理５０２）を行うと、サーバ・コンピュータのモデル要素アクセス制御システムは、モデル・リポジトリからオブジェクト・モデルのファイル５２０を参照する。 オブジェクト・モデルのファイル５２０には実際に複数のモデル要素についての情報が含まれている。 よって、各モデル要素ごとにその情報が取得（処理５０４）される。
取得された各モデル要素ごとに、その第１拡張メタデータの情報を参照して、そのユーザについてのアクセス権の確認（処理５０６）がされる。
アクセス権を確認した結果、そのユーザからそのモデル要素に対するアクセス権限が、「読出し付加」かつ「編集不可」であった場合は、そのモデル要素はスタブに変換（処理５０８）される。

スタブとは、そのモデル要素が有するＩＤのみを残し、それ以外の情報をそのモデル要素から全て取り除いて作成した代替モデル要素である。
図６は、モデル要素と、対応する代替モデル要素（スタブ）との間の構成例の比較を示したものである。 この図に示すように、代替モデル要素６０２では、原則は、オリジナルのモデル要素６０４のＩＤ６０６のみがその構成に反映され、その他の構成内容は、第１拡張メタデータ６０８、第２拡張メタデータ６１０も含め、一切代替モデル要素に反映されない。 モデル要素のモデル要素名６１２についても、代替名６１４に変換される。 しかし、後述するように、オリジナルのモデル要素の内容の一部を、代替モデル要素に残すことができる場合もある。

確認されたアクセス権限が上記以外の場合は、そのモデル要素は代替モデル要素に変換されない。 即ち、図４のアクセス管理部４０８を通過する各モデル要素のデータは、代替モデル要素への変換４１０を経るものと経ないものがある。

最後に、各モデル要素の情報がそのユーザのクライアント・コンピュータに提供（処理）される。 この際、上記の判断によって、モデル要素が代替モデル要素（スタブ）に変換されたものは、そのスタブがオリジナルのモデル要素に代わってクライアント・コンピュータに送られる。
クライアント・コンピュータに送られた各モデル要素のデータからなるオブジェクト・モデルは、ローカルなオブジェクト・モデルのファイル５１２としてクライアント・コンピュータでローカルに利用される。

５．チェックイン要求
次に、あるユーザから、オブジェクト・モデル４２０についてのチェックイン要求があった場合の、アクセス管理部４０８の動作について説明する。
一般にチェックインとは、ユーザが、チェックアウトによって自身のローカルな作業環境に取り込んだローカルなオブジェクト・モデルに基づいて作業を行い、修正や更新が行われたそのローカルなオブジェクト・モデルを、もう一度、サーバ・コンピュータにおける基準となるオブジェクト・モデルに書き戻すことである。

例えば、図１の環境において、ユーザ１２０がクライアント・コンピュータ１１０のモデル編集ツール１１４を介して、サーバ・コンピュータ１０２のモデル・リポジトリ１０６に保管されたオブジェクト・モデルに対して、自己のローカルな環境におけるオブジェクト・モデルのチェックイン要求を発した場合を考える。
この場合、このチェックイン要求を、サーバ・コンピュータ１０２のモデル要素アクセス制御システム１０４が、より詳しくは、モデル要素アクセス制御システム１０４内のアクセス管理部４０８が受ける。 アクセス管理部４０８は、モデル・リポジトリ１０６内に保管されたオブジェクト・モデルの各モデル要素ごとに、そのモデル要素に対してクライアント・コンピュータ１１０からのローカルなモデル要素を書き戻す（上書きする）かどうか等を判断し、それを実行する。

図７は、あるユーザからのチェックイン要求があった場合の、本発明の実施に係る処理の流れを模式的に示したものである。
ユーザがチェックイン要求（処理５０２）を行うと、そのユーザのクライアント・コンピュータに記憶されたローカルなオブジェクト・モデルのファイル７１６がサーバ・コンピュータに送られ、サーバ・コンピュータのモデル要素アクセス制御システムは、このローカルなオブジェクト・モデルのファイル７１６を参照する。 このローカルなオブジェクト・モデルのファイル７１６には実際に複数のモデル要素および代替モデル要素（スタブ）についての情報が含まれている。 よって、各モデル要素および代替モデル要素ごとにその情報が取得（処理７０４）される。

ローカルなオブジェクト・モデルのファイル７１６から取得された代替モデル要素（スタブ）がある場合は、この代替モデル要素は、チェックアウトの際、オリジナルのモデル要素に対するこのユーザからのアクセス権限が「読出し不可」かつ「編集不可」であったために、代替モデル要素に置換されてチェックアウトされたものであることを意味する。 よって、この場合は、この代替モデル要素に含まれるＩＤと同一のＩＤを有する、即ち対応するモデル要素を、モデル・リポジトリ内の基準となるオブジェクト・モデルのファイル７２０の中から検索する。
この代替モデル要素は、この検索された対応するモデル要素で置換、即ち適正な内容に復元（処理７０６）される。

ローカルなオブジェクト・モデルのファイル７１６から取得されたモデル要素の場合は、各モデル要素ごとに、その第１拡張メタデータの情報を参照して、そのユーザについてのアクセス権限の確認がされる。
確認されたアクセス権限が「編集可」である場合は、そのモデル要素はローカルな環境で編集が許可されていたものであるから、そのままモデル・リポジトリのオブジェクト・モデルに書き戻されることになる。

そのユーザからそのモデル要素に対するアクセス権限が、「読出し可」かつ「編集不可」である場合は、ローカルな環境で編集が許可されていないので、通常はこのモデル要素に対する編集は行われていない。しかし、このユーザが故意に、あるいは、誤って、ローカルな環境でこのモデル要素に対する編集を行ってしまう場合が発生し得る。 この可能性は、クライアント・コンピュータに導入された現行のＲＳＡ等のモデル編集ツールを使用する限り、避けることができない。 よって、このような場合、このローカルなモデル要素をそのままモデル・リポジトリのオブジェクト・モデルに書き戻すことは行わない。 即ち、このローカルなモデル要素に含まれるＩＤと同一のＩＤを有する、即ち対応するモデル要素を、モデル・リポジトリ内の基準となるオブジェクト・モデルの中から検索し、このローカルなモデル要素をこの検索された対応するモデル要素で置換（処理７０８）する。

このようにして、チェックイン要求に伴うローカルなオブジェクト・モデルに含まれるモデル要素の内容が、内容の置換等によって適宜修正された後、このローカルなオブジェクト・モデルのファイルは、モデル・リポジトリに書き戻されて、チェックインが完了（処理７１０）する。 即ち、モデル・リポジトリに記憶されていたオブジェクト・モデルのファイルは、修正後のローカルなオブジェクト・モデルのファイルで置き換えられる。
チェックインの完了は、モデル要素アクセス制御システムから、このユーザのクライアント・コンピュータ側に通知（処理７１２）される。

なお、上記では、ユーザからローカルなモデル要素に対するアクセス権限が、「読出し可」かつ「編集不可」である場合に、モデル・リポジトリ内の基準となるオブジェクト・モデルの中から対応するモデル要素を検索し、このローカルなモデル要素を、検索された対応するモデル要素で置換（処理７０８）する態様を示した。 しかし、このように、対応するモデル要素で無条件に置換してしまうのではなく、各モデル要素について先ずその整合性をチェック（処理７１４）して、不整合であった場合に、その旨をユーザのクライアント・コンピュータ側に通知し、チェックインを拒否（処理７１８）するという態様をとることも可能である。

ここで、整合性のチェックとは、各々のローカルなモデル要素について、その第１拡張メタデータの内容をチェックして、そのユーザからのアクセス権限が、「読出し可」かつ「編集不可」であった場合に、そのローカルなモデル要素の内容が、チェックアウト直後の内容と異なっているか、即ち、チェックアウト後に、ローカルな環境下で、そのユーザによって実際に編集されたかどうかを確認することである。 このためには、このユーザが以前チェックアウトしたときのオブジェクト・モデルのファイルのバックアップをサーバ・コンピュータ等が持っている必要があるのは言うまでもない。
確認の結果、実際にそのローカルなモデル要素が編集されていた場合は、そのモデル要素に関して、編集するべきではなかったのに編集がされたため不整合である旨の通知と、不整合を解消するためにそのローカルなモデル要素の中の修正が必要な箇所とをクライアントに提示し、チェックインを拒否する。

６．代替モデル要素のチェックアウト、チェックイン時の更なる実施態様
図６に示したように、チェックアウト時のあるモデル要素についての代替モデル要素への変換では、オリジナルのモデル要素のＩＤのみがその構成に反映され、その他の構成内容は、一切反映されないのが原則である。
しかし、代替モデル要素へ変換されるべきそのモデル要素が、他のモデル要素に対する関係性を示す情報を有している場合には、その関係性の情報は、代替モデル要素にも残しておかなければならない。
図８は、代替モデル要素へ変換しなければならないオリジナルのモデル要素に、他のモデル要素との関係性を示す情報を、拡張メタデータとして有している場合の、このオリジナルのモデル要素と、対応する代替モデル要素（スタブ）との間の構成例の比較を示したものである。 この図に示すように、代替モデル要素８０２においても、オリジナルのモデル要素８０４が有する他のモデル要素との関係性を示す拡張メタデータ８０６は、消去されずにそのまま反映される。

図９は、図２に示したオブジェクト・モデルに対してチェックアウトがされた後の、ローカルな環境下でのＳｙｓＭＬによるオブジェクト・モデルの例９００を示したものである。 この例では、図２のブロック２０６で表されるモデル要素についてこのユーザからのアクセス権限が、「読出し不可」かつ「編集不可」であったため、このモデル要素が代替モデル要素（スタブ）９０２に変換されている。 しかし、図２のブロック２０６とブロック２２２との間には、ブロック２２２で表される要求条件を、ブロック２０６で表されるコンポーネント（Ｒａｄａｒ Ｒｅｃｅｉｖｅｒ）が満足する（Ｓａｔｉｓｆｙ）という関係性を有している。
よって、図９に示される、図２のブロック２２２から置き換えられた代替モデル要素（スタブ）であるブロック９０２においては、ブロック２２２とのこの関係性を示す拡張メタデータ９０４が残される。

なお、チェックアウト時には、他のモデル要素との関係性の記述が存在しなかったモデル要素が、代替モデル要素に変換されてチェックアウトされ、チェックアウト後のローカルな環境下における作業で、この代替モデル要素について、他のモデル要素との関係性が新たに追加される場合がある。
例えば、図２のサーバ・コンピュータにおけるオブジェクト・モデルにおいては、ブロック２２２をブロック２０６が満足する（Ｓａｔｉｓｆｙ）という関係は無かったが、このオブジェクト・モデルをチェックアウトして、ローカルな環境下でモデルの更新等を行った結果、図９のローカルなオブジェクト・モデル環境下で、ブロック２０６に対応する代替モデル要素であるブロック９０２において、ブロック２２２との関係性を示す拡張メタデータ９０４が追加される場合がある。

このようなローカルなオブジェクト・モデルをチェックインする際は、この代替モデル要素を、サーバ・コンピュータのモデル・リポジトリ内に記憶された、対応する（即ち、同じＩＤを持つ）モデル要素に置換した後、置換された代替モデル要素に対してローカルな環境下で追加していた拡張メタデータを、置換したそのモデル要素に対しても同様に追加する編集を行う。
これにより、ローカルな環境下で追加された他のモデル要素との関係性を、チェックイン後の、基準となるオブジェクト・モデルにおいても反映させることができる。

７．モデル検証要求
チェックアウトにより、ローカルな環境下に取り込まれたオブジェクト・モデルにおいて、全てのモデル要素の第１拡張メタデータが示すアクセス権限が（「読出し不可」かつ「編集不可」であったとしても）少なくとも「実行可」である場合がある。 この場合、そのローカルなオブジェクト・モデルのうちのいくつかのモデル要素が代替モデル要素（スタブ）に置換されたものであったとしても、そのオブジェクト・モデル全体のモデル検証を、本発明の実施態様として行うことができる。

図１０は、あるユーザからのモデル検証要求があった場合の、本発明の実施に係る処理の流れを模式的に示したものである。
ユーザが、チェックアウトによって自己のローカルな環境に取り込んだローカルなオブジェクト・モデルについて、モデル検証要求（処理５０２）を行うと、そのユーザのクライアント・コンピュータに記憶されたローカルなオブジェクト・モデルのファイル１０１６がサーバ・コンピュータに送られ、サーバ・コンピュータのモデル要素アクセス制御システムは、このローカルなオブジェクト・モデルのファイル１０１６を参照する。 このローカルなオブジェクト・モデルのファイル１０１６には実際に複数のモデル要素および代替モデル要素（スタブ）についての情報が含まれている。 よって、各モデル要素および代替モデル要素ごとにその情報が取得（処理１００４）される。

ローカルなオブジェクト・モデルのファイル１０１６から取得された代替モデル要素（スタブ）がある場合は、この代替モデル要素は、チェックアウトの際、オリジナルのモデル要素に対するこのユーザからのアクセス権限が「読出し不可」かつ「編集不可」であったために、代替モデル要素に置換されてチェックアウトされたものであることを意味する。
この代替モデル要素に含まれるＩＤと同一のＩＤを有する、対応するモデル要素を、モデル・リポジトリ内の基準となるオブジェクト・モデルのファイル１０２０の中から検索する。
検索されたその対応するモデル要素について、第１拡張メタデータを参照して、このユーザについて「実行可」の権限が付与されている場合は、この代替モデル要素を、この検索された対応するモデル要素で置換（処理１００６）する。

検索されたその対応するモデル要素について、第１拡張メタデータを参照して、このユーザについて「実行不可」の権限が付与されている場合は、このローカルなオブジェクト・モデルは検証できない旨をこのユーザのクライアント・コンピュータに通知する。

このようにして、モデル検証要求に応答して、ローカルなオブジェクト・モデルに含まれる代替モデル要素が、モデル・リポジトリに記憶されたオリジナルのオブジェクト・モデルに含まれる対応するモデル要素で適宜置換された後、このローカルなオブジェクト・モデルのファイルは、サーバ・コンピュータの環境下でモデル要素アクセス制御システムによってモデル検証が実施（処理１００８）される。 モデル検証の結果は、モデル要素アクセス制御システムから、このユーザのクライアント・コンピュータ側に通知（処理１０１０）される。

このように、ユーザが「読出し可」の権限を持たないため、代替モデル要素に置換されてチェックアウトされている場合でも、そのユーザにその代替モデル要素に対応するオリジナルのモデル要素の内容を見せることなく、チェックアウトしたローカルなオブジェクト・モデルのモデル検証をそのユーザからの要求に応じて実施することができる。

９．ハードウェア資源との関連性
以上、本発明の実施形態について、サーバ・コンピュータが備えるモデル要素アクセス制御システムとして説明し、そのモデル要素アクセス制御システムには構成要件としての複数の機能ブロックが備わることを説明した。
これらの機能ブロックは、このサーバ・コンピュータ（および、場合によっては他のコンピュータ）に記憶されたコンピュータ・プログラムによる情報処理が、このサーバ・コンピュータのＣＰＵ等のハードウェア資源（ハードウェア・コンポーネント）と協働した具体的手段によって実現される。

図１１は、本発明の実施に係るサーバ・コンピュータ１１００の詳細なハードウェア構成の典型的な例を示した図である。 この構成では、コンピュータ・システム１１００の全体の制御をつかさどるプロセッサ１１０２（中央処理装置、ＣＰＵ、メイン・プロセッサ等と称することもある。）の直近にメモリ・コントローラ・ブリッジ１１０４（メモリ・コントローラ、ホスト・コントローラ、メモリ・ブリッジ、第１のブリッジ、ノース・ブリッジ等と称することもある。）が接続される。

メモリ・コントローラ・ブリッジ１１０４にはメイン・メモリ１１０６（メモリ、主記憶等と称することもある。）およびグラフィックス・コントローラ１１０８が直接接続され、プロセッサ１００２から主に高い転送レートでメイン・メモリ１１０６やグラフィックス・コントローラ１１０８をアクセスすることができる。

グラフィック・コントローラ１１０８は、プロセッサ１１０２等がメイン・メモリ１１０６内に設けたフレーム・バッファ上に生成する画像データを取得し、ディスプレイ１１１４（表示装置、ディスプレイ装置、モニタ装置等と称することもある。）上に表示させる。 これに代えて、グラフィック・コントローラ１１０８、プロセッサ１１０２等が生成する画像データを格納するフレーム・バッファ・メモリ１１１０を独自に備えることもできる。

メモリ・コントローラ・ブリッジ１００４からはまた、ＰＣＩローカル・バス１１８０などのバスを介して、Ｉ／Ｏコントローラ・ブリッジ１１１８（Ｉ／Ｏコントローラ、Ｉ／Ｏブリッジ、第２のブリッジ、サウス・ブリッジ等と称することもある。）が接続される。

Ｉ／Ｏコントローラ・ブリッジ１１１８には、ストレージ・コントローラ１１２０（ＩＤＥコントローラ、ＳＣＳＩコントローラ、等）を介してハードディスク・ドライブ１１２２（ＨＤＤ、ハードディスク、ハードディスク・ストレージ、固定記憶装置等と称することもある。）等の大容量記憶装置が接続される。
Ｉ／Ｏコントローラ・ブリッジ１１１８にはまた、ＤＶＤドライブ１１２４、ＣＤＲＯＭドライブ１１２６、ＭＯドライブ１１２８、フレキシブル・ディスク・ドライブ等の外部記憶媒体用装置が接続される。

大容量記憶装置または外部記憶媒体用装置には、本発明を実施させるのに必要なオペレーティング・システム１１３２や、オペレーティング・システム１１３２と協働してプロセッサ１１０２等に命令を与えて本発明を実施させるためのアプリケーション・ソフトウェア１１３０等のコンピュータ・プログラムを記憶する事ができる。 これらコンピュータ・プログラムはメイン・メモリ１１０６にロードされ、プロセッサ１１０２は、メイン・メモリ１００６に格納されたコンピュータ・プログラムに基づいて動作し、各部の制御を行う。
コンピュータ・プログラムは圧縮し、また複数に分割して複数の媒体に記録することもできる。
ハードディスク・ドライブ１１２２にはさらに、本発明の実施に係るオブジェクト・モデルのファイル１１３４を含めることができる。

Ｉ／Ｏコントローラ・ブリッジ１１１８にはまた、キーボード／マウス・コントローラ１１３６が接続され、キーボード１１３８やマウス１１４０のような入力デバイスからの入力を受けつける。
Ｉ／Ｏコントローラ・ブリッジ１１１８にはこの他に、各種の外部バス・インターフェース１１４２、１１４４、１１４６が接続される。
外部バス・インターフェース１１４２は、ＵＳＢ等のシリアル・ポートまたはパラレル・ポートであり、ここを介して各種周辺装置を接続することができる。

外部バス・インターフェース１１４６には、別のコンピュータ・システム１１５０を通信可能に接続することができ、コンピュータ・システム１１５０を構成するハードディスク・ドライブ１１４８に上記コンピュータ・プログラムの全部もしくは一部、または上記オブジェクト・モデルのファイル１１３４を保管させることも可能である。

さらに、外部バス・インターフェース１１４４を介して外部のコンピュータ・ネットワーク１１５２に接続することができる。 このコンピュータ・ネットワーク１１５２を介して接続された別のコンピュータ・システムのハードディスク・ドライブにも、上記コンピュータ・プログラムの全部もしくは一部、または上記オブジェクト・モデルのファイル１１３４を保管させることも可能である。 これは即ち、本発明の実施は、スタンドアロンのサーバ・コンピュータ環境で行うこともでき、あるいは複数のサーバ・コンピュータの環境で行うこともできることを意味する。
なお、このコンピュータ・ネットワーク１１５２を介して、このサーバ・コンピュータにチェックアウトまたはチェックインをするユーザのクライアント・コンピュータを接続することができる。

コンピュータ・システム１１００の大容量記憶装置に記憶され、その全体的な動作を司るオペレーティング・システム１１３２としては、マイクロソフト・コーポレーションが提供するＷｉｎｄｏｗｓ（Ｒ）オペレーティング・システム、アップル・コンピュータ・インコーポレイテッドが提供するＭａｃＯＳ（Ｒ）、Ｘ Ｗｉｎｄｏｗ Ｓｙｓｔｅｍを備えるＵＮＩＸ（Ｒ）系システムといった、ＧＵＩ（Graphical User Interface）をサポートするオペレーティング・システムを採用することができる。
ＵＮＩＸ（Ｒ）系システムには、例えば、インターナショナル・ビジネス・マシーンズ・コーポレーションが提供するＡＩＸ（Ｒ）あるいはＬｉｎｕｘ（Ｒ）等がある。

以上の説明により、本発明の実施に好適なコンピュータ・システム１１００は、通常のパーソナル・コンピュータ、ワークステーション、メインフレーム等の情報処理装置、または、これらの組み合わせによって実現されることが容易に理解されるであろう。

１０．本発明の実施に係る方法
以上、本発明の実施形態を、複数のユーザからのアクセスを制御する、サーバ・コンピュータが備えるモデル要素アクセス制御システムとして説明したが、本発明はまた、当該システムによってその機能を実施するアクセス制御方法としての側面からも捉えることができる。
また、モデル要素アクセス制御システムがその機能を発揮するためには、サーバ・コンピュータ等に記憶されたコンピュータ・プログラムがサーバ・コンピュータのモデル要素アクセス制御システムに上記アクセス制御方法に係る各ステップを実行させることで行うので、本発明はまた、コンピュータ・プログラムとしての側面からも捉えることができる。

図１２は、本発明をアクセス制御方法としての側面から捉えた場合の、実施形態に係る処理手順の流れを示す図である。
モデル要素アクセス制御システムは、まず、ステップ１２０２で、サーバ・コンピュータに記憶されたオブジェクト・モデルの各モデル要素について、そのモデル要素の第１拡張メタデータおよび第２拡張メタデータの初期設定を行う

これ以降、モデル要素アクセス制御システムは、イベント・ドリブンで処理を行う。
ステップ１２０４において、あるユーザから、いくつかのモデル要素についての第１拡張メタデータの内容の変更要求があった場合は、そのいくつかのモデル要素の各々について以下の処理を行う。
先ず、ステップ１２０６において、そのモデル要素の第２拡張メタデータを参照して、そのユーザが第１拡張メタデータを変更可能であるかどうかを調べる。 変更可能であれば、ステップ１２０８で、第１拡張メタデータの内容を、そのユーザの指示に基づいて変更する。
この処理を、このいくつかのモデル要素ごとに繰り返す。

ステップ１２１０において、あるユーザから、いくつかのモデル要素についての第２拡張メタデータの内容の変更要求があった場合は、そのいくつかのモデル要素の各々について以下の処理を行う。
先ず、ステップ１４０２において、そのモデル要素の第２拡張メタデータを参照して、そのユーザが第２拡張メタデータ自身を変更可能であるかどうかを調べる。 変更可能であれば、ステップ１２０２で、第２拡張メタデータの内容を、そのユーザの指示に基づいて変更する。
この処理を、このいくつかのモデル要素ごとに繰り返す。

ステップ１２１４において、あるユーザから、オブジェクト・モデルについてのチェックアウト要求があった場合は、全モデル要素の各々について以下の処理を行う。
先ず、ステップ１２１６において、対象のモデル要素についての第１拡張メタデータを参照して、そのユーザのそのモデル要素に対するアクセス権限が、「読出し可」または「編集可」であるかどうかを調べる。
アクセス権限が、「読出し可」または「編集可」である場合は、ステップ１２１８で、このモデル要素をそのままそのユーザのクライアント・コンピュータに提供する。
アクセス権限が、「読出し可」または「編集可」ではない場合、即ち「読出し不可」かつ「編集不可」ある場合は、ステップ１２２０で、このモデル要素を代替モデル要素（スタブ）で置き換えて、そのユーザのクライアント・コンピュータに提供する。
この処理を、このオブジェクト・モデルの全モデル要素ごとに繰り返す。

ステップ１２２２において、あるユーザから、オブジェクト・モデルについてのチェックイン要求があった場合は、チェックインさせようとしているローカルなオブジェクト・モデルの全モデル要素および代替モデル要素の各々について以下の処理を行う。
先ず、ステップ１２２４において、対象のローカルなモデル要素等についての第１拡張メタデータを参照して、そのユーザのそのモデル要素に対するアクセス権限が、「編集可」であるかどうかを調べる。
アクセス権限が、「編集可」である場合は、ステップ１２２６で、このローカルなモデル要素をそのままサーバ・コンピュータのモデル・リポジトリに書き戻す。
アクセス権限が「編集可」ではない場合は、更にステップ１２２８において、アクセス権限が「読出し可」であるかどうか調べる。 「読出し可」である場合は、ステップ１２３０で、このローカルなモデル要素をサーバ・コンピュータのモデル・リポジトリに書き戻さず、モデル・リポジトリにある対応するモデル要素を利用する。 「読出し可」ではない場合とは、即ち、代替モデル要素である場合を意味する。 この場合は、ステップ１２３２で、この代替モデル要素をサーバ・コンピュータのモデル・リポジトリに書き戻さず、この代替モデル要素と同一のＩＤを持つ、モデル・リポジトリにある対応するモデル要素を利用する。
この処理を、このオブジェクト・モデルの全モデル要素ごとに繰り返す。

以上、本発明を実施の形態を用いて説明したが、本発明の技術的範囲は上記実施の形態の記載の範囲には限定されない。
上記実施の形態に、多様な変更または改良を加えることが可能であることが当業者に明らかである。 またその様な変更または改良を加えた形態も本発明の技術的範囲に含まれ得ることが、特許請求の範囲の記載から明らかである。 さらに、上記実施の形態の中で説明されている特徴の組み合わせの全てが、発明の解決手段に必須とは限らないことにも留意されたい。

モデル駆動型の開発におけるシステム環境の例を表す。 モデル・リポジトリとしてサーバ・コンピュータ内に記憶される、基準となるオブジェクト・モデルの例を示す。 本発明の実施に係る、オブジェクト・モデルの各モデル要素の内部構成の例を示す。 本発明の実施に係る、モデル要素アクセス制御システムの構成とその機能を模式的に示す。 ユーザからのチェックアウト要求があった場合の、本発明の実施に係る処理の流れを模式的に示す。 モデル要素と、対応する代替モデル要素（スタブ）との間の構成例の比較を示す。 ユーザからのチェックイン要求があった場合の、本発明の実施に係る処理の流れを模式的に示す。 他のモデル要素との関係性を示す情報を拡張メタデータとして有しているモデル要素と、対応する代替モデル要素（スタブ）との間の構成例の比較を示す。 チェックアウトがされた後の、ローカルな環境下でのオブジェクト・モデルの例を示す。 ユーザからのモデル検証要求があった場合の、本発明の実施に係る処理の流れを模式的に示す。 本発明の実施に係るサーバ・コンピュータの詳細なハードウェア構成の典型的な例を示す。 アクセス制御方法としての側面から捉えた場合の、実施形態に係る処理手順の流れを示す。

Claims (11)

1. それぞれが固有のＩＤを有する複数のモデル要素を備える、サーバ・コンピュータに記憶されたオブジェクト・モデルに対して、複数のユーザからのアクセスを制御するシステムであって、
   前記複数のモデル要素のそれぞれについて、前記複数のユーザの各々からの当該モデル要素に対するアクセス権限の種類を規定する第１拡張メタデータを当該モデル要素に関連付けて設定し、および、前記第１拡張メタデータおよび自身を修正する権限があるかどうかを示す第２拡張メタデータを当該モデル要素に関連付けて設定し、前記第２拡張メタデータには、各ユーザについて前記第１拡張メタデータを修正する権限があることが初期的に示される、初期設定部と、
   第１ユーザからの第１拡張メタデータの編集要求に応じて、１以上のモデル要素のそれぞれについて、１以上のユーザの各々について、前記第２拡張メタデータが、前記第１拡張メタデータを編集する権限があることを示す場合に、前記第１拡張メタデータを編集する、第１拡張メタデータ編集部と、
   第２ユーザからの第２拡張メタデータの編集要求に応じて、１以上のモデル要素のそれぞれについて、１以上のユーザの各々について、前記第１拡張メタデータを編集する権限がないことを示すように前記第２拡張メタデータを編集する、第２拡張メタデータ編集部と、
   第３ユーザからの、前記オブジェクト・モデルを前記第３ユーザのクライアント・コンピュータにローカルなオブジェクト・モデルとして取り込むためのチェックアウト要求に応答してチェックアウトを行う、アクセス管理部であって、前記チェックアウトは、前記複数のモデル要素の各々について、前記第３ユーザに関して、
   （１）読出し可能のアクセス権限または編集可能のアクセス権限があることを当該モデル要素の前記第１拡張メタデータが示す場合は、当該モデル要素をそのまま前記クライアント・コンピュータに提供し、
   （２）読出し可能のアクセス権限および編集可能権のアクセス権限のいずれも無いことを当該モデル要素の前記第１拡張メタデータが示す場合は、当該モデル要素の代わりに、その内容を取り除いて少なくとも同一のＩＤと第１拡張メタデータのみを付与した、代替モデル要素を前記クライアント・コンピュータに提供する、
   アクセス管理部と、
   を備えるシステム。
2. 前記アクセス管理部は、さらに、第４ユーザからの、前記第４ユーザのクライアント・コンピュータにおけるローカルなオブジェクト・モデルを前記オブジェクト・モデルに書き戻すためのチェックイン要求に応答してチェックインを行い、前記チェックインは、前記ローカルなオブジェクト・モデルが備える複数のローカルなモデル要素の各々について、前記第４ユーザに関して、
   （１）編集可能のアクセス権限があることを当該ローカルなモデル要素の前記第１拡張メタデータが示す場合は、当該ローカルなモデル要素を前記オブジェクト・モデルに書き戻し、
   （２）読出し可能のアクセス権限があるが編集可能のアクセス権限が無いことを当該ローカルなモデル要素の前記第１拡張メタデータが示す場合は、当該ローカルなモデル要素の代わりに、当該ローカルなモデル要素のＩＤと同一のＩＤを有する、前記オブジェクト・モデル内の当該ローカルなモデル要素に対応するモデル要素を用い、
   （３）当該ローカルなモデル要素が代替モデル要素である場合、前記代替モデル要素の代わりに、前記代替モデル要素のＩＤと同一のＩＤを有する、前記オブジェクト・モデル内の前記代替モデル要素に対応するモデル要素を用いる、
   請求項１に記載のシステム。
3. 当該ローカルなモデル要素の代わりに、当該ローカルなモデル要素のＩＤと同一のＩＤを有する、前記オブジェクト・モデル内の当該ローカルなモデル要素に対応するモデル要素を用いることは、
   当該ローカルなモデル要素が前記第４ユーザによって編集されていた場合には、チェックインを拒否し、前記第４ユーザに対して、当該ローカルなモデル要素の編集を許容できない旨の通知をすることを含む、
   請求項２に記載のシステム。
4. 前記代替モデル要素の代わりに、前記代替モデル要素のＩＤと同一のＩＤを有する、前記オブジェクト・モデル内の前記代替モデル要素に対応するモデル要素を用いることは、
   前記代替モデル要素が前記第４ユーザによって編集されていた場合であって、その編集が、他のモデル要素との関係性を追加する変更であった場合に、前記代替モデル要素に対応するモデル要素に、前記他のモデル要素との関係性を追加する前記変更を反映させることを含む、
   請求項３に記載のシステム。
5. 前記アクセス管理部は、さらに、第５ユーザから、前記第５ユーザのクライアント・コンピュータにおける前記ローカルなオブジェクト・モデルについて、モデル検証の要求があった場合に、前記ローカルなオブジェクト・モデルが備える複数のローカルなモデル要素の各々について、
   当該ローカルなモデル要素が代替モデル要素であり、かつ、前記第５ユーザに関して、実行可能のアクセス権限があることを当該代替モデル要素の前記第１拡張メタデータが示す場合は、前記代替モデル要素の代わりに、前記代替モデル要素のＩＤと同一のＩＤを有する、前記オブジェクト・モデル内の前記代替モデル要素に対応するモデル要素を用いて、
   前記ローカルなオブジェクト・モデルの前記モデル検証を完遂する、請求項３に記載のシステム。
6. 前記オブジェクト・モデルはＵＭＬにより記述されたモデルであり、前記第１の拡張メタデータおよび前記第２の拡張メタデータは、前記ＵＭＬの拡張機能であるステレオタイプであり、前記代替モデル要素は、前記ＵＭＬにおけるスタブである、請求項１に記載のシステム。
7. 前記オブジェクト・モデルはＳｙｓＭＬにより記述されたモデルであり、前記第１の拡張メタデータおよび前記第２の拡張メタデータは、前記ＵＭＬの拡張機能であるステレオタイプであり、前記代替モデル要素は、前記ＵＭＬにおけるスタブである、請求項１に記載のシステム。
8. それぞれが固有のＩＤを有する複数のモデル要素を備える、サーバ・コンピュータに記憶されたオブジェクト・モデルに対しての、複数のユーザからのアクセスを、当該サーバ・コンピュータによって制御する方法であって、
   前記複数のモデル要素のそれぞれについて、前記複数のユーザの各々からの当該モデル要素に対するアクセス権限の種類を規定する第１拡張メタデータを当該モデル要素に関連付けて設定し、および、前記第１拡張メタデータおよび自身を修正する権限があるかどうかを示す第２拡張メタデータを当該モデル要素に関連付けて設定し、前記第２拡張メタデータには、各ユーザについて前記第１拡張メタデータを修正する権限があることを示すように初期設定するステップと、
   第１ユーザからの第１拡張メタデータの編集要求に応じて、１以上のモデル要素のそれぞれについて、１以上のユーザの各々について、前記第２拡張メタデータが、前記第１拡張メタデータを編集する権限があることを示す場合に、前記第１拡張メタデータを編集するステップと、
   第２ユーザからの第２拡張メタデータの編集要求に応じて、１以上のモデル要素のそれぞれについて、１以上のユーザの各々について、前記第１拡張メタデータを編集する権限がないことを示すように前記第２拡張メタデータを編集するステップと、
   第３ユーザからの、前記オブジェクト・モデルを前記第３ユーザのクライアント・コンピュータにローカルなオブジェクト・モデルとして取り込むためのチェックアウト要求に応答してチェックアウトを行うステップであって、前記チェックアウトは、前記複数のモデル要素の各々について、前記第３ユーザに関して、
   （１）読出し可能のアクセス権限または編集可能のアクセス権限があることを当該モデル要素の前記第１拡張メタデータが示す場合は、当該モデル要素をそのまま前記クライアント・コンピュータに提供し、
   （２）読出し可能のアクセス権限および編集可能権のアクセス権限のいずれも無いことを当該モデル要素の前記第１拡張メタデータが示す場合は、当該モデル要素の代わりに、その内容を取り除いて少なくとも同一のＩＤと第１拡張メタデータのみを付与した、代替モデル要素を前記クライアント・コンピュータに提供する、
   ステップと、
   を備える方法。
9. 第４ユーザからの、前記第４ユーザのクライアント・コンピュータにおけるローカルなオブジェクト・モデルを前記オブジェクト・モデルに書き戻すためのチェックイン要求に応答してチェックインを行うステップであって、前記チェックインは、前記ローカルなオブジェクト・モデルが備える複数のローカルなモデル要素の各々について、前記第４ユーザに関して、
   （１）編集可能のアクセス権限があることを当該ローカルなモデル要素の前記第１拡張メタデータが示す場合は、当該ローカルなモデル要素を前記オブジェクト・モデルに書き戻し、
   （２）読出し可能のアクセス権限があるが編集可能のアクセス権限が無いことを当該ローカルなモデル要素の前記第１拡張メタデータが示す場合は、当該ローカルなモデル要素の代わりに、当該ローカルなモデル要素のＩＤと同一のＩＤを有する、前記オブジェクト・モデル内の当該ローカルなモデル要素に対応するモデル要素を用い、
   （３）当該ローカルなモデル要素が代替モデル要素である場合、前記代替モデル要素の代わりに、前記代替モデル要素のＩＤと同一のＩＤを有する、前記オブジェクト・モデル内の前記代替モデル要素に対応するモデル要素を用いる、
   ステップを更に備える、請求項８に記載の方法。
10. それぞれが固有のＩＤを有する複数のモデル要素を備える、サーバ・コンピュータに記憶されたオブジェクト・モデルに対しての、複数のユーザからのアクセスを制御するための、コンピュータ・プログラムであって、当該サーバ・コンピュータに、
    前記複数のモデル要素のそれぞれについて、前記複数のユーザの各々からの当該モデル要素に対するアクセス権限の種類を規定する第１拡張メタデータを当該モデル要素に関連付けて設定し、および、前記第１拡張メタデータおよび自身を修正する権限があるかどうかを示す第２拡張メタデータを当該モデル要素に関連付けて設定し、前記第２拡張メタデータには、各ユーザについて前記第１拡張メタデータを修正する権限があるこを示すように初期設定するステップと、
    第１ユーザからの第１拡張メタデータの編集要求に応じて、１以上のモデル要素のそれぞれについて、１以上のユーザの各々について、前記第２拡張メタデータが、前記第１拡張メタデータを編集する権限があることを示す場合に、前記第１拡張メタデータを編集するステップと、
    第２ユーザからの第２拡張メタデータの編集要求に応じて、１以上のモデル要素のそれぞれについて、１以上のユーザの各々について、前記第１拡張メタデータを編集する権限がないことを示すように前記第２拡張メタデータを編集するステップと、
    第３ユーザからの、前記オブジェクト・モデルを前記第３ユーザのクライアント・コンピュータにローカルなオブジェクト・モデルとして取り込むためのチェックアウト要求に応答してチェックアウトを行うステップであって、前記チェックアウトは、前記複数のモデル要素の各々について、前記第３ユーザに関して、
    （１）読出し可能のアクセス権限または編集可能のアクセス権限があることを当該モデル要素の前記第１拡張メタデータが示す場合は、当該モデル要素をそのまま前記クライアント・コンピュータに提供し、
    （２）読出し可能のアクセス権限および編集可能権のアクセス権限のいずれも無いことを当該モデル要素の前記第１拡張メタデータが示す場合は、当該モデル要素の代わりに、その内容を取り除いて少なくとも同一のＩＤと第１拡張メタデータのみを付与した、代替モデル要素を前記クライアント・コンピュータに提供する、
    ステップと、
    を実行させるための、コンピュータ・プログラム。
11. 第４ユーザからの、前記第４ユーザのクライアント・コンピュータにおけるローカルなオブジェクト・モデルを前記オブジェクト・モデルに書き戻すためのチェックイン要求に応答してチェックインを行うステップであって、前記チェックインは、前記ローカルなオブジェクト・モデルが備える複数のローカルなモデル要素の各々について、前記第４ユーザに関して、
    （１）編集可能のアクセス権限があることを当該ローカルなモデル要素の前記第１拡張メタデータが示す場合は、当該ローカルなモデル要素を前記オブジェクト・モデルに書き戻し、
    （２）読出し可能のアクセス権限があるが編集可能のアクセス権限が無いことを当該ローカルなモデル要素の前記第１拡張メタデータが示す場合は、当該ローカルなモデル要素の代わりに、当該ローカルなモデル要素のＩＤと同一のＩＤを有する、前記オブジェクト・モデル内の当該ローカルなモデル要素に対応するモデル要素を用い、
    （３）当該ローカルなモデル要素が代替モデル要素である場合、前記代替モデル要素の代わりに、前記代替モデル要素のＩＤと同一のＩＤを有する、前記オブジェクト・モデル内の前記代替モデル要素に対応するモデル要素を用いる、
    ステップを更に前記サーバ・コンピュータに実行させるための、請求項１０に記載のコンピュータ・プログラム。
    

Images