(57)【要約】【課題】プログラム作成時の手戻りを防止し、プログラムを効率的に生成するプログラム自動生成装置を提供する。【解決手段】仕様入力手段１１０は、入力された通信サービスの動作仕様１０を、入力要素を表示するための入力要素提供データ３０を基に、あらかじめ通信サービスの動作仕様として定義された送受信信号等の情報と共に内部データ４０として保存し、仕様変換手段１２０は、保存された内部データ３０を基に、必要なら定義不足部分等の自動補完を行い、変換に必要な情報を抽出し、予め用意されたサービスに依存しない複数の変換形式に基づいて通信サービスソフトウエア２０を生成する。仕様入力手段１１０は、自動補完を行った部分を識別可能に表示し、仕様検証手段１３０は、自動補完を行った部分をユーザが修正したかどうか判断して、ユーザが修正している場合に検証を行なう。【選択図】        図１
2004280152.tif 000002
【特許請求の範囲】
【請求項１】
通信サービスの動作仕様を図表現を用いて視覚的に入力することが可能な仕様入力手段と、入力された通信サービスの動作仕様を通信サービスソフトウエアに変換する仕様変換手段を有するプログラム自動生成装置において、
仕様入力手段は、入力された通信サービスの動作仕様を、入力要素を表示するための入力要素提供データを基に、あらかじめ通信サービスの動作仕様として定義された送受信信号等の情報と共に内部データとして保存し、
仕様変換手段は、前記保存された内部データを基に、変換に必要な情報を抽出し、あらかじめ用意されたサービスに依存しない複数の変換形式に基づいて通信サービスソフトウエアを生成する、
ことを特徴とするプログラム自動生成装置。
【請求項２】
請求項１記載のプログラム自動生成装置において、
仕様変換手段は、通信サービスの動作仕様として、定義不足部分あるいはサービスに依存しないプログラムコードの自動補完を行うことが選択された場合には、必要な仕様入力要素の自動補完を行う、
ことを特徴とするプログラム自動生成装置。
【請求項３】
請求項２記載のプログラム自動生成装置において、
仕様入力手段は、自動補完を行った部分を識別可能に表示することを特徴とするプログラム自動生成装置。
【請求項４】
請求項３記載のプログラム自動生成装置において、入力された仕様を検証する仕様検証手段を更に有し、
仕様検証手段は、自動補完を行った部分をユーザが修正したかどうか判断して、ユーザが修正している場合に検証を行なうことを特徴とするプログラム自動生成装置。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は、通信サービス動作仕様を入力し、通信サービスソフトウエアのプログラムを生成するプログラム自動生成装置に関し、詳しくは、通信サービス動作仕様をフローチャートを用いて記述し、その記述内容を複数の変換パターンを持って、プログラム言語に変換し、さらに、必要時には不足部分等の補完を行い、補完部分を識別可能とし、仕様誤り等を検証することで、プログラム作成時の手戻りを防止し、プログラムを効率的に生成するプログラム自動生成装置に関する。
【０００２】
【従来の技術】
従来のこの種のプログラム自動生成装置では、ＰＳＴＮ網（Ｐｕｂｌｉｃ
Ｓｗｉｔｃｈｅｄ  Ｔｅｌｅｐｈｏｎｅ  Ｎｅｔｗｏｒｋ：公衆電話交換網）を前提とした通信サービス動作仕様に基づき、メッセージシーケンス図を用いて定義し、現在の呼状態に基づき、前後の呼状態を抽出するための呼状態遷移図を規定し、それに基づく、準正常手順の自動補完を行っていた（例えば、特許文献１参照）。
【０００３】
しかし、準正常はサービス仕様に依存する部分が存在するため、新しく開発するサービスの状態遷移が従来サービスのサブセットではない場合、サービスの開発毎に、変換知識の追加を要していた。また、変換を行いながら、自動補完を行っていたため、入力した仕様のレベルでは自動補完部分の確認を行う手段がなく、試験時の効率低下を招いていた。準正常手順の部分について、自動補完の後に、サービス仕様の手直しをする場合は自動補完された仕様をエディタ上で修正することが不可能であり、再度準正常に関する変換知識を修正してから生成し直すため、大幅に工数を要していた。変換知識の修正はプログラム自動生成装置の開発者しか行うことができなかった。
【０００４】
【特許文献１】
特開平９−８１３８０号公報
【０００５】
【発明が解決しようとする課題】
当今、ＰＳＴＮ網だけでなく、ＩＰ網やモバイル網上での通信サービスを定義できるプログラム自動生成を実現するためには、呼状態遷移に基づく準正常の自動補完に関わらず、呼状態に関係ない複数のプロトコルや分散環境に対応したプログラムも自動生成する必要がでてきた。また、ユーザの入力した部分とプログラム自動生成装置において自動補完した部分を、入力したアイコンレベルで明確に表示し、自動補完後にユーザが修正することを可能にし、修正した場合は、自動で検証を行う必要がある。
【０００６】
本発明の目的は、サービス動作仕様に基づき、アイコンを貼り付け、記述したフローチャートにおいて、入力された信号送受信アイコンに対し、信号送受信アイコンの情報は入力要素提供データに基づいて作成した内部データを利用することにより、あらかじめ用意された複数の形式の変換情報データに対応した変換パターンに基づいて、サービスソフトウエアを生成し、複数の形式の変換情報データの中にユーザが容易に変更可能な変換情報データを含むことにより、プログラム作成時の手戻りを防止し、プログラムを効率的に生成するプログラム自動生成装置を提供することにある。
【０００７】
また、本発明の他の目的は、サービスの開発ごとまたは、ＡＰＩの追加ごとに変換知識の追加を必要とせず、内部データを利用して、自動的に補完を行い、サービス動作仕様を入力したレベルで、自動的に補完した箇所を明示し、修正可能とすることで、プログラム作成時の手戻りを防止し、プログラムを効率的に生成するプログラム自動生成装置を提供することにある。
【０００８】
【課題を解決するための手段】
本発明は、少なくとも通信サービスの動作仕様を図表現を用いて視覚的に入力することが可能な仕様入力手段と、入力された通信サービスの動作仕様を通信サービスソフトウエアに変換する仕様変換手段を有するプログラム自動生成装置において、仕様入力手段は、入力された通信サービスの動作仕様を、入力要素を表示するための入力要素提供データを基に、あらかじめ通信サービスの動作仕様として定義された送受信信号等の情報と共に内部データとして保存し、仕様変換手段は、前記保存された内部データを基に、変換に必要な情報を抽出し、あらかじめ用意されたサービスに依存しない複数の変換形式に基づいて通信サービスソフトウエアを生成することを主要な特徴とする。
【０００９】
また、本発明は、仕様変換手段は、通信サービスの動作仕様として、定義不足部分あるいはサービスに依存しないプログラムコードの自動補完を行うことが選択された場合には、必要な仕様入力要素の自動補完を行い、仕様入力手段は、自動補完を行った部分を識別可能に表示することを特徴とする。
【００１０】
また、本発明のプログラム自動生成装置は、入力された仕様を検証する仕様検証手段を更に有し、該仕様検証手段は、自動補完を行った部分をユーザが修正したかどうか判断して、ユーザが修正している場合に検証を行なうことを特徴とする。
【００１１】
【発明の実施の形態】
以下、発明の実施の形態について図面により詳細に説明する。
図１は、本発明のプログラム自動生成装置の一実施例を示す機能ブロック図である。図１において、プログラム自動生成装置１００は、ユーザからの通信サービス動作仕様１０の入力を受け付け、入力要素提供データ３０を基に内部データ４０を生成して保存する仕様入力手段１１０、内部データ４０を基に、必要なら定義不足部分やサービスに依存しないプログラムコード等の自動補完処理を行い、あらかじめ用意されたサービスに依存しない複数の変換パターン形式に基づいて通信サービスソフトウエア２０を生成する仕様変換手段２０、入力及び変換時、パラメータチェックや状態遷移情報に基づき、状態遷移検証等、仕様の検証を行う仕様検証手段１３０を備える。なお、入力要素提供データ３０、内部データ４０は、実際にはメモリ装置内に保持される。
【００１２】
図２は、通信サービスソフトウエアの一例を示す。この例は、ＯｐｅｎＡＰＩ（Ａｐｐｌｉｃａｔｉｏｎ  Ｐｒｏｇｒａｍｍｉｎｇ  Ｉｎｔｅｒｆａｃｅ）の一つであるＰａｒｌａｙＡＰＩ（ｈｔｔｐ：／／ｗｗｗ．ｐａｒｌａｙ．ｏｒｇ）に基づく、送受信信号（メソッド）を選択した場合を示したもので、各々の状態遷移情報はメッセージシーケンスを用いて示している。２１１は制御ロジックであり、通信サービスの動作仕様に基づき、通信サービスを実現するためのクラス群である。２１２はＰａｒｌａｙ  ＡＰＩで規定されているＰａｒｌａｙサービスクラスであり、制御ロジック２１１はこれらのクラスのもつ送受信メソッドを選択し、利用する。２１３は制御ロジック２１１の状態遷移を示す。この例の場合、４つの状態を保有している。２１４は仕様書に規定されているＰａｒｌａｙサービスクラス２１２の状態遷移である。２１５は仕様書に規定されているＰａｒｌａｙサービスクラス２１２の送受信メソッドであり、Ｐａｒｌａｙ  ＡＰＩと呼ばれている。実施例では、図２のような通信サービスソフトウエアを想定する。
【００１３】
図３は、ＧＵＩ（Ｇｒａｐｈｉｃａｌ  Ｕｓｅｒ  Ｉｎｔｅｒｆａｃｅ）により、通信サービスの動作仕様を図表現を用いて視覚的にシステムへ入力することを可能とする仕様入力手段１１０の実現例を示した図である。ユーザは、入力要素選択画面１１２により、入力要素としてのアイコンを選択し、入力画面１１１へ貼り付けて、サービス動作仕様を入力する。例では、アイコンが１〜５の順に選択されたことを示している。入力要素選択画面１１１のアイコン情報は、あらかじめ保持されている入力要素提供データ３０に基づき表示される。入力要素提供データ３０は、例えば、ＯＭＧ（Ｏｂｊｅｃｔ  Ｍａｎａｇｅｍｅｎｔ  Ｇｒｏｕｐ：分散オブジェクト技術の標準化団体）で標準化され、提供されるすべてのＣＯＲＢＡ（Ｃｏｍｍｏｎ  Ｏｂｊｅｃｔ  Ｒｅｑｕｅｓｔ  Ｂｒｏｋｅｒ  Ａｒｃｈｉｔｅｃｔｕｒｅ：分散システム環境でオブジェクト同士がメッセージを交換するための共通仕様）オブジェクトのインタフェースを定義する言語であるＩＤＬ（Ｉｎｔｅｒｆａｃｅ  Ｄｅｆｉｎｉｔｉｏｎ  Ｌａｎｇｕａｇｅ）ファイルから、自動的に生成されるデータである。図４に入力要素提供データ３０の一例を示す。なお、ＩＤＬファイルから入力要素提供データを生成する処理は、本発明者らが先に提案しており（特願２００２−１２２３９９）、また、本発明の主旨ではないので、その詳細は省略する。
【００１４】
仕様入力手段１１０は、入力要素提供データ３０に基づき、ユーザからのサービス仕様入力を、あらかじめ通信サービスの動作仕様として定義された送受信号等の情報と共に内部データ４０として保存する。図５に内部データ４０の一例を示す。内部データ４０は、一般に複数のテーブルから構成されるが、図５では簡単にテーブルＡとテーブルＢのみを示す。テーブルＡにおいて、１〜５は図３の入力画面１１１に示したアイコン（入力要素）１〜５に対応する。テーブルＡとテーブルＢとは、例えばＢ−２、Ｂ−８のように、必要に応じてポインタにより関連づけられる。図５に示すように、テーブルＢには、主として入力要素提供データ４０に定義された送受信信号（メソッド）等の情報が保持される。
【００１５】
図６は、仕様変換手段１２０の構成例を示している。仕様変換手段１２０は、内部データ４０を基にサービス仕様をプログラムコードに変換するロジックである変換制御部１２１、サービス仕様としての内部データをプログラムコードに変換するためにロジックが利用する変換情報データ１２２、サービスに依存しないプログラムコードをテンプレート化したテンプレートファイル１２３、ＣＯＲＢＡ等の分散処理を前提としたプログラムの生成時に必要なスケルトンコード１２４、および、内部データ４０に基づき、定義不足部分やサービスに依存しないプログラムコードを補完するための自動補完制御部１２５、アイコンごと自動補完制御部１２５が補完処理を行うために用いられる補完判定フラグが定義された自動補完データ１２６からなる。実際には、変換情報データ１２２、テンプレートファイル１２３、スケルトンコード１２４、自動補完データ１２６はメモリ装置に保存されている。
【００１６】
図７は変換情報データ１２２の一例、図８はテンプレートファイル１２３の一例、図９はスケルトンコード１２４の一例である。ここでは、スケルトンコード１２４は、ＩＤＬファイルをコンパイルした際に生成されるクライアント側のメソッドを記述してあるプログラムコードを示す。図１０は自動補完データ１２６の一例である。後述するように、自動補完制御部１２５は、アイコンごとに自動補完データ１２６のフラグを参照し、該当フラグのＯＮ／ＯＦＦに応じて補完処理を場合分けする。なお、図１０では、極く一部の補完判定フラグのみを示したものである。
【００１７】
図１１に、図６の仕様変換手段１２０における一連の処理動作例を示す。図１１において、ステップ１１００、１１１０〜１１１３、１１２０〜１１２３、１１３０〜１１３２が変換制御部１２１での処理、ステップ１２００が自動補完制御部１２５での処理を示している。
【００１８】
仕様変換手段１２０の変換制御部１２１は、キーボードや入力画面上等の変換ボタンが押下されると、自動補完を行うかをユーザに問い合わせる（ステップ１１００）。自動補完を行わない場合、変換制御部１２１は、直ちにステップ１１１０、１１２０、１１３０に進み、それぞれの変換パターンに従い、変換を開始する。自動補完を行う場合には、変換制御部１２１は、自動補完制御部１２５に制御を渡し、自動補完制御部１２５が自動補完処理を行った後（ステップ１２００）、ステップ１１１０、１１２０、１１３０に進む。ステップ１２００の自動補完処理については後述する。以下では、それぞれの変換パターンの処理を説明する。
【００１９】
変換パターン１では、まず、プログラムに出力するコメント文等を管理している変換情報データ１２２（図７）を読み込む（ステップ１１１１）。次に、プログラム言語ごとのテンプレートファイル１２３（図８）を読み込む（ステップ１１１２）。次に、自動補完済みあるいは元々の内部データ４０（図５）に基づき、変換情報データ１２２、テンプレートファイル１２３を利用して、プログラムソースに置き換え、通信サービスソフトウエア２０として生成する。
【００２０】
変換パターン２では、まず、スケルトンコード１２４（図９）を読み込む（ステップ１１２１）。次に、自動補完済みあるいは元々の内部データ４０（図５）に基づき、利用しているメソッドを検索し、抽出する（ステップ１１２２）。次に、スケルトンコードの利用メソッドに対し、内部データに基づくソースコードを挿入し、通信サービスソフトウエア２０として生成する（ステップ１１２３）。
【００２１】
変換パターン３では、まず、テンプレートファイル１２３（図８）を読み込む（ステップ１１３１）。次に、テンプレートファイル１２３を、自動補完済みあるいは元々の内部データ４０（図５）に基づき、必要情報を挿入し、通信サービスソフトウエア２０として生成する（ステップ１１３２）。
【００２２】
図１２は、図１１におけるステップ１２００の自動補完処理の詳細動作例を示す。ユーザは、入力したサービス仕様について定義不足部分やサービスに依存しないプログラムコードの自動補完を行うかどうか選択することができる。ユーザが自動補完を選択すると、変換制御部１２１は自動補完制御部１２５に制御を渡し、自動補完制御部１２５が自動補完処理を開始する。
【００２３】
自動補完制御部１２５は、変換制御部１２１から制御が渡されると、内部データ４０（図５）を読み込む（ステップ１２０１）。以下、内部データ４０の入力されたアイコン数分、ステップ１２０２以降の処理を繰り返す。
【００２４】
まず、入力されたアイコンが、ユーザが選択した自動補完対象かどうかをチェックし（ステップ１２０２）、自動補完対象でない場合はステップ１２１１に進む。自動補完対象である場合は、自動補完済みかどうかをチェックし（ステップ１２０３）、自動補完済みである場合は同様にステップ１２１１に進む。なお、自動補完対象か自動補完済みかどうかはアイコン属性（図５参照）で判別する。
【００２５】
入力されたアイコンが自動補完対象で、自動補完済みでない場合には、当該入力されたアイコンに対し、自動補完データ１２６（図１０）を取得し（ステップ１２０４）、該自動補完データ内に定義された補完判定フラグがＯＮかＯＦＦかチエックする（ステップ１２０５）。フラグがＯＮである場合は、テンプレートファイル１２３（図８）を読み込み（ステップ１２０６）、該テンプレートファイル１２３内の処理を記述したアイコンを自動補完する（ステップ１２０７）。また、フラグがＯＦＦである場合は、入力されたアイコンの内部データ内のアイコン例外情報（図５参照）を取得し（ステップ１２０８）、例外処理アイコンを自動補完する（ステップ１２０９）。その後、アイコン属性として自動補完済みフラグをＯＮにする（ステップ１２１０）。
【００２６】
ステップ１２１１では、最終アイコンであるかどうかをチェックし、最終アイコンでない場合はステップ１２０２に戻って処理を繰り返し、最終アイコンである場合は自動補完処理を終了とする。自動補完処理が終了すると、自動補完制御部１２５は変換制御部１２１に制御を戻す。
【００２７】
図１３に自動補完後の入力画面例を示す。網掛けのアイコンが自動補完したアイコンである。自動補完される処理は、例えば、ログ出力である。図１３中、ログ（送信〔前〕）、ログ（送信〔後〕）などのアイコンが自動補完フラグＯＮのケースで自動補完されたものであり、例外（ログ出力）、例外（処理呼出）、例外（ｔｈｒｏｗ）などのアイコンが自動補完フラグＯＦＦのケースで自動補完されたものである。仕様入力手段１１０は、自動補完済み内部データを取り込み、自動補完フラグがオンであれば、例えば、当該アイコンの色を変えて表示し、自動補完された部分が識別可能な表示にする。これにより、ユーザは必要なら修正や変更を行う。ユーザが修正・変更を行ったか否かはアイコン属性（図５参照）に反映される。
【００２８】
図１４は、図１の仕様検証手段１３０における一連の検証処理動作例を示したものである。仕様検証手段１３０は、内部データを読み込む（ステップ１３０１）。以下、各アイコンごとにステップ１３０２以降の処理を繰り返す。まず、当該アイコンが自動補完済みであるどうかをチェックし（ステップ１３０２）、自動補完済みでない場合には、そのまま仕様検証処理に進む（ステップ１３０４）。自動補完済みである場合は、ユーザが修正・変更を行っているかどうかをチェックし（ステップ１３０３）、ユーザが修正・変更を行っている場合、仕様検証処理に進み（ステップ１３０４）、ユーザが修正・変更を行っていない場合はステップ１３０５に行く。ステップ１３０４の仕様検証処理では、パラメータチエックや、検証情報知識ベース等の状態遷移情報に基づき、状態遷移検証等、仕様の検証を行う。この検証処理については、本発明者らが先に提案した特願２００２−２３６２１２に詳述されているので、詳細は省略する。ステップ１３０５は、最終アイコンであるかどうかをチェックし、最終アイコンでない場合は、ステップ１３０１に戻って処理を繰り返し、最終アイコンである場合は、検証を終了とする。
【００２９】
なお、図１に示したプログラム自動生成装置における各部の一部もしくは全部の処理機能をコンピュータのプログラムで構成し、そのプログラムをコンピュータを用いて実行して本発明を実現することができること、あるいは、図１１、図１２、図１４などに示した処理手順をコンピュータのプログラムで構成し、そのプログラムをコンピュータに実行させることができることは言うまでもない。また、コンピュータでその処理機能を実現するためのプログラム、あるいは、コンピュータにその処理手順を実行させるためのプログラムを、そのコンピュータが読み取り可能な記録媒体、例えば、ＦＤ、ＭＯ、ＲＯＭ、メモリカード、ＣＤ、ＤＶＤ、リムーバブルディスクなどに記録して、保存したり、提供したりすることができるとともに、インターネット等のネットワークを通してそのプログラムを配布したりすることが可能である。
【００３０】
【発明の効果】
本発明によれば、サービス動作仕様に基づき、アイコンを貼り付け、記述したフローチャートにおいて、入力された信号送受信アイコンに対し、信号送受信アイコンの情報は入力要素提供データとして分離し、サービスの開発ごとまたは、ＡＰＩの追加ごとに変換知識の追加を必要とせず、自動的に補完を行い、サービス動作仕様を入力したレベルで、自動的に補完した箇所を明示し、修正可能とし、あらかじめ用意された複数の形式の変換情報データに対応した変換パターンに基づいて、サービスソフトウエアを生成し、複数の形式の変換情報データの中にユーザが容易に変更可能な変換情報データを含むことにより、プログラム作成時の手戻りを防止し、プログラムを効率的に生成するプログラム自動生成装置を提供することができる。
【図面の簡単な説明】
【図１】本発明のプログラム自動生成装置の一実施例を示す機能ブロック図である。
【図２】通信サービスソフトウエアの構成例を示す図である。
【図３】仕様入力手段の画面例である。
【図４】入力要素提供データの一例である。
【図５】内部データの一例である。
【図６】仕様変換手段の構成例を示す図である。
【図７】変換情報データの一例である。
【図８】テンプレートファイルの一例である。
【図９】スケルトンコードの一例である。
【図１０】自動補完データの一例である。
【図１１】仕様変換手段の処理動作例である。
【図１２】図１１中の自動補完処理の詳細フロー例である。
【図１３】自動補完後の入力画面例である。
【図１４】仕様検証手段の処理動作例である。
【符号の説明】
１０    通信サービス動作仕様
２０    通信サービスソフトウエア
３０    入力要素提供データ
４０    内部データ
１００    プログラム自動生成装置
１１０    仕様入力手段
１２０    仕様変換手段
１２１    変換制御部
１２２    変換情報データ
１２３    テンプレートファイル
１２４    スケルトンコード
１２５    自動補完制御部
１２６    自動補完データ
１３０    仕様検証手段
【図１】
2004280152.tif 000003
【図２】
2004280152.tif 000004
【図３】
2004280152.tif 000005
【図４】
2004280152.tif 000006
【図５】
2004280152.tif 000007
【図６】
2004280152.tif 000008
【図７】
2004280152.tif 000009
【図８】
2004280152.tif 000010
【図９】
2004280152.tif 000011
【図１０】
2004280152.tif 000012
【図１１】
2004280152.tif 000013
【図１２】
2004280152.tif 000014
【図１３】
2004280152.tif 000015
【図１４】
2004280152.tif 000016