JP2012164177A - プログラム自動生成システム - Google Patents

Abstract

【課題】適切なアクセス権限管理をすることのできるプログラムを極めて簡単な設計書から自動生成することにより、プログラム開発の工数を大幅に削減する。
【解決手段】プログラム自動生成システム０１１０は、プログラムの設計書である定義書０１０１から自動的にプログラム０１２０を生成する。定義書は少なくともエンティティ定義書０１０２とユースケース定義書０１０３とを含む。プログラム自動生成システムは、設計情報取得部０１１１と、インタフェイス用コード出力部０１１２と、データベース用コード出力部０１１３とを有する。設計情報取得部は、二つの定義書から必要な設計情報を読みとる。そしてインタフェイス用コード出力部は設計情報取得部から必要な設計情報を取得したうえでインタフェイス用コード０１２１を出力する。同様にデータベース用コード出力部は、データベース用コード０１２２を出力する。
【選択図】図１

Description

この発明は、プログラミング言語によるソースコードの記述を要することなく、簡単な設計書から直接コンピュータ・プログラム（以下単に「プログラム」という）を自動的に生成する技術に関する。

簡単な設計書からプログラムを自動生成する方法については数多くの技術が提案されている。その目的は、プログラム開発期間を短縮して開発コストを低減すること、プログラマーの関与を排除してバグをなくすこと、プログラムの修正が必要となった場合にプログラムを修正する代わりに設計書を変更してプログラムを再生成する手法によりプログラムのメンテナンスコストを低減すること等にある。

特許文献１もプログラム自動生成の技術を提案するもののひとつである。特許文献１は、ひな型となる設計書を記録し、ひな形をもとに編集された設計書からソースコードを自動生成する技術を開示している。

特開２００３−５９６６

プログラム自動生成システムは、設計書の作成を要するのみであって、ソースコードの記述を要しないという点においてはプログラム開発工数をおおいに削減するものである。しかし実際にはプログラムの仕様において選択可能な項目は多岐にわたり、その細部にまで特定することを要したのでは、設計書の作成自体に多大の労力が要求される結果となってしまう。

この点、特許文献１のプログラム自動生成装置では、予めひな型を用意し、同時にそのひな型ごとのソースコードを用意することで、自動生成という要求と、設計書作成の負担軽減という要求に応えようとしているものと思われる。しかし、特許文献１ではひな型をもとに編集された設計書からどのようにしてソースコードが自動生成されるのか、また、どのような技術により簡単な設計書から複雑なプログラムを自動生成するのかについては具体的な技術が開示されていない。

第１発明は、二つの定義書、すなわちエンティティを定義するエンティティ定義書とユースケースを定義するユースケース定義書とからプログラムを自動的に生成するプログラム自動生成システムに関する。ここで「エンティティ」とは「実体」ともいい、一単位として扱われるデータのまとまりをいう。また、「ユースケース」とは何らかの機能に関するプログラムとユーザとのやり取りをいう。

第２発明は、プログラムの作成者がユーザについてデータへのアクセス権限について逐一決めなくても、エンティティ定義書にてエンティティ間の関連を定義するだけでユーザのデータに対するアクセス権限が自動的に決定されるプログラム自動生成システムに関する。

第３発明は、ユースケース定義書でエンティティに対する操作を許可するための条件を定義し、その定義に従ってエンティティに対する操作を許可するプログラムを生成するプログラム自動生成システム、に関する。

第４発明は、一のインタフェイスから他のインタフェイスに自動的に移行することにより業務を効率化することのできるプログラムを生成するプログラム自動生成システム、に関する。

本願の発明によれば、データに対するアクセス権限の定義を個別に行うことなく、適切なアクセス権限管理をすることのできるプログラムを極めて簡単な設計書から自動生成することが可能となる。これによりプログラム開発の工数を大幅に削減することが可能となる。

実施例１のプログラム自動生成システムの機能構成を表す図。 実施例１のプログラム自動生成システムにおけるエンティティ定義書の一例を表す図。 実施例１のプログラム自動生成システムにおけるユースケース定義書の一例を表す図。 実施例１のプログラム自動生成システムにより生成されたプログラムにより出力される画面の一例を表す図。 エンティティの属性情報の操作のためのインタフェイスに係るコードの一例(抜粋)。 インタフェイス用コード出力部のうち図５(Ａ)のコードを出力するための出力元コードのコーディング例。 インタフェイス用コード出力部のうち図５(Ａ)のコードを出力するための出力元コードのコーディング例。 インタフェイス用コード出力部のうち図５(Ａ)のコードを出力するための出力元コードのコーディング例。 インタフェイス用コード出力部のうち図５(Ａ)のコードを出力するための出力元コードのコーディング例。 データベース操作用コード出力部により出力されたデータベース操作用コードの一例(抜粋)。 実施例１のプログラム自動生成システムのハードウェア構成図。 実施例１のプログラム自動生成システムの処理の流れを表す図。 実施例２のプログラム自動生成システムの機能構成を表す図。 実施例２のプログラム自動生成システムにおけるエンティティ定義書の一例を表す図。 権限管理コード出力部により出力されるコードの一例(抜粋)。 実施例３のプログラム自動生成システムにおけるユースケース定義書の一例を表す図。 図１２のエンティティフィルタ用条件定義欄に記載の条件を反映したコードの出力例。 図１２の外部参照エンティティフィルタ用条件定義欄に記載の条件を反映したコードの出力例。

実施例１は請求項１に記載の第１発明に関する。実施例２は請求項２に記載の第２発明に関する。実施例３は請求項３に記載の第３発明に関する。実施例４は請求項４に記載の第４発明に関する。

以下の説明では、本願発明のプログラム自動生成システムにより出力されるプログラムを単に「プログラム」、そのコードを「コード」と呼び、本願発明のプログラム自動生成システム自体のプログラムを「出力元プログラム」、そのコードを「出力元コード」と呼んで両者を明確に区別することにする。

<実施例１の概念>

実施例１のプログラム自動生成システムは、情報のひとまとまりの単位であるエンティティの定義と、プログラムの利用者とプログラムとの間のやり取りについてのユースケースの定義とからプログラムを自動的に生成するシステムである。<実施例１の構成>

図１は、実施例１のプログラム自動生成システムの機能構成を表す図である。実施例１のプログラム自動生成システム０１１０は、プログラムの設計書である定義書０１０１から自動的にプログラム０１２０を生成する。定義書は少なくともエンティティ定義書０１０２とユースケース定義書０１０３とを含む。プログラム自動生成システムは、設計情報取得部０１１１と、インタフェイス用コード出力部０１１２と、データベース用コード出力部０１１３とを有する。設計情報取得部は、二つの定義書から必要な設計情報を読みとる。そしてインタフェイス用コード出力部は設計情報取得部から必要な設計情報を取得したうえでインタフェイス用コード０１２１を出力する。同様にデータベース用コード出力部は、データベース用コード０１２２を出力する。

以下設例を用いて各部の構成を説明する。ある会社で、社内情報を管理し、社員間で情報を共有するためのプログラムを開発しようとしているものとする。ここで情報管理の対象となるエンティティは、「社員」、「部署」及び「案件」である。社員は必ずいずれか一の部署に所属する。また、案件は必ず一の部署が担当する。

「エンティティ定義書」は、エンティティの属性情報を定義する。「エンティティ」とは一単位として扱われるデータのまとまりをいう。設例では、社員、部署及び案件であり、これらのエンティティは「属性」を有する。属性とは、エンティティが有する性質や特徴を表す情報のことをいう。例えば、社員の属性は、名前、性別等である。

図２は、実施例１のプログラム自動生成システムにおけるエンティティ定義書の一例を表す図である。社員、部署及び案件の三つのエンティティそれぞれについて定義がされている。それぞれのエンティティの定義書にはまずエンティティを特定するための「エンティティ名の欄」０２０１がある。そして次に属性情報を定義するための「属性名の欄」０２０２があり、例えば「社員」エンティティでは、「属性名」の見出しの下に、ユーザID、パスワード、名前及び性別が列挙されている。属性名の欄の右側にはそれぞれの属性の型を定義する「属性型の欄」０２０３がある。例えば、「ユーザID」属性については「文字列」に、「性別」の属性については「0:男」又は「1:女」のいずれかに限定を行っている。

図３は、実施例１のプログラム自動生成システムにおけるユースケース定義書の一例を表す図である。

「ユースケース」とは何らかの機能に関するプログラムとユーザとのやり取りをいい、ユースケース定義書とはそのようなプログラムとのやり取り、つまり、典型的にはプログラム操作のためのユーザインタフェイスを定義するものなどをいう。例えば、社員をシステムに登録するためには、社員情報の入力を受け付け、入力された情報の妥当性を検証し、その後データベースへ保存する、という一連の処理を一体として行う必要があるが、ユースケースとは、このようなシステムとユーザとのやり取りと、そのやり取りに基づいて実行される処理等を定義するものである。

本発明の「ユースケース定義書」は、所定のユースケースにおいて操作対象となるエンティティの属性情報を示す操作対象属性一覧情報と、それら属性情報を操作するための入力欄に係るインタフェイスの構成を示す入力欄設計情報と、を含む定義書である。

図３のユースケース定義書は、社員登録を行うためのユーザインタフェイスを定義するものの例である。操作対象定義欄０３１０には、「ユースケース名」欄０３０１、「操作型」欄０３０２及び「エンティティ名」欄０３０３がある。ユースケース名欄の「社員登録」は、このユースケース定義書で定義する操作が社員エンティティの登録に係るものであることを示しており、画面の表題に用いられる。操作型欄の「登録」は、操作の種類が登録であることを示している。他の操作型としては、「変更」及び「削除」等がありうる。さらに、エンティティ名欄の「社員」は、当該ユースケースで操作の対象となるエンティティは社員であることを示している。

図３のユースケース定義書には、入力画面定義欄０３２０、確認画面定義欄０３３０及び完了画面定義欄０３４０が含まれている。これは、社員登録では、社員エンティティの属性の入力を「入力」、「確認」及び「完了」の三つの画面を介して行うべきことを示している。これらの欄には「画面名」欄０３０４があり、それぞれ「入力」、「確認」、「完了」と入力されている。また、「コメント」欄０３０５にはそれぞれの画面上に表示されるメッセージが入力されている
。たとえば、入力画面のコメント欄には「社員情報を入力してください」とのコメントが入力されている。

入力画面定義欄及び確認画面定義欄には「属性名」欄０３０６及び「改行」欄０３０７がある。属性名欄には、ユースケースにおいて操作対象となるエンティティの属性情報を示す操作対象属性一覧情報が入力されており、また、改行欄には、それら属性情報を操作するための入力欄に係るインタフェイスの構成を示す入力欄設計情報が入力されている。

「操作対象属性一覧情報」とは、操作の対象となるエンティティの属性のうち、所定のユースケースにおいて入力、変更、削除などの操作の対象となる全ての属性の一覧となる情報である。設例では、社員の属性のうち、ユーザID、パスワード、名前及び性別がこれに含まれる。

「入力欄設計情報」とは、操作の対象となる属性の入力欄を画面上でどのように配置して表示するか等、画面構成について定義するための情報である。設例では、画面上での改行を行うか否かのみを指定する構成となっている。ユーザIDとパスワードは同一の行に配置されるが、名前と性別はそれぞれ行を改めて配置される。入力欄設計情報は、画面の端からのオフセットを定義する方法や、行番号を指定する方法等他の方法により入力欄の配置を決定するものであっても構わない。

「設計情報取得部」は、エンティティ定義書からは属性情報を、ユースケース定義書からは操作対象属性一覧情報及び入力欄設計情報を取得する。取得の方法は、様々である。例えば、二つの定義書をエクセル（マイクロソフト社の商標）のような表形式のファイルとし、これをCSV形式やXML形式で出力したものを読み取る方法や、二つの定義書をテキストファイル形式としてこれを直接読み取る方法等が考えられる。

「インタフェイス用コード出力部」は、操作対象属性一覧情報及び入力欄設計情報に基づいてエンティティの属性情報の操作のためのインタフェイスに係るコードを出力する。すなわち、操作対象属性一覧情報に含まれる一つ一つの属性について、その属性を操作するための入力欄の配置を入力欄設計情報に従って判断し、インタフェイスを生成するコードを出力する。

図４は、実施例１のプログラム自動生成システムにより生成されたプログラムにより出力される画面の一例を表す図である。この出力画面は図２及び図３を用いて説明した二つの定義書に対応する例となっている。すなわち、画面はユースケース定義書に従って、登録画面０４２０、確認画面０４３０及び完了画面０４４０の３画面構成となっており、画面左上の表題０４０１には操作対象定義欄のユースケース名欄で指定された通り「社員登録」と表示されており、さらに入力画面定義欄等の画面名欄に従い「登録」、「確認」及び「完了」の文字がこれに続いている。また、表題の下には入力画面定義欄等のコメント欄に従ってコメント０４０２がそれぞれ表示されている。さらに登録画面の下部には、操作対象属性一覧情報及び入力欄設計情報に従って、属性入力欄０４０３が配置されている。すなわち、ユーザID及びパスワードは属性入力欄の１行目に、名前は２行目に、性別は３行目に配置されている。確認画面においては属性の入力を確認するための（従って変更はできない）属性確認欄０４０４が配置されている。なお、確認画面で入力の誤りが見つかったときに登録画面に戻って入力を訂正できるように〈前の画面に戻る〉ボタンを設ける構成としてもよい。

図５(Ａ)は、エンティティの属性情報の操作のためのインタフェイスに係るコードの一例(抜粋)である。このコードは図４の「社員登録:登録」画面０４２０を表示するためのコードであって、ウェブ上でのドキュメントを記述するための代表的なマークアップ言語であるHTML言語で書かれている。但し、簡単化のため表題０４０１及びコメント０４０２を表示するための記述や入力用の窓のための記述は省略した。

図５(Ｂ)から図５(Ｅ)は、インタフェイス用コード出力部のうち図５(Ａ)のコードを出力するための出力元コードのコーディング例である。図５(Ｂ)の左端の数字は説明のための行番号である。図５(Ｂ)の出力元コードは図５(Ａ)のコードを出力するためのテンプレートであって、♯で始まる行では適切な関数が呼び出されてテンプレートが呼び出され、これにより図５(Ａ)のコードを生成する仕組みとなっている。図５(Ｂ)の♯で始まる部分、図５(Ｃ)から図５(Ｅ)で使用されているプログラミング言語は説明のための仮想的なプログラミング言語で記述されている。

これらの出力元コードの動作を以下に説明する。図５(Ｂ)のテンプレートの５行目の#for eachから１６行目の#end forまでは図３のユースケース定義書の入力画面定義欄０３２０における属性名欄０３０６で列挙された属性の一つ一つについて関連するコードの生成を行う。６行目の変数「$属性型」にはそれら属性の属性型が読み込まれ、これが「文字列」である場合には７行目の「#case文字列」の分岐に入り、「列挙型」である場合には１０行目の「#case列挙型」分岐に入る。「#case文字列」の分岐に入った場合には９行目の「#call stringTemplate($属性名);」によって図５(Ｃ)のstringTemplate関数が呼び出される。stringTemplate関数はテキスト文「<INPUT type="text" name="$属性名">」を出力してテンプレートを書き換える。このとき変数「$属性名」の部分は属性の属性名で置換される。「#case列挙型」の分岐に入った場合には12行目の「#call codeTemplate($属性名);」によって図５(Ｄ)のcodeTemplate関数が呼び出されて適切なコードを出力してテンプレートを書き換える。

また１５行目では属性のそれぞれについてlayoutTemplate関数が呼び出される。この関数は変数「$改行」を引数とする。変数「$改行」には、図３のエンティティ定義書から設計情報取得部が読み取った入力欄設計情報である改行０３０７のデータがそれぞれの属性について格納される。layoutTemplate関数は、このデータが「有」の場合にはインタフェイス上で改行を行うためのタグである「<BR／>」を出力する。

「データベース操作用コード出力部」は、前記属性情報から属性のデータベース上における操作に係るコードを出力する。「データベース」とは、データを集めて管理し、データの検索、抽出等の再利用が容易にできるようにしたものをいい、様々なものが商用化されているが、本発明ではそれらのいずれを用いることもできる。また、操作に係るコードとは、例えば、データベースがSQLの規格に基づくものであればSQL言語で書かれた関数のコードであり、データの登録、変更、削除、検索、ソート等を実行する関数である。例えば、図４の登録画面で入力された情報を入力欄から読み取りこれをデータベースに記憶するための関数がこれに当たる。

図６は、データベース操作用コード出力部により出力されたデータベース操作用コードの一例(抜粋)である。このコードは図４の社員登録画面により登録を行う場合の社員の名前の登録に係る部分を表している。このようなコードを出力するためのデータベース操作用コード出力部の出力元コードのコーディング例は省略する。これはインタフェイス用コード出力部のコーディング例で説明したものと同様のコーディングにより実現することができる。

図６のコードはユーザIDを使用してログインした社員が自分の名前を変更するためのコードである。８行目の変数「$ユーザID」にはログイン時に使用されたユーザIDが格納されており、これと同一のユーザIDをもつ社員のデータのみが変更の対象となるという条件を規定している。６行目の変数「$名前」にはユースケース定義書に従って生成されたインタフェイス上で入力された名前が格納される。最後に１０行目のコードによりデータベース上のデータが変更される。<実施例１のハードウェア構成>

図７は、実施例１のプログラム自動生成システムのハードウェア構成図である。実施例１のプログラム自動生成システムは、各種演算処理及び検索処理を行う「ＣＰＵ」０７０１と、出力元プログラムやデータを保持するためのハードディスクドライブ装置、ＲＯＭなどの「外部記憶装置」０７０２と、出力元プログラムやデータを一時的に記憶して保持する「メモリ」０７０３と、を備えている。そしてそれらがデータ通信経路である「システムバス」０７１０によって相互に接続され、情報の送受信や処理を行う。

外部記憶装置に保持された出力元プログラムは必要に応じてメモリに読みだされ、ＣＰＵは当該出力元プログラムをメモリに参照することで各種演算処理を実行する。また、このメモリにはそれぞれ複数のアドレスが割り当てられており、ＣＰＵの演算処理においては、そのアドレスを特定し格納されているデータにアクセスすることで、データを用いた演算処理を行うことが可能になっている。

このようなハードウェア構成は他の実施例についても同様である。<実施例１の処理の流れ>

図８は、実施例１のプログラム自動生成システムの処理の流れを表す図である。まず、設計情報取得部が、エンティティ定義書からは属性情報を、ユースケース定義書からは操作対象属性一覧情報及び入力欄設計情報を取得する（ステップ０８０１）。そして、インタフェイス用コード出力部が、操作対象属性一覧情報及び入力欄設計情報に基づいてエンティティの属性情報の操作のためのインタフェイスに係るコードを出力する（ステップ０８０２）。そして、データベース操作用コード出力部が、属性情報から属性のデータベース上における操作に係るコードを出力する（ステップ０８０３）。ステップ０８０２とステップ０８０３の順序は問わない。<実施例１の効果>

実施例１のプログラム自動生成システムにより、簡単な定義書からプログラムを自動的に生成することができる。

<実施例２の概念>

情報処理において情報セキュリティを高めるためには特定の情報について追加・変更・削除などの処理の権限を特定の者に限定する何らかの方法が必要となる。従来技術では情報ごとにその情報の所有者を定め、所有者が他の者にその情報に対するアクセス権限を与えるという構成や、情報ごとにその情報へアクセスする権限を有するユーザの地位を定義する構成等が採用されている。しかし、このような情報ごとのアクセス権限定義は非常に面倒でありプログラムの設計の工数やプログラムの運用の負担を増大させるものであった。

実施例２のプログラム自動生成システムは、自動生成されるべきプログラムの利用者を定義し、かつ、その利用者と少なくとも一のエンティティとの紐づけについて定義する。そうすることにより、利用者に対し直接または間接に関連付けられたエンティティに関する情報についてのみ、当該利用者にアクセス権限を与えるようなプログラムを生成する。実施例２のプログラム自動生成システムは、このような極めて簡単な設計手法により、アクセス権限管理の定義を個別に行うことなく、その管理を実現可能なプログラムを自動生成するものである。<実施例２の構成>

図９は、実施例２のプログラム自動生成システムの機能構成を表す図である。実施例２のプログラム自動生成システム０９１０は、プログラムの設計書である定義書０９０１から自動的にプログラム０９２０を生成する。定義書は少なくともエンティティ定義書０９０２とユースケース定義書０９０３とを含み、プログラム自動生成システムの設計情報取得部０９１１は、これら二つの定義書から必要な設計情報を読みとる。そしてインタフェイス用コード出力部０９１２は設計情報取得部から必要な設計情報を取得したうえでインタフェイス用コード０９２１を出力する。同様にデータベース用コード出力部０９１３は、データベース用コード０９２２を出力する。ここまでの構成は実施例１と同様である。実施例２のプログラム自動生成システムは、さらに権限管理用コード出力部０９１４が権限管理用コード
０９２３を出力する。

「権限管理用コード出力部」は、紐づけの定義により直接または間接に利用者に紐付けられたエンティティの属性情報についてのみ当該利用者に対して操作権限を与える権限管理用コードを出力する。権限管理用コードがどのように機能するかについては、以下の設例を用いて説明する。

図１０は、実施例２のプログラム自動生成システムにおけるエンティティ定義書の一例を表す図である。図２を用いて説明した実施例１のエンティティ定義書と多くの点で共通するが、属性情報を定義するための「属性名の欄」１００２には他のエンティティとの関連を示す属性である「関連属性」が含まれる点が異なる。例えば、「社員」エンティティ１００１の属性情報には「所属部署」１０１１の属性が含まれるが、その属性型は「関連属性（親）」とされており、さらに「関連先エンティティ名」欄１０１２に「部署」が指定されていることから、「社員」エンティティと「部署」エンティティは関連付けられていることが分かる。また、この関係は「部署」エンティティ１００３の定義においても裏付けられている。すなわち、「部署」エンティティの属性情報には「帰属社員」１０１３が含まれるが、その属性型は「関連属性（子）」とされ、また、「関連先エンティティ名」欄１０１４は「社員」となっており、前記「社員」エンティティにおける「所属部署」の箇所に対応する形となっている。

同様の関連付けは「部署」エンティティの「担当案件」１０１５及び「案件」エンティティ１００４の「所属部署」１０１７においても行われている。すなわち、「部署」エンティティと「案件」エンティティとは関連付けられており、「部署」エンティティが親、「案件」エンティティが子の関係となっている。

「前記利用者と少なくとも一のエンティティとの紐づけの定義」とは、以上の例で示されるような利用者とエンティティとの間の関連付けの定義のことをいう。「社員」エンティティと「部署」エンティティとは関連属性が定義されることにより、直接の親子関係の関連付けがされている。また、「部署」エンティティと「案件」エンティティも同様に直接の親子関係の関連付けがされている。そして、「社員」エンティティと「案件」エンティティとは直接の親子関係はないが、「部署」エンティティを介して間接的に関連付けがされているということができる。

実施例２のプログラム自動生成システムのエンティティ定義書には、前記「紐づけ」（＝関連属性）の定義の他に、「自動生成されるべきプログラムの利用者の情報」が含まれる。図１０の設例では、社員が「自動生成されるべきプログラムの利用者」に相当する。

このように、「社員」エンティティの定義に従って登録された社員が前記紐づけの定義により関連付けられたエンティティの属性情報についてアクセスの権限を得る。例えば設例で、「部署」として「本部」、「開発部」及び「営業部」があり、「案件」としては、本部の担当する「新人研修」、開発部の担当する「新商品開発」及び営業部の担当する「顧客開拓」がある場合において、開発部に所属するＡさんは前記関連属性の定義に従って、自らの所属する開発部の担当する新商品開発の属性情報に対するアクセス権が与えられる。すなわち、Ａさんが自らのユーザID及びパスワードを用いてプログラムにログインした場合、権限管理コードは、Ａさんの属性定義における「所属部署」が「開発部」であることを認識し、所属部署の「関連先エンティティ」として「部署」が指定されていることから、「開発部」エンティティに対してのみアクセス権を付与すべきと判断する。そして権限管理コードはさらに、「開発部」エンティティの属性定義における「担当案件」として「新商品開発」があり、その「関連先エンティティ」として「案件」が指定されていることから、「新商品開発」エンティティについても、Ａさんにアクセス権を付与すべきと判断する。

以上の設例では、自動生成されるべきプログラムの利用者がエンティティ定義書において「社員」エンティティとして定義されていた。しかし、プログラムの利用者は必ずしもエンティティとして定義されていなければならないものではない。プログラムの利用者についての詳細情報は外部システムで定義されているような場合もあり、そのような場合のエンティティ定義書は図１０のエンティティ定義書から社員エンティティ１００１の項目を除いたもののようになる。但し、実施例２のアクセス権限管理を実現するためにはそのような場合においてもエンティティ定義書にはプログラムの利用者と少なくとも一のエンティティとの紐づけの定義は含まれていなければならない。プログラムの利用者がエンティティとして定義されていない場合の具体的構成としては、例えば図１０において、帰属社員１０１３の関連先エンティティ名欄１０１４に「社員」とあるところを、「外部システムＡＢＣで定義されたユーザＩＤ」等とする。これにより、外部システムＡＢＣで定義されたユーザIDを持つユーザは、当該関連属性の定義により紐づけされた情報についてのみ操作のアクセス権限を得ることができる。なお、この場合における「自動生成されるべきプログラムの利用者の情報」とは、関連先エンティティ名欄に記載された「外部システムＡＢＣで定義されたユーザＩＤ」の情報を意味することとなる。

図１１は、権限管理コード出力部により出力されるコードの一例(抜粋)である。これは、利用者である社員の所属部署の案件についてのみアクセス権限を付与する部分のコードである。このようなコードを出力するための権限管理用コード出力部の出力元コードのコーディング例は省略する。これはインタフェイス用コード出力部のコーディング例で説明したものと同様のコーディングにより実現することができる。

図１１のコードは案件を所有する部署に所属する社員にのみアクセス権限を与えるためのコードであるが、７行目の「$ユーザID IN 所属部署.帰属社員」の部分がアクセス権限に合致するデータ抽出のための条件式である。この条件式のうち「所属部署」は図１０の「案件」エンティティのエンティティ定義書１００４中の関連属性である「所属部署」１０１７に由来し、前記条件式の「帰属社員」の部分は「部署」エンティティのエンティティ定義書１００３中の関連属性である「帰属社員」１０１３に由来する。この条件式により、案件に関連した部署の社員のみが当該案件を抽出してアクセスすることが可能となり、当該案件データに対する変更の権限を得ることとなる。

図１１のコードはデータを操作しようとする者がデータにアクセスする際に操作権限のあるデータのみを抽出可能としてその変更を認めるというものである。つまりこの例ではデータの操作に対する権限があるかどうかの判断を行うのはデータの抽出時である。これに対して、データの抽出時においてではなくデータの書き換え時にアクセス権限の有無を判定する方法もある。後者によれば、データの抽出後にアクセス権限を失った者によるデータの書き換えを防止できるという利点がある。また、データ抽出時と書換時の両時点でアクセス権限の判定を行えばデータの健全性を一層高めることができる。<実施例２の効果>

実施例２のプログラム自動生成システムによれば、データに対するアクセス権限の定義を個別に行うことなく、適切なアクセス権限管理をすることのできるプログラムを自動生成することが可能となる。

<実施例３の概念>

実施例２のプログラム自動生成システムはエンティティ定義書でエンティティの関連属性を定義することにより簡単にデータに対するアクセス権限を管理できた。しかし、より細かなアクセス権限管理が必要となる場合がある。例えば、案件の規模が一定額以上の場合に限ってその変更を行いたいという場合に、実施例３のプログラム自動生成システムによれば、そのような案件についてのみアクセスを許可することができる。<実施例３の構成>

実施例３のプログラム自動生成システムは、操作許可用コード出力部をさらに有する。また、ユースケース定義書には操作許可情報が含まれ、出力されるプログラムには操作許可用コードが含まれる。操作許可用コード出力部は、操作許可情報に従ってエンティティに対する操作を許可する操作許可用コードを出力する。機能構成図は省略する。

図１２は、実施例３のプログラム自動生成システムにおけるユースケース定義書の一例を表す図である。操作対象定義欄１２１０には、ユースケース名欄１２０１、操作型欄１２０２及びエンティティ名欄１２０９がある。ユースケース名欄の「案件情報変更」は、このユースケース定義書で定義する操作が案件情報の変更に係るものであることを示しており、画面の表題に用いられる。操作型欄の「変更」は、操作の種類が変更であることを示している。さらに、エンティティ名欄の「案件」は、当該ユースケースで操作の対象となるエンティティは案件であることを示している。

ユースケース定義書には、エンティティに対する操作を許可するための条件である操作許可情報を定義するための「操作許可情報欄」１２２０が含まれる。操作許可情報は二種類ある。ひとつは「エンティティフィルタ」であり、もうひとつは「外部参照エンティティフィルタ」である。これらは一般的にいうとエンティティの有する属性情報に基づいて一定の条件に合致するデータを抽出するものであるが、本実施例においては、「エンティティフィルタ」は当該ユースケースで操作の対象となるエンティティの属性情報に係る条件に基づいてふるいを掛けるものであり、一方「外部参照エンティティフィルタ」は、当該ユースケースで操作の対象となるエンティティ以外のエンティティの属性情報に係る条件に基づいてふるいを掛けるものである。

図１２のユースケース定義書中の操作許可情報欄には、エンティティフィルタに係る「エンティティフィルタ用条件定義欄」１２０４と、外部参照エンティティフィルタに係る「外部参照エンティティフィルタ用条件定義欄」１２０５とが含まれる。

エンティティフィルタ用条件定義欄１２０４では、「案件」エンティティの「案件状態」属性が「起案中」であり、かつ、同エンティティの「案件」が「１０００万円以下の案件についてのみアクセスを許可するという内容が定義されている。当該フィルタは操作対象である「案件」そのものの属性に基づいてふるいをかけるものであることからエンティティフィルタに分類することができる。

図１３(A)は図１２のエンティティフィルタ用条件定義欄に記載の条件を反映したコードの出力例である。案件の中から、６行目に記載の条件により案件状態が「起案中」のものが抽出され、さらに７行目に記載の条件により案件規模が１千万円以下のものが抽出される。

外部参照エンティティフィルタ用条件定義欄１２０５では、「案件」エンティティに紐付けられた「部署」エンティティの「部門コード」が「0:本部」でないものについてのみアクセスを許可するという内容が定義されている。これによれば、例えば本部が担当する「新人研修」についてはこのユースケースによるアクセスが許されないこととなる。当該フィルタは操作対象である「案件」エンティティではなく外部の「部署」エンティティの属性に基づいてふるいをかけるものであることから外部参照エンティティフィルタに分類される。

図１３(B)は図１２の外部参照エンティティフィルタ用条件定義欄に記載の条件を反映したコードの出力例である。案件の中から、６行目に記載の条件により案件に関連付けられた部署の部門コードが「本部」でないものが抽出される。<実施例３の効果>

実施例３のプログラム自動生成システムによれば、細かな条件を定めてデータに対するアクセス権限を管理することのできるプログラムを自動生成することができる。

<実施例４の概念>

プログラムを自
動生成するシステムは、プログラマーによるプログラミングを要することなく、プログラムの設計書から直接にプログラムを生成することを可能とするものである。しかし、プログラミング不要としてもプログラムの設計書の作成自体に特殊な能力や多大な労力・時間を要したのでは全く意味がない。そこで、プログラムの設計をできるだけ簡単なものとしつつ、同時にプログラム開発者の要求にきめ細かに応えることができるものとすることが、プログラム自動生成システムにおいては重要となる。

実施例４のプログラム自動生成システムは、システム設計を簡明化する手法のひとつを実現するものである。プログラムの操作においては、ある操作Ａを行った後に他の操作Ｂ（操作ＢはＡと関係なく単独で行われることもある）が続けて行われるのが通例であることがある。例えば、顧客から商品の注文を受けたときに行う「注文入力」というユースケースと、新規顧客を登録するための「顧客登録」というユースケースとが定義されている場合において、顧客登録は新規顧客から商品の注文を受けたときに行うのが通例である場合には、顧客登録と注文入力が連続して行われる。このような場合には顧客登録が完了したときに、注文入力へと自動的に移行するのが便宜である。実施例４のプログラム自動生成システムは、このようなユースケースの移行を自動的に行うことのできるプログラムを自動的に生成することを特徴とする。<実施例４の構成>

実施例４のプログラム自動生成システムの機能構成は前記実施例１乃至３のそれと同様である。但し、ユースケース定義書は、操作完了後に移行する移行先のユースケースに係る移行先情報を含み、インタフェイス用コード出力部は、一のユースケース定義書で定義されたユースケースの完了後に移行先情報に従って他のユースケース定義書で定義されたユースケースを開始するコードを出力するためのユースケース移行用コード出力手段を有する。

「移行先情報」とは、具体的には移行先のユースケース名及び画面名のことであり、ユースケース定義書に「移行先情報」欄を設けて特定される。そして、これを設計情報取得部が読み取り、移行用コード出力手段が読み取った移行先情報に従って当該ユースケース完了後に移行先の画面を起動する。<実施例４の効果>

実施例４のプログラム自動生成システムは、ユースケース間の自動の移行を実現することにより設計書の作成を単純化し、プログラムの開発工数を削減することのできるプログラム自動生成システムである。

０１０１ 定義書０１０２ エンティティ定義書０１０３ ユースケース定義書０１１０ プログラム自動生成システム０１１１ 設計情報取得部０１１２ インタフェイス用コード出力部０１１３ データベース用コード出力部０１２０ プログラム０１２１ インタフェイス用コード０１２２ データベース用コード

Claims (4)

1. エンティティの属性情報を定義したエンティティ定義書と、所定のユースケースにおいて操作対象となるエンティティの属性情報を示す操作対象属性一覧情報と、それら属性情報を操作するための入力欄に係るインタフェイスの構成を示す入力欄設計情報と、を含むユースケース定義書との二つの定義書から、データベースに保持されたエンティティに係る情報を操作するためのプログラムを自動的に生成するプログラム自動生成システムであって、前記エンティティ定義書からは属性情報を、前記ユースケース定義書からは操作対象属性一覧情報及び入力欄設計情報を取得する設計情報取得部と、前記操作対象属性一覧情報及び入力欄設計情報に基づいてエンティティの属性情報の操作のためのインタフェイスに係るコードを出力するインタフェイス用コード出力部と、前記属性情報から属性のデータベース上における操作に係るコードを出力するデータベース操作用コード出力部と、を有するプログラム自動生成システム。
2. 前記エンティティ定義書には、自動生成されるべきプログラムの利用者の情報と、前記利用者と少なくとも一のエンティティとの紐づけの定義とが含まれ、この紐づけの定義により直接または間接に利用者に紐付けられたエンティティの属性情報についてのみ当該利用者に対して操作権限を与える権限管理用コードを出力する権限管理用コード出力部をさらに有することを特徴とする請求項１に記載のプログラム自動生成システム。
3. 前記ユースケース定義書で定義する属性情報には、エンティティに対する操作を許可するための条件である操作許可情報が含まれ、前記操作許可情報に従ってエンティティに対する操作を許可する操作許可用コードを出力する操作許可用コード出力部をさらに有することを特徴とする請求項１又は２に記載のプログラム自動生成システム。
4. 前記ユースケース定義書は、操作完了後に移行する移行先のユースケースに係る移行先情報を含み、前記インタフェイス用コード出力部は、一のユースケース定義書で定義されたユースケースの完了後に前記移行先情報に従って他のユースケース定義書で定義されたユースケースを開始するコードを出力するためのユースケース移行用コード出力手段を有することを特徴とする請求項１乃至３のいずれか一に記載のプログラム自動生成システム。

Images