JPS6288033A - ソフトウエアプログラムを生成するための装置及びその方法 - Google Patents

Abstract

(57)【要約】本公報は電子出願前の出願データであるた
め要約のデータは記録されません。

Description

【発明の詳細な説明】 〔産業上の利用分野〕 本発明はソフトウェア生成システム、よシ詳細にはソフ
トウェアの幾つかの部分が何回も生成されることが要求
されるようなソフトウェアの生成システムに関する。

〔従来技術とその問題点〕

ソフトウェア　システムは、各々が特定のタスクを遂行
する複数の要素あるいはモジュールから構成される。こ
れら要素は、通常、１つあるいは複数の機能を実現し、
及び／あるいはソフトウェア　システム全体として全体
的なタスクを遂行するために保持、更新及び検索される
情報のある構造を持つ部分を構成する。

ソフトウェア　システムには２つのタイプのモジュール
、つまり、１）そのタスクを遂行するために設計された
システムによって特にそのタスクのために要求される動
作を遂行する動作モジュール、及び２）第１のタイプの
ソフトウェア　モジュールを支援するために必要とされ
る一般的なデータ処理動作を遂行するための支援モジュ
ールが存在する。典型的なシステムにおいては、大多数
のモジュールが、第２のタイプ、つまり、支援タイプに
属する。

異なるソフトウェア　システムの支援モジュールの間に
は多くの類似点が存在する。例えば、全てのオペレーテ
ィング　システムは、ある方法によって、項目のスタッ
ク、待ち行列及びテーブルを保持及び処理することを要
求される。例えば、項目のテーブルを処理するための必
要とされる動作はテーブル内になにが格納されていても
同じである。しかし１つのオペレーティング　システム
が、個々が異なるタイプの項目を含む複数の独立したテ
ーブルを処理するために要求されることも、さらに、異
なるオペレーティング　システムが異なるタイプの項目
を処理し、従って、これら項目に対する異なるテーブル
を必要とする場合もある。

現在のソフトウェア開発技術においては、ソフトウェア
　システムのモジュールは全てスクラッチから開発され
る。この作業が殆んどのモジュールが他の類似のソフト
ウェアシステムに対して既に開発されているのにもかか
わらず行なわれている。前に開発されたソフトウェア要
素を再使用することができないのは、現在のソフトウェ
ア開発ツールでは総称モジュールの指定及び生成が不可
能なためである。今日の技術においては、モジュールは
単に１つの特定のフオームの構造の特定のタイプの特定
の項目に関しての特定の動作を遂行するためにのみ開発
される。このため、例えば、あるタイプの項目のテーブ
ルを支援するソフトウニ“ア　モジュールは別のタイプ
の項目のテーブルを支援するために使用できない。また
、別の例として、テーブル内の項目を検出するための特
定の捜索方法を使用するモジュールは異なる捜索方法が
必要とされる場合には使用できない。従って、ソフトウ
ェア開発者によって指定される要件に従ってソフトウェ
アの部分を自動的に生成するシステムに対する需要が存
在する。

〔発明の概要〕

本発明のシステムによると、頻繁に使用されるソフトウ
ェア要素が一度のみ設計及び開発され、これらが異なる
背景及び異なる要件を持つ異なるシステム内で何度も再
使用される。これは設計者にその要素が使用される特定
の背景と基本的に独立したソフトウェア要素を指定する
ことができる機能を提供することによって達成される。

このモジュールを新たなシステムにそのシステム固有の
要件を持たせて統合したい場合、本発明によるシステム
はこのモジュールのその新たなシステムの要件に合った
具体的バージョンを自動的に生成する。

ソフトウェア再使用のためのこのシステムは以下の可視
的要素から構成される。

■、吃称モジュールを指定するための形式２、第１項の
指定言語にて書かれた仕様を処理するためのコンパイラ
。

３、総称モジュールからそれぞれが与えられた特定の背
景内でその背景の要件に基づいて機能する複数の具体的
ソフトウェア　モジュールを自動的に生成するためのイ
ンスタンシエータ。

このシステムによって処理される論理実体は汎用要素（
ＧＰＣ）と呼ばれる。１つのＧＣＰは総称プログラミン
グ　サービスの集合を提供する。例えば、ｃｐｃは特定
のソフトウェア　テーブルを保持及び処理し、ある特定
のタイプの項目を格納するために必要とされる全ての動
作及びデータ定義を提供する。

このＧＰＣによって提供される（集合的に１サービス“
と呼ばれる）これら動作及び定義はこれらが９テーブル
“の動作及び定義の基本のみを把握し、これらが特定の
タイプの項目あるいは特定の処理方法に具体的に連結さ
れないという意味にお鈷て総称的である。

従って、これらサービスは、原形のままでは、どのプロ
グラムにも使用できない。

しかし、この総称サービスが、それらが意図された環境
の背景及び要件が入力されると、本発明によるシステム
は、これらを具体的プログラミング　サービスに生成す
る。例えば、プログラマがテーブル内に格納されるべき
項目のタイプを決定し、この情報を本発明によるシステ
ムに送ると、インスタンシエータを使用してＧＰＣの具
体的、つまシ、翻訳されたバージョンが自動的に生成さ
れる。このソフトウェア　コードの生成されたバージョ
ンは、プログラマによってスクラッチから書かれたもの
と全く同様である。この総称バージョンから具体的バー
ジョンを生成するプロセスはインスタンシェーション　
プロセスと呼ばれる。

