JP2597460B2 - 複合データ構造を生成及び記憶する方法及び装置 - Google Patents

Description

【発明の詳細な説明】

【０００１】

【産業上の利用分野】本発明はデータ処理分野に関し、
特にオブジェクト指向のプログラミング環境に関する。

【０００２】

【従来の技術】１９４８年のＥＤＶＡＣコンピュータ・
システムの開発は、しばしばコンピュータ時代の幕開け
と呼ばれている。その時以来、コンピュータ・システム
はアメリカン・ライフ・スタイルのあらゆる分野に浸透
してきた。こうした普及の１つの理由は、コンピュータ
・システムが様々なタスクを効率的に実行する能力を有
することにある。これらのタスクを実行するためにコン
ピュータ・システムにより使用される機構は、コンピュ
ータ・プログラムと呼ばれる。

【０００３】コンピュータ・システム自身と同様に、コ
ンピュータ・プログラムの開発も長年に渡り発展してき
た。ＥＤＶＡＣシステムは、"１アドレス"コンピュータ
・プログラミング言語と称される言語を使用した。この
言語は、最も初歩的なコンピュータ・プログラムだけを
考慮した。１９５０年代初期、科学者達は人間に合理的
に理解できるシンボリック命令を、コンピュータ・シス
テムにより理解される形式に変換する機構を開発した。
各コンピュータ・システムは、特定のグループのこれら
の命令を扱うように設計された。これらのグループの命
令は、命令セットと称される。

【０００４】コンピュータ・プログラム開発の次のステ
ップは、コンピュータ・プログラミング言語の概念であ
った。コンピュータ・プログラミング言語は、シンボリ
ック命令セットよりも、より理解しやすいものであっ
た。コンピュータ・プログラムは様々なコンピュータ・
プログラミング言語を用いて作成される。一度作成され
ると、コンピュータ・プログラムは特定のコンピュータ
・システムの命令セットの一部である命令にコンパイル
される。FORTRAN は通常、特定の命令セットと無関係に
作成されるコンピュータ・プログラムの最初の言語とし
て引用される。１９６０年代までに、コンピュータ・プ
ログラミング言語の改良は、コンピュータ・プログラム
にまで及んだ。なぜなら、コンピュータ・プログラムが
非常に大規模化し、複雑化したため、コンピュータ・プ
ログラムの開発環境及び保守を管理及び制御することが
困難となったためである。

【０００５】こうして１９７０年代には、焦点は新たな
プログラミング言語の開発から、大規模なコンピュータ
・プログラムの日増しに進む複雑化及びコストを収容可
能な、プログラミング方法論及び環境の開発に移行し
た。こうした方法論の１つが、オブジェクト指向プログ
ラミング（ＯＯＰ：Object Oriented Programming ）の
アプローチである。ＯＯＰの支持者達は、コンピュータ
・プログラミングにおけるこのアプローチにより、コン
ピュータ・プログラマの生産性が２５倍程度改良される
と主張する。こうして、ＯＯＰ概念が最初に開発されて
から、既にある時間が経過したが、現在でもこの概念が
将来的な方法であると見なされている。

【０００６】ＯＯＰのより基本的な３つの概念は、"カ
プセル化（encapsulation）"、"インヘリタンス（継
承）（inheritance）"及び "再利用性（reusability）"
である。カプセル化は情報及び情報を使用する手段が、
概念的に"オブジェクト"と呼ばれる個々のエンティティ
（entity）にパッケージ化されることを意味する。オブ
ジェクトに含まれる情報はデータと称され、情報に対し
て特定のオペレーションを実行するために使用される手
段は、メソッド（method）と称される。オブジェクトは
コンピュータ・システムにより実行される個々のオペレ
ーションまたはオペレーションのグループを表す。再使
用性の概念は、オブジェクトが他の多くのオブジェクト
のメソッドにより使用可能なように、総称的に作成され
ることを意味する。オブジェクトを使用するプログラム
或いはメソッド・プログラムは、オブジェクトのクライ
アント（すなわちクライアント・プログラム）であると
呼ばれる。クライアントはオブジェクトを呼出す一方
で、使用されるメソッドを指定する。

【０００７】オブジェクトはまた、オブジェクトの特定
の"クラス"のメンバであると見なされる。オブジェクト
は生成されると、特定のクラスのメンバとなるか、或い
は特定のクラスのサブクラスのメンバであると見なされ
る。サブクラスのメンバとして生成されるオブジェクト
は、そのサブクラスの上のクラス（すなわちそれらのス
ーパー・クラス）の性質（すなわちデータ及びメソッ
ド）を継承すると言われる。例えば、自動車（Vehicle
）と称されるオブジェクト・クラスを考えてみよう。
このクラスは、そのクラスのオブジェクトを示すデータ
（すなわち名前、色、重量、所有者など）を有する。こ
のクラスはまた、このクラスのデータと共に作用するた
めに用いられるメソッドを定義される。クラス「自動
車」のサブクラスであるクラス「陸上自動車（RoadVehi
cle ）」は、更にどのタイプの自動車が含まれるかを示
すデータ（すなわち車輪の数などの属性を追加すること
による）を含むようにクラス「自動車」を細かく分類す
る。同様に「水上自動車（WaterVehicle）」と呼ばれる
クラスは、クラス「自動車」が排気量及び喫水などの属
性を含むように細かく分類する。例えば、クラス「陸上
自動車」のオブジェクトは、名前「ブーマ（Boome
r）」、色「赤」、重量「４０００ｌｂｓ」及び所有者
「スティーブ（Steve ）」を有するように生成される。
同様に、特定のボートを表すクラス「水上自動車」のオ
ブジェクトが生成される。サブクラスが追加されると、
階層構造が生成される。それぞれサブクラス或いはスー
パー・クラスと呼ばれる各クラスは、階層構造における
特定のレベルに位置するものと見なされる。上述の例で
は、クラス「自動車」のサブクラスであるクラス「陸上
自動車」及びクラス「水上自動車」は、クラス「自動
車」よりも１レベル高いレベルに位置する。

【０００８】継承の概念は、"多重継承"（multiple inh
eritance）と呼ばれるものを含むように拡張される。多
重継承は、あるクラスが複数のクラスのサブクラスとし
て生成される時に発生する。クラスが複数のクラスから
の性質を継承するために、そのクラスのオブジェクト
は、同時に２個或いはそれ以上のクラスのメンバと見な
される。例えば、上述の例のアクアタンク（AquaTank）
の場合を考えてみる。アクアタンクは、タンクのように
道路上を走る特殊な軍用自動車であるが、水上ではボー
トのように機能する。アクアタンクは陸上自動車でもあ
り水上自動車でもあるため、ここでは陸上自動車及び水
上自動車の両方から継承する（すなわち両者のサブクラ
スである）水陸両用自動車（AmphibiousVehicle ）と称
するクラスを生成する。この新たなクラスはドラフト及
び変位と同様に、車輪数に関するデータを有し、更に特
殊なデータを含むこともある。クラス「水陸両用自動
車」のオブジェクトは、このように両方のクラスの性質
を継承する。上述のように、これは"多重継承"と呼ばれ
る。

【０００９】単一継承では、クラスは１つの継承ツリー
構造を形成する。多重継承を追加することにより、ツリ
ー構造はグラフに一般化される。図２は継承グラフを示
す。

【００１０】最もよく知られるＯＯＰ環境に"Ｃ++"環境
と、"スモールトーク"（Smalltalk）環境の２つがあ
り、Ｃ++環境だけが多重継承をサポートする。Ｃ++環境
は現存の"Ｃ"コンピュータ・プログラミング言語の単に
拡張である。従って、その多重継承に対するアプロー
チ、及び一般にはＯＯＰに対するアプローチは、極めて
柔軟性に欠如する。オブジェクトの特定のクラスに対応
するデータが変更を要求する場合、或いはオブジェクト
の特定のクラスに対応するメソッドが追加される場合、
変更されるクラスのメンバである全てのオブジェクト、
及び変更されるクラスのサブクラスのメンバである全て
のオブジェクトが作り直されて、それらのメソッドが再
コンパイルされなければならない。更に、変更されるク
ラスのオブジェクト、或いは変更されるクラスのサブク
ラスのメンバであるオブジェクトに依存するクライアン
トもまた、再コンパイルされなければならない。これは
上述の仮定では特に問題とは思われないが、多数のクラ
ス及びサブクラスを含む大規模システムでは、非常にコ
ストがかかり、また時間を消費する。

【００１１】本質的に、今日のＯＯＰ環境はＯＯＰアプ
ローチにより実現されるはずの生産性の利点を著しく低
減させている。

【００１２】

【発明が解決しようとする課題】本発明の主な目的は、
多重継承をサポートする改良されたＯＯＰ環境を提供す
ることである。

【００１３】本発明の別の目的は、改良された多重継承
ＯＯＰ環境の構造を生成及び記憶する方法及び装置を提
供することである。

【００１４】更に本発明の別の目的は、改良されたＯＯ
Ｐ環境の多重継承オブジェクトに経路指定する方法及び
装置を提供することである。

【００１５】更に本発明の別の目的は、改良された多重
継承ＯＯＰ環境を生成する方法及び装置を提供すること
である。

【００１６】

【課題を解決するための手段】これらの目的が、本明細
書において開示される多重継承ＯＯＰデータ構造、装
置、方法、及び機構により達成される。本発明のデータ
構造、装置、方法、及び機構は、ユーザに柔軟な多重継
承ＯＯＰ環境を提供するように協力する。

【００１７】ＯＯＰ環境は、複合データ構造及びこれら
の構造を操作する内部機構を含む。こうした構造は、ユ
ーザがＯＯＰの効果を実現することを可能とする。従っ
て、これらの構造のレイアウト、これらの相関方法、及
びこれらが生成され使用される方法は、全て特定のＯＯ
Ｐ環境のユーティリティにとって重要である。従って、
ＯＯＰ環境の製造者及び供給者が、ユーザの生産性を最
大化する複合データ構造及び内部機構を設計しようと、
常時努力していることは、驚くに及ばないことである。

【００１８】本発明を構成する内部機構及び構造は、総
称的に多重継承オブジェクト・モデル（ＭＯＭ：Multip
le Inheritance Object Model ）と称される。複合デー
タ構造及びＭＯＭ ＯＯＰ環境の編成は、従来の多重継
承環境によっては提供されない重要な利点を提供する。
これらの利点には、コード・ベースの大部分の再コンパ
イルを要することなく、クラス定義にメソッド・プログ
ラムを追加する機能が含まれる。

【００１９】ＭＯＭ環境は３つの主要な複合データ構造
を含み、それらはオブジェクト構造、インタフェース・
テーブル、及びメソッド・テーブルである。オブジェク
ト構造は、その性質が現存のＯＯＰオブジェクト構造に
類似であり、オブジェクトを特徴づけるデータ、及びイ
ンタフェース・テーブルに関するロケーション情報を含
む。オブジェクト・データは更に、クラス・レベルによ
り細分化される。従って、各オブジェクトは特定の階層
ツリー構造におけるクラスの深さに対応する数のデータ
・セットを含む。インタフェース・テーブルは、オブジ
ェクトが属するクラスに対応するインタフェース・テー
ブル入力、及びオブジェクトのスーパー・クラスの各々
に対応する入力（すなわち特定の階層ツリー構造におけ
るクラスの深さに至る各レベルに対応して、１入力が割
当てられる）を含む。各入力はサブジェクト・クラス・
レベルに対応するメソッド・テーブルに関するロケーシ
ョン情報、特定のクラス・レベルに関連するオブジェク
ト・データのオフセットを含む。ロケーション情報はメ
ソッド・テーブルへのアクセスを獲得するために使用さ
れ、オフセットはオブジェクトに記憶されるインスタン
ス・データへのアクセスを獲得するために使用される。
特定のクラス・レベルに対応するメソッド・テーブル
は、個々のメソッド・プログラム及びメソッド・シグニ
チャに関するロケーション情報を含むメソッド・テーブ
ル入力を含む。メソッド・シグニチャは特定のメソッド
・プログラムを識別する。

【００２０】多重継承を提供するために、ＭＯＭインタ
フェース・テーブルは更に、多重インタフェース・テー
ブル（すなわちクラス構造）をリンクするために使用さ
れるリンク・ポインタを含み、特定のオブジェクト・イ
ンスタンスは複数のクラスから性質を継承することがで
きる。

【００２１】クライアント・プログラムが特定のオブジ
ェクトにおいて具現される機能を利用する時、これはオ
ブジェクト名及び呼出されるメソッド・プログラムの名
前を指定することにより、オブジェクトを呼出す。オブ
ジェクトの呼出しは、オブジェクトに"経路指定する"と
も称される。コンパイル時、ＭＯＭ呼出しステートメン
トは４片の情報を含み、それらはオブジェクトＩＤ、レ
ベル、呼出しシグニチャ、及びメソッド・オフセット
（すなわちメソッド・テーブル内のメソッド・プログラ
ムのロケーション）である。オブジェクトＩＤは特定の
オブジェクトを突き止め、アクセスするために使用され
る。一度実行されると、オブジェクト内のロケーション
情報が、インタフェース・テーブルへのアクセスを獲得
するために使用される。次に、適切なインタフェース・
テーブル入力を突き止めるために、レベルが使用され
る。インタフェース・テーブル入力に含まれるメソッド
・テーブル・ロケーション情報は、適切なメソッド・テ
ーブルへのアクセスを獲得するために使用される。次
に、正確なメソッド・テーブル入力をアクセスし、呼出
しシグニチャをメソッド・プログラム・シグニチャと比
較するために、メソッド・オフセットが使用される。シ
グニチャが一致すると、メソッド・プログラムを呼出す
ために、ロケーション情報が使用される。

【００２２】呼出しシグニチャがメソッド・プログラム
・シグニチャに一致しない場合、ＭＯＭメソッド解析装
置が自動的にリンク・ポインタをロードし、追加のイン
タフェース・テーブルが初期インタフェース・テーブル
に接続されているか（すなわち、この特定のオブジェク
トが複数のクラスから性質を継承しているか）を判断す
る。接続されていれば、メソッド解析機構が再度レベ
ル、メソッド・オフセット及び呼出しシグニチャを使用
して、選択されたメソッド・プログラムの呼出しを試み
る。この処理は、適切なメソッド・プログラムが突き止
められるか、インタフェース・テーブルが存在しなくな
るまで継続される。後者が発生すると、ＭＯＭメソッド
解析機構はエラー状態を発生し、呼出者に対してそれを
返却する。

【００２３】特定のクラスに対し、メソッド・プログラ
ムを追加する必要がある場合には、コンピュータ・プロ
グラマは、特定のクラスに関連するメソッド・テーブル
に、別の入力を追加するだけでよい。オブジェクトの再
コンパイルは必要ない。しかしながら、新たなメソッド
・プログラムへのアクセスを必要とするクライアント・
プログラムだけは、再コンパイルを必要とする。

【００２４】更にＭＯＭ環境は、複合データ構造をサポ
ートする内部機構を提供する。内部機構には、複数クラ
スから性質を継承するオブジェクト・インスタンスの生
成をサポートするオブジェクト・マネージャが含まれ
る。

【００２５】

【実施例】前述のように、現存の多重継承ＯＯＰ環境は
再コンパイルを要せずに、メソッド・プログラム或いは
データを既存のオブジェクト及びクラス構造に追加する
機能を提供しない。データ及びメソッド・プログラムを
非多重継承ＯＯＰ環境のクラスに追加する柔軟なアプロ
ーチが、審査中の米国特許出願第９５４１３８号（１９
９２年９月３１日出願）に述べられている。上記審査中
の米国特許出願第９５４１３８号は、本発明においても
参照される。

【００２６】図１は本発明のコンピュータ・システムの
ブロック図を示す。好適な実施例のコンピュータ・シス
テムは、改良されたＩＢＭ ＡＳ／４００中型コンピュ
ータ・システムである。しかしながら、ＯＯＰ環境をサ
ポートできるコンピュータ・システムであれば、使用可
能である。図１に示されるように、コンピュータ・シス
テム１００は中央処理ユニット（ＣＰＵ）１０５を含
み、これはシステム・バス１５０を介して、データ記憶
装置１４０及び端末インタフェース１４５に接続され
る。端末インタフェース１４５により、システム管理者
及びコンピュータ・プログラマは、通常、プログラマブ
ル・ワークステーションを通じて、コンピュータ・シス
テム１００と通信することができる。図１に示されるシ
ステムは、単一のメインＣＰＵ及び単一のシステム・バ
スしか含まないが、本発明が複数のメインＣＰＵ及び複
数のＩ／Ｏバスを有するコンピュータ・システムにも適
応できることは理解されよう。同様に実施例のバスは、
典型的にはハードワイヤで配線されるマルチドロップ・
バスであるが、双方向通信をサポートする接続手段であ
れば使用可能である。

【００２７】データ記憶装置１４０はシステム・オブジ
ェクト・マネジャ１１５、クラス定義ユーティリティ１
１７、クライアント・プログラム１２０、オブジェクト
１２５、メソッド・プログラム１３０、及びオペレーテ
ィング・システム１３５を含む。データ記憶装置１４０
は、一様な存在として示されるが、実際には様々なデバ
イスを含むこともあり、示される全てのプログラム及び
ファイルが、必ずしもある１つのデバイス内に含まれる
ものではないことが理解されよう。例えば、クライアン
ト・プログラム１２０及びオペレーティング・システム
１３５の一部は、典型的には主メモリにロードされて実
行され、一方、ソース・データ・ファイルは、典型的に
は磁気或いは光ディスク記憶装置上に記憶される。

【００２８】図２は、本発明の装置、方法、及び構造を
説明するために、本明細書を通じて使用されるＯＯＰ階
層ツリー構造の例を示す。２重線で示されるボックスは
異なるクラスを表し、単線で示されるボックスは、特定
のクラスのオブジェクト・インスタンスを表す。オブジ
ェクト・インスタンスは特定のクラスのメンバを表す。
ここで図２が仮定的構成の概念を表すことが理解されよ
う。データ記憶装置１４０にクラス及びオブジェクトが
実際に存在する様子が、図８乃至図１１、図１４に示さ
れている。更に概念レベルでは、図２の仮定的構成が、
個人或いはユーザが特定の人または従業員を扱うデータ
を編成する様子を表すことが理解されよう。各クラスは
情報の特定のカテゴリと見なされ、各サブクラスは情報
のサブカテゴリとして見なされる。特定のクラスの個々
のメンバ（オブジェクト・インスタンスにより表され
る）は、特定の個人に関する情報を含む。

【００２９】クラス"Root"２００はツリー構造の実例の
基本クラスである。クラスRoot２００はインスタンス変
数を含み、それらは"オブジェクト名"２０２、 "オブジ
ェクト・クラス" ２０４、"クラス・レベル"２０６、及
び"インスタンス・サイズ"２０８である。クラスRoot２
００はツリー構造の最高レベルに位置するため、そのイ
ンスタンス変数は、それ以下で定義される全てのサブク
ラスにより継承される（クラスPersonnel ２１８に対応
しては示されていない）。クラスRoot２００はまたクラ
ス・レベル０と見なされる。クラス・レベル１には、Ed
ucation ２１０、Personnel２１８が定義される。クラ
スEducation２１０はオブジェクト・インスタンス変数
として、"オブジェクト名"２０２、"オブジェクト・ク
ラス"２０４、"クラス・レベル"２０６、"インスタンス
・サイズ"２０８、"従業員番号"２１２、"学年"２１
４、及び"カレッジ"２１６が含まれる。オブジェクト・
インスタンス変数の"オブジェクト名"２０２、"オブジ
ェクト・クラス"２０４、 "クラス・レベル"２０６、及
び"インスタンス・サイズ" ２０８は、クラスRootから
継承され、オブジェクト・インスタンス変数の"従業員
番号"２１２、"学年"２１４、及び"カレッジ"２１６
は、クラスEducation に対応して特定的に定義される。
クラスEducationのサブクラスとして定義される各クラ
ス（すなわちクラスMasters２２０、Phd２２２、及びJD
２２８）は、これら全てのオブジェクト・インスタン
ス変数の定義を継承する。（クラスMasters ２２０に対
応しては図示されていない。）

【００３０】例えば、クラスPhd２２２は、クラスEduca
tion２１０のサブクラスとして定義される。クラスEduc
ation ２１０はそれ自身、クラスRoot２００のサブクラ
スである。従って、クラスPhd ２２２は両方のスーパー
・クラスのオブジェクト・インスタンス変数定義（すな
わち"オブジェクト名"２０２、 "オブジェクト・クラ
ス"２０４、"クラス・レベル"２０６、"インスタンス・
サイズ"２０８、"従業員番号"２１２、"学年"２１４、
及び"カレッジ"２１６）を継承する。クラスPhd２２２
はまた、その固有のクラス定義部分であるインスタンス
変数も含む。それらは、"Phdユニバーシティ"２２４、
及び"Phd Gpa"２２６である。クラスPhd ２２２のメン
バとして生成されるオブジェクトは、オブジェクト・イ
ンスタンス変数、すなわちオブジェクト名、オブジェク
ト・クラス、クラス・レベル、インスタンス・サイズ、
従業員番号、学年、カレッジ、Phdユニバーシティ、及
びPhd Gpaに関連する値を有する。John２３４はクラスP
hd ２２２のメンバであるオブジェクトの例であり、Sal
ly２３８はクラスJD ２２８のメンバであるオブジェク
トの例である。

【００３１】クラスPhd/JD２４０は多重継承クラスとし
て示される。これはクラスPhd/JDがその性質を、構造内
の特定のレベルの複数のスーパー・クラスから継承する
ことを意味する。この例では、クラスPhd/JD２４０はそ
の性質を、構造内のレベル２に位置するクラスPhd２２
２及びクラスJD２２８から継承する。例ではクラスPhd/
JD ２４０が、階層内の１つだけ上位のレベルの２つの
クラスから性質を継承するように示されるが、本発明が
階層内の任意のレベルのクラスから発生する多重継承に
も同様に適用可能なことが理解されよう。更に、本発明
が２つのスーパー・クラスからの継承に限るものでない
ことが理解されよう。本発明は任意のレベルにおける任
意の数のスーパー・クラスからの継承に対して適応す
る。

【００３２】クラスPhd/JD２４０はPhd ２２２及びJD２
２８のサブクラスとして定義されたため、クラスPhd/JD
２４０は両者の共通の性質（すなわち"オブジェクト名"
２０２、"オブジェクト・クラス"２０４、"クラス・レ
ベル"２０６、 "インスタンス・サイズ" ２０８、"従業
員番号"２１２、"学年"２１４、及び"カレッジ"２１
６）、クラスPhd２２２に特有の性質（すなわち"Phdユ
ニバーシティ"２２４及び"Phd Gpa" ２２６）、及びク
ラスJD２２８に特有の性質（すなわち"法律学校"２３０
及び"JD Gpa"２３２）を継承する。また、図２はクラス
Phd/JD２４０に対して特定に定義されるインスタンス変
数定義を示していないが、本発明の範疇にはこれらの変
数も含まれる。

【００３３】オブジェクト・インスタンスJoe ２３６
は、クラスPhd/JDのメンバであるオブジェクトの例であ
る。

【００３４】ＭＯＭインタフェース・テーブル：本発明
を理解するために、ＭＯＭインタフェース・テーブルが
多重継承を提供する様子を理解することは重要であり、
その詳細を図３で説明する。インタフェース・テーブル
における各入力は、階層内の特定のクラスに関する情報
を含む。更に詳細には、各入力は追加のインタフェース
・テーブル或いはメソッド・プログラムに関するロケー
ション情報、及び特定のクラスのインスタンス・データ
を含む。クライアント・プログラムがオブジェクトを呼
出す時、これらはインタフェース・テーブルに記憶され
るロケーション情報を介して、追加のインタフェース・
テーブル及びメソッド・プログラム及びインスタンス・
データへのアクセスを獲得する。

【００３５】ＭＯＭインタフェース・テーブル２５０は
インタフェース・テーブル入力２５１、２５５、２６０
及び２６５を含み、インタフェース・テーブル２７０は
インタフェース・テーブル入力２７１、２７５、２８０
及び２８５を含む。インタフェース・テーブル入力２５
１及び２７１は、追加のインタフェース・テーブルに関
するロケーション情報を記憶するために使用される。例
えば図３は、インタフェース・テーブル２７０がインタ
フェース・テーブル入力２５１に含まれるロケーション
情報を通じて位置付けられることを示す。インタフェー
ス・テーブル入力２５５、２６０、２６５、２７５、２
８０及び２８５は、メソッド・テーブル・ポインタ（例
えばメソッド・テーブル・ポインタ２５５）及びデータ
・オフセット（例えばデータ・オフセット２５５）を含
む。メソッド・テーブル・ポインタは、特定のメソッド
・テーブル及び最終的にはメソッド・プログラムをアク
セスするために、クライアント・プログラムにより使用
される。これらのフィールドは、図１４及び図１５に関
連してより詳細に説明される。

【００３６】ＭＯＭ環境の生成：図４はクラス定義ユー
ティリティ１１７の内部作業の流れ図であり、図５及び
図６はシステム・オブジェクト・マネジャ１１５の内部
作業の流れ図である。図８乃至図１１は、図２の木構造
の一部が、実際にデータ記憶装置１４０内に存在する様
子を示す。図４乃至図７は、図２で示されるような階層
構造が実際に生成される様子を説明するために、図８乃
至図１１と関連して使用される。

【００３７】コンピュータ・システム１００が顧客或い
は他のユーザに届けられる時、クラス・オブジェクトRo
ot（図８の４００）に対応する複合データ構造、及びRo
otクラス（図８の構造４０５及び４１０）は、既にデー
タ記憶装置１４０にロードされている。当業者には理解
されるように、これらの複合データ構造が最初に生成さ
れて、データ記憶装置１４０に記憶されるための多数の
方法が存在する。同様に、これらの構造の生成及び記憶
は、必ずしも製造工場において実施される必要はない。
顧客或いはユーザが、クラス定義ユーティリティ１１７
及びシステム・オブジェクト・マネジャ１１５を独立に
呼出すことにより、これらの複合データ構造を生成及び
記憶することも可能である。しかしながら、説明の都合
上、ここではクラス・オブジェクトRoot４００、インタ
フェース・テーブル４０５（すなわちクラスRootに対応
するインタフェース・テーブル）、及びメソッド・テー
ブル４１０（すなわちクラスRootに対応するメソッド・
テーブル）が、製造工場において、データ記憶装置１４
０に予めロードされるものと仮定する。

【００３８】コンピュータ・システム１００のユーザが
クラスEducation ２１０を定義しようと望むと、ユーザ
はクライアント・プログラム（すなわちクライアント・
プログラム１２０の１つ）を開始し、クライアント・プ
ログラム自身はクラス・オブジェクトRoot４００のメソ
ッドを呼出す。クライアント・プログラムはそれによ
り、インタフェース・テーブル４０５及びメソッド・テ
ーブル４１０へのアクセスを獲得する。このアクセスが
実際にどのように実行されるかに関しては、図１４及び
図１５に関連して説明される。メソッド・テーブル４１
０へのアクセスが実行されると、クライアント・プログ
ラムはdefine_subclass_p ４１２により、クラス定義ユ
ーティリティ１１７を呼出す。ここでクラス定義ユーテ
ィリティ１１７は、実際にはメソッド・プログラム１３
０とそう違わないメソッド・プログラムである。クラス
定義ユーティリティ１１７は、クラス定義において演じ
る役割に由来して、多数の処理を引受ける。流れ図４
は、クラス定義ユーティリティ１１７により実行される
第１のステップ（ブロック３０２）が、適切なクラス・
オブジェクトの生成であることを示す。この場合、生成
されるクラス・オブジェクトはクラス・オブジェクトEd
ucation ４１５（図９に示される）である。ユーザは次
にブロック３０４で、クラス名を入力するように求めら
れ、ブロック３０６では、このクラスに対応するインス
タンス変数定義（図９の４１９で示される）を入力する
ように求められる。そしてブロック３０８では、メソッ
ド・プログラム・アドレスを入力するように求められ
る。

【００３９】クラス定義ユーティリティ１１７は、次に
ブロック３１０でユーザに対し、定義されるクラスがサ
ブクラスであるかを尋ねる。この例では、クラスEducat
ionはクラスRootのサブクラスであるので、この問いか
けは肯定して返答される。図５を参照すると、ユーザは
次にブロック３１６で、定義されるクラスのスーパー・
クラスの名前及びレベルを催促される。名前及びレベル
は両者共に、特定のスーパー・クラスが識別されること
を保証するように、指定されなければならない。この例
では、入力されるスーパー・クラスはRootであり、入力
されるレベルは０である。スーパー・クラス名及びレベ
ルが入力されると、クラス定義ユーティリティ１１７
は、次にブロック３１８で、１次インタフェース・テー
ブルを生成する。多重継承が含まれる場合、１次インタ
フェース・テーブルはインタフェース・テーブルの連鎖
内の最初のインタフェース・テーブルである（図３参
照）。クラスEducation は複数クラスから継承しないた
め（ブロック３２０）、クラス定義ユーティリティ１１
７はクラスEducation に対応するメソッド・テーブルを
生成し、クラスEducation のスーパー・クラス（ここで
はスーパー・クラスRoot）からメソッド・テーブルをコ
ピーする（ブロック３２４）。これらの構造はそれぞれ
インタフェース・テーブル４２０及びメソッド・テーブ
ル４２５及び４３０として、図９に示される。新たなク
ラス（すなわちEducation ）は次にブロック３２８で、
クラス・レベルが割当てられる（この場合１）。ブロッ
ク３３２でクラス定義ユーティリティ１１７は、ブロッ
ク３０６でユーザにより入力されたインスタンス変数定
義のオフセットを計算する。ブロック３３４でクラス定
義ユーティリティ１１７は、クラス・オブジェクトRoot
（クラス・オブジェクト４００）からインスタンス変数
をコピーし、それらをEducation クラス・オブジェクト
（クラス・オブジェクト４１５）に配置する。これが図
９の４１８に示される。

【００４０】次のステップでは、クラス・オブジェクト
４１５をインタフェース・テーブル４２０にリンクする
（ブロック３３６）。これはinterface_tbl_p ４１７
を、インタフェース・テーブル４２０の開始アドレスに
等しくセットすることにより達成される。多重継承が含
まれないため（ブロック３４０）、クラス定義ユーティ
リティ１１７はクラス・インスタンス変数のオフセット
を、インタフェース・テーブル４２０内の適切なインタ
フェース・テーブル入力に書込む（ブロック３４２）。
Education クラス・インスタンス変数定義に対応するオ
フセットは、インタフェース・テーブル入力４２３のEd
_instance_data_oフィールドに書込まれ、スーパー・ク
ラス・インスタンス変数定義に対応するオフセットは、
インタフェース・テーブル入力４２１のroot_insutance
_data_o フィールドに書込まれる。最後に、メソッド・
テーブル及びメソッド・プログラムのアドレスが、イン
タフェース・テーブル及びメソッド・テーブルにそれぞ
れ書込まれる（ブロック３４４及び３４６）。メソッド
・テーブル４３０のアドレスは、インタフェース・テー
ブル入力４２３のEd_meth_tbl_p フィールドに書込ま
れ、メソッド・テーブル４２５のアドレスは、インタフ
ェース・テーブル入力４２１に書込まれる。ブロック３
４６では、メソッド・プログラムのアドレスが、メソッ
ド・テーブル４３０に書込まれる。例えば"学年更新"と
称されるメソッド・プログラムのアドレスが、"update_
U_degree_p"フィールド４２７に書込まれる。

【００４１】クラスEducationと同様、図２のツリー構
造に示される次のサブクラスPhd及びJDについても、複
数のスーパー・クラスから性質を継承しない。図４はこ
れらのサブクラスが定義される様子を理解するために、
図１０と関連して使用される。繰返しを避けるため、こ
れらのサブクラスを定義するために実行されるステップ
についての説明は省略する。

【００４２】クラスPhd/JDはクラスPhd 及びクラスJDの
両方から性質を継承し、その定義はクラスEducation、P
hd及びJDの場合とは異なる。上述のように、クライアン
ト・プログラムがクラス・オブジェクトRoot４００に経
路指定されると、クラス定義ユーティリティ１１７が開
始される。流れ図４は、クラス定義ユーティリティ１１
７により実行される最初のステップ（ブロック３０２）
が、適切なクラス・オブジェクトの生成であることを示
す。この場合、生成されるクラス・オブジェクトはクラ
ス・オブジェクトPhd/JD４７０（図１１参照）である。
ユーザは次にクラス名、クラスに対応するインスタンス
変数定義、及びメソッド・プログラム・アドレスを入力
するように、それぞれブロック３０４、３０６及び３０
８で要求される。この場合、クラスPhd/JDは固有のイン
スタンス変数定義を有さない。

【００４３】クラス定義ユーティリティ１１７は、次に
ブロック３１０でユーザに対し、定義されるクラスがサ
ブクラスであるかを尋ねる。この例では、クラスPhd/JD
はクラスPhd 及びJDのサブクラスであるので、この問い
かけ肯定して返答される。図５を参照すると、ユーザは
次にブロック３１６で、定義されるクラスのスーパー・
クラスの名前及びレベルを催促される。名前及びレベル
は両者共に、特定のスーパー・クラスが識別されること
を保証するように、指定されなければならない。この例
では、入力されるスーパー・クラスはPhd 或いはJDであ
り、入力されるレベルは２である。初期スーパー・クラ
ス名及びレベルが入力されると、クラス定義ユーティリ
ティ１１７は、次にブロック３１８で、１次インタフェ
ース・テーブルを生成する（図１１にインタフェース・
テーブル４７５として示される）。この場合、多重継承
が含まれるため、１次インタフェース・テーブルはイン
タフェース・テーブルの連鎖内の最初のインタフェース
・テーブルである（図３参照）。クラス定義ユーティリ
ティ１１７は次にブロック３２２で、ユーザに対し、追
加のスーパー・クラス名の入力を催促し、ブロック３２
６で追加のインタフェース・テーブルを生成する（図１
１にインタフェース・テーブル４８０として示され
る）。インタフェース・テーブル内のほとんどのインタ
フェース・テーブル入力が同一であるため、クラス定義
ユーティリティ１１７は重複する入力を除去する（ブロ
ック３３０）。

【００４４】ブロック３２０で、ユーザは再び追加の継
承が求められているかどうかを問われる。この例では、
Phd/JDはレベル２の２つのスーパー・クラスだけから性
質を継承するが、当業者には、本発明が同一レベル或い
は異なるレベルに存在する任意の数のスーパー・クラス
からの継承に適応することが理解されよう。複数のイン
タフェース・テーブルの生成を完了すると、クラス定義
ユーティリティ１１７はクラスPhd/JDに対応するメソッ
ド・テーブルを生成し、クラスPhd/JDのスーパー・クラ
ス（ここではスーパー・クラスRoot、Education、Phd、
及びJD）からメソッド・テーブルをコピーする（ブロッ
ク３２４）。新たなクラス（すなわちPhd/JD）は、次に
ブロック３２８で、クラス・レベルが割当てられる（す
なわち最も深いスーパー・クラスよりも１大きい値、こ
の場合には３が割当てられる）。ブロック３３２で、ク
ラス定義ユーティリティ１１７は、ブロック３０６にお
いてユーザにより入力されたインスタンス変数定義（こ
の場合には入力されていない）のオフセットを計算す
る。ブロック３３４で、クラス定義ユーティリティ１１
７は、クラス・オブジェクトRoot（クラス・オブジェク
ト４００）からインスタンス変数をコピーし、それらを
Phd/JDクラス・オブジェクト（クラス・オブジェクト４
７０）に配置する。これが図１１の４７２に示される。

【００４５】次のステップでは、クラス・オブジェクト
４７０をインタフェース・テーブル４７５にリンクする
（ブロック３３６）。これはinterface_tbl_p ４７３
を、インタフェース・テーブル４７５の開始アドレスに
等しくセットすることにより達成される。多重継承が含
まれるため（ブロック３４０）、クラス定義ユーティリ
ティ１１７は、最初に１次インタフェース・テーブル４
７５を追加のインタフェース・テーブル４８０にリンク
し（ブロック３３８）、次にクラス・インスタンス変数
のオフセットを、インタフェース・テーブル４７５及び
４８０内の適切なインタフェース・テーブル入力に書込
む（ブロック３４２）。最後に、メソッド・テーブル及
びメソッド・プログラムのアドレスが、インタフェース
・テーブル及びメソッド・テーブルにそれぞれ書込まれ
る（ブロック３４４及び３４６）。

【００４６】図２の構造例を構成する最後のステップで
は、特定のクラスのメンバであるオブジェクト・インス
タンスを生成する。サブクラス定義ユーティリティ１１
７の呼出しの場合同様、クラスPhd/JDのオブジェクト・
インスタンスを生成しようと望むコンピュータ・システ
ム１００のユーザは、インタフェース・テーブル４７５
及びクラスRootからコピーされたメソッド・テーブルへ
のアクセスを獲得する。このアクセスが実際に実行され
る様子については、図１４及び図１５に関連して説明さ
れる。メソッド・テーブル４７５へのアクセスが実行さ
れると、クライアント・プログラムはcreat_new_object
_p４４２（図８参照）を通じて、システム・オブジェク
ト・マネジャ１１５を呼出す。

【００４７】図７は、システム・オブジェクト・マネジ
ャ１１５の内部作業の流れ図である。システム・オブジ
ェクト・マネジャ１１５は、最初にブロック３６０で、
オブジェクトを生成する。この例では、オブジェクト・
インスタンス４５５（Joe ）が生成される（図１２参
照）。ユーザは次にブロック３６２で、オブジェクト名
を入力するように催促され、引続きブロック３６４では
クラス及びレベルを、更にブロック３６６では、オブジ
ェクト・インスタンス変数の値を入力するように催促さ
れる。この値は図１２の４４７に示される。システム・
オブジェクト・マネジャ１１５は、次にブロック３６８
で、この情報をオブジェクト４５５に書込む。オブジェ
クト４５５は、次にinterface_tbl_p ４４６を介して、
インタフェース・テーブル４６０（すなわちクラスPhd/
JDに対応するインタフェース・テーブル）にリンクされ
る。従業員"Joe" に関するデータを処理しようと望むク
ライアント・プログラムは、次に、オブジェクト・イン
スタンスJoe を呼出す。

【００４８】図１６は、Ｃ++ ＯＯＰ環境の基本となる
主な複合データ構造を示す。オブジェクト・インスタン
ス５５５は、従業員Joe に対応するオブジェクト・イン
スタンスが、Ｃ++環境において存在する様子を表してい
る。仮想ファンクション・テーブル５６０及び５６５
は、オブジェクトJoe がそのメンバに含まれるクラス
（すなわちクラスPhd及びJD）、及びクラスPhd及びJDが
サブクラスに含まれる全てのスーパー・クラス（すなわ
ちスーパー・クラスEducation及びRoot ）のメソッド・
プログラムを指示するメソッド・ポインタを含む。

【００４９】従来の技術で述べられたように、Ｃ++環境
は、メソッド・プログラムを追加する必要が生じた場
合、極めて柔軟性がない。オブジェクトの特定のクラス
に対応するメソッド・プログラムが追加される時、変更
されるクラスのメンバである全てのオブジェクト、及び
変更されるクラスのサブクラスのメンバである全てのオ
ブジェクトが作り直され、それらのメソッド・プログラ
ムが再コンパイルされなければならない。更に、それら
のオブジェクトの全てのクライアントについても、再コ
ンパイルされなければならない。この柔軟性の欠如は、
Ｃ++データ構造の設計に由来する。

【００５０】Ｃ++環境において、クライアント・プログ
ラムがオブジェクトに経路指定される時、呼出されるメ
ソッド・プログラムを表す仮想ファンクション・テーブ
ル内の入力のオフセットが、呼出しステートメントの一
部として指定される。図１６に示されるように、全階層
のメソッド・プログラムに対するポインタが、仮想ファ
ンクション・テーブル５６０及び５６５にスタックされ
る。特定のクラスにメソッド・プログラムを追加する必
要が生じる時、特定のクラスのサブクラスのメソッド・
プログラムに対するメソッド・プログラム・ポインタ
が、構造内で全てシフト・ダウンされる（すなわち、そ
れらのオフセットが変化する）。例えば、クラスEducat
ion にメソッド・プログラムを追加する場合、メソッド
・プログラムのアドレスが５０７及び５１１に挿入され
る。次に、新たなメソッド・プログラムに対するポイン
タが、以前に"Phdユニバーシティ更新"及び"法律学校更
新"に対するポインタ（すなわちupdate_Phd_univ_p５０
６及びupdate_Law_school_p５０９）により占有されて
いたオフセットに配置される。これらのメソッド・プロ
グラムに対するポインタは、以前に他のポインタにより
占有されていたロケーションに、シフト・ダウンされ
る。

【００５１】この"シフト"作用は、クラスEducation の
オブジェクトを呼出す全てのクライアント・プログラム
の再コンパイルを要求し（すなわち新たなメソッドの存
在を認識するため）、旧メソッド・プログラムの新たな
オフセットを認識するために、クラスEducationのサブ
クラス（すなわちPhd及びJD）に対応する全てのクライ
アント・プログラムの再コンパイルを要求する。

【００５２】多くの場合において、オブジェクトの特定
クラスへのメソッド・プログラムの追加により、影響を
受けるオブジェクト及びクライアント・プログラムを判
断しようと試みるよりも、単に全てのコードを再コンパ
イルすることの方が容易である。しかしながら、このタ
イプの再コンパイルは、その実行にまる一日を費やす可
能性がある。

【００５３】

【発明の効果】

ＭＯＭ ＯＯＰ環境の利点：図１３は、本発明の主要な
複合データ構造を示す。オブジェクト・インスタンス６
００は、従業員Joe に対応するオブジェクト・インスタ
ンスがＭＯＭ環境において存在する様子を表す。Ｃ++環
境の場合と異なり、ＭＯＭ ＯＯＰ環境では、クラスPh
d に対応するインタフェース・テーブル（すなわちイン
タフェース・テーブル６０５）、及び階層内の各クラス
に対応するメソッド・テーブルを含む。図１３は、クラ
スEducation に対応するスーパー・クラス・メソッド・
テーブル（すなわちメソッド・テーブル６１５）、及び
クラスJDに対応するクラス・メソッド・テーブル（すな
わちメソッド・テーブル６２０）しか示していない。す
なわち、クラスRootに対応するスーパー・クラス・メソ
ッド・テーブル、及びクラスPhdに対応するクラス・メ
ソッド・テーブルは示されていない。Joeは多重継承オ
ブジェクトであるため、クラスJDに対応するインタフェ
ース・テーブル（すなわちインタフェース・テーブル６
１０）もまた図１３には示されている。これらの相違は
ＭＯＭ ＯＯＰ環境のユーザに対し、Ｃ++ ＯＯＰ環境
のユーザによっては実現されない利点を提供する。前節
で述べたように、ＭＯＭ環境のユーザは、特定のクラス
にメソッド・プログラムを追加するために、全コード・
ベースを再コンパイルする必要がない。

【００５４】ＭＯＭクラスへのメソッド・プログラムの
追加：ＭＯＭクラスへのメソッド・プログラムの追加を
説明するために、上述のように、ユーザがクラスEducat
ion に対してメソッド・プログラムを追加することを希
望するものと仮定する。メソッド・プログラムに対する
ポインタが、クラスEducation に対応するメソッド・テ
ーブル（すなわちメソッド・テーブル６１５）の６１７
に追加される。Ｃ++環境の場合とは異なり、その際シフ
トは発生しない。クラスPhd 及びJDに対応するメソッド
・プログラムに対するポインタが、異なる構造内（例え
ばメソッド・テーブル６２０）に配置されるため、これ
らは変位されない。従って、クラスPhd/JDのオブジェク
トを使用するクライアント・プログラムは、再コンパイ
ルを要さない。新たなメソッド・プログラムへのアクセ
スを獲得する必要のあるクライアント・プログラムだけ
が、再コンパイルを要することになる。

【００５５】メソッド・プログラムの効率的アクセス：
図１４及び図１５は、クライアント・プログラムにより
ＭＯＭ環境のメソッド・プログラムが呼出される時に、
それが探索される様子を示す。図１５を参照して、クラ
イアント・プログラムが従業員JoeのLaw Gpaの更新を望
むものと仮定する。クライアント・プログラムは、その
コードの一部として、呼出しステートメント（"Joe．up
date_Law_Gpa"７５０）を有し、これによりオブジェク
トJoeが呼出される。コンパイル時、ＭＯＭ呼出しステ
ートメントは、オブジェクトＩＤ、クラス・レベル、ク
ラス・シグニチャ、及びメソッド・オフセットを含む。
呼出しステートメントの実行後、クライアント・プログ
ラム・コードは、ブロック７５５で、オブジェクト・イ
ンスタンスJoe （図１４のオブジェクト・インスタンス
７００）をロードし、次にブロック７６０で、オブジェ
クトJoe からインタフェース・テーブル・ポインタ（図
１４のinterface_tbl_p ７０２）をロードする。次にブ
ロック７６５で、クラス・レベルを使用して、正しいイ
ンタフェース・テーブル入力（すなわちクラス・レベル
１により指定されるインタフェース・テーブル入力７１
１）をアクセスする。

【００５６】ブロック７７０で、クライアント・プログ
ラムはPhd_meth_tbl_p７０９により、クラスPhd に対応
するメソッド・テーブル（すなわちメソッド・テーブル
７１５）へのアクセスを獲得し、次にブロック７７５
で、メソッド・オフセットによりメソッド・シグニチャ
７１７をアクセスし、ブロック７８５で、それを呼出し
シグニチャと比較する。実施例の呼出しシグニチャ及び
クラスシグニチャは、本コンピュータ・システムの識別
番号、クラス・レベル、及びタイム・スタンプを使用し
て構成されるが、特定の識別子を生成する任意の手段が
使用可能である。この例では、クライアント・プログラ
ムが"Phd Gpa 更新"メソッド・プログラムへのアクセス
の獲得を望まないため、ブロック７８７でシグニチャは
合致しない。従って、クライアント・プログラムは、次
のインタフェース・テーブル・ポインタの中の情報が空
（Nill）であるかどうかをブロック７９０で問いかけ、
そうでない場合には、ブロック７８０で次のインタフェ
ース・テーブルに移行する。

【００５７】この例では、オブジェクトJoe は多重継承
オブジェクトであるため、ブロック７８０で入力７０７
はインタフェース・テーブルのアドレスを含む。この時
点において、処理は上述したように継続する。ブロック
７６５及び７７０で、インタフェース・テーブル入力及
びメソッド・テーブルがそれぞれアクセスされ、ブロッ
ク７８５で呼出しシグニチャが再度メソッド・プログラ
ム・シグニチャと比較される。この例では、呼出しシグ
ニチャはこの繰返しの間にメソッド・シグニチャと合致
し（ブロック７８７）、"Law Gpa 更新"メソッド・プロ
グラムがブロック７９２で呼出される。クライアント・
プログラムは次に従業員Joe に対応するLaw Gpaを更新
する。

【００５８】本発明の別の実施例では、多重継承を要求
するオブジェクトが生成される度に、インタフェース・
テーブル及びメソッド・テーブルの動的な生成が生じ
る。実質的には、これは多重継承論理（図５及び図６）
をオブジェクト生成ステージ（図７）に移動することに
より達成される。

【００５９】以上、本発明の特定の実施例について述べ
てきたが、当業者には理解されるように、本発明の精神
及び範疇内において、様々な変更が可能である。

【図面の簡単な説明】

【図１】本発明の実施例のコンピュータ・システムを表
す図である。

【図２】本発明のＯＯＰ環境を説明するために使用され
る仮定的多重継承ＯＯＰ構成を示す図である。

【図３】ＭＯＭインタフェース・テーブルの詳細図であ
る。

【図４】ＭＯＭ ＯＯＰ環境が生成される様子を示す流
れ図である。

【図５】ＭＯＭ ＯＯＰ環境が生成される様子を示す流
れ図である。

【図６】ＭＯＭ ＯＯＰ環境が生成される様子を示す流
れ図である。

【図７】ＭＯＭ ＯＯＰ環境が生成される様子を示す流
れ図である。

【図８】ＭＯＭ環境を構成するデータ構造が実際に生成
されて記憶装置に記憶される様子を示す図である。

【図９】ＭＯＭ環境を構成するデータ構造が実際に生成
されて記憶装置に記憶される様子を示す図である。

【図１０】ＭＯＭ環境を構成するデータ構造が実際に生
成されて記憶装置に記憶される様子を示す図である。

【図１１】ＭＯＭ環境を構成するデータ構造が実際に生
成されて記憶装置に記憶される様子を示す図である。

【図１２】ＭＯＭ環境を構成するデータ構造が実際に生
成されて記憶装置に記憶される様子を示す図である。

【図１３】メソッド・プログラムが複数のクラスから性
質を継承するＭＯＭオブジェクト・インスタンスに追加
される様子を示す図である。

【図１４】ＭＯＭ ＯＯＰ環境において使用されるメソ
ッド経路指定技術を示す図である。

【図１５】ＭＯＭ ＯＯＰ環境において使用されるメソ
ッド経路指定技術を示す図である。

【図１６】メソッド・プログラムが複数のクラスから性
質を継承するＣ++オブジェクト・インスタンスに追加さ
れる様子を示す図である。

【符号の説明】

１００ コンピュータ・システム １０５ 中央処理ユニット（ＣＰＵ） １１５ システム・オブジェクト・マネジャ １１７ クラス定義ユーティリティ １２０ クライアント・プログラム １２５ オブジェクト １３０ メソッド・プログラム １３５ オペレーティング・システム １４０ データ記憶装置 １４５ 端末インタフェース １５０ システム・バス ２００ クラス"Root" ２１０ クラス"Education" ２１８ クラス"Personnel" ２２０ クラス"Masters" ２２２ クラス"Phd" ２２８ クラス"JD" ２４０ クラス"Phd/JD" ２５０ ＭＯＭインタフェース・テーブル ２５５ メソッド・テーブル・ポインタとデータ・オフ
セット ４００ クラス・オブジェクトRoot ４５５、６００、７００ オブジェクト・インスタンス ４７０ クラス・オブジェクトPhd/JD ５６０、５６５ 仮想ファンクション・テーブル ７１７ メソッド・シグニチャ

───────────────────────────────────────────────────── フロントページの続き (72)発明者 アショク・マルホトラ アメリカ合衆国10520、ニューヨーク州 クロトン−オン−ハドソン、ヘシアン・ ヒルズ・ロード 212 (72)発明者 スティーブン・ジェイ・マンロー アメリカ合衆国55901、ミネソタ州ロチ ェスター、ノース・ウエスト、サーティ サード・ストリート 1320 (56)参考文献 特開 平３−257530（ＪＰ，Ａ)

Claims (6)

(57)【特許請求の範囲】
1. 【請求項１】複合データ構造を生成及び記憶する方法で
   あって、 オブジェクトのインスタンスを生成するステップと、上記オブジェクトが継承する第１のクラスに対応する第
   １のインタフェース・テーブルのロケーション情報を上
   記オブジェクト中に記憶することによって、上記 第１の
   インタフェース・テーブルを上記オブジェクト・インス
   タンスに接続するステップと、上記オブジェクトが継承する第２のクラスに対応する第
   ２のインタフェース・テーブルのロケーション情報を上
   記第１のインタフェース・テーブル中に記憶することに
   よって、上記 第２のインタフェース・テーブルを上記第
   １のインタフェース・テーブルに接続するステップと、上記第１のクラスに関連する第１及び第２のメソッド・
   テーブルのロケーション情報を上記第１のインタフェー
   ス・テーブル中に記憶することによって、上記 第１及び
   第２のメソッド・テーブルを上記第１のインタフェース
   ・テーブルに個別に接続するステップと、上記第２のクラスに関連する第３のメソッド・テーブル
   のロケーション情報を上記第２のインタフェース・テー
   ブル中に記憶することによって、上記 第３のメソッド・
   テーブルを上記第２のインタフェース・テーブルに接続
   するステップと、 を含む方法。
2. 【請求項２】上記オブジェクト・インスタンスの生成ス
   テップが、 インスタンス変数を生成するステップと、 上記インスタンス変数を上記オブジェクト・インスタン
   スに配置するステップと、 を含む、請求項１記載の方法。
3. 【請求項３】特定のクラスに対応するメソッド・プログ
   ラムを呼出す方法であって、 オブジェクトのアドレス、上記呼出しを行う上記クラス
   を表すレベル、呼出しシグニチャ、及び呼出される上記
   メソッド・プログラムを表すメソッド・プログラム・オ
   フセットを含む呼出しステートメントを使用して、上記
   オブジェクトを呼出すステップと、 上記オブジェクト・アドレスを使用して上記オブジェク
   トをアクセスするステップと、 上記オブジェクトに記憶されるインタフェース・テーブ
   ル・アドレスを使用して、該オブジェクトが継承する第
   １のクラスに対応する第１のインタフェース・テーブル
   をアクセスするステップと、 上記第１のインタフェース・テーブルに記憶され、上記
   レベルによって決定される第１のメソッド・テーブル・
   アドレスを使用して、上記第１のクラスに関連する第１
   のメソッド・テーブルをアクセスするステップと、 上記メソッド・プログラム・オフセットを使用して、第
   １のメソッド・シグニチャをアクセスするステップと、 上記第１のメソッド・シグニチャが上記呼出しシグニチ
   ャに合致しないことを判断するステップと、 上記第１のインタフェース・テーブルに含まれるロケー
   ション情報を使用し、該オブジェクトが継承する第２の
   クラスに対応する第２のインタフェース・テーブルをア
   クセスするステップと、 上記第２のインタフェース・テーブルに記憶され、上記
   レベルによって決定される第２のメソッド・テーブル・
   アドレスを使用して、上記第２のクラスに関連する第２
   のメソッド・テーブルをアクセスするステップと、 上記メソッド・プログラム・オフセットを使用し、第２
   のメソッド・シグニチャをアクセスするステップと、 上記第２のメソッド・シグニチャが上記呼出しシグニチ
   ャに合致することを判断するステップと、 上記メソッド・プログラム・オフセットを使用し、メソ
   ッド・プログラム・アドレスをアクセスするステップ
   と、 上記メソッド・プログラム・アドレスを使用して、上記
   メソッド・プログラムを呼出すステップと、 を含む方法。
4. 【請求項４】上記呼出しステップが、上記メソッド・プ
   ログラムに、上記オブジェクトに記憶されるオブジェク
   ト・インスタンス変数をアクセスするために上記メソッ
   ド・プログラムにより使用される上記オブジェクト・ア
   ドレス及びデータ・オフセットを供給するステップを含
   む、 請求項３記載の方法。
5. 【請求項５】複合データ構造を生成及び記憶する装置で
   あって、 クラス・オブジェクトを生成する手段と、 上記オブジェクトが継承する第１及び第２のクラスに対
   応する第１及び第２のインタフェース・テーブルを生成
   する手段と、 上記第１のクラスに関連する第１及び第２のメソッド・
   テーブル並びに上記第２のクラスに関連する第３のメソ
   ッド・テーブルを生成する手段と、 上記第１のインタフェース・テーブルのロケーション情
   報を上記クラス・オブジェクト中に記憶することによっ
   て、上記第１のインタフェース・テーブルを上記クラス
   ・オブジェクトに接続する手段と、 上記第２のインタフェース・テーブルのロケーション情
   報を上記第１のインタフェース・テーブル中に記憶する
   ことによって、上記第２のインタフェース・テーブルを
   上記第１のインタフェース・テーブルに接続する手段
   と、 上記第１及び上記第２のメソッド・テーブルのロケーシ
   ョン情報を上記第１のインタフェース・テーブルに記憶
   することによって、上記第１及び上記第２のメソッド・
   テーブルを上記第１のインタフェース・テーブルに個別
   に接続する手段と、 上記第３のメソッド・テーブルのロケーション情報を上
   記第２のインタフェース・テーブルに記憶することによ
   って、上記第３のメソッド・テーブルを上記第２のイン
   タフェース・テーブルに接続する手段と、 所定のメソッド・プログラムのロケーション情報を上記
   第１、上記第２及び上 記第３のメソッド・テーブルにそ
   れぞれ記憶することによって、上記メソッド・プログラ
   ムを各上記メソッド・テーブルに個別に接続する手段
   と、 を含む装置。
6. 【請求項６】上記クラス・オブジェクトのインスタンス
   の生成手段が、 インスタンス変数定義を生成する手段と、 上記インスタンス変数定義を上記クラス・オブジェクト
   に配置する手段と、 を含む、請求項５記載の装置。