JP2002501230A - プログラム・フロー方法及びプログラム・コンポーネント・システム拡張方法 - Google Patents

プログラム・フロー方法及びプログラム・コンポーネント・システム拡張方法

Info

Publication number
JP2002501230A
JP2002501230A JP2000527884A JP2000527884A JP2002501230A JP 2002501230 A JP2002501230 A JP 2002501230A JP 2000527884 A JP2000527884 A JP 2000527884A JP 2000527884 A JP2000527884 A JP 2000527884A JP 2002501230 A JP2002501230 A JP 2002501230A
Authority
JP
Japan
Prior art keywords
component
data
program
program flow
docking
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
JP2000527884A
Other languages
English (en)
Inventor
ダブリュー ノルベルト カスト
Original Assignee
エイコス インターナショナル リミテッド
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Priority claimed from DE19807191A external-priority patent/DE19807191A1/de
Application filed by エイコス インターナショナル リミテッド filed Critical エイコス インターナショナル リミテッド
Publication of JP2002501230A publication Critical patent/JP2002501230A/ja
Pending legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/30—Creation or generation of source code

Landscapes

  • Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Stored Programmes (AREA)
  • Debugging And Monitoring (AREA)
  • Circuits Of Receivers In General (AREA)

Abstract

(57)【要約】 【課題】 柔軟で拡張性に優れたプログラム・コンポーネント・システム。 【解決手段】 ラン・タイム・システム(14)と若干のコンポーネント(20,20',…）を有するプログラム・コンポーネント・システムにおいて、第２コンポーネント(20'）にて定義されたインターフェースと独立な第１コンポーネント(20)における第２コンポーネント(20') に関するデータ取得を含み、ラン・タイム・システム(14)で転送する。第２コンポーネント(20') にて定義されたインターフェースと独立な第２コンポーネント(20') における第１コンポーネント(20)に関するデータの取得も含む。プログラム・コンポーネント・システムを追加コンポーネントの回りに拡張するには、追加コンポーネントに対しドッキング・ポイントをサーチし、少なくとも１つのドッキング・ポイントが見つかった各コンポーネント(20,20' …）が、各ドッキング・ポイントに関するコール情報を登録する。

Description

【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明はプログラム・フローに関するとともに、「コンポーネント・ウェア」
とも呼ばれるプログラム・コンポーネント・システムの設定に関する。特に本発
明は、プログラム・コンポーネント・システムにおけるプログラム・フロー方法
と、このようなシステムを拡張するための方法に関する。
【０００２】
【従来の技術】
オブジェクト・スペクトラム誌１９８７年第３号、８６−８９頁に発表された
ミヒャエル・シュタルの記事「コンポーネント・ウェア−コンポーネントからア
プリケーションへ」に、プログラム・コンポーネント・システムの基礎が説明さ
れている。これまで非常に時間のかかっていたソフトウェア製造を、与えられた
コンポーネントを単純に「結線」することで置換えることを狙いとしている。こ
れらのコンポーネントは、コンポーネントの製造者に対してコンポーネントの基
礎となるソース・コードの詳細開示を要求しないでも、様々なコンテクストで適
用できるものと期待されている。
【０００３】 コンポーネント・ウェアの作成に対して、ディストリビューション・プラット
フォーム、コンテナー・プラットフォーム及び複合文書（composite documents ）テクノロジーなどの、相互に補完しあう幾つかのテクノロジーが知られている
。
【０００４】 ディストリビューション・プラットフォームにおいては、コンピュータの境界
を超えてコンポーネントを分配させたり、コンポーネント間のコミュニケーショ
ンを行うための決まりやツールが提供される。以下のディストリビューション・
プラットフォームは、ほどんど業界の標準となっている：Microsoft（マイクロ ソフト社）によるDCOM（Distributed Component Object Module）、OMG（Object
Management Group）によるCOBRA（Common Object Request Broker Architectur
e）、JavaSoftによるJAVA-RMI（Remote Method Invocation）。
【０００５】 コンテナー・プラットフォームは、予め決められた問題やタスクの分野（在庫
管理、経理など）を少なくとも部分的にカバーするソフトウェア・コンポーネン
トのソリューション指向の一群と、ソリューションによらないミドルウェア（グ
ラフィカル・ユーザー・インターフェースなど）を含んでおり、コンポーネント
とユーザーの間のやり取りができるるようになっている。
【０００６】 複合文書テクノロジーは、異なるアプリケーションの統合を考慮している。複
合文書は、幾つかのコンポーネント（表、グラフィック、テキストなど）と、各
コンポーネントを担当する１つのアプリケーションを含んでいる。複合文書に対
する既知のアーキテクチャーとしては、例えばMicrosoft によるActiveX 、ClLa
b によるOpenDoc 、及びJavaSoftによるJava Beansなどがある。
【０００７】
【発明が解決しようとする課題】
しかしながら、これら既存の方法には、あるコンポーネントの機能がコンポー
ネント・メーカーが予め定義したインターフェースを経由してしか使用できない
という問題がある。特に、これらのインターフェースは、コンポーネント・メー
カーが予め定義した方法あるいはパラメータである。ソース・コードは一般に入
手できないので、コンポーネントの機能をコンポーネント・メーカーとは独立に
拡張する手段はない。単にパラメータ化が提供される可能性があるというだけで
は、コンポーネントの機能拡張にはならない。何故なら、全ての可能な機能がコ
ンポーネント・メーカーから既に最初から提供されなければならないからである
。
【０００８】 従って、本発明の目的は取り分けフレキシブルで拡張性に優れたプログラム・
コンポーネント・システムを提供することである。特に、コンポーネントの機能
は、拡張するコンポーネントのソース・コードの知識を要求せずに修正または拡
張できなければならない。
【０００９】
【課題を解決するための手段】
請求項１に係る発明は上記課題を解決するプログラム・フロー方法であり、 ランニング・タイム・システム（１４）及びそれぞれ１つのプログラム部分を有
する幾つかのコンポーネント（２０、２０' 、…）から成るプログラム・コンポ
ーネント・システムにおけるプログラム・フロー方法であって、 第１のコンポーネント（２０）のプログラム部分（２２）の実行中に、 ａ）ランニング・タイム・システム（１４）によって、第２のコンポーネント（
２０’）のデータを前記第１コンポーネント（２０）内に、前記第２コンポーネ
ント（２０’）においてプログラムで定義されたインターフェースと独立に取得
するステップ、及び ｂ）ランニング・タイム・システム（１４）によって、前記第１コンポーネント
（２０）のデータを前記第２コンポーネント（２０’）内に、前記第２コンポー
ネント（２０’）においてプログラムで定義されたインターフェースと独立にデ
ータを処分するステップ を含むことを特徴とする。
【００１０】 請求項２に係る発明は、請求項１において、 データ取得中に転送されるデータが前記第２コンポーネント（２０’）のメモリ
ー・イメージ部分（２８）から前記第１コンポーネント（２０）の転送データ部
分（３４）に転送されること、及び、データ処分中に転送されるデータが前記第
１コンポーネント（２０）の転送データ部分（３４）から前記第２コンポーネン
ト（２０’）のメモリー・イメージ部分（２８）に転送されること、のうち少な
くとも一方が行われることを特徴とするプログラム・フロー方法である。
【００１１】 請求項３に係る発明は、請求項１又は２おいて、 前記データ取得及びデータ処分の少なくとも一方が前記第２コンポーネント（２
０’）の協力なしに実施されることを特徴とするプログラム・フロー方法である
。
【００１２】 請求項４に係る発明は、請求項１から３いずれかにおいて、 前記第２コンポーネント（２０’）が前記データ取得中及びデータ処分中の少な
くとも一方ではアクティブでないことを特徴とするプログラム・フロー方法であ
る。
【００１３】 請求項５に係る発明は、請求項１から４いずれかにおいて、 前記第２コンポーネント（２０’）の前記データ転送領域（３４）が前記データ
取得及び該データ処分中はセービング領域に配置されることを特徴とするプログ
ラム・フロー方法である。
【００１４】 請求項６に係る発明は、請求項１から５いずれかにおいて、 前記第２コンポーネント（２０’）のローカル・データ及び持続性のないデータ
のうち少なくと一方が前記データ取得中及びデータ処分中の少なくとも一方で転
送されることを特徴とするプログラム・フロー方法である。
【００１５】 請求項７に係る発明は、請求項１から６いずれかにおいて、 前記第１コンポーネント（２０）のプログラム部分（２２）の実行中に前記第１
コンポーネント（２０）のどのデータがデータ処分を必要とするかを示すウェイ
ティング・リストが作成されることを特徴とするプログラム・フロー方法である
。
【００１６】 請求項８に係る発明は、請求項１から７いずれかにおいて、 コールされたコンポーネント（２０、２０’、…）が、該コールするコンポー
ネント（２０、２０’、…）において定義されたデータ・フィールド及び使用可
能なデータ・フィールドのうち少なくとも一方で構成されるアクセス・データ領
域（３０）に直接アクセスできることを特徴するプログラム・フロー方法である
。
【００１７】 請求項９に係る発明は、請求項１から８いずれかにおいて、 コンポーネント（２０、２０’、…）のコールが、該コールするコンポーネント
のドッキング・ポイントに含まれるコール情報によってトリガーされることを特
徴とするプログラム・フロー方法である。
【００１８】 請求項１０に係る発明はプログラム・コンポーネント・システム拡張方法であ
り、 幾つかのコンポーネント（２０、２０’、…）を含むプログラム・コンポーネン
ト・システムをもう１つの別コンポーネントによって拡張する方法であって、 ａ）前記プログラム・コンポーネント・システムの前記別コンポーネントに対す
るドッキング・ポイント、即ち、前記別コンポーネントの定義によって決定され
る遺伝パラメータに対応するドッキング・ポイントをサーチするステップ、及び ｂ）少なくとも一つのドッキング・ポイントが見つかったプログラム・コンポー
ネント・システムのコンポーネント（２０、２０’、…）を、見付かった各ドッ
キング・ポイントにおいて前記別コンポーネントに関するコール情報をエンター
することによって修正するステップ を含むことを特徴とする。
【００１９】 請求項１１に係る発明は、請求項１０に記載において、 以前のコンポーネント（２０、２０’、…）の全てのインターラクション・イン
ターフェースが潜在的なドッキング・ポイントとして予め定義されていることを
特徴とするプログラム・コンポーネント・システム拡張方法である。
【００２０】 請求項１２に係る発明は、請求項１０において、 以前のコンポーネント（２０、２０’、…）によって参照される全てのインター
アクション・スクリーン・フィールド、全てのプリント・マスク・アウトプット
・フィールド及び持続性のあるデータ上の全てのアクセス操作のうち、少なくと
も１つが潜在的なドッキング・ポイントとして予め定義されていることを特徴と
するプログラム・コンポーネント・システム拡張方法である。
【００２１】 請求項１３に係る発明は、請求項１０から１２いずれかにおいて、 前記コール情報をドッキング・ポイントにエンターすることにより、前記コール
情報がエンターされたコンポーネントからの前記別コンポーネントのコールが準
備されることを特徴とするプログラム・コンポーネント・システム拡張方法であ
る。
【００２２】 請求項１４に係る発明は、請求項１０から１３いずれかにおいて、 前記別コンポーネントの定義から少なくとも１つのバイナリー・オブジェクトが
生成される、という追加ステップ を含むことを特徴とするプログラム・コンポーネント・システム拡張方法である
。
【００２３】 請求項１５に係る発明は、請求項１４ににおいて、 見つかった各ドッキング・ポイントから最大１つのバイナリー・オブジェクトが
生成されることを特徴とするプログラム・コンポーネント・システム拡張方法で
ある。
【００２４】 請求項１６に係る発明は、請求項１５において、 各バイナリー・オブジェクトを生成している間に、下層にあるドッキング・ポイ
ントを含むプログラム・コンポーネント・システムの１つのコンポーネント（２
０、２０’、…）においてメモリーの割り当てが考慮されていることを特徴とす
るプログラム・コンポーネント・システム拡張方法である。
【００２５】
【発明の実施の形態】
次に、本発明の実施形態例を説明する。
【００２６】 まず、本発明によれば、請求項１の特徴を持つ、プログラム・コンポーネント
・システムにおてるプログラム・フロー方法、及び、請求項１０の特徴をもつ、
プログラム・コンポーネント・システムを拡張するための方法によって、本発明
の目的が達成される。
【００２７】 以下に、拡張されるべきコンポーネントを「基本コンポーネント」と呼び、追
加されるべき新しいコンポーネントを「拡張コンポーネント」と呼ぶ。
【００２８】 本発明は、プログラマーが定義する基本コンポーネント内の拡張インターフェ
ースの要求を断念することによって、基本コンポーネントのほとんど無限な拡張
性を達成するための基本的なアイデアから出発している。拡張コンポーネントの
メーカーは、むしろ、拡張コンポーネントがどのようにして基本コンポーネント
と相互に作用しあうかを定義している。
【００２９】 この基本的なアイデアは、コンピュータ・サイエンスにおける伝統的な原則（
カプセル化、情報ハイディングなど）を逆転することにある。しかし驚くべきこ
とに、伝統的な確立された原則を放棄することによってこそ、プログラマーでな
い人でも比較的大規模なソフトウェア・システムを驚くほど短時間で完成できる
ようになるのである。
【００３０】 基本コンポーネントのプログラマーよりもむしろ拡張コンポーネントのプログ
ラマーに拡張インターフェ−スを定義させるという本発明による考え方では、プ
ログラム・フロー中、及び、既存のプログラム・コンポーネント・システムに拡
張コンポーネントを導入する間に、使用される思考パターンを逆転させる。これ
ら２つの場合が、独立な請求項１及び１０の対象である。
【００３１】 プログラム・フロー中は、コンポーネントどうしが、それらを処理して結果を
生み出すため、互いからデータを必要とするのが普通である。コールされた手順
に対してコールする場所からデータを与え、再エントリー（リターン・ジャンプ
）時に結果を戻す方法が知られている。しかし、この方法ではコール手順のプロ
グラマーが予めコール・インターフェースを定義する必要がある。
【００３２】 これと対称的に本発明は、適当なランニング・タイム・システムを用いること
によって、コールされたコンポーネントが要求データをフェッチ又は獲得できる
ようにする。このプロセスを今後、「データ取得」と呼ぶことにする。データが
そこから取得されるコンポーネントにおいては、プログラマーが予め定義する特
別なインターフェースは必要ない。従って、結果を他のコンポーネントの適当な
場所にストアすることは、コールされたコンポーネントのジョブである。このプ
ロセスを今後、「データ処分」と呼ぶことにする。この場合も、プログラマーが
データ処分用に特別なインターフェースを提供しておく必要はない。この場合、
データ・フィールドや変数（必要ならタイプ仕様や更なるパラメーターなどを含
めて）を単に定義したり宣言するだけでは、「インターフェース」とは見なされ
ない。これに対してインターフェースとは、適当なランニング・タイムでデータ
転送を開始したり可能にするためにプログラマーがコンポーネント・スクリプト
に明確に導入する必要がある手順指示などのことである。
【００３３】 拡張コンポーネントを既存のコンポーネント・システムに付与する時は、既知
の原則を逆転することになる。通常はプログラム・コンポーネント・システムの
以前のコンポーネントが拡張によっても変更されないことが期待される。逆に、
本発明では、拡張コンポーネントに対するドッキング・ポイントがプログラム・
コンポーネント・システムにおいてサーチされること、及び、少なくとも１つの
ドッキング・ポイントが見つかったプログラム・コンポーネント・システム内の
コンポーネントが、見つかった各ドッキング・ポイントにおいて新しいコンポー
ネントのためのコール情報を挿入することによって、変更されることを規定して
いる。かくして、プログラム・コンポーネント・システム全体における各コンポ
ーネントが修正可能である。
【００３４】 本発明によるソリューションによって、プログラム・コンポーネント・システ
ムの機能を、以前のコンポーネントのプログラマーにコンポーネント拡張の可能
性を予め計画、提供あるいは予想させることなしに、広く拡張することが可能と
なる。これは、以前に知られていたプログラム・コンポーネント・システムと比
較して実質的な進歩である。
【００３５】 本明細書では、「ランニング・タイム・システム（ラン・タイム・システム）
」という用語は全てのジェネリックなルーチン、即ち、コンポーネントのプログ
ラマーが明確に与えないルーチンをカバーする意味である。ここでランニング・
タイム・システムは、コンポーネントに含まれる部分を含むこともある。例えば
、データ転送を実行するランニング・タイム・システムの部分は、個別のコンポ
ーネントにシフトさせても良い。
【００３６】 データ取得及びデータ処分の間に転送されるデータは一般的にアクセスできず
に、データをそこから取得したりデータをその中に処分するするコンポーネント
に関連付けることが望ましい。これらのデータは、好ましい実施例においては、
該当するコンポーネントがアクティブでない間に転送される。特に、このコンポ
ーネントは、データ取得およびデータ処分時に、通常のワーキング・メモリーか
ら外部の場所に転送できる。ローカル及び／又は持続性のない（non-persistent
）データがデータ取得時及び／又はデータ処分時に転送されること、言いかえれ
ば特にグローバルに利用できるデータは、データ取得時及び／又はデータ処分時
に転送されないことが望ましい。
【００３７】 好ましくは、データ取得及び／又はデータ処分は、データをそこから取得する
コンポーネント、あるいはそこにデータを処分するコンポーネントと協調せずに
実施される。例えば、処分するコンポーネントとランニング・タイム・システム
だけがデータ処分中に寄与するように規定することができる。好ましい実施例で
は、データをアーカイブとして保存するコンポーネントが影響を受けないように
なっている。
【００３８】 好ましくは、コンポーネントを実行している時は、データ処分に必要なデータ
・フィールドをリストに記載しておく。特に、このデータ・フィールドは、デー
タ取得によってコンテンツが決まっているデータ・フィールドであって、しかも
書き込みアクセスが実行されているデータ・フィールドとすることができる。
【００３９】 更に、コールされたコンポーネントは、コールするコンポーネント内で定義さ
れているか、入手（利用）可能なデータ・フィールドを読んだり書いたりするこ
とによって、直接アクセスできることが望ましい。かくして、上記の２つのコン
ポーネント間でほとんどインターフェースのいらないデータ転送が可能となる。
コンポーネントのコールは、コール情報で、例えばコールするコンポーネントの
ドッキング・ポイントに含まれるコール・メッセージでトリガーすることが望ま
しい。コール情報を受入れることができるドッキング・ポイントを使用すること
によって、取り分けフレキシブルな機能拡張が可能となる。
【００４０】 望ましくは、コンポーネントの全てのインターアクション・インターフェース
を潜在的なドッキング・ポイントとして予め定義しておく。このようなインター
ラクション・インターフェースは、インプット・フィールドやスイッチ・パネル
のようなインターアクション・スクリーン・フィールドでも良い。更に、プリン
ト・マスクの全てのアウトプット・フィールド、及び／又は、パーシステント（
persistent）なデータ（例えば、ファイルまたはデータ・ベースを開く、読む、
書く）上の全てのアクセス・オペレーションをインターアクション・インターフ
ェースとして提供することもできる。好ましい実施例では、インターラクション
・インターフェースは、コンポーネントのプログラマーが予め決定することもで
きるようになっている。
【００４１】 プログラム・コンポーネント・システムに別のコンポーネントを追加する時に
は、可能な全てのドッキング・ポイントが（既に存在しているコンポーネントの
ソース・コードを知らないでも）自動的に同定されることが望ましい。従って、
プログラミングの労力が殆ど無しで拡張を実施できる。更に、適当なコール情報
を少なくとも一つのドッキング・ポイントに入れることが好ましい。
【００４２】 望ましい実施例では、プログラム・コンポーネント・システムのコンポーネン
ト拡張方法に、少なくとも１つのコンポーネントをバイナリー・オブジェクトと
して生成する更なるステップが含まれている。特に、ちょうど１つのまたは最大
１つのバイナリー・オブジェクトを、見つけられた各ドッキング・ポイントに対
して生成できる。このバイナリー・オブジェクトでは、プログラム・コンポーネ
ント・システムのメモリー割り当てを、後のプログラム実行時に考慮することが
できる。
【００４３】 更なる好ましい実施例は従属請求項の主題である。
【００４４】 次に、本発明をより良く理解するために、本発明の実施例と若干の修正例を図
面を参照しながらより詳しく説明する。
【００４５】 図１(FIG１）は、実行中のプログラム・コンポーネント・システムの構造を図
解したものである。従来のWindowsオペレーション・システムのようなオペレー ティング・システム１０が、DCOMやCOBRAのようなディストリビューション・プ ラットフォーム１２によって拡張されている。このディストリビューション・プ
ラットフォーム１２上に、「ミドルウェア」とも呼ばれるランニング・タイム・
システム(running time system) １４が配置されている。オペレーティング・シ
ステム１０は、ランニング・タイム・システム１４で管理され且つ使用されるワ
ーキング・メモリ領域１６を持つ。１つの実施例では、ディストリビューション
・プラットフォーム１２が省略され、ランニング・タイム・システム１４がオペ
レーティング・システム１０上に直接配置される。プログラム・コンポーネント
・システムは、PC互換機のような市販のコンピュータで実行することができる。
【００４６】 ランニング・タイム・システム１４の他にプログラム・コンポーネント・シス
テムは、幾つかのコンポーネント２０、２０’、２０''、２０''' をバイナリー
・オブジェクトの形で含むコンテナー環境（container environment)１８を備え
ている。コンポーネント２０、２０’、２０''、２０''' はプログラム・コンポ
ーネント・システムの挙動を決定する。これらのコンポーネントは、例えばユー
ザーが起こしたアクションの機能として、ランニング・タイム・システム１４に
よってコールされる。
【００４７】 図２(FIG２）に図解したように、バイナリー・オブジェクト形式の１つのコン
ポーネント２０は、幾つかの部分、即ち１つのプログラム部分２２、１つのテー
ブル（表）部分２４、１つのディレクトリー部分２６及び１つのメモリー・イメ
ージ部分２８を含む。
【００４８】 プログラム部分２２は解釈可能なコード(interpretable code)コードを含んで
いる。このコードは、実行時にランニング・タイム・システム１４によって解釈
され、コンポーネント２０の挙動を決定する。プログラム部分２２に含まれるこ
のコードは、プログラム実行時に効率的に実行できる中間フォーマット(interme
diate format) で書かれている。別の幾つかの実施例では、オペレーティング・
システム１０の管理下で直ちに実行できるように、コードの適当な翻訳(compila
tion)gがなされる。
【００４９】 表部分２４では、コードのコンフィギュレーション可能な特性やパラメータの
実行時間表がストアされる。これは例えば、ウィンドウ・サイズやスクリーン表
示の色に関する情報や、印刷表示するための情報である。更に実行時間表は、メ
モリー割り当てについてのマネージメント情報を含んでいる。ディレクトリー部
分２６は、ドッキング・レファレンスのディレクトリー、メモリー・ディレクト
リー、データ転送ディレクトリー、及びメソッド・ディレクトリーを含む。
【００５０】 メモリー・ディレクトリーは、コンポーネント内の使用可能なメモリー・フィ
ールドに対する指定、メモリー・フィールドに関する情報並びにそれらに対する
レファレンス（より詳しくは、オフセット値または移動（displacement）値）を
含む。メソッド・ディレクトリーはコンポーネントによって提供されるメソッド
一覧表（list）を含む。これら２つのディレクトリーは、バイナリー・コードに
含まれており、コンポーネントのソース・コードを知らないでもコンポーネント
（コンポーネント・スクリプト）の機能拡張が可能である。メモリー・ディレク
トリーに含まれる全てのメモリー・フィールドは、他の任意のコンポーネントか
らデータ取得やデータ処分の操作でアクセスすることができ、読んだり、修正し
たり、記述することができる。ここで説明する実施例では、プログラマーが個々
のメモリー・フィールドを権限のない無断アクセスから保護することはできない
。実行時にデータ取得およびデータ処分のために必要な情報は、データ転送ディ
レクトリーに含まれている。
【００５１】 メモリー・イメージ部分２８では、実行時間表のマネージメント情報で境界が
与えられる３つの隣接する領域が用意されている。最初のデータ領域３０を、以
下にアクセス・データ領域と呼ぶ。これはコール階層（hierarchy)中の高い水準
にあるコンポーネントから出されるデータのために用意されている。これらのデ
ータは、プログラム化されたデータ転送を必要とせずに、コールされたコンポー
ネントによって直ちに読み、処理し、書くことが出来る。手順プログラミング言
語（procedural programming language)のコンテクストでは、これは静的により
高い水準の手順に定義されている変数に直接アクセスできるということと、ほぼ
同意義である。アクセス・データ領域３０のサイズは、コンポーネント２０を具
体化する間は固定される。これが可能な理由は、バイナリー・オブジェクト・フ
ォーマットの各コンポーネント２０には１つだけの可能なコール位置（location
）（１つのドッキング・ポイント）が関連付けられているためである。コンポー
ネント２０のアクセス・データ領域３０のサイズは、アクセス・データ領域とコ
ールするコンポーネントのローカル・データ領域（後述）の量の合計である。
【００５２】 コンポーネント２０のメモリー・イメージ部分２８における２番目のデータ領
域として、ローカル・データ領域３２が用意されている。このデータ領域はアク
セス・データ領域に隣接している。これはコンポーネント２０内で定義されたデ
ータを含んでいる。このような定義は、コンポーネント内で直接行われるか、ま
たはスクリーン・マスクやプリント・フォーマット上のレファレンスなどの手段
によって間接的に行われる。手順プログラミング言語のコンテクストでは、ロー
カル・データ領域３２は、およそ１つの手順のローカル変数を含んでいる。
【００５３】 最後に、メモリー・イメージ部分２８における３番目のデータ領域として、転
送データ領域３４が用意されている。転送データ領域は、プログラム実行時にデ
ータ取得の原則に従って別のコンポーネントから取得されデータ処分の原則に従
ってそのコンポーネントに処分されたデータを、直ちにストアするために用意さ
れている。
【００５４】 コンポーネント２０を具体化（instantiate)する時に、すなわちコンポーネン
ト・スクリプトから少なくとも１つのバイナリー・オブジェクトに翻訳する時に
、アクセス・データ領域３０と転送データ領域３４は、実行時にいずれにしても
上書きされるので、定義された値でカバーする必要はない。ローカル・データ領
域３２は、個々のデータ・タイプに対して予め定めた標準値で満たされる。プロ
グラム・コンポーネント・システムの実行時に、コンポーネント２０の３つのデ
ータ領域３０、３２及び３４は、追加のコンポーネントがコールされる度に現在
のシステム条件を直ちにストアするために、そしてこの条件を（ローカル・デー
タ領域３２と転送データ領域３４に関して）リターン・ジャンプにおいて部分的
にカバーするために使用される。
【００５５】 コンポーネントを作成するために、プログラマーはジェネレータ・システムに
よる自動翻訳に適したコンポーネント・スクリプトを作成する。コンポーネント
の具体化（instantiation)とも呼ばれるこの翻訳プロセスを、以下により詳しく
説明する。コンポーネント・スクリプトは、作成するコンポーネントの定義を構
成している。これは、コンポーネントの解釈可能なコードとして翻訳される指示
行（instruction lines)を含む。使用するプログラミング言語は、それ自体で既
知であり、オブジェクト指向の原則に基づいている。更に、コンポーネント・ス
クリプト検査員（examiner）が予想する拡張のためのドッキング・ポイントを決
定する指示を含むこともできる。また、データやパラメータは、例えばデータを
視覚的に表示するためのパラメータや許容入力データの列挙などを、コンポーネ
ント・スクリプトにオプションとして含めることも出来る。更に、コンポーネン
ト・スクリプトは「外部（foreign)」プログラムをコールするための指示を含ん
でいても良い。実行時に、例えばCOBOL などの対応するプログラムをスタートす
るのである。このプログラム自体がプログラム・コンポーネント・システムのイ
ンターフェースを使用でき、更なるコンポーネントをスタートさせることが出来
る。
【００５６】 更に、コンポーネント・スクリプトは使用するスクリーン・マスクやフォーマ
ット、及びプリント・フォーマットに関するレファレンスを含んでも良い。この
ようなスクリーン・マスクやプリント・フォーマットは、適当なグラフィック・
ツールを用いて前もって開発される。ツール（「GUI ビルダー」）は、コンポー
ネントを具体化する各プロセスにおいてアクセスできる幾つかのグローバル・デ
ィレクトリーを作成する。これらは第１に、使用可能なスクリーン・マスクやプ
リント・フォーマットのグローバル・ディレクトリーであり、第２にこれらのマ
スクやフォーマットによって与えられるドッキング・ポイントのディレクトリー
であり、そして第３に定義されたインプット・フィールドやプリント・フィール
ドにおいて期待されるラベルやデータのタイプのディレクトリーである。
【００５７】 コンポーネント・スクリプトが拡張コンポーネント、すなわち既存のコンポー
ネント（基本コンポーネント）を拡張すると想定されているコンポーネントの定
義である場合、コンポーネント・スクリプトもまた、コンポーネント拡張のため
の望ましいドッキング・ポイントを指定する遺伝（inheritance)パラメータを含
んでいる。
【００５８】 遺伝パラメータは、以下に説明するように、複数の基本コンポーネントと複数
のドッキング・ポイントを定義することができる。
【００５９】 ドッキング・ポイントは、ジェネリック・ロケーション、あるいはプログラマ
ーが示す基本コンポーネント内のロケーションとすることができ、このようなロ
ケーションでは拡張コンポーネントのためのコール情報を挿入することができる
。バイナリー・オブジェクト・フォーマットにおけるコンポーネントのドッキン
グ・ポイントは自動的に識別でき、基本コンポーネントのソース・コードを知ら
ないでもコンポーネントを拡張することができる。
【００６０】 この場合の実施例では、４種類のドッキング・ポイントが提供される。まず、
全てのインプット・フィールドおよびスクリーン・マスクにおけるその他の操作
エレメント（ボタン、スイッチング・エリアなど）が、基本コンポーネントがア
クセスするドッキング・ポイントとして提供される。例えば、これによってユー
ザーが基本コンポーネントのインプット・フィールドとのインターアクションを
実施する時に、値をインプットしたり、インプット・フィールドをアクティベー
トしたり、マウス・ポインターをインプット・フィールド上に動かすなどして、
コンポーネントの拡張が常にコールされるようにすることができる。基本コンポ
ーネントのプログラマーは、必ずしも明確に（explicitly）この可能性を準備す
る必要がない。同様に、全てのプリント・マスク・アウトプット・フィールドを
、例えば印刷すべき表のアウトプット値が修正できるように、ドッキング・ポイ
ントとして使用することができる。
【００６１】 更に、基本コンポーネントの持続的（persistent）データ（データ・アクセス
やデータ・ベース・アクセスなど）に関する全ての操作は、ドッキング・ポイン
トとして提供される。この場合もまた、拡張コンポーネントは基本コンポーネン
トのプログラマーが明確に示さないでも、「中間で接続」できる。最後に、以前
に述べた通り、コンポーネントはプログラム・フローの任意の位置においてプロ
グラマーが定義したドッキング・ポイントを含むことができる。別の実施例では
、追加のあるいは別のドッキング・ポイントを含んでいる。
【００６２】 本実施例では、各ドッキング・ポイントは複数のドッキング・ロケーション（
「スロット」）で構成されている。こうして、幾つかのコンポーネント拡張を一
つのドッキング・ポイントに接続できる。インプット・フィールドに関連したド
ッキング・ポイントでは、例えば一つの主ドッキング・ロケーションと５個の副
ドッキング・ロケーションがある。
【００６３】 主ドッキング・ロケーションにエンターしたコンポーネント拡張は、ユーザー
がインプット・フィールドをアクティベートする時に常にコールされる。オプシ
ョンとして、このコンポーネントは、インプット・フィールドがディスプレイさ
れている間、すなわちユーザー・アクションの前に、毎回コールすることもでき
る。逆に、副（サブ）ドッキング・ロケーションを、例えば、特定のファンクシ
ョン・キー操作やユーザーの別なアクションに関連付けることも可能である。プ
リント・マスク・アウトプット・フィールドの場合、ドッキング・ポイントのド
ッキング・ロケーションのコントロールは、例えば、印刷プロセスの開始時にユ
ーザー・インプットによって決定することができる。別な実施例では、別なコー
ル戦略や異なる個数のドッキング・ロケーション（例えば、ドッキング・ポイン
ト当り１つ）が可能である。
【００６４】 図３(FIG３）では、コンポーネントの具体化がより詳しく説明されている。上
述のように、「具体化」とはコンポーネント・スクリプトを少なくとも１つのバ
イナリー・オブジェクトに翻訳するという意味である。この実施例では、見つか
ったドッキング・ポイントに対してちょうど１つのコンポーネントがバイナリー
・オブジェクトとして作成される。
【００６５】 ジェネレータ・システムによって自動的に実施される具体化プロセスは、コン
ポーネント・スクリプトを読むことから始まる（ステップ４０）。ステップ４２
で、最初のドッキング・ポイントをサーチする。翻訳するコンポーネント・スク
リプトが遺伝パラメータとしてコンテナー識別のみを含む場合は、コンテナー環
境１８（図１参照）におけるジェネリック・ドッキング・ポイントを占有する。
こうすることで、「ルート・コンポーネント」、即ちどのコンポーネント拡張も
構成しないコンポーネントが具体化できる。
【００６６】 しかし、翻訳するコンポーネント・スクリプトが「真の（リアル）」遺伝パラ
メータを含む場合は、このパラメータがコンポーネント拡張に提供されるドッキ
ング・ポイントを決定する。このためには幾つかの可能性がある。例えば、スク
リーン・マスクのインプット・フィールドがドッキング・ポイントとして使用さ
れる場合、遺伝パラメータは基本コンポーネントを指定する他に、フィールド名
およびドッキング・ポイント内の希望するドッキング・ロケーション（「スロッ
ト」の番号）の両方を示すことができる。その代りに、フィールド名だけをエン
ターし、必要ならば「スロット」番号を遺伝パラメータに入れることも可能であ
る。この場合、ドッキング・ポイントとして、プログラム・コンポーネント・シ
ステム内で現在使用できるバイナリー・コードの全てのロケーションが使用され
、これらのバイナリー・コードでは上記のフィールドをレファレンス・フィール
ドとして使用するスクリーン・フォーマットが参照される。
【００６７】 最初のドッキング・ポイントが見つかったら（質問ステップ４４）、拡張コン
ポーネントをコールするための「メッセージ」のような適当なコール情報を、ド
ッキング・ポイントを含む基本コンポーネントにまずエンターする（ステップ４
６）。このために、基本コンポーネントをバイナリー・フォーマットで読み、拡
張コンポーネントに対するレファレンスを基本コンポーネントにエンターし、こ
のように修正されたバイナリー・オブジェクトを再びプログラム・コンポーネン
ト・システムに書き込む。このようにして、遺伝パラメータは、ドッキング・ポ
イントのどのドッキング・ロケーション（「スロット」）にコール情報をエンタ
ーするか、そしてどんなユーザー・アクションが拡張コンポーネントをコールす
るかを決定する。
【００６８】 見つかったドッキング・ポイントを含む基本コンポーネントを修正した後、こ
のドッキング・ポイントに関連した拡張コンポーネントがバイナリー・オブジェ
クトとして構成される（ステップ４８）。最初に、拡張コンポーネントのドッキ
ング・ポイントが決定され、コンポーネント３０のディレクトリー部分２６の対
応するディレクトリーにエンターされる（ステップ５０）。このために、拡張コ
ンポーネントのスクリプトによって参照される全てのスクリーン・マスクとプリ
ント・フォーマットが吟味される。更に、これらのマスクやフォーマットで定義
されるドッキング・ポイントのグローバル・ディレクトリーがアクセスされる。
ここに含まれる情報は、ドッキング・レファレンスとしてディレクトリー部分２
６にインポートされる。統合されたスクリーン・フィールドやプリント・フィー
ルドの名前の他に、これはフィールドのタイプや、関連するデータ値などのメモ
リー・スペース要求に関する情報でも良い。
【００６９】 更に、コポーネント・スクリプトがプログラマーによって示されるドッキング
・レファレンスのためにサーチされる（構造：INTERFACE-IS＜名称＞）。これら
のドッキング・レファレンスはディレクトリー部分２６によっても採用される。
最後に、コンポーネント・スクリプト（構造：例えばREAD＜エンティティの名称
＞）内のパーティネント（pertinent:持続的）なデータ上の全てのアクセス操作
に対して、対応するドッキング・レファレンスがディレクトリー部分２６に採用
される。
【００７０】 次のステップ５２では、ランニング・タイム・メモリー組織が具体化される。
このために、拡張コンポーネントが参照するスクリーン・マスクとプリント・フ
ォーマット内のフィールド名が最初に決定されるが、そのフィールド名は基本コ
ンポーネント内ではまだ決定されていないものである。アクセス・データ領域３
０のエントリーと対応しない限り、これらのフィールド名は拡張コンポーネント
のローカル変数と見なされる。全てのフィールド名が、ディレクトリー部分２６
のメモリー・ディレクトリーにエンターされる。更に、スクリーン・データとプ
リント・データを実行時にバッファ・メモリーから拡張コンポーネントのメモリ
ー領域（アクセス・データ領域３０またはローカル・データ領域３２または転送
データ領域３４）に転送するために、転送リストが作成される。この機能は、明
確にプログラミングしないでも実行時に自動的に実施される。
【００７１】 ステップ５２の一部として更に、コンポーネント・スクリプト内のスタティッ
ク（statical：静的）なメモリーの定義が処理される。基本コンポーネントが明
確に与えられているので、バイナリー・オブジェクト２０の３つのデータ領域３
０、３２、３４のサイズは、具体化の時点ですでに決定できる。更に、ディレク
トリー部分２６内のメモリー・ディレクトリーは完全に作成できる。
【００７２】 最初に、基本コンポーネントですでに定義されているコンポーネント・スクリ
プト内の静的メモリー定義（構造：INHERIT-DATA＜名称＞）がサーチされる。実
行時に、対応するデータ値がアクセス・データ領域３０内の基本コンポーネント
内と同じ場所（同じオフセットまたは移動値）に配置される。これは、基本コン
ポーネントのアクセス・データ領域３０によって占められるワーキング・メモリ
ー領域１６が、拡張コンポーネントがコールされる時にもまだ使用されるためで
ある。従って、基本コンポーネントに対応するエントリーは、メモリー・ディレ
クトリー内に受領される。これらのエントリーには、データ値の名称やタイプ、
およびフィールド長さや移動値が含まれる。
【００７３】 最後に、ローカル・データ領域３２に関連したコンポーネント・スクリプトの
静的メモリー定義が処理される。これらは、第１に、基本コンポーネントで定義
されていないメモリー・フィールドの定義であり、第２に、ローカル・ストレッ
ジが明確に与えられているメモリー定義である（構造：INHERIT-DATA-LOCAL＜名
称＞）。このようなメモリー定義に対しては、ローカル・メモリー領域３２にお
けるフリーなアドレスが決定され確保される。より詳しく言えば、現在のメモリ
ー水準に関して次に使用できる（空いている）アドレスが使用される（基本コン
ポーネントのメモリー占有状態に依存し、既に指定されている拡張コンポーネン
トのローカル・フィールドにも依存することがある）。これらのメモリー定義に
対しても、拡張コンポーネントのメモリー・ディレクトリーへの対応するエント
リーが受領される。
【００７４】 次のステップ５４では、実行時に発生する拡張コンポーネントのデータ取得と
データ処分が、メモリー部分２６にデータ転送メモリーを設定することによって
具体化される。このために、コンポーネント・スクリプト内のデータ取得および
データ処分の定義がサーチされる。これらの定義は次の形をしており、“INH"は
“inherit"（遺伝）を、“IME"は“import/export"（インポート／エクスポート
）を表している。 INH-DATA-IME＜データ取得とデータ処分を行うコンポーネントの識別＞ INTERFACE(インターフェース）＝＜フィールド名１＞、 ＜フィールド名２＞、 …、 ＜フィールド名ｎ＞ ENDTRANSFER(転送終了）
【００７５】 このような定義が見付かったら、扱ったコンポーネントのメモリー・ディレク
トリーが評価される。実行時にワーキング・メモリー領域１６において交換すべ
きデータ・フィールドに関する情報（フィールド・タイプ、フィールド長さ、ア
ドレスまたは移動）がエンターされる。更に、アドレスしたフィールドがアクセ
ス・データ領域３０に含まれていない場合は、対応するメモリー・フィールドが
転送データ領域３４に用意される。この情報から、拡張コンポーネントのディレ
クトリー部分２６のデータ転送ディレクトリーにおいて対応するエントリーが作
成される。このエントリーは、現在具体化されているコンポーネントの転送デー
タ領域３４のメモリー・フィールドに対する、アドレスしたコンポーネントのメ
モリー・フィールド割り当ても含んでいる。アドレスしたコンポーネントは、基
本コンポーネントとは限らず、このコンポーネント内のアドレスしたメモリー・
フィールドが３つの領域３０、３２、３４のうちの１つに位置していても良い。
こうして、他のどのコンポーネント中の使用可能な全てのデータも、データ取得
およびデータ処分することができる。
【００７６】 さて、ここでコードが作成され（ステップ５６）、コンポーネント・スクリプ
ト内の指示行（instruction lines)が、ランニング・タイム・システム１４が解
釈できる適当な中間コード内に転送される。コード生成は、それ自体で既知の原
則を用いて実施される。コンポーネントは、これまでに説明したステップで作成
されたコンポーネントから、バイナリー・オブジェクト・フォーマットにおいて
互いに結合される。結果として生じるバイナリー・オブジェクトは、図２に示す
構造および前に既に説明した構造を有している。これは、次のステップ（ステッ
プ５８）でストアされる。
【００７７】 こうして、ドッキング・ポイントに対するバイナリー・オブジェクトの作成が
完了する。具体化手順においては、続きのドッキング・ポイントがサーチされる
（ステップ６０）。このようなドッキング・ポイントがプログラム・コンポーネ
ント・システム内に存在する場合は、更にバイナリー・オブジェクトを作成する
。存在しない場合は、具体化が終了する。１つのコンポーネント・スクリプトか
ら作成したバイナリー・オブジェクトは、メモリー・ディレクトリー内で定義さ
れるメモリー占有が互いに異なっているだけである。しかし、基本コンポーネン
ト内に幾つかのドッキング・ポイントが見つかった場合は、メモリーの占有は通
常同じである。このような状況は、幾つかのドッキング・ポイントが異なる基本
コンポーネントで見付かった場合にも生じる。このように、別な１つの実施例で
は、各バイナリー・コードを１回だけ作成するための最適化を考慮している。
【００７８】 プログラム・コンポーネント・システムを実行するために、図１に示した構造
が構築される。このために、ランニング・タイム・システム１４とコンテナー環
境１８が最初にロードされ、スタートされる。コンテナー環境１８は、ローディ
ング中に見ることのできるメニュー・エントリーのカタログを含んでいる。この
カタログは、コンポーネント１８で定義される。ここで、上記の具体化プロセス
中にジェネレータ・システム自身によって作成されたルート・コンポーネントが
スタートされる。ランニング・タイム・システムは、メニュー選択など、プログ
ラム・コンポーネント・システムの「実際の（オクチュアル）」コンポーネント
のコールを示す、ユーザーが行うアクションを待つ。
【００７９】 図４(FIG４ａ）、図５(FIG４ｂ）、図６(FIG４ｃ）に、コンポーネントをコー
ルする間、及びコールされたコンポーネントを実行する間に実施されるプログラ
ム・フロー方法を示す。この実施例では、ランニング・タイムにおいてちょうど
１つのコンポーネントが常にアクティブな状態になっている。システムのスター
ト直後では、これは上に説明したルート・コンポーネントである。ワーキング・
メモリー領域１６には、アクティブな各コンポーネントだけが配置されている。
このコンポーネントは、図２に示すバイナリー・オブジェクト構造を有している
。別な実施例では、（例えば「マルチ・スレディング（multi-threading)」によ
って）準平行（quasi-parallel）プログラム・ラン手順も可能である。この場合
、コントロールは下層（アンダーライイング）のオペレーティング・システム１
０によって行う。
【００８０】 例えばユーザーのインプットあるいはアクションに呼応して新しいコンポーネ
ントがコールされる場合、アクティブなコンポーネントの状態がセーブされる（
ステップ７０）。このことは、ワーキング・メモリー領域１６の少なくとも一部
分が、コンポーネントのメモリー・イメージ領域２８が配置されているファイル
またはその他のセービング領域に転送されることを意味している。本実施例では
、残りの部分のメモリー・スペース要求が少ないので、バイナリー・オブジェク
ト全体がセーブされている。
【００８１】 更に、アクティブなコンポーネントのプログラム・ラン手順においてウェイテ
ィング・リストに記載されている全てのデータ処分プロセスが実施される（ステ
ップ７２）。効率を向上させるため、本実施例では書き込みでアクセスされた転
送データ領域３４のメモリー・フィールドだけが、現在のコンポーネントからデ
ータ処分によって参照されたコンポーネントに再転送されるようにしている。別
な実施例では、変更されたデータのウェイティング・リストは準備されない。代
りに、コンポーネントの各変更において、転送データ領域３４内の全てのデータ
・フィールドが参照された各コンポーネントに転送される。
【００８２】 各データ処分プロセスにおいて、現在のコンポーネントのデータ転送ディレク
トリーを活用する。こうすることによって、参照されたコンポーネントおよびメ
モリー・イメージ部分２８内の対応するデータ・フィールドを決定し、そこにデ
ータを転送するのである。このように、各データ処分は、現在アクティブでない
コンポーネントのバイナリー・オブジェクトを変更する。ラン・タイム中は、コ
ンポーネントをコールして部分的に数回実行することもある。この場合、コンポ
ーネントの数種類のバージョンがセーブされ、データは、現在アクティブなコン
ポーネントに至るコール・チェーンの中でこのコンポーネントに最も近くセーブ
されたコンポーネント・バージョンに処分される。別な実施例では、コンポーネ
ント・バージョンの異なった選択、またはプログラマーが決定した選択を行って
いる。
【００８３】 次に、ステップ７４では、最後にコールされた新しいコンポーネントがワーキ
ング・メモリー領域１６にバイナリー・オブジェクトとしてロードされる。これ
が終了すると、ワーキング・メモリー領域１６のうちで古いコンポーネントのプ
ログラム、表及びディレクトリー部分２２、２４、２６のために使用された部分
が、いずれの場合も上書きされる。
【００８４】 また、新しいコンポーネントのメモリー・イメージ部分２８におけるローカル
・データ領域３２が、ワーキング・メモリー領域１６にロードされる。こうして
、新しいコンポーネントのスタートにおいては、全てのローカル・データが定め
られた標準値によって予め占有される。しかし、コールされたコンポーネントの
アクセス・データ領域３０に対応するワーキング・メモリー領域１６の部分は、
上書きされない。つまり、ここにストアされたデータ値は、コンポーネントが交
換されても失われない。新しいコンポーネントは、コールするコンポーネント内
で定義されたアクセス・メモリー・フィールドに、アクセス・データ領域３０を
経由して直接にアクセスできる。アクセス・データ領域３０のサイズは、具体化
のフェーズにおいて見つかったメモリー・ディストリビューションによって決定
される。コールする側のコンポーネントがコールされる側のコンポーネントの値
と全く異なる値にアクセスする場合は、アクセス・データ領域はゼロ・サイズで
ある。
【００８５】 コールされたコンポーネントがバイナリー・オブジェクトとしてロードされた
後、プログラム部分２２に含まれるコードがコマンドごとに解釈される。コマン
ドを実行する時（ステップ７６）には、幾つかの特別な場合を考慮しなければな
らない。
【００８６】 コマンドが転送データ領域３４を目指したメモリー操作である場合（質問ステ
ップ７８）、問題のメモリー・フィ−ルドは後のデータ処分用にウェイティング
・リストに記載される（ステップ８０）。このようなウェイティング・リスト記
載は、明確（イクスプリシット）なコマンドによっても可能である。
【００８７】 現在のコマンドが参照されるコンポーネントからのデータ取得を行う指示であ
る場合は（質問ステップ８２）、図５(FIG４ｂ）に示したステップが実施される
。このようなコマンドは、例えば上に説明した構造INH-DATA-IMEであっても良く
、本実施例ではデータ取得宣言として、またデータ処分関係及びデータ取得指示
とも考えられる。別な実施例では、コンポーネントが参照する全てのデータが既
にこのコンポーネントの最初から取得されている。
【００８８】 図５(FIG４ｂ）のデータ取得方法では、参照されたコンポーネントが既に（少
なくとも部分的に）実施されているかを最初に調べる（質問ステップ８４）。ま
だ実施されていない場合は、有効なデータを取得することはできず、ラン・タイ
ム・エラーがトリガーされる。逆に参照されたコンポーネントのセーブされたバ
ージョンがある場合は、要求されたデータがそのバージョンからロードされ、現
在アクティブなコンポーネントの転送データ領域３４に書き込まれる。参照され
たコンポーネントとアクティブなコンポーネントの各メモリー・ロケーションは
、アクティブなコンポーネントのデータ転送ディレクトリーから見ることができ
る。この場合（ステップ７２）、参照されたコンポーネントの数種類のバージョ
ンが記憶されることが可能である。アクティブなコンポーネントに至るコール・
チェーンにおいて最後に実施されたバージョンがデータ取得に使用される。別な
実施例では、他の与えられた選択戦略やプログラム化された選択戦略が可能であ
る。データ取得の終了後、プログラム・フローはステップ７６で継続される（図
４(FIG４ａ））。
【００８９】 質問ステップ８８（図４(FIG４ａ））において、現在解釈されているコマンド
がコンポーネントを交換するコマンドであるか、つまり新しいコンポーネントを
要求するコマンドであるかどうかが調べられる。特に、このようなコマンドはド
ッキング・ポイントにストアされたコール情報（メッセージ）であっても良い。
上に説明した通り、このようなコール情報は、ドッキング・ポイントのタイプに
応じて、単に存在することによって、あるいは予め決められたユーザーのアクシ
ョンによって、コール情報に示されたコンポーネントをコールさせる。このよう
なコールが行われると、現在のコマンド・カウンター・レベルがスタック・スト
レッジにストアされ、図４(FIG４ａ）に示した方法が新たにスタートされる。
【００９０】 最後に、質問ステップ９０は、現在のコンポーネントの実行が通常のやり方で
終了される場合に関するものである。通常のやり方で終了されない場合、プログ
ラムの実行はステップ７６で継続される。逆に、プログラムの最後に到達した場
合は、図６(FIG４ｃ）に示した方法が実施される。ステップ７２と同様に、ウェ
イティング・リストに記載された全てのデータ処分が実施される（ステップ９２
）。そして、現在のコンポーネントをコールしたワーキング・メモリー領域１６
内のコンポーネントの状態が復活される（ステップ９４）。これは、部分２２、
２４および２６、並びにローカル・データ領域３２に関係している。しかし、コ
ールするコンポーネントのアクセス・データ領域３０に対応するワーキング・メ
モリー領域１６の部分は復活（リストア）されず、アクセス・データ領域３０内
の値を、現在のコンポーネントからコールする側のコンポーネントへ戻すことが
できる。
【００９１】 コールするコンポーネントがリストアしたら、図４から図６(FIG４ａから FIG
４ｃ）に図解した方法の現在の流れが終了される。プログラムの実行は、元のコ
ンポーネントのコールがトリガーされたロケーションにおいて前の段階（ステッ
プ７６）で継続される。
【００９２】 上述の方法を使用することによって、コンポーネントの機能を比較的簡単に拡
張することができる。例えば、ユーザーが（インプット・フィールドを経由して
）入力する単一価格に基づいて価格を決定する方法を実行する基本コンポーネン
トが与えられる。適当な拡張コンポーネントを使用することで、この基本コンポ
ーネントは単一価格に対して価格を決定するアプリケーション固有の方法によっ
て拡張することができる。このために、拡張コンポーネントのためのコール情報
が、単一価格に対するインプット・フィールドに関連するドッキング・ポイント
に書き込まれる。拡張コンポーネントによって決定された単一価格は、データ処
分方法により基本コンポーネントに書き込まれる。拡張コンポーネントが価格決
定のために必要とする追加データは、データ取得方法によって他のコンポーネン
トからコールされる。基本コンポーネントやその他のコンポーネントをプログラ
ミングする時には、このような機能拡張を考慮する必要はない。
【００９３】 大規模なソフトウェア・システムのプログラミングは、様々なやり方で単純化
できる。例えば、「アダプター・コンポーネント」と呼ばれるコンポーネントを
定義することができる。アダプター・コンポーネントとは、別のコンポーネント
を直接参照する拡張コンポーネントである。このように、別コンポーネントを異
なる名称で複数回使用することができる。
【００９４】
【発明の効果】
本発明は、ラン・タイム・システム及び若干のコンポーネントを有するプログ
ラム・コンポーネント・システムにおけるプログラム・フロー方法に関するもの
であり、第２コンポーネントにおいてプログラムで定義されたインターフェース
と独立な第１コンポーネントにおける第２コンポーネントに関するデータ取得を
含み、このデータ取得はラン・タイム・システムによって転送される。また、本
発明の方法は、第２コンポーネントにおいてプログラムで定義されたインターフ
ェースと独立な第２コンポーネントにおける第１コンポーネントに関するデータ
の取得も含んでいる。プログラム・コンポーネント・システムを追加コンポーネ
ントの回りに拡張する方法において、本発明は追加コンポーネントに対してドッ
キング・ポイントがサーチされることと、少なくとも１つのドッキング・ポイン
トが見つかったプログラム・コンポーネント・システムの各コンポーネントが、
見つかった各ドッキング・ポイントに関するコール情報を登録することによって
変更されることを規定している。従って、本発明によれば、プログラム・コンポ
ーネント・システムを取り分けフレキシブルかつ広範囲に拡張することができる
。特に、拡張するコンポーネントのソース・コードの知識を要求せずに修正また
は拡張できる。
【図面の簡単な説明】
【図１】 プログラム実行中のプログラム・コンポーネント・システムの原則を示す図(F
IG１）。
【図２】 バイナリー・オブジェクトの原則を示している図(FIG２）
【図３】 コンポーネントのインストールのフロー・チャート(FIG３）。
【図４】 コンポーネント変更を含む実行時の演算のフロー・チャート(FIG４ａ）。
【図５】 コンポーネント変更を含む実行時の演算のフロー・チャート(FIG４ｂ）。
【図６】 コンポーネント変更を含む実行時の演算のフロー・チャート(FIG４ｃ）。
【符号の説明】
１０ オペレーティンング・システム １２ ディストリビューション・プラットフォーム １４ ラン・タイム・システム １６ ワーキング・メモリ領域 １８ コンテナー環境 ２０、２０’、２０''、20''' コンポーネント ２２ プログラム部分 ２４ 表部分 ２６ ディレクトリー部分 ２８ メモリー・イメージ部分 ３０ アクセス・データ領域 ３２ ローカル・データ領域 ３４ 転送データ領域
【手続補正書】特許協力条約第３４条補正の翻訳文提出書
【提出日】平成１１年１１月９日（１９９９．１１．９）
【手続補正１】
【補正対象書類名】明細書
【補正対象項目名】０００２
【補正方法】変更
【補正内容】
【０００２】
【従来の技術】 ＵＳＰ（米国特許明細書）５，６３４，１２４号から、複数のオブジェクト・ マネージャと１つのオペレーション・マネージャが用いられる、オブジェクト・ マネージャによるデータ統合方法が知られている。 オブジェクト・スペクトラム誌１９８７年第３号、８６−８９頁に発表された
ミヒャエル・シュタルの記事「コンポーネント・ウェア−コンポーネントからア
プリケーションへ」に、プログラム・コンポーネント・システムの基礎が説明さ
れている。これまで非常に時間のかかっていたソフトウェア製造を、与えられた
コンポーネントを単純に「結線」することで置換えることを狙いとしている。こ
れらのコンポーネントは、コンポーネントの製造者に対してコンポーネントの基
礎となるソース・コードの詳細開示を要求しないでも、様々なコンテクストで適
用できるものと期待されている。
───────────────────────────────────────────────────── フロントページの続き (81)指定国 ＥＰ(ＡＴ，ＢＥ，ＣＨ，ＣＹ， ＤＥ，ＤＫ，ＥＳ，ＦＩ，ＦＲ，ＧＢ，ＧＲ，ＩＥ，Ｉ Ｔ，ＬＵ，ＭＣ，ＮＬ，ＰＴ，ＳＥ)，ＯＡ(ＢＦ，ＢＪ ，ＣＦ，ＣＧ，ＣＩ，ＣＭ，ＧＡ，ＧＮ，ＧＷ，ＭＬ， ＭＲ，ＮＥ，ＳＮ，ＴＤ，ＴＧ)，ＡＰ(ＧＨ，ＧＭ，Ｋ Ｅ，ＬＳ，ＭＷ，ＳＤ，ＳＺ，ＵＧ，ＺＷ)，ＥＡ(ＡＭ ，ＡＺ，ＢＹ，ＫＧ，ＫＺ，ＭＤ，ＲＵ，ＴＪ，ＴＭ) ，ＡＬ，ＡＭ，ＡＴ，ＡＵ，ＡＺ，ＢＡ，ＢＢ，ＢＧ， ＢＲ，ＢＹ，ＣＡ，ＣＨ，ＣＮ，ＣＵ，ＣＺ，ＤＥ，Ｄ Ｋ，ＥＥ，ＥＳ，ＦＩ，ＧＢ，ＧＤ，ＧＥ，ＧＨ，ＧＭ ，ＨＲ，ＨＵ，ＩＤ，ＩＬ，ＩＮ，ＩＳ，ＪＰ，ＫＥ， ＫＧ，ＫＰ，ＫＲ，ＫＺ，ＬＣ，ＬＫ，ＬＲ，ＬＳ，Ｌ Ｔ，ＬＵ，ＬＶ，ＭＤ，ＭＧ，ＭＫ，ＭＮ，ＭＷ，ＭＸ ，ＮＯ，ＮＺ，ＰＬ，ＰＴ，ＲＯ，ＲＵ，ＳＤ，ＳＥ， ＳＧ，ＳＩ，ＳＫ，ＳＬ，ＴＪ，ＴＭ，ＴＲ，ＴＴ，Ｕ Ａ，ＵＧ，ＵＳ，ＵＺ，ＶＮ，ＹＵ，ＺＷ

Claims (16)

    【特許請求の範囲】
  1. 【請求項１】 ランニング・タイム・システム（１４）及びそれぞれ１つの
    プログラム部分を有する幾つかのコンポーネント（２０、２０' 、…）から成る
    プログラム・コンポーネント・システムにおけるプログラム・フロー方法であっ
    て、第１のコンポーネント（２０）のプログラム部分（２２）の実行中に、 ａ）ランニング・タイム・システム（１４）によって、第２のコンポーネント（
    ２０’）のデータを前記第１コンポーネント（２０）内に、前記第２コンポーネ
    ント（２０’）においてプログラムで定義されたインターフェースと独立に取得
    するステップ、及び ｂ）ランニング・タイム・システム（１４）によって、前記第１コンポーネント
    （２０）のデータを前記第２コンポーネント（２０’）内に、前記第２コンポー
    ネント（２０’）においてプログラムで定義されたインターフェースと独立にデ
    ータを処分するステップ を含むプログラム・フロー方法。
  2. 【請求項２】 請求項１に記載のプログラム・フロー方法において、 データ取得中に転送されるデータが前記第２コンポーネント（２０’）のメモリ
    ー・イメージ部分（２８）から前記第１コンポーネント（２０）の転送データ部
    分（３４）に転送されること、及び、データ処分中に転送されるデータが前記第
    １コンポーネント（２０）の転送データ部分（３４）から前記第２コンポーネン
    ト（２０’）のメモリー・イメージ部分（２８）に転送されること、のうち少な
    くとも一方が行われることを特徴とするプログラム・フロー方法。
  3. 【請求項３】 請求項１又は２に記載のプログラム・フロー方法において、
    前記データ取得及びデータ処分の少なくとも一方が前記第２コンポーネント（２
    ０’）の協力なしに実施されることを特徴とするプログラム・フロー方法。
  4. 【請求項４】 請求項１から３いずれかに記載のプログラム・フロー方法に
    おいて、 前記第２コンポーネント（２０’）が前記データ取得中及びデータ処分中の少な
    くとも一方ではアクティブでないことを特徴とするプログラム・フロー方法。
  5. 【請求項５】 請求項１から４いずれかに記載のプログラム・フロー方法に
    おいて、 前記第２コンポーネント（２０’）の前記データ転送領域（３４）が前記データ
    取得及び該データ処分中はセービング領域に配置されることを特徴とするプログ
    ラム・フロー方法。
  6. 【請求項６】 請求項１から５いずれかに記載のプログラム・フロー方法に
    おいて、 前記第２コンポーネント（２０’）のローカル・データ及び持続性のないデータ
    のうち少なくと一方が前記データ取得中及びデータ処分中の少なくとも一方で転
    送されることを特徴とするプログラム・フロー方法。
  7. 【請求項７】 請求項１から６いずれかに記載のプログラム・フロー方法に
    おいて、 前記第１コンポーネント（２０）のプログラム部分（２２）の実行中に前記第１
    コンポーネント（２０）のどのデータがデータ処分を必要とするかを示すウェイ
    ティング・リストが作成されることを特徴とするプログラム・フロー方法。
  8. 【請求項８】 請求項１から７いずれかに記載のプログラム・フロー方法に
    おいて、 コールされたコンポーネント（２０、２０’、…）が、該コールするコンポー
    ネント（２０、２０’、…）において定義されたデータ・フィールド及び使用可
    能なデータ・フィールドのうち少なくとも一方で構成されるアクセス・データ領
    域（３０）に直接アクセスできることを特徴するプログラム・フロー方法。
  9. 【請求項９】 請求項１から８いずれかに記載のプログラム・フロー方法に
    おいて、 コンポーネント（２０、２０’、…）のコールが、該コールするコンポーネント
    のドッキング・ポイントに含まれるコール情報によってトリガーされることを特
    徴とするプログラム・フロー方法。
  10. 【請求項１０】 幾つかのコンポーネント（２０、２０’、…）を含むプロ
    グラム・コンポーネント・システムをもう１つの別コンポーネントによって拡張
    する方法であって、 ａ）前記プログラム・コンポーネント・システムの前記別コンポーネントに対す
    るドッキング・ポイント、即ち、前記別コンポーネントの定義によって決定され
    る遺伝パラメータに対応するドッキング・ポイントをサーチするステップ、及び ｂ）少なくとも一つのドッキング・ポイントが見つかったプログラム・コンポー
    ネント・システムのコンポーネント（２０、２０’、…）を、見付かった各ドッ
    キング・ポイントにおいて前記別コンポーネントに関するコール情報をエンター
    することによって修正するステップ を含むプログラム・コンポーネント・システム拡張方法。
  11. 【請求項１１】 請求項１０に記載のプログラム・コンポーネント・システ
    ム拡張方法において、 以前のコンポーネント（２０、２０’、…）の全てのインターラクション・イン
    ターフェースが潜在的なドッキング・ポイントとして予め定義されていることを
    特徴とするプログラム・コンポーネント・システム拡張方法。
  12. 【請求項１２】 請求項１０に記載のプログラム・コンポーネント・システ
    ム拡張方法において、 以前のコンポーネント（２０、２０’、…）によって参照される全てのインター
    アクション・スクリーン・フィールド、全てのプリント・マスク・アウトプット
    ・フィールド及び持続性のあるデータ上の全てのアクセス操作のうち、少なくと
    も１つが潜在的なドッキング・ポイントとして予め定義されていることを特徴と
    するプログラム・コンポーネント・システム拡張方法。
  13. 【請求項１３】 請求項１０から１２いずれかに記載のプログラム・コンポ
    ーネント・システム拡張方法において、 前記コール情報をドッキング・ポイントにエンターすることにより、前記コール
    情報がエンターされたコンポーネントからの前記別コンポーネントのコールが準
    備されることを特徴とするプログラム・コンポーネント・システム拡張方法。
  14. 【請求項１４】 請求項１０から１３いずれかに記載のプログラム・コンポ
    ーネント・システム拡張方法において、 ｃ）前記別コンポーネントの定義から少なくとも１つのバイナリー・オブジェク
    トが生成される、という追加ステップ を含むことを特徴とするプログラム・コンポーネント・システム拡張方法。
  15. 【請求項１５】 請求項１４に記載のプログラム・コンポーネント・システ
    ム拡張方法において、 見つかった各ドッキング・ポイントから最大１つのバイナリー・オブジェクトが
    生成されることを特徴とするプログラム・コンポーネント・システム拡張方法。
  16. 【請求項１６】 請求項１５に記載のプログラム・コンポーネント・システ
    ム拡張方法において、 各バイナリー・オブジェクトを生成している間に、下層にあるドッキング・ポイ
    ントを含むプログラム・コンポーネント・システムの１つのコンポーネント（２
    ０、２０’、…）においてメモリーの割り当てが考慮されていることを特徴とす
    るプログラム・コンポーネント・システム拡張方法。
JP2000527884A 1998-01-02 1998-12-29 プログラム・フロー方法及びプログラム・コンポーネント・システム拡張方法 Pending JP2002501230A (ja)

Applications Claiming Priority (5)

Application Number Priority Date Filing Date Title
DE19800102.9 1998-01-02
DE19800102 1998-01-02
DE19807191A DE19807191A1 (de) 1998-01-02 1998-02-20 Programmablaufverfahren und Verfahren zur Erweiterung eines Programmkomponentensystems
DE19807191.4 1998-02-20
PCT/EP1998/008507 WO1999035571A2 (de) 1998-01-02 1998-12-29 Programmablaufverfahren und verfahren zur erweiterung eines programmkomponentensystems

Publications (1)

Publication Number Publication Date
JP2002501230A true JP2002501230A (ja) 2002-01-15

Family

ID=26042960

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2000527884A Pending JP2002501230A (ja) 1998-01-02 1998-12-29 プログラム・フロー方法及びプログラム・コンポーネント・システム拡張方法

Country Status (8)

Country Link
US (2) US7185343B1 (ja)
EP (1) EP1044409B1 (ja)
JP (1) JP2002501230A (ja)
AT (1) ATE218721T1 (ja)
AU (1) AU2614399A (ja)
CA (1) CA2316952A1 (ja)
ES (1) ES2180232T3 (ja)
WO (1) WO1999035571A2 (ja)

Families Citing this family (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7574689B2 (en) * 2005-06-28 2009-08-11 Sap Ag Generic interface to provide object access display views based on object type
US9274790B2 (en) * 2014-04-30 2016-03-01 Oracle International Corporation Customization manager

Family Cites Families (16)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5226161A (en) 1987-08-21 1993-07-06 Wang Laboratories, Inc. Integration of data between typed data structures by mutual direct invocation between data managers corresponding to data types
US5491808A (en) * 1992-09-30 1996-02-13 Conner Peripherals, Inc. Method for tracking memory allocation in network file server
DE69511080T2 (de) * 1994-04-21 2000-02-03 British Telecommunications P.L.C., London Schnittstellenanordnung und verfahren
US5809564A (en) * 1994-06-27 1998-09-15 Microsoft Corporation Apparatus and method for swapping blocks of memory between a main memory area and a secondary storage area of a computer system
JP3072709B2 (ja) * 1994-11-21 2000-08-07 インターナショナル・ビジネス・マシーンズ・コーポレ−ション 要求伝達方法
US6321275B1 (en) * 1995-04-24 2001-11-20 Microsoft Corporation Interpreted remote procedure calls
US5887172A (en) * 1996-01-10 1999-03-23 Sun Microsystems, Inc. Remote procedure call system and method for RPC mechanism independent client and server interfaces interoperable with any of a plurality of remote procedure call backends
US6044409A (en) * 1996-06-26 2000-03-28 Sun Microsystems, Inc. Framework for marshaling and unmarshaling argument object references
US6321273B1 (en) * 1996-07-11 2001-11-20 724 Solutions, Inc. Method and apparatus using parameterized vectors for converting interface definition language-defined data structures into a transport and platform independent format
US5819263A (en) * 1996-07-19 1998-10-06 American Express Financial Corporation Financial planning system incorporating relationship and group management
US6438573B1 (en) * 1996-10-09 2002-08-20 Iowa State University Research Foundation, Inc. Real-time programming method
US6473768B1 (en) * 1996-11-12 2002-10-29 Computer Associates Think, Inc. System and method for modifying an executing application
US6298391B1 (en) * 1998-03-13 2001-10-02 Microsoft Corporation Remote procedure calling with marshaling and unmarshaling of arbitrary non-conformant pointer sizes
US6438744B2 (en) * 1998-07-15 2002-08-20 Microsoft Corporation Dynamic mapping of component interfaces
US6425017B1 (en) * 1998-08-17 2002-07-23 Microsoft Corporation Queued method invocations on distributed component applications
US6397384B1 (en) * 1998-12-18 2002-05-28 Adobe Systems Incorporated Run-time addition of interfaces

Also Published As

Publication number Publication date
ES2180232T3 (es) 2003-02-01
CA2316952A1 (en) 1999-07-15
WO1999035571A2 (de) 1999-07-15
ATE218721T1 (de) 2002-06-15
EP1044409A2 (de) 2000-10-18
AU2614399A (en) 1999-07-26
WO1999035571A3 (de) 1999-09-16
US7185343B1 (en) 2007-02-27
US20070113236A1 (en) 2007-05-17
EP1044409B1 (de) 2002-06-05

Similar Documents

Publication Publication Date Title
US5369766A (en) Object-oriented loader system with support for different load formats
US7080373B2 (en) Method and device for creating and using pre-internalized program files
US5615400A (en) System for object oriented dynamic linking based upon a catalog of registered function set or class identifiers
US7263699B2 (en) Preparation of a software configuration using an XML type programming language
US5835768A (en) Computer operating system providing means for formatting information in accordance with specified cultural preferences
EP1224543B1 (en) Fixing applications that are incompatible to the operating system by providing stubs for apis
US5842220A (en) Methods and apparatus for exposing members of an object class through class signature interfaces
US6108661A (en) System for instance customization
US5930503A (en) System and method for on demand registration of tasks
US6792612B1 (en) Java runtime system with modified constant pool
JP2002529812A (ja) 実行時にコンパイルされたコンピュータコードの機能を改変するためのシステム
WO2004077289A1 (en) Method for using a business model data interface
US6314445B1 (en) Native function calling
JP2001518658A (ja) プラットフォームとアプリケーションとの間の互換性を評価する方法および装置
US20040268301A1 (en) Adding new compiler methods to an integrated development environment
JP2002544589A (ja) ビジネスオブジェクトインタフェースをビジュアルにカスタマイズするシステムおよび方法
JPH08339296A (ja) 動的リンク・ライブラリをプログラムにリンクする方法
EP1016963A2 (en) Run-time addition of interfaces
EP2380078B1 (en) Shared value resolution with multiple runtime containers
US6842905B2 (en) Method and system for implementing collection program interface for accessing a collection of data associated with a legacy enumeration application interface
US20020056075A1 (en) System for a run-time engine capable for pager capable remote device
US7155701B1 (en) System for dynamically constructing an executable computer program
JP2002501230A (ja) プログラム・フロー方法及びプログラム・コンポーネント・システム拡張方法
US20040153580A1 (en) Component based operation system dynamic device drive method
EP1678607B1 (en) Mapping of dynamic link libraries in a computing device

Legal Events

Date Code Title Description
A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20050812

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20080507

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20080716

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20081021

A601 Written request for extension of time

Free format text: JAPANESE INTERMEDIATE CODE: A601

Effective date: 20090120

A602 Written permission of extension of time

Free format text: JAPANESE INTERMEDIATE CODE: A602

Effective date: 20090127

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20090414

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20091222

A02 Decision of refusal

Free format text: JAPANESE INTERMEDIATE CODE: A02

Effective date: 20100608