エンティティの属性情報を定義したエンティティ定義書と、所定のユースケースにおいて操作対象となるエンティティの属性情報を示す操作対象属性一覧情報と、それら属性情報を操作するための入力欄に係るインタフェイスの構成を示す入力欄設計情報と、を含むユースケース定義書との二つの定義書から、データベースに保持されたエンティティに係る情報を操作するためのプログラムを自動的に生成するプログラム自動生成システムであって、前記エンティティ定義書からは属性情報を、前記ユースケース定義書からは操作対象属性一覧情報及び入力欄設計情報を取得する設計情報取得部と、前記操作対象属性一覧情報及び入力欄設計情報に基づいてエンティティの属性情報の操作のためのインタフェイスに係るコードを出力するインタフェイス用コード出力部と、前記属性情報から属性のデータベース上における操作に係るコードを出力するデータベース操作用コード出力部と、を有するプログラム自動生成システム。前記エンティティ定義書には、自動生成されるべきプログラムの利用者の情報と、前記利用者と少なくとも一のエンティティとの紐づけの定義とが含まれ、この紐づけの定義により直接または間接に利用者に紐付けられたエンティティの属性情報についてのみ当該利用者に対して操作権限を与える権限管理用コードを出力する権限管理用コード出力部をさらに有することを特徴とする請求項1に記載のプログラム自動生成システム。前記ユースケース定義書で定義する属性情報には、エンティティに対する操作を許可するための条件である操作許可情報が含まれ、前記操作許可情報に従ってエンティティに対する操作を許可する操作許可用コードを出力する操作許可用コード出力部をさらに有することを特徴とする請求項1又は2に記載のプログラム自動生成システム。前記ユースケース定義書は、操作完了後に移行する移行先のユースケースに係る移行先情報を含み、前記インタフェイス用コード出力部は、一のユースケース定義書で定義されたユースケースの完了後に前記移行先情報に従って他のユースケース定義書で定義されたユースケースを開始するコードを出力するためのユースケース移行用コード出力手段を有することを特徴とする請求項1乃至3のいずれか一に記載のプログラム自動生成システム。プログラム自動生成システムは、設計書の作成を要するのみであって、ソースコードの記述を要しないという点においてはプログラム開発工数をおおいに削減するものである。しかし実際にはプログラムの仕様において選択可能な項目は多岐にわたり、その細部にまで特定することを要したのでは、設計書の作成自体に多大の労力が要求される結果となってしまう。この点、特許文献1のプログラム自動生成装置では、予めひな型を用意し、同時にそのひな型ごとのソースコードを用意することで、自動生成という要求と、設計書作成の負担軽減という要求に応えようとしているものと思われる。しかし、特許文献1ではひな型をもとに編集された設計書からどのようにしてソースコードが自動生成されるのか、また、どのような技術により簡単な設計書から複雑なプログラムを自動生成するのかについては具体的な技術が開示されていない。第1発明は、二つの定義書、すなわちエンティティを定義するエンティティ定義書とユースケースを定義するユースケース定義書とからプログラムを自動的に生成するプログラム自動生成システムに関する。ここでエンティティとは実体ともいい、一単位として扱われるデータのまとまりをいう。また、ユースケースとは何らかの機能に関するプログラムとユーザとのやり取りをいう。第2発明は、プログラムの作成者がユーザについてデータへのアクセス権限について逐一決めなくても、エンティティ定義書にてエンティティ間の関連を定義するだけでユーザのデータに対するアクセス権限が自動的に決定されるプログラム自動生成システムに関する。第3発明は、ユースケース定義書でエンティティに対する操作を許可するための条件を定義し、その定義に従ってエンティティに対する操作を許可するプログラムを生成するプログラム自動生成システム、に関する。第4発明は、一のインタフェイスから他のインタフェイスに自動的に移行することにより業務を効率化することのできるプログラムを生成するプログラム自動生成システム、に関する。本願の発明によれば、データに対するアクセス権限の定義を個別に行うことなく、適切なアクセス権限管理をすることのできるプログラムを極めて簡単な設計書から自動生成することが可能となる。これによりプログラム開発の工数を大幅に削減することが可能となる。実施例1は請求項1に記載の第1発明に関する。実施例2は請求項2に記載の第2発明に関する。実施例3は請求項3に記載の第3発明に関する。実施例4は請求項4に記載の第4発明に関する。以下の説明では、本願発明のプログラム自動生成システムにより出力されるプログラムを単にプログラム、そのコードをコードと呼び、本願発明のプログラム自動生成システム自体のプログラムを出力元プログラム、そのコードを出力元コードと呼んで両者を明確に区別することにする。実施例1のプログラム自動生成システムは、情報のひとまとまりの単位であるエンティティの定義と、プログラムの利用者とプログラムとの間のやり取りについてのユースケースの定義とからプログラムを自動的に生成するシステムである。図1は、実施例1のプログラム自動生成システムの機能構成を表す図である。実施例1のプログラム自動生成システム0110は、プログラムの設計書である定義書0101から自動的にプログラム0120を生成する。定義書は少なくともエンティティ定義書0102とユースケース定義書0103とを含む。プログラム自動生成システムは、設計情報取得部0111と、インタフェイス用コード出力部0112と、データベース用コード出力部0113とを有する。設計情報取得部は、二つの定義書から必要な設計情報を読みとる。そしてインタフェイス用コード出力部は設計情報取得部から必要な設計情報を取得したうえでインタフェイス用コード0121を出力する。同様にデータベース用コード出力部は、データベース用コード0122を出力する。以下設例を用いて各部の構成を説明する。ある会社で、社内情報を管理し、社員間で情報を共有するためのプログラムを開発しようとしているものとする。ここで情報管理の対象となるエンティティは、社員、部署及び案件である。社員は必ずいずれか一の部署に所属する。また、案件は必ず一の部署が担当する。エンティティ定義書は、エンティティの属性情報を定義する。エンティティとは一単位として扱われるデータのまとまりをいう。設例では、社員、部署及び案件であり、これらのエンティティは属性を有する。属性とは、エンティティが有する性質や特徴を表す情報のことをいう。例えば、社員の属性は、名前、性別等である。図2は、実施例1のプログラム自動生成システムにおけるエンティティ定義書の一例を表す図である。社員、部署及び案件の三つのエンティティそれぞれについて定義がされている。それぞれのエンティティの定義書にはまずエンティティを特定するためのエンティティ名の欄0201がある。そして次に属性情報を定義するための属性名の欄0202があり、例えば社員エンティティでは、属性名の見出しの下に、ユーザID、パスワード、名前及び性別が列挙されている。属性名の欄の右側にはそれぞれの属性の型を定義する属性型の欄0203がある。例えば、ユーザID属性については文字列に、性別の属性については0男又は1女のいずれかに限定を行っている。図3は、実施例1のプログラム自動生成システムにおけるユースケース定義書の一例を表す図である。ユースケースとは何らかの機能に関するプログラムとユーザとのやり取りをいい、ユースケース定義書とはそのようなプログラムとのやり取り、つまり、典型的にはプログラム操作のためのユーザインタフェイスを定義するものなどをいう。例えば、社員をシステムに登録するためには、社員情報の入力を受け付け、入力された情報の妥当性を検証し、その後データベースへ保存する、という一連の処理を一体として行う必要があるが、ユースケースとは、このようなシステムとユーザとのやり取りと、そのやり取りに基づいて実行される処理等を定義するものである。本発明のユースケース定義書は、所定のユースケースにおいて操作対象となるエンティティの属性情報を示す操作対象属性一覧情報と、それら属性情報を操作するための入力欄に係るインタフェイスの構成を示す入力欄設計情報と、を含む定義書である。図3のユースケース定義書は、社員登録を行うためのユーザインタフェイスを定義するものの例である。操作対象定義欄0310には、ユースケース名欄0301、操作型欄0302及びエンティティ名欄0303がある。ユースケース名欄の社員登録は、このユースケース定義書で定義する操作が社員エンティティの登録に係るものであることを示しており、画面の表題に用いられる。操作型欄の登録は、操作の種類が登録であることを示している。他の操作型としては、変更及び削除等がありうる。さらに、エンティティ名欄の社員は、当該ユースケースで操作の対象となるエンティティは社員であることを示している。図3のユースケース定義書には、入力画面定義欄0320、確認画面定義欄0330及び完了画面定義欄0340が含まれている。これは、社員登録では、社員エンティティの属性の入力を入力、確認及び完了の三つの画面を介して行うべきことを示している。これらの欄には画面名欄0304があり、それぞれ入力、確認、完了と入力されている。また、コメント欄0305にはそれぞれの画面上に表示されるメッセージが入力されている。たとえば、入力画面のコメント欄には社員情報を入力してくださいとのコメントが入力されている。入力画面定義欄及び確認画面定義欄には属性名欄0306及び改行欄0307がある。属性名欄には、ユースケースにおいて操作対象となるエンティティの属性情報を示す操作対象属性一覧情報が入力されており、また、改行欄には、それら属性情報を操作するための入力欄に係るインタフェイスの構成を示す入力欄設計情報が入力されている。操作対象属性一覧情報とは、操作の対象となるエンティティの属性のうち、所定のユースケースにおいて入力、変更、削除などの操作の対象となる全ての属性の一覧となる情報である。設例では、社員の属性のうち、ユーザID、パスワード、名前及び性別がこれに含まれる。入力欄設計情報とは、操作の対象となる属性の入力欄を画面上でどのように配置して表示するか等、画面構成について定義するための情報である。設例では、画面上での改行を行うか否かのみを指定する構成となっている。ユーザIDとパスワードは同一の行に配置されるが、名前と性別はそれぞれ行を改めて配置される。入力欄設計情報は、画面の端からのオフセットを定義する方法や、行番号を指定する方法等他の方法により入力欄の配置を決定するものであっても構わない。設計情報取得部は、エンティティ定義書からは属性情報を、ユースケース定義書からは操作対象属性一覧情報及び入力欄設計情報を取得する。取得の方法は、様々である。例えば、二つの定義書をエクセルマイクロソフト社の商標のような表形式のファイルとし、これをCSV形式やXML形式で出力したものを読み取る方法や、二つの定義書をテキストファイル形式としてこれを直接読み取る方法等が考えられる。インタフェイス用コード出力部は、操作対象属性一覧情報及び入力欄設計情報に基づいてエンティティの属性情報の操作のためのインタフェイスに係るコードを出力する。すなわち、操作対象属性一覧情報に含まれる一つ一つの属性について、その属性を操作するための入力欄の配置を入力欄設計情報に従って判断し、インタフェイスを生成するコードを出力する。図4は、実施例1のプログラム自動生成システムにより生成されたプログラムにより出力される画面の一例を表す図である。この出力画面は図2及び図3を用いて説明した二つの定義書に対応する例となっている。すなわち、画面はユースケース定義書に従って、登録画面0420、確認画面0430及び完了画面0440の3画面構成となっており、画面左上の表題0401には操作対象定義欄のユースケース名欄で指定された通り社員登録と表示されており、さらに入力画面定義欄等の画面名欄に従い登録、確認及び完了の文字がこれに続いている。また、表題の下には入力画面定義欄等のコメント欄に従ってコメント0402がそれぞれ表示されている。さらに登録画面の下部には、操作対象属性一覧情報及び入力欄設計情報に従って、属性入力欄0403が配置されている。すなわち、ユーザID及びパスワードは属性入力欄の1行目に、名前は2行目に、性別は3行目に配置されている。確認画面においては属性の入力を確認するための従って変更はできない属性確認欄0404が配置されている。なお、確認画面で入力の誤りが見つかったときに登録画面に戻って入力を訂正できるように前の画面に戻るボタンを設ける構成としてもよい。図5は、エンティティの属性情報の操作のためのインタフェイスに係るコードの一例である。このコードは図4の社員登録登録画面0420を表示するためのコードであって、ウェブ上でのドキュメントを記述するための代表的なマークアップ言語であるHTML言語で書かれている。但し、簡単化のため表題0401及びコメント0402を表示するための記述や入力用の窓のための記述は省略した。図5から図5は、インタフェイス用コード出力部のうち図5のコードを出力するための出力元コードのコーディング例である。図5の左端の数字は説明のための行番号である。図5の出力元コードは図5のコードを出力するためのテンプレートであって、♯で始まる行では適切な関数が呼び出されてテンプレートが呼び出され、これにより図5のコードを生成する仕組みとなっている。図5の♯で始まる部分、図5から図5で使用されているプログラミング言語は説明のための仮想的なプログラミング言語で記述されている。これらの出力元コードの動作を以下に説明する。図5のテンプレートの5行目のforeachから16行目のendforまでは図3のユースケース定義書の入力画面定義欄0320における属性名欄0306で列挙された属性の一つ一つについて関連するコードの生成を行う。6行目の変数属性型にはそれら属性の属性型が読み込まれ、これが文字列である場合には7行目のcase文字列の分岐に入り、列挙型である場合には10行目のcase列挙型分岐に入る。case文字列の分岐に入った場合には9行目のcallstringTemplateによって図5のstringTemplate関数が呼び出される。stringTemplate関数はテキスト文を出力してテンプレートを書き換える。このとき変数属性名の部分は属性の属性名で置換される。case列挙型の分岐に入った場合には12行目のcallcodeTemplateによって図5のcodeTemplate関数が呼び出されて適切なコードを出力してテンプレートを書き換える。また15行目では属性のそれぞれについてlayoutTemplate関数が呼び出される。この関数は変数改行を引数とする。変数改行には、図3のエンティティ定義書から設計情報取得部が読み取った入力欄設計情報である改行0307のデータがそれぞれの属性について格納される。layoutTemplate関数は、このデータが有の場合にはインタフェイス上で改行を行うためのタグであるを出力する。データベース操作用コード出力部は、前記属性情報から属性のデータベース上における操作に係るコードを出力する。データベースとは、データを集めて管理し、データの検索、抽出等の再利用が容易にできるようにしたものをいい、様々なものが商用化されているが、本発明ではそれらのいずれを用いることもできる。また、操作に係るコードとは、例えば、データベースがSQLの規格に基づくものであればSQL言語で書かれた関数のコードであり、データの登録、変更、削除、検索、ソート等を実行する関数である。例えば、図4の登録画面で入力された情報を入力欄から読み取りこれをデータベースに記憶するための関数がこれに当たる。図6は、データベース操作用コード出力部により出力されたデータベース操作用コードの一例である。このコードは図4の社員登録画面により登録を行う場合の社員の名前の登録に係る部分を表している。このようなコードを出力するためのデータベース操作用コード出力部の出力元コードのコーディング例は省略する。これはインタフェイス用コード出力部のコーディング例で説明したものと同様のコーディングにより実現することができる。図6のコードはユーザIDを使用してログインした社員が自分の名前を変更するためのコードである。8行目の変数ユーザIDにはログイン時に使用されたユーザIDが格納されており、これと同一のユーザIDをもつ社員のデータのみが変更の対象となるという条件を規定している。6行目の変数名前にはユースケース定義書に従って生成されたインタフェイス上で入力された名前が格納される。最後に10行目のコードによりデータベース上のデータが変更される。図7は、実施例1のプログラム自動生成システムのハードウェア構成図である。実施例1のプログラム自動生成システムは、各種演算処理及び検索処理を行うCPU0701と、出力元プログラムやデータを保持するためのハードディスクドライブ装置、ROMなどの外部記憶装置0702と、出力元プログラムやデータを一時的に記憶して保持するメモリ0703と、を備えている。そしてそれらがデータ通信経路であるシステムバス0710によって相互に接続され、情報の送受信や処理を行う。外部記憶装置に保持された出力元プログラムは必要に応じてメモリに読みだされ、CPUは当該出力元プログラムをメモリに参照することで各種演算処理を実行する。また、このメモリにはそれぞれ複数のアドレスが割り当てられており、CPUの演算処理においては、そのアドレスを特定し格納されているデータにアクセスすることで、データを用いた演算処理を行うことが可能になっている。このようなハードウェア構成は他の実施例についても同様である。図8は、実施例1のプログラム自動生成システムの処理の流れを表す図である。まず、設計情報取得部が、エンティティ定義書からは属性情報を、ユースケース定義書からは操作対象属性一覧情報及び入力欄設計情報を取得するステップ0801。そして、インタフェイス用コード出力部が、操作対象属性一覧情報及び入力欄設計情報に基づいてエンティティの属性情報の操作のためのインタフェイスに係るコードを出力するステップ0802。そして、データベース操作用コード出力部が、属性情報から属性のデータベース上における操作に係るコードを出力するステップ0803。ステップ0802とステップ0803の順序は問わない。実施例1のプログラム自動生成システムにより、簡単な定義書からプログラムを自動的に生成することができる。情報処理において情報セキュリティを高めるためには特定の情報について追加変更削除などの処理の権限を特定の者に限定する何らかの方法が必要となる。従来技術では情報ごとにその情報の所有者を定め、所有者が他の者にその情報に対するアクセス権限を与えるという構成や、情報ごとにその情報へアクセスする権限を有するユーザの地位を定義する構成等が採用されている。しかし、このような情報ごとのアクセス権限定義は非常に面倒でありプログラムの設計の工数やプログラムの運用の負担を増大させるものであった。実施例2のプログラム自動生成システムは、自動生成されるべきプログラムの利用者を定義し、かつ、その利用者と少なくとも一のエンティティとの紐づけについて定義する。そうすることにより、利用者に対し直接または間接に関連付けられたエンティティに関する情報についてのみ、当該利用者にアクセス権限を与えるようなプログラムを生成する。実施例2のプログラム自動生成システムは、このような極めて簡単な設計手法により、アクセス権限管理の定義を個別に行うことなく、その管理を実現可能なプログラムを自動生成するものである。図9は、実施例2のプログラム自動生成システムの機能構成を表す図である。実施例2のプログラム自動生成システム0910は、プログラムの設計書である定義書0901から自動的にプログラム0920を生成する。定義書は少なくともエンティティ定義書0902とユースケース定義書0903とを含み、プログラム自動生成システムの設計情報取得部0911は、これら二つの定義書から必要な設計情報を読みとる。そしてインタフェイス用コード出力部0912は設計情報取得部から必要な設計情報を取得したうえでインタフェイス用コード0921を出力する。同様にデータベース用コード出力部0913は、データベース用コード0922を出力する。ここまでの構成は実施例1と同様である。実施例2のプログラム自動生成システムは、さらに権限管理用コード出力部0914が権限管理用コード0923を出力する。権限管理用コード出力部は、紐づけの定義により直接または間接に利用者に紐付けられたエンティティの属性情報についてのみ当該利用者に対して操作権限を与える権限管理用コードを出力する。権限管理用コードがどのように機能するかについては、以下の設例を用いて説明する。図10は、実施例2のプログラム自動生成システムにおけるエンティティ定義書の一例を表す図である。図2を用いて説明した実施例1のエンティティ定義書と多くの点で共通するが、属性情報を定義するための属性名の欄1002には他のエンティティとの関連を示す属性である関連属性が含まれる点が異なる。例えば、社員エンティティ1001の属性情報には所属部署1011の属性が含まれるが、その属性型は関連属性親とされており、さらに関連先エンティティ名欄1012に部署が指定されていることから、社員エンティティと部署エンティティは関連付けられていることが分かる。また、この関係は部署エンティティ1003の定義においても裏付けられている。すなわち、部署エンティティの属性情報には帰属社員1013が含まれるが、その属性型は関連属性子とされ、また、関連先エンティティ名欄1014は社員となっており、前記社員エンティティにおける所属部署の箇所に対応する形となっている。同様の関連付けは部署エンティティの担当案件1015及び案件エンティティ1004の所属部署1017においても行われている。すなわち、部署エンティティと案件エンティティとは関連付けられており、部署エンティティが親、案件エンティティが子の関係となっている。前記利用者と少なくとも一のエンティティとの紐づけの定義とは、以上の例で示されるような利用者とエンティティとの間の関連付けの定義のことをいう。社員エンティティと部署エンティティとは関連属性が定義されることにより、直接の親子関係の関連付けがされている。また、部署エンティティと案件エンティティも同様に直接の親子関係の関連付けがされている。そして、社員エンティティと案件エンティティとは直接の親子関係はないが、部署エンティティを介して間接的に関連付けがされているということができる。実施例2のプログラム自動生成システムのエンティティ定義書には、前記紐づけ=関連属性の定義の他に、自動生成されるべきプログラムの利用者の情報が含まれる。図10の設例では、社員が自動生成されるべきプログラムの利用者に相当する。このように、社員エンティティの定義に従って登録された社員が前記紐づけの定義により関連付けられたエンティティの属性情報についてアクセスの権限を得る。例えば設例で、部署として本部、開発部及び営業部があり、案件としては、本部の担当する新人研修、開発部の担当する新商品開発及び営業部の担当する顧客開拓がある場合において、開発部に所属するAさんは前記関連属性の定義に従って、自らの所属する開発部の担当する新商品開発の属性情報に対するアクセス権が与えられる。すなわち、Aさんが自らのユーザID及びパスワードを用いてプログラムにログインした場合、権限管理コードは、Aさんの属性定義における所属部署が開発部であることを認識し、所属部署の関連先エンティティとして部署が指定されていることから、開発部エンティティに対してのみアクセス権を付与すべきと判断する。そして権限管理コードはさらに、開発部エンティティの属性定義における担当案件として新商品開発があり、その関連先エンティティとして案件が指定されていることから、新商品開発エンティティについても、Aさんにアクセス権を付与すべきと判断する。以上の設例では、自動生成されるべきプログラムの利用者がエンティティ定義書において社員エンティティとして定義されていた。しかし、プログラムの利用者は必ずしもエンティティとして定義されていなければならないものではない。プログラムの利用者についての詳細情報は外部システムで定義されているような場合もあり、そのような場合のエンティティ定義書は図10のエンティティ定義書から社員エンティティ1001の項目を除いたもののようになる。但し、実施例2のアクセス権限管理を実現するためにはそのような場合においてもエンティティ定義書にはプログラムの利用者と少なくとも一のエンティティとの紐づけの定義は含まれていなければならない。プログラムの利用者がエンティティとして定義されていない場合の具体的構成としては、例えば図10において、帰属社員1013の関連先エンティティ名欄1014に社員とあるところを、外部システムABCで定義されたユーザID等とする。これにより、外部システムABCで定義されたユーザIDを持つユーザは、当該関連属性の定義により紐づけされた情報についてのみ操作のアクセス権限を得ることができる。なお、この場合における自動生成されるべきプログラムの利用者の情報とは、関連先エンティティ名欄に記載された外部システムABCで定義されたユーザIDの情報を意味することとなる。図11は、権限管理コード出力部により出力されるコードの一例である。これは、利用者である社員の所属部署の案件についてのみアクセス権限を付与する部分のコードである。このようなコードを出力するための権限管理用コード出力部の出力元コードのコーディング例は省略する。これはインタフェイス用コード出力部のコーディング例で説明したものと同様のコーディングにより実現することができる。図11のコードは案件を所有する部署に所属する社員にのみアクセス権限を与えるためのコードであるが、7行目のユーザIDIN所属部署帰属社員の部分がアクセス権限に合致するデータ抽出のための条件式である。この条件式のうち所属部署は図10の案件エンティティのエンティティ定義書1004中の関連属性である所属部署1017に由来し、前記条件式の帰属社員の部分は部署エンティティのエンティティ定義書1003中の関連属性である帰属社員1013に由来する。この条件式により、案件に関連した部署の社員のみが当該案件を抽出してアクセスすることが可能となり、当該案件データに対する変更の権限を得ることとなる。図11のコードはデータを操作しようとする者がデータにアクセスする際に操作権限のあるデータのみを抽出可能としてその変更を認めるというものである。つまりこの例ではデータの操作に対する権限があるかどうかの判断を行うのはデータの抽出時である。これに対して、データの抽出時においてではなくデータの書き換え時にアクセス権限の有無を判定する方法もある。後者によれば、データの抽出後にアクセス権限を失った者によるデータの書き換えを防止できるという利点がある。また、データ抽出時と書換時の両時点でアクセス権限の判定を行えばデータの健全性を一層高めることができる。実施例2のプログラム自動生成システムによれば、データに対するアクセス権限の定義を個別に行うことなく、適切なアクセス権限管理をすることのできるプログラムを自動生成することが可能となる。実施例2のプログラム自動生成システムはエンティティ定義書でエンティティの関連属性を定義することにより簡単にデータに対するアクセス権限を管理できた。しかし、より細かなアクセス権限管理が必要となる場合がある。例えば、案件の規模が一定額以上の場合に限ってその変更を行いたいという場合に、実施例3のプログラム自動生成システムによれば、そのような案件についてのみアクセスを許可することができる。実施例3のプログラム自動生成システムは、操作許可用コード出力部をさらに有する。また、ユースケース定義書には操作許可情報が含まれ、出力されるプログラムには操作許可用コードが含まれる。操作許可用コード出力部は、操作許可情報に従ってエンティティに対する操作を許可する操作許可用コードを出力する。機能構成図は省略する。図12は、実施例3のプログラム自動生成システムにおけるユースケース定義書の一例を表す図である。操作対象定義欄1210には、ユースケース名欄1201、操作型欄1202及びエンティティ名欄1209がある。ユースケース名欄の案件情報変更は、このユースケース定義書で定義する操作が案件情報の変更に係るものであることを示しており、画面の表題に用いられる。操作型欄の変更は、操作の種類が変更であることを示している。さらに、エンティティ名欄の案件は、当該ユースケースで操作の対象となるエンティティは案件であることを示している。ユースケース定義書には、エンティティに対する操作を許可するための条件である操作許可情報を定義するための操作許可情報欄1220が含まれる。操作許可情報は二種類ある。ひとつはエンティティフィルタであり、もうひとつは外部参照エンティティフィルタである。これらは一般的にいうとエンティティの有する属性情報に基づいて一定の条件に合致するデータを抽出するものであるが、本実施例においては、エンティティフィルタは当該ユースケースで操作の対象となるエンティティの属性情報に係る条件に基づいてふるいを掛けるものであり、一方外部参照エンティティフィルタは、当該ユースケースで操作の対象となるエンティティ以外のエンティティの属性情報に係る条件に基づいてふるいを掛けるものである。図12のユースケース定義書中の操作許可情報欄には、エンティティフィルタに係るエンティティフィルタ用条件定義欄1204と、外部参照エンティティフィルタに係る外部参照エンティティフィルタ用条件定義欄1205とが含まれる。エンティティフィルタ用条件定義欄1204では、案件エンティティの案件状態属性が起案中であり、かつ、同エンティティの案件が1000万円以下の案件についてのみアクセスを許可するという内容が定義されている。当該フィルタは操作対象である案件そのものの属性に基づいてふるいをかけるものであることからエンティティフィルタに分類することができる。図13は図12のエンティティフィルタ用条件定義欄に記載の条件を反映したコードの出力例である。案件の中から、6行目に記載の条件により案件状態が起案中のものが抽出され、さらに7行目に記載の条件により案件規模が1千万円以下のものが抽出される。外部参照エンティティフィルタ用条件定義欄1205では、案件エンティティに紐付けられた部署エンティティの部門コードが0本部でないものについてのみアクセスを許可するという内容が定義されている。これによれば、例えば本部が担当する新人研修についてはこのユースケースによるアクセスが許されないこととなる。当該フィルタは操作対象である案件エンティティではなく外部の部署エンティティの属性に基づいてふるいをかけるものであることから外部参照エンティティフィルタに分類される。図13は図12の外部参照エンティティフィルタ用条件定義欄に記載の条件を反映したコードの出力例である。案件の中から、6行目に記載の条件により案件に関連付けられた部署の部門コードが本部でないものが抽出される。実施例3のプログラム自動生成システムによれば、細かな条件を定めてデータに対するアクセス権限を管理することのできるプログラムを自動生成することができる。プログラムを自動生成するシステムは、プログラマーによるプログラミングを要することなく、プログラムの設計書から直接にプログラムを生成することを可能とするものである。しかし、プログラミング不要としてもプログラムの設計書の作成自体に特殊な能力や多大な労力時間を要したのでは全く意味がない。そこで、プログラムの設計をできるだけ簡単なものとしつつ、同時にプログラム開発者の要求にきめ細かに応えることができるものとすることが、プログラム自動生成システムにおいては重要となる。実施例4のプログラム自動生成システムは、システム設計を簡明化する手法のひとつを実現するものである。プログラムの操作においては、ある操作Aを行った後に他の操作B操作BはAと関係なく単独で行われることもあるが続けて行われるのが通例であることがある。例えば、顧客から商品の注文を受けたときに行う注文入力というユースケースと、新規顧客を登録するための顧客登録というユースケースとが定義されている場合において、顧客登録は新規顧客から商品の注文を受けたときに行うのが通例である場合には、顧客登録と注文入力が連続して行われる。このような場合には顧客登録が完了したときに、注文入力へと自動的に移行するのが便宜である。実施例4のプログラム自動生成システムは、このようなユースケースの移行を自動的に行うことのできるプログラムを自動的に生成することを特徴とする。実施例4のプログラム自動生成システムの機能構成は前記実施例1乃至3のそれと同様である。但し、ユースケース定義書は、操作完了後に移行する移行先のユースケースに係る移行先情報を含み、インタフェイス用コード出力部は、一のユースケース定義書で定義されたユースケースの完了後に移行先情報に従って他のユースケース定義書で定義されたユースケースを開始するコードを出力するためのユースケース移行用コード出力手段を有する。移行先情報とは、具体的には移行先のユースケース名及び画面名のことであり、ユースケース定義書に移行先情報欄を設けて特定される。そして、これを設計情報取得部が読み取り、移行用コード出力手段が読み取った移行先情報に従って当該ユースケース完了後に移行先の画面を起動する。実施例4のプログラム自動生成システムは、ユースケース間の自動の移行を実現することにより設計書の作成を単純化し、プログラムの開発工数を削減することのできるプログラム自動生成システムである。