JPH0778075A - 対話式分散有限状態プログラム発生器を提供する方法及び装置 - Google Patents

Abstract

(57)【要約】 （修正有） 【目的】 有限状態駆動型データ処理プログラムの設
計、開発、及びテストにおけるプロジェクト要求を通じ
て、ユーザ手引きの方法及び装置を提供する。 【構成】 ユーザは構成、環境、プロトコル及び分散パ
ートナ・プログラムを含む内部及び外部要因に従い、判
断支援を提供される。ユーザにとって複数経路が使用可
能な場合、本発明はユーザに最も好適な、選択を通知す
る。ユーザは構成の変更を許可され、ユーザはこの作用
を生成するために要求される構成の変更を助言される。
このツールにより生成されるソース・コードは、設計に
おいて構文的に正しく、固有の環境においても適切な分
散パートナ・プログラムと一緒にテストされ機能する。
ユーザはセッションの間、プロトコル及び環境だけでな
く、所望の作用を生成するためのプログラム要求につい
ても指導される。本発明はソース・コードの個別化を簡
単なテーブル更新により生成し、新たなインタフェース
の実現を最小の手間で達成する。

Description

【発明の詳細な説明】

【０００１】

【産業上の利用分野】本発明は一般にデータ処理システ
ムに関し、特に、有限状態駆動型データ処理プログラム
の設計、開発及びテストを通じて、ユーザを手引きする
方法及び装置に関する。

【０００２】

【従来の技術】現存のデータ処理システムはプログラミ
ング・インタフェースへの対話式アクセス機能を提供す
る。これらのツールは２つのカテゴリに分類できる。す
なわち、ソース・コード発生器及びプログラム式機能テ
スタまたはサブルーチン・テスタである。

【０００３】ソース・コード発生器モデルは全て共通の
基盤を有する。ユーザはある高レベル・インタフェース
を提供され、これによりソース・コード発生器が低レベ
ル・インタフェースへ翻訳し、これがコンパイルされて
実行される。高レベル・インタフェースは設計抽象、モ
デル、仕様、モジュール、またはこれらのモジュールを
表現するグラフィカル・アイコンであったりする。ユー
ザは意図する設計を反映するために、ある順序でこれら
のモジュールを選択することができる。ツールがこれら
のモジュールを低レベル・コンポーネントに翻訳し、コ
ンパイル可能コードを生成すると、テスト及び変更を開
始することが可能となる。これらのツールは少量のテス
ト時間を排除するために、入力パラメータのフォーマッ
トまたは構文をチェックするための支援を提供すること
もある。これらの発生器はプログラムが生成されている
時には、固有環境機能のテストを許可しない。また外部
的影響から生じる要因を考慮しない。これはすなわち、
製品ソフトウェアが設計または仕様には順応的である
が、実際のシステム環境に対応して機能的でないことを
意味する。これらのタイプのソース・コード発生器は容
易に調達可能であり、例えば、P．Busnello及びA．Clau
deによる"Structure of a Source CodeGenerator"（IBM
Techinical Disclosure Bulletin、ニューヨーク州ア
ーモンクにて１９７１年６月発行）などの文献において
開示されている。

【０００４】第２のカテゴリのツールは、ユーザが特定
のモジュールまたはプログラム式機能及びサブルーチン
をテスト可能とすることに焦点が当てられている。これ
らのツールは、環境及び特定の状態を考慮するための問
題を解決しようとしている。このツールでは、ユーザは
設計を理解する責任は負うが、固有のシステム環境にお
いて機能をテストすることが許可される。ユーザはメニ
ューまたはアイコンにより実行する機能を選択し、可変
データにより機能をテストする。こうしたツールの例
に、ＩＢＭの顧客情報制御システム実行コマンド・レベ
ル・インタープリタ（ＣＩＣＳ ＣＥＣＩまたはＣＥＣ
Ｉ：Customer Information ControlSystem Execution C
ommand-Level Interpreter）があり、これはＣＩＣＳ
（Customer Information Control System ）コマンドの
ための画面インタフェースまたはコマンド・インタープ
リタである。このツールはユーザが機能をテストするこ
とを可能とするがソース・コードを生成しない。ユーザ
は意図する設計、プログラムのフロー、構成要求、プロ
トコル及びシステム環境を理解することが要求される。

【０００５】現存のシステムが不十分であるいくつかの
状況が存在する。両方のカテゴリの現存のシステムにお
いて、ユーザはプログラム設計、モデル、またはツール
で使用される擬似コードを完了していることが要求され
る。より高度に複雑な状態駆動型データ処理システムに
おいて、しばしば遭遇する環境について考えてみよう。
この環境における最も共通の例は、分散型データ処理環
境である。この環境では、プログラマは現存のシステム
により指摘される構文及び固有の処理要求だけでなく、
他の分散データ処理プログラムとの通信インタフェース
により指摘されるこれらの点についても責任を負う。こ
の環境では、プログラマは更に構成、通信プロトコル、
及びパートナ分散プログラムについても理解しなければ
ならない。現存のシステムが適切な通信モジュールへの
アクセスを含むとしても、ユーザはユーザによって作成
された分散パートナ・プログラムを含む特定の環境の負
担を理解することに直面する。現存のシステムは構成、
通信プロトコル、分散パートナ・プログラムと、生成さ
れるコード要求との間の関係を理解するための余計な負
担について指摘していない。更に現存のシステムは、こ
れらの内部及び外部要因にもとづき、未熟なプログラマ
が設計を行う時の問題を指摘していない。従って、設
計、開発及びテストにおけるソフトウェア生成要求を通
じて、ユーザを手引きする方法が求められる。

【０００６】現存のシステムでは、プログラマはより困
難で高度な技術的要求、リサーチ、及び設計局面に遭遇
する。多くの場合では、ユーザがこれらのリソースを費
やして生成されるソフトウェアは、価値がなく、設計障
害または環境の複雑性により、いくつかの再生を要求さ
れることになる。本発明は複雑な有限状態駆動型データ
処理プログラムの設計、開発、及びテストを通じユーザ
を手引きすることにより、これらの問題を解決する。本
発明はまた単一セッションにおいてこれを提供できる。
単一セッションまたは複数セッションにおいて、本発明
はモジュールの構文及び拡張だけでなく、構成、プロト
コル、環境の複雑性、及びパートナ分散型データ処理プ
ログラムに関する理解を請け負う。

【０００７】現存のシステムは、分散型データ処理プロ
グラムの設計、開発及びテストのためのプロジェクト要
求を通じ、ユーザを手引きする方法または装置を提供し
ない。従って、分散型データ処理プログラムの設計、開
発及びテストのためのプロジェクト要求を通じ、ユーザ
を手引きする方法及び装置が必要とされる。

【０００８】

【発明が解決しようとする課題】本発明は複雑な有限状
態駆動型データ処理プログラムの設計、開発、及びテス
トにおけるプロジェクト要求を通じ、ユーザを手引きす
るための方法及び装置を提供する。この方法及び装置
は、複雑な有限状態駆動型データ処理プログラムを実現
しようと試みる時、現存のシステムの困難を排除または
低減する。

【０００９】本発明の目的は、環境の複雑性を使用する
ことにより、データ処理プログラムの設計、開発及びテ
ストのためのプロジェクト要求を通じて、ユーザを手引
きすることである。

【００１０】本発明の別の目的は、判断支援への入力と
してシステム環境を追跡することである。

【００１１】本発明の別の目的は、ユーザが開発する際
にユーザを指導するために実行されるように、また現存
のプログラムに包含するために、モジュール化されたデ
ータ処理プログラム要求を表示することである。

【００１２】本発明の別の目的は、ソース・コードを生
成するために、ユーザ変更可能なテンプレートを使用
し、単にテーブルを更新することにより、ユーザが追加
機能を組込むことを可能とすることである。

【００１３】本発明の別の目的は、追加の判断支援及び
有効な入力データに対応するセッション間の環境変化の
動的性質を追跡することである。

【００１４】本発明の更に別の目的は、携帯用のテーブ
ル駆動型の有限状態駆動型インタフェースを提供するこ
とである。

【００１５】

【課題を解決するための手段】本発明の１態様によれ
ば、複雑な有限状態駆動型データ処理プログラムの設
計、開発及びテストのためのプロジェクト要求を通じ、
ガイダンスが提供される。

【００１６】本発明の別の態様によれば、構成、プロト
コル及び分散パートナ・データ処理プログラムを含む内
部的及び外部的要因に従い、判断支援が提供される。

【００１７】本発明の別の態様によれば、複数の処理経
路が使用可能な場合に、ユーザに最も可能性の高いまた
は有利な選択を通知する。

【００１８】本発明の別の態様によれば、ユーザ要求を
実施するために構成の変更が許可され、更にユーザ要求
を生成するために要求される構成変更をユーザに助言す
る。

【００１９】

【実施例】図１を参照すると、本発明によるデータ処理
システム１００のブロック図が示される。データ処理シ
ステム１００はプロセッサ０２を含み、これは中央処理
ユニット（ＣＰＵ）０４及びメモリ０６を含む。更にプ
ロセッサ０２にはハードディスク・ファイル記憶装置０
８及びフロッピー・ディスク装置１０が接続される。フ
ロッピー・ディスク装置１０は、データ処理システム１
００において本発明を実施するコンピュータ・プログラ
ム・コードが記録されるディスケット１２を収容する。
データ処理システム１００は、プロセッサ０２へのユー
ザ入力を可能とするマウス１４及びキーボード１６など
のユーザ・インタフェース・ハードウェア、及び可視デ
ータをユーザに提供するための表示装置１８を含む。デ
ータ処理システム１００は更に、ネットワークまたは他
のデータ処理システムと通信するための通信ポート２０
を含む。

【００２０】図２を参照すると、本発明の好適な実施例
のブロック図が示される。本発明によれば、複雑な有限
状態駆動型ソフトウェアの設計、開発、及びテストのた
めのプロジェクト要求を通じ、ガイダンスが提供され
る。図２は、この好適な実施例が、現存のプラットフォ
ーム上で使用可能な要素に適合され、迅速に実施される
様子を表すものである。この実施例は、通信のための共
通プログラミング・インタフェース（ＣＰＩ−Ｃ：Comm
on Programming Interface for Communications）であ
るＳＮＡ通信インタフェースを示す。この実施例は以降
では、ＳＮＡプログラミング・インタフェースまたはＳ
ＮＡＰＩと称される。ＳＮＡＰＩツールは、標準の画面
インタフェース及び携帯用またはプラットフォーム特有
の通信インタフェースとインタフェースするために作成
される。図２のブロック２００は端末を表し、ユーザは
ここから画面インタフェースをアクセスする。ブロック
２０１は、ＳＮＡＰＩツールに対応する画面操作ユーザ
・インタフェース・フロントエンドを表す。この実施例
はユーザ・インタフェース・フロントエンドとしてＩＢ
Ｍのシステム管理インタフェース・ツール（ＳＭＩＴ）
を使用するが、当業者には理解されるように、他のユー
ザ・インタフェース・フロントエンドも使用可能であ
る。この画面インタフェースは、ＳＮＡＰＩツールに対
応する画面フォーマッティング、データ・プレゼンテー
ション、及びデータ検索を提供する。図２のブロック２
０５は、ＳＮＡＰＩサーバ２０４が分散環境をアクセス
する様子を表す。ブロック２０５はこの実施例ではＣＰ
Ｉ−Ｃインタフェースを参照するが、プラットフォーム
及び所望の通信プロトコルに依存して、他のインタフェ
ースがＣＰＩ−Ｃの代わりに使用されても良い。

【００２１】図２のブロック２０２及びブロック２０４
は、クライアント／サーバ・アーキテクチャとしてのＳ
ＮＡＰＩツールの実施例を表す。ブロック２０２はＳＮ
ＡＰＩサーバ２０４に対するクライアントとしてのＳＮ
ＡＰＩコマンド・インタプリタ（ＳＮＡＰＩ ＣＩ）を
表す。ＳＮＡＰＩ ＣＩ２０２は画面インタフェース２
０１からＳＮＡＰＩサーバ２０４への要求を受諾し、次
に、結果及び設計の助言をＳＮＡＰＩサーバ２０４から
画面インタフェース２０１に転送する。情報がプロセス
間通信２０３を介し、ＳＮＡＰＩ ＣＩ２０２とＳＮＡ
ＰＩサーバ２０４との間で転送される。図２のブロック
２０３はまた、ＳＮＡＰＩサーバ２０４のＳＮＡＰＩ
ＣＩ２０２及び支援されるインタフェース２０５との関
係を示す。ＳＮＡＰＩサーバ２０４は、プログラム・コ
ンテキスト、構成及び環境情報を維持する責任を負う一
方、分散コンポーネントとインタフェースする。ＳＮＡ
ＰＩ ＣＩすなわち図２のブロック２０２は、図３に示
される詳細流れ図に展開される。ＳＮＡＰＩサーバすな
わち図２のブロック２０４は、図４及び図５に示される
詳細流れ図に展開される。

【００２２】図３乃至図５を参照すると、本発明におい
て実行される好適なオペレーションの流れ図が示され
る。流れ図において、図形規約に従いひし形はテストま
たは判断を、方形は処理または機能を表す。これらの規
約は当業者には既知であり、これらの流れ図を参考に、
当業者は任意の適切なコンピュータ・プログラムミング
言語によりコードを作成することができる。

【００２３】本発明を実行するために好適なオペレーシ
ョンは、図３に示されるＳＮＡＰＩコマンド・インタフ
ェース（ＳＮＡＰＩ ＣＩ）、及び図４及び図５に示さ
れるＳＮＡＰＩサーバを含む２つの処理またはプログラ
ムとして実施される。

【００２４】図３を参照すると、ＳＮＡＰＩ ＣＩを実
行するのに好適なオペレーション３００が示される。Ｓ
ＮＡＰＩ ＣＩ３００のフローを理解するために、次の
要求がガイドラインとして提示される。ＳＮＡＰＩ Ｃ
Ｉ３００の各インスタンスは、単一の要求の期間だけ有
効となる。ＵＮＩＸシステムでは、全ての信号（割込
み）が無視される。ＳＮＡＰＩ ＣＩ３００はユーザ・
インタフェース・タイプ（コマンド・ラインまたは画面
パネル）の知識を含まない。ＳＮＡＰＩ３００は通信イ
ンタフェース（ＡＰＰＣ、ＣＰＩ−Ｃ、ＳＤＬＣ、イー
サネットなど）の知識を含まない。ＳＮＡＰＩ ＣＩ３
００はある独立言語型要求を受信し、ある独立言語型応
答を返却する。任意のコンテキストを維持することは要
求されない。

【００２５】ＳＮＡＰＩ ＣＩ３００の要求を理解した
上で、図３を参照すると、図３のブロック３０１はＳＮ
ＡＰＩ ＣＩ３００のあるインスタンスの開始を表す。
ＳＮＡＰＩ ＣＩ３００はユーザによって、要求される
引数を有するコマンド・ライン・プロンプトから開始さ
れる。これは総称画面インタフェースに容易に統合され
る。ＩＢＭのＡＩＸプラットフォーム上では、システム
管理インタフェース・ツール（ＳＭＩＴ）が、総称画面
インタフェース及びＭＯＴＩＦグラフィック・ユーザ・
インタフェースをフロントエンド・シェル・コマンドに
提供する。図３の処理ブロック３０２は入力引数の処理
の初期化ステップを表す。処理ブロック３０２では、Ｓ
ＮＡＰＩ ＣＩ３００は入力引数を文字バッファにフォ
ーマットし、これが図２のブロック２０４及び図４の４
００で示されるＳＮＡＰＩサーバへ要求として送信され
る。ＳＮＡＰＩ ＣＩ３００は複数のコマンド・ライン
引数を受信する。これらの引数はヌルで終了される自己
識別型の（ノン・ポジショナルな）英数字ストリングで
あり、要求及び要求引数を示す。処理ブロック３０２は
これらの入力引数をストリングに再フォーマットし、こ
れが図４の４００で示されるＳＮＡＰＩサーバへプロセ
ス間通信として送信される。また、処理ブロック３０２
のこの初期化機能の１部として、ＳＮＡＰＩ ＣＩ３０
０はその親プロセスＩＤを判断する。親プロセスは別の
処理を開始するプロセスである。従って、この環境で
は、親プロセスは画面インタフェースすなわち図２のブ
ロック２０１である。この親プロセスＩＤは、このセッ
ションにおけるＳＮＡＰＩサーバすなわち図４の４００
とのプロセス間通信のキーとして使用される。この親プ
ロセスＩＤは、このウィンドウまたは端末、現在のユー
ザ及びＳＮＡＰＩサーバすなわち図４の４００との間で
要求される１対１の関係を確立する。判断ブロック３０
３で示されるように、ＳＮＡＰＩ ＣＩ３００はこれが
新たな会話であるか否かを判断することができる。新た
な会話の場合、ＳＮＡＰＩ ＣＩ３００はこの会話を処
理するために、ＳＮＡＰＩサーバすなわち図４の４００
の新たなインスタンスを開始する。処理ブロック３０４
は新たなＳＮＡＰＩサーバすなわち図４の４００の生成
を表す。処理ブロック３０４は単一の入力引数により、
ＳＮＡＰＩサーバ（図４の４００）を開始する。入力引
数はＳＮＡＰＩ ＣＩ３００の親プロセスＩＤを含み、
これはＳＮＡＰＩ ＣＩ３００とＳＮＡＰＩサーバ（図
４の４００）との間のプロセス間通信（図２の２０３）
のために使用される。処理ブロック３０５では、要求が
ＳＮＡＰＩサーバ４００（図４の４００）に送信され
る。ＵＮＩＸプラットフォーム上では、ソケットがプロ
セス間通信（図２のブロック２０３）のために使用され
る。従って、処理ブロック３０５では、ＳＮＡＰＩ Ｃ
Ｉ３００はＳＮＡＰＩサーバ（図４の４００）に対しソ
ケットを開き、次に要求をＳＮＡＰＩサーバ（図４の４
００）に書込む。処理ブロック３０６は、ＳＮＡＰＩ
ＣＩ３００がＳＮＡＰＩサーバ（図４の４００）からの
応答を待機することを示し、この応答は要求の完了時に
送信される。応答が受信されると、ＳＮＡＰＩ ＣＩ３
００はＳＮＡＰＩサーバ（図４の４００）に対してソケ
ットを閉じる。処理ブロック３０７は画面インタフェー
ス（図２のブロック２０１）への応答の書込みを示す。
応答は文字ストリングであり、ＳＮＡＰＩサーバ（図４
の４００）からの追加の翻訳を伴わずに画面インタフェ
ース（図２のブロック２０１）に送信される。その後、
ＳＮＡＰＩ ＣＩ３００はブロック３０８で示されるよ
うに終了する。

【００２６】図４及び図５を参照すると、本発明の１部
であるＳＮＡＰＩサーバを実行するのに好適なオペレー
ション４００が示される。ＳＮＡＰＩサーバ４００のフ
ローを理解するために、次の要求がガイドラインとして
提示される。ＳＮＡＰＩサーバ４００はユーザがプログ
ラムを生成する期間有効である。この期間を以降ではセ
ッションと称する。ユーザは異なるウィンドウから別々
のセッションを有することが可能であるが、これらは別
々のセッションまたはプログラムとして扱われる。ユー
ザはある時刻において、特定のウィンドウまたは端末か
ら単一のセッション（プログラム）だけを有する。単一
のセッション内において、ＳＮＡＰＩサーバ４００は、
同一または異なる遠隔プログラムに対し、いくつかの明
らかに別々のリンクを確立する。これらのリンクの各々
は以降では会話と称される。会話はＳＮＡＰＩ ＣＩ
（図３の３００）から特定の遠隔パートナ・プログラム
に対する要求のグループである。ＳＮＡＰＩサーバ４０
０はそのイニシエータすなわちＳＮＡＰＩ ＣＩ（図３
の３００）から、プロセス間通信キーを入力パラメータ
として受信する。この情報はクライアントＳＮＡＰＩ
ＣＩ（図３の３００）からＳＮＡＰＩサーバ４００に転
送される。ＵＮＩＸでは、ＳＮＡＰＩ ＣＩ（図３の３
００）とＳＮＡＰＩサーバ４００との間のプロセス間通
信媒体として、ソケットが使用される。ＳＮＡＰＩ Ｃ
Ｉ（図３の３００）が要求を受信すると、これはソケッ
トを介してＳＮＡＰＩサーバ４００に接続され、この要
求を送信し、応答を受信し、その後、ＳＮＡＰＩサーバ
４００から切り離される。ＳＮＡＰＩ ＣＩ（図３の３
００）からのクライアント要求は、'RequestTypeParame
ter1 Parameter2 Parameter3 ．．．' の形式を取り、
ここでRequestTypeは要求される活動のタイプを識別す
る。各フィールドはブランク終了される。ParameterXは
要求を満たすために使用される自己識別型のパラメータ
である。各パラメータには識別フラグが前置され、従っ
て、パラメータはノン・ポジショナル（non-positiona
l）である。

【００２７】ＳＮＡＰＩサーバ４００はＳＮＡＰＩコア
機能及びＳＮＡＰＩサーバ・インタフェース特有機能を
含み、後者は以降ではＩＳＦと称される。コア機能は図
４に示され、インタフェース特有機能は図５に示され
る。コア機能は使用されるインタフェースに無関係に変
更されない。要求を適切なインタフェースに経路指定す
る役割をするモジュールを以降ではルータと称し、これ
によりＳＮＡＰＩサーバ・コア機能は、活動をＳＮＡＰ
Ｉサーバ・インタフェース特有機能に引き渡すことが可
能となる。

【００２８】ＳＮＡＰＩサーバ４００の詳細流れ図を説
明する前に、ＳＮＡＰＩサーバ４００により要求される
情報を構成するために使用されるファイル及びテーブル
を理解することが重要である。３つのタイプのファイル
が存在し、これらは本発明のＳＮＡＰＩサーバ４００部
分を実行するオペレーションを表すために、特に注目と
なるまた必要とされる情報である。第１に、各インタフ
ェース特有サブルーチンに対応してテンプレートが要求
される。テンプレート・ファイルは２つの部分を含む。
第１の部分はサブルーチン情報を記録するために使用さ
れる。特定パラメータの代わりにプレース・ホールダが
使用され、これらはログに書込まれる時に置換される。
Ｃ言語では、これらのプレース・ホールダは記述子であ
り、フォーマットされるプリント機能、"PRINTF"により
認識され置換される。第２の部分は生成されるソース・
コードの基本として使用される。ここでは代用は使用さ
れず、生成されるソース・コードのフォーマットがモジ
ュール化される。テンプレートはＳＮＡＰＩサーバ４０
０で要求されるインタフェース特有のプログラミングの
量を低減するために使用され、更にユーザが生成される
ソース・コードを個別化することを可能とする利点を提
供する。

【００２９】第２に、各異なるインタフェースに対応し
て機能テーブルが提供される。機能テーブルは、ＳＮＡ
ＰＩサーバ・コア機能における判断支援論理、ソース・
コード及びログの生成のために使用される。このテーブ
ルはインタフェース特有プログラミングを最小化する機
能も追加する。この機能テーブルのフォーマットは、Fu
nctionNum：FunctionName：CallModule：NumParameter
s：GlobalOffsetであり、FunctionNum はテーブル情報
を容易にアクセスするために、特定のインタフェース特
有機能に割当てられる数値である。FunctionNameはＩＳ
Ｆの名前である。CallModuleは、生成されるソース・コ
ードにおいてＩＳＦモジュールを呼出すために使用され
る名前である。NumParameters は、このＩＳＦに対応す
る入力パラメータの数である。GlobalOffsetは、生成さ
れるソース・コードにおいてグローバルとして宣言され
るパラメータの数である。特定のインタフェースに対応
する各ＩＳＦのエントリが、機能テーブルに含まれなけ
ればならない。

【００３０】第３にヘッダ・ファイルは、ＳＮＡＰＩサ
ーバ４００により要求される構成、環境、インタフェー
ス特有情報、及び現状態情報へのアクセスを単純化する
ために要求される情報をテーブル化するために使用され
る。ヘッダ・ファイルは更に、有限状態及びプロトコル
依存情報を翻訳するために使用されるテーブル情報を含
む。再度、特定のインタフェースに対応するプログラミ
ング要求を最小化するために、この情報は３つのカテゴ
リに分割される。すなわち、セッション特有情報、会話
特有情報、及び要求特有情報である。セッション特有情
報は使用されるインタフェースには無関係に同一であ
る。その構造はＳＮＡＰＩヘッダ・ファイル内において
以下のように定義される。

【表１】 struct session_str_s { int snasub; /* 現在のクライアント要求を示し、状態遷移の指標と*/ /* して使用される */ int num_functions; /* 支援されるＩＳＦの数 */ int type; /* 分散プログラム・タイプ */ /* （ソース／ターゲット） */ int log_msg; /* ソース・メッセージが対話式に記録されるべきかを*/ /* 示すフラグ */ int generate_source;/* ソース・コードが生成されるべきかを示すフラグ */ int program_fd; /* 生成されるソース・コードをアクセスするために */ /* 使用されるファイル記述子 */ char src_file[50]; /* 生成されるソース・コードの完全修飾されたファイ*/ /* ル名 */ char default_tmplt_dir[40]; /* テンプレートを含むディレクトリ名 */ char sendbuf[MAXBUF]; /*クライアントＳＮＡＰＩ ＣＩへの応答用バッファ*/ struct func_tab_s[40] { */ int func_num; /* 機能識別子 */ char func_name[20]; /* インタフェース・サブルーチン名 */ char module_name[40];/* 生成されるソース内で呼ばれるサブルーチン */ int num_parms; /* サブルーチンへ受渡されるパラメータ数 */ int global_offset; /* グローバル・パラメータが開始するオフセット */ int func_called; /* 機能が呼ばれた時に追跡するためのフラグ */ int(*subr_addr)(); /* 機能をアクセスするためのアドレス */ /* この要求を処理するための（ＩＳＦ） */ }; };

【００３１】会話特有情報は、インタフェース特有状
態、環境及び構成情報を維持するために要求される。こ
の構造は各インタフェースに対応して異なって定義され
る。しかしながら、この構造のアドレスだけがＳＮＡＰ
Ｉサブルーチン間で受渡されるため、コア依存性は存在
しない。ＣＰＩ−Ｃインタフェースの実施例におけるこ
の構造の例を次に示す。

【表２】 struct conversation_struct { char conversation_id[16]; /* この会話を識別する */ long cm_rc; /* 最終要求の結果を保持する */ int cid; /* 接続識別子 */ int state; /* 現在の会話状態 */ long send_type; /* 送信データの活動 */ long rcv_type; /* データの受信方法 */ long deal_type; /* 割当て解除活動 */ long err_direction; /* エラー発信方向 */ long ptr_type; /* 状態反転活動 */ long rts_rcvd; /* 遠隔要求用フラグ */ int translate; /* データ変換要求 */ char connection[15]; /* 構成データに対応するキー */ char TP_profile[30]; /* 構成データに対応するキー */ char TPN[9]; /* このプログラムの名前 */ };

【００３２】要求特有情報は、インタフェース特有機能
に渡される引数に対するポインタの配列として記憶され
る。

【００３３】図４を参照すると、本発明のＳＮＡＰＩサ
ーバ部分を実行するために好適なオペレーションが示さ
れる。ＳＮＡＰＩサーバは一般に４００と言及される。
ブロック４０１はＳＮＡＰＩサーバ４００の開始を示
す。ＳＮＡＰＩサーバ４００はＳＮＡＰＩ ＣＩ（図３
の３００）により開始され、単一の入力引数を渡され
る。ＳＮＡＰＩサーバ４００はプロセス間通信キーを受
信し、これからクライアント要求が受信される。この情
報はクライアントＳＮＡＰＩ ＣＩ（図３の３００）が
ＳＮＡＰＩサーバ４００を開始する時に、クライアント
ＳＮＡＰＩ ＣＩからＳＮＡＰＩサーバ４００に受渡さ
れる。ＵＮＩＸでは、プロセス間通信媒体としてソケッ
トが使用され、キーはＳＮＡＰＩ ＣＩの親プロセスの
プロセスＩＤを接尾部として含むソケット・ファイル名
である。クライアントＳＮＡＰＩ ＣＩ（図３の３０
０）が要求を受信すると、これはＳＮＡＰＩサーバ４０
０に接続され要求を転送し、待機して応答を受信する。
その後、ＳＮＡＰＩサーバ４００から切り離される。

【００３４】処理ブロック４０２はＳＮＡＰＩサーバ４
００のセッション初期化プロシージャを示す。処理のこ
の部分では、ＳＮＡＰＩサーバ４００はＵＮＩＸ信号
（割込み）の事象において実行される活動を設定する。
本発明のＵＮＩＸの実施例では信号は無視される。セッ
ション構造は全てヌル値に初期化される。ソース・コー
ドを生成するデフォルトもまた設定されるが、モジュー
ルを対話式に記録するデフォルトは設定されない。入力
パラメータとして受渡されるプロセス間通信キーが、ソ
ケットを初期化するために使用され、これは後に予想さ
れるクライアントからの接続要求を聞き入れるために使
用される。処理ブロック４０２と処理ブロック４０３の
間において、入力矢印は処理ループの開始を示し、これ
はＳＮＡＰＩサーバ４００の停止要求が受信されるまで
継続される。処理ブロック４０３は要求がクライアント
ＳＮＡＰＩ ＣＩ（図３の３００）から受信される様子
を示す。処理ブロック４０３において、ＳＮＡＰＩサー
バ４００はプロセス間通信ソケット上で要求を聴取す
る。クライアントＳＮＡＰＩ ＣＩ（図３の３００）が
ソケットに接続されると、ＳＮＡＰＩサーバ４００は入
力要求を読出す。処理ブロック４０４は入力要求を解析
するオペレーションを示す。入力要求は、ポインタを入
力要求の各フィールドの開始に設定することによりフォ
ーマットされる。クライアントＳＮＡＰＩ ＣＩ（図３
の３００）が要求を受信すると、これはソケットを介し
てＳＮＡＰＩサーバ４００に接続され、要求を送信し、
応答を受信し、その後ＳＮＡＰＩサーバ４００から切り
離される。クライアント要求は、'RequestType Paramet
er1 Parameter2 Parameter3．．．'の形式を取り、ここ
でRequestType は要求される活動のタイプを識別する。
各フィールドはブランクで終了される。ParameterXは自
己識別型のパラメータであり、要求を満たすために使用
される。各パラメータには識別フラグが前置され、従っ
てパラメータはノン・ポジショナルである。解析ルーチ
ンはポインタの配列を生成し、これらの各ポインタは要
求のフィールドを指示し、最大のポインタの指標はこれ
らのポインタと初期化されないポインタとの境界を定め
る。図４の処理ブロック４０５は、本発明のルータ機能
のオペレーションを示す。ルータ機能は、ＳＮＡＰＩサ
ーバ・コア機能からＳＮＡＰＩインタフェース特有機能
へのブリッジである。要求タイプに依存して、ルータ機
能はＳＮＡＰＩインタフェース特有機能モジュールまた
はＳＮＡＰＩコア機能モジュールのいずれかを呼出す。
ＳＮＡＰＩインタフェース特有機能モジュールが図５に
表される。ＳＮＡＰＩコア機能は、サーバ開始とサーバ
停止を含む。サーバ開始機能では、会話特有構造が全て
ヌル値に初期化される。入力テーブルが続くソース・コ
ード生成及び判断支援のために要求される、インタフェ
ース特有データを初期化するために読出される。サーバ
開始機能要求に渡されるパラメータは、ソース・コード
が生成されるか否か、モジュールが動的に記録されるか
否か、プログラマがパートナ分散プログラムに接触して
いるか否かを示す標識である。ソース・コードが生成さ
れると、グローバル・プログラム要求及び最小プログラ
ム要求をソース・ファイルに書込むことにより、ソース
・ファイルが準備される。ＳＮＡＰＩ ＣＩ（図３の３
００）に対する応答が後の応答のために準備される。サ
ーバ停止機能では、プログラマの活動と現在の構成との
間で検出される不一致が評価され、要求される構成の変
更が、ＳＮＡＰＩ ＣＩ（図３の３００）に対する応答
内に助言としてフォーマットされる。要求を処理する全
ての機能の１部として、要求の結果を示す応答がＳＮＡ
ＰＩ ＣＩ（図３の３００）に送信されるようにフォー
マットされる。処理ブロック４０６は、クライアントＳ
ＮＡＰＩ ＣＩ要求への応答を示す。本発明のこの部分
では、応答がＳＮＡＰＩ ＣＩ（図３の３００）に転送
され、次にクライアントＳＮＡＰＩ ＣＩ（図３の３０
０）がＳＮＡＰＩサーバ４００から切り離される。判断
ブロック４０７は要求がサーバ停止機能要求か否かを示
し、そうでない時には、ＳＮＡＰＩサーバ４００はルー
プして処理ブロック４０３に戻り、他のＳＮＡＰＩ Ｃ
Ｉクライアントが接続を試行しているかを聴取する。判
断ブロック４０７は、サーバ停止機能要求が受信された
か否かを示し、受信された場合には、ループが解除さ
れ、ＳＮＡＰＩサーバ４００はブロック４０８の処理を
継続して実行する。処理ブロック４０８はＳＮＡＰＩサ
ーバ４００の通信クリーンアップ部分を表す。処理ブロ
ック４０８において、全ての通信チャネルが順番にアク
セスを終了される。処理ブロック４０９は生成されるソ
ース・コードに対する最終出力を表す。ソース・コード
は現在進行中の全ての機能を終了することにより、完了
される。呼出されたがまだ含まれていない機能について
も書込まれる。最後に図４のブロック４１０において、
ＳＮＡＰＩサーバ４００が終了される。

【００３５】図５を参照すると、本発明のＳＮＡＰＩサ
ーバ・インタフェース特有機能部分を実行するのに好適
なオペレーションが示される。ＳＮＡＰＩサーバ・イン
タフェース特有機能は一般に５００と言及される。ＳＮ
ＡＰＩサーバ（図４の４００）及びＳＮＡＰＩサーバ・
インタフェース特有機能５００のフローを理解するため
に、次に示す要求がガイドラインとして提示される。４
つのタイプのＳＮＡＰＩサーバ・インタフェース特有機
能モジュールが存在し、次にこれらについて説明する。
オブジェクトはＳＮＡＰＩコア機能モジュールの機能を
最大化することにより、インタフェース特有のコーディ
ング量を最小化する。４つのモジュールのタイプは、Ｓ
ＮＡＰＩルータ、ＳＮＡＰＩ ＩＳＦ、ディスカバ（Di
scover）、及びネクスト・オペレーション（Nextop）で
ある。各インタフェース特有サブルーチンに対応して、
１つのインタフェース特有機能（ＩＳＦ）が提供され
る。各ＩＳＦは図５で示されるオペレーションと同一の
フローを有する。各ＩＳＦはＳＮＡＰＩルータにより呼
出され、ロギング及び他のコア・タイプ機能のためにＳ
ＮＡＰＩコア機能ルーチンを呼出す。各ＩＳＦは３つの
オペレーションを実行する。すなわち、インタフェース
・サブルーチンの呼出し、ＳＮＡＰＩロガ（logger）の
呼出し、プロトコル特有状態テーブルに従う状態／環境
情報の更新である。状態テーブルの例が付録Ａに示され
る。この情報は後の判断支援のために更新される。ＳＮ
ＡＰＩルータの唯一の目的は、ＳＮＡＰＩコア機能をＳ
ＮＡＰＩ ＩＳＦにブリッジすることである。ＳＮＡＰ
Ｉルータは単に別の機能であり、従ってコアから特有へ
のリンクは明らかである。Ｃ言語では、これはＩＳＦの
アドレスをテーブル化することにより、単一のステート
メントで足りる。ネクスト・オペレーション（Nextop）
機能は有限状態マシン・テーブルのインプリメンテーシ
ョンであり、これは有効な次のオペレーションを見い出
すために、現在の状態、環境及び構成を使用する。現在
の状態の更新の責任はＩＳＦに含まれ、これについては
図５のＩＳＦの説明の中で詳細に述べられる。複数の有
効なネクスト・オペレーションが存在する場合、これら
のオペレーションが可能性の高い順にリストされる。デ
ィスカバ機能は、入力パラメータに対応する最も賢明な
値を決定するために、状態テーブル及び構成情報を使用
する。従って、ユーザにとっての通常のフローは、助言
（ネクスト・オペレーションにより生成される）を受取
ることである。なぜなら、この助言にもとづきオペレー
ションが実行されるからである。次にユーザがオペレー
ションを選択すると、オペレーション画面が表示され
る。このオペレーションに対応して要求される入力パラ
メータが、既に記入された最も賢明な値（ディスカバに
より生成される）により表示される。従って、ほとんど
のオペレーションでは、ユーザはエンタ・キーを押すこ
とにより、'助言'を確認するだけでよい。

【００３６】各許可されるインタフェース特有活動に対
応してＩＳＦが提供されるが、各ＩＳＦのオペレーショ
ンは図５に示されるオペレーションと類似する。図５に
示されるオペレーションは各ＩＳＦに対応するモデルで
ある。ＳＮＡＰＩサーバ・インタフェース特有機能は、
一般に５００と言及される。図５を参照すると、ブロッ
ク５０１で、ＳＮＡＰＩルータ機能によりＩＳＦが開始
される。ブロック５０２は要求パラメータのフォーマッ
トまたは構造へのロードを示し、これらがインタフェー
ス特有サブルーチンに渡される。処理ブロック５０３
は、処理ブロック５０２でフォーマットされた引数を使
用して、ユーザ要求を実行するために要求されるサブル
ーチンを実行し、その結果をテストする。処理ブロック
５０３は更に、これらの引数を使用することにより、シ
ステム環境、パートナ分散プログラム、または構成によ
り引き起こされる変更を認識する。判断ブロック５０４
はサブルーチンが成功したか否かを判断する。サブルー
チンが成功して実行された場合、ＳＮＡＰＩサーバＩＳ
Ｆ５００は処理ブロック５０６に移行する。一方、サブ
ルーチンが失敗に終わると、ＳＮＡＰＩサーバＩＳＦ５
００は処理ブロック５０５に移行する。処理ブロック５
０５では、ＳＮＡＰＩ ＣＩ（図３の３００）に対して
失敗を示す応答をフォーマットする。処理ブロック５０
５から、ＳＮＡＰＩ ＩＳＦ５００は処理ブロック５０
８に移行する。判断ブロック５０４に戻り、インタフェ
ース特有サブルーチンが成功した場合、ＳＮＡＰＩ Ｉ
ＳＦ５００はブロック５０６に移行し、クライアントＳ
ＮＡＰＩ ＣＩ（図３の３００）に対して成功を示す応
答をフォーマットする。その後、処理ブロック５０７が
ＳＮＡＰＩコア・ロギング機能を呼出す。ＳＮＡＰＩコ
ア・ロギング機能はソース・ファイルに適切なコードを
追加し、ソース・コード生成テーブルを更新し、プログ
ラム開発に関わるユーザを指導するために、ログ・モジ
ュールを生成する。処理ブロック５０８は状態及び環境
情報の更新を示す。処理ブロック５０８は以下に示すリ
ストに表される情報、及びテストされたユーザ要求の結
果を使用し、判断支援のために使用される有限状態追跡
を更新する。ブロック５０９はインタフェース特有機能
の出力を示し、フローは図４のブロック４０６に復帰す
る。

【００３７】

【表３】

【００３８】

【表４】

【００３９】

【表５】

【００４０】

【表６】

【００４１】

【表７】

【００４２】

【表８】

【００４３】リストは、図５のブロック５０８で状態及
び環境変数を更新するために使用されるＣＰＩ−Ｃ有限
状態マシンを表すテーブルである。リストの列の先頭
は、このインタフェースの有効状態を示す。リストの行
の先頭は、このインタフェースにおいて有効な活動を示
す。矢印記号は、機能が相互参照状態から有効か否かを
示す。このテーブルは、ローカル・プログラムまたはパ
ートナ・プログラムによる活動の結果、どの状態に入力
したかを判断するために使用される。テーブルは更に、
ユーザが実効可能であり、構成の範囲内に含まれる有効
で '最も可能性の高い' 活動を決定するために使用され
る。

【００４４】リストに示される関係を明らかにするため
に、リストの１ページ目の６番目の入力に相当する機能
ＣＭＤＥＡＬ（ＣＯＮＦＩＲＭ）を参照されたい。リス
トは、ＣＭＤＥＡＬ（ＣＯＮＦＩＲＭ）がＲＥＳＥＴ状
態から呼ばれた場合に、パラメータ・チェック・エラー
（ｐｃ）になることを示す。ＣＭＤＥＡＬ（ＣＯＮＦＩ
ＲＭ）がＩＮＩＴＩＡＬＩＺＥ、ＲＥＣＥＩＶＥ、ＣＯ
ＮＦＩＲＭ、ＣＯＮＦＩＲＭ−ＳＥＮＤ、またはＣＯＮ
ＦＩＲＭ−ＤＥＡＬＬＯＣＡＴＥ状態から呼ばれると、
ＣＭＤＥＡＬ（ＣＯＮＦＩＲＭ）は状態チェック・エラ
ー（ｓｃ）となる。しかしながら、ＣＭＤＥＡＬ（ＣＯ
ＮＦＩＲＭ）はＳＥＮＤまたはＳＥＮＤ−ＰＥＮＤＩＮ
Ｇ状態からは有効である。ＣＭＤＥＡＬ（ＣＯＮＦＩＲ
Ｍ）がＳＥＮＤまたはＳＥＮＤ−ＰＥＮＤＩＮＧ状態か
ら呼ばれ、復帰コードが実行成功（ｏｋ）の場合、結果
状態はＲＥＳＥＴである。ＣＭＤＥＡＬ（ＣＯＮＦＩＲ
Ｍ）がＳＥＮＤまたはＳＥＮＤ−ＰＥＮＤＩＮＧ状態か
ら呼ばれ、パートナ・プログラムがＣＭＤＥＡＬ（ＡＢ
ＥＮＤ）を発行しているか（ｄａ）、または通信リンク
が失敗すると（ｒｆ）、結果状態はＲＥＳＥＴである。
ＣＭＤＥＡＬ（ＣＯＮＦＩＲＭ）がＳＥＮＤ状態から呼
ばれ、パートナ・プログラムがＣＭＡＣＣＰの発行中に
割当てエラー（ａｅ）に遭遇した時、結果状態はＲＥＳ
ＥＴである。ＣＭＤＥＡＬ（ＣＯＮＦＩＲＭ）がＳＥＮ
Ｄ−ＰＥＮＤＩＮＧ状態から呼ばれる時には、割当てエ
ラー（ａｅ）の可能性はない。ＣＭＤＥＡＬ（ＣＯＮＦ
ＩＲＭ）がＳＥＮＤまたはＳＥＮＤ−ＰＥＮＤＩＮＧ状
態から呼ばれ、遠隔パートナ・プログラムがエラーによ
り入力データを消去した場合（ｅｐ）、結果状態はＲＥ
ＣＥＩＶＥである。ＣＭＤＥＡＬ（ＣＯＮＦＩＲＭ）が
ＳＥＮＤまたはＳＥＮＤ−ＰＥＮＤＩＮＧ状態から無効
パラメータを伴って呼ばれる場合（ｐｃ）、状態はＳＥ
ＮＤまたはＳＥＮＤ−ＰＥＮＤＩＮＧをそれぞれ維持す
る。ＣＭＤＥＡＬ（ＣＯＮＦＩＲＭ）がＳＥＮＤ状態か
ら呼ばれ、状態チェック（ｓｃ）となる場合、状態はＳ
ＥＮＤを維持する。ＣＭＤＥＡＬ（ＣＯＮＦＩＲＭ）が
ＳＥＮＤ−ＰＥＮＤＩＮＧ状態から呼ばれる時には、状
態チェック・エラー（ｓｃ）の可能性はない。

【００４５】

【発明の効果】以上説明したように、本発明によれば、
複雑な有限状態駆動型データ処理プログラムの設計、開
発、及びテストにおけるプロジェクト要求を通じ、ユー
ザを手引きするための方法及び装置が提供される。

【図面の簡単な説明】

【図１】本発明の方法を実施し、本発明の装置の１部を
形成するために使用されるデータ処理システムのブロッ
ク図である。

【図２】本発明の実施例のブロック図である。

【図３】本発明のコマンド・インタプリタ部分を実施す
るために好適なオペレーションを表す流れ図である。

【図４】本発明のサーバ部分を実施するために好適なオ
ペレーションを表す流れ図である。

【図５】本発明のサーバ部分のインタフェース特有部分
を実施するために好適な、図４に続くオペレーションを
表す流れ図である。

【符号の説明】

２０ 通信ポート １００ データ処理システム ２０１ 画面インタフェース ２０３ プロセス間通信

Claims (18)

【特許請求の範囲】
1. 【請求項１】有限状態駆動型データ処理プログラムの設
   計、開発、及びテストを通じてユーザを手引きする方法
   であって、 環境の要求に従い、上記有限状態駆動型データ処理プロ
   グラムの設計に関する助言をユーザに提供するステップ
   と、 コードが生成される時に上記コードをテストするステッ
   プと、 環境の要求に適合するソース・コードを生成するステッ
   プと、 を含む方法。
2. 【請求項２】上記有限状態駆動型データ処理プログラム
   の設計に関する助言をユーザに提供する上記ステップ
   が、 追跡情報を生成するために、上記有限状態駆動型データ
   処理プログラムの設計に関する情報を追跡するステップ
   と、 有効な活動を決定するために、上記追跡情報に従い有限
   状態マシン情報を翻訳するステップと、 を含む、請求項１記載の方法。
3. 【請求項３】コードが生成される時に上記コードをテス
   トする上記ステップが、 ユーザ要求をファンクションに翻訳するステップと、 上記ファンクションを実行するステップと、 上記ファンクションの実行結果を表明するステップと、 を含む、請求項１記載の方法。
4. 【請求項４】環境の要求に適合するソース・コードを生
   成する上記ステップが、 ソース・コード・ファイルをグローバル情報により初期
   化するステップと、 上記ソース・コード・ファイルをユーザ要求を支援する
   コードにより更新するステップと、 を含む、請求項１記載の方法。
5. 【請求項５】上記有限状態駆動型データ処理プログラム
   の設計に関する情報を追跡する上記ステップが、 上記有限状態駆動型データ処理プログラムの実行結果に
   従い、上記有限状態駆動型データ処理プログラムの状態
   情報を追跡するステップと、 上記有限状態駆動型データ処理プログラムのパートナ・
   プログラムの実行結果に従い、上記有限状態駆動型デー
   タ処理プログラムの上記状態情報を追跡するステップ
   と、 構成情報を追跡するステップと、 システム環境情報を追跡するステップと、 を含む、請求項２記載の方法。
6. 【請求項６】有効な活動を決定するために、上記追跡情
   報に従い有限状態マシン情報を翻訳する上記ステップ
   が、 次のユーザ要求によるアクセスに対応して有限状態マシ
   ン情報をテーブル化するステップと、 有限状態駆動型データ処理プログラムの現状態を、次の
   ユーザ要求として許可される活動を決定するための指標
   として使用することにより、有限状態マシン情報をアク
   セスするステップと、 上記追跡情報により、上記許可される活動を制限するス
   テップと、 次のユーザ要求として許可される活動に変更を助言とし
   て反映させるために、上記追跡情報を更新するステップ
   と、 を含む、請求項２記載の方法。
7. 【請求項７】有限状態駆動型データ処理プログラムの設
   計、開発、及びテストを通じてユーザを手引きする装置
   であって、 環境の要求に従い、上記有限状態駆動型データ処理プロ
   グラムの設計に関する助言をユーザに提供する手段と、 コードが生成される時に、上記コードをテストする手段
   と、 環境の要求に適合するソース・コードを生成する手段
   と、 を含む装置。
8. 【請求項８】上記有限状態駆動型データ処理プログラム
   の設計に関する助言をユーザに提供する上記手段が、 追跡情報を生成するために、上記有限状態駆動型データ
   処理プログラムの設計に関する情報を追跡する手段と、 有効な活動を決定するために、上記追跡情報に従い有限
   状態マシン情報を翻訳する手段と、 を含む、請求項７記載の装置。
9. 【請求項９】コードが生成される時に、上記コードをテ
   ストする上記手段が、 ユーザ要求をファンクションに翻訳する手段と、 上記ファンクションを実行する手段と、 上記ファンクションの実行結果を表明する手段と、 を含む、請求項７記載の装置。
10. 【請求項１０】環境の要求に適合するソース・コードを
    生成する上記手段が、 ソース・コード・ファイルをグローバル情報により初期
    化する手段と、 上記ソース・コード・ファイルをユーザ要求を支援する
    コードにより更新する手段と、 を含む、請求項７記載の装置。
11. 【請求項１１】上記有限状態駆動型データ処理プログラ
    ムの設計に関する情報を追跡する上記手段が、 上記有限状態駆動型データ処理プログラムの実行結果に
    従い、上記有限状態駆動型データ処理プログラムの状態
    情報を追跡する手段と、 上記有限状態駆動型データ処理プログラムのパートナ・
    プログラムの実行結果に従い、上記有限状態駆動型デー
    タ処理プログラムの上記状態情報を追跡する手段と、 構成情報を追跡する手段と、 システム環境情報を追跡する手段と、 を含む、請求項８記載の装置。
12. 【請求項１２】有効な活動を決定するために、上記追跡
    情報に従い有限状態マシン情報を翻訳する上記手段が、 次のユーザ要求によるアクセスに対応して、有限状態マ
    シン情報をテーブル化する手段と、 有限状態駆動型データ処理プログラムの現状態を、次の
    ユーザ要求として許可される活動を決定するための指標
    として使用することにより、有限状態マシン情報をアク
    セスする手段と、 上記追跡情報により、上記許可される活動を制限する手
    段と、 次のユーザ要求として許可される活動に変更を助言とし
    て反映させるために、上記追跡情報を更新する手段と、 を含む、請求項８記載の装置。
13. 【請求項１３】有限状態駆動型データ処理プログラムの
    設計、開発、及びテストを通じ、ユーザにガイダンスを
    提供する方法であって、 環境の要求に従い、上記有限状態駆動型データ処理プロ
    グラムの設計に関する助言をユーザに提供する手段を提
    供するステップと、 コードが生成される時に、上記コードをテストする手段
    を提供するステップと、 環境の要求に適合するソース・コードを生成する手段を
    提供するステップと、 を含む方法。
14. 【請求項１４】上記有限状態駆動型データ処理プログラ
    ムの設計に関する助言をユーザに提供する手段を提供す
    るステップが、 追跡情報を生成するために、上記有限状態駆動型データ
    処理プログラムの設計に関する情報を追跡する手段を提
    供するステップと、 有効な活動を決定するために、上記追跡情報に従い有限
    状態マシン情報を翻訳する手段を提供するステップと、 を含む、請求項１３記載の方法。
15. 【請求項１５】コードが生成される時に、上記コードを
    テストする手段を提供する上記ステップが、 ユーザ要求をファンクションに翻訳する手段を提供する
    ステップと、 上記ファンクションを実行する手段を提供するステップ
    と、 上記ファンクションの実行結果を表明する手段を提供す
    るステップと、 を含む、請求項１３記載の方法。
16. 【請求項１６】環境の要求に適合するソース・コードを
    生成する手段を提供する上記ステップが、 ソース・コード・ファイルをグローバル情報により初期
    化する手段を提供するステップと、 上記ソース・コード・ファイルをユーザ要求を支援する
    コードにより更新する手段を提供するステップと、 を含む、請求項１３記載の方法。
17. 【請求項１７】上記有限状態駆動型データ処理プログラ
    ムの設計に関する情報を追跡する手段を提供する上記ス
    テップが、 上記有限状態駆動型データ処理プログラムの実行結果に
    従い、上記有限状態駆動型データ処理プログラムの状態
    情報を追跡する手段を提供するステップと、 上記有限状態駆動型データ処理プログラムのパートナ・
    プログラムの実行結果に従い、上記有限状態駆動型デー
    タ処理プログラムの上記状態情報を追跡する手段を提供
    するステップと、 構成情報を追跡する手段を提供するステップと、 システム環境情報を追跡する手段を提供するステップ
    と、 を含む、請求項１４記載の方法。
18. 【請求項１８】有効な活動を決定するために、上記追跡
    情報に従い有限状態マシン情報を翻訳する手段を提供す
    る上記ステップが、 次のユーザ要求によるアクセスに対応して、有限状態マ
    シン情報をテーブル化する手段を提供するステップと、 有限状態駆動型データ処理プログラムの現状態を、次の
    ユーザ要求として許可される活動を決定するための指標
    として使用することにより、有限状態マシン情報をアク
    セスする手段を提供するステップと、 上記追跡情報により、上記許可される活動を制限する手
    段を提供するステップと、 次のユーザ要求として許可される活動に変更を助言とし
    て反映させるために、上記追跡情報を更新する手段を提
    供するステップと、 を含む、請求項１４記載の方法。