(57)【要約】【課題】従来、プログラム全体を動作することにより追加・修正部分をテストしなければならないこと、および仕様変更時にドキュメントとソースの両方を修正するなど作業効率を低下させる要因が発生している。【解決手段】システム設計時は、チェック条件や編集条件設計時に自動生成できる処理か自動生成できない処理かを区別し、自動生成できない処理については部品として切り出しする。切り出した部品は、処理をコーディング後、テストプログラムを生成して部品テストを実施する。自動生成できる処理は、データ項目辞書に登録する。プログラム設計時は、プログラム定義書に標準パターンと入出力ファイルを選択して、プログラム生成を実行する。仕様変更時は、同じ作業を繰り返し、再生成を実施する。【選択図】    図１
2005043931.tif 000002
【特許請求の範囲】
【請求項１】
プログラムの部品を格納するファイルとデータ項目をチェックする処理手段を持ち、データ項目を部品として格納するファイルと標準パターンライブラリと標準パターンの制御構造に従った入出力の定義情報を格納するファイルとプログラム仕様書を選択してプログラム自動生成機能を実行する自動生成ツールとを備えるプログラムの自動生成システムにおいて、そのままでは自動生成できない処理を部品として格納するファイルを備え、検査済みの標準パターンとデータ項目辞書から自動生成される単位ソースとテスト済みの部品とを組み立てる手段を備えることでプログラムを自動生成することを特徴とするプログラム自動生成システム。
【請求項２】
請求項１に記載のプログラム自動生成システムにおいて、チェック条件および編集条件の定義処理で自動生成部分と非自動生成部分を切り分け、非自動生成部分を部品として生成することを特徴とするプログラム自動生成方法。
【請求項３】
請求項１に記載のプログラム自動生成システムにおいて、上記自動生成できない処理の部品のみをテストする手段を備えたことを特徴とするプログラム自動生成システム。
【請求項４】
請求項１に記載のプログラム自動生成システムにおいて、チェック条件及び編集条件定義機能に上記自動生成できない機能の部品についても定義できる手段を備え、そのまま設計書となるドキュメントを生成する手段を備えたことを特徴とするプログラム自動生成システム。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は、ソフトウェアプログラムの自動生成を行うシステムとその方法、及び生成プログラムのテスト方法に関し、特に仕様変更時のプログラムの自動再生成を可能とするシステムとその方法に関する。
【０００２】
【従来の技術】
従来のソフトウェアプログラムの自動生成は次のように実施されていた。
ソフトウェアプログラムの自動生成を行うシステムは、ソフトウェアの部品を格納するファイル（これをディクショナリとよぶ）とデータ項目をチェックする処理機能を持ち、データ項目を部品として格納するファイル（これを関連チェック仕様書とよぶ）と標準パターンライブラリと、標準パターンの制御構造に従った入出力、例えば画面、帳票、ファイルなどの関係を格納するファイル（これをプログラム仕様書とよぶ）と、プログラム仕様書を選択してプログラム自動生成機能を実行する自動生成ツールとを備える。このシステムを用いたソフトウェアプログラムの自動生成は以下の手順で実施する。
【０００３】
まず、ソフトウェアをデータ項目単位の処理に着目し、ソフトウェア部品として定義し、ディクショナリに格納する。また、複数のデータ項目間の相互関係に基づいてデータの妥当性を判定する関連チェック処理を部品として関連チェック仕様書に格納する。次に、プログラムを標準パターンというスケルトンに合わせて機能分割を行い、標準パターンの制御構造に従った入出力（画面、帳票、ファイルなど）関係をプログラム仕様書に格納する。プログラムソースは、プログラム仕様書を選択して、自動生成ツールがプログラム自動生成機能を実行することにより、自動生成される。そのとき、ディクショナリに登録されたデータ項目単位のソフトウェア部品、および複数のデータ項目間の関連チェック部品を入出力情報から、自動選択してプログラムソースを生成する。このような手法は例えば、特許文献１（特開平８−９５７６８号公報）に示されている。
【０００４】
この方法では複雑な処理、例えばチェックや編集等の処理プログラムは自動生成できず、上記ツールで生成されたソースを直接修正することにより補正していた。また、プログラムの単体テストは、非自動生成部分のみ行えば良いが、その際にプログラム内で使用するデータ項目に対する全てのテストデータを作成して、プログラム全体を動作させることにより確認を実施していた。
【０００５】
【特許文献１】
特開平８−９５７６８号公報
【０００６】
【発明が解決しようとする課題】
上記従来の技術では、自動生成できずに修正により追加作成した部分をプログラム全体の一部分に埋め込むため、仕様変更などでプログラムの変更が発生した場合に、プログラムの自動再生成を実施できない場合があるという問題があった。また、自動生成できない追加作成部分が小規模であっても、プログラム全体を実行してテストを行うため、追加部分以外のテストデータが必要になり、追加規模に応じたテスト作業工数とはならないという問題があった。さらに、プログラム変更時に、ソースとドキュメントの両方を別々に修正する部分があるため、お互いの整合性が取れなくなる可能性があるという問題があった。
【０００７】
本発明の目的は上記課題を解決し、仕様変更時のプログラムの自動再生成を可能とするシステムとその方法を提供することにある。
【０００８】
【課題を解決するための手段】
上記課題を解決するため、本発明のプログラムの自動生成システムは上記構成要素の他に、自動生成できない処理を部品として格納するためのファイルを設ける。また、追加仕様の部品のみについてドライバプログラムとテストデータ、ＰＣＬを生成し、動作テストを実施する処理を設ける。このテストを「部品テスト」と呼ぶことにする。このシステムを用いたソフトウェアプログラムの自動生成は以下の手順で実施する。
まず、設計時に要求仕様を標準パターン、辞書（業務ルール）および部品に機能分割して格納する。個々の部品同士は、お互いに影響を与えないように分割することとする。自動生成できない処理は、追加仕様の部品といった別の単位ソースとして格納する。追加仕様の部品のみについて、ドライバプログラムとテストデータ、ＰＣＬを生成し、動作テストを実施する。プログラム単位に全ての追加仕様の部品テストが完了した後、追加仕様の部品を自動生成システムに取り込めるように準備し、自動生成システムによりプログラムを自動生成する。既に部品のテストは終了しているため、生成したプログラムの動作テストは実施する必要がない。
仕様変更や保守時には、変更になった部品のみについて上記の作業を繰り返し実施することにより、プログラムの自動再生成と効率的なテストが実現できる。
【０００９】
【発明の実施の形態】
図１に本発明のプログラム再生成方法を実現するためのシステム構成を示す。ソフトウェア開発支援システム（１０）は、システム設計機能（７）、部品テスト機能（８）、プログラム設計／生成機能（９）の３つの機能で構成される。また、これらの機能を実現するためのファイル環境を説明する。
システム設計機能（７）と連携するチェック条件定義書（１）、編集条件定義書（２）、データ定義書（３）、プログラム設計／生成機能（９）と連携するプログラム定義書（６）は、仕様書に関するデータを格納するファイルである。部品テスト機能（８）と連携するテストデータライブラリ（４）は、過去に使用したテストデータや、新規部品用に作成したテストデータを格納するファイルである。プログラム設計／生成機能（９）と連携する標準パターンライブラリ（５）は、標準的なプログラムの制御構造を格納するファイルである。
システム設計機能（７）及びプログラム設計／生成機能（９）と連携するデータ項目辞書（１２）、上記３つの機能と連携する部品ライブラリ（１３）は、部品という単位ソースを格納するファイルである。ソースプログラムライブラリ（１４）は、プログラム設計／生成機能（９）により生成したソースプログラムを格納するファイルである。
【００１０】
次に各機能の詳細を説明する。システム設計機能（７）は、画面設計、帳票設計、ＤＢ設計、ファイル設計を行う機能である。例えば画面設計で新規画面を作成する場合、まず画面に必要なデータ項目を定義して、画面仕様書としてデータ定義書（３）に格納する。次に各データ項目に対してチェック条件や編集条件を定義し、チェック条件定義書（１）、編集条件定義書（２）に格納する。定義したチェック条件や編集条件は、自動生成部分とユーザ追加編集部分に切り分けられ、自動生成分は、データ項目辞書（１２）に、ユーザ追加編集部分は、部品という単位ソースとして部品ライブラリ（１３）に格納する。また、定義したチェック条件や編集条件は、そのまま設計書として利用できるドキュメント（１１）として出力することができる。帳票設計、ＤＢ設計、ファイル設計についても同様の手順で設計することができる。
【００１１】
部品テスト機能（８）は、ユーザ追加編集部分をコーディングした部品のテストを実施する機能である。部品ライブラリからテスト対象を選定する、また、テストデータを作成してテストデータライブラリ（４）へ格納したり過去のテストデータを利用したりすることもできるので、繰り返しテストを実行する場合にも有用である。
プログラム設計／生成機能（９）は、標準パターンライブラリ（５）から、標準的な制御パターンを選択し、システム設計で設計した入出力ファイルおよび部品を選択して定義する設計機能と、生成時には、選択したパターン、部品およびデータ項目辞書にあるソース部品を自動的に読み込んで、プログラムを生成する生成機能で構成される。
本発明のシステムでは仕様変更等による対応についても、一度作成した部品はライブラリにファイルとしてすべて保管できるため部品の再利用が可能であり、仕様変更の繰り返しが続く場合も、簡単にプログラムを再生成することが可能となっている。
【００１２】
次に、上記構成のシステムを用いたプログラム作成方法に付いて説明する。
本発明のシステムを用いたプログラム作成方法では、ソフトウェア開発の効率化を図るため、図２のような手順で処理を進める。従来の開発方法と手順が異なる点は、従来はプログラム生成後に処理していたプログラムソースに不足部分を追加するコーディングを、部品という単位ソースに切り出す処理としてプログラム設計前に実施することと、従来はソース全体が完成した後に行っていたプログラムのテストを、部品単位でプログラム設計前にテストを実施することの２点である。
まず、システム設計として、画面設計、帳票設計、ＤＢ設計、ファイル設計を行う。各設計に必要なデータ項目に対して、チェック条件および編集条件を作成する（１６）。作成したチェック条件および編集条件を読込み、データ項目辞書との突合せ処理が行われる（１７）。処理の結果、未生成条件がある場合はそれについてチェック条件および編集条件を編集（１９）してドキュメント（２０）と部品（枠のみ）（２１）を生成する。未生成条件がない場合は、ドキュメント（２２）を生成する。
【００１３】
次に、未生成条件に対応する各部品のみテストを行うためのチェックリストおよびテストデータを作成する（２３）。次に未生成条件に対応する部品（枠のみ）について、部品単位での追加コーディングを行う（２４）。追加コーディングした部品のみを、テストプログラムを使用して動作テストを行う（２５）。この（２３）から（２５）の部分が従来と異なる部分である。次にプログラム設計として、プログラムの標準パターン、入力および出力を定義する（２６）。最後にプログラムの自動生成を実施する（２７）。従来の方法では、データ項目辞書に登録できないような仕様が空欄となった半完成のプログラムソースが生成されるが、本発明のシステムによる自動生成処理では既に検査済みの標準パターンとデータ項目辞書から自動生成される単位ソースと、テスト済みの追加コーディングした部品を組み立てる方法であるため、そのまま動作可能なソースとして自動生成される。
【００１４】
次に本発明のシステムによるドキュメントの生成について説明する。本発明のシステムでは、図１に示すチェック条件定義書（１）、編集条件定義書（２）、データ項目辞書（１２）を用い、図２に示すような手順でドキュメントの自動生成処理を実現する。手順は以下の通りである。まず、チェック条件および編集条件を作成する（１６）。次にチェック・編集内容を生成する（１７）。チェック条件および編集条件は、データ項目辞書（１２）に登録済みの条件のみ自動生成される。次に生成内容を確認する（１８）。チェック条件、編集条件がデータ項目辞書として登録して自動生成可能かどうかを確認する。自動生成できない仕様が無い場合はそのままドキュメントを自動生成する（２２）。自動生成できない仕様がある場合は、編集モードによりチェック条件および編集条件をそのまま文章形式で記述する（１９）。最後に、データ項目辞書に登録したチェック条件、編集条件を文章形式に変換し、ユーザ追加、編集部分は定義した文章をそのまま出力してドキュメントとする（２０）。また、編集した仕様の部品としてテンプレートを生成する（２１）。
従来のシステムによるドキュメント自動生成では上記の確認ステップが無く、データ項目辞書に登録済みのものは自動生成され、そうでない部分は空白になり、表計算ソフト等で追加仕様部分の記述を別途作成する。
このように本発明のシステムではユーザが追加・編集するチェック条件や、編集条件をあらかじめチェック条件、編集条件定義書に定義することにより、ドキュメント生成した時点のドキュメントがそのまま利用できるようになり、ドキュメント生成を毎回再生成することが可能になる。
【００１５】
本発明のシステムでは、仕様変更が発生した際にも同様に、図２の（１５）〜（２７）部分の処理を仕様変更部品の作成処理として実施する事により、プログラムの自動再生成が可能となる。ドキュメント生成についても同様に、仕様変更内容をチェック条件および編集条件の定義の修正によって反映することにより、仕様変更内容を反映したドキュメントが再生成できる。また、編集した仕様の部品を再生成すると、新たに追加になった部品のテンプレートが生成できる。
【００１６】
次に、本発明のシステムによるプログラム動作テストについて説明する。
自動生成できない部分のテストデータの量と質について、従来方法と本発明の開発方法との比較を以下に述べる。テスト対象は、チェック条件の関連チェックとし、チェック内容を確認するのに必要なテストデータについて比較してみる。まず、テストが必要な項目を、「顧客番号」、「商品コード」、「数量」、「納品予定日」の４つと仮定する。プログラム全体の流れとして、この順序でチェックを行うものとする。ここでは境界値の確認等、複雑なところは排除して、各項目それぞれがチェック条件を満足するかしないかという確認基準で、確認に必要なデータがどのくらいなのかまとめる。
従来のシステムで初期開発した場合、４つの項目のテストデータを準備した上で確認する。４つの項目について各条件すべてを満足するテストデータの組合せが１つ、各項目が一つずつ条件を満足しないテストデータの組合せが４つ考えられ、全部で５つのテストデータの組合せが必要である。また、テストデータの組合せを考えるときに考慮しなければいけない条件が発生する。つまり、各項目は順番に確認処理が流れるので、確認したい項目の先に処理がなされるすべての項目に対し、それぞれの条件を満足するテストデータを設定しなければならない。
【００１７】
本発明のシステムで初期開発した場合、４つの項目をそれぞれ独立して１つずつ確認する。１つの項目で条件を満足する、しないテストデータの組合せが２つずつ、全部で８つの組合せが必要である。また、各項目同士の影響は考慮する必要がないため、従来方式のテストデータのような考慮すべき条件は発生しない。仕様変更時のテストデータについても同様に比較する。従来のシステムでの仕様変更時は、４つの項目のテストデータを準備した上で確認する。４つの項目について各条件すべてを満足するテストデータの組合せが１つ、仕様変更した項目が条件を満足しないテストデータの組合せが１つ考えられ、全部で２つのテストデータの組合せが必要である。また、テストデータの組合せを考えるときに考慮しなければいけない条件が発生するのは初期生成時と同様である。
【００１８】
一方、本発明のシステムでの仕様変更時は、仕様変更した項目のみを確認する。条件を満足する、しないテストデータの組合せが２つで全部である。つまり、従来方式のテストデータのように、テストが必要な部分に関係ないデータを準備する必要がない。
データ量について考察すると、初期開発時の場合、本発明のシステムの方がテストデータの組合せの数が多いが実質の設定値は８データであり、従来のシステムでは２０データである。また、仕様変更後の開発時においても、本発明のシステムの実質の設定値は２データで、従来のシステムの設定値は８データである。つまり、本発明のシステムでは、従来のシステムに比べてテストデータの量が少なくなる効果がある。
その他に、従来のシステムでは、テストデータ作成時にお互いの項目の設定値について考慮する必要があり、プログラム全体の規模が大きくなればなるほどその条件が厳しくなるという問題があるが、本発明のシステムでは、お互いの項目の設定値について考慮する必要がなく、プログラムの全体規模に対する修正規模が小さい場合ほどテストデータの量が従来のシステムより少なくなるので、準備作業およびテストにかかる作業が軽減できる。
【００１９】
本発明のシステムを用いた注文明細画面プログラムの生成処理を例として説明する。ここでは図３に示すような表示画面を生成することとする。また、この画面の各項目の動作は次のような仕様とする。
１）顧客番号、注文日、商品コード、数量および納品予定日を入力する。
２）「確認」ボタンを押下すると、顧客名と商品名が自動入力される。
３）「注文」ボタンを押下すると、明細の内容がＤＢに格納され、注文処理の次段階へ進む。
４）顧客番号は、入力必須かつ数字とする。かつ顧客ＤＢに顧客番号が既に存在すること。
５）注文日は、日付のチェックを行う。
６）商品コードは、数字とする。かつ商品ＤＢに商品コードが既に存在すること。
７）数量は、数字とする。かつ  在庫数−数量≧０  であること。
８）納品予定日は、日付のチェックを行う。かつ  注文日＜納品予定日であること。
【００２０】
メインメニュー画面は図４に示すようなボタンを備える。「画面設計」ボタン（２８）、「帳票設計」ボタン（２９）、「ＤＢ設計」ボタン（３０）、「ファイル設計」ボタン（３１）、「部品テスト」ボタン（３２）、「プログラム設計」ボタン（３３）、「プログラム生成」ボタン（３４）を備え、各ボタンは、ソフトウェア開発における各作業に対応しており、ボタンを押下することにより、各メニューの画面に遷移する。本発明のシステムを用いたプログラム作成方法では、図２のような手順で処理を進めるので、まず、システム設計である「画面設計」、「帳票設計」、「ＤＢ設計」、「ファイル設計」について、それぞれの画面に遷移して、データ項目とそれに対応するチェック条件および編集条件を設定する。次に「部品テスト」画面からテストデータと想定結果を設定して動作テストを実施し、「プログラム設計」画面から入出力ファイルと部品の設定を行い、最後に「プログラム生成」画面で対象となるプログラムを自動生成する。以下に各画面毎の設定と処理を説明する。ここでは画面表示のみを対象とするため、「帳票設計」「ＤＢ設計」「ファイル設計」は省略する。
【００２１】
まず画面設計について説明する。画面設計のメイン画面である「画面設計―登録編集」画面は図５に示すような構成である。画面名称の表示エリア（３５）、画面で使用するデータ項目属性定義エリア（３６）、「保存」ボタン（３７）、「キャンセル」ボタン（３８）、「チェック条件入力」ボタン（３９）、「編集条件入力」ボタン（４０）で構成されている。データ項目定義エリア（３６）は、画面で使用するデータ項目名、タイプ、桁数を入力する。本例では、データ項目のデータ項目名として顧客番号、注文日、商品コード、数量および納品予定日、それぞれについてのタイプ、桁数を入力する。「保存」ボタン（３７）を押下すると、定義内容を画面仕様書としてデータ定義書（３）に格納することができる。「キャンセル」ボタン（３８）は入力した内容を破棄することができる。「チェック条件入力」ボタン（３９）は、各データ項目に対する「単項目チェック」及び「関連チェック」を定義する「画面設計−チェック条件入力」画面に遷移するボタンである。「編集条件入力」ボタン（４０）は、各データ項目に対する「編集条件」を定義する「画面設計−編集条件入力」画面に遷移するボタンである。本例では、図５「画面設計―登録編集」画面でデータ定義後、図６に示す「画面設計−チェック条件入力」画面で「単項目チェック」及び「関連チェック」を設定し、図９に示す「画面設計−登録・編集」画面で「編集条件」を設定し、次に移ることとする。
【００２２】
図６は、「画面設計−チェック条件入力」画面の例である。「画面設計」画面で指定した画面名称表示エリア（４１）、定義するチェックの種類の選択（「単項目チェック」タブ（４２）、「関連チェック」タブ（４３））、「標準チェック条件反映」ボタン（４４）、チェック条件入力エリア（４５）、チェック条件毎の「参照」ボタン（４６）、「保存」ボタン（４７）、「キャンセル」ボタン（４８）、「データ項目辞書登録」ボタン（４９）、「条件清書」ボタン（５０）から構成されている。定義するチェック条件の種類を切り替えるためには、「単項目チェック」タブ（４２）または、「関連チェック」タブ（４３）の何れかを押下することで切り替える。「標準チェック条件反映」ボタン（４４）を押下することにより、単項目チェックで必要な標準的なチェック条件を取得できる。チェック条件入力エリア（４５）では、データ項目毎にチェック条件を入力する。条件の入力は、「参照」ボタン（４６）を押下して遷移するチェック条件選択画面で入力する。ここでは「顧客番号は、入力必須」「注文日は、日付のチェックを行う」等の独立したチェック条件を入力する。「保存」ボタン（４７）を押下することにより、入力したチェック条件を格納することができる。「キャンセル」ボタン（４８）の機能は上記と同様である。「単項目チェック」タブ画面には「データ項目辞書登録」ボタン（４９）があり、単項目チェックで定義したチェック条件をデータ項目辞書１２に登録する機能を持つ。データ項目辞書に登録されたチェック条件は、プログラム生成時に、ソースとして展開される。「条件清書」ボタン（５０）を押下することにより、定義したチェック条件をドキュメントとして出力する。
図７は、「画面設計−チェック条件入力」画面で「関連チェック」タブ（５２）を選択した状態である。関連チェック条件入力エリア（５３）に、データ項目名が表示され、チェック条件を表示するエリアが現れる。最初は、チェック条件欄は空欄であり、「編集」ボタン（５４）を押下して遷移する入力画面で、「顧客番号」項目に対して「顧客マスタに顧客番号が既に存在すること」「注文日＜納品予定日であること」等の条件を入力することで条件が反映される。「関連チェック」タブ（５２）には、「部品生成」ボタン（５６）があり、押下すると関連チェックに定義したチェック条件に対する部品のテンプレートを生成することができる。「画面設計−チェック条件入力」画面で、本例の関連チェックを設定し、「保存」ボタン（５５）を押下すると、定義したチェック内容をチェック条件定義書（１）に格納する。また、「条件清書」ボタン（５７）はタブ間で共通であり、定義した単項目チェック・関連チェック内容を「チェック条件表」という設計ドキュメント（１１）として出力する。「チェック条件表」は図８に示すような構成である。ヘッダー部分には、対象の画面名称（本例では、「Ｍｅｉｓａｉ００１」）（５８）を出力し、単項目チェックの内容（５９）、関連チェックの内容（６０）を定義した内容に従って出力する。単項目チェックのデータ実体はキーワード等であるが、選択したチェック条件に対する文章に変換して出力する。これで仕様の４）〜８）の条件が定義されていることがわかる。このように、本発明のシステムではチェック内容を分かり易い文章形式で記述できるため、図２の（２０）または（２２）で生成する設計ドキュメントとしてそのまま利用できる。
【００２３】
図９は編集条件を設定する「画面設計−登録・編集」画面の例である。画面設計−編集条件入力」画面は、指定した画面名称（本例では「Ｍｅｉｓａｉ００１」）（６１）、自動生成可能な編集条件を定義する「自動生成」タブ（６２）、自動生成できない編集条件を定義する「ユーザ追加編集」タブ（６３）、「自動生成」タブで編集条件を定義する「自動生成編集条件」定義エリア（６４）、編集条件キーワードを選択する「参照」ボタン（６５）、編集する場合の入力側データ項目を選択する「参照」ボタン（６６）、標準的な編集条件を反映するための「標準編集条件反映」ボタン（６７）、定義した編集条件を編集条件定義書（２）として格納するための「保存」ボタン（６８）、定義内容を無効にする「キャンセル」ボタン（６９）、「自動生成」タブで定義した編集条件をデータ項目辞書に格納するための「データ項目辞書登録」ボタン（７０）、定義した編集条件を設計ドキュメント（１１）として出力するための「条件清書」ボタン（７１）から構成されている。この画面に遷移した状態では、「自動生成」タグに位置付けられており、前段階で設定された情報である、出力側の媒体名（画面名）、データ項目名（本例では、「顧客番号」「注文日」など）は初期表示されている。データ項目名はチェック条件と同様に「参照」ボタン（６６）押下により遷移する画面で選択し設定する。同様に編集条件キーワードも別画面でデータ項目を選択することにより入力できる。
【００２４】
図１０は、「画面設計−編集条件入力」画面で、「自動生成」タブ（６２）から、「ユーザ追加編集」タブ（６３）に切り替えた状態である。「ユーザ追加編集」タブでは、出力側のデータ項目が指定した画面（本例では、「Ｍｅｉｓａｉ００１」）の名称が媒体名に、データ項目名がデータ項目名欄に表示されている。ここでのデータ設定も「自動生成」の場合と同様に参照画面から入力するが、ユーザが独自に追加する内容なので、空欄の「編集条件」欄に編集条件を文章形式で入力し、「画面設計−編集条件入力」画面に反映する。
「画面設計−編集条件入力」画面で必要な条件を定義し、定義した編集条件を確認した後、「条件清書」ボタン（７１）を押下することにより、「編集条件表」とよぶ設計ドキュメントを出力する。図１１は、「編集条件表」の例である。ヘッダー部には、対象の画面名（本例では、「Ｍｅｉｓａｉ００１」）（７４）が出力され、編集条件は「自動生成」タブと「ユーザ追加編集」タブの定義情報を統合して、画面の項目順に出力する（７５）。このとき、「自動生成」タブで定義した編集条件は、チェック条件と同様に編集条件キーワードを文章形式に変換して出力する（例．編集キーワード（ＤＡＴＥ）を、「ｙｙｙｙ／ｍｍ／ｄｄの形式に編集する。」という文章に変換する）。このように、本発明では編集内容を分かり易い文章形式で記述できるため、設計ドキュメントとしてそのまま利用できる。
【００２５】
次にＤＢ設計の画面入力について説明する。図１２はＤＢ設計のメイン画面である「ＤＢ設計−登録・編集」画面であり、指定したＤＢに対するデータ項目属性を定義する。設計対象のＤＢ名称（７６）が表示され（本例では、「ＤＢ０１」）、データ項目定義エリア（７７）に、データ項目名、タイプ、桁数を入力する。入力した内容を確認し、「保存」ボタン（７８）を押下することにより、定義したＤＢ設計情報をＤＢ仕様書としてデータ定義書（３）に格納できる。入力した内容を無効にしたい場合は、「キャンセル」ボタン（７９）を押下することにより、入力する直前の状態にできる。
【００２６】
図１３は、図７に示す「画面設計−チェック条件入力」画面で「部品生成」ボタン（５６）を押下した場合に表示される「チェック条件入力−部品生成」画面である。これにより図２の（２１）に示す部品テンプレートの生成を行う。この画面で対象画面名称（本例では、「Ｍｅｉｓａｉ００１」）（８０）、データ項目と部品名の一覧表（８１）を出力する。部品の一覧表を印刷したい場合は、「一覧表印刷」ボタン（８３）を押下する。部品は、対象画面に定義された関連チェック毎に生成されたテンプレートである。部品の編集は、「編集」ボタン（８２）を押下して、チェック条件やソース編集欄にソースのスケルトンを表示した別画面で行う。図１４は、ソース編集欄に実際にコーディングを行った例を図に示す（８４）。
【００２７】
ここまでが図２の（１６）と（２２）にあたる処理である。次に（２３）から（２５）にあたる部品テストの画面操作について説明する。「部品テスト」のメイン画面である「部品テスト−部品一覧表示」の例を図１５に示す。この画面で部品を選択し（ここでは「Ｍｅｉｓａｉ００１−００１」「Ｍｅｉｓａｉ００１−００２」）、「テストプログラム生成」ボタン（８９）を押下し、遷移した画面上で生成したいテストプログラムの名称を「テストプログラム名」として入力し、部品名に対応付けて設定する。それぞれの部品のテストを行うための「テストプログラム名」のテストプログラムを一覧表示する「部品テスト−テストプログラム一覧表示」画面の例を図１６に示す。この画面は「部品テスト−部品一覧表示」画面で「テストプログラム一覧表示」ボタン（９０）を押下して遷移する。画面には、対象の画面名（本例では、「Ｍｅｉｓａｉ００１」）（９１）、「Ｎｏ．」「テストプログラム」「部品名」からなる一覧表示（９２）が表示される。内容を確認後、「テスト」ボタン（９３）を押下することにより、テストプログラムを使用して部品のテストを行う処理が開始する。
まず図１７に示すような「テストプログラム一覧表−テスト」画面に遷移し、テストデータの作成、想定結果の作成、テストの実行の順に操作を行う。「テストプログラム一覧表−テスト」画面はテストプログラムの状況を表す一覧表と、「テストデータ作成」ボタン（９４）と、「想定結果作成」ボタン（９５）と、「テスト実行」ボタン（９６）と「結果検証」ボタン（９７）と「キャンセル」ボタンで構成される。選択するテストプログラムの「選択」欄にチェックマークをつけ、テストデータを作成する場合は、「テストデータ作成」ボタン（９４）を押下する。想定結果の作成を行うためには、「想定結果作成」ボタン（９５）を押下する。それぞれ別画面でデータの作成を行い、作成データを保存して「テストプログラム一覧表−テスト」画面に戻るとデータ有りと表示される。それぞれのデータの作成画面では過去に作成したデータを読込むことも「編集」ボタンで編集することも、組み合わせで作成することも可能である。
【００２８】
テストデータ、想定結果作成後、「テスト実行」ボタン（９６）を押下してテストを実行する。対象のテストプログラムの実行結果は別画面で「テストプログラム名」に対応する実行結果（ログ）として表示する。表示画面を確認するボタンを押下すると、図１８の「テストプログラム一覧表−テスト」画面で、対象のテストプログラムに対する「テスト実行」表示が「済み」と表示される。
【００２９】
最後に結果検証を行うために、「結果検証」ボタン（９８）を押下すると、図１９に示すような「テスト−結果検証」画面に遷移する。図１９は、対象の「テストプログラム名（本例では、「Ｍｅｉｓａｉ＿ｔｓｔ００１」）（９９）、「結果検証一覧」（１００）が表示される。更に、「結果検証一覧」（１００）には、「Ｎｏ．」「データ項目」「想定結果」「実行結果」「検証結果」が出力される。検証結果が「○」になれば、想定結果通りの結果が得られたということになる。検証結果を印刷する場合は、「印刷」ボタン（１０１）を押下する。ここまでで部品の動作テストが終了したことになる。
【００３０】
次に図２の（２６）に対応するプログラム設計処理で入出力ファイルと部品を設定する画面操作を説明する。
図２０は、「プログラム設計」のメイン画面である。画面は、プログラム名称を入力する「プログラム名称」入力エリア（１０４）、標準パターンを選択するための「標準パターン」選択エリア（１０５）、選択した標準パターンの入出力関係を示す「パターン概念図」（１０６）、「入出力定義」ボタン（１０７）、「部品定義」ボタン（１０８）、「キャンセル」ボタン（１０９）、「メニューへ」ボタン（１１０）から構成されている。「プログラム名称」（１０４）を入力して「入出力定義」ボタン（１０７）を押下すると、図２１に示すような「プログラム設計−入出力定義」画面に遷移する。「部品定義」ボタン（１０８）を押下すると、図２２に示すような「プログラム設計−部品定義」画面に遷移する。
【００３１】
図２１に示す「プログラム設計−入出力定義」画面は、「プログラム名称」（本例では、「ＰＲＧ＿Ｍｅｉｓａｉ００１」）（１１１）、「パターン選択」（本例では、「ＰＴＮ００１」）（１１２）、入出力ファイルを指定するための「参照」ボタン（１１３）、「ＯＫ」ボタン（１１４）、「キャンセル」ボタン（１１５）、「Ｎｏ．」「種別」「入出力ファイル名」からなる「入出力一覧」（１１６）で構成されている。画面に対する入出力ファイル名は、画面に対応する「参照」ボタン（１１３）を押下して別画面でこれまで登録された画面仕様書名の一覧から選択することで「Ｍｅｉｓａｉ００１」を設定する。ＤＢに対応する入出力ファイル名の設定も同様に行い、ＤＢに対応する「ＭｅｉｓａｉＤＢ０１」「ＭｅｉｓａｉＤＢ０２」「ＭｅｉｓａｉＤＢ０３」が登録できる。
【００３２】
図２２に示す「プログラム設計−部品定義」画面は、対象となるプログラム名称（本例では、「ＰＲＧ＿Ｍｅｉｓａｉ００１」）（１１７）、「定義部品一覧」表示エリア（１１８）、「部品追加」ボタン（１１９）、「部品削除」ボタン（１２０）、「ＯＫ」ボタン（１２１）、「キャンセル」ボタン（１２２）から構成されている。「定義部品一覧」表示エリア（１１８）には、プログラムの入出力定義で定義した画面、ＤＢで使用している部品を表示される。また、独自に部品を作成して、「部品追加」ボタン（１１９）や「部品削除」ボタン（１２０）で追加・削除を行うことができる。部品の設定と選択が完了して、「ＯＫ」ボタン（１２１）を押下すると、定義内容をプログラム定義書（６）に格納し、「プログラム設計」画面に戻り、部品定義内容が反映される。
【００３３】
最後に図２の（２７）に対応するプログラム生成について説明する。
図２３は、プログラム生成処理の「メインメニュー」画面である。画面は、対応の「プログラム名称選択」（１２３）、「生成」ボタン（１２４）、「メニューへ」ボタン（１２５）から構成されている。まず、「プログラム名称選択」（１２３）で、生成したいプログラム名称を選択し（本例では、「ＰＲＧ＿Ｍｅｉｓａｉ００１」）、「生成」ボタン（１２４）を押下することにより、プログラム生成を実行できる。プログラム生成結果は別画面で処理メッセージとして表示する。以上で、標準パターン、データ項目辞書、テスト済みの部品を組合せて、そのまま動作できるプログラムソース（１４）を生成することができる。
【００３４】
本発明のプログラムの自動生成システムで仕様変更に対応する処理を以下に説明する。
仕様変更時には、変更があった部分を修正してプログラムを再生成することでプログラムの変更が実現する。例えば数量チェック条件が「数量が  在庫数−数量≧１００」に変更になった場合には、下記のように変更処理を行う。
まず、「メインメニュー」画面で、「画面設計」ボタンを押下し、「画面設計」画面に遷移する。対象となる画面名称を選択し、「選択・編集」ボタンを押下することにより、「画面設計−登録・編集」画面に遷移する。ここでは、関連チェックに関する仕様変更を行うため、まず「チェック条件入力」ボタンを押下して、「画面設計−チェック入力」画面に遷移して、関連チェックを再定義する。ここでは数量に関する関連チェックの仕様変更を行うため、Ｎｏ．３の「数量」に対応する「編集」ボタンを押下して、「チェック入力−編集」画面に遷移し、関連チェック内容を修正して再定義する。修正内容確認後、「画面設計−チェック条件入力」画面で「条件清書」ボタンを押下することにより、「チェック条件表」上で変更内容を確認することができる。ここでは図８で「在庫数―数量≧０」であった条件が、図２４のように「在庫数―数量≧１００」になっていることが確認できる。
【００３５】
次にチェック条件に対応する処理内容を変更するため、「画面設計−チェック条件入力」画面で「部品生成」ボタンを押下し、「チェック条件入力−部品生成」画面を表示する。部品は、対象画面に定義された関連チェック毎に生成されたデータ項目名が同じ場合はその内容をコピーした形で生成される。仕様変更により、チェック条件が新たに追加になった場合は、テンプレートを生成する。ここでは変更したデータ項目名「数量」が同じため、対応する部品ファイルは内容のコピーとなっている。部品の編集は、「編集」ボタンを押下することにより行う。
【００３６】
図２５に示すような「部品生成−編集」画面で、該当する「ＩＦ  在庫数  −  数量  ＜  ０」の条件を「ＩＦ  在庫数  −  数量  ＜  １００」と修正することで、所望の変更が実現する。修正後、「保存」ボタンで内容を保存する。内容保存後、「メインメニュー」画面から遷移する「部品テスト」サブメイン画面で新規生成時と同様に対象となる画面の対象となるテスト部品のテストプログラムを作成する。ここでは図２６に示すように「部品テスト−部品一覧表示」画面で、変更があった「数量」項目に対する部品「Ｍｅｉｓａｉ００１−００３」が未テスト状態と表示されるので、これにチェックを付けて。新規作成時と同様の手順で対応するテストプログラム「Ｍｅｉｓａｉ＿ｔｓｔ００２」を再作成し、テストデータの作成、想定結果の作成、テスト実行、結果検証、の順でテストを実施し、結果に問題の無い事を確認する。このように、従来はプログラム全体を実行するのに必要なテストデータを準備しなければならなかったが、仕様変更の影響がある部品のテストデータだけ準備すればよいため、従来に比べてテストデータの準備作業およびテストにかかる作業を軽減することができる。
部品テスト終了後、新規生成時と同様の手順でプログラム設計処理、プログラム生成処理を行い、仕様変更後のプログラムを再生成する。
【００３７】
【発明の効果】
以上、本発明によれば、予め検証済みの標準パターンと、データ項目辞書から生成できるソースと、既にテスト完了した部品を組み立てる方式により自動プログラム生成を行うシステムが実現し、仕様変更時にも新規開発時と同様の操作で再生成が可能となる。また、プログラム動作テストについて、従来方式のテストデータのように、テストが必要な部分に関係ないデータを準備する必要がなく、お互いの項目の設定値について考慮する必要もないので、プログラムの全体規模に対する修正規模が小さい場合ほどテストデータの量が従来のシステムより少なくなり、準備作業およびテストにかかる作業が軽減できる。さらに、各プログラムが、単位ソースごとにコーディング、テスト可能なので設計者とプログラマ間のコミュニケーションのずれ等による品質低下を招きにくい、ドキュメントとソースの内容に不整合が発生しにくい、という効果がある。
【図面の簡単な説明】
【図１】システム機能構成を示す図。
【図２】本発明の開発手順を示す図。
【図３】実施例の画面仕様のイメージを示す図。
【図４】メニュー画面を示す図。
【図５】画面設計−登録・編集を示す図。
【図６】画面設計−チェック条件入力を示す図。
【図７】画面設計−チェック条件入力を示す図。
【図８】チェック条件表を示す図。
【図９】画面設計−編集条件入力を示す図。
【図１０】画面設計−編集条件入力を示す図。
【図１１】編集条件表を示す図。
【図１２】ＤＢ設計−登録・編集を示す図。
【図１３】チェック条件入力−部品生成を示す図。
【図１４】部品生成−編集を示す図。
【図１５】部品テスト−部品一覧表示を示す図。
【図１６】部品テスト−テストプログラム一覧表示を示す図。
【図１７】テストプログラム一覧表−テストを示す図。
【図１８】テストプログラム一覧表−テストを示す図。
【図１９】テスト−結果検証を示す図。
【図２０】プログラム設計を示す図。
【図２１】プログラム設計−入出力定義を示す図。
【図２２】プログラム生成−部品定義を示す図。
【図２３】プログラム生成−変更を示す図。
【図２４】チェック条件表を示す図。
【図２５】部品生成−編集を示す図。
【図２６】部品テスト−部品一覧表示を示す図。
【符号の説明】
１    チェック条件定義書，
２    編集条件定義書，
３    データ定義書，
４    テストデータライブラリ，
５    標準パターンライブラリ，
６    プログラム定義書，
７    システム設計，
８    部品テスト，
９    プログラム設計／生成，
１０  ソフトウェア開発支援システム，
１１  ドキュメント，
１２  データ項目辞書，
１３  部品ライブラリ，
１４  ソースプログラムライブラリ，
１５  システム設計，
１６  チェック条件、編集条件定義書作成，
１７  チェック・編集内容生成，
１８  生成内容判定，
１９  チェック条件、編集条件定義書編集，
２０  ドキュメント生成，
２１  部品生成（枠のみ），
２２  ドキュメント生成，
２３  チェックリスト、テストデータ作成，
２４  自動生成不可部分作成，
２５  動作テスト，
２６  プログラム設計，
２７  プログラム生成，
【図１】
2005043931.tif 000003
【図２】
2005043931.tif 000004
【図３】
2005043931.tif 000005
【図４】
2005043931.tif 000006
【図５】
2005043931.tif 000007
【図６】
2005043931.tif 000008
【図７】
2005043931.tif 000009
【図８】
2005043931.tif 000010
【図９】
2005043931.tif 000011
【図１０】
2005043931.tif 000012
【図１１】
2005043931.tif 000013
【図１２】
2005043931.tif 000014
【図１３】
2005043931.tif 000015
【図１４】
2005043931.tif 000016
【図１５】
2005043931.tif 000017
【図１６】
2005043931.tif 000018
【図１７】
2005043931.tif 000019
【図１８】
2005043931.tif 000020
【図１９】
2005043931.tif 000021
【図２０】
2005043931.tif 000022
【図２１】
2005043931.tif 000023
【図２２】
2005043931.tif 000024
【図２３】
2005043931.tif 000025
【図２４】
2005043931.tif 000026
【図２５】
2005043931.tif 000027
【図２６】
2005043931.tif 000028