JPH07168708A

JPH07168708A - 交換サービスシナリオ設計支援システム

Info

Publication number: JPH07168708A
Application number: JP31474993A
Authority: JP
Inventors: Tetsuro Nishida; 哲朗西田; Hirohisa Yamamoto; 博久山本
Original assignee: NEC Corp
Current assignee: NEC Corp
Priority date: 1993-12-15
Filing date: 1993-12-15
Publication date: 1995-07-04

Abstract

(57)【要約】【目的】交換システムの付加サービス設計にあたり、
設計者はメニュー問い合わせに順次応答するだけでサー
ビス定義が自動的に作成されるシステムを提供する。【構成】問い合わせパターンを記述したメニュー記述
ファイル３から個々の問い合わせを木構造形態でつなげ
たスケルトンデータを生成し、問い合わせを設計者６に
表示し、当該問い合わせ結果の情報を木構造データとし
てサービス定義を構築するエディタ制御部１１を有す
る。エディタ生成部１２は、構築されたサービス定義を
評価し、サービスコードに変換してサービスコードファ
イル５に出力する。【効果】サービス設計の容易化と開発効率の大幅な向
上に寄与する。

Description

【発明の詳細な説明】

【０００１】

【産業上の利用分野】本発明は、交換サービスシナリオ
設計支援システムに関し、特にユーザとの対話形式によ
るメニュー問い合わせ方式により交換システムの付加サ
ービスシナリオを生成する交換サービスシナリオ設計支
援システムに関する。

【０００２】

【従来の技術】現在、ＰＢＸ、局用交換機、ＡＴＭ交換
機などの交換システムで提供される付加サービスは多種
多用化が進み、その付加サービスを実現するために必要
とされるソフトウェアの開発量は膨大なものとなってき
ており、付加サービスソフトウェア開発の生産性及び品
質の向上を図る事が大変重要な課題となっている。

【０００３】このような状況下において、付加サービス
の開発効率を大幅に向上させるための手段として、付加
サービス制御方式がある。（「付加サービス制御方
式」、嶋、児玉他、電子情報通信学会技報、ＳＳＥ９１
ー８、１９９１．５参照）

【発明が解決しようとする課題】この付加サービス制御
方式（以下「本制御方式」という）は、メッセージの処
理単位であるシナリオと、そのシナリオが基本呼制御か
ら起動される条件記述、シナリオ処理から基本呼制御に
復帰するポイント記述、サービスで使用するデータ記述
などの集まりにより１つのサービスを実現するもので、
付加サービスの着脱性、独立性、記述性、移植性が考慮
されている。

【０００４】図１２に示すように、本制御方式では、基
本呼制御においてサービスシナリオの起動をチェックす
るポイントをＴＣＰ（トリガー・チェック・ポイン
ト）、サービスシナリオが復帰できるポイントをＰＩＣ
（ポイント・イン・コール）と呼ぶ。また、シナリオは
シグナル発生によって起動することも可能である。

【０００５】本制御方式に基けば、各シナリオを単純な
処理単位にすることで、制御プリミティブ部品やサービ
ス処理部品、シナリオ起動条件部品、復帰ポイント指定
部品、データ記述部品などを組み合わせるだけでサービ
スの定義を可能とする共通ライブラリを用意すること
は、比較的容易に実現できる。

【０００６】そして更に、部品組み合わせの集合である
サービス定義を入力とし、共通ライブラリコールを内容
とするＣ言語のソースコードを生成する変換系が用意で
きれば、付加サービスのコーディングは自動化すること
ができる。

【０００７】しかし、このような従来の付加サービス制
御方式は、サービス定義の共通ライブラリ及び変換系が
用意できれば、付加サービスの生産性、品質の両面での
向上が見込める訳であるが、抽象度が高くなったとはい
え、サービスを定義するには変換系の入力形式を理解す
る必要があるので、Ｃ言語で直接コーディングするより
も若干生産性が向上する程度に留まってしまう。

【０００８】つまり、設計者は設計しようとする付加サ
ービスの知識以外にもその付加サービスを定義するため
に使用するプログラミング言語に対する理解を必要とす
るという課題がある。

【０００９】従って、本発明は、サービス定義作業を積
極的に支援できるツールとして、設計者が自分が設計す
る付加サービス以外の知識を必要とせずにＧＵＩ（グラ
フィック・ユーザ・インタフェース）を用いたさまざま
なメニュー問い合わせを行ないながら付加サービスを記
述できる環境を提供し、更なる付加サービス開発の生産
性向上を実現することを目的とする。