同一のＧＰＣを使用して異なるソフトウェア　システム
に対する異なる具体的バージョンを生成することができ
る。つまり、本発明によるシステムにおいては、ソフト
ウェア要素が一度のみ生成され、これが何回でも必要に
応じて異なるソフトウェア　システムに合うように自動
的に修正される。

〔実施例の説明〕

本発明のこれら及び他の目的及び特徴、並びに動作及び
用途は、−例としての実施態様を図面を参照して読むこ
とによって一層明白となるものである。

上に説明され、また第１図に示されるごとく、ここに示
される実施態様は汎用コンピュータ、例えば、ＶＡＸＩ
　１／７８ｏとともに使用される。さらに、ここに説明
のシステムはパーソナル　コンピュータ、側光ば、ＡＴ
＆Ｔ　　ＰＣ６３００を含む任意のコンピュータでも使
用できる。

内部的には、このシステムは関連する４つの要素、つ−
まり：ユーザが汎用要素（ＧＰＣ）仕様１０１を生成す
るために使用する仕様記述言語、この仕様言語を処理す
るためのＧＰＣコンパイラ１０２、コンパイルされたＧ
ＰＣ仕様のための記憶領域１ｏ４、及びインスタンシエ
ータ１０６から構成される。

必須要件ではないが、ＧＰＣ仕様からＧＰＣの英語によ
る説明を抽出し、これを後に他のユーザが前に書かれた
ＧＰＣを調べ再使用できるように別個のデータ　ベース
１０３に格納しておくと便利である。

ＧＰＣの設計者は仕様記述言語を使用してＧＰＣを総称
的背景自由形式にて指定する。

設計者は次にこのＧＰＣ仕様をコンピュータ内のファイ
ル１０１に格納し、次にＧＰＣコンパイラ１０２を１呼
び出してこのファイルを処理する。この処理の結果、コ
ンパイルされたＧＰＣ仕様が記憶領域１０４内に格納さ
れる。

ＧＰＣのユーザはユーザによって開発中のソース　プロ
グラム１０５に適当な呼び出し命令文を挿入する。この
呼び出し命令文に応答して、後に説明されるように、シ
ステムはまず最初に適当なプログラム　セグメントを生
成し、次に生成されたプログラム　セグメントをユーザ
　プログラムに挿入及び／あるいはユーザ　プログラム
を修正することによって拡張されたプログラム１０１を
生成する。

この拡張されたプログラムはコンパイラ１０８によって
周知の方法でコンパイルされ、コンパイルされたプログ
ラム１０９を生成する。

そしてこのプログラムによってコンピュータが動作され
る。

仕様記述言語 本発明は全てのコンピュータ言語に使用できるが、説明
の目的上、周知のＣ言語が想定される。この言語の説゛
萌に関しては、１９７８年に合衆国、ニューシャーシー
州、エンジェルウッド　クリフ（Ｅｎｇｌｅｗｏｏｄ　
Ｃ１１ｆｆｓ　ｓ　Ｎ−Ｊ、　Ｕ、　Ｓ、　Ａ、　）所
在プレンテイスーヘイル（Ｐｒｅｎｔｉｃｅ　−Ｈａｌ
ｅ　）社から出版された；ソフトウェア　シリーズ：Ｂ
、Ｗ、カーニハン（Ｂ、　Ｗ、　Ｋｅｒｎｉｇｈａｎ　
）及びり、　Ｍ、ライチェ（Ｄ、　Ｍ、　Ｒｉｔｈｉｅ
　）著１Ｃプログラミング言語（Ｔｈｅ　ＣＰｒｏｇｒ
ａｍｍｉｎｇ　Ｌａｎｇｕａｇｅ　）“を参照すること
。この仕様において太文字は言語キーワードを表わする
に使用され：イタリック体はユーザ供給文字列を表わす
のに使用され；曲った括弧“）““（“はオプションの
項目を囲むのに使用され：垂直バー９１　“は代替を分
離するのに使用され；そしてチ（及びチ）は引用のため
に使用されるキーワードである。

この仕様記述言語はＧＰＣ仕様を書くのに使用される。

個々の仕様は３つの主な部分、つまり：記述部分、宣言
部分、及び定義部分から構成される。ＧＰＣ仕様の一般
的なフオームが第１表に示される。尚、第１表から第１
５表は汎用要素（ＧＰＣ）のフォーマットを示す。又、
以後表示される表に関しては本欄の最後にまとめて表示
する。

最初のチの前の全てのものは記述部分２０１と呼ばれ、
コンパイル　プロセスによって無視される。ただし、本
発明によるシステムのユーザは記述部分が機械的に処理
されカタログ１０３内に格納されるようにテンプレート
＋Ｖｐａｒａｍｅｔｅｒ　“（パラン“り）　、’　５
ｅｒｖｉｃｅ’（サービス）あるいは’　ｈｉｄｄｅｎ
“　（ハイド）を宣言できる。パラメータ宣言の構文が
第２表に示され、サービス宣言の構文が第３表に示され
、モしてハイド宣言の構文が第４表に示される。

パラメータはＧＰＣユーザによって指定されるものであ
り、一方、５ｅｒｖｉｃｅ　（サービス）はＧＰＣによ
ってユーザに提供されるものであるｏ　　ｐａｒａｍｅ
ｔｅｒ　（パラメータ）Ｆｉ、ｔｙｐｅ（タイプ）、ｖ
ａｌｕｅ　Ｃ値）（オブジェクトのサイズ、あるいはエ
ラー　リターン　コードを定義する定数）、ｏｐｔｉｏ
ｎ　　（オプション）（例えば、　異なるアルゴリズム
を選択するために使用）、ｏｐｅｒａｔｉｏｎ　（動作
）（例えば、ハツシュ機能あるいはエラー処理ルーチン
）、あるいはｐｒｏｇｅ　（プローグ）（任意のテキス
ト）であシえる。５ｅｒｖｉｃｅ　（サービス）は、ｔ
ｙｐｅ　（タイプ）％　ｖａｌｕｅ　（値）、ｏｐｅｒ
ａｔｉｏｎ（動作）・あるいはｐｒｏｓｅ　（プローグ
）でありえる。ｈｉｄｄｅｎ　（ハイド）に関しては後
に説明される。

１ｄｅｎｔｉｆｉｅｒ　（識別子）は文字から開始する
一連の文字あるいは数字である。下線Ｎ−“け１文字と
してカウントされる。大文字と小文字は区別される。最
初の１２文字以下のみが有効である。ただし、最つと多
くすることも可能である。

ｔｙｐｅ　　Ｃタイプ）は以下の一般フオームにて使用
できる任意のＣ言語である。

ｔｙｐｅ　　ＶａｒｉａｂｌｅＮａｍｅ　；タイプの一
例としては、’　ｉｎｔ＊“、’　ｆｌｏａｔ“、’　
５ｔｒｕｃｔ　（ｉｎｔ　ｖａｒｌ　；　ｌｏｎｇ　ｖ
ａｒ２　；ｌ　　“、及び’　ＭｙＴｙｐｅ　“等を挙
げることができる。

ここで、ＭｙＴｙｐｅは前に、例えば、以下のように定
義される。

ｔｙｐｅｄｅｆ　ｃｈａｒ　＊　　Ｍｙｔｙｐｅ（）　
１ｖａｌｕｅ　Ｃ値）は、例えば、′２５〃、ゝゝ　１
＼０３３１　“、及び“１．９Ｅ−６ｔｔなどノヨうな
任意のＣ言語である。

オプションはそのオプションに対して有効な事前に定義
された文字列の１つに対応する文字の任意のシーケンス
である。

ｏｐｅｒａｔｉｏｎ　（動作）は構文的にＣ言語機能の
名称と等しい名称である。これは、１つのｔｙｐｅ　（
タイプ）、ｃａｓｔ　（カースト）を持つ。

ｐｒｏｓｅ　（プローグ）はテキスト　セグメントの名
称である。

ｈｉｄｄｅｎ　　（ハイド）はユーザによってアクセス
することはできないが１つあるいは複数のユーザによっ
てアクセス可能なサービスによって必要とされるサービ
スである。

第５表及び第６表に宣言の例が示される。

ＧＰＣ仕様の実現部分２０５は個々の宣言された５ｅｒ
ｖｉｃｅ　（サービス）あるいはｈｉｄｄｅｎ（ハイド
）に対する１つのプログラムから構成される。このプロ
グラムはインスタンシェータ１０６にユーザ　プログラ
マのコード内に対応するサービスに対する呼（ｃａｌｌ
　）　　が発見されたとき何なすべきかを命令する。例
えば１第１２表に示される非常に簡単なプロダラムはサ
ービス’　ｎｏｄｅ　“　（ノード）への呼が検出され
たときのインスタンシエータ１０６の動作を定義する。

つまシ、このプログラムはインスタンシエータ１０６に
Ｃ言語タイプを定義し、それにこのサービス’ｎｏｄｅ
　〃（ノード）に対してユーザが指定する名称を与える
ように命令する。タイプの個々の定義はユーザによって
選択された連結法（シングルあるいはダブル）に依存す
る。

句”ｒｅｑｕｉｒｅｓ　Ａｌｗａｙｓ”は”　ｎｏｄｅ
　”がインスタンシェード（１ｎｓｔａｎｔｉａｔｅ　
）されるたびに、インスタンシエータ１０６は、まず最
初にもう１つの’　Ａｌｗａｙｓ　”　と呼ばれるサー
ビスが既にインスタンシェードされていることを確保し
なければならないことを記述する。

オプションの句’　ｒｅｑｕｉｒｅｓ　１ｄｅｎｔｉｆ
ｉｅｒ’は、異なる値の１ｄｅｎｔｉｆｉｅｒ　（識別
子）に対して何度も反復することができる。ここで、１
ｄｅｎｔｉｆｉｅｒ　（識別子）はｈｉｄｄｅｎ　（ハ
イド）、あるいは他の５ｅｒｖｉｃｅ　（サービス）の
名称である。

３つの命令、つまり、ｒｅｐｌａｃｅ　（置換え）１１
ｈｅａｄｅｒ　（見出し）、及びｏｐｐｅｎｄ　（附加
）、並びに１つのフロー構造ｉｆ　−ｔｈｅｎ　−ｅｌ
ｓｅ　−ｅｎｄｉｆのみが存在する。

命令は、ｉｆ　−ｔｈｅｎ　−ｅｌｓｅ　−ｅｎｄｉｆ
構造によってグループ化されたときを除いてそれらが書
かれたのと同一シーケンスによって実行される。

ｒｅｐｌａｃｅ　（置換え）命令は第７表に示されるよ
うな一般フオームを持つ。このｒｅｐｌａｃｅ（置換え
）命令が実行されると、インスタンシエータ１０６は呼
のテキストを任意のＣ言語セグメントによって置換する
。１つの動作に対する呼のテキストは開始ドル信号、サ
ービスの名称、終端ドル記号、及び左右の括弧及び括弧
間の中身から構成される。他のサービスでは、呼のテキ
サスはサービスの名称及ヒドル記号の囲いベアから構成
される。この命令はハイドに対しては許されないことは
勿論である。

置換えプロセスの際に、Ｃ言語セグメント内の全ての文
字は以下のケースを除いて変換されないまま出力に伝送
される。

一一フオーム＼＄　Ｎａｍｅ　＄のシーケンスは＄　Ｎ
ａｍｅ　＄　　に変換される。（これによってＧＰＣを
他のＧＰＣによって指定することが可能となる）。

一一フオーム＄　Ｎａｍｅ　＄　　のシーケンスは総称
名”Ｎａｍｅ″を持つ〔サービス呼ではなく）サービス
のリファレンスとみなされ、単に、そのサービスに対す
るユーザ定義名に変換される。

一一フオーム＄ｏ＄のシーケンスは指定中のプログラム
を持つサービスのユーザによって既知の名称に変換され
る。

一一タイブｏｐｅｒａｔｉｏｎ　（動作）の動作サービ
スでは、ｎが１から２０の間の数字から成るフオーム＄
ｎ＄のシーケンスはそのサービス呼のｎ番目の引数の（
拡張された）テキストのリファレンスとみなされ、この
シーケンスは対応する文字列に変換される。あるサービ
ス呼の引数はそれ自体サービス呼である場合もあること
に注意する。

ａｐｐｅｎｄ　（附加）命令は第８表に示される一般フ
オームを持つ。この命令が実行されると、インスタンシ
エータ１０６は与えられたＣ言語セグメントをユーザ　
ンース　ファイルの（現在の）終端に附加する。このＣ
言語セグメントの＄ｎ＄及び＄　Ｎａｍｅ　＄　文字列
の変換も遂行される。修飾子ｍｕｌｔｉｐｌｅ　（複数
）が存在する場合は、そのＣ言語セグメントがサービス
呼が処理されるたびに附加され。

ｏｎｃｅ　（一度）が存在する場合、あるいは修飾子が
全く存在しない場合は、Ｃ言語セグメントは最高でも一
度のみ附加される。

ｈｅａｄｅｒ　　（見出し）命令１−を第９表に示され
る一般フオームを持つ。この命令が実行されると、イン
スタンシエータ１０６はユーザソース　ファイル内の与
えられたＣ言語セグメントを対応するＧＰＣ要求ライン
の立置（あるいは同−ＧＰＣの他のｈｅａｄｅｒ　　（
見出し）命令の最後に挿入されたＣ言語セグメントの後
）に挿入する。このＣ言語セグメントの処理は上に説明
のごとくである。

ｉｆ　−ｔｈｅｎ　−ｅｌｌｅ　−ｅｎｄｉｆ　　制御
フロー構造は第１０表に示される一般フオームを持つ。

フオーム１１０１において、”　１ｎｓｔｒｕｃｔｉｏ
ｎｓ”（命令）は”　ｃｏｎｄｉｔｉｏｎ　’　（条件
）が真であるときにのみ遂行される。フオーム１１０２
においては、キーワードｔｈｅｎと６１３ｅの間の命令
は“ｃｏｎｄｉｔｉｏｎ“が真であるときにのみ遂行さ
れ、キーワードｅｌＢｅとｅｎｄｉｆの間の命令は“ｃ
ｏｎｄｉｔｉｏｎ　’が真でないときにのみ遂行される
。ｉｆ　−ｔｈｅｎ　−ｅｌｓｅ　−ｅｎｄｉｆ構造は
構文的［１つの命令に等しく、従って、別のｉｆ　−ｔ
ｈｅｎ　−ｅｌｓｅ　−ｅｎｄｆｆのｉｆ−あるいは６
１１ｅ−ブロック内に現れることがある。

このｅｎｄｉｆのあいまいさＦｉｌつのｅｎｄｉｆを最
後に遭遇されるｉｆと結ぶことによって解決される。

”　ｃｏｎｄｉｔｉｏｒｌ　”　（条件）は第１１表に
示される一般フオームを持つ。’　１ｄｅｎｔｉｆｉｅ
ｒ　’（識別子）はサービスあるいはパラメータの総称
名である。フオーム１２０１及び１２０２はユーザが与
えられたパラメータあるいはサービスの省略時の値（ｄ
ｅｆａｕｌｔ　ｖａｌｕｅ　）に代わる値を指定したか
否かをテストする。ユーザが省略時と異なる値Ｃｄｅｆ
ａｕｌｔ　ｖａｌｕｅ　）を指定した場合は、第１の条
件が真であり、第２の条件は真でなく、異なる値を指定
しない場合は、第１の条件は真でなく、第２の条件が真
である。

フオーム１２０３及び１２０４は与えられた文字列（ｓ
ｔｒｉｎｇ　）　　に対して与えられたパラメータある
いはサービスの値をテストする。

−＝＝＃は等しいことを意味し“　１＝”は等しくない
ことを意味する。

第１２表の例では、ライン１３０２はインスタンシエー
タ１０Ｇにこのサービスのユーザによって既知の名称を
優（及び悌）のペアによって囲まれたセグメントの内容
と置換するように命令する。このケースでは、置換テキ
ストは単に（＄０＄によって指定される）ユーザによっ
て既知の名称である。つまり、この命令は実際には”ｅ
ｃｈｏ″　（エコー）命令である。

命令１３０３はｉｆ　−ｔｈｅｎ　−ｅｌｓｅ　−ｅｎ
ｆｉｆ構造を使用して、制御フローをユーザによってｏ
ｐｔｉｏｎ　（オプション）ＳＩＮＧＬＹ　が要求され
るか否かに対応する２つの経路に分割する。異なるのは
、総称名”ノード″を持つタイプがいかに定義されるか
である。いずれのケースにおいても、たった１つの命令
、つまり、インスタンシエータ１０６によって実行され
るべきｈｅａｄｅｒ　（見出し）命令が存在するのみで
ある。ｈｅａｄｅｒ　（見出し）命令を実行すると、結
果として、ユーザ　ファイルのＧＰＣが要求されたライ
ンの所に与えられたセグメントが挿入される。＄　Ｄａ
ｔｅ　＄及び＄　ｎｏｄｅ　＄　　はそれぞれパラメー
ダ’　ｄａｔａ　”、及びサービス”ｎｏｄｅ”に対す
るユーザの名称を表わす。修飾子０ｎｅｅはサービス”
ｍｏｄｅ”が何度呼び出されてもセグメントの挿入を一
度のみ行なうべきであることを指定する。

０ｎｃｅ　は省略時の値（ｄｅｆａｕｌｔ　ｖａｌｕｅ
　）であり、これは修飾子ｍｕｌｔｉｐｌｅ　　によっ
て書き変えることができる。

前述したごとく、ＧＰＣの宣言部分内には、もう１つの
クラスのオブジェクト、つまり、ｈｉｄｄｅｎ　　（ハ
イド）として宣言されたオブジェクトが存在する。ｈｉ
ｄｄｅｎ　（ハイド）はユーザ　プログラマによっては
認識されないが、１つあるいは複数の他のサービスある
いはハイドを実現するのに使用されるサービスである。

ハイドのインスタンシェーションは必ずｒｅｑｕｉｒｅ
ｓ　　機構によって呼び出される。この例では、ライン
６０６内に宣言された隠れた“Ａｌｗａｙｓ　’　に対
するプログラムが第１３表及び第１４表に示される。

ＧＰＣ仕様記述言語の１つの興味深い特徴としてｏｐｅ
ｒａｔｉｏｎ　（動作〕タイプのサービスがいかに使用
されるかを挙げることができる。

ＧＰＣ設計者Ｆ′ｉＣ言語セグメントをそのパラメータ
の１つとみなす１つのｏｐｅｒａｔｉｏｎ　（動作〕を
指定するととができる。例えば、リスト、そのリストの
個々の要素内のデータを表わす名称、及びコードの１つ
のセグメントをそのパラメータとみなす。ｐｅｒａｔｉ
ｏｎ　（動作）ｆｏｒａｌｌ　”を指定し、そのリスト
内の全ての要素に対するセグメントを最初から最後まで
実行することができる。この動作の仕様が第１５表に示
される。

コンパイラ ＧＰＣコンパイラ１０２はＧＰＣ仕様をインスタンシエ
ータ１０６に適するフォーマットに翻訳する役割を持つ
。これはＧＰＣ仕様を読み、これはＧＰＣ仕様を読み、
これが構文的に正常であるかチェックする。ＧＰＣコン
パイラによって遂行されるチェックには以下が含まれる
。

一一仕様内の全ての命令文が構文的に正常であるか。

一一全ての宣言されたサービス及びハイドが正常に定義
されているか。

ｍ−存在ループが存在しないか。あるサービスあるいは
ハイドが別のサービスあるいはハイドのインスタンシェ
ーションを要求 （ｒｅｑｕｉｒｅｓ　）　　する場合は、後者のサービ
スあるいはハイドはｒｅｑｕｉｒｅｓ　　命令のチェー
ンを介して前のサービスあるいはハイドのインスタンシ
ェーションを要求（ｒｅｑｕｉｒｅｓ　）　　すること
はない。

ＧＰＣコンパイラが異常を検出すると、ＧＰＣはエラー
　メツセージを印字することによってＧＰＣ設計者にこ
れを通知する。存在しない場合は、これは他のコンパイ
ラと類似の方法でシンボル　テーブル及びパース（ｐａ
ｒｓｅ　）木を２構成し、これらをコンパイルされたＧ
ＰＣｌ　０４のための記憶領域に格納する。この情報は
後にインスタンシエータ１０６によって拡張されたプロ
グラム１０７を生成するのに使用される。

ＧＰＣコンパイラは通常のコンパイラのように機械コー
ドを生成することはないことに注意する。ＧＰＣコンパ
イラの出力は、仕様の（２進）符号化されたものであり
、これは後に説明されるように、インスタンシエ・〜り
によってプログラム　セグメントを生成するのに使用さ
れる。

ＧＰＣの使用 新たなソフトウェア　プログラムの作成を開始しようと
するユーザ　プログラマはＧＰＣカタログ１０３内から
開発されるべきプログラムに使用できるＧＰＣ（複数）
を捜がす。

発見されたら、ユーザ　プログラマはプログラム内に必
要とされるＧＰＣ（複数）の名称を指定し、また個々の
ＧＰＣが動作する背景に関する情報を提供する”ｒｅｑ
ｕｅｓｔ　１ｉｎｅ”（要求ライン）を挿入する。これ
ら要求ラインは、これらがコンパイラ１０８にパスされ
ないことから、’　１ｎｄｉｒｅｃｔ”　（間接）命令
文（複数）であるとみなすことができる。一方、変換さ
れないままコンパイラ１０８にパスされる命令文は直接
命令文であるとみなすことができる。

典型的なＧＰＣ要求ラインにおいては、ユーザはパラメ
ータの値及びサービスの名称を指定する。ＧＰＣ要求ラ
インは第１６表に示される一般フオームを持つ。尚、第
１６表から第２０表は典型的なＧＰＣ用途のフォーマッ
トを示す。

Ａｒｇｓ　　はＧＰＣのパラメータ及びサービスに対応
する’　ａｒｇｕｍｅｎｔ　−ｎａｍｅ　”＝　ａｒｇ
ｕｍｅｎｔ　−ｎａｌｕｅ″（引数−名称＝引数−値）
のコンマによって分離されたリストである。

ＧＰＣが”　ｌ１ｓｔｈｎｄｌｒ　％”　と呼ばれるも
のと仮定し、第１７表及び第１８表は２つのＧＰＣ要求
ラインを示す。

第１図のケース（第１７表）においては、”　ＭｙＥｌ
ｅｍｅｎｔＴｙｐｅ”がユーザによって前にＣ言語のｔ
）’ｆｌｅｄｅｆ構造によって定義されたタイプの名称
であると仮定される。ＧＰＣは、他のサービスとともに
、”　ＭｙＬｉ　ｓ　ｔ　Ｔ　ｙｐｅ”と呼ばれるタイ
プ、及びＡＤＤ”と呼ばれる動作の定義を提供する。第
２のケース（第１８表）においては、”　ｄａｔｅＨの
定義が与えられた構造の定義であるとみなされ、ＧＰＣ
によって提供されるサービスはこれらの省略値の名称に
よって呼ばれる。

ユーザは１ｉｓｔｈｎｄｌｒによって提供されるサービ
スが正しく定義されており、ＧＰＣ要求ライン後のコン
パイル　モジュール内のどこでも使用できるものと想定
できる。ユーザはこれらサーザスを”　５ｅｒｖｉｃｅ
　ｃａｌｌｓ”（サービス呼）によって使用することが
できる。サービスはペアのドル記号（＄）内に囲まれた
ユーザによって即知の名称を示すことによって呼び出す
ことができる。例えば、第１９表（第１７表のＧＰＣ要
求ラインに対応）は、サービス′″１ｉｓｔ”及び”　
ａｄｄａｆｔｅｒ　”を呼び出す。

一例として、ユーザがプログラム内の１つの入力ライン
に対して１つの名称を読み出す１ｉｓｔｈｎｄｌｒ　Ｇ
ＰＣを使用して、入力ストリーム内の名称及びそれらの
相対位置を逆の順序で印刷したいものと仮定する。つま
り、最初に入力された名称を最後に印刷したいものと仮
定する。すると、このユーザ　ソース　プログラムは第
２０表に示されるようなプログラムとなる。ライン２１
０９から２１６６がＧＰＣ要求ラインを構成し、ライン
２１９９．２１２５．２１２９．２１３２．２１３４．
２１３５、及び２１３６が各々ＧＰＣサービス呼を含む
ことに注意する。

インスタンシェータ インスタンシエータ１０６は（コンパイルされた）ＧＰ
Ｃ仕様及びＧＰＣ要求ラインの両方に従ってテーラ−メ
イド　プログラムあるいはプログラム　セグメントを生
成する役割を持つ。インスタンシエータ１０６は、まず
最初に、ユーザ　ソース　プログラム１０５を走査し、
ＧＰＣ要求ラインを捜がす。発見されると、ＧＰＣの名
称を抽出し、コンパイルされたＧＰＣ記憶領域１０４内
の対応する（コンパイラされた）仕様の位置を突きとめ
る。インスタンシエータ１０６は、次に、ユーザによっ
て指定された値をＧＰＣ設計者によって宣言された総称
パラメータに連結する。

この結果、全ての総称パラメータがそれと関連する具体
的値を持つＧＰＣ仕様の具体的バージョンが得られる。

上のプロセスが同一〇ＰＣに対して複数の要求が存在す
る場合でも要求された個々のＧＰＣに対して一回遂行さ
れる（ユーザは毎回総称パラメータに対する異なるセッ
トの値を使用して、同一〇ＰＣを数回要求することがで
きることに注意する）。

インスタンシエータ１０６ｆｌ’ｆだユーザソース　プ
ログラムを走査し、サービス呼を捜す。サービス呼が検
出されると、インスタンシエータ１０６はその内部テー
ブルを使用して、どのＧＰＣがそのサービスの定義を持
つか調べる。これは次に定義（これは、通常、総称パラ
メータとして定義される）並びにその総称パラメータに
対する対応する値の位置を突きとめる。この結果、ユー
ザ　プログラムの部分の変更、ユーザ　プログラムの部
分のプログラム　セグメントによる代用、プログラム　
セグメントのユーザ　プログラムのさまざ筐なセクショ
ンへの挿入、全く新たなプログラムの生成、あるいはこ
れらのユーザプログラムへの附加が起こる。これらの具
体的な動作は、勿論、ＧＰＣ仕様内のサービスの対応す
る定義によって決定される。

最後に、インスタンシエータＩＱ６は拡張されたファイ
ル１０７を生成し、このファイルに結果として生成され
たソース　プログラム１０７を格納する。

第２０表のプログラムに対応するインスタンシエータ１
０６の出力（第１図の拡張されたプログラム１０７）が
第２１表に示される。

尚、第２１表は本発明の一例としての出力（生成された
プログラム）を示す。インスタンシエータ１０６がソー
ス　ファイルを幾つかの点で変更していることに注意す
る。２つのｔｙｐｅｄｅｆ句を７センブルし、これらを
ＧＰＣが要求されたラインの所に入力している。

”　＋　１ｎｃｌｕｄｅ　＜　ｍｅｍｏｒｙ、　ｈ　＞
”が加えられている（ライン２２０９〕。ユーザ　ソー
スファイル内の全てのサービス呼が置換されている。よ
り具体的には、動作”ＰＵＳＨ″及び”ＰＯＰ”　に対
して完全なプログラムが生成されており、これがユーザ
　コードに加えられている（それぞれライン２２４３か
ら２２６２並びにライン２２６３から２２７４）。

一方、動作”　ＧＥＴ　、　”　”　ＴＯＰ　％”　”
　ｉｓｅｍｐｔｙ　、”及びｈｏｗｍａｎｙ　”は単に
プログラム　セグメントによって置換されている（ライ
ン２２２９、ｚ２３３．２２３６．２２３８．２２３９
、及び２２４０）。

拡張されたプログラム（第２１表）はユーザが時間をか
けて全てスクラッチからソースプログラムを設計し、書
いた場合と同様なものとなる。ただし、ＧＰＣは任意の
ファミリーのモジュールに対して一度のみの設計が要求
されるため、設計者はモジュールの設計に十分な時間を
費すことができ、結果として、効率が非常に良いソース
　コードを設計することができる。再使用可能なモジュ
ールのもう１つの特徴は、総合的なソフトウェア製造コ
ストを減少できることである。例えば、後の使用のため
のデバッグ時間の短縮、コード修正時間の短縮、あるい
はコードを書く時間の短縮などが実現される。

ここに説明のシステムは上に説明のソフトウェア再使用
以外の用途にも使用できる。実際、総称要素を修正して
特定の要件に合ったものを生成するような全ての用途に
おいて本発明は真価を発揮する・ これら用途において本発明を活用するためには、ユーザ
はＧＰ（１”仕様記述言語を使用して汎用要素を設計し
、欠に、インスタンシエータを使用して要素の複数の特
定のバージョンを生成する。

一例として、銀行が顧客に顧客の信用状態に関する手紙
を送るケースを考えることができる。このような状況に
おいては、ＧＰＣ設計者は、顧客の名称、顧客が個人で
あるか会社であるか、顧客が銀行とどの程度の期間数シ
引きを行なっているか、顧客の現在及び過去の信用状態
、銀行の現在の方針を反映する変数、その他を総称パラ
メータとして持つ“汎用レター″（ｇｅｎｅｒａｌ　ｐ
ｕｒｐｏｓｅ　１ｅｔｔｅｒ）を作成することができる
。

個別の顧客ベースの手紙をインスタンシエータによって
個々の顧客に対して指定されたこれら総称パラメータの
値の組合せに基づいて合成することができる。

例えば、過去の信用状態は良くなかったが現在の信用状
態は改善された。顧客と現在も過去も信用状態の良い顧
客とでは異なる手紙が構成できる。

可能性は無限であり、どの程度まで高度なＧＰＣを作成
するかによって、全て同一のレターを使用して、数個の
標準フォーマットから多様の非常に個別化された手紙ま
で作成することができる。

【図面の簡単な説明】

第１図はコンピュータ　システムに実現された本発明の
ブロック図を示す。 〔主要部分の符号の説明〕 １０２・・・コンパイラ（ＧＰＣコンパイラ）１０４・
・・記憶装置（コンパイルされたＧＰＣ用記憶装置） ＦＩＧ、　／

Claims (1)

1. 【特許請求の範囲】 １、供給される総称仕様からソフトウェア　プログラム
   を生成するための装置において、該システムが 総称ソフトウェア要素を指定する言語命令文を受信する
   コンパイラ、 該総称ソフトウェア要素のコンパイルされた要素を格納
   するための記憶装置、及び 特定のソフトウェア　アプリケーションを指定する言語
   命令文を受信するための入力を持つ受信装置を含み、 該コンパイラとの関連において、個々の該総称ソフトウ
   ェア要素がプログラム生成のための１つあるいは複数の
   ユーザ要求可能サービスに対応し、該サービスが該サー
   ビスの具体的な特性を決定する言語命令文の集合によつ
   て指定され、与えられた１つの総称ソフトウェア要素が
   総称仕様内の命令文及び総称パラメータに対して特定の
   アプリケーションによつて供給された値の組合せの下で
   具体的ソフトウェア　プログラムの生成を制御し、 該記憶装置との関連において、該記憶装置が該コンパイ
   ルされた総称ソフトウェア要素を該格納された指定要素
   が検索できるように格納し、 該受信装置との関連において、該言語命令文が１つの特
   定の総称ソフトウェア要素を指定する直接命令文、間接
   命令文、及び１つの特定の総称ソフトウェア要素内の特
   定のサービスを指定する要求命令文を含み、個々の間接
   命令文がさらに該総称ソフトウェア要素の総称パラメー
   タに対応する特定の値を指定し、該受信装置がさらに 該命令文の間接命令文の受信に応答して該コンパイルさ
   れた総称ソフトウェア要素のための記憶装置から該指定
   された総称ソフトウェア要素のコード化された仕様の位
   置を突きとめるための検出装置、 該検出されたコード化された仕様と該対応する間接命令
   文からの該指定されたパラメータ値とを互いに関連させ
   るための関連装置、 １つの要求命令文の受信に応答して該検出された該総称
   ソフトウェア要素の１つの中の該要求命令文と関連する
   サービスに対応する命令文の集合の位置を検出するため
   の第２の検出装置、及び 該検出された命令文の集合による制御下においてその出
   力の所に間接及び要求命令文を含まない言語命令文を持
   つ該特定のソフトウェア　アプリケーションの具体的バ
   ージョンを生成するための生成装置を含むことを特徴と
   するソフトウェア　プログラムを生成するための装置。 ２、特許請求の範囲第１項に記載の装置において、 該特定のソフトウェア　アプリケーションが個々が同一
   の総称ソフトウェア要素を引用する複数の間接命令文を
   含み、これら個々の間接命令文が異なるセットの総称パ
   ラメータ値を指定し、 該特定のソフトウェア　アプリケーションを指定する言
   語命令文を受信する該受信装置が個々の該引用された総
   称ソフトウェア要素に対して同一の総称ソフトウェア要
   素の複数の異なる実例を生成するための装置、及び該総
   称ソフトウェア要素の個々の実例によつて提供される同
   一サービスに対して後に提供されるユーザ要求が個々の
   サービスの個々の実例を一意的に引用できるように異な
   る名称を与えるための装置を含むことを特徴とする装置
   。 ３、特許請求の範囲第１項に記載の装置において、 該言語命令文の集合が間接命令文及びそれらの同一ある
   いは別の総称ソフトウェア要素を引用する要求命令文を
   挿入する命令を含み、該受信装置が該生成されたソフト
   ウェア　アプリケーション内に加えられた間接命令文あ
   るいは要求命令文が存在しないか監視し、該生成された
   ソフトウェア　アプリ・ケーションを該受信装置の該入
   力に再び加えるための装置を含むことを特徴とする装置
   。 ４、供給される総称仕様からソフトウェア　プログラム
   を生成するための方法において、該方法が総称ソフトウ
   ェア要素を指定する受信された言語命令文をコンパイル
   するステップ、該総称ソフトウェア要素のコンパイルさ
   れた要素を格納するステップ、及び 特定のソフトウェア　アプリケーションを指定する言語
   命令文を受信するステップを含み、 該コンパイルするステップとの関連において、個々の総
   称ソフトウェア要素がプログラム生成のための１つある
   いは複数のユーザ要求可能サービスに対応し、該サービ
   スが該サービスの具体的な特性を決定する言語命令文の
   集合によつて指定され、与えられた１つの総称ソフトウ
   ェア要素が総称仕様内の命令文及び総称パラメータに対
   して特定のアプリケーションによつて供給された値の組
   合せの下で具体的ソフトウェア　プログラムの生成を制
   御し、 該記憶ステップとの関連において、該格納された指定要
   素が検索できるように格納され、 該受信ステップとの関連において、該言語命令文が１つ
   の特定の総称ソフトウェア要素を指定する直接命令文、
   間接命令文、及び１つの特定の総称ソフトウェア要素内
   の特定のサービスを指定する要求命令文を含み、個々の
   間接命令文がさらに該総称ソフトウェア要素の総称パラ
   メータに対応する特定の値を指定し、該受信ステップが
   さらに該命令文の間接命令文の受信に応答して該コンパ
   イルされた総称ソフトウェア要素のための記憶装置から
   該指定された総称ソフトウェア要素のコード化された仕
   様の位置を突きとめるステップ、 該検出されたコード化された仕様と該対応する間接命令
   文からの該指定されたパラメータ値とを互いに関連させ
   るステップ、 １つの要求命令文の受信に応答して該検出された該総称
   ソフトウェア要素の１つの中の該要求命令文と関連する
   サービスに対応する命令文の集合の位置を検出するステ
   ップ、及び 該検出された命令文の集合による制御下において間接及
   び要求命令文を含まない言語命令文を持つ該特定のソフ
   トウェア　アプリケーションの具体的バージョンを生成
   するステップを含むことを特徴とするソフトウェア　プ
   ログラムを生成するための方法。 ５、特許請求の範囲第４項に記載の方法において、 該特定のソフトウェア　アプリケーションが、個々が同
   一の総称ソフトウェア要素を引用する複数の間接命令文
   が異なるセットの総称パラメータ値を指定し、 該特定のソフトウェア　アプリケーションを指定する言
   語命令文を受信するステップが個々の該引用された総称
   ソフトウェア要素に対して同一の総称ソフトウェア要素
   の複数の異なる実例を生成するステップ、及び該総称ソ
   フトウェア要素の個々の実例によつて提供される同一サ
   ービスに対して後に提供されるユーザ要求が個々のサー
   ビスの個々の実例を一意的に引用できるように異なる名
   称を与えるステップを含むことを特徴とする方法。 ６、特許請求の範囲第４項に記載の方法において、 該言語命令文の集合が間接命令文及びそれらの同一ある
   いは別の総称ソフトウェア要素を引用する要求命令文を
   挿入する命令を含み、該受信ステップが該生成されたソ
   フトウェア　アプリケーション内に加えられた間接命令
   文あるいは要求命令文が存在しないか監視するステップ
   、及び該生成されたソフトウェア　アプリケーションを
   該受信装置の該入力に再び加えるステップを含むことを
   特徴とする方法。