JP2006318448A - インタフェース画面設計中心のソフトウェア生産工程の自動化方法及び、この方法をプログラム化して収録したコンピュータで読出し可能な記録媒体｛Ｍｅｔｈｏｄｆｏｒａｕｔｏｍａｔｉｏｎｏｆｓｏｆｔｗａｒｅｍａｎｕｆａｃｔｕｒｉｎｇｐｒｏｃｅｓｓｂａｓｅｄｏｎｇｒａｐｈｉｃｕｓｅｒｉｎｔｅｒｆａｃｅｄｅｓｉｇｎ，ａｎｄＣｏｍｐｕｔｅｒｒｅａｄａｂｌｅｍｅｄｉｕｍｈａｖｉｎｇｔｈｅｒｅｏｎｃｏｍｐｕｔｅｒｅｘｅｃｕｔａｂｌｅｉｎｓｔｒｕｃｔｉｏｎｆｏｒｐｅｒｆｏｒｍｉｎｇｔｈｅｓａｍｅ｝ - Google Patents

Abstract

【課題】 ビジネスプロセスに対する理解と設計能力を備えた人々の役割範囲を拡大し、インタフェース画面設計中心のソフトウェア生産工程の自動化方法を提供する。
【解決手段】 ユーザが入力するデータの項目名表示欄、対応するデータ入力欄、及びイベントボタンを含む業務プログラムのユーザインタフェース画面をグラフィックユーザインタフェース（ＧＵＩ）で作成する。次に、ＤＢ名及びテーブル名を指定し、各インタフェース画面を分析してテーブルのフィールド設計情報を自動抽出する。続いて、テーブルごとにフィールド構造を定義したデータベース設計図（ＥＲＤ）をグラフィックインタフェースで作成する。続いて、テーブルのフィールド構造を参照してＳＱＬ命令文を自動生成して物理的データベースを作成する。続いて、ボタンの動作と連動して実行されるＳＱＬ命令文を自動生成し、ボタンの動作イベントと連動させる。
【選択図】 図１

Description

本発明は、業務用コンピュータプログラムを開発する方法及び著作システムに関するものであり、プログラミングの専門技術者ではない実際の業務論理と流れを理解している人が迅速でかつ効率よくコンピュータプログラムを開発できるようにする、プロセス知識とユーザインタフェース中心のソフトウェア自動生産方法及び著作システムに関する。

コンピュータプログラムすなわち、ソフトウェアの開発において標準化された開発方法論は、１９７０年代以後ウォーターフォール・モデル（Ｗａｔｅｒｆａｌｌ Ｍｏｄｅｌ）のパラダイムに基づいた「構造的開発方法論」が体系的に定立されながらその発展が始まった。

構造的開発方法論は、開発過程を「要求」−「分析」−「設計」−「プログラミング」−「検査」−「運用」−「メインテナンス」という形に分割する。そして、段階的に具現プロセスを体系化し、開発プロセスごとに特化した開発ツールと図形的な技法を通じて、複雑で難解な概念や手順及び管理をわかりやすく支援した。また、ソフトウェア開発の論理的な側面と物理的な側面とを分離し、物理的設計に先立って論理的設計が先行されなければならないという点を強調し、このように二つの過程に分離することでシステムの具現に入る前に利用者にシステムの論理的設計案を提示して、事前検討を受けることができるようにした。
しかしながら、構造的開発方法論はソフトウェア開発方法において開発のプロセスの体系を確立する契機にはなったが、１９８０年代以後ソフトウェアの機能が急激に多様化され、ユーザの要求水準も益々高まりつつあり、ソフトウェア生産の限界に直面することになった。特に、以前はソフトウェアの開発が単位モジュールや単位プログラムを開発するレベルに留まったが、１９８０年代以後には企業の全社的なレベルでの情報システムに対するニーズが発生し、企業の戦略的な側面まで考慮した大型プロジェクトが現れ、既存の構造的開発方法論では変化する環境にうまく適応することができなかった。
このような限界を解決すべく、１９８１年Ｃ．Ｆｉｎｋｅｌｓｔｅｉｎは情報工学 （Ｉｎｆｏｒｍａｔｉｏｎ Ｅｎｇｉｎｅｅｒｉｎｇ）という用語を提案し、Ｊ．Ｍａｒｔｉｎはこの思想を方法論で具体化した「情報工学方法論」を定立して幅広く広めた。ここで、情報工学とは「企業や企業の核心部門が要求する情報システムの計画、 分析、設計及び構築に必要な定型化された方法の応用」をいう。
情報工学開発方法論は企業中心の思想を持っているため、企業情報と企業の業務手順に焦点を合せてシステムデータと自動化手順を模型化している。また、「計画」−「分析」−「設計」−「構築」とつながる各段階間の柔軟な進行と統合を追求し、方法論とケースツールが相互補完的な役割が十分果たせるようになっている。そこで、情報工学に基づいて作られた多様な開発方法論は、その方法論に合うケースツールを導入したり、独自で開発した方法論とケースツールをともに提供している。

上記情報工学開発方法論に基づいた方法論は基本的に次の手順に従う。すなわち、ユーザの要求事項を把握してそれを図式化する分析段階 → 分析段階で作られたモデルに基づいてプログラム起動に必要なデータベース構造を設計する段階 → ユーザの要求事項とデータベース構造に合う画面レイアウトを詳細に設計する段階 → コーディング作業を遂行して実行プログラムを具現する段階 → 部分的に具現されたプログラム及びシステムを上向式の方法で統合していく段階 → 各プログラムの細部機能と統合されたプログラムの機能をテストする検査段階 → テストを終えたシステムを実際運用環境へ移して事後管理を遂行する適用段階などで構成される。

上記情報工学開発方法論は、構造的な開発方法論が持っている論理的体系性を基に企業の情報システム構築という大型プロジェクトを支援できるほど膨大に設計され、各段階別に最適化されたケースツールがともに提供される実用性まで揃えていた。さらに、プロジェクトの管理側面まで補完して１９８０，１９９０年代のソフトウェア開発、情報システム構築において代表的な方法論となった。
しかしながら、情報工学的開発方法論の体系的で徹底した管理を追求する特性は、過度に多くの時間と費用を要求するようになる。また、その根幹には依然として構造的開発方法論のパラダイムに基づいているため、システム開発の柔軟性においても多くの問題を含んでいた。そこで１９９０年代半ば以後、これに対する代案として客体指向方法論、ＣＢＤ方法論などの概念が登場して活発に研究されることになったが、まだ十分に実用化されているとはいえないのが現実である。

現在、殆どのビジネス向けのコンピュータプログラム及びソフトウェアの開発で使われている情報工学的方法論体系と開発システムとは今でも次のような問題を多く含んでいる。

第一、複雑な手順と膨大な規模を特徴とする既存ソフトウェア開発方法論の低い実用性とそれによるソフトウェア開発体系化の難しさが挙げられる。
すなわち、既存の開発方法論は非常に複雑に構成されており、要求する産出物の量も膨大である。例えば、韓国電子通信研究院（ＥＴＲＩ）で研究開発して、韓国内の代表的なコンポーネント基盤の開発方法論として活用されている「ＭＡＲＭＩ−ＩＩＩ」の場合、全体４個のｐｈａｓｅ、３０個のａｃｔｉｖｉｔｙ、９６個のｔａｓｋで構成されており、要求される産出物の種類も膨大である。そして、特定のタスクで作成された産出物が他のタスクに参照され、修正される作業まで考えれば、単に産出物の数で立てられる予想工数以上の作業量が必要になるだろう。
このように既存の開発方法論が複雑な手順と膨大な規模で構成された理由は、最初の分析段階からデータ構造とプロセス及びユーザインタフェース体系までを同時に考慮し、システムを構築していく方式であるからである。このような方式の開発方法論は開発者に立体的な視角と接近方式を持たせるように要求する。そして、既存の方法論はデータとプロセスというソフトウェア的な領域だけでなくシステムを構築する技術的な環境までも同時に考慮している。このような前提では本当にすばらしい方法論が登場して完璧に立体的な接近方法を提示し、段階別に必要な産出物及び指針を明確に定義したとしても、これは既に実用的な経済性をなくすほど複雑になる。

第二、分析及び設計段階からデータベース構造を最も優先的に考慮し、具現することにより発生する構造的な非効率性及び非現実性が挙げられる。
すなわち、ソフトウェア開発過程で柔軟性が最も低くて、問題が発生したり追加事項があるときに修正が最も難しい部分はデータベースと関連した部分である。データベースの構造に少しでも変更事項が発生すればそれに関連した数多くのモジュールが影響を受け、これにより工数が極めて増加することになる。したがって、常識的には柔軟性が低い作業は全体の工程上、後半部で行われるのが自然なことである。
ところが、既存の開発方法論ではデータベースと関連した部分は、全体の開発工程上、前半部に位置するため、基本的な前提がソフトウェアの遂行する核心機能であるビジネス及び業務機能の自動化から外れ、データ処理にあらゆる関心を集中させていた。そこで、方法論上の分析段階からプロセス分析とともにデータモデリング作業が行われるので、設計段階でも最終処理及び保存されるデータベース構造を物理的次元まで設計するのに重点を置いて処理してきた。すなわち、プログラムソースコーディングなど本格的な具現作業に入る前にデータ構造が既に確定されるわけである。

このような方式が今まではあまりにも当然なことに認められてきたが、この方式には二つの大きな構造的な問題点を持っている。
一つは、分析段階からデータ構造を考慮していくのがプロセスを根本的に改善し、革新するのに相当な制約条件として作用されるという点である。最初、情報工学が登場したときには現場で発生する問題を分析し、非効率的な部分を修正して人が処理した仕事を情報技術に切り替えるのが情報システム開発の本質であった。したがって、現行のプロセスとデータ構造を開発者に理解しやすく伝達する必要があり、その方法として登場したのがまさに多様なモデリング技法であった。このように過去には開発方法論が現実をそのまま模型化することに主眼を置いたが、今日では現行システムやプロセスを革新することが重要なイシューとなっている。
言い換えれば、真のプロセス革新やＢＰＲを推進するためには、既存システムや現場の業務処理手順及び慣行から一歩後退して、ＩＴという革新的な手段を活用し、より合理的なプロセスだけを研究して発展させることが需要者の最も重要な要求となっている。このような観点から見れば、分析、設計段階から現在の遂行構造に対応するデータ構造を考慮すると同時にプロセスの改善可能性や効率性を評価し進行するのは根本的な目的を達成するのに殆ど不可能なことである。

データベースをプロセスの前の段階で考慮することのもう一つの構造的な問題は、一度確定されたデータベース構造を変更するにはいろいろな試行錯誤と莫大な努力及び時間が投入され、これにより設計段階からテストと検証に過度の努力が所要されるという点である。先述のように、データ構造と関連した部分は柔軟性が非常に低くて一度確定されれば修正するのが難しい。したがって、実際の具現段階でプロセスやデータ構造に問題点が発見されたり、追加要求事項が発生してデータベース構造での簡単な修正作業を一つ行う場合にも、該当するモジュールの画面及び出力物構造とソースコードなどの修正だけではなく、このモジュールと連携されて作動する前後方の関連モジュールや上下位機能を遂行するモジュールまですべて直さなければならないという問題が発生する。このように単純な修正作業さえも非常に大変なことであるが、その上に各段階ごとに一つ一つ確実なテストと検証作業を行わなければならないので非常に過度な費用と努力が必要となってくる。それにもかかわらず、複雑な産業現場を反映する応用ソフトウェアは必然的にこのような試行錯誤を繰り返しているのである。

第三、業務プロセスの設計者と専門開発者の役割が明確に区別されており、互いのコミュニケーションに多くの時間と費用が消耗され、業務プロセス専門家の知識をソフトウェアに完全に反映させるのには限界がある。
すなわち、既存の開発方法論はコンピュータ技術を持った開発者と業務論理を理解しているユーザの役割を明確に分けている。これは開発者とユーザが持っている知識だけでなくシステムを把握する観点も全く異なるために表れる当然な結果である。
まず、知識の側面から見れば、開発者の場合には業務論理を正しく理解していない状態であり、ユーザの場合にはシステムを構築できるほどの開発能力や知識を持っていない状態である。そして、システムを眺める観点においても二人の主体には大きな差が発見される。ソフトウェア開発においてユーザはシステムが何（Ｗｈａｔ）をしてくれるのかが観点であるが、開発者はどのように（Ｈｏｗ）具現するのかが観点である。したがって、開発者はプログラムの開発の際、何をどのように作るかをユーザや関連専門家と十分に協議しながら仕事を進めなければならない。このように分析−設計−開発につながる段階にこのように多くて複雑な検討と承認及びテスト手順が含まれざるをえないことである。
このような特性のために分析・設計段階ではコミュニケーションが非常に重要な要素であり、コミュニケーションが最も活発に行われる段階でもある。実際に開発者とユーザ間のコミュニケーションはソフトウェア開発プロジェクトで最も重要ではあるが、最も成功的に遂行することも難しい部分である。

そして、ソフトウェア開発において必須的な二つの領域（業務プロセスに対する理解と開発技術）をこのように分担しているというのは、システムの分析−設計段階だけでなく、その以後の段階にも多くの問題点を引き起こしている。そのためにソフトウェア開発は本質的に難しい作業であり、開発方法論も複雑になるのである。
開発者とユーザ間に存在するこのようなギャップをなくしてコミュニケーションの効率性を高めるために多様なツールと技法が研究・開発された。ＥＲＤやＤＦＤ、ＵＭＬなどのような分析及びモデリング部分を支援するツールは複雑な現状を抽象化させ理解しやすくし、開発者とユーザ間のコミュニケーションの不一致を最小化するのに役に立った。
また、プロトタイプを利用するのは開発者にユーザの要求事項が何であるかを明確に糾明し、要求事項を確実に理解させる有用な方法の一つではある。しかし、プロトタイプを完成品へ移行するほど多くの変化が発生することになり、結局はユーザに完成品に対しての間違った情報を提供することで誤解を引き起す。さらに、他のプログラムやシステムとの交流及び統合などに対する良い結果を容易に得られないという問題点も含んでいる。
つまり、最終的にソフトウェアを使用するユーザの立場だけを考えれば、業務プロセスを本質的に理解している業務プロセス設計者が設計から具体的な具現作業まで行うのが最も理想的なことである。しかし、既存の開発方法と開発システムではハードウェアや運営体制を制御する詳細な機能までを視野にいれてソースコードで開発しなければならなく、再使用性を通じてソフトウェアの開発生産性を極大化するというコンポーネント基盤の開発方法論さえも結局は各コンポーネントを組み立て、ユーザインタフェースと連係する作業は専門開発者により行わなければならない作業であり、先述のように業務プロセス設計者の役割を根本的に拡大させるのは不可能なことである。

この他に、特許文献１に示されるような技術も知られている。

特開２００３−２７１２５６号公報

本発明は、上記のような従来の技術の問題点を解決するために創案されたものであり、人が行うべきである必須事項を最初段階で大部分を設計して置けば、その後のプログラムとデータベースとを実際に具現する数多くの作業はほとんど自動化することで、具体的なインタフェース画面よりデータベース構造などの抽象的な設計作業を先に遂行することで発生する生産性低下、試行錯誤、時間と費用の所要、設計者と開発者間のコミュニケーション問題などを解決するのが主な目的である。
特に、本発明は業務用ソフトウェアを生産するにあたって、本質的な競争力といえるビジネスプロセスに対する理解と設計能力を揃えた人々の役割範囲を最大限に拡大すると同時に、具現段階の各部分を最大限に人工知能で自動化し、開発を支援する著作システムを開発することで、過去の方法論及び体制と比較したとき、革新的に短時間でかつユーザ指向的な高機能ソフトウェアを開発する生産体制を構築することにその目的がある。

上記の技術的課題を達成するための本発明は、ユーザインタフェース画面を先に設計し、その以後生産工程を自動化する逆工学方式の業務プログラム自動生産方法であって、（ａ） ユーザから入力されるデータの項目名表示欄及びこれに対応してデータが入力されるデータ入力欄と、機能識別が可能なイベントボタンとを含む業務プログラムのユーザインタフェース画面をグラフィックユーザインタフェースで作成する段階と、（ｂ） インタフェース画面を通じて、入力されるデータが保存されるＤＢ名及びテーブル名を各インタフェース画面ごとに設計者から指定される段階と、（ｃ） 各インタフェース画面を分析して項目名表示欄の項目名とデータ入力欄のサイズとに基づいてテーブルのフィールド設計情報を自動抽出する段階と、（ｄ） 各インタフェース画面ごとに分析されたフィールド設計情報と各インタフェース画面ごとに指定されたテーブル名を参照してテーブルごとにフィールド構造を定義したデータベース設計図（ＥＲＤ）をグラフィックインタフェースで作成する段階と、（ｅ） 上記データベース設計図に表示されたテーブルのフィールド構造を参照してデータベースを作成するためのＳＱＬ命令文を自動作成し実行して物理的データベースを作成する段階と、（ｆ） 上記イベントボタンの機能を識別してボタンの動作と連動して実行されるＳＱＬ命令文を自動作成してボタンの動作イベントと連動させる段階と、を含むことを特徴とする。
望ましくは、上記 （ｃ） 段階は、（ｃ１） 各インタフェース画面に含まれたデータ入力欄を基準にして項目名表示欄の探索方向と探索範囲とを設計者から指定される段階と、（ｃ２） 指定された探索条件に応じて各データ入力欄ごとに項目名表示欄に記載された項目名を抽出する段階と、（ｃ３） 抽出された項目名をフィールド名に指定するか、または抽出された項目名を所定の基準により加工してフィールド名に指定する段階と、（ｃ４） 上記データ入力欄のサイズを計算してフィールド長さに指定する段階と、（ｃ５） データ入力欄と指定されたフィールド名とを互い連係させる段階と、を含む。ここで、上記の加工は、例えば抽出された項目名からスペース及び特殊記号を削除することを言う。
望ましくは、上記 （ｃ４） 段階は、各データ入力欄に対して現在フォントの種類及びサイズを認識してデータ入力欄に入力できる文字の数を計算してフィールド長さとして指定する段階である。
本発明の（ｂ） 段階では、設計者が選択したインタフェース画面内の所定文字列がテーブル名として指定されることが望ましい。ここで、上記所定文字列はインタフェース画面の題目であり得る。
望ましくは、各インタフェース画面とデータベース設計図とは相互同期化されている。このような場合、設計者によりインタフェース画面に含まれた項目名表示欄またはデータ入力欄の追加、削除、変更が行われれば、その変更された事項がデータベース構造図に自動反映される。さらに、設計者によりデータベース構造図に含まれた特定テーブルのフィールドに対する追加、削除、またはフィールドの名称及び属性が変更されれば、該特定テーブルと関連したインタフェース画面で項目名表示欄及びデータ入力欄の追加、削除、変更の形態で自動反映される。
本発明において、上記イベントボタンの機能は、データの保存、削除、以前レコードへの移動及び以後レコードへの移動からなる群より選択された一つまたは二つ以上の組み合わせであり得る。
上記のような本発明に伴うソフトウェア生産工程の自動化方法は、コンピュータで読出し可能な記録媒体に保存することができる。このような記録媒体はコンピュータシステムによって読み出せるようにプログラム及びデータが保存されるあらゆる種類の記録媒体を含む。その例は、ＲＯＭ（Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）、ＲＡＭ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）、ＣＤ（Ｃｏｍｐａｃｔ Ｄｉｓｋ）−ＲＯＭ、ＤＶＤ（Ｄｉｇｉｔａｌ Ｖｉｄｅｏ Ｄｉｓｋ）−ＲＯＭ、磁気テープ、フレキシブルディスク、光データの保存装置などがある。また、このような記録媒体はネットワークで連結したコンピュータシステムに分散され、分散方式でコンピュータが読み出すことができるコードに保存され、実行することができる。

本発明によれば、ビジネス用のコンピュータプログラムを開発することにあたって本発明で提示する開発方法と著作システムを活用すれば、最終の結果といえるユーザインタフェース画面の構造と機能を優先して設計するために、開発作業進行中の試行錯誤と修正作業を最小化できるだけでなく実行プログラムを具現する生産性自体を飛躍的に高めることができる。

本発明は既存の開発方法論と異なり、（１）入出力文書設計、（２）ＤＢ構造自動設計、（３）コーディング作業の自動実行という順序に改善することで、ソフトウェアの生産速度の向上が図れる。すなわち、既存にはＤＢ構造に若干の変化が発生しても関連されたあらゆるプログラムモジュールに対するコード修正作業とテスト作業とを新しく行わなければならなかったが、本発明で提示する生産方式ではＧＵＩ方式で最終的な使用画面を設計すれば、ＤＢ構造設計やコーディング作業は著作システムの助けを受け、あらゆる関連のある部分が自動的に遂行されることになるので、最終の使用画面に変化が発生する場合にもこれを把握して直ちに関連されたＤＢ構造に変更作業を自動に遂行するためソフトウェアの生産速度向上と維持補修の容易性を確保することができる。

また、本発明が提供するソフトウェア著作システムの各部分は、過去にソフトウェア開発技術があるプログラマーだけ遂行することができた作業を専門開発技術がない現場実務者や業務プロセス専門家が直接遂行することができるようになると同時に、多くの作業を自動的に進行してくれる。

このように本発明では、従来のソースコードを中心とするソフトウェア開発方式で設計及び要求分析作業は業務専門家が遂行し、実際の具現作業は開発技術者が分担して遂行した形態を改善して、業務に対する知識を持ってユーザ要求分析の能力がある人々が最終産出物の設計と具現を同時に遂行することができるようになり、ユーザ指向的で実用的なソフトウェアの開発が可能になる。

すなわち、業務用またはビジネス用のソフトウェア開発に必要な核心的な知識といえる業務プロセスに対する理解力は持ったが、専門的なプログラミング技術は不足して実用的なビジネス用コンピュータプログラムを開発できなかった業務論理の理解者やプロセス専門家の役割と機能の範囲を大きく拡張することができる。
このように業務論理の理解者が設計から具現までソフトウェア生産手順の核心工程で実質的な役割を果たすことになると、従来のソフトウェア開発方式で業務専門家と開発技術者間のコミュニケーションに消耗された直接的な費用と時間は勿論、コミュニケーション誤解によって発生する試行錯誤と費用などをなくしてソフトウェアの設計及び生産速度を革新的に向上させることができる。

本明細書に添付される下記の図面は本発明の望ましい実施例を例示するものであり、後述の発明の詳細な説明とともに本発明の技術思想をより一層、理解を深める役割をするためであり、本発明が図面に記載された事項のみに限定して解釈されてはならない。

以下、添付された図面を参照して本発明の望ましい実施例を詳細に説明することにする。その前に、本明細書及び請求範囲に使われた用語や単語は通常的で辞書的な意味に限定して解釈してはいけないのであり、発明者は本発明を最善の方法で説明するため用語の概念を適切に定義することができるという原則の基に、本発明の技術的思想に当たる意味と概念で解釈すべきである。したがって、本明細書に記載された実施例と図面に示された構成は本発明の最も適した一つの実施例に過ぎず、本発明の技術的思想のすべてを代表するものではないことを認知し、本出願時点においてこれらを代えることができる多様な均等物と変形例があり得ることを理解すべきである。

図１は本発明の実施例による「ソフトウェアの自動生産方法」の概略的な流れ図である。
図面に示されたように、本発明が提示するソフトウェアの自動生産方法は大別して六つの細部段階１０１〜１０６で構成される。
具体的には、「最終インタフェース画面の様式と細部機能設計及び定義」段階１０１は、コーディングなど専門的なソフトウェア技術を保有していないユーザ（例えば、プロセス分析家、業務論理を理解している実務者など）が誰でも容易に使用することができるＧＵＩ方式の開発著作ツールを利用して、実際エンドユーザ（Ｅｎｄ−Ｕｓｅｒ）が使用する入出力画面を構成するデザイン要素を生成（図２参照）し、該画面で行われるプロセスと細部処理機能とを実現するためアプリケーションの具体的な機能の設計及び定義する作業を遂行する段階である。
「インタフェース画面を自動分析してＤＢ設定のための情報抽出及び指定」段階１０２は、以前の段階１０１で設計、作成したインタフェース画面上で、実際にエンドユーザがデータを入力する入力欄と関連名称（例えば、図５の「使用者コード」等）を自動に探索してインタフェース画面を構成する入力欄が連結されたデータベースのフィールド名を自動抽出し、これを物理的なデータベースのフィールドとして適した形で使用できるようにスペースや特殊文字を除去した後、データ入力欄の情報を保存するデータベースのフィールド名に自動的に指定する段階である。また、この段階では、入力欄が連結されたデータベースのテーブル名もテーブル名称の自動指定プログラム（図７参照）を活用して簡単に一括・自動指定することになる。

インタフェース画面を構成するデータ入力欄が連結されるテーブル名とフィールド名とが指定された後に、「保存」、「削除」、「以前レコードへ移動」、「以後レコードへ移動」などの機能をする機能ボタンを作成すれば、本発明が提供する著作システムにより該当機能の遂行のために実行命令語であるコード（ＳＱＬ文章等）が自動的に作成される。この過程が「ボタンの機能を分析して実行命令語のコード自動作成」段階１０３である（図１２参照）。
インタフェース画面を設計した後には、各データ入力欄に指定されたＤＢ設定情報（テーブル名、フィールド名、データ型、データ長さ、連結フィールド（Ｊｏｉｎ情報）等）を分析してデータベース設計図（以下、ＥＲＤ）を作成しなければならない。この過程が「ＤＢ設定のための情報を分析してＥＲＤ自動作成」段階１０４である（図９参照）。
ＥＲＤが作られた後、該ＥＲＤの内容に合う物理的データベース構造を作成するためのテーブル及びフィールド作成ＳＱＬ文章を作成しなければならない。この作成も「ＥＲＤを分析して物理的ＤＢ生成に必要なＳＱＬ自動作成」段階１０５で本発明の著作システムを通じて、自動に生成することになる（図１０参照）。

最後に、「ＳＱＬ命令を実行してプログラム運営に必要な物理的ＤＢ生成」段階１０６では、段階１０５で自動作成した物理的ＤＢ生成ＳＱＬを実行して実際に活用する物理的データベース構造を作成することになる。
上のような過程を経て、既存のプログラミング言語に対する知識や技術が不足した業務論理理解者がエンドユーザのインタフェース画面だけ設計すれば、本発明が提供する方法論と細部支援著作システムを活用して物理的データベースの作成まで含んだ、完成した応用プログラムを非常に早く開発し、この状態でまさに実務に適用することができる。

図２は図１で説明した「ソフトウェア自動生産方法」の各細部段階を支援するための本発明の実施例による著作システムの画面例示図である。
参照番号２０１は本発明で提供する著作システムのメインフレームであり、参照番号２０３は著作システムで開発中であるインタフェース画面の例である。参照番号２０３のようなインタフェース画面は、業務用プログラムを開発するのに必要な要素機能を標準オブジェクト化して提供されるビジネスコンポーネント２０２を使用して設計及び具現することになる。

図３は図１を参照して説明した「ソフトウェア自動生産方法」の各細部段階を支援するために本発明で提供する著作システムの主要機能構成とこれらのリレーションを示す。図３を構成する細部構成要素は、以後に別途の図面や図面の一部にて追加的な説明をする。ここでは概括的な機能と図１で説明した生産方法との連関性を中心にして説明する。

業務用プログラムのインタフェース画面を設計するときは、一般にデータ入力欄の左側や上段に該当データ入力欄に保存する情報を表示する項目名表示欄を作成し、この項目名がデータベースのフィールド名に使われる場合が多いのである。
データ入力欄の名称探索部３０１は、インタフェース画面が設計されれば、各データ入力欄の左側や上段を自動に探索して該当データ入力欄の項目名が存在するのかを確認する。項目名が存在すればデータベースのフィールド名調整部３０２で該当項目名を物理的データベースのフィールド名として使用できるように、スペースや特殊文字を除去した後、データベースフィールド名の自動設定部３０４に伝達する。
データベースのフィールド長さ表示部３０３は、インタフェース画面設計の際、データ入力欄を作成するときマウスのドラッグを通じてデータ入力欄の長さを調節すれば、該当入力欄に入れる文字の数を自動計算して画面上に小さなツールチップで表示する（図６の６０３参照）。そして、ユーザがドラッグしたマウスボタンを置いた瞬間、データ入力欄の長さを自動的に認識してデータベースのフィールド長さの自動設定部３０５に伝達する。
なお、インタフェース画面を設計するときには、一般に該当画面の名称が該当画面を構成するデータ入力欄の共通したテーブル名に使われる場合が多い。このような点に鑑みてデータベース・テーブル名の一括指定部３０６では、インタフェース画面を構成するデータ入力欄のテーブル名として一括指定しようとする項目名表示欄を設定し、該当項目名（例えば、インタフェース画面の題目）をあらゆるデータ入力欄のテーブル名として一括指定する。

各データ入力欄が連結されたテーブル名とフィールド名及びフィールド長さが指定されれば、プログラムの実行ＳＱＬ自動作成部３１０では、該当情報を分析してインタフェース画面で使用している機能イベントボタンの種類によってプログラム実行時に使用するＳＱＬなどの文章を自動的に作成する。
データベース設計図の自動一括生成部３０７では、先に指定したＤＢ設定情報（テーブル名、フィールド名、データ型、データ長さ、連結フィールド（Ｊｏｉｎ情報）等）を分析してＥＲＤを自動作成する。そして、データベース設計図の解析部３０８でこのＥＲＤ情報を分析し、物理データベース生成ＳＱＬ作成部３０９でＤＢ生成のためＳＱＬ文章を自動生成する。
インタフェース画面設計と関連データベースの作成が完了した以後にもＥＲＤ上で変更事項がある場合にＥＲＤ修正作業とインタフェース画面の修正作業を常に同期化された状態を維持するため、データベース設計図及びインタフェース画面の同期化部３１１では、ＥＲＤ情報の変更に応じてインタフェース画面のデータ入力欄のＤＢ設定情報を自動に変更して別々に修正する面倒をなくしてくれる機能をする。

図４は、「インタフェース画面を構成するデータ入力欄のテーブル名とフィールド名を項目名表示欄などを探索して自動に設定するプログラム部」の論理的な流れ図である。
まず、設計者はインタフェース画面を設計した（４０１）後、画面を構成する項目名表示欄の中で該当画面のデータ入力欄のテーブル名に使用するオブジェクトを選択する。また、データ入力欄の題目をどの方向で自動探索するか、そしてどんな範囲（横認識範囲または縦認識範囲）内にあるものを題目として認識するのかに対する自動認識処理基準を設定する（４０２）。
設計者がここまで作業をした後、該当インタフェース画面を保存すると、データ入力欄のテーブル名とフィールド名の自動探索及び設定プログラムは、まず設計者が該当インタフェース画面のデータ入力欄で共通したテーブル名として使用するように指定した項目名表示欄を探索した（４０３）後、インタフェース画面を構成するあらゆる構成オブジェクトのリストを作成する（４０４）。それから、段階４０５から段階４１５までの過程を繰り返しながら各データ入力欄のテーブル名とフィールド名を指定することになる。

具体的には、インタフェース画面を構成するオブジェクトがデータ入力欄であるかを確認する（４０５）。データ入力欄である場合、前段階で設計者がテーブル名として使用しようと設定した項目名表示欄の項目名を該当データ入力欄のテーブル名に設定する（４０６）。そして、段階４０２で設定した項目名の自動認識方向を確認する（４０７）。認識方向が縦である場合には縦認識範囲値によりデータ入力欄の項目名を探索及び確認し（４０８）、認識方向が横である場合には横認識範囲値によりデータ入力欄の項目名を探索及び確認する（４０９）。そして、画面構成オブジェクトリストから項目名表示欄を一つずつ探索しながら（４１０）該当項目名表示欄が前段階で設定した項目名の自動認識方向及び認識範囲値の条件に当たるのかを確認する（４１１）。条件に当たる場合、該当する項目名表示欄の内部にデータ入力欄のインデックスを保存し、項目名表示欄とデータ入力欄とを連結する（４１２）。そして、項目表示欄の項目名で実際データベースのフィールド名に使用することができないスペースや特殊文字を除去した（４１３）後、段階４１２で連結したデータ入力欄のフィールド名に設定する（４１４）。
一つのデータ入力欄に対して上のように段階４０５から段階４１４までの過程を遂行してから、段階４０４で作成した画面構成オブジェクトリストから次のオブジェクトを探索して、存在する場合にはデータ入力欄なのかを確認する（４０５）過程からさらに繰り返し、存在しない場合にはプログラムを終了する。

図５は、「データ入力欄のテーブル名及びフィールド名の自動探索プログラム」の一実施例の図面である。
図面から見られるように、一般的なデータ入力画面では５０１のような項目名表示欄とそれに対応する５０２のようなデータ入力欄がペアになって存在する場合が殆どである。図面で項目名表示欄はテキストが記入された領域であり、データ入力欄は長方形ボックスが入力された領域である。図５のプログラム画面で設計者がデータ入力欄の題目認識方向５０３と横及び縦認識範囲値５０４を設定すれば、図４の段階４０７、４０８及び４０９で、データ入力欄のテーブル名及びフィールド名を自動で探索するための基準情報に活用することになる。

図６は、「データ入力欄のフィールド名及びフィールド長さを自動に設定するプログラム」の一実施例である。
図面に示されたように、例えばデータ入力欄６０２には項目名表示欄６０１の項目名がフィールド名に指定される（６０４参照）。また、データ入力欄６０２を実際に作成するためにマウスをドラッグすれば、その長さを認識して選択されたフォント（Ｆｏｎｔ）の種類とサイズなどを考慮して該当する長さに入力できる文字数をリアルタイムで著作システム画面上に自動に表示する（６０３参照）。そして、設計者が特定の長さに合せてマウスボタンを置けば、その瞬間に画面上に表示された文字数を該当データ入力欄のフィールド長さに自動設定することになる（６０５）。

図７は、「データ入力欄のテーブル名に使用する題目表示欄を選択して該当題目表示欄の題目を該当インタフェース画面に存在するあらゆるデータ入力欄のテーブル名に一括指定するプログラム」の一実施例の図面である。
図面に示されたように、インタフェース画面の題目７０１でマウスの右側ボタンをクリックして該当題目表示欄をテーブル名として使用するように設定すれば（７０２参照）、該当インタフェース画面内部のあらゆるデータ入力欄に対してテーブル名を題目表示欄７０１の題目で一括指定することになる（７０３参照）。

図８は、「ＥＲＤ自動設計プログラム」内部の進行手順を示している流れ図である。
図面を参照すれば、まずユーザがあらかじめ設計しておいた特定インタフェース画面を選択した後、ＥＲＤ自動設計機能を作動すれば、ＥＲＤ自動設計プログラムはインタフェース画面を構成するオブジェクトのリストを作成する（８０１）。そして、このリストを参照して画面構成オブジェクトを一つずつ点検しながらデータ入力欄である場合に（８０２）、該当データ入力欄の各種データベース設定情報を確認して文字列形態のデータ組み合わせを作成する。
まず、データ入力欄であることが確認されれば、データ型とフィールド長さを確認する（８０３）。それから、論理的ＥＲＤモデルで使用する項目名（物理的モデルでのフィールド名と区別すべきである）を確認する。このとき、図４の段階４１２で特定項目名表示欄がデータ入力欄と連結されインデックスを有している場合には、項目名表示欄の項目名をデータ入力欄の項目名に設定する（８０５）。そして、該当データ入力欄と連結された項目名表示欄がない場合には、ユーザが指定したデータ入力欄の固有名称とデータ入力欄のインデックスとを組み合わせて「データ入力欄の名称＿データ入力欄のインデックス」の形態で項目名を設定する（８０６）。

論理的モデルのための項目名の設定後には、データ入力欄の残ったＤＢ設定情報であるテーブル名、フィールド名を確認して該当データ入力欄が主キー（Ｐｒｉｍａｒｙ Ｋｅｙ）に指定されているのか、他のテーブルの特定フィールドを参照して外部キー（Ｆｏｒｅｉｎ Ｋｅｙ）に使われているのかに対しても把握する（８０７）。
最後に、このようにインタフェース画面を構成するデータ入力欄に対して段階８０３から８０７までの過程を経ながら収集された「ＥＲＤ作成のための設計情報（データ入力欄のインデックス、テーブル名、フィールド名、データ型、フィールド長さ、項目名、ＰＫ情報、ＦＫ情報）」をデータ入力欄固有の文字列形態に組み合わせる（８０８）過程を経れば、インタフェース画面のデータ入力欄からＥＲＤ設計情報を抽出する作業を完了することになる。このように一つのデータ入力欄に対して情報抽出作業が終われば、段階８０１で作成した構成オブジェクトリストから次のオブジェクトを探索して（８０９）、データ入力欄である場合に段階８０３から段階８０８までの過程を繰り返す。すなわち、インタフェース画面を構成するあらゆるデータ入力欄に対して上のような過程を遂行する。

ＥＲＤ自動設計プログラムでは、このように作られたＥＲＤ設計情報を組み合わせて設計情報文字列上に存在するテーブルとフィールドのリストをツリー形態で作成する（８１０）。これを基準にしてＥＲＤ図面上に必要なテーブルを自動生成した（８１１）後、ＥＲＤ設計情報からフィールド名と項目名情報とを読み出して物理的ＥＲＤモデルにはフィールド名を表示し、論理的ＥＲＤモデルでは段階８０５や段階８０６で設定された項目名を表示するようになる（８１２）。
テーブルとフィールドの作成が終われば、ＥＲＤ設計情報で各フィールドごとに指定されたデータ型とフィールド長さ情報に応じてＥＲＤ図面上に適用し（８１３）、主キー（ＰＫ）に指定されたフィールドはテーブル最上段へ移動させ別途表示をして、主キーフィールドであることを示す（８１４）。最後に、ＥＲＤ設計情報のＦＫ情報に応じて関係のあるテーブル間に連結する（８１５）過程を終わりにして、ＥＲＤ自動設計が完了する。

図９は、「ＥＲＤ自動設計プログラム」の一実施例の図面である。
図面に示されたように、ＥＲＤ自動設計プログラムでは、まずインタフェース画面の目録９０３を見ながらＥＲＤを作成しようとする画面を選択する。すると、プログラムでは該当画面から読み出されたＥＲＤ設計情報を自動で分析して必要なテーブルとフィールドリストをツリー形態に構成した後、画面上に表示するようになる（９０２）。そして、ユーザがＥＲＤ自動設計命令を下すと、９０１のようなＥＲＤ図面表示部に自動に設計されたＥＲＤが描かれる。

図１０は、「テーブル作成のためのＳＱＬ自動作成及び実行プログラム」の一実施例の図面である。
ユーザが図１０のようなＥＲＤ自動設計プログラムを使用してＥＲＤ図面１００１を自動作成したり、最初から直接設計した後、該当するＥＲＤ図面に合う物理的テーブル作成命令をすると、テーブル作成のためのＳＱＬ自動作成プログラムは、テーブル作成に必要なＳＱＬ文章１００２を自動作成する。このとき、ユーザは細部オプション設定ウィンドウ１００３でテーブル及びフィールド別、作成可否とテーブル作成に必要な各種オプション１００４を自由に選択してＳＱＬ文を新しく編集して作成することもできる。
ここで、設定できるオプションには、基本キー指定可否、参照キー指定可否、テーブル作成可否、同名のテーブル存在時に既存テーブル削除可否、ビューテーブル作成可否、同名のビューテーブル存在時に既存ビューテーブル削除可否、各コラム別有効性及びディフォルト値の設定可否、Ｐｕｂｌｉｃ権限設定（Ｇｒａｎｔ）及び制限（Ｄｅｎｙ）可否などがある。
このようにテーブル作成のためのＳＱＬ文章を自動作成した後、ユーザがテーブル作成命令を下すと、該当ＳＱＬ文章を直ちに実行して物理的データベース内に該当テーブルとフィールドを作成する。

図１１は、図１０で見た「テーブル作成のためのＳＱＬ自動作成及び実行プログラム」の進行手順を示す図面である。
図面を参照すれば、まずＥＲＤ図面（図１０の１００１）からテーブル及びフィールド情報を探索する（１１０１）。それから、作成すべきテーブルとフィールドをツリー形態に構成して画面上に表示し、ユーザが必要としないテーブルやフィールドを除外させる（１１０２）。ユーザは、作成しようとするテーブルとフィールドが確定されれば、ＳＱＬ作成の際に必要な各種オプションを設定する（１１０３）ことができる。
上のようにテーブル作成のためのＳＱＬ自動作成に必要な基本情報が確定されれば、ユーザはテーブル作成のためのＳＱＬ文章を作成するように命令を下す（１１０４）。すると、プログラムは前段階で設定した情報を総合し分析して必要なＳＱＬ文章を作成した後、画面（図１０の１００２）上に表示する（１１０５）。ユーザが最終的にＳＱＬ文章の実行命令を下すと、該当ＳＱＬ文章を実行して物理的なデータベース内にテーブルを自動に作成する（１１０６）。

図１２は、「インタフェース画面分析の後、ＤＢ動作に必要なＳＱＬ文章を自動作成するプログラム」の一実施例の図面である。このプログラムは、図１の「ボタンの機能を分析して実行命令語コード自動作成」段階１０３で動作することになり、図３の「プログラム実行ＳＱＬ自動作成部」３０１に該当することを明らかにしておく。
図面を参照すれば、インタフェース画面設計者は、まず特定インタフェース画面１２０１を設計して画面内にＤＢ動作を起こすための機能ボタンを作成しなければならないである。図面で機能ボタンは、「前ページ」、「次ページ」、「図書情報」及び「修正」ボタンである。必要なボタンを作成した後、特定機能ボタンのところでマウス右側ボタンをクリックすれば（１２０２）、該当機能ボタンのクリック時に自動で作成、実行されるＳＱＬ文章の内容を予想することができる（１２０３）。

図１３は、図１２で見た「インタフェース画面分析後、ＤＢ動作に必要なＳＱＬ文章を自動作成するプログラム」の進行手順を示す図面である。
図面を参照すれば、まずユーザがインタフェース画面に機能ボタンを作成し、その種類を定義すれば（１３０１）、プログラムではユーザが機能ボタンをクリックしたときに作動させるＳＱＬ文章を自動的に作成する。具体的に、プログラムはまず機能ボタンの種類を確認する（１３０２）ことになるが、その以後の過程は機能ボタンの種類によって変わる。すなわち、新しいレコードを作成する「保存」ボタン及びレコードを削除する「削除」ボタンである場合と、直前のレコードまたは直後のレコード情報を読み出す「以前レコードへ移動」、「以後レコードへ移動」の類型のボタンなどによって以後の手順が変わる。

まず、機能ボタンの種類が「保存」または「削除」である場合の手順をみると次の通りである。まず、プログラムはインタフェース画面内にあるデータ入力欄を検索して使われたテーブル名を確認し（１３０３）、特定テーブルのどんなフィールド名が使用されているのかも確認する（１３０４）。テーブル名とフィールド名とが確認されれば、この情報でＩｎｓｅｒｔ、Ｕｐｄａｔｅ文のＩｎｔｏ節とＤｅｌｅｔｅ文のＦｒｏｍ節を作成する（１３０５）。それから、「保存」ボタンである場合インタフェース画面にユーザが入力した値を読み出してＩｎｓｅｒｔ文のＶａｌｕｅ節とＵｐｄａｔｅ文のＳｅｔ節を作成する（１３０６）。最後にＷｈｅｒｅ節を作成するために主キーに指定されたフィールド名を探索した（１３０７）後、この主キーを条件とするＷｈｅｒｅ節を作成し（１３０８）、Ｉｎｓｅｒｔ、Ｕｐｄａｔｅ、Ｄｅｌｅｔｅ文章を完成することになり、テーブルの数だけ段階１３０３から１３０９までの過程を繰り返すことになる。このように作成されたＳＱＬ文章は、ユーザが機能ボタンをクリックしたときやプログラムモジュールを保存するときに自動的にＳＱＬ文章を作成する機能を遂行することになる（１３１８）。

次に、機能ボタンの種類が「以前レコードへ移動」または「以後レコードへ移動」である場合の手順を見ると次の通りである。まず、インタフェース画面のデータ入力欄欄を検索して主キーに指定されたフィールド名が何であるかを確認し（１３１０）、該当する主キーを条件とするＷｈｅｒｅ節を作成する（１３１１）。データ入力欄に使われたテーブル名を調べて各テーブルごとに別称（ａｌｉａｓ）を付与し（１３１２）、データ入力欄のフィールド名を利用してＳｅｌｅｃｔ文のフィールドリストを構成する（１３１３）。

そして、もし特定データ入力欄が他のテーブルのフィールドを参照して外部キー（Ｆｏｒｅｉｎ Ｋｅｙ）として使われるように設定した場合には、該当する連結フィールド情報を読み出して、その情報に応じてＪｏｉｎ節を作成することになる（１３１４）。このように作られたＪｏｉｎ節とテーブルリストを利用してＦｒｏｍ節を作成し（１３１５）、特定データ入力欄がレコード揃えの基準に指定された場合も該当する情報を読み出してＯｒｄｅｒｂｙ節を作成する（１３１６）。

それから、以前の段階ごとに作成した部分を組み合わせてＳｅｌｅｃｔ文を完成することになり（１３１７）、このように作成されたＳＱＬ文章はユーザが機能ボタンをクリックしたときやプログラムモジュールを保存するときに自動的にＳＱＬ文章を作成する機能を遂行することになる（１３１８）。

図１４は、「ＥＲＤ情報変更の際にインタフェース画面やコードを自動修正するプログラム」の構成図として、図３の「データベース設計図及びインタフェース画面同期化部」３１１に該当するプログラムである。
図面を参照すれば、プログラムはＥＲＤ図面上で設計者がテーブル名、フィールド名、フィールド長さ、データ型、ＰＫ情報、ＦＫ情報等を変更した場合（１４０１、１４０２、１４０３）に、該当するＥＲＤ図面と関連したインタフェース画面のデータ入力欄にも変更された情報を反映してくれる機能をする。もちろん、ユーザがＥＲＤ図面とインタフェース画面とを自動に同期化するように設定した場合（１４０４）にのみ作動することになる。
変更事項があってユーザが変更事項をインタフェース画面に自動適用するように設定した場合（１４０５）には、変更された情報の種類、変更された値、変更されたフィールドを使用するインタフェース画面のパス、変更されたフィールドを使用するデータ入力欄のインデックスに文字列を作成する（１４０６）。このように文字列の形態に作られた変更情報はインタフェース画面を設計するプログラムに伝送され（１４０７）、インタフェース画面を設計するプログラムでは文字列に存在するインタフェース画面を検索し（１４０８）、変更情報文字列の構成内容に応じてデータ入力欄の設定情報を自動的にリアルタイム変更してＥＲＤ図面とインタフェース画面間の同期化を行う。
以上のように、本発明はたとえ限定された実施例と図面により説明されたが、本発明はこれに限られずに本発明が属する技術分野で通常の知識を持つ者によって本発明の技術思想と以下に記載される特許請求の範囲の均等範囲内で多様な修正及び変形が可能なことは同然なことである。

本発明に係るソフトウェアの自動生産方法の流れ図。 本発明に係るソフトウェアの自動生産方法のインタフェース画面設計作業のため、ＧＵＩ著作システムの一実施例の図。 本発明に係るソフトウェアの自動生産支援の著作システムの構成図である。 本発明に係るデータ入力欄のテーブル名及びフィールド名の自動探索及び設定プログラムの流れ図。 本発明に係るデータ入力欄のテーブル名及びフィールド名の自動探索プログラムの一実施例の図。 本発明に係るデータ入力欄のフィールド名及びフィールド長さの自動設定プログラムの一実施例の図。 本発明に係るデータ入力欄のテーブル名を一括指定するプログラムの一実施例の図。 本発明に係るデータベースの設計図（ＥＲＤ）の自動設計プログラムの構成図。 本発明に係るＥＲＤ自動設計プログラムの自動生成ＤＢ情報表示部及びＥＲＤ表示部に対する一実施例の図。 本発明に係るテーブル生成のためのＳＱＬ自動生成及び実行プログラムの一実施例の図。 本発明に係るテーブル生成のためのＳＱＬ自動作成及び実行プログラムの流れ図。 本発明に係るインタフェース画面分析後、ＤＢ動作に必要なＳＱＬを自動生成するシステムの一実施例の図。 本発明に係るインタフェース画面分析後、ＤＢ動作に必要なＳＱＬを自動生成するシステムの構成図。 本発明に係るＥＲＤ情報変更の際、インタフェース画面やコードを自動修正するプログラムの構成図。

符号の説明

１０１ 「最終インタフェース画面の様式と細部機能設計及び定義」段階
１０２ 「インタフェース画面を自動分析してＤＢ設定のための情報抽出及び指定」段階
１０３ 「ボタンの機能を分析して実行命令語のコード自動作成」段階
１０４ 「ＤＢ設定のための情報を分析してＥＲＤ自動作成」段階
１０５ 「ＥＲＤを分析して物理的ＤＢ生成に必要なＳＱＬ自動作成」段階
１０６ 「ＳＱＬ命令を実行してプログラム運営に必要な物理的ＤＢ生成」段階

Claims (11)

1. ユーザインタフェース画面を先に設計し、その以後生産工程を自動化する逆工学方式の業務プログラム自動生産方法において、
   （ａ） ユーザから入力されるデータの項目名表示欄及びこれに対応してデータが入力されるデータ入力欄と、機能識別が可能なイベントボタンとを含む業務プログラムのユーザインタフェース画面をグラフィックユーザインタフェースで作成する段階と、
   （ｂ） インタフェース画面を通じて、入力されるデータが保存されるＤＢ名及びテーブル名を各インタフェース画面ごとに設計者から指定される段階と、
   （ｃ） 各インタフェース画面を分析して項目名表示欄の項目名とデータ入力欄のサイズとに基づいてテーブルのフィールド設計情報を自動抽出する段階と、
   （ｄ） 各インタフェース画面ごとに分析されたフィールド設計情報と各インタフェース画面ごとに指定されたテーブル名を参照してテーブルごとにフィールド構造を定義したデータベース設計図（ＥＲＤ）をグラフィックインタフェースで作成する段階と、
   （ｅ） 上記データベース設計図に表示されたテーブルのフィールド構造を参照してデータベースを作成するためのＳＱＬ命令文を自動作成し実行して物理的データベースを作成する段階と、
   （ｆ） 上記イベントボタンの機能を識別してボタンの動作と連動して実行されるＳＱＬ命令文を自動作成してボタンの動作イベントと連動させる段階と、を含むことを特徴とするインタフェース画面設計中心のソフトウェア生産工程の自動化方法。
2. 上記（ｃ）段階は、
   （ｃ１）各インタフェース画面に含まれたデータ入力欄を基準にして項目名表示欄の探索方向と探索範囲とを設計者から指定される段階と、
   （ｃ２）指定された探索条件に応じて各データ入力欄ごとに項目名表示欄に記載された項目名を抽出する段階と、
   （ｃ３）抽出された項目名をフィールド名に指定するか、または抽出された項目名を所定の基準により加工してフィールド名に指定する段階と、
   （ｃ４）上記データ入力欄のサイズを計算してフィールド長さに指定する段階と、
   （ｃ５）データ入力欄と指定されたフィールド名とを互い連係させる段階と、を含むことを特徴とする請求項１に記載のインタフェース画面設計中心のソフトウェア生産工程の自動化方法。
3. 上記の加工は抽出された項目名からスペース及び特殊記号を除去することを特徴とする請求項２に記載のインタフェース画面設計中心のソフトウェア生産工程の自動化方法。
4. 上記（ｃ４）段階は、
   各データ入力欄に対して現在フォントの種類及びサイズを認識してデータ入力欄に入力できる文字数を計算してフィールド長さに指定する段階であることを特徴とする請求項２に記載のインタフェース画面設計中心のソフトウェア生産工程の自動化方法。
5. 上記（ｂ）段階では、
   設計者が選択したインタフェース画面内の所定文字列がテーブル名に指定されることを特徴とする請求項１に記載のインタフェース画面設計中心のソフトウェア生産工程の自動化方法。
6. 上記所定の文字列はインタフェース画面の題目であることを特徴とする請求項５に記載のインタフェース画面設計中心のソフトウェア生産工程の自動化方法．
7. 各インタフェース画面とデータベース設計図とは相互同期化されていることを特徴とする請求項１に記載のインタフェース画面設計中心のソフトウェア生産工程の自動化方法。
8. 設計者によりインタフェース画面に含まれた項目名表示欄及びデータ入力欄の追加、削除または変更が行われる段階と、
   上記変更された事項がデータベース構造図に自動反映される段階と、を含むことを特徴とする請求項７に記載のインタフェース画面設計中心のソフトウェア生産工程の自動化方法。
9. 設計者によりデータベース構造図に含まれた特定テーブルのフィールドが追加、削除、またはフィールドの名称及び／または属性が変更される段階と、
   上記特定テーブルと関連されたインタフェース画面で項目名表示欄及び／またはデータ入力欄の追加、削除または変更の形態に自動反映される段階と、をさらに含むことを特徴とする請求項７に記載のインタフェース画面設計中心のソフトウェア生産工程の自動化方法。
10. 上記イベントボタンの機能は、データの保存、削除、以前レコードへ移動及び以後レコードへ移動からなる群より選択された一つまたは二つ以上の組み合わせであることを特徴とする請求項１に記載のインタフェース画面設計中心のソフトウェア生産工程の自動化方法。
11. 請求項１ないし請求項１０の何れか一項に記載の方法をプログラム化して収録したコンピュータで読出し可能な記録媒体。