【００１０】

【課題を解決するための手段】上述した問題点を解決す
るため、本発明の交換サービスシナリオ設計支援システ
ムでは、メニュー問い合わせ方式によって、用意された
処理部品からサービス定義を構成することで、エディタ
使用記述に規定される入力形式に沿ったサービス定義の
記述作業を自動化したものである。

【００１１】本発明の交換サービスシナリオ設計支援シ
ステムは、シナリオ設計の出力であるサービス定義を作
成するにあたり、設計者に対する問い合わせパターンを
記述したメニュー記述手段と、このメニュー記述手段か
ら個々の問い合わせを木構造形態でつなげたスケルトン
データを生成し、設計者に問い合わせを表示し、当該問
い合わせ結果で設計者が選択した情報を木構造データと
してサービス定義を構築する編集制御手段とを有するこ
とを特徴とする。

【００１２】

【実施例】以下、本発明について図面を参照して説明す
る。

【００１３】図１は本発明に係る交換サービスシナリオ
設計支援システム（以下「シナリオエディタシステム」
という）のシステム構成を示すブロック図である。

【００１４】同図において、シナリオエディタ１はエデ
ィタ制御部１１とエディタ生成部１２とを有している。

【００１５】エディタ制御部１１は、シナリオエディタ
システムにより実行される設計者に対する問い合わせ手
段を定義したメニュー記述ファイル３及び基本呼ＳＤＬ
図４を用いて問い合わせ手段を呼び出し、更に設計者に
より実行された実行結果をサービスファイル２にセーブ
する。

【００１６】エディタ生成部１２は、設計者により実
行、構築されサービスファイル２にセーブされている付
加サービスを評価し、更に当該付加サービス内容をＣ言
語等のサービスソースコードに変換してサービスコード
ファイル５に出力する。

【００１７】設計者６は、このようなシナリオエディタ
に向かい、図示しない表示手段、入力手段を用いてメニ
ュー問い合わせに対応しつつサービス定義を編集し、途
中結果はサービスファイル２としてセーブする。サービ
ス定義が完了すると、サービス定義の整合性の確認と、
変換系の起動により当該サービス定義からサービス定義
のサービスコード（例えばＣソースコード）を獲得す
る。

【００１８】シナリオエディタ１は起動時にメニュー記
述ファイル３と基本呼制御のＳＤＬ図４を読み込む。

【００１９】メニュー記述ファイル３には、サービス定
義の際の問い合わせパターン、サービスコード生成フォ
ーマットなどが記述してあり、この記述を追加変更する
だけで多数の種別のサービスがシナリオエディタで定義
可能となる。

【００２０】ＳＤＬ図４はサービス定義の際の補助入力
用に利用する。

【００２１】本発明のシナリオエディタシステムでは、
サービスは全体として１つの木構造で表現されており、
一連のメニュー問い合わせは、対応するサービスのサブ
木構造を編集するものとなる。

【００２２】メニュー問い合わせは、それまでの問い合
わせの文脈を自動的に判断して進められるため、設計者
はサービス定義の階層的な木構造を意識したり、不要な
メニュー選択をする必要がないという特長をもつ。

【００２３】次にメニュー問い合わせ方式について説明
する。図２は、本実施例のシナリオエディタシステムに
おけるメニュー問い合わせ方式が有する機能構成を示す
ブロック図である。

【００２４】同図において、メニュー記述４１は、質問
の形態、文脈等を定義する。

【００２５】スケルトンデータ４３は、メニュー記述４
１が定義した質問の１つ１つを木構造形態で表現してい
るデータである。

【００２６】スケルトンデータ構築手段４２は、このス
ケルトンデータ４３を生成する。

【００２７】問い合わせ手段４４は、スケルトンデータ
４３、現在までに構築された構文木データ４５を参照、
評価しながら質問を表示して、設計者により選択された
結果を木構造形態で表現した構文木データ４５として構
築する。

【００２８】構造データ構築手段４６は、スケルトンデ
ータ４３、構文木データ４５を参照しながら構造データ
４７を構築する。

【００２９】次に、図２のそれぞれのブロックについて
説明する。

【００３０】メニュー記述４１は、メニューの骨組みと
なるスケルトンを定義する複数のスケルトンルールの集
合により構成され、問い合わせを階層的に表現してい
る。

【００３１】メニュー記述４１では、スケルトン階層を
簡単にして見通しを良くするように、スケルトンルール
はトップダウンで文脈自由に記述してリソース値で文脈
を自動判断させるようにしている。

【００３２】個々のスケルトンルールは以下のような記
述形式を取る。

【００３３】スケルトン名＝スケルトン種別パラメータリソース名リソース値リソース名リソース値スケルトンは問い合わせの形態によって以下に示す種別
のものがあり、それぞれのスケルトンは持てるパラメー
タ、リソース名が異なる。

【００３４】これらを組合せることにより様々な問い合
わせ形態を実現することができる。

【００３５】「field」：文字列を入力させる問い合わ
せを行う。パラメータは持たず木構造の末端に位置す
る。

【００３６】「oneOf」：候補となり得る固定個の子ス
ケルトンをパラメータとして持ち、その中から１つを選
択させ、選んだ子スケルトンの問い合わせを行う。

【００３７】「oneOfList」：既に構築されている「lis
t」の要素を選択要素とすることをパラメータで指定
し、問い合わせを行いその中から１つを選択させる。

【００３８】「oneOfMap」：候補となり得る固定個の子
スケルトンをパラメータとして持ち、二次元的な候補か
ら選択させ、選んだ子スケルトンの問い合わせを行う。

【００３９】「struct」：固定個の子スケルトンをパラ
メータに持ち順番に子スケルトンの問い合わせを行う。

【００４０】「randomStruct」：固定個の子スケルトン
をパラメータに持ち、問い合わせで選ばれた子スケルト
ンの問い合わせを行う。

【００４１】「list」：パラメータで示される子スケル
トンを要素として不定個持つことが出来る。編集時には
要素の追加、変更、削除、カット、コピー、ペースト等
の編集機能を提供する。

【００４２】「quote」：問い合わせは持たず、木構造
の末端に位置する。定数値の定義を行う。

【００４３】また、各スケルトンが持つことのできる代
表的なリソースを以下に示す。

【００４４】リソースは各リソースの性格上、スケルト
ンによってその持つことができるリソースが異なる。

【００４５】「format」：構造データへの変換フォーマ
ットを定義する。全スケルトン種別で持つことが可能で
ある。

【００４６】「message」：問い合わせを行うスケルト
ンが持て、問い合わせ項目と共に表示するテキストを定
義する。

【００４７】「maxChars」：入力可能最大文字数を定義
する。「field」スケルトン専用のリソース。

【００４８】「menuItem」：選択項目としての表示テキ
ストを定義する。「oneOf」,「oneOfList」,「oneOfMa
p」,「randomStruct」スケルトンが持てる。

【００４９】「where」：選択項目の候補条件を指定す
る。「oneOf」,「oneOfList」,「oneOfMap」スケルトン
が持てる。

【００５０】「check」：構築した構文木データの整合
性を式で指定する。全スケルトン種別で持つことが可能
である。

【００５１】シナリオエディタ１の内部では、問い合わ
せは、問い合わせ結果を保持する構文木と呼ぶデータに
対する編集操作として位置付けられている。

【００５２】構文木はスケルトンをクラスとするインス
タンスであり、スケルトンはスケルトン種別をクラスと
するインスタンスである。

【００５３】構文木に対する編集操作は構文木からスケ
ルトンを介して辿ったスケルトン種別に記載してあり、
スケルトン種別が同じであれば処理手続きは同じであ
る。

【００５４】構文木は編集前は不完全な木であり、正規
に編集が完了した時は完全な木となる。

【００５５】次にスケルトンデータ生成手段４２と、ス
ケルトンデータ４３を説明する。

【００５６】スケルトンデータ４３は、メニュー記述４
１のシステム内部形式である木構造の形態をした静的な
データで、システム起動時にスケルトンデータ生成手段
４２により構築される。スケルトンデータ４３のそれぞ
れの要素には、問い合わせ手段の手続きポインタ、リソ
ースデータへのポインタを持ち、子スケルトンを持つス
ケルトンの場合は子スケルトンへのポインタも有する。

【００５７】次に問い合わせ手段４４と、構文木データ
４５を説明する。

【００５８】問い合わせ手段４４はスケルトン種別毎に
存在し、現在のスケルトンデータを４３を上下に辿りな
がら問い合わせを進め、結果として構文木データ４５を
追加、削除しながら構築を行う。

【００５９】問い合わせは全てのスケルトン種別で行わ
れるとは限らず、種類によっては行われないものもあ
る。

【００６０】また、問い合わせ手段４４は１つ１つの質
問に対して存在するのではなく、スケルトン種別毎に１
つ存在し同じスケルトン種別であれば汎用的に使用でき
る。

【００６１】構文木データ４５は木構造の形式をとる動
的なデータでそれぞれは親構文木へのポインタ、対応す
るスケルトンデータへのポインタ、子構文木へのポイン
タ等を有する。

【００６２】次に構造データ構築手段４６と、構造デー
タ４７を説明する。

【００６３】構造データ構築手段４６はスケルトン種別
毎に存在し、構文木データ４５の最上位構文木から階層
的に各構文木を辿り、各構文木から指されるスケルトン
の「format」リソースを参照して、目的とする構造デー
タ４７を組み立てる。

【００６４】次に簡単な問い合わせ例を用いて本発明の
動作を説明する。

【００６５】図３は問い合わせ例の流れ図である。３つ
の質問があり、初めに「field」型のメニューＡ（menu
-a）を用いて問い合わせを行い、テキストを入力する
（ＳＴ３１）。次に「oneOf」型のメニューＢ（menu-
b）を用いて問い合わせを行い、単一項目（x 叉はy ）
を選択する（ＳＴ３２）。最後に、「oneOf」型のメニ
ューＣ（menu-c）を用いて単一選択するものである。な
お、ここではメニューＢの問い合わせによる選択結果に
よってメニューＣでの選択候補が異なることとしてい
る。

【００６６】図４は問い合わせ例を実現するためのメニ
ュー記述の例を表した図である。

【００６７】なお、図中には行番号が有るが、これは説
明を行うために参考として付与したものである。

【００６８】この例では前述した中の４種類のスケルト
ン種別を用いて記述を行っている。

【００６９】以下に説明を行う。

【００７０】３−５行の「inquiry」スケルトン記述
は、「struct」型スケルトンでメニューＡ（menu-a）メ
ニューＢ（menu-b）、メニューＣ（menu-c）スケルトン
の問い合わせを順番に行う事を定義している。

【００７１】７−１０行の「menu-a」スケルトン記述
は、「field」型スケルトンで定義してテキストの入力
を問い合わせている。

【００７２】１２−１７行の「menu-b」スケルトン記述
は、「oneOf」型スケルトンで「item-x」、「item-y」
スケルトンから単一選択することを定義している。

【００７３】１９−３４行の「office」スケルトン記述
は、「oneOf」型スケルトンで「item-p」、「item-
q」、「item-r」スケルトンから単一選択することを定
義している。

【００７４】２６−３４行の「where」リソースの式が
あるが既に選択された「menu-b」スケルトンでの選択結
果のより選択候補を変えることを定義している。

【００７５】３６−４８行の各「quote」型スケルトン
記述は、「quote」型スケルトンで末端に位置する各ス
ケルトンを定義している。

【００７６】図５は、スケルトンデータ生成手段４２が
図１のメニュー記述ファイル３から構築したスケルトン
データの木構造を示す図である。スケルトンデータ生成
手段４２はメニュー記述上のスケルトン名、パラメー
タ、リソースを解釈して「%inquiry」をルートとしたス
ケルトンデータを構築する。

【００７７】図５のスケルトンデータには、問い合わせ
に使う表示テキスト、構造データのフォーマット等もリ
ソースデータとして格納され、問い合わせの文脈全てを
表現する。

【００７８】図６は「struct」問い合わせ手段の流れ
図、図７は「field」問い合わせ手段の流れ図、図８は
「oneOf」問い合わせ手段の流れ図、図９は「quote」
問い合わせ手段の流れ図、図１０は構文木データの木構
造を示す図である。

【００７９】これらの図と前述した図５のスケルトンデ
ータの木構造を示す図を使って問い合わせの流れに従い
説明する。

【００８０】（１）問い合わせ手段の主となる処理が最
初の問い合わせの「struct」構文木（図１０の１０１）
を作成する。

【００８１】構文木内に存在するインデックス情報には
０が初期設定される。

【００８２】「struct」構文木の場合は配下の子構文木
（図１０の１０２、１０３、１０５）も同時に作成して
繋がれる。

【００８３】これらの構文木作成の手段は、問い合わせ
手段に内包されてスケルトン種別毎の手段が存在する。

【００８４】問い合わせ手段の主となる処理はカレント
構文木を「struct」構文木にして、カレント構文木のス
ケルトン種別である「struct」問い合わせ手段を呼び出
す。

【００８５】（２）「struct」問い合わせ手段において
最後の子構文木まで問い合わせが終了しているかのチェ
ックを行う（図６のＳＴ６１）。

【００８６】この場合はまだ完了していないのでインデ
ックスを１加算して（図６のＳＴ６２）、カレント構文
木をインデックスに示された番号の子構文木（図１０の
１０２）にしてから（図６のＳＴ６３）、カレント構文
木のスケルトン種別である「field」問い合わせ手段を
呼び出す（図６のＳＴ６４）。

【００８７】（３）「field」問い合わせ手段において
メニューを表示して（図７のＳＴ７１）テキストが入力
されるのを待つ（図７のＳＴ７２）。

【００８８】入力されたテキストをfield 構文木（図１
０の１０２）に設定して（図７のＳＴ７３）、次の問い
合わせを構文木データを上方向に辿りサーチする（図７
のＳＴ７４）。

【００８９】この場合は上方向に辿ると「struct」構文
木（図１０の１０１）があるのでカレント構文木を「st
ruct」構文木（図１０の１０１）にして（図７のＳＴ７
６）、カレント構文木のスケルトン種別である「struc
t」問い合わせ手段を呼び出す（図７のＳＴ７７）。

【００９０】（４）「struct」問い合わせ手段において
最後の子構文木まで問い合わせが終了しているかのチェ
ックを行う（図６のＳＴ６１）。

【００９１】この場合はまだ完了していないのでインデ
ックスを１加算して（図６のＳＴ６２）、カレント構文
木をインデックスに示された番号の子構文木（図１０の
１０３）にしてから（図６のＳＴ６３）、カレント構文
木のスケルトン種別である「oneOf」問い合わせ手段を
呼び出す（図６のＳＴ６４）。

【００９２】（５）「oneOf」問い合わせ手段において
「%item-x」（図５の５４）、「%item-y」（図５の５
５）を選択候補とするメニューを表示して（図８のＳＴ
８１）、項目が選択されるのを待つ（図８のＳＴ８
２）。

【００９３】選択された項目が２番目の項目と仮定する
と、「item-y」のスケルトン（図５の５５）に対応する
「quote」構文木（図１０の１０４）を作成し、「oneO
f」構文木（図１０の１０３）の子構文木として繋ぐ
（図８のＳＴ８３、ＳＴ８４）。

【００９４】次にカレント構文木を子構文木（図１０の
１０４）にして（図８のＳＴ８５）、カレント構文木の
スケルトン種別である「quote」問い合わせ手段を呼び
出す（図８のＳＴ８６）。

【００９５】（６）「quote」問い合わせ手段は、問い
合わせは行わないが木構造の末端に位置するので、次の
問い合わせを構文木データを上方向に辿りサーチする
（図９のＳＴ９１）。

【００９６】この場合は上方向に辿ると「struct」構文
木（図１０の１０１）があるのでカレント構文木を「st
ruct」構文木（図１０の１０１）にして（図９のＳＴ９
３）、カレント構文木のスケルトン種別である「struc
t」問い合わせ手段を呼び出す（図９のＳＴ９４）。

【００９７】（７）「struct」問い合わせ手段において
最後の子構文木まで問い合わせが終了しているかのチェ
ックを行う（図６のＳＴ６１）。

【００９８】この場合はまだ完了していないのでインデ
ックスを１加算して（図６のＳＴ６２）、カレント構文
木をインデックスに示された番号の子構文木（図１０の
１０５）にしてから（図６のＳＴ６３）、カレント構文
木のスケルトン種別である「oneOf」問い合わせ手段を
呼び出す（図６のＳＴ６４）。

【００９９】（８）「oneOf」問い合わせ手段において
メニューを表示して（図８のＳＴ８１）、項目が選択さ
れるのを待つ（図８のＳＴ８２）。

【０１００】この場合のメニューに表示する項目は、
「oneOf」構文木（図１０の１０５）から辿れる「oneO
f」スケルトン（図５の５６）に「where」リソースが
あるので選択候補を「%item-p」（図５の５７）、「%i
tem-q」（図５の５８）に絞りこむ。

【０１０１】選択された項目が１番目の項目と仮定する
と、「item-p」のスケルトン（図５の５７）に対応する
「quote」構文木（図１０の１０６）を作成し、「oneO
f」構文木（図１０の１０５）の子構文木として繋ぐ
（図８のＳＴ８３、ＳＴ８４）。

【０１０２】次にカレント構文木を子構文木（図１０の
１０６）にして（図８のＳＴ８５）、カレント構文木の
スケルトン種別である「quote」問い合わせ手段を呼び
出す（図８のＳＴ８６）。

【０１０３】（９）「quote」問い合わせ手段は、問い
合わせは行わないが次の問い合わせを構文木データを上
方向に辿りサーチする（図９のＳＴ９１）。

【０１０４】この場合は上方向に辿ると「struct」構文
木（図１０の１０１）があるのでカレント構文木を「st
ruct」構文木（図１０の１０１）にして（図９のＳＴ９
３）、カレント構文木のスケルトン種別である「struc
t」問い合わせ手段を呼び出す（図９のＳＴ９４）。

【０１０５】（１０）「struct」問い合わせ手段におい
て、最後の子構文木まで問い合わせが終了しているかの
チェックを行う（図６のＳＴ６１）。

【０１０６】この場合はインデックスが３になっていて
全子構文木を問い合わせ完了していることがわかるの
で、次の問い合わせを構文木データを上方向に辿りサー
チする（図６のＳＴ６５）が、自構文木がルートであり
他の問い合わせがないので、問い合わせを終了する（図
６の６８）。

【０１０７】以上によって問い合わせの結果を反映した
図１０の構文木データが構築される。

【０１０８】最後に、目的とする構造データは、構造デ
ータ変換手段により各構文木から指されるスケルトンの
リソースデータ内のフォーマットに従って以下のように
完成する。

【０１０９】answer(abcdef,YYY,PPP) ここで、「answer」は「%inquiry」の「format」リソー
ス、「abcdef」は「%menu-a」で入力されたテキスト、
「YYY」は「%menu-b」で選択された「%item-y」の「for
mat」リソース、「PPP」は「%menu-c」で選択された「%
item-p」の「format」リソースである。

【０１１０】上記に説明したメニュー問い合わせ方式お
いて、本実施例が生成するサービス定義を実現するスケ
ルトン構造の概念を図１１に示す。

【０１１１】

【発明の効果】以上説明したように、本発明によれば、
設計者が自分の設計する付加サービス以外の知識を有し
ていなくても、メニュー問い合わせ方式によるさまざま
な問い合わせに対応するだけでその入力形式に沿った交
換システムの目的とする付加サービス設計を自動的に記
述することができる。

【０１１２】このことにより、多種多用化が進み、膨大
な開発量を要する交換システムの付加サービス設計の容
易化、付加サービスの開発効率の大幅な向上に寄与する
ことができるという効果がある。

【図面の簡単な説明】

【図１】本発明に係る交換サービスシナリオ設計支援シ
ステムの構成を示すブロック図である。

【図２】上記システムにおけるメニュー問い合わせ方式
が有する機能構成を示すブロック図である。

【図３】上記システムにおける動作を説明するための問
い合わせ例を示す流れ図である。

【図４】上記システムにおける動作を説明するための問
い合わせ例を実現するメニュー記述例を示す図である。

【図５】上記システムにおける動作を説明するためメニ
ュー記述例から生成されるスケルトンデータの構成を示
す図である。

【図６】上記システムにおける動作を説明するための
「struct」問い合わせ手段の流れ図である。

【図７】上記システムにおける動作を説明するための
「field」問い合わせ手段の流れ図である。

【図８】上記システムにおける動作を説明するための
「oneOf」問い合わせ手段の流れ図である。

【図９】上記システムにおける動作を説明するための
「quote」問い合わせ手段の流れ図である。

【図１０】上記システムにおける動作を説明するための
構文木データの構成を示す図である。

【図１１】上記システムにおいて生成するサービス定義
を実現するスケルトン構造の概念を示す概念図である。

【図１２】付加サービス制御方式を説明する概念図であ
る。

【符号の説明】

１シナリオエディタ１１エディタ制御部１２エディタ生成部２サービスファイル３メニュー記述ファイル４基本呼ＳＤＬ図５サービスコードファイル

Claims

【特許請求の範囲】

【請求項１】メニュー問い合わせによりシナリオ設計を
行う交換サービスのシナリオ設計支援システムにおい
て、当該シナリオ設計のサービス定義の作成にあたり、問い合わせパターンを記述したメニュー記述手段と、前記メニュー記述手段から個々の問い合わせを木構造形
態でつなげたスケルトンデータを生成し、問い合わせを
表示し、当該問い合わせ結果の情報を木構造データとし
てサービス定義を構築する編集制御手段とを有すること
を特徴とする交換サービスシナリオ設計支援システム。