この発明は、データベースを管理するデータベース管理部と、データベースアクセス時にユーザにより利用される入出力用画面を管理する画面管理部と、データベース管理部と画面管理部との間に介在してデータの変換並びに受け渡しを行うプログラムを管理するプログラム管理部とを有する情報処理システムのシステム生産方法、システム生産システム、システム生産プログラムおよびシステム生産に用いられる定義体情報のデータ構造に関し、特に、データ入出力画面、データベーステーブルおよびプログラムを一括して作成することができるとともに、各作成物の整合性を担保することが容易なシステム生産方法、システム生産システム、システム生産プログラムおよびシステム生産に用いられる定義体情報のデータ構造に関する。
従来、Webブラウザに表示されるデータ入出力用画面を用いてデータベースのデータ更新処理を行う情報処理システムが知られている。このような情報処理システムを設計する場面では、データ入出力画面の設計、データベーステーブルの設計およびデータベースのデータ更新処理を行うプログラムの設計をそれぞれ行う必要がある。
しかし、上記したデータ入出力画面設計、データベーステーブル設計およびデータ更新処理プログラム設計は、それぞれ異なる設計スキルを要するものである。したがって、上記した情報処理システムの設計および作成をする場合には、各分野のスキルに精通した開発要員を揃える必要がある。また、それぞれの設計作業の連携も必要となるため、設計作業が大規模になるとともに、作業効率が良くないという問題があった。
このため、データ入出力画面設計、データベーステーブル設計およびデータ更新処理プログラム設計を連携させて行う手法の提案がなされている。たとえば、特許文献1には、電子アンケートの集計システムに関し、アンケートの項目に関するデータ定義を行うことによってデータ入出力画面、データベーステーブルおよびデータ更新処理プログラムのひな形を自動作成する技術が開示されている。
しかしながら、上記した特許文献1の技術は、データベーステーブルを自動作成するものの、データ入出力画面やデータ更新処理プログラムに関してはそのひな形を作成するにすぎない技術である。すなわち、特許文献1の技術は、電子アンケートという特定の分野において用いられることを考慮したものであり、アンケート項目を定義すればお仕着せのデータ入出力画面等が生成されるにすぎなかった。そのため、画面やプログラムに個別システムの目的に応じた完全な動作を行わせるためにはファイルやプログラムに対する追加作業や修正作業が必要となり、システム生産時に作業ミスを誘発しやすいという問題があった。
たとえば、特許文献1の技術を用いて複数画面間の画面遷移や、電子承認に関するワークフローを実現しようとする場合には、画面遷移やワークフローに関するロジックを追加する作業が発生する。このため、作業ミスが発生するとシステム全体の整合性をとることが困難となり、最悪の場合にはシステムダウンなどの重大な障害を誘発するおそれがある。
また、特許文献1の技術は、データ項目の追加や削除といったデータベース再定義を前提とした技術ではないため、会計システムや営業管理システムといった基幹業務に適用しづらいという問題があった。たとえば、営業管理システムにおいては、取り扱う製品に応じて製品を構成する部品点数が異なることが通常であるため、新たな製品を販売対象とする場合には、各部品に対応するデータ項目を追加したり削除したりといったデータベースを再作成する作業が発生する。
これらのことから、データ入出力画面、データベーステーブルおよびプログラムを一括して作成することができるとともに、各作成物の整合性を担保することができるシステム生産手法をいかにして実現するかが大きな課題となっている。
この発明は、上述した従来技術による問題点を解消するためになされたものであって、データ入出力画面、データベーステーブルおよびプログラムを一括して作成することができるとともに、各作成物の整合性を担保することが容易なシステム生産方法、システム生産システム、システム生産プログラムおよびシステム生産に用いられる定義体情報のデータ構造を提供することを目的とする。
上述した課題を解決し、目的を達成するため、請求項1に係る発明は、データベースを管理するデータベース管理部と、データベースアクセス時にユーザにより利用される入出力用画面を管理する画面管理部と、前記データベース管理部と前記画面管理部との間に介在してデータの変換並びに受け渡しを行うプログラムを管理するプログラム管理部とを有する情報処理システムのシステム生産方法であって、前記データベースのデータベーステーブルを作成するためのデータベース作成情報、前記入出力用画面を作成するための画面作成情報及び前記入出力用画面間の遷移制御を少なくとも行う業務プログラムを作成するための業務プログラム作成情報を含んだ定義体情報の受け付けを行う受付工程と、前記受付工程が受け付けた定義体情報に基づいて前記データベーステーブル、前記入出力用画面及び前記業務プログラムを作成する作成工程とを含んだことを特徴とする。
また、請求項2に係る発明は、上記の発明において、前記作成工程は、前記定義体情報に基づいて複数の属性の属性値からなる組を識別する組識別子、各属性を識別する属性識別子及び属性値を列とする前記データベーステーブルを作成することを特徴とする。
また、請求項3に係る発明は、上記の発明において、前記受付工程は、前記データベーステーブルに対して属性の属性識別子を追加、削除または修正する変更を行う場合に、新たな属性に対応する新規入出力用画面及び新規業務プログラムを作成するための作成情報を含む前記定義体情報を受け付け、前記作成工程は、作成した新規入出力用画面及び新規業務プログラムを前記画面管理部及び前記プログラム管理部に出力することによってシステム生産を行うことを特徴とする。
また、請求項4に係る発明は、上記の発明において、前記受付工程は、前記データベース作成情報、前記画面作成情報及び前記業務プログラム作成情報を関連付けた1又は複数のテーブル形式の前記定義体情報を受け付けることを特徴とする。
また、請求項5に係る発明は、上記の発明において、前記受付工程は、前記データベーステーブルの各行に格納される前記属性と対応付けられた前記入出力用画面の構成部品の表示形式を表す表示情報と前記構成部品の各画面内における位置を表す配置情報とを前記画面作成情報として含んだ前記定義体情報を受け付けることを特徴とする。
また、請求項6に係る発明は、上記の発明において、前記受付工程は、前記入出力用画面の構成部品に関連付けられたデータベースアクセス処理を作成するための情報を前記業務プログラム作成情報として含んだ前記定義体情報を受け付けることを特徴とする。
また、請求項7に係る発明は、上記の発明において、前記受付工程は、前記入出力用画面ごとに付与された使用権限に基づくワークフロー情報を前記画面作成情報として含んだ前記定義体情報を受け付けることを特徴とする。
また、請求項8に係る発明は、上記の発明において、前記受付工程によって受け付けられた定義体情報の整合性を検査する定義体情報検査工程をさらに含んだことを特徴とする。
また、請求項9に係る発明は、データベースを管理するデータベース管理部と、データベースアクセス時にユーザにより利用される入出力用画面を管理する画面管理部と、前記データベース管理部と前記画面管理部との間に介在してデータの変換並びに受け渡しを行うプログラムを管理するプログラム管理部とを有する情報処理システムのシステム生産を行うシステム生産装置を含んだシステム生産システムであって、前記データベースのデータベーステーブルを作成するためのデータベース作成情報と、前記入出力用画面を作成するための画面作成情報と、前記入出力用画面間の遷移制御を少なくとも行う業務プログラムを作成するための業務プログラム作成情報とを含んだ定義体情報の受け付けを行う受付手段と、前記受付手段が受け付けた定義体情報に基づいて前記データベーステーブル、前記入出力用画面及び前記業務プログラムを作成する作成手段とを備えたことを特徴とする。
また、請求項10に係る発明は、データベースを管理するデータベース管理部と、データベースアクセス時にユーザにより利用される入出力用画面を管理する画面管理部と、前記データベース管理部と前記画面管理部との間に介在してデータの変換並びに受け渡しを行うプログラムを管理するプログラム管理部とを有する情報処理システムのシステム生産を行うシステム生産装置に用いられるシステム生産プログラムであって、前記データベースのデータベーステーブルを作成するためのデータベース作成情報と、前記入出力用画面を作成するための画面作成情報と、前記入出力用画面間の遷移制御を少なくとも行う業務プログラムを作成するための業務プログラム作成情報とを含んだ定義体情報の受け付けを行う受付手順と、前記受付手順が受け付けた定義体情報に基づいて前記データベーステーブル、前記入出力用画面及び前記業務プログラムを作成する作成手順とをコンピュータに実行させることを特徴とする。
また、請求項11に係る発明は、データベースを管理するデータベース管理部と、データベースアクセス時にユーザにより利用される入出力用画面を管理する画面管理部と、前記データベース管理部と前記画面管理部との間に介在してデータの変換並びに受け渡しを行うプログラムを管理するプログラム管理部とを有する情報処理システムのシステム生産に用いられる定義体情報のデータ構造であって、前記定義体情報は、前記データベースのデータベーステーブルを作成するためのデータベース作成情報と、前記入出力用画面を作成するための画面作成情報と、前記入出力用画面間の遷移制御を少なくとも行う業務プログラムを作成するための業務プログラム作成情報とを整合性を維持しつつ関連付けた1又は複数のテーブルからなり、複数の属性の属性値からなる各組を識別する組識別子、各属性を識別する属性識別子及び属性値を列とする前記データベーステーブルを作成する情報を含んだ情報であることを特徴とする。
請求項1、9又は10の発明によれば、データベースのデータベーステーブルを作成するためのデータベース作成情報、入出力用画面を作成するための画面作成情報及び入出力用画面間の遷移制御を少なくとも行う業務プログラムを作成するための業務プログラム作成情報を含んだ定義体情報の受け付けを行い、受け付けた定義体情報に基づいてデータベーステーブル、入出力用画面及び前記業務プログラムを作成するよう構成したので、データ入出力画面、データベーステーブルおよび業務プログラムを一括して作成することができるとともに、各作成物の整合性を担保することができるという効果を奏する。
また、請求項2の発明によれば、定義体情報に基づいて複数の属性の属性値からなる組を識別する組識別子、各属性を識別する属性識別子及び属性値を列とするデータベーステーブルを作成するよう構成したので、縦もちのデータベーステーブルに各データを格納することによって、新規属性の追加や、既存属性の削除を行う場合であってもデータベーステーブルの再定義を不要とすることができるという効果を奏する。
また、請求項3の発明によれば、データベーステーブルに対して属性の属性識別子を追加、削除または修正する変更を行う場合に、新たな属性に対応する新規入出力用画面及び新規業務プログラムを作成するための作成情報を含む定義体情報を受け付け、受け付けた定義体情報に基づいて作成した新規入出力用画面及び新規業務プログラムを画面管理部及びプログラム管理部に出力することによってシステム生産を行うよう構成したので、システムの変更を効率的かつ確実に行うことができるという効果を奏する。
また、請求項4の発明によれば、データベース作成情報、画面作成情報及び業務プログラム作成情報を関連付けた1又は複数のテーブル形式の定義体情報を受け付けるよう構成したので、データベーステーブル、画面および業務プログラムの整合性を担保することができるとともに、システム変更点の波及範囲を正確に把握することができるという効果を奏する。
また、請求項5の発明によれば、データベーステーブルの各行に格納される属性と対応付けられた入出力用画面の構成部品の表示形式を表す表示情報と構成部品の各画面内における位置を表す配置情報とを画面作成情報として含んだ定義体情報を受け付けるよう構成したので、定義体情報に対するデータ定義を行うのみで、そのまま使用可能な完成された画面を自動作成することができるという効果を奏する。
また、請求項6の発明によれば、入出力用画面の構成部品に関連付けられたデータベースアクセス処理を作成するための情報を業務プログラム作成情報として含んだ定義体情報を受け付けるよう構成したので、定義体情報に対するデータ定義を行うのみで、データベースに対する問い合わせロジックを自動作成することができるという効果を奏する。
また、請求項7の発明によれば、入出力用画面ごとに付与された使用権限に基づくワークフロー情報を画面作成情報として含んだ定義体情報を受け付けるよう構成したので、定義体情報に対するデータ定義を行うのみで、複数画面を用いたワークフローを自動作成することができるという効果を奏する。
また、請求項8の発明によれば、受け付けた定義体情報の整合性を検査するよう構成したので、整合性が担保された定義体情報に基づいてシステム生産を行うことによって、システム生産の信頼性を高めることができるという効果を奏する。
また、請求項11の発明によれば、定義体情報は、データベースのデータベーステーブルを作成するためのデータベース作成情報と、入出力用画面を作成するための画面作成情報と、入出力用画面間の遷移制御を少なくとも行う業務プログラムを作成するための業務プログラム作成情報とを整合性を維持しつつ関連付けた1又は複数のテーブルからなり、複数の属性の属性値からなる各組を識別する組識別子、各属性を識別する属性識別子及び属性値を列とする前記データベーステーブルを作成する情報を含んだ情報であるよう構成したので、この定義体情報を用いたシステム生産を行うことによって、データ入出力画面、データベーステーブルおよび業務プログラムを一括して作成することができるとともに、各作成物の整合性を担保することができるという効果を奏する。
以下に添付図面を参照して、本発明に係るシステム生産方法、システム生産システム、システム生産プログラムおよびシステム生産に用いられる定義体情報のデータ構造の実施例1〜2を詳細に説明する。なお、以下の説明においては、ダウンロード用画面をネットワークを介してダウンロードするクライアントコンピュータと、ダウンロード用画面および業務ロジックを管理するアプリケーションサーバ装置と、データベースを管理するデータベースサーバ装置とで構成されるいわゆる「三層アーキテクチャ」を採用した情報処理システムのシステム生産を行う場合について説明する。
まず、各実施例の詳細な説明に先立って本発明に係るシステム生産手法の特徴について説明する。図1は、本発明に係るシステム生産手法の概要を示す図である。
同図に示すように、本実施例に係るシステム生産手法では、上記した三層アーキテクチャを採用した情報処理システムのシステム生産を、ネットワーク接続されたシステム生産装置を用いて行う。このシステム生産装置は、データ入出力画面、データベーステーブルおよび業務プログラム(画面遷移制御プログラムおよびデータ更新処理プログラムを含む)を作成するための情報である「定義体情報」に基づき、同図に示すアプリケーションサーバあるいはデータベースサーバのデータ更新を行うことによってシステム生産処理を行う装置である。
具体的には、このシステム生産装置は、テーブル形式の情報である定義体情報の登録を受け付け(図1の(1)参照)、受け付けた定義体情報の整合性などをチェックする(図1の(2)参照)。そして、定義体情報が正常であると判定されたならば、画面作成用のJSP(登録商標、Java(登録商標) Server Pages)、業務ロジック作成用のJAVA(登録商標)プログラムおよびデータベース問い合わせ用のSQL(Structured Query Language)、データベーステーブル作成用のSQLなどを作成し、これらのデータを用いたリモートコマンドを発行することによってシステムを作成する(図1の(3a)〜(3c)参照)。
前述したように、特許文献1には、電子アンケートの項目に関するデータ定義を行うことによって、データベーステーブルを作成するとともに、データ入出力画面およびデータ更新処理プログラムのひな形を作成する技術が開示されている。
しかし、特許文献1の技術は、電子アンケートのようにデータ項目のメンテナンスを要しないシステムを前提とした技術であり、この技術分野にのみ使用されることを前提としたうえでアンケート項目を定義すれば機械的にお仕着せのレイアウトに従ったデータ入出力画面等が生成されるにすぎないものである。また、電子アンケートは単発的におこなわれアンケート結果が出るとその使命を終える性質を有しているので、データ項目が追加・削除されることはない。すなわち、特許文献1の技術は、データベーステーブルの項目追加や項目削除が頻繁に行われるシステムへの適用を前提とした技術ではない。
このため、企業の基幹業務システムなどのように、データ項目の追加や削除が頻繁に発生するシステム生産には適用しづらいという問題があった。また、かかる従来技術は、データ入出力画面やデータ更新処理プログラムのひな形を作成する技術であり、画面やプログラムに個別のシステムの目的に応じた完全な動作を行わせるためにはファイルやプログラムに対する追加作業や修正作業が必要となる。
そこで、本実施例に係るシステム生産手法では、データベース作成情報、画面作成情報及び業務プログラム作成情報を含んだ定義体情報を新たに考案し、この定義体情報を用いて画面作成、業務ロジック作成およびデータベース作成を一括して行うこととした。なお、本システム生産手法によって作成される画面や業務ロジックは、事後的な修正作業を要することなくそのまま動作可能な完全な形で作成される。
また、かかる定義体情報は、データ項目の追加や削除をデータベーステーブルに反映させるのみならず、画面や業務ロジックにも一括して反映させることができるデータ構造を有している。すなわち、データベーステーブルのデータ項目、各データ項目に対応する画面部品、画面部品が操作された場合などに呼び出される業務ロジックを関連付けて定義することが可能である。したがって、データ項目の追加や削除といったシステムメンテナンスを行う場合であっても、変更点の整合性を担保することができる。
また、本実施例に係るシステム生産手法には上記した定義体情報をチェックする機能を持たせているので、定義体情報の定義ミスを事前に発見することができる。したがって、定義ミスに起因するシステムダウンなどのシステム障害を防止することが可能である。なお、かかる定義体情報のデータ構造の詳細については後述する。
さらに、本実施例に係るシステム生産手法ではかかる定義体情報に基づき、データベースのいわゆる1レコードに相当するデータ群を、複数行にわたって格納する列数が固定のデータベーステーブルを作成するので、データベーステーブルにデータ項目を追加あるいは削除する場合であっても、通常のデータベースアクセス処理(たとえば、行挿入や行削除)を実行すれば足りる。すなわち、データ項目の追加や削除に伴ってデータベーステーブルを再作成する必要がないので、コンピュータシステムの可用性を高めることができる。
ところで、図1においては、アプリケーションサーバやデータベースサーバとは別にシステム生産装置を設け、このシステム生産装置がシステム生産を行う場合について示しているが、これに限らず、アプリケーションサーバあるいはデータベースサーバ上に、システム生産装置と同様の機能(たとえば、プログラム)を搭載することによってシステム生産を行うこととしてもよい。
また、図1においては、システム生産装置がリモートコマンドを用いてシステム生産する場合について示したが、アプリケーションサーバやデータベースサーバにシステム生産用データを送信することとし、これらのデータを受信した各装置がシステム生産を行うよう構成することもできる。なお、かかる変形例については、図18を用いて後述する。
ここで、かかるアプリケーションサーバは以下に示す各実施例のように、インターネットやイントラネットで用いられる場合には、Webサーバとしての機能をあわせもつように構成すればよい。また、この場合にはクライアントの端末にWebブラウザを搭載するよう構成することになる。
以下では、本発明に係るシステム生産手法を適用した実施例1〜2を説明する。なお、実施例1では、定義体情報を用いた基本的な実施例について、実施例2では、定義体情報に複数画面の定義を行い、これらの画面を用いた画面遷移およびワークフローを実現する実施例についてそれぞれ説明することとする。
本実施例1では、定義体情報を用いた基本的な実施例について図2〜図6を用いて説明する。図2は、本実施例1に係るシステム生産装置10の構成を示す機能ブロック図である。同図に示すように、システム生産装置10は、入力部11と、出力部12と、I/F部13と、記憶部14と、制御部15とを備えている。また、記憶部14は、定義体データ14aと、画面作成情報14bと、業務ロジック作成情報14cと、データベーステーブル(以下、「DBテーブル」と記載する)作成情報14dとを記憶し、制御部15は、定義体データ管理部15aと、チェック処理部15bと、システム情報作成部15cと、システム生産処理部15dとをさらに備えている。
入力部11は、後述する定義体データの登録を受け付けるキーボード、マウス、可搬型記録媒体読取装置といった入力デバイスである。そして、この入力部11は受け付けた定義体データを制御部15の定義体データ管理部15aに渡す処理を行う。また、出力部12は、ディスプレイ装置などの出力デバイスであり、登録された定義体データや、定義体データのチェック結果を表示する処理を行う。なお、本実施例1では、入力部11および出力部12を別々のデバイスとして構成した場合を示したが、タッチパネル付ディスプレイ装置などの入出力デバイスを用いることとしてもよい。
I/F部13は、LAN(Local Area Network)ボードなどの通信デバイスで構成され、図1に示した各サーバ装置とシステム生産装置10の間でデータ送受信処理を行う。たとえば、このI/F部13は、制御部15のシステム生産処理部15dが発行するリモートコマンドを該当する装置に対して送信する処理を行う。
記憶部14は、不揮発性RAM(Random Access Memory)や、ハードディスク装置といった記憶デバイスで構成された記憶部であり、定義体データ14a、画面作成情報14b、業務ロジック作成情報14cおよびDBテーブル作成情報14dを記憶する。
定義体データ14aは、データベーステーブル、画面および業務ロジックの作成を行うためのデータであり、複数のテーブル形式データによって構成される。この定義体データ14aを構成する各テーブルは他のテーブルと関連付けられており、各テーブルにデータを定義することによって、システム生産を一括して行うことが可能となる。なお、本実施例1では、定義体データ14aをテーブル群によって構成する場合について説明するが、かかるテーブル群と同様の内容を含んだ、INI(INItialize)ファイル形式やCSV(Comma Separated Value)形式のファイル群、あるいは、複数の定義項目を含んだ単一のファイルを用いることとしてもよい。
ここで、かかる定義体データ14aを構成する各テーブルについて図3を用いて説明しておく。図3は、定義体情報(定義体データ14a)を構成するテーブル群の一例を示す図である。なお、同図には、データ項目定義テーブル103a、画面タイプ定義テーブル103b、画面構成項目定義テーブル103cおよび画面間遷移定義テーブル103dの4つのテーブルを示している。
データ項目定義テーブル103aは、データベーステーブルのデータ項目を定義するためのテーブルである。このデータ項目定義テーブル103aは、「項目ID」と、「項目名」と、「桁数」と、「チェックタイプ」と、「ビジネスロジック」とを列項目として含んだテーブルである。「項目ID」は、定義体データ14aで定義する全てのデータ項目を一意に識別するための識別子である。この項目IDは、画面構成項目定義テーブル103cにおいても用いられており、データ項目定義テーブル103aの行データと、画面構成項目定義テーブル103cの行データとの対応関係を表現するために用いられる。たとえば、データ項目定義テーブル103aにおける項目IDが「102」の行データは、画面構成項目定義テーブル103cにおける項目IDが「102」の行データと関連付けられている。
「項目名」は、データ項目の名称を定義したものである。この項目名に定義されたデータは、後述する作成画面に表示されるデータ項目名に対応している。なお、データ項目定義テーブル103aの項目名とは異なるデータ項目名を画面上に表示したい場合には、画面構成項目定義テーブル103cにおいてその旨を定義することとすればよい。
「桁数」は、データベーステーブルにおける各データ項目のバイト数を定義したものである。なお、この桁数は、上記した項目名と同様に作成画面に表示される各画面構成部品のデータ項目長としても用いられる。
「チェックタイプ」は、入力値に対するチェック方式を定義したものである。たとえば、この「チェックタイプ」に「0」が指定された場合には入力値チェックを行わない。また、「10」が指定された場合には日付形式チェックを行う、「20」の場合には数字のみ入力可のチェック、「30」の場合には半角英字のみ可のチェック、「40」の場合には半角英数字のみ可のチェックというように、データ項目ごとにチェック方式を変更することが可能である。
「ビジネスロジック」は、データ項目に対応して実行されるクラスを定義したものである。たとえば、同図に示すように、この「ビジネスロジック」にクラスパスが指定された場合には、このクラスパスに一致するクラスが実行されることになる。また、同図に示した「ConsumerTax」というクラスは、データ項目定義テーブル103aの中から「金額」という項目を探し、見つかった「金額」項目の値に所定の税率をかける計算を行うクラスである。
画面タイプ定義テーブル103bは、作成される画面の形式を定義するためのテーブルである。この画面タイプ定義テーブル103bは、「画面ID」と、「名称」と、「画面タイプ」とを列項目として含んだテーブルである。「画面ID」は、定義体データ14aで定義する全ての画面を一意に識別するための識別子である。たとえば、図3に示した場合では、この画面IDは「A01」と指定されているので、他の画面定義を行う場合には「A01」以外の識別子を指定することになる。
「名称」は、各画面の名称であり、この「名称」に指定されたデータが各画面のタイトル部などに表示される。たとえば、図3に示した場合では、作成された画面のタイトル部などに「契約入力」と表示されることになる。また、「画面タイプ」は、各画面の画面形式を定義したものである。たとえば、この「画面タイプ」に「10」が指定された場合にはメニュー画面として画面作成が行われる。また、「20」が指定された場合には検索データの一覧画面として、「30」が指定された場合には検索条件を入力する画面として、「40」が指定された場合には各項目の入力/参照画面としてというように、作成画面の画面形式を変更することが可能である。
画面構成項目定義テーブル103cは、作成される画面に含まれる各画面構成部品の詳細情報を定義するためのテーブルである。この画面構成項目定義テーブル103cは、「画面ID」と、「項目ID」と、「ソート順」と、「入力フラグ」と、「必須チェック」と、「入力タイプ」とを列項目として含んだテーブルである。「画面ID」は、上記した画面タイプテーブル103bの「画面ID」と対応した項目であり、「項目ID」は、上記したデータ項目定義テーブル103aの「項目ID」と対応した項目である。このように、他のテーブルで用いられるキー項目などの項目と対応付けることで、データベーステーブル上に作成されるデータ項目と作成画面に含まれる画面構成部品とを関連付けている。
「ソート順」は、画面内における各画面構成部品の配置順序を指定するための項目である。たとえば、図3に示した場合では、「ソート順」に指定された値の昇順で配置が行われ、「項目ID」が「100」、「103」、「102」、「101」、「200」、「201」の順序で各画面構成部品が上から下へと配置される。
「入力フラグ」は、該当する画面における入力を許可するか否かを指定するための項目である。たとえば、この「入力フラグ」に「1」が指定された場合には入力が許可され、「0」が指定された場合には入力が不許可(参照のみ可)となる。また、「必須チェック」は、「入力フラグ」に「1」(入力可)が指定された場合にのみ用いられる項目であり、必須入力項目であるか任意入力項目であるかが指定される。たとえば、この項目に「0」が指定されていれば該当項目は任意入力項目であり、「1」が指定されていれば必須入力項目である。
「入力タイプ」は、「入力フラグ」に「1」(入力可)が指定された場合には必須指定項目となる項目であり、入力用部品の種類を指定する。たとえば、「text」が指定された場合には単一行のテキスト入力部品が、「radio」が指定された場合には選択肢から一つを選択するいわゆるラジオボタンが、「check」が指定された場合には各選択肢の選択/非選択を指定可能ないわゆるチェックボックスが、「textarea」が指定された場合には複数行のテキスト入力部品がそれぞれ作成されることになる。
画面間遷移定義テーブル103dは、作成される画面に含まれる各画面構成部品が選択された場合などに、コールされる業務ロジックを指定するためのテーブルである。この、画面間遷移定義テーブル103dは、「画面ID」と、「ID」と、「次画面ID」と、「アクションID」と、「表示名称」とを列項目として含んだテーブルである。「画面ID」は、画面タイプ定義テーブル103bおよび画面構成項目定義テーブル103cの「画面ID」と対応した項目である。また、「ID」は、画面に含まれるボタン部品を一意に識別するための識別子である。
「次画面ID」は、表示中の画面がポップダウンした場合に表示される画面の識別子である。なお、同図に示したように、この「次画面ID」に「9999」が指定された場合には、一覧画面に戻ることになる。また、「アクションID」は、該当するボタン部品が押下された場合に呼び出される業務ロジックを一意に識別するための識別子であり、「表示名称」は、該当するボタン部品に表示される文字列である。
たとえば、図3に示した場合では、画面IDが「A01」である画面の表示中に、画面間遷移定義テーブル3dの表示名称が「確認」であるボタンが押下されると、アクションIDが「Save」である業務ロジックが呼び出され、「A01」の画面がポップダウンするとともに、「A02」の画面がポップアップする。なお、アクションIDが「Save」である業務ロジックの作成については後述する(図4参照)。
また、定義体データ14aにおいては、この他、データのデフォルト値を指定したり、ある項目の値が特定の範囲内にあれば他の項目の値について所定のチェックを行ったり、ある項目に値が入力されるとこの入力値を他の項目の初期値として設定したりといった各種データ処理についての定義を行うこととしてもよい。
上述したように、定義体データ14aを用いることによって、データベーステーブル、画面および業務ロジックの作成を一括して行うことができるとともに、データ項目の追加や削除が生じた場合であっても、この定義体データ14aを更新するのみで、システム再作成を容易に行うことができる。
図2の説明に戻り、画面作成情報14bについて説明する。画面作成情報14bは、制御部15のシステム情報作成部15cが定義体データ14aに基づいて作成するJSP(登録商標)などの画面作成用情報である。また、業務ロジック作成情報14cは、同じくシステム情報作成部15cが作成するSQLを含んだJAVA(登録商標)プログラムなどの業務ロジック作成用情報である。そして、DBテーブル作成情報14dは、同じくシステム情報作成部15cが作成するSQLデータなどのデータベーステーブル作成用情報である。これらの情報が制御部15のシステム生産処理部15dに読み込まれると、画面、業務ロジックおよびデータベーステーブルが図1に示した各サーバ装置上に作成されることになる。
制御部15は、定義体データ14aの登録やチェック、修正といった管理処理を行うとともに、定義体データ14aに基づいてシステム生成情報を作成し、作成したシステム生成情報を用いることによってシステムの生産処理を行う処理部である。
定義体データ管理部15aは、定義体データ14aを入力部11を介して受け取り、受け取った定義体データ14aを記憶部14に記憶させる処理を行う処理部である。また、この定義体データ管理部15aは、入力部11から受け取った定義体データ14aをチェック処理部15bに渡し、チェック処理部15bのチェック結果が正常である場合にのみ、かかる定義体データ14aを記憶部14に記憶させる処理を行う。なお、かかるチェック結果は、出力部12に出力されるので、保守員などはチェック結果を参照しながら正常な定義体データ14aを入力することが可能である。
チェック処理部15bは、定義体データ管理部15aから渡された定義体データ14aの書式検査や整合性検査を行い、検査結果を定義体データ管理部15aに返す処理を行う処理部である。たとえば、このチェック処理部15bは、図3に示した各テーブル(図3の103a〜103d参照)を関連付ける情報(たとえば、「項目ID」や「画面ID」)の参照先あるいは参照元をトレースすることによって整合性を検査する。また、テーブルの各項目に入力されたデータが許容値であるか否かの検査も併せて行う。
システム情報作成部15cは、記憶部14の定義体データ14aを取得し、取得した定義体データ14aに基づいて画面作成情報14b、業務ロジック作成情報14cおよびDBテーブル作成情報14dを作成して記憶部14に記憶させる処理を行う処理部である。
システム生産処理部15dは、記憶部14の画面作成情報14b、業務ロジック作成情報14cおよびDBテーブル作成情報14dを取得し、取得した各情報(14b〜14d)に対応するJSP(登録商標)やSQLを作成するとともに、作成したデータを含んだリモートコマンドを各サーバ装置に発行することによってシステム生産を実行する処理部である。
次に、かかるシステム生産処理部15dが実行するシステム生産処理によって作成される画面やDBテーブルの一例について図4を用いて説明する。図4は、図3に示した定義体情報(103a〜103dの各テーブル)に基づいて作成される成果物について示す図である。
図4の104aに示したのは、図3に示した定義体情報(103a〜103dの各テーブル)に基づいて作成される画面である。図4の104aに示したように、103aの「項目名」に対応する画面構成部品が103cの「ソート順」に従って作成されている。また、103dの「表示名称」に対応するボタン部品がそれぞれ作成されており、「契約入力」という画面タイトルは、103bの「名称」に従って作成されている。
また、図4の104bに示したのは、図3の103aに基づいて作成されるDBテーブルである。図4の104bに示したように、作成されるDBテーブルは、「識別コード」と、「項目ID」と、「登録内容」とを列項目として有する列数が固定のテーブルである。「識別コード」は、図3の103aに示した5つの項目名(「契約#」〜「金額」)を1グループとした項目群を一意に識別する識別子である。また、「項目ID」は、図3の103aに示した「項目ID」と対応した項目であり、同一の「識別コード」に属する各項目を一意に識別する識別子である。そして、「登録内容」は、図3の103aに示した「桁数」に従って作成される記憶エリアに格納されるデータ内容である。
また、図4の104cに示したのは、図3の103dに示した「アクションID」が「Save」である行に対応して作成された業務ロジックによってDBテーブルに登録されるデータ群の一例である。図4の104c示したように、「項目ID」が「100」〜「200」の5つの行には、同一の「識別コード」(「A0000001」)が付与される。そして、図4の104aに示した画面にデータが入力されて「確認ボタン」が押下されるたびに、異なる識別コードが付与された6つの行がDBテーブル(図4の104b参照)に登録されていくことになる。
なお、図4の104cでは、作成された業務ロジックによって登録されるDBテーブルのイメージを示したが、かかる業務ロジックの作成例としては以下のものがある。たとえば、各画面構成部品に入力されたデータを取得し、取得した各データをDBテーブルの各行に登録するSQLを発行するルーチンなどである。
次に、定義体情報に新規項目を追加する場合の例について図5〜図6を用いて説明する。図5は、図3に示した定義体情報に新規項目を追加する場合の一例を示す図であり、図6は、図5に示した定義体情報に基づいて作成される成果物について示す図である。なお、図5〜図6は、図4の104aに示した画面に「備考」の欄を追加する例について示している。また、図5に示した105a〜105dの各テーブルは、図3に示した103a〜103dの各テーブルにそれぞれ対応している。
図3に示した103aのテーブルに「項目名」が「備考」である行を追加したものが図5の105aのテーブルである。また、図3に示した103cのテーブルに「項目ID」が「202」である行を追加したものが図5の105cのテーブルである。このように、新規項目の追加を行うためには該当するテーブルに行を追加するだけでよい。なお、同図においては、各テーブルの最下行に新規項目を追加する場合について示したが、追加する行の位置に制限はない。すなわち、各テーブルの最上行に新規項目を挿入したり、任意の行に新規項目を挿入したりすることができる。
このようにして定義された定義体情報に基づいて作成される成果物を図6に示している。図6の106aに示すように、画面には「備考欄」が追加されているが、106bに示したDBテーブルに変更はない。すなわち、本実施例1に係る定義体情報に基づいて作成されるDBテーブルは列数が固定のテーブルであり、新規項目の追加や削除を行う場合であってもDBテーブルを再作成する必要がない。
また、図6の106cに示すように、図4の104cに示したデータ群には、「項目ID」が「202」(画面の「備考欄」に対応)が追加されている。このように、データ項目を追加した場合には、DBテーブル(図6の106b参照)の変更は生じない。そして、データ項目の追加に対応した業務ロジックを自動作成することによってデータ項目の追加に対応することとしている。また、データ項目追加の手順と同様の手順で、データ項目の削除を行うことができる。したがって、本実施例1に係るシステム生産手法は、データ項目の追加や削除が頻繁に発生するシステムのシステム生産に適している。
上述してきたように、本実施例1では、定義体データ管理部がデータベースのデータベーステーブルを作成するためのデータベース作成情報、入出力用画面を作成するための画面作成情報及び入出力用画面間の遷移制御を少なくとも行う業務プログラムを作成するための業務プログラム作成情報を含んだ定義体情報を受け付け、チェック処理部がかかる定義体情報の整合性を検査したうえで定義体データとして記憶部に記憶させるよう構成した。また、システム情報作成部が記憶部の定義体データに基づいて画面作成情報、業務ロジック作成情報およびDBテーブル作成情報を作成し、システム生産処理部がこれらの作成情報に基づいてシステム生産を行うよう構成した。
したがって、データ入出力画面、データベーステーブルおよび業務プログラムを一括して作成することができるとともに、各作成物の整合性を担保することが容易である。また、システムの変更時には、かかる定義体情報の変更箇所からシステム変更の波及範囲を正確に把握することができるとともに、システム変更の整合性を予め確認することが可能となる。
実施例2では、定義体情報に複数画面の定義を行い、これらの画面を用いた画面遷移およびワークフローを実現する実施例について図7〜図17を用いて説明する。なお、以下の説明においては実施例1との相違点について主に説明し、共通点についての説明は簡単なものにとどめることとする。
まず、定義体情報を構成するテーブル群について説明する。本実施例2では、実施例1で示したテーブル群(図5の105a〜105d参照)において複数画面の定義を行うとともに(図7〜図9参照)、新たに、アクタ(権限)定義テーブル(図10参照)、ユーザ定義テーブル(図11参照)およびワークフロー定義テーブル(図12参照)を追加することによって複数画面を用いた画面遷移およびワークフローを定義することとしている。
図7は、本実施例2に係る定義体情報に含まれる画面タイプ定義テーブルの一例を示す図である。なお、同図に示す画面タイプ定義テーブルは、実施例1で示した画面タイプ定義テーブル(図5の105b参照)において複数画面の定義を行ったものである。
具体的には、図7に示したように、契約入力画面(画面IDが「A01」)、契約確認画面(画面IDが「A02」)および契約承認画面(画面IDが「B02」)の3画面を、この画面タイプ定義テーブルにおいて定義している。本実施例2においては、これら3画面を使用権限が異なるユーザに割り当て、部下から上司への電子承認に関するワークフローを実現することとしている。
図8は、画面構成項目定義テーブルの一例を示す図である。なお、同図に示す画面構成項目定義テーブルは、実施例1で示した画面構成項目定義テーブル(図5の105c参照)において複数画面に関する画面構成項目の定義を行ったものである。また、図8の108aは図7に示した画面IDが「A01」の契約入力画面を構成する項目を定義したデータ例であり、同じく108bは図7に示した画面IDが「A02」の契約確認画面を構成する項目を定義したデータ例であり、同じく108cは図7に示した画面IDが「B02」の契約承認画面を構成する項目を定義したデータ例である。
なお、図8の108aは、図5の105cと同一内容である。また、図8の108bおよび108cは、108aと異なり「入力フラグ」の項目が全て「0」となっている。すなわち、契約確認画面(108bに対応)および契約承認画面(108cに対応)では、各画面構成項目への入力を禁止することとしている。
図9は、画面間遷移定義テーブルの一例を示す図である。なお、同図に示す画面間遷移定義テーブルは、実施例1で示した画面間遷移定義テーブル(図5の105d参照)において複数画面に関する画面間遷移の定義を行ったものである。また、図9の109aは図7に示した画面IDが「A01」の契約入力画面に関する画面間遷移を定義したデータ例であり、同じく109bは図7に示した画面IDが「A02」の契約確認画面に関する画面間遷移を定義したデータ例であり、同じく109cは図7に示した画面IDが「B02」の契約承認画面に関する画面間遷移を定義したデータ例である。
なお、図9に示した画面間遷移定義テーブルには、「アクタコード」という項目が新たに追加されている。この「アクタコード」とは、後述するアクタ(権限)定義テーブル(図10参照)において定義される、画面の使用者(たとえば、「担当者」や「管理者1」)の権限を一意に識別するための識別子である。たとえば、図9の109aおよび109bは、アクタコードが「1001」であるので画面の使用者は「担当者」である(図10参照)。また、図9の109cは、アクタコードが「1002」であるので画面の使用者は「管理者1」である(図10参照)。
図9の109aに示すように、画面IDが「A01」である画面の表示中に「表示名称」が「確認」であるボタンが押下されると、「アクションID」が「Save」である業務ロジックがコールされるとともに「次画面ID」に指定された画面ID(A02)に対応する画面、すなわち、契約確認画面がポップアップする。
また、図9の109bに示すように、画面IDが「A02」である画面の表示中に「表示名称」が「申請」であるボタンが押下されると、「アクションID」が「Application」である業務ロジックがコールされるとともに「次画面ID」に指定された画面ID(B02)に対応する画面、すなわち、契約承認画面が承認者のPC(パーソナルコンピュータ)などに表示されることになる。
また、図9の109cに示すように、画面IDが「B02」である画面の表示中に「表示名称」が「承認」であるボタンが押下された場合には「アクションID」が「Recognition」である業務ロジックがコールされ、「表示名称」が「返却」であるボタンが押下された場合には「アクションID」が「Rejection」である業務ロジックがコールされる。
すなわち、画面間遷移定義テーブルに図9で示したような記述を行うことによって複数画面間における遷移あるいはコールされるロジックを定義することが可能となる。
図10は、アクタ(権限)定義テーブルの一例を示す図である。このアクタ(権限)定義テーブルは、「アクタコード」と「アクタ名称」とを列項目として含んだテーブルである。「アクタコード」は画面使用者の権限あるいは役割の設定単位である「アクタ」を一意に識別するための識別子である。また、「アクタ名称」は各アクタに付与された名称であり、同図に示したように、たとえば、「担当者」や「管理者1」といった役職名などが設定される。
図11は、ユーザ定義テーブルの一例を示す図である。このユーザ定義テーブルは、「ユーザID」と、「アクタコード」と、「ユーザ名」とを列項目として含んでおり、各画面使用者の定義を行うためのテーブルである。「ユーザID」は各画面使用者(ユーザ)を一意に識別するための識別子であり、「アクタコード」は図10に示した権限定義テーブルの「アクタコード」に対応する項目である。また、「ユーザ名」は各画面使用者に付与された名称であり、同図に示したように、たとえば、各画面使用者のフルネームなどが設定される。
図12は、ワークフロー定義テーブルの一例を示す図である。このワークフロー定義テーブルは、「申請」と、「現在」と、「次」とを列項目として含んでおり、ワークフローを構成する各段階に介在する画面使用者の「アクタコード」を定義したテーブルである。「申請」はワークフローの起点となる申請処理を行う画面使用者のアクタコードであり、「現在」はワークフロー内の現段階における画面使用者のアクタコードである。また、「次」はワークフロー内における次段階における画面使用者のアクタコードである。
たとえば、図12に示した場合では、アクタコードが「1001」すなわちアクタ名称が「担当者」(図10参照)が起点となるワークフローを定義している。そして、ワークフローの現段階が「1001」(担当者)であれば次段階は「1002」(管理者1,図10参照)であり、現段階が「1002」(管理者1)であれば次段階は「9999」(終了)である旨が定義されている。
このように、ワークフロー定義テーブルを用いることでワークフローを構成する各段階に介在する画面使用者を定義することができる。なお、図12においては、「担当者」および「管理者1」の2段階のワークフローを定義しているが、これに限らず、5段階や10段階といった多段階のワークフローを定義することももちろん可能である。
次に、本実施例2に係る定義体情報に含まれる各テーブル間の関係について図13を用いて説明する。図13は、実施例2に係る定義体情報に含まれる各テーブル間の関係を示す図である。なお、同図に示す1−1〜1−9は各テーブルの名称を表しており、1−1aから1−9aは各テーブルの内容を表している。そして、1−1〜1−7の各テーブルは、上記したデータ項目定義テーブル、画面タイプ定義テーブル、画面構成項目定義テーブル、画面間遷移定義テーブル、アクタ定義テーブル、ユーザ定義テーブルおよびワークフロー定義テーブルにそれぞれ対応している。
また、図13に示した区分体系定義テーブル1−8は、データ項目定義テーブル1−1などのテーブルで用いられる「翻訳ID」(1−8a参照)などの項目を定義するテーブルである。なお、この「翻訳ID」は商品区分などの区分体系を一意に識別するための識別子である。
また、図13に示した区分値定義テーブル1−9は、ラジオボタンやコンボボックスといった選択式の画面構成部品の各選択肢を定義するためのテーブルである。たとえば、ラジオボタンの選択肢として、鉛筆、ノートおよび消しゴムの3つがある場合には、「翻訳コード」(1−9a参照)に1、2および3を指定することになる。
ところで、図13に示した各テーブル(1−1〜1−9)を結ぶ矢印は、各テーブル間の参照関係を表している。具体的には、矢印の根が参照元となるテーブルを、矢印の先が参照先となるテーブルをそれぞれ指しており、参照元テーブルと参照先テーブルとの対応関係は1対N(Nは自然数)となる。たとえば、区分体系定義テーブル1−8の「翻訳ID」(1−8a参照)は、区分値定義テーブル1−9およびデータ項目定義テーブル1−1においてそれぞれ参照されている(1−9aおよび1−1a参照)。
このように、定義体情報を構成する各定義テーブル(1−1〜1−9)は、図13の矢印で示した関係を有しているので、各テーブルにおいてそれぞれ矛盾したデータ定義がされた場合には、かかる矛盾を容易に検出することができる。さらに、矛盾したデータ定義を受け付けないようにすることも可能である。
各テーブル間の関係についての説明を続ける。画面構成項目定義テーブル1−3は、データ項目定義テーブル1−1の「項目ID」(1−1a参照)と、画面タイプ定義テーブル1−2の「画面ID」(1−2a参照)とを参照している(1−3a参照)。また、画面間遷移定義テーブル1−4は、画面タイプ定義テーブル1−2の「画面ID」(1−2a参照)を「画面ID」および「次画面ID」として参照しており、アクタ定義テーブル1−5の「アクタコード」(1−5a参照)を「アクタ」として参照している。そして、ワークフロー定義テーブル1−7は、アクタ定義テーブル1−5の「アクタコード」(1−5a参照)を「申請者アクタ」および「現在のアクタ」として参照している。
なお、図13に示した各テーブルおよび各テーブル間の関係は一例であり、テーブルの種類や数、あるいはテーブル間の関係を限定するものではない。
次に、本実施例2に係る定義体情報に基づいてシステム生産処理部15dが実行するシステム生産処理によって作成される画面の一例について図14を用いて説明する。図14は、実施例2に係る定義体情報に基づいて作成される画面について示す図である。
図14の114a〜114cに示したのは、実施例2に係る定義体情報(図5の105a、図7〜図9)に基づいて作成される画面である。なお、図14の114aは契約入力画面(図7の「名称」が「契約入力」である行、図8の108aおよび図9の109a参照)であり、同じく114bは契約確認画面(図7の「名称」が「契約確認」である行、図8の108bおよび図9の109b参照)である。また、同じく114cは契約承認画面(図7の「名称」が「契約承認」である行、図8の108cおよび図9の109c参照)である。
また、図14の114aに示した契約入力画面では画面構成部品に対する入力が許可されているのに対し、図14の114bおよび114cに示した契約確認画面および契約承認画面では入力が許可されていない。これは、図8に示した画面構成項目定義テーブルにおける「入力フラグ」の項目が、同図の108bおよび108cにおいて全て「0」に定義されていることによるものである。
次に、本実施例2に係る定義体情報に基づいて作成されたデータベーステーブルに登録されるデータ例について図15を用いて説明する。図15は、実施例2に係る定義体情報に基づいて作成されたデータベーステーブルに登録されるデータの一例を示す図である。なお、同図に示す識別コードが「A0000001」である7行のデータが、図14に示した契約入力画面などによって一度に登録されるデータの組を表している。そして、登録されるデータの組にはそれぞれ一意の識別コードが付されていく(たとえば、「A0000002」)。
次に、本実施例2に係る定義体情報に基づいて作成される画面のワークフローについて図16を用いて説明する。図16は、実施例2に係る定義体情報に基づいて作成される画面のワークフローについて示す図である。なお、図16に示す3つの画面(116a〜116c)は、図14に示した3つの画面(114a〜114c)にそれぞれ対応している。また、116aおよび116bの2画面は担当者に、116cの画面は管理者1にそれぞれ割り当てられている(図9および図10参照)。
図16に示すように、担当者が契約入力画面(116a)にデータ入力を行って「確認」ボタンを押下すると、契約入力画面(116b)に画面遷移する。そして、担当者が契約入力画面に表示されたデータ内容に誤りがないことを確認したうえで「申請」ボタンを押下すると、管理者1が使用するPC(パーソナルコンピュータ)などに契約承認画面(116c)がポップアップする。
つづいて、管理者1が契約承認画面に表示されたデータを承認する場合には、「承認ボタン」を押下する。この「承認」ボタンを押下することによって契約承認画面に表示されたデータが承認情報としてデータベーステーブルに登録される。一方、管理者1がデータを承認できないと判断した場合には、「返却」ボタンを押下する。この「返却」ボタンを押下することによって契約承認画面に表示されたデータが承認されなかった旨が担当者に対して通知される。
上述してきたように、本実施例2では定義体情報に複数画面の定義を行うこととした。したがって、本実施例2に係る定義体情報を用いることで、複数画面間の画面遷移および各画面を用いたワークフローを自動作成することができる。また、かかる定義体情報を変更することで、画面遷移やワークフローを容易に変更することができる。
次に、上記した実施例(実施例1〜2)におけるシステム生産処理の処理手順について図17を用いて説明する。図17は、システム生産処理の処理手順を示すフローチャートである。同図に示すように、定義体データ管理部15aが定義体情報を受け付けると(ステップS101)、チェック処理部15bがこの定義体情報の整合性チェックを行う(ステップS102)。
そして、チェック処理部15bが整合性ありと判定した場合には(ステップS103,Yes)、システム情報作成部15cがシステム情報を作成し(ステップS104)、システム生産処理部15dが該当サーバ装置の設定を実行して(ステップS105)処理を終了する。一方、チェック処理部15bが整合性なしと判定した場合には(ステップS103,No)、ステップS101以降の処理を繰り返すことになる。
次に、上記した実施例(実施例1〜2)の変形例について図18を用いて説明する。図18は、各サーバ装置にシステム生産部を配置した場合について示す図である。同図に示すように、本変形例は、アプリケーションサーバやデータベースサーバにシステム生産用データを送信することとし、これらのデータを受信した各装置がシステム生産を行うよう構成したものである。
具体的には、システム生産装置は、テーブル形式の情報である定義体情報の登録を受け付け(図18の(1)参照)、受け付けた定義体情報の整合性などをチェックする(図18の(2)参照)。そして、定義体情報が正常であると判定されたならば、画面作成情報および業務ロジック作成情報をアプリケーションサーバに対して送信する(図18の(3a)参照)とともに、DBテーブル作成情報をデータベースサーバに対して送信する(図18の(3b)参照)。
かかる画面作成情報および業務ロジック作成情報を受信したアプリケーションサーバは、自装置に搭載されたジェネレータ(図2のシステム作成処理部に相当)を介することによって、画面作成情報からJSP(登録商標)を、業務ロジック作成情報からJAVA(登録商標)プログラムおよびデータベース問い合わせ用のSQLを、それぞれ作成する(図18の(4a)および(4b)参照)。
また、システム生産装置からDBテーブル作成情報を受信したデータベースサーバは、自装置に搭載されたジェネレータ(図2のシステム作成処理部に相当)を介することによって、DBテーブル作成情報からデータベーステーブル作成用のSQLを作成する(図18の(4c)参照)。
なお、上記した各実施例では、本発明を実現するシステム生産装置を機能面から説明したが、システム生産装置の各機能はPC(パーソナルコンピュータ)やワークステーションなどのコンピュータにプログラムを実行させることによって実現することもできる。
すなわち、上述した各種の処理手順は、あらかじめ用意されたプログラムをコンピュータ上で実行することによって実現することができる。そして、これらのプログラムは、インターネットなどのネットワークを介して配布することができる。さらに、これらのプログラムは、ハードディスク、フレキシブルディスク(FD)、CD−ROM、MO、DVDなどのコンピュータで読み取り可能な記録媒体に記録され、コンピュータによって記録媒体から読み出されることによって実行することもできる。
つまり、例を挙げれば、各実施例に示したシステム生産装置用プログラムを格納したCD−ROMを配布し、このCD−ROMに格納されたプログラムを各コンピュータが読み出して実行するようにしてもよい。そして、このシステム生産装置用プログラムを図1などに示したアプリケーションサーバやデータベースサーバにインストールすることとすれば、アプリケーションサーバやデータベースサーバがシステム生産装置としての機能を併せ持つことができる。
以上のように、本発明に係るシステム生産方法、システム生産システム、システム生産プログラムおよびシステム生産に用いられる定義体情報のデータ構造は、データベースを用いたシステムの一括生産に有用であり、特に、三層アーキテクチャなど多階層のシステム構造を有するシステムの生産に適している。また、本発明の好適な適用対象としては、長期的に使用されるなかで細々とした仕様変更をすることが多い生産管理、営業管理、購買、勘定系、商品・原料のマスタ管理などがあるが、もちろん、本発明の適用対象がこれらに限定されるものではない。
本発明に係るシステム生産手法の概要を示す図である。
実施例1に係るシステム生産装置の構成を示す機能ブロック図である。
定義体情報を構成するテーブル群の一例を示す図である。
図3に示した定義体情報に基づいて作成される成果物について示す図である。
図3に示した定義体情報に新規項目を追加する場合の一例を示す図である。
図5に示した定義体情報に基づいて作成される成果物について示す図である。
実施例2に係る定義体情報に含まれる画面タイプ定義テーブルの一例を示す図である。
画面構成項目定義テーブルの一例を示す図である。
画面間遷移定義テーブルの一例を示す図である。
権限定義テーブルの一例を示す図である。
ユーザ定義テーブルの一例を示す図である。
ワークフロー定義テーブルの一例を示す図である。
実施例2に係る定義体情報に含まれる各テーブル間の関係を示す図である。
実施例2に係る定義体情報に基づいて作成される画面について示す図である。
実施例2に係る定義体情報に基づいて作成されたデータベーステーブルに登録されるデータの一例を示す図である。
実施例2に係る定義体情報に基づいて作成される画面のワークフローについて示す図である。
システム生産処理の処理手順を示すフローチャートである。
各サーバ装置にシステム生産部を配置した場合について示す図である。
符号の説明
10 システム生産装置
11 入力部
12 出力部
13 I/F部
14 記憶部
14a 定義体データ
14b 画面作成情報
14c 業務ロジック作成情報
14d DBテーブル作成情報
15 制御部
15a 定義体データ管理部
15b チェック処理部
15c システム情報作成部
15d システム生産処理部
103a、1−1 データ項目定義テーブル
103b、1−2 画面タイプ定義テーブル
103c、1−3 画面構成項目定義テーブル
103d、1−4 画面間遷移定義テーブル
1−5 アクタ(権限)定義テーブル
1−6 ユーザ定義テーブル
1−7 ワークフロー定義テーブル
1−8 区分体系定義テーブル
1−9 区分値定義テーブル