JPH0683595A - 永続的及び過渡的オブジェクトのバージョンと構成を管理する機能を提供する方法と装置 - Google Patents

Abstract

(57)【要約】 （修正有） 【目的】媒体に依存せず、オブジェクト指向の方法で過
渡的かつ永続的両オブジェクトの変更を管理する。 【構成】関数パラメータとして分野固有の情報及び、イ
ンターフェースを介して抽象マシンへオブジェクト型情
報を入力する段階、前記抽象マシン内でユーザ選定の方
針を初期化する段階、前記抽象マシンの私的状態に変更
管理データ構造を記憶する段階であって、データ構造は
一般的なアプリケーション非依存の方法で管理される記
憶段階、少なくとも１つの名前を含む名前空間を管理す
る段階、前記少なくとも１つの名前のみを用いてアプリ
ケーションと通信する段階、前記の記憶した変更管理デ
ータを更新する段階、並びに前記名前と共に型無ポイン
タ構造を用いてアプリケーションへ情報を返す段階を有
する。

Description

【発明の詳細な説明】

【０００１】

【産業上の利用分野】本発明はソフトウェア・システム
及びアプリケーションの変更管理に関係し、特に一般的
な、分野によらない、媒体に依存しない方法でオブジェ
クトの発展と構成を支持するシステムと方法に関する。

【０００２】

【従来の技術】多くのソフトウェア及び設計アプリケー
ションはオブジェクトの発展に加えて、オブジェクトを
層状階層記述に構成するためのサポートを必要としてい
る。「変更管理」は抽象化の設計と実装を発展させる際
の助けとなる技術の一連の組として定義される。これら
の技術は来歴を記録する、別案を調査する、層別設計を
管理するため多くのレベルで適用可能である。

【０００３】システムを定義し、ソフトウェアを設計す
るための技術として抽象マシンを使用する考えはソフト
ウェア工学では非常に良く知られている。通常、抽象マ
シンを使用して、これらのシステムの設計をハイパーテ
キスト・システム又はモデル化システムとして指定す
る。

【０００４】今日のソフトウェア・システムでは、変更
管理はアプリケーションと密接に作用する機能として取
扱われる。変更管理情報と分野知識は混合しているた
め、変更管理部品が存在する場合は別の実体としては識
別不能である。識別可能な変更管理部品はしばしばファ
イル・システムと密接に作用し、管理可能なオブジェク
トとしてファイルのみを支持する。いくつかの変更管理
システムが存在するが、これらはターゲットとしている
１つの特定の分野の必要性に立脚してるのみである（例
えば、コンピュータ支援電子設計、コンピュータ支援ソ
フトウェア工学、オーサリング・システム等）。

【０００５】現在のシステムは分野及びアプリケーショ
ンに特定の方法で変更管理を実装する。このことは、シ
ステムが再利用可能ではなく、新たなアプリケーション
毎に同様の技術の組を特別に再実装する必要があること
を意味する。例えば、バークレー・バージョン・サーバ
ーはコンピュータ支援設計の変更を管理し、サン・マイ
クロシステムのＮＳＥはソフトウェア開発の変更を管理
する。これらのシステムは共にユニックス・オペーレー
ティング・システム下のサン・マイクロシステム・ワー
クステーション上で動作するが、両システム共変更管理
ソフトウェアにその分野の知識を埋込んでいるためコー
ド共有はない。

【０００６】現在のシステムは、埋め込まれている単一
のアプリケーション環境に緊密に結びつけられ、主要な
再設計または再実装なしには環境への変化に耐える程十
分堅牢ではない。このような変化の例は監査跡を保持す
る方法を変更するための経営決定がある。このように緊
密に結合された又は埋め込まれた支持システムの主要な
欠点は、アプリケーションのセマンテックが混合された
抽象化を有する点である。混合抽象化は、設計、実装、
検証、保守が困難なソフトウェアに導かれる。

【０００７】加えて、現在のシステムは固定データの変
更管理を支持するのみである。過渡的データも又変更を
受ける。それ故、過渡的及び永続的データの両方に対し
て統一的な方法で変更を管理する必要がある。

【０００８】現在の所、システムは変更をうける情報単
位はファイルであるというアプローチを取る。ファイル
は単に記憶システムの工作物であり、しばしばアプリケ
ーションが関心を持つオブジェクトとは何の関係もな
い。オブジェクトは通常、設計ブロック、機能定義、ま
たはテキスト行のような多数の論理単位から構成され
る。変更管理システムはアプリケーションに意味ある全
ての論理単位を支持する必要がある。

【０００９】

【発明の要約】関連技術と関係する上記の問題を考慮し
て、本発明の目的は、分野に独立でアプリケーションに
特定されず、オブジェクトの型と記憶クラスに対して多
態（ｐｏｌｙｍｏｒｐｈｉｃ）な方法でオブジェクトの
発展と共にオブジェクトの構造と構成を層状の階層構造
に管理する変更管理システムとその方法を提供すること
である。

【００１０】本発明の他の目的は、サービスを利用する
クライアントのデータ構造に何らの変更を必要としな
い、プログラミング言語関数から構成される簡単なイン
ターフェースによりクライアント（アプリケーション）
へ与えられるサービスとして変更管理を提供することで
ある。

【００１１】本発明のさらに他の目的は、その初期状態
がアプリケーションから隠され、これにより与えられた
インターフェースを除いて変更管理システムとアプリケ
ーションを分離するようにした変更管理システムを提供
することである。

【００１２】本発明のさらに他の目的は、アプリケーシ
ョンが正確な良く定義された方法で変更管理システムへ
分野情報を宣言し、変更管理システムは分野の知識を有
することなく情報を利用するような変更管理システムと
その方法を提供することである。

【００１３】本発明の別な目的は、組織の政策が変更さ
れた時変更管理システムが時代遅れとならないように方
針層を提供することである。

【００１４】本発明の他の目的は、型又は寸法に係ら
ず、一様な方法で過渡的及び永続的オブジェクトの発展
を管理することである。

【００１５】本発明のさらに他の目的は、永続的媒体へ
の取込取出が可能となるようにシステムの内部構造に対
する外部オブジェクト表示を提供することである。

【００１６】本発明の上記目的に従って、本発明の好適
実施例は変更管理仮想マシン、以後「ＣＭＶＭ」と呼ぶ
ものである。仮想マシンとしての変更管理の実装は、こ
れが設置と使用が容易であり、かつ既存のアプリケーシ
ョンに対して最小の外乱を含む。アプリケーションのデ
ータ構造は、その発展と組成が管理されていることを知
る必要はない。これは、変更管理が特別に押しつけて、
高度に輸部的な方法で実行され、変更管理のセマンテッ
クスがアプリケーションのセマンテックスと混合してい
る既存の技術と対比される。

【００１７】ソフトウェア・アプリケーションはＣＭＶ
Ｍの公開されたインターフェースを用いて変更管理サー
ビスを得る。ＣＭＶＭは丁度データベース管理システム
（ＤＢＭＳ）がデータ管理サービスを与えるように変更
管理サービスをアプリケーションに与える。ＣＭＶＭは
その内部状態の一部として変更管理に必要な全てのデー
タ構造を作成し管理する。アプリケーションはこれらの
構造をアクセスしたり指す必要はなく、これによりアプ
リケーションのデータ構造又は制御流れに何らの変更を
加えることなく変更管理を提供できる。クライアント
（アプリケーション）は方針の組から選択することによ
りＣＭＶＭの全体的ふるまいを調整する。このような全
体的方針はさらにインターフェース関数に指定した引数
を介して一時的にオーバライド可能である。

【００１８】本発明の好適実施例は変更を管理すること
に関係する機能を抽象化し、抽象化を純粋なサービスと
して実装する。この純粋なサービスはＣＭＶＭ内でノー
ドのグラフとして実現される。グラフはバージョンと構
成に関してアプリケーションの変更管理情報を表現す
る。ノードはマシンのポインタ又は他の何らかの型式の
識別子のどちらかを用いてアプリケーション・データを
指す。アプリケーションがインターフェース関数の１つ
を介して本発明を呼ぶと、内部のグラフ構造が更新され
る。何らかのアプリケーション・データ構造を変換する
必要がある場合、このような変換はＣＭＶＭに代ってア
プリケーションにより実行される。ＣＭＶＭは後述する
ようにＣＭＶＭ初期化時にＣＭＶＭに宣言された関数を
呼ぶことにより前記変換を要求する。

【００１９】ＣＭＶＭ初期化は宣言の組から構成され
る。一組の宣言がＣＭＶＭへ、管理すべきオブジェクト
の型名、この型に関係する関数の名前を与える。標準的
な宣言は、型「文書」のオブジェクトを管理すべきで、
文書をマージする関数名は「ｄｏｃｕｍｅｎｔ−ｍｅｒ
ｇｅ」であることを記述する。このような関数はＣＭＶ
Ｍの要求で常にアプリケーション空間で実行する。関数
名と型名はＣＭＶＭの内部状態に保持される。ＣＭＶＭ
はこれらの関数を介してのみユーザのデータを操作す
る。この結果、丁度ＣＭＶＭがアプリケーションに対し
て抽象マシンとして見えるようにアプリケーションはＣ
ＭＶＭに対して抽象マシンとして見える。他の組の宣言
がＣＭＶＭに変更管理方針のアプリケーションの選択を
与える。望ましい実施例では、アプリケーションが選択
する一定の組の方針がある。ＣＭＶＭの方針層はＣＭＶ
Ｍをカスタマイズして変更の管理に関する組織の方針を
実装可能とする。例えば、ある組織の方針は大規模な監
査跡を保持することを命令するが、一方他の組織は監査
跡に何の必要性も有しない。

【００２０】ＣＭＶＭは２個の直交する抽象マシンを用
いて実装される。バージョン抽象マシンはバージョンを
管理し、構成抽象マシンは構成を管理する。これらのサ
ービスの一方のみを必要とするアプリケーションはこれ
らのマシンの内の一方のみを使用する必要がある。２つ
のマシンの仮想マシンとしてのグループ化は単なる機能
上の都合である。互いに直交した抽象マシンの組合せと
してのＣＭＶＭの設計はその拡張性を保証する際の重大
な要因である。

【００２１】ＣＭＶＭの関数呼出はアプリケーション・
コードの内側から行われる。アプリケーションの最終ユ
ーザはこれらの呼出しを見ず、事実ＣＭＶＭの存在を間
接的にのみ知っている。

【００２２】ＣＭＶＭは管理するオブジェクトの型と記
憶状態に関して多態である。過渡的および永続的オブジ
ェクトは一様な方法で処理される。型に固有の情報、例
えばオブジェクトをいかにマージするか、はアプリケー
ションを初期化する時ＣＭＶＭへ宣言される。ＣＭＶＭ
は下の永続的記憶に関して何の仮定もしない。他の変更
管理システム（本発明を使用しないもの）は所定の型の
永続的オブジェクトを管理するよう自身を限定し、通常
ファイルが基本となっている。本発明のこれらの及び他
の特徴と利点は添附図面と共に取られた好適実施例の以
下の詳細な説明から当業者には明らかとなる。

【００２３】

【実施例】本発明の以下の詳細な説明を考慮する時、変
更管理を必要とする任意のアプリケーションは、ＣＭＶ
Ｍインターフェース関数を呼出しうる言語でアプリケー
ションが書かれている限りＣＭＶＭを使用可能であるこ
とを想起すべきである。例えば、ＦＯＲＴＲＡＮで書か
れたアプリケーションは、アプリケーションの動作環境
がＦＯＲＴＲＡＮからＣまたはＬＩＳＰ関数の呼出しを
支持している場合にはＣＭＶＭインターフェース関数を
呼出し可能である。本発明はＣｏｍｍｏｎＬｉｓｐ及び
ＣＴＴで実装された。好適実施例は以下で説明するＣＴ
Ｔ実装であるが、本発明の設計は一般のプログラミング
言語の任意のものでの実装として実現化可能である。Ｌ
ｉｐｓ及びＣＴＴ実装は実装言語の微小なシンタックス
上の差異を除いては同一である。

【００２４】本発明は方針の組により駆動され、アプリ
ケーション固有の情報を埋込む必要がないため、同じマ
シンを異なるアプリケーション、異なるハードウェア及
びソフトウェア・プラットフォームに使用可能である。
唯一の要件は、クライアントのアプリケーションがＣＭ
ＶＭのインターフェースへの関数呼出を実行可能なこと
である。例えば、本発明をＣまたはＣＴＴで実装する場
合、ＡｄａコンパライがＣで書かれた関数を呼出可能な
らばＡｄａで書かれたアプリケーションを管理可能であ
る。

【００２５】本発明の好適実施例によるＣＭＶＭはアプ
リケーションのオブジェクトのバージョンと構成の管理
を支持するため「抽象マシン」と呼ばれる２つのソフト
ウェア・モジュールから構成される。第１の抽象マシン
はバージョン抽象マシン（ＶＡＭ）と呼ばれ、第２の抽
象マシンは構成抽象マシン（ＣＡＭ）と呼ばれる。これ
らの抽象マシンはクライアントのアプリケーションにイ
ンターフェースを提供するソフトウェア・モジュール
で、ハードウェアマシンのマシン命令とマシン状態と類
似の内部状態を保持する。クライアントのアプリケーシ
ョンはインターフェースを介して抽象マシンと通信す
る。これらのアプリケーションは抽象マシンのデータ構
造の知識を有さず、その内部状態をアクセス不能であ
る。抽象マシンは知る必要のあるクライアントのオブジ
ェクトの名前空間を管理する。ＣＭＶＭは２つのマシン
の内部状態の変更管理に関係する全ての情報を保持す
る。

【００２６】図１はＶＡＭとＣＡＭの組合せとしてのＣ
ＭＶＭのアーキテクチャを図示する。図１で、ＣＭＶＭ
２０は２つの抽象マシン２２，２４から構成される。Ｖ
ＡＭ２２はオブジェクトのバージョンを管理する責任を
有し、ＣＡＭ２４はオブジェクトの構成を管理する責任
を有する。ＶＡＭ２２のインターフェース２６はマシン
状態２８を含む。マシン状態２８はユーザから隠されて
いる。インターフェース２６は「命令セット」（表１の
項目（１００−１５４））として知られる関数の組であ
る。同様に、ＣＡＭ２４はインターフェース２５とマシ
ン状態２７を有する。ＣＡＭのインターフェース２５は
以下の表２に図示する命令セットを含む。ＣＡＭ２４と
ＶＡＭ２２の命令セットは以下で説明する。

【００２７】図１に戻ると、ＶＡＭ２２とＣＡＭ２４と
の間の両方向矢印は、ＣＡＭ２４とＶＡＭ２２が命令セ
ットのみを用いて互いに通信していることを示してい
る。抽象化の分離の原則はＣＭＶＭのアーキテクチャに
厳格に固定されている。

【００２８】クライアントのアプリケーションはＣＭＶ
Ｍをサービスとして見る。サービス要求は命令セットを
用いてクライアントのアプリケーションにより行われ
る。クライアントはいかにサービスを得るか、どのサー
ビスが利用可能かのみを考える必要があり、サービス実
装の詳細はクライアントには何の関りもない。典型的に
は、クライアントのアプリケーションの設計者はアプリ
ケーション・コードにＣＭＶＭ命令を埋込む。ＣＭＶＭ
を使用するアプリケーションのエンド・ユーザは付加機
能を除いてはＣＭＶＭの存在を明確には知らない。ＣＭ
ＶＭ命令はアプリケーション分野の用語で書かれたユー
ザ指令の結果として実行される。例えば、テキスト・エ
ディタがファイルの過去のバージョンを法的、安全性、
又は履歴上の理由から保持し、媒体損傷に対して保護す
ることを望むものとする。これは又ファイルが多数の人
間により編集される場合には別の発展路を管理する必要
もある。エディタの実装者はエディタを実装するソフト
ウェア内部の適切な所でＣＭＶＭを呼出す。エンド・ユ
ーザが「ファイル保存（Ｓａｖｅ Ｆｉｌｅ）」指令を
与えると、バージョンの生成と発展路におけるその適切
な配置がサービスとしてエディタに与えられる。動作は
ユーザには透明である。

【００２９】アプリケーションから切離したサービスと
して変更管理を提供する本発明のアプローチは図２に図
示した既存にアプローチと対比される。既存のアプリケ
ーション（本発明を使用しない）では、変更管理構造は
アプリケーション構造に束ねられ、変更管理データはア
プリケーション・データから分離されない。アプリケー
ションの実体３０はアプリケーション・データ３２と変
更管理データ３４を管理する。このアプローチの明白な
欠点は、データ構造の主要な再設計やアプリケーション
・コードの主要な再修正なしには変更管理を既存のアプ
リケーションに実装不能な点である。又、選択的に変更
管理サービスを消勢することも困難である。しかしなが
ら主要な欠点は、大体は直交したセマンテック単位とし
ての変更管理の特別な知識を有さない開発者により、同
じ機能が各アプリケーションで再実装されている点であ
る。

【００３０】本発明のアプローチは図３で現在のアプロ
ーチと対比されている。図３の左側はアプリケーション
の実体４０，４２，４４，４６（その各々が図２のアプ
リケーション実体３０の例）が既存システムにより使用
されるバージョン階層にいかに関係しているかを示す。
このバージョン階層はアプリケーション・セマンテック
スを混乱させるのみで、アプリケーションから分離され
なければならない。図３の右側はアプリケーション・セ
マンテックスからのバージョン構造の分離が本発明でい
かに実施されたかを図示する。バージョン構造５０はア
プリケーションから分離される。項目６０，６１，６
２，６３，６４から構成されるバージョン構造５０はＣ
ＭＶＭの私的状態に存在する。アプリケーション構造か
ら変更管理構造を除去することはアプリケーションを簡
単化する。これは、変更管理サービスを提供するためア
プリケーション・データ構造を変更しないことにより重
要な目的を達成する。図３を図２と比較することによ
り、変更部が見えてくる、すなわち変更管理データ３４
をアプリケーション実体３０から除去し、代りにバージ
ョン構造５０のノードに置く。これはアプリケーション
から変更管理を有効に分離する。

【００３１】本発明の好適実施例ＣＭＶＭは、一時的な
発展のみを管理した従来の変更管理システムに対向し
て、オブジェクトの時間的、非時間的、又は質的側面を
基にしたバージョン操作を処理する。それ故、ＶＡＭ２
２はオブジェクトの発展に対する支持を提供する。ＶＡ
Ｍ２２は線形及び分岐履歴と共に履歴のマージも支持す
る。履歴はアプリケーションの分野で非時間的または非
量的特性を基にしてもよい。例えば、回路設計の分野で
は、チップは早いチップ、より早いチップ等のように性
能を基にした履歴を有してもよい。同じ分野で、全体の
設計は完了設計、検証設計、検査設計等のように確信レ
ベルを基に発展してもよい。時間を基にした履歴の通常
の場合では、ＶＡＭ２２は時刻スタンプ、ベースライン
操作、主／細／実験バージョンを支持する。「取消（Ｕ
ｎｄｏ）」機能は「もしこうしたら」実験を提供する。
ＶＡＭ２２は、オブジェクトをいかにマージするか、異
なるバージョンをいかにして導出するかを指定するため
の機能を提供する。

【００３２】ＶＡＭ２２は１次バージョンとしてノード
の多重バージョンの１つを区別する。各ノードはその１
次バージョンと他の別なバージョンと共にそれを導いた
バージョンを知っている。この種の知識は、グラフの各
ノードに割当てた内部システム識別子と共に使用され
て、バージョンを追加／削除／マージ／修正するユーザ
の要求を検証し実行する。

【００３３】ＶＡＭ２２の主要データ構造はノードのグ
ラフであり、各ノードはオブジェクトの１つのバージョ
ンをモデル化する。バージョン管理される各オブジェク
トには１つのグラフがある。図４は本発明の好適実施例
によるこのようなグラフのブロック線図である。全体構
造は「バージョン・グラフ」７０として参照される。項
目７２−９４はバージョン・グラフ７０のノードであ
る。ノードＡからノードＢへの矢印は、ＢがＡにより表
現されるオブジェクトの１つのバージョンであるオブジ
ェクトを表していることを示す。アプリケーションが表
１にあげた命令セットを介してＶＡＭ２２（特に図示せ
ず）のサービスを要求する時、グラフはＶＡＭ２２の私
的状態で更新される。ＶＡＭ２２の私的状態はハッシュ
表に構成したこのようなグラフの集まりから主に構成さ
れる。私的状態中の他のデータ構造は後述する名前空間
である。

【００３４】アプリケーションの完全な機能性を提供す
るため協動するモジュールを一体とする際の主な問題の
１つはデータの交換である。ＣＭＶＭは、全てのデータ
・アクセスが数字のような原始データ型の文字列名を介
して間接的に発生することを必要とすることによりこの
問題に対処する。ＶＡＭ２２とＣＡＭ２４は名前空間を
管理して内部状態を文字列名へ写し込む。好適実施例で
は、この名前空間は多重レベル・ハッシュ表の集合とし
て実装される。

【００３５】「取消」操作を支持するためスタック構造
が使用される。リストや表のような各種容器構造を用い
てデータを効率的に管理する。これらの構造はＶＡＭ２
２の動作には基本のものではなく、本明細書ではこれ以
上議論しない。

【００３６】図４は７２のオブジェクトが一連の発展を
とげた後のバージョン・グラフ７０を示す。図４を生じ
うるいくつかの命令の組合せが存在する。このような命
令の可能な組の１つは、図８を参照して、命令列１０
０，１０２，１０４，１０２，１０４，１０２，１０
４，１０２，１０４，１０２，１０４，１０２，１０
４，１０８，１０４である。バージョン・グラフ７０は
ノードかマージした時を除いて木構造を有する。ノード
がマージすると、図４のマージしたノード７８はそれが
マージされた全てのノードのバージョンとなる。

【００３７】各バージョン・ノードはオブジェクトがメ
モリ中にある場合には型無ポインタまたは非ポインタ識
別子を用いて、オブジェクトが永続的記憶部にある場合
には非ポインタ識別子によりアプリケーション・オブジ
ェクトを指す。線形バージョン操作のみの存在では、グ
ラフは線形構造に分解され、分岐バージョンの存在では
グラフは木となる。グラフ構造を発生するのはバージョ
ンをマージする能力である。２つのバージョン・ノード
がマージされると、例示のマージされたノード７８はマ
ージされるノード、すなわちノード８４，７６，９４の
バージョンとして挿入される。マージされたノードが指
すオブジェクトは初期化時にアプリケーションにより与
えられたマージ関数を呼出すことによりアプリケーショ
ンから得られる。

【００３８】ＶＡＭ２２はその命令により駆動される。
命令はクライアントのアプリケーションに埋込まれる。
埋込命令がアプリケーションから取出された場合、結果
の命令の組（以下の表１参照）はＶＡＭ２２のプログラ
ムを構成する。ＶＡＭ２２プログラムは以下の基本的制
御流れを有する。 １． 方針を選択することによりＶＡＭ２２を初期化す
る。 ２． 管理すべきオブジェクトの型とこの型に関連する
関数引数の名前をＶＡＭ２２に宣言する。 ３． バージョン操作をする各オブジェクトに対して、
「バージョン・グラフ作成（Ｃｒｅａｔｅ Ｖｅｒｓｉ
ｏｎ Ｇｒａｐｈ）」命令１００を実行する。 ４． 最初にバージョンを作成する（「バージョン・ノ
ード作成（ＣｒｅａｔｅＶｅｒｓｉｏｎ Ｎｏｄｅ）１
０２」ことによりオブジェクトのバージョンを作成し、
ついでバージョンを設置する（「バージョン設置（Ｉｎ
ｓｔａｌｌ Ｖｅｒｓｉｏｎ）１０４」。 ５． 段階３，４を繰返してＶＡＭ２２の内部状態を組
上げる。 ６． 命令セット中のどの関数でも任意の時点で呼出さ
れる。前記関数により要求されたサービスが実行不能の
場合には、失敗を支持する復帰コードがサービスを要求
したクライアントへ返される。 ７． アプリケーションが終了すると、ＶＡＭ２２の私
的状態は命令「外部への出力（Ｅｘｐｏｒｔ Ｔｏ）１
５２」を介して永続的記憶部へ収められる。 ８． アプリケーションが再始動すると、ＶＡＭ２２は
命令「外部からの入力（Ｉｍｐｏｒｔ Ｆｒｏｍ）１５
４」を介して最後の終了時の状態へされる。

【００３９】本発明の好適実施例ＣＭＶＭは粒状性と層
状組成に対する適切で柔軟な支持を有する。抽象、具象
及び動的構成は組成の高度に柔軟で調節可能で理解でき
る管理を提供する。構成抽象マシン（ＣＡＭ）２４は層
状または階層状の構造化オブジェクトに対する支持を与
える。構成とはオブジェクトの組成の指定である。例え
ば、本は章から、章は節から、節は段落から構成され、
又ソフトウェア・システムはモジュールから、モジュー
ルは関数から、関数は文から構成される。同様に、ＣＡ
Ｍ２４は、非循環である必要はない一般グラフにオブジ
ェクトの組成を支持する。ＣＡＭ２４が支持する構成は
「抽象」、「具象」又は「動的」である。抽象構成は一
般オブジェクト（３章を有する本）の組成であり、具象
構成（リリース）は部品の特定バージョンから作られ、
動的構成は解消されない結合を有する制約付構成であ
る。動的構成の例は「最も最近」と指定されたソフトウ
ェア・リリースである。

【００４０】ＣＡＭ２４の主データ構造はノードのグラ
フで、各ノードは「スーパーコンポーネント」と呼ばれ
る全体として概念的なオブジェクトまたはオブジェクト
の区別可能な部分、「サブコンポーネント」のどちらか
をモデル化する。図５はこのようなグラフの１つの図で
ある。全体構造３００は「構成グラフ」として参照され
る。項目３２０，３４０，３６０，３８０はグラフ３０
０の構成ノードである。ノードＡからノードＢへの矢印
は、構成ノードＢが構成ノードＡのサブコンポーネント
であることを示している。スーパーコンポーネント３２
０はグラフのルート・ノードである。サブコンポーネン
ト３４０，３６０，３８０はグラフのリーフ・ノードで
ある。３４０，３６０，３８０はグラフ３００のリーフ
・ノードであるが、これら自体も又分解可能なオブジェ
クトを表わしていることに注意するのが重要である。こ
れらは他の構成グラフのスーパーコンポーネント又はル
ート・ノードでもよい。

【００４１】ここで図６を見ると、図５のリーフ・ノー
ド３６０の構成グラフの図が示されている。グラフ４８
０は１つのスーパーコンポーネント３６０ａと２つのサ
ブコンポーネント４００，４２０を有する。項目３６０
（図５）と３６０ａ（図６）は同じオブジェクトを表わ
す。アプリケーションが以下の表２に挙げた命令セット
を介してＣＡＭ２４のサービスを要求すると、４８０の
ような構成グラフがＣＡＭ２４の私的状態２７で更新さ
れる。ＣＡＭ２４の私的状態２７はハッシュ表に構成さ
れたこれらの構成グラフの集合から主に構成される。私
的状態２７中の他のデータ構造はＶＡＭ２２に記述した
ものと全く同じ名前空間を管理する。これらの名前空間
は設計と実装は同一であるが、これらは各々のマシンＶ
ＡＭ２２とＣＡＭ２４で局所的かつ別々に定義されてい
ることに注意することが重要である。ＶＡＭ２２と同様
に、ＣＡＭ２４は「アンドゥー」操作を支持するためス
タック構造を保持する。リストや表のような各種容器構
造を用いてデータを効率的に管理する。これらの構造は
ＣＡＭ２４の動作には基本的ではなく、本明細書ではこ
れ以上説明はしない。

【００４２】オブジェクトがメモリ中にある場合には各
構成ノードは型無ポインタ又は非ポインタ識別子を用い
て、オブジェクトが永続的に記憶部にある場合は非ポイ
ンタ識別子を用いて、オブジェクトが永続的記憶部にあ
る場合は非ポインタ識別子によりアプリケーション・オ
ブジェクトを指す。

【００４３】ＣＡＭ２４により支持される完全機能性を
達成するため、ＣＡＭ２４がＶＡＭ２２とその動作を協
調する必要がある。これは、アプリケーションがするの
と同様にＶＡＭ２２のサービス要求を行うことにより、
又オブジェクトを参照するのに非ポインタ識別子を使用
する構成ノードの能力により行われる。この動作は「抽
象構成」、「具象構成」、「動的構成」を表現し管理す
るＣＡＭ２４の能力に最も普通に行われる。

【００４４】上述したように、ＶＡＭ２２は時間を通し
て又は他の特性を通して発展したオブジェクトを支持す
る。ＣＡＭ２４は他のオブジェクトのサブコンポーネン
トとしてオブジェクトを支持する。それ故、そのサブコ
ンポーネントが発展するオブジェクトを支持することを
必要としなければならない。「抽象構成」とは、そのサ
ブコンポーネントがバージョンを有するオブジェクトの
構成である。例えば、「トラック」はサブコンポーネン
トのオブジェクト、「トラック・エンジン」、「トラッ
ク・ボディ」、「トラック・フレーム」から構成され
る。しかしながら、「トラック・エンジン」には「トラ
ック・エンジン／３０００ｃｃ」と「トラック・エンジ
ン／４０００ｃｃ」の２つのバージョンがある。図７は
この例の図である。構成グラフ５００は「トラック」構
成を表している。バージョン・グラフ６００は「トラッ
ク・エンジン」のバージョンを表わす。「トラック」の
抽象構成では、「トラック・エンジン」に関連するデー
タ値は「トラック・エンジン」バージョン・グラフ６０
０である。両バージョン「トラック・エンジン／３００
０ｃｃ」６２０と「トラック・エンジン／４０００ｃ
ｃ」６４０が使用可能であるが、どちらも選択されてい
ない。「トラック」構成グラフ５００の抽象構成のため
に、ＣＡＭ２４の私的状態２７は「トラック・エンジ
ン」構成ノード４５０用に「トラック・エンジン」バー
ジョン・グラフ６００の名前を有する。この例では、
「トラック・エンジン」バージョン・グラフ６００名は
メモリ中の「トラック・エンジン」バージョン・グラフ
６００（過渡的）の非ポインタ識別子としての役割を果
たす。ＣＡＭ２４はＶＡＭ２２へバージョン・グラフ作
成１００又は現在のグラフを戻す１２０のサービス要求
を発行することにより「トラック・エンジン」バージョ
ン・グラフ６００の名前を得る。

【００４５】「具象構成」は、そのサブコンポーネント
が発展し、各サブコンポーネントの特定のバージョンが
選択されたオブジェクトの構成である。図７の例では、
「トラック」５００の１つの具象構成は、「トラック・
エンジン」を「トラック・エンジン」バージョン・グラ
フ６００の「トラック・エンジン／３０００ｃｃ」バー
ジョン・ノード６２０へ関連づけるデータ値を有する。
「トラック」構成グラフ５００の抽象構成に対して、Ｃ
ＡＭ２４の私的状態２７は「トラック・エンジン」構成
ノード４５０の値用に「トラック・エンジン」バージョ
ン・グラフ６００の名前と「トラック・エンジン／３０
００ｃｃ」バージョン・ノード６２０の名前を有する。
抽象例と同様に、「トラック・エンジン」バージョン・
グラフ６００名と「トラック・エンジン／３０００ｃ
ｃ」バージョン・ノード６２０名はメモリ中の特定の
「トラック・エンジン」バージョン・ノードの非ポイン
タ識別子としての役割を果たす。ＣＡＭ２４は、ＶＡＭ
２２へバージョン・グラフ作成１００、又は現在グラフ
を返す１２０、ルート・バージョンを返す１１６、又は
現在バージョンを返す１２２のサービス要求を出すこと
により「トラック・エンジン」バージョン・グラフ６０
０の名前と「トラック・エンジン／３０００ｃｃ」バー
ジョン・ノード６２０の名前を得る。

【００４６】「動的構成」は、そのサブコンポーネント
が発展し、各サブコンポーネントの特定バージョンの選
択が、動的構成のサービス要求が行われた時のＣＡＭ２
４とＶＡＭ２２の私的状態２７を基にしている構成であ
る。図７の例では、アプリケーションは、「最大のエン
ジン」を含むように「トラック」５００の構成を発生す
るよう要求する。ＣＡＭ２４は、「トラック・エンジ
ン」バージョン・グラフ６００を与えて、そのバージョ
ン・ノードの各々を検査し、どのバージョン・ノードが
「最大のエンジン」を表わしているかを決定するアプリ
ケーションにより定められたサーチ関数を利用すること
により前記の要求を処理可能である。ＣＡＭはこのバー
ジョン・ノードを「トラック」構成グラフ５００の「ト
ラック・エンジン」構成ノード５４０へ関連づける。な
ぜこれが「動的構成」であるかの理由は、現在の所「最
大のエンジン」は「トラック・エンジン／４０００ｃ
ｃ」バージョン・ノード６４０であるが、他のバージョ
ンの「トラック・エンジン／３０００ｃｃ」バージョン
・ノード６２０は「トラック・エンジン／４０００ｃ
ｃ」バージョン・ノード６４０の兄弟として「トラック
・エンジン／４５００ｃｃ」を作成できる。このような
バージョン・ノードの作成後、ＶＡＭ２２の私的状態２
８の変化により「トラック」構成グラフ５００の「トラ
ック・エンジン」構成ノード５４０へ値が関係づけられ
たため、「最大のエンジン」を基にした「トラック」５
００の動的構成に対するサービス要求は「トラック・エ
ンジン／４５００ｃｃ」を生成する。どちらの場合で
も、「トラック」構成グラフ５００の動的構成に対して
は、ＣＡＭ２４の私的状態２７は「トラック・エンジ
ン」構成ノード４５０の値に対して「トラック・エンジ
ン」バージョン・グラフ６００の名前とアプリケーショ
ン定義の関数により選択された「トラック・エンジン」
バージョン・ノードの名前を有する。抽象及び具象例と
同じく、「トラック・エンジン」バージョン・グラフ６
００名と選択した「トラック・エンジン」バージョン・
ノードの名前はメモリ中の特定の「トラック・エンジ
ン」バージョン・ノードの非ポインタ識別子としての役
割を果たす。ＣＡＭ２４は現在のグラフを戻す１２０の
サービス要求を発行することにより「トラック・エンジ
ン」バージョン・グラフ６００の名前を得る。選択すべ
き「トラック・エンジン」バージョン・ノードの名前を
決定するため、ＶＡＭ２２へのバージョン・グラフを戻
す１０２、ルート・バージョンを戻す１１６、現在バー
ジョンを戻す１２２、属性によりバージョンを見出す１
３２のサービス要求がアプリケーション定義のサーチ関
数での使用に利用できる。ＣＡＭ２４のサービスのこれ
以上の詳細は後述するＣＡＭ２４の命令セットの説明に
現れる。

【００４７】ＣＡＭ２４はその命令により駆動される。
命令はクライアント・アプリケーションに埋込まれる。
埋込命令がアプリケーションから取出された場合、生成
された命令の組がＣＡＭ２４のプログラムを構成する。
ＣＡＭ２４プログラムは以下の基本制御流れを有する。 １． 方針を選択することによりＣＡＭ２４を初期化す
る。 ２． 管理すべきオブジェクトの型とこの型に関連づけ
られる関数引数の名前をＣＡＭ２４に宣言する。 ３． 構成すべき各オブジェクトに対して、「構成ノー
ドの作成」命令２００を実行する。これはこれは、最初
に構成ノードを作成することにより、ＣＡＭ２４へオブ
ジェクトの構成グラフを初期化することを告げる。 ４． 各サブコンポーネントに対して段階３を続けるこ
とによりオブジェクトのサブコンポーネントを設定し、
ルート構成ノードのリーフ・ノードとしてサブコンポー
ネントを設置する（「構成ノードの設置）２０２」）。 ５． 段階３、４を繰返してＣＡＭ２４の内部状態を組
立てる。 ６． 命令セットの関数を任意の時点で呼出す。前記関
数により要求されたサービスが実行不能の時、失敗を示
す復帰コードをサービスを要求したクライアントへ返
す。 ７． アプリケーションが終了すると、ＣＡＭ２４の私
的状態を「外部への出力２２０命令を介して永続的記憶
部へ収める。 ８． アプリケーションが再始動すると、ＣＡＭ２４は
命令「外部からの入力（２２２を介して最後の終了時の
状態へされる。

【００４８】ＣＭＶＭ抽象マシンはアプリケーション・
オブジェクトに関する型又は操作の知識は何もない。ア
プリケーション・セマンテックスへのアクセスなしで変
更を管理できる事実は、一般的特性を保持するための鍵
となる要因であり、従って本発明の価値でもある。アプ
リケーション固有の情報はマージ関数のような関数によ
り本発明の外側で管理される。抽象マシンを初期化する
一部として、オブジェクトの型名と共にその型に関係す
る関数名も又マシンへ宣言される（これらの名前は単に
マシンに対する文字列であり、型または関数に名前付す
る以外はこれには何の意味もないことに注意すべきであ
る。）例えば、「セル」は型で、これは「マージセル
（Ｍｅｒｇｅ Ｃｅｌｌ）」と呼ばれる関連マージ関数
を有することを宣言は言っている。２つのバージョン
「セル１」「セル２」をマージする時、ＶＡＭ２２は、
２つのオブジェクトを分野固有の方法でマージし、マー
ジしたオブジェクトへポインタを返す関数「マージセ
ル」を呼出す。このオブジェクトは「セル１」と「セル
２」をモデル化した２つのノードのマージであるノード
により指される。異なるバージョンを得る、オブジェク
トに関する情報を印刷する等も同じ技術に従う。これ以
上の詳細は以下で与えるＶＡＭ２２とＣＡＭ２４の命令
セットの説明に現われる。

【００４９】表１と表２に与えたＶＡＭ２２とＣＡＭ２
４の命令セットは関数の集合である。関数は整数型、文
字列型、ブール型、又は型無変数である引数を取る。こ
のように引数型を制限することにより、ＣＭＶＭはアプ
リケーションに属する型付データを処理する必要はなく
なる。又、多くのプログラミング言語はこのような原始
データ型を支持しており、従って多くのプログラミング
言語で書かれたアプリケーションが言語間呼出を介して
ＣＭＶＭを利用することを可能とする。

【００５０】ＶＡＭ２２は現在グラフと呼ばれるコンテ
キストを有し、各グラフは現在ノードと呼ばれるコンテ
キストを有する。命令セット中の多くの関数は文字列で
ある。「Ｇｎａｍｅ」と呼ばれる引数を取る。これがオ
プションで指定されていない場合、ＶＡＭ２２は現在グ
ラフとしてしられているグラフを用いる。同様に、オプ
ションのバージョン名がデフォールトとされた場合、Ｖ
ＡＭ２２は現在ノードを用いる。現在ノードと現在グラ
フは各種ＶＡＭ操作によりリセットされる。これは又後
述する適切な関数によってもリセットされる。さらに、
以下で与える関数を用いることにより現在ノードと現在
グラフの現在の設定を問合わせることが可能である。

【００５１】ＶＡＭ２２インターフェース関数が集合デ
ータ構造（リスト又はアレイ）を返す時、構造体の項目
は時番列で並べられる。

【表１】

【００５２】表１はＶＡＭ２２のインターフェース関数
１００−１５４をその関数名、所要引数１６２、オプシ
ョン引数１６４、返り値１６６と共に列挙してある。こ
れらの関数の簡単な説明は以下に与えられている。これ
らの関数はＶＡＭ２２の私的状態を更新するか、又はマ
シンの私的状態に関する何らかの情報を返す。命令１０
０−１１４，１５０はＶＡＭ２２の私的状態を更新す
る。命令１１６−１４８はクライアントのアプリケーシ
ョンへＶＡＭ２２の私的状態に関する情報を返す。命令
１５２，１５４はＶＡＭ２２の内部状態の過渡的及び永
続的表現間を変換する特殊命令である。

【００５３】ポインタ値（ｃｈａｒ＊，ｃｈａｒ＊＊）
がインターフェース関数により返される場合、アプリケ
ーションはポインタがＮＵＬＬでないことを検査すべき
である。ＮＵＬＬ値は、ＶＡＭ２２が要求されたサービ
スを実行できなかったことを意味する返りコードであ
る。ブール値（真、偽）がインターフェース関数により
返される場合、アプリケーションは値が偽でないことを
検査すべきである。偽値はＶＡＭ２２が要求されたサー
ビスを実行できなかったことを意味する返りコードであ
る。バージョン・グラフの作成（Ｃｒｅａｔｅ Ｖｅｒ
ｓｉｏｎ Ｇｒａｐｈ）１００はバージョン・グラフを
作成し、これを返す。これはオブジェクトのバージョン
操作を開始するためバージョン抽象マシンへ行われる最
初の呼出である。バージョン・ノードの作成（Ｃｒｅａ
ｔｅ Ｖｅｒｓｉｏｎ Ｎｏｄｅ）１０２はバージョン
・ノードを作成し、これを返す。バージョン設置（Ｉｎ
ｓｔａｌｌ Ｖｅｒｓｉｏｎ）１０４は既存のバージョ
ン・グラフへバージョン・ノードを設置する。バージョ
ン削除（Ｄｅｌｅｔｅ Ｖｅｒｓｉｏｎ）１０６は既存
のバージョン・ノードを削除する。バージョン・マージ
（Ｍｅｒｇｅ Ｖｅｒｓｉｏｎ）１０８は２つのバージ
ョン・ノードをマージする。ノードがアドレスするオブ
ジェクトのマージはアプリケーションにより行われる。
マージしたノードは、マージされた２つのノードのバー
ジョンとして設置される。現在バージョンのセット（Ｓ
ｅｔ Ｃｕｒｒｅｎｔ Ｖｅｒｓｉｏｎ）１１０は現在
バージョンをセットする。バージョン属性のセット（Ｓ
ｅｔ Ｖｅｒｓｉｏｎ Ａｔｔｒｉｂｕｔｅ）１１２は
標準的にはユーザ指定の時刻スタンプであるバージョン
の属性をセットする。現在グラフのセット（ｓｅｔ Ｃ
ｕｒｒｅｎｔ Ｇｒａｐｈ）１１４は現在グラフをセッ
トする。ルート・バージョンを返す（Ｒｅｔｕｒｎ Ｒ
ｏｏｔ Ｖｅｒｓｉｏｎ）１１６はルート・バージョン
を返す。値付バージョン（Ｖｅｒｓｉｏｎｓ Ｗｉｔｈ
ｖａｌｕｅ）１１８は特定値を有する全てのバージョ
ンを返す。現在グラフを返す（Ｒｅｔｕｒｎ ｃｕｒｒ
ｅｎｔ Ｇｒａｐｈ）１２０は現在グラフを返す。現在
バージョンを返す（Ｒｅｔｕｒｎ Ｃｕｒｒｅｎｔ Ｖ
ｅｒｓｉｏｎ）１２２は現在バージョンを返す。ノード
と値の記述（Ｄｅｓｃｒｉｂｅ Ｎｏｄｅ Ａｎｄ Ｖ
ａｌｕｅ）１２４はユーザにより指定された何らかの形
式でバージョン・ノードとその値を記述する。バージョ
ン・グラフの記述（Ｄｅｓｃｒｉｂｅ Ｖｅｒｓｉｏｎ
Ｇｒａｐｈ）１２６は基本的には数学グラフとしてバ
ージョン・グラフを記述する。バージョン・ノードの記
述（Ｄｅｓｃｒｉｂｅ Ｖｅｒｓｉｏｎ Ｎｏｄｅ）１
２８はバージョン・ノードの値を示すことなく親子、兄
弟をリストすることによりバージョン・ノードを記述す
る。全バージョン（Ａｌｌ Ｙｏｕｒ Ｖｅｒｓｉｏｎ
ｓ）１３０はあるノードの全バージョンの線形リストを
与える。属性によりバージョンを見出す（Ｆｉｎｄ Ｖ
ｅｒｓｉｏｎｓ Ｂｙ Ａｔｔｒｉｂｕｔｅ）１３２は
ある属性に対して一定値を有する全てのバージョン・ノ
ードを見出す。この関数は標準的には特定の時刻スタン
プの全バージョンを見出すために使用される。バージョ
ン時刻（Ｖｅｒｓｉｏｎ Ｔｉｍｅ）１３４はユーザが
このノードに関係づけた時刻を存在する場合に返す。ユ
ーザ指定の時刻属性がない場合、システム時刻が返され
る。子バージョンを返す（Ｒｅｔｕｒｎ Ｃｈｉｌｄ
Ｖｅｒｓｉｏｎｓ）１３６はあるノードの全ての直下の
子を返す。親バージョンを返す（Ｒｅｔｕｒｎ Ｐａｒ
ｅｎｔ Ｖｅｒｓｉｏｎｓ）１３８はあるノードの全て
の直上の親を返す。１次バージョンを返す（Ｒｅｔｕｒ
ｎ Ｐｒｉｍａｒｙ Ｖｅｒｓｉｏｎｓ）１４０はある
ノードの１次バージョンを返す。バージョン存在（Ｔｈ
ｅｒｅ Ｅｘｉｓｔｓ Ｖｅｒｓｉｏｎ）１４２は適切
な真偽を返す。全てのバージョン・グラフをリスト（Ｌ
ｉｓｔ Ａｌｌ Ｖｅｒｓｉｏｎ Ｇｒａｐｈ）１４４
はＶＡＭ２２に知られている全てのバージョン・グラフ
のリストを返す。バージョン管理されている各オブジェ
クトに１つのグラフがあることに注意されたい。バージ
ョン・グラフのブラウズ（Ｂｒｏｗｓｅ Ｖｅｒｓｉｏ
ｎ Ｇｒａｐｈ）１４６は、本発明を実装するために用
いた言語にグラフ・ブラウズ機能が利用可能であると仮
定して、ＶＡＭ２２に知られているバージョン・グラフ
をブラウザを用いてブラウズする。ブラウザがない場
合、グラフのテキスト表示が与えられる。バージョン・
オブジェクトを返す（Ｒｅｔｕｒｎ ｖｅｒｓｉｏｎ
Ｏｂｊｅｃｔ）１４８はバージョン・ノードの値を返
す。前回の取消し（Ｕｎｄｏ Ｌａｓｔ）１５０は前回
操作を取消す。外部への出力（Ｅｘｐｏｒｔ Ｔｏ）１
５２は例えばアレイのようなディスクへの書出しに適す
るマシン又はグラフの線形化バージョンを書出す。外部
からの入力（Ｉｍｐｏｒｔ Ｆｒｏｍ）１５４は外部へ
の出力１５２の反対である。

【００５４】以下はＣＡＭ２４の命令セットである。以
下の関数の多くは文字列である「ノード」、「ルート・
ノード」、「親ノード」と呼ばれる引数を取る。インタ
ーフェース関数が集合データ構造（リスト又はアレイ）
を返す時、構造体中の項目は挿入されたものと同じ順序
で並べられている。

【表２】

【００５５】表２はＣＡＭ２４のインターフェース関数
で、その関数名２３０、所要引数２３２、オプション引
数２３４及び返り値２３６をあげてある。関数の簡単な
説明は以下に与えてある。ＶＡＭ２２の命令セットと同
じく、ポインタ値（ｃｈａｒ＊，ｃｈａｒ＊＊）を返す
関数は返り値を使う前にＮＵＬＬを検査すべきである。
真又は偽を返す関数は真（成功）又は偽（失敗）の検査
をすべきである。構成ノードの作成（Ｃｒｅａｔｅ Ｃ
ｏｎｆｉｇｕｒａｔｉｏｎ Ｎｏｄｅ）２００は構成ノ
ードを作成し、これを返す。構成ノードの設置（Ｉｎｓ
ｔａｌｌ Ｃｏｎｆｉｇｕｒａｔｉｏｎ Ｎｏｄｅ）２
０２はスーパーコンポーネント構成ノードのサブコンポ
ーネントとして構成ノードの組を設置する。構成ノード
の削除（Ｄｅｌａｔｅ Ｃｏｎｆｉｇｕｒａｔｉｏｎ
Ｎｏｄｅ）２０４は、指定の構成ノードをルートとする
構成ノードをそのスーパーコンポーネント構成ノードか
ら削除する。前回の取消し（Ｕｎｄｏ Ｌａｓｔ Ｏｐ
ｅｒａｔｉｏｎ）２０６は前回操作を取消す。構成ノー
ドの子を返す（Ｒｅｔｕｒｎ Ｃｈｉｌｄｒｅｎ ｏｆ
Ｃｏｎｆｉｇｕｒａｔｉｏｎ Ｎｏｄｅ）２０８は現
在の構成ノードのサブコンポーネントである構成ノード
の現在の組を返す。構成ノードの親を返す（Ｒｅｔｕｒ
ｎ Ｐａｒｅｎｔｓ ｏｆ Ｃｏｎｆｉｇｕｒａｔｉｏ
ｎ Ｎｏｄｅ）２１０は現在の構成ノードのスーパーコ
ンポーネントである構成ノードの現在の組を返す。パラ
メータ化構成グラフを返す（Ｒｅｔｕｒｎ Ｐａｒａｍ
ｅｔｅｒｉｚｅｄＣｏｎｆｉｇｕｒａｔｉｏｎ Ｇｒａ
ｐｈ）２１２は現在の構成ノードと同じ構成グラフをル
ートとしているが、そのサブコンポーネント構成ノード
は指定関数により決定される新たな構成ノードを返す。
構成グラフを記述（Ｄｅｓｃｒｉｂｅ Ｃｏｎｆｉｇｕ
ｒａｔｉｏｎ Ｇｒａｐｈ）２１４は現在の構成ノード
をルートとする構成グラフを記述する。記述により構成
グラフを見出す（Ｆｉｎｄ Ｃｏｎｆｉｇｕｒａｔｉｏ
ｎ Ｇｒａｐｈ ｂｙ Ｄｅｓｃｒｉｐｔｉｏｎ）２１
６はその記述が特定の記述とマッチする構成グラフをル
ートとする全ての構成ノードを見出す。構成グラフのブ
ラウズ（Ｂｒｏｗｓｅ Ｃｏｎｆｉｇｕｒａｔｉｏｎ
Ｇｒａｐｈ）２１８は、本発明を実装するために用いた
言語にグラフ・ブラウズ機能が利用可能であると仮定し
てＣＡＭ２４に知られている構成グラフをブラウザを用
いてブラウズする。ブラウザがない場合、グラフのテキ
スト記述が与えられる。外部への出力（Ｅｘｐｏｒｔ
Ｔｏ）２２０は例えばアレイのようなディスクへの書出
に適したマシン又はグラフの線形化バージョンを書出
す。外部からの入力（Ｉｍｐｏｒｔ Ｆｒｏｍ）２２２
は外部への出力２２０の反対である。

【００５６】ＶＡＭ２２とＣＡＭ２４の全てのアプリケ
ーション実体は名前付され、インターフェース関数はこ
れらの名前を用いて前記実体を引用する。ＶＡＭ２２の
グラフはグラフの名前をキーとするハッシュ表に集めら
れる。

【００５７】アプリケーションがいかに変更を管理する
かに関するユーザ選択の異なる方針はＣＭＶＭ設定可能
である。ＣＭＶＭはこのような方針を抽象化として扱
い、ＣＭＶＭがインターフェースする層として設計す
る。これらの方針は認定、監査跡、ベースライン操作、
オブジェクトの変動性、バージョン数、粒状性の支持の
ような項目と関係する。テフォールトの方針の組が提供
されているため、ＣＭＶＭは方針宣言が指定されない時
も使用可能である。別の方針は、アプリケーションを初
期化するコード内部から標準的には起動されるＩＭＰＬ
ＥＭＥＮＴマクロを用いて宣言される。アプリケーショ
ン・データへインターフェースするためＣＭＶＭが使用
する関数の名前もこの初期化過程でＣＭＶＭへ渡され
る。このような渡される関数の例は、２つのアプリケー
ション・オブジェクトを取り、２つのオブジェクトの
「マージ」であるアプリケーション・オブジェクトを返
すマージ関数である。明らかに、「マージ」は分野固有
の情報を必要とし、アプリケーションの作業空間で実行
する。

【００５８】クライアント・アプリケーションはアプリ
ケーション・ソフトウェアにＶＡＭ２２とＣＡＭ２４へ
の関数呼出を埋込むことによりＣＭＶＭ２０のサービス
を得る。本発明の好適実施例では、ＣＭＶＭ２０はソフ
トウェアの２つのライブラリと各々ＶＡＭ２２とＣＡＭ
２４に対応する２つのＣヘッダ・ファイルから構成され
る。アプリケーションはアプリケーション・ソフトウェ
アへヘッダ・ファイルを含ませる。ライブラリはアプリ
ケーションのメイクファイル中のライブラリ・サーチ・
パスで指定される。これはアプリケーション・ロード・
モジュールへのＣＭＶＭのリンク組込を生じる。アプリ
ケーションがＶＡＭ２２のみを使用することも可能で、
この場合アプリケーション・ロード・モジュールの組立
にはＶＡＭ２２のヘッダ・ファイルとＶＡＭ２２のライ
ブラリのみが関係する。ＣＡＭ２４は動的構成を管理す
るためにＶＡＭ２２を用いる、それ故、ＣＡＭ２４ヘッ
ダ・ファイルとライブラリが指定された場合、ＶＡＭ２
２ヘッダ・ファイルは自動的に含まれ、ＶＡＭ２２ライ
ブラリは自動的にリンクされる。

【００５９】本発明の好適実施例では、ＣＭＶＭとＣＭ
ＶＭを用いたアプリケーションは同じアドレス空間で動
作する。しかしながら、ＣＭＶＭインターフェースは原
始データ型引数の関数から構成されているため、動作環
境がＲＰＣ（例えばユニックス下のサン・マイクロシス
テム・ワークステーション）を支持している場合サービ
ス要求は遠隔手続呼出も可能である。ＣＭＶＭ２０が遠
隔で動作している時、ＶＡＭ２２とＣＡＭ２４のノード
はアプリケーション実体をアクセスし返すためにオブジ
ェクト識別子を用いる。

【００６０】本発明の特定の実施例を図示し説明してき
たが、当業者には各種の修正や別の実施例が生じうる。
従って、本発明は添附の特許請求の範囲に関してのみ限
定されるべきものである。

【００６１】注意 １９９０年テキサス・インストラメント社著作権。本特
許文書の開示の一部は著作権保護を受ける材料を含んで
いる。著作権者は特許商標局特許ファイル又は記録に現
れる限り特許開示のだれによる複写再生に反対しない
が、それ以外の全ての著作権はこれを保持する。

【００６２】以上の説明に関して以下の項を開示する。 （１） 変更がいかに管理されているかはユーザには透
明なままでアプリケーションにおける変更を管理する方
法において、関数パラメータとして分野固有の情報と共
に、インタフェースを介して抽象マシンへオブジェクト
型情報を入力する段階と、前記抽象マシン内でユーザ選
定の方針を初期化する段階と、前記サービスの要求の結
果として前記抽象マシンの私的状態に変更管理データ構
造を記憶する段階であって、前記データ構造は一般的な
アプリケーション非依存の方法で管理される前記記憶段
階と、少なくとも１つの名前を含む名前空間を管理する
段階と、前記少なくとも１つの名前のみを用いて前記ア
プリケーションと通信する段階と、前記サービス要求に
応答して前記の記憶した変更管理データを更新する段階
と、前記名前と共に型無ポインタ構造を用いてアプリケ
ーション情報を返す段階と、を含むアプリケーションに
おける変更を管理する方法。

【００６３】（２） 第１項記載の方法において、前記
変更管理データ構造を記憶する段階は、オブジェクトの
変更を管理するため最初の要求が出された時に変更管理
データ構造を作成する段階と、前記抽象マシンの前記私
的状態に前記作成した変更管理データ構造を記憶する段
階と、をさらに含むアプリケーションにおける変更を管
理する方法。

【００６４】（３） 第１項記載の方法において、名前
空間を管理する前記段階は、サービスの要求は引数とし
て原始データ・オブジェクトのみを必要とすることを保
証する段階を含むアプリケーションにおける変更を管理
する方法。

【００６５】（４） 第１項記載の方法において、情報
を返す前記段階は引数として原始データオブジェクトの
みを使用することを必要とするアプリケーションにおけ
る変更を管理する方法。

【００６６】（５） 第１項記載の方法において、前記
通信段階の後、前記更新段階の前に、前記抽象マシンが
前記アプリケーションからさらに情報を必要とする場
合、前記抽象マシンの状態内部で所要のパラメータ関数
を、あるならば検査する段階と、前記要求されたサービ
スに応じて前記アプリケーションの作業空間内で実行さ
せるため前記少なくとも１つの名前を担持する少なくと
も１つの関数を前記アプリケーションから前記抽象マシ
ンにより要求する段階と、前記分野固有の情報を得る段
階と、をさらに含むアプリケーションにおける変更を管
理する方法。

【００６７】（６） 第１項記載の方法において、前記
入力段階は、方針宣言を入力する段階を更に含み、前記
方針宣言は前記抽象マシンの行動をさらに調節するアプ
リケーションの変更を管理する方法。

【００６８】（７） アプリケーションから変更管理を
分離するための変更管理のシステムにおいて、第１及び
第２の命令セットから構成されるアプリケーション・イ
ンターフェースと、オブジェクトの発展を管理するバー
ジョン抽象マシンであって、前記バージョン抽象マシン
は前記第１の命令セットを用いることによりアプリケー
ションと相互作用する前記抽象マシンと、層状又は階層
構造のオブジェクトと共に構成を指定するための支持を
与える構成抽象マシンであって、前記構成抽象マシンは
前記第２命令セットを用いることによりアプリケーショ
ンと相互作用する前記抽象マシンと、を含む変更管理シ
ステム。

【００６９】（８） 第７項記載のシステムにおいて、
前記バージョン抽象マシンが前記構成抽象マシンと相互
作用したい場合、前記バージョン抽象マシンは前記第２
命令セットを用いてサービスとして前記構成抽象マシン
を呼出し、一方前記構成抽象マシンが前記バージョン抽
象マシンと相互作用したい場合、前記構成抽象マシンは
前記第１命令セットを用いてサービスとして前記バージ
ョン抽象マシンを呼出す変更管理のシステム。

【００７０】（９） 第７項記載のシステムにおいて、
前記第１及び第２の命令セットは関数の集合である変更
を管理するシステム。

【００７１】（１０） 第９項記載のシステムにおい
て、前記関数の集合は整数型の引数を取る変更を管理す
るシステム。

【００７２】（１１） 第９項記載のシステムにおい
て、前記関数の集合は文字列型の引数を取る変更を管理
するシステム。

【００７３】（１２） 第９項記載のシステムにおい
て、前記関数の集合はブール型の引数を取る変更を管理
するシステム。

【００７４】（１３） 第９項記載のシステムにおい
て、前記関数の集合は型無ポインタ型の引数を取る変更
を管理するシステム。

【００７５】（１４） 全ての型の永続的かつ過渡的オ
ブジェクトの変更管理を提供するシステムにおいて、イ
ンターフェースを介してアプリケーション・プログラム
からオブジェクト型情報と共に関数パラメータとして入
力分野固有情報を受取り、抽象マシン内のユーザ選択の
方針を初期化する抽象マシンと、前記抽象マシンの私的
状態中にあって、要求したサービスから生じる変更管理
データ構造を記憶するデータ構造記憶装置であって、前
記データ構造は一般にアプリケーション非依存の方法で
管理される前記記憶装置と、前記抽象マシン内にある名
前空間マネジャであって、前記名前空間は前記アプリケ
ーション・プログラムと通信するために使用される少な
くとも１つの名前を含む前記名前空間マネジャと、識別
構造と共に前記少なくとも１つの名前を用いて前記アプ
リケーション・プログラムへ情報を返す装置と、前記ア
プリケーション・プログラムにより前記抽象マシンのサ
ービスを要求する前記インターフェース内のサービス・
リクエスタと、を含む変更管理を提供するシステム。

【００７６】（１５） 第１４項記載のシステムにおい
て、前記データ構造記憶装置は要求したサービスに応答
して前記記憶した変更管理データ構造を更新するデータ
構造更新器を含む、永続的および過渡的オブジェクトの
変更管理を提供するシステム。

【００７７】（１６） 第１４項記載のシステムにおい
て、前記識別構造は前記返り情報が過渡的オブジェクト
を含む時は型無ポインタである、永続的及び過渡的オブ
ジェクトの変更管理を提供するシステム。

【００７８】（１７） 第１４項記載のシステムにおい
て、前記返り情報が過渡的オブジェクトを含む時前記識
別情報は非ポインタ識別子である、永続的及び過渡的オ
ブジェクトの変更管理を提供するシステム。

【００７９】（１８） 第１４項記載のシステムにおい
て、前記返り情報が永続的オブジェクトを含む時前記識
別情報は非ポインタ識別子である、永続的及び過渡的オ
ブジェクトの変更管理を提供するシステム。

【００８０】（１９） ソフトウェア・システムとアプ
リケーションの変更を管理するシステム２０と方法は、
分野に独立で、押しつけでなく、オブジェクト指向の方
法で過渡的かつ永続的両オブジェクトの変更を管理す
る。システム２０と方法は、アプリケーションに見られ
るインターフェース関数２５，２６の組と、前記アプリ
ケーションから隠されている内部又は私的状態２７，２
８から構成される２つの抽象マシン２２，２４の組合せ
として設計実装される。アプリケーションはインターフ
ェース関数２５，２６を用いてこの変更管理システム２
０と方法のサービスを得る。システム２０と方法の内部
状態はアプリケーションの外側にあるため、アプリケー
ション・データ構造とインターフェースを変更する又は
追加する必要なしにサービスとして変更管理が提供され
る。

【図面の簡単な説明】

【図１】アプリケーション開発者から見た本発明のアー
キテクチャのブロック線図。

【図２】変更管理データ構造がアプリケーション・デー
タ構造に束縛されている変更管理システムの従来のアー
キテクチャを示すブロック線図。

【図３】変更管理に対する従来のアプローチを本発明の
それと対比したブロック線図。

【図４】本発明の望ましい実施例のバージョン抽象マシ
ンの主要内部データ構造のブロック線図。

【図５】本発明の望ましい実施例の構成抽象マシンの主
要内部データ構造のブロック線図。

【図６】第５図に見られるノードの構成グラフを示す構
成抽象マシンの主要内部データ構造のブロック線図。

【図７】例示の構成グラフと関連するバージョン・グラ
フのブロック線図。

【符号の説明】

２０ 変更管理仮想マシン，ＣＭＶＭ ２２ バージョン抽象マシン，ＶＡＭ ２４ 構成抽象マシン，ＣＡＭ ２５，２６ インターフェース ２７，２８ マシン状態 ３０ アプリケーション実体 ３２ アプリケーション・データ ３４ 変更管理データ ５０ バージョン構造 ７０ バージョン・グラフ ７２−９４ ノード ３００ 構成グラフ ３２０，３４０，３６０，３８０ 構成ノード １００−１５４ 命令セット ２００−２２２ 命令セット

─────────────────────────────────────────────────────

【手続補正書】

【提出日】平成５年６月１８日

【手続補正１】

【補正対象書類名】図面

【補正対象項目名】図２

【補正方法】変更

【補正内容】

【図２】

【手続補正２】

【補正対象書類名】図面

【補正対象項目名】図４

【補正方法】変更

【補正内容】

【図４】

【手続補正３】

【補正対象書類名】図面

【補正対象項目名】図５

【補正方法】変更

【補正内容】

【図５】

【手続補正４】

【補正対象書類名】図面

【補正対象項目名】図６

【補正方法】変更

【補正内容】

【図６】

【手続補正５】

【補正対象書類名】図面

【補正対象項目名】図７

【補正方法】変更

【補正内容】

【図７】

───────────────────────────────────────────────────── フロントページの続き (72)発明者 クレイグ ダブリュ．トンプソン アメリカ合衆国テキサス州プラノ，ディー プ バレー トレイル 2725 (72)発明者 ジョン チュング − リン チェン アメリカ合衆国テキサス州プラノ，ビッカ ーズ ドライブ 2229

Claims (3)

【特許請求の範囲】
1. 【請求項１】 変更がいかに管理されているかはユーザ
   には透明なままでアプリケーションにおける変更を管理
   する方法において、 関数パラメータとして分野固有の情報と共に、インター
   フェースを介して抽象マシンへオブジェクト型情報を入
   力する段階と、 前記抽象マシン内でユーザ選定の方針を初期化する段階
   と、 前記サービスの要求の結果として前記抽象マシンの私的
   状態に変更管理データ構造を記憶する段階であって、前
   記データ構造は一般的なアプリケーション非依存の方法
   で管理される前記記憶段階と、 少なくとも１つの名前を含む名前空間を管理する段階
   と、 前記少なくとも１つの名前のみを用いて前記アプリケー
   ションと通信する段階と、 前記サービス要求に応答して前記の記憶した変更管理デ
   ータを更新する段階と、 前記名前と共に型無ポインタ構造を用いてアプリケーシ
   ョンへ情報を返す段階と、を含むアプリケーションにお
   ける変更を管理する方法。
2. 【請求項２】 アプリケーションから変更管理を分離す
   るための変更管理のシステムにおいて、 第１及び第２の命令セットから構成されるアプリケーシ
   ョン・インターフェースと、 オブジェクトの発展を管理するバージョン抽象マシンで
   あって、前記バージョン抽象マシンは前記第１の命令セ
   ットを用いることによりアプリケーションと相互作用す
   る前記抽象マシンと、 層状または階層構造のオブジェクトと共に構成を指定す
   るための支持を与える構成抽象マシンであって、前記構
   成抽象マシンは前記第２命令セットを用いることにより
   アプリケーションと相互作用する前記抽象マシンと、を
   含む変更管理のシステム。
3. 【請求項３】 全ての型の永続的かつ過渡的オブジェク
   トの変更管理を提供するシステムにおいて、 インターフェースを介してアプリケーション・プログラ
   ムからオブジェクト型情報と共に関数パラメータとして
   入力分野固有情報を受取り、抽象マシン内のユーザ選択
   の方針を初期化する抽象マシンと、 前記抽象マシンの私的状態中にあって、要求したサービ
   スから生じる変更管理データ構造を記憶するデータ記憶
   装置であって、前記データ構造は一般にアプリケーショ
   ン非依存の方法で管理される前記記憶装置と、 前記抽象マシン内にある名前空間マネジャであって、前
   記名前空間は前記アプリケーション・プログラムと通信
   するために使用される少なくとも１つの名前を含む前記
   名前空間マネジャと、 識別構造と共に前記少なくとも１つの名前を用いて前記
   アプリケーション・プログラムへ情報を返す装置と、 前記アプリケーション・プログラムにより前記抽象マシ
   ンのサービスを要求する前記インターフェース内のサー
   ビス・リクエスタと、を含む変更管理を提供するシステ
   ム。