(57)【特許請求の範囲】
【請求項１】
データベースを格納するデータベース装置に接続されるアプリケーションサーバシステムであって、前記データベースのレコードを構成する各項目に対応するデータ項目と、前記データ項目を参照するために用いられる項目名とは関連付けられており、前記アプリケーションサーバシステムは、前記データ項目を使用する画面を表示するクライアント装置にさらに接続されており、
前記クライアント装置から、前記画面を表示する要求の入力を受け付ける入力手段と、
前記画面における前記データ項目の表示のために前記項目名を使用してコーディングされたプログラムと、前記項目ごとに規定される項目オブジェクトとを格納する記憶手段とを備え、
前記項目オブジェクトは、前記データ項目の属性と、前記項目名に対応するデータ項目を操作するためのメソッドに対応するメソッドプログラムコードとを含み、
前記属性は、前記項目名と、前記画面に表示される項目名称とを含み、
前記プログラムは、前記クライアント装置において前記画面を表示するためのソースを構成する部品プログラムを含み、前記データ項目の属性と、前記部品プログラムとは、分離して規定されており、
前記プログラムと、前記項目オブジェクトに対応する処理とを実行する演算手段を備え、
前記演算手段は、
前記クライアント装置からの前記要求に基づいて、前記画面の表示に使用されるデータ項目を特定する項目名を前記部品プログラムに与える手段と、
前記項目名に基づいて前記部品プログラムを実行することにより、前記データ項目に対応する項目オブジェクトを検索する検索手段と、
前記部品プログラムを実行することにより、前記検索手段により検索された項目オブジェクトに含まれる前記項目名称と前記メソッドプログラムコードとを取得する取得手段と、
前記取得手段により取得された前記項目名称および前記メソッドプログラムコードを用いて前記部品プログラムを実行することにより、前記項目名称を含む画面を表示するための前記ソースを生成する生成手段とを含み、
前記クライアント装置に対して前記生成手段により生成されたソースを送信する送信手段をさらに備える、アプリケーションサーバシステム。
【請求項２】
前記演算手段は、
前記クライアント装置からの情報を取得するセッション変数取得手段と、
前記クライアント装置から送信されたデータを取得するデータ取得手段と、
前記データ取得手段により取得されたデータに基づいて、前記データベースにアクセスするためのアクセス手段とをさらに含む、請求項１に記載のアプリケーションサーバシステム。
【請求項３】
前記入力手段は、前記クライアント装置において入力された更新データの入力をさらに受け付け、
前記演算手段は、前記更新データに基づいて、前記データベースに格納されているデータ項目を更新する更新手段をさらに含む、請求項１または２に記載のアプリケーションサーバシステム。
【請求項４】
前記属性は、前記データ項目のデータ型をさらに含み、
前記メソッドは、前記データ型に基づいて前記データ項目のエラーチェックを行なうためロジックを含む、請求項１〜３のいずれかに記載のアプリケーションサーバシステム。
【請求項５】
前記項目オブジェクトのデータ定義は、前記テータベースのデータ定義に基づいている、請求項１〜４のいずれかに記載のアプリケーションサーバシステム。
【請求項６】
前記生成手段は、タグ言語に基づいて前記ソースを生成する、請求項１〜５のいずれかに記載のアプリケーションサーバシステム。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は、アプリケーションプログラムの開発および実行方法の改善に関し、特に、いわゆるオブジェクト指向プログラミングにおいて、プログラム間で共用できる部分を大幅に拡大するプログラム開発環境および実行環境の改善に関する。
【０００２】
【従来の技術】
従来から、コンピュータを用いたシステム開発においては、開発コストの削減、納期の短縮、品質向上が重要な目標となっている。そのため、たとえば手順中心の設計手法からデータを中心とした設計手法への転換、ＲＡＤ（rapid application development）開発手法の導入、プログラムの部品化などが試みられ、一定の効果を上げている。
【０００３】
たとえばデータ中心設計開発手法の導入によりかなりの生産性の向上が見られた。またＲＡＤ開発手法では、ユーザの要求に合わせてプロトタイピングを行ない、その結果によりさらにユーザの要求を確認してプロトタイピングの修正を行なう、というように開発サイクルを短くすることができる。その結果、ＲＡＤ開発手法を導入したシステムでは、主として外部設計、詳細設計の期間短縮、コスト削減を達成することができた。その結果、プログラム作成のフェーズが、システム開発全体で占める割合が相対的に大きくなって来ている。
【０００４】
また、最近では、企業の基幹システムの開発プラットフォームにイントラネットを採用するケースが多くなっている。そうした基幹システムには、アプリケーションサーバを採用してシステム構築を行なうのが、ネットワーク化された企業では効率的である。典型的には、アプリケーションサーバのシステム開発では、ＨＴＭＬ（HyperText Markup Language）を拡張したタグ言語が用いられる。そうしたタグ言語は、習得が容易であり、イントラネットの開発ツールとして高い生産性を有するものとして評価されている。
【０００５】
しかし、企業を取り巻く環境が一層厳しくなるにつれ、システム開発に対する要求も厳しくなっている。具体的には、より企業のビジネスサイクルが短縮化してきたため、納期の一層の短縮化が求められ、またコストの面でもより低コストで製品を提供できる企業が有利となってきている。
【０００６】
そこで、前述のようにシステム開発においてプログラム作成のフェースの占める割合いが相対的に大きくなっていることから、この部分の生産性をさらに向上させることが重要である。そのために最も効率的と思われるのは、プログラムの部品化の促進である。
【０００７】
プログラムの部品化は、システム開発に要する工数を引き下げ、その結果システム開発に要する期間の短縮と、そのために要する費用の削減との両方の面でシステム開発の競争力強化に貢献する。また十分に信頼性のおけるプログラムのみを部品化することで、システムの品質向上にも貢献できる。したがって、プログラムの部品化を如何に効率的に行えるか、そしてそのように準備された部品を如何に効率的に組み合わせてアプリケーションプログラムを構築するかが重要である。
【０００８】
しかし、従来イントラネットシステムの開発に用いられていたタグ言語では、こうした部品化の機能が弱い。そのため従来のタグ言語をそのまま用いる限り、生産性の向上はあまり望めないことが明白となっている。
【０００９】
図３２に一般的な、データベース（ＤＢ）を利用したイントラネットのシステム構成図を示す。図３２を参照して、一般的なイントラネット６００は、ネットワーク６１０を介して互いにＨＴＴＰと呼ばれるプロトコルで通信可能なアプリケーションサーバ６１２、ＤＢサーバ６１４、および複数個のクライアントＰＣ６１６を含む。なお「ＨＴＴＰ」はＨｙｐｅｒ  Ｔｅｘｔ  Ｔｒａｎｓｆｅｒ  Ｐｒｏｔｏｃｏｌの省略形である。
【００１０】
クライアントＰＣ６１６上では一般的なブラウザ６３０が動作する。
ＤＢサーバ６１４ではＲＤＢＭＳ６２２が稼動している。
【００１１】
アプリケーションサーバ６１２上ではＷＷＷサーバ６１８が稼動している。「ＷＷＷ」はＷｏｒｌｄ  Ｗｉｄｅ  Ｗｅｂの省略形である。ＷＷＷサーバ６１８の実体はＪａｖａサーブレットエンジン６２０である。Ｊａｖａサーブレットエンジン６２０は、ネットワーク６１０を介してクライアントＰＣ６１６のブラウザ６３０から与えられる要求に応じてＲＤＢＭＳ６２２をアクセスするための画面を形成するための情報（ＨＴＭＬソース）をブラウザ６３０に与える。ブラウザ６３０はこの画面を表示し、ユーザによって入力された情報をＪａｖａサーブレットエンジン６２０に返す。Ｊａｖａサーブレットエンジン６２０は、与えられた情報にしたがってＲＤＢＭＳ６２２をアクセスし、結果を表示するためのＨＴＭＬソースをブラウザ６３０に返す。ブラウザ６３０ではこの結果を表示することにより、ユーザの要求に答える。
【００１２】
こうして、イントラネット６００では、アプリケーションサーバ６１２上で稼動するＷＷＷサーバ６１８によって複数個のクライアントＰＣ６１６からの要求を処理し、結果を各クライアント上のブラウザに返すことでＲＤＢＭＳ６２２を用いた業務処理を行なっていく。
【００１３】
【発明が解決しようとする課題】
しかし、前述したとおりこうしたシステムにおいてＪａｖａサーブレットエンジン６２０を用いたシステムを開発するために重要なプログラムの部品化およびその再利用は、従来のタグ言語を用いている限り限界に達しているように思われる。従来のプログラム言語では、部品化の対象はアプリケーションから独立して切り出せる部分である。そのため、業務ロジックを含むようなプログラムは部品化することができなかった。たとえば、システムの部品化は全体の２割程度に留まっていた。
【００１４】
特に、企業の基幹業務システムではデータベースを取扱うことになるが、データベースの各項目にはそれぞれデータベース固有の名称が与えられている。そのため、データベースを取扱うプログラム内にそうした固有の名称が埋込まれている。業務が異なり、データベースが変わるとそうした名称は変わる。そのため、あるシステムで作成したプログラムを他のシステムの開発において再利用することは困難である。データベースの各項目を処理するプログラムを部品化することができれば、部品化およびその再利用がすすみ、プログラム開発の効率が向上すると思われる。
【００１６】
この発明の目的は、データベースの各項目を処理するためのプログラムの部品化およびその再利用をより効率的に行なうことができるアプリケーションサーバシステムを提供することである。
【００１７】
【課題を解決するための手段】
この発明のある局面に従うアプリケーションサーバシステムは、データベースを格納するデータベース装置に接続されるアプリケーションサーバシステムであって、データベースのレコードを構成する各項目に対応するデータ項目と、データ項目を参照するために用いられる項目名とは関連付けられており、アプリケーションサーバシステムは、データ項目を使用する画面を表示するクライアント装置にさらに接続されており、クライアント装置から、画面を表示する要求の入力を受け付ける入力手段と、画面におけるデータ項目の表示のために項目名を使用してコーディングされたプログラムと、項目ごとに規定される項目オブジェクトとを格納する記憶手段とを備え、項目オブジェクトは、データ項目の属性と、項目名に対応するデータ項目を操作するためのメソッドに対応するメソッドプログラムコードとを含み、属性は、項目名と、画面に表示される項目名称とを含み、プログラムは、クライアント装置において画面を表示するためのソースを構成する部品プログラムを含み、プログラムと、項目オブジェクトに対応する処理とを実行する演算手段を備え、演算手段は、プログラムを実行することにより、要求に基づいて、画面の表示に使用されるデータ項目を特定する項目名を部品プログラムに与える手段と、項目名に基づいて部品プログラムを実行することにより、データ項目に対応する項目オブジェクトを検索する検索手段と、部品プログラムを実行することにより、検索手段により検索された項目オブジェクトに含まれる項目名称とメソッドプログラムコードとを取得する取得手段と、取得手段により取得された項目名称およびメソッドプログラムコードを用いて部品プログラムを実行することにより、項目名称を含む画面を表示するためのソースを生成する生成手段とを含み、クライアント装置に対して生成手段により生成されたソースを送信する送信手段をさらに備える。
【００１９】
好ましくは、演算手段は、クライアント装置からの情報を取得するセッション変数取得手段と、クライアント装置から送信されたデータを取得するデータ取得手段と、データ取得手段により取得されたデータに基づいて、データベースにアクセスするためのアクセス手段とをさらに含む。
【００２１】
好ましくは、入力手段は、クライアント装置において入力された更新データの入力をさらに受け付け、演算手段は、更新データに基づいて、データベースに格納されているデータ項目を更新する更新手段をさらに含む。
【００２３】
好ましくは、属性は、データ項目のデータ型をさらに含み、メソッドは、データ型に基づいてデータ項目のエラーチェックを行なうためロジックを含む。
【００２５】
好ましくは、項目オブジェクトのデータ定義は、テータベースのデータ定義に基づいている。
【００２７】
好ましくは、生成手段は、項目オブジェクトの修正のための画面を表示するソースを生成する。
【００２９】
さらに好ましくは、生成手段は、タグ言語に基づいてソースを生成する。
【００４３】
【発明の実施の形態】
従来、応答速度が遅いため実用化が進まなかったＪａｖａ言語は、Ｊａｖａ  ＶＭ（Ｖｉｒｔｕａｌ  Ｍａｃｈｉｎｅ）をサーバ側で動かすサーブレット（Ｓｅｒｖｌｅｔ）の形態で米国を中心にその使用が広がりつつ有る。Ｊａｖａ言語は、以下の特徴を有している。
【００４４】
（１）  幅広いプラットフォームで動作し、次世代ＯＳ（Ｏｐｅｒａｔｉｎｇｓｙｓｔｅｍ）として期待されるＬｉｎｕｘへの対応も容易である。
【００４５】
（２）  多くのベンダが共通のＡＰＩ（Ａｐｐｌｉｃａｔｉｏｎ  Ｐｒｏｇｒａｍｍｉｎｇ  Ｉｎｔｅｒｆａｃｅ）でツールを提供しており、１社のみのツールベンダに依存することがない。
【００４６】
（３）  オブジェクト指向言語であり差分プログラミングなど、プログラムの再利用の仕組を持っている。
【００４７】
以上のようにＪａｖａ言語は本発明の目的と合致した特性を持っているため、本実施の形態のシステムではＪａｖａ言語を採用することとした。ただし、本発明はＪａｖａ言語を用いたシステムのみに適用可能なわけではなく、オブジェクト指向言語であればどのようなプログラム言語を用いてもよい。たとえばＣ＋＋、オブジェクトパスカルなどである。
【００４８】
そして、本発明では、オブジェクト指向言語におけるプログラム開発およびプログラム実行の上で特徴的な「オブジェクト」として、データベースのレコードを構成する各項目ごとに規定される、「項目オブジェクト」と呼ぶものを用いることとした。項目オブジェクトの内容の詳細については後述することとして、ここでは項目オブジェクトが従来は考えられていなかったもので本発明において新規なものであり、また項目オブジェクトをプログラム開発に用いることによりデータベース操作のためのプログラムの部品化が大きく促進されたことを指摘しておく。
【００４９】
Ｊａｖａ言語はオブジェクト指向言語であり、部品とフレームワークとの２つの側面でプログラムの再利用が可能である。
【００５０】
ここで、部品とは従来から行なわれている手法と同様のものであり、複数のプログラム中で共通する部分を抜き出し、他のプログラムから呼出して再利用するものである。一般的に部品は業務ロジックからは独立したものであることが多い。
【００５１】
一方、フレームワークとは、メインルーチンや業務ロジックを含むプログラムの集まりである。たとえば、以下に説明する受注フレームワークは、一般的な受注を実装しており、そのまま利用することも、差分プログラミングによって独自の機能を追加して再利用することもできる。本発明では、一方で項目オブジェクトを導入してデータベース固有の名称などを抽象化し、それによって業務プログラムに共通する共通のロジックとして実装されるべき部分をフレームワークとして構築することが可能となった。そのため、本発明によれば従来の部品化の範囲を超えて、より広い範囲でプログラムの再利用が可能になる。
【００５２】
図１に、本発明のシステムを開発するためのパーソナルコンピュータの外観を示す。以下に説明するようにこのパーソナルコンピュータは一般的な構成のものでよい。なお、本発明にしたがって開発されたプログラムによって実現されるアプリケーションサーバが動作するコンピュータも一般的なものでよく、図１に示されるものと同様なものでよい。
【００５３】
図１を参照して、このコンピュータシステムは、ＣＤ−ＲＯＭ（Compact Disc Read-Only Memory）ドライブ１１０およびＦＤ（Flexible Disk）ドライブ１１２を備えたコンピュータ１００と、ディスプレイ１０２と、プリンタ１０４と、キーボード１０６と、マウス１０８とを含む。
【００５４】
図２に、このコンピュータの構成をブロック図形式で示す。図２に示されるようにこのコンピュータ１００は、ＣＤ−ＲＯＭドライブ１１０およびＦＤドライブ１１２に加えて、それぞれバス１２６に接続されたＣＰＵ（Central Processing Unit）１１６と、オペレーティングシステムのブートアッププログラムなどを記憶したＲＯＭ（Read Only Memory)１１８と、実行されるプログラムをロードするための、およびプログラム実行中のデータを記憶するためのＲＡＭ（Random Access Memory）１２０と、作成されたプログラムなどを不揮発的に記憶するためのハードディスク１１４と、このコンピュータ１００をネットワーク１３２に接続するためのネットワークインタフェース１３０とを含んでいる。ＣＤ−ＲＯＭドライブ１１０にはＣＤ−ＲＯＭ１２２が装着される。ＦＤドライブ１１２にはＦＤ１２４が装着される。
【００５５】
既に述べたようにこのプログラム開発システムは、コンピュータハードウェアと、ＣＰＵ１１６により実行されるソフトウェアとにより実現される。一般的にこうしたソフトウェアは、ＣＤ−ＲＯＭ１２２、ＦＤ１２４などの記憶媒体に格納されて流通し、ＣＤ−ＲＯＭドライブ１１０またはＦＤドライブ１１２などにより記憶媒体から読取られてハードディスク１１４に一旦格納される。さらにハードディスク１１４からＲＡＭ１２０に読出されてＣＰＵ１１６により実行される。図１および図２に示したコンピュータのハードウェア自体は一般的なものである。したがって、本発明の最も本質的な部分はＣＤ−ＲＯＭ１２２、ＦＤ１２４、ハードディスク１１４などの記憶媒体に記憶されたソフトウェアである。
【００５６】
なお図１および図２に示したコンピュータ自体の動作は周知であるので、ここではその詳細な説明は繰返さない。
【００５７】
また、上記したコンピュータと同様のコンピュータを、アプリケーションサーバとして動作させることも当然考えられる。その場合の上記した各構成要素の役割も上記したものと同様である。
【００５８】
［Ｊａｖａ  フレームワークの検討］
図３２に示す一般的なイントラネットでは、ブラウザ６３０とアプリケーションサーバ６１２との間ではＨＴＴＰプロトコルが使用されている。ＨＴＴＰプロトコルはセッションレス（ステートレス）のプロトコルである。ブラウザ６３０に表示される画面はＨＴＭＬで構成される。ＨＴＴＰおよびＨＴＭＬは情報を閲覧するために開発された仕様であり、基幹系システムを構築する場合には生産性を悪化させる要因となることが分かった。
【００５９】
イントラネットで使用するＨＴＴＰプロトコルがセッションレスであるため、ブラウザ６３０とアプリケーションサーバ６１２との間の通信は毎回切断されている。しかし、基幹システムではログインしたユーザ情報をブラウザ６３０で表示されるページ間で引継ぐ必要があり、何らかのセッション管理の仕組みを作り込む必要がある。
【００６０】
また、セッションレスであるがために、ブラウザ６３０に表示される画面の間での遷移の順番が保証されない。そのため、ユーザの側からＵＲＬ（Ｕｎｉｆｏｒｍ  Ｒｅｓｏｕｒｃｅ  Ｌｏｃａｔｏｒ）を指定して、本来であれば一連の流れの途中で表示されるべき画面に直接アクセスしたり、アクセス権限のない画面を表示させたりすることができる可能性がある。そうした事態を防止するために、各プログラムでは、ブラウザ６３０に表示される画面が、設計時に想定した遷移の順番となっているか否かをチェックしたり、表示される画面が所定の権限に基づいてアクセスされたものかどうかをチェックしたりする必要がある。
【００６１】
その他にも、ユーザの操作ミスで不正なデータがアプリケーションサーバ６１２に送信されてくることがある。たとえば最終的にデータをサーバにおくるための指示をするために準備されたボタン（「Ｓｕｂｍｉｔ」ボタンなどと呼ばれる。）が誤って二度押されたりすると、データが二重にサーバに送信されることになる。このため、何らかの手当てをしないとサーバにおいて当該データが二重に処理されたりする可能性があるが、そうした誤動作を防止するための仕組みも必要となる。
【００６２】
さらに、通常のクライアント＆サーバシステムでは、ＧＵＩ（Ｇｒａｐｈｉｃａｌ  Ｕｓｅｒ  Ｉｎｔｅｒｆａｃｅ）によって画面設計を行なうことができるが、イントラネットシステムでは、画面表示のためのＨＴＭＬを出力するためのコーディングを手作業で行なわなければならない。すなわち、イントラネットシステムでは、画面で使用するデータ項目全てに対して、項目名称、入力形式（テキストボックス、ラジオボタン等）、および入力桁数等の指定などをソースコード中で行なわなければならない。そのため、通常のＧＵＩを用いたシステム開発と比較して工数が増えることが避けられない。また、ＨＴＭＬ出力のコードと業務ロジックのコードとが混在することが多く、プログラムの部品化をさまたげる要因となっている。
【００６３】
これらの要因を考慮しながらプログラムを作成すると、生産性の大きな低下が避けられない。それのみでなく、プログラム作成中での考慮もれなどによる品質の低下も懸念される。そこで、フレームワークの内部でこれらの問題を解決し、プログラマーが特に意識しなくても高品質のプログラムが容易に作成できるように、フレームワークの構築を行なうこととした。
【００６４】
［フレームワークに必要な機能］
フレームワークは、それ以後開発される全てのシステムのベースとなる可能性が高い。したがって一旦フレームワークをリリースした後に大きな変更を行なうような事態はできるだけ避ける必要がある。今後開発されるいかなるシステムに対しても対応できるように、フレームワークが持つべき機能を検討した結果、下記の機能をフレームワークとして実装することととした。
【００６５】
（１）  イントラネット固有の問題の隠ぺい
既に述べたようなイントラネットシステムでの生産性悪化の要因を隠ぺいし、プログラマーが特に意識することなくプログラムの開発が行えるようにする。
【００６６】
（２）  多国語対応
ビジネスのグローバル化に伴い、ある企業が海外に子会社を持つケースが増加している。そうした場合にも、同一システムを国内と海外との双方で使用することが望ましいが、使用する言語の問題がある。通常のアプローチとしては、最初に日本語版のプログラムを作成したのち、そのプログラムのうち必要な部分（画面に表示される項目名称、メッセージなど）を外国語（たとえば英語）に翻訳することであろう。しかしその場合には、実質的に一つのプログラムを二つの別々のプログラムで実現することとなる。そのようにプログラムを二重に持つのはプログラムの保守性を悪化させることは明らかである。そのため、プログラムの保守性を悪化させることなく多国語に対応できるようなプログラム開発の手法が望まれる。
【００６７】
そこで本システムでは、一つのシステム中に予め日本語のみならず外国語の資源も組込んでおき、プログラムの実行時のパラメータ指定によって言語を切り替える仕組みを実装することとした。こうした機能は、後述するように項目オブジェクトを使用することにより簡単に実現することができる。
【００６８】
このような仕組みをフレームワークとして実装することにより、たとえばプログラム開発の人件費が安い海外でプログラムを開発し、それを日本語化することも容易に行える。
【００６９】
（３）  項目名称のカスタマイズ
ある企業が自社のために開発したシステムをパッケージ化し外販することはよくあることである。しかしその場合、たとえばシステム中で使用されるデータベースの項目名称などを、購入企業での使用形態に合わせてカスタマイズしたい、というニーズが強い。そこで、本システムではそうしたニーズを満足させるべく、フレームワークにそのための機能を実装することとした。この機能も項目オブジェクトを使用すると簡単に実現することができる。
【００７０】
［プログラム再利用の形態］
プログラムの再利用を考えた場合、プログラム全体をそのまま利用するもの、データ加工のための単純なサブルーチンレベルで再利用するもの、など様々な粒度のものがある。そこで、プログラムの再利用の形態としてどのようなものがあるかを検討したところ、以下の４つが主要なものとして分類された。
【００７１】
（１）  部品
部品はプログラム再利用の最小単位である。部品は業務アプリケーションによって呼出され使用される。
【００７２】
（２）  プログラムパターン
プログラムパターンとは、部品を組み合わせた業務ロジックを含まないプログラムのことをいう。プログラムパターン中で使用するデータ項目などはパラメータで与えることができる。基本テーブルのメンテナンスなどに使用することができる。
【００７３】
（３）  フレームワーク
フレームワークとは部品およびプログラムパターンを組合せ、基本的な業務ロジックを組込んだ、再利用可能なプログラムの集合体のことをいう。フレームワーク中のプログラムは、使用するシステムにあわせて差分プログラムを用いることにより、実際の業務に適応させながら再利用することができる。
【００７４】
（４）  パッケージ
パッケージとは、システム全体をそのまま再利用する再利用形態である。
【００７５】
本実施例を実現するにあたっては、まず部品を開発し、プログラムパターン、フレームワークの順に開発を進めることとした。その結果、後に詳述する項目オブジェクトという概念に到達したのである。以下、項目オブジェクトを利用したイントラネットシステム構築の手法、およびそのようなイントラネットシステムの構造と動作とについて述べる。
【００７６】
［システム開発の手順］
図３を参照して、本システムの開発手順は以下のとおりである。まず、処理対象となるデータベースの構成に基づいて項目オブジェクトを作成する（１４０）。そして、そのようにして作成された項目オブジェクトを利用してアプリケーションプログラムの作成を行なう（１４２）。次に、そのように作成されたアプリケーションを実行することによりイントラネットシステムのアプリケーションサーバを実現する（１４４）。
【００７７】
［項目オブジェクト］
図４を参照して、項目オブジェクト１５０は、データベースの各項目に対応して設定されるオブジェクトである。項目オブジェクトの例は、受注業務でいえばデータ項目「受注番号」に対応する項目オブジェクト１５０Ａである。この項目オブジェクト１５０Ａは、プログラム開発過程ではオブジェクトクラスであって、プログラム実行時にはこの項目オブジェクトのインスタンスが形成されてプログラム実行に利用される。
【００７８】
項目オブジェクト１５０はオブジェクトクラスであるので、図４に示すとおり、項目名（たとえば「OrderNum」）の他に、プロパティとして項目名称（日本語名、英語名、他の言語による名称など）、データ長、データ型（数値型、ストリング型、など）、入力形式（テキストボックス、ラジオボタン、チェックボックス、プルダウンリスト、プルダウンメニュー、コンボボックス、スライダなど）、対応ＤＢ列名など、データ項目を抽象化した場合にそなえておくべき属性一般、および入力されたデータが正しいか否か（たとえばデータ型が数値型のときに、入力されたデータが数値であるか否か、桁数はデータ長以内か、など）のチェックを行なうためのプログラムコードをメソッドの形で備えている。
【００７９】
項目オブジェクトの備える属性、メソッドなどについて表１に示す。
【００８０】
【表１】
0004136271.tif 000002
【００８１】
表１において「項目名」とは、プログラムのコーディング中でこのデータ項目を参照するために用いられる名称である。通常はＤＢ中の、この項目オブジェクトに対応する列名を使用し、アルファベットと一部の記号のみからなる。
【００８２】
「項目名称」とは、プログラム実行時に画面に表示される名称のことをいう。本実施の形態では、項目名称として５通りを設定することが可能である。したがって項目名を画面表示に使用する場合もあわせると、６通りの表示を切替えて項目名称を表示することができる。
【００８３】
表１に示されるその他の要素については、当業者にはその意味は明白であろうから、ここではこれ以上の説明は行なわない。
【００８４】
［ＤＢ定義からの項目オブジェクト定義の抽出］
項目オブジェクトは、本実施の形態のプログラム開発システムではＪａｖａ言語のクラス定義のソースプログラムの形でテキスト形式で準備される。項目オブジェクトはデータベースと深い関係があるので、データベース定義からそのまま項目オブジェクトのデータ定義を行なうようにすると便利である。
【００８５】
図５に、そのようなプログラム開発システムの簡単なシステムブロック図を示す。実際にはこのシステムが図１および図２に示すような一般的なパーソナルコンピュータによって実現可能であることは言うまでもない。
【００８６】
図５を参照して、このシステムは、テキスト形式で予め準備されたＤＢ定義情報１６０からデータベース１６６を作成したり、ＤＢ定義情報１６０からデータベース１６６の各項目に対応する項目オブジェクトの定義の原型であるデータ定義１６８をテキスト形式で出力したり、ディスプレイ１０２、キーボード１０６およびマウス１０８を用いたインタラクティブな処理によりデータ定義１６８の内容を修正したり、修正されたデータ定義１６８から項目オブジェクトのクラス定義のためのＪａｖａソース１６４のファイルを出力したりする処理を行なうＤＢ作成ツール１６２からなる。
【００８７】
ＤＢ定義情報１６０の内容の一例を図６に示す。またデータ定義１６８の一例を図７に示す。図７に示されるデータ定義１６８は、図６のＤＢ定義情報１６０のうち、「／Ｒｅｃｏｒｄ」文の直後の「受注番号」で始まる行から抽出された情報に基づいて作成され、さらに後にプログラマーによって必要な項目が補充されたものである。各行は、属性を示すキーワード（たとえば「／ＬＡＮＧ」、「／ＩＮＰＵＴＴＹＰＥ」など）と、そのキーワードに対応する属性内容とからなっている。このデータ定義１６８の内容にさらにデータチェックなどのメソッドに相当するプログラムコーディングの原形を追加する処理もこのときに行なわれる。
【００８８】
ＤＢ定義情報１６０からデータ定義１６８を作成することにより、項目オブジェクト作成のための工数を最小限に抑えることができる。
【００８９】
図８に、ＤＢ定義情報１６０からデータ定義１６８を作成するプログラムの概略フローチャートを示す。図８を参照して、まず最初にプログラマーにより指定されたＤＢ定義ファイルをオープンする（１８０）。つぎにこのファイルの１行目を読む（１８２）。その行の内容が「／ＲＥＣＯＲＤ」か否かを判定し（１８４）、読込んだ１行の内容が「／ＲＥＣＯＲＤ」となるまでステップ１８２および１８４の処理を繰返す。
【００９０】
「／ＲＥＣＯＲＤ」の一行を読込むと、それ以後はＤＢ定義の一行ごとにデータ定義１６８を作成し出力する処理を繰返す。具体的には、まずＤＢ定義情報１６０の次の１行を読み（１８６）、その行の内容が「／ＥＮＤ」か否かを判定する。「／ＥＮＤ」でなければ、読込んだ１行の内容からデータ定義１６８を作成し、項目オブジェクトファイルとして出力して（１９０）次の行を読込む処理を行なう（１８６）。もし読込んだ１行の内容が「／ＥＮＤ」であれば、ＤＢ定義情報１６０の中の全てのＤＢ項目を処理したということであるから、ＤＢ定義ファイルをクローズし（１９２）処理を終了する。
【００９１】
ステップ１９０での処理はＤＢ定義の書式とデータ定義１６８との書式との対応関係に基づいて定められる。その内容についてはシステムに依存し、かつ当業者には明らかであるのでここではその詳細は述べない。
【００９２】
図５に示されるＤＢ作成ツール１６２の機能のうち、データ定義１６８の内容をインタラクティブに修正する処理について、その操作の面から図９〜図１２を参照して説明する。開発対象のシステムにもよるが、項目オブジェクトの数は数千に達することもあるため、データ定義１６８を効率的に修正することが可能となっていることが望ましい。
【００９３】
図９を参照して、本実施の形態のシステムでは、ＤＢ作成ツール１６２の基本画面２００において、メニュー２０２から生成メニュー２０４を選択することによって表示されるプルダウンメニューの中から、「項目オブジェクト編集」というメニュー項目２０６をポインタ２０８で選択することによりデータ定義１６８の修正を行なう処理が起動される。これにより、図１０に示されるデータ定義選択画面２１０が表示される。
【００９４】
データ定義選択画面２１０の上部には、アルファベットのＡ〜Ｚまでに対応するボタンからなるアルファベット選択ボタン列２１２が表示される。この中のたとえば「Ｕ」に対応するボタン２１４をポインタ２０８で選択することにより、データ定義一覧フィールド２１６にそのアルファベットで始める項目名を有する項目オブジェクトの一覧が表示される。
【００９５】
図１１を参照して、この画面２２０において、データ定義一覧フィールド２１６に表示された項目名のうち、修正対象となる項目に対応するデータ定義（たとえば「ＵｓｅｒＩＤ」に対応するデータ定義フィールド２２２）をポインタ２０８で選択することにより、選択されたデータ定義の内容が項目オブジェクト情報修正画面として表示される。このときの表示の一例を図１２に示す。
【００９６】
図１２を参照して、項目オブジェクト情報修正画面２２４では、選択されたデータ定義に対応する項目オブジェクト情報が一覧表示される。これらの内容を修正した後、更新ボタン２２８を押すことにより、もとのデータ定義ファイルが更新後の情報で上書きされる。
【００９７】
図９〜図１２に示す処理は通常のＧＵＩを用いたプログラム開発ツールで開発することができる。これら画面によって行なわれる処理の内容は簡単なので、これら画面を実現するためのプログラムの詳細はここでは述べない。しかし当業者にはこれら画面を用いてデータ定義ファイルを更新する方法については明らかであろう。
【００９８】
［アプリケーションプログラムの構造］
次に、このようにして準備した項目オブジェクトを用いたアプリケーションの構造について説明する。この説明により、そうしたアプリケーションをどのようにして作成するかについても当業者には明らかとなるであろう。
【００９９】
図１３に、アプリケーションサーバによってクライアントＰＣ上に実現される画面の一例を示す。この例は、ユーザＤＢ（ユーザテーブル）をメンテナンスするためのプログラムである。図１３を参照して、ユーザテーブルメンテナンス画面２３０は、インラインメニュー２４０と、ボタン２４２と、項目名称２４４および項目フィールドとからなる複数の項目別の行からなる入力フォームとを含む。ブラウザによりこの画面を表示するためのＨＴＭＬソースをアプリケーションサーバで作成し、クライアントＰＣに送って表示させ、クライアントＰＣから送信されてくる入力データにしたがってユーザテーブルを更新するのがアプリケーションサーバの機能である。
【０１００】
従来であれば、この画面で主となる入力フォームの部分を、ユーザテーブルメンテナンスとは別のプログラム、たとえば部署登録の画面で再利用することは困難であった。ユーザ登録のプログラムには、ユーザＩＤ、氏名などのようなユーザ登録プログラム特有の項目名称が埋込まれているからである。しかし、項目オブジェクトを導入することにより、プログラムからそうしたデータ項目の属性を分離することができ、フォーム部分を再利用することが可能となった。
【０１０１】
図１４に、このイントラネットシステムのアプリケーションサーバを構成するＷＷＷサーバ２５０のシステム構成を簡単に示す。図１４を参照して、ＷＷＷサーバ２５０は、ネットワーク２５２を介して複数のクライアントＰＣ上で動作するブラウザ２５４、２５６等からのリクエストを処理するためのＪａｖａサーブレットエンジン２６０と、Ｊａｖａサーブレットエンジン２６０を介して与えられるクライアントブラウザからのリクエストを処理するためのメインプログラム２６２と、メインプログラム２６２が各クライアントごとにセッションを維持するために用意するセッション変数２７０、２７２などを格納するセッション変数オブジェクト２６４およびメインプログラム２６２の実行時に参照する項目オブジェクト２８０、２８２などを格納するメモリ空間２６６とを含む。
【０１０２】
メインプログラム２６２は、クライアントに送信される部品を構成するフォーム部品２９０を含んでいる。そして、後述するようにフォーム部品２９０に表示すべきデータ項目をメモリ空間２６６内の項目オブジェクトの中から選択することにより所望のフォームを形成するＨＴＭＬソースが形成され、クライアントＰＣのブラウザに送信される。フォーム部品２９０自体にはデータ項目が埋込まれることがないので、フォーム部品２９０を他のプログラムに再利用することが可能となる。またユーザテーブルメンテナンスのためのプログラムが実装すべき機能（登録、削除、変更など）のロジック部分は他のＤＢテーブルのメンテナンスにも使用可能であり、その場合にはフォーム部品２９０に与える項目オブジェクトを変えればよいので、プログラムの再利用がより効率的に行える。
【０１０３】
ＷＷＷサーバ２５０が実装すべき機能構造を図１５に示す。図１５を参照して、ＷＷＷサーバ２５０は、ブラウザ２５４、２５６からのリクエストによって起動するＪａｖａプログラムからなる。このプログラム（メインプログラム２６２）は、セッション変数２７０からログイン情報や前の画面の情報を取得し、アクセス権限や画面遷移の正統性を検査するためのセッション変数取得部３００と、ブラウザ２５４、２５６などのブラウザから送信されるデータ（例えば入力された受注番号など）を取得するためのＦｏｒｍ／ＵＲＬ変数取得部３０２と、取得されたデータに基づいてＳＱＬ（Ｓｔｒｕｃｔｕｒｅｄ  Ｑｕｅｒｙ  Ｌａｎｇｕａｇｅ）を組み立てるためのＳＱＬ組立部３０４と、組み立てられたＳＱＬを実行してデータベース１６６にアクセスするためのＳＱＬ実行部３０６と、データベース１６６から取得したデータに対して、必要に応じてフォーマット変換などの処理を行なうためのデータ加工部３０８と、こうして得られたデータをＨＴＭＬタグとともにブラウザ２５４、２５６などに送信する処理を行なうＨＴＭＬ出力部３１０と、次回のアクセスのためにセッション変数２７０を保管しておくためのセッション変数の保存部３１２とを含む。
【０１０４】
特定のプログラムと連係するために特別なフォーマットでデータファイルを書出すような処理を行なうプログラムを除けば、大半のプログラムは上記の順序で処理を行なう。図１５に示す各処理単位を基本部品として、必要な数の部品を予め用意すれば、プログラマは自己が作成しようとするプログラムが実現すべき機能に対応する部品を見つけだして組み合わせることで効率的にプログラムを作成することができる。また上記した処理単位全体をフレームワークとして用意することで、必要な業務ロジックを追加するだけでプログラムを完成させることができる。
【０１０５】
［項目オブジェクトを利用した画面出力］
さて、メモリ空間２６６に格納された項目オブジェクトを使用した画面出力（ＨＴＭＬソース出力）の機構の概略を図１６に示す。図１６を参照して、メインプログラム２６２は、フォーム部品２９０に対して画面で使用する項目を特定する情報を与える。フォーム部品２９０は、メモリ空間２６６の中で、メインプログラム２６２から与えられた項目に対応する項目オブジェクトを探し出す。項目オブジェクトには、画面に表示すべきデータ名称、データ長などに関する情報がすべて含まれているので、フォーム部品２９０は項目オブジェクトからこれら情報を取得することにより、ブラウザ２５４、２５６などに与えるべきＨＴＭＬソースを作成することができる。作成されたＨＴＭＬソースをブラウザ２５４、２５６などに送信することにより、図１３に示される画面がクライアントＰＣの上で動作するブラウザにより表示される。
【０１０６】
表示される項目の名称、データ長、データ形式などに関する情報は項目オブジェクトから取得されるので、メインプログラム２６２中にはそれらの情報はコーディングされていない。メインプログラム２６２の一部の例を図１７に示す。図１７を参照して、メインプログラム２６２のプログラム中では、まずパラメータ定義行３２０でこの処理において使用するべき項目オブジェクト名称のリストである定数「ｐ＿ｆｉｅｌｄｓ」を定義しておき、後のロジック中のフォーム部品をコールするＣＡＬＬ命令３２２において、この定数をパラメータとしてフォーム部品に渡している。つまり、業務に直結した項目オブジェクトの指定は、パラメータ定義行３２０に見られるのみである。
【０１０７】
この場合にメインプログラム２６２がフォーム部品２９０に与えるパラメータを図１７に示されるように｛ｕｓｅｒｉｄ，ｕｓｅｒｎａｍｅ，ｆｕｒｉｇａｎａ，．．．｝とすると、これらパラメータを他の項目オブジェクトの名称のリストに変えるだけで、全く同じメインプログラム２６２のロジックとと同じフォーム部品２９０とを用いて、全く別の画面の表示を実現することができる。
【０１０８】
図１８に、フォーム部品を構成するプログラムのロジックをフローチャート形式で示す。与えられたパラメータのうち、最初から順番に１パラメータずつ以下の処理を行なう。すなわち、当該パラメータについて、そのパラメータで指定される項目オブジェクトを参照し、項目名称、データ長などの情報からその項目を入力するためのフォーム部品に相当するＨＴＭＬソースを作成する（３３０）。
【０１０９】
続いて全てのパラメータを処理したか否かを判定し（３３２）、全てのパラメータを処理するまでステップ３３０、３３２の処理を繰返す。
【０１１０】
全てのパラメータを処理したと判定された場合、これまでの処理で作成されたＨＴＭＬソースをブラウザ２５４などに対して出力し、処理を終了する。
【０１１１】
このようにメインプログラムのロジック中には項目特有の情報がコーディングされていない。その結果、メインプログラムを種々の処理において共通に再利用することが可能となった。またフォーム部品２９０自体も項目特有の情報と分離されているので、フォーム部品２９０についても種々の処理において共通に再利用することが可能となった。
【０１１２】
このように、本発明によれば、項目オブジェクトを用いることによりプログラムからユーザインタフェースを分離し、部品化することに成功した。さらに、項目オブジェクト中に当該項目のエラーチェック、ＤＢ更新のためのロジックをメソッドとして実装しておくことで、業務に直結するプログラム部分を部品化することが可能となった。
【０１１３】
なお、項目オブジェクトを実装することで、ＷＷＷサーバ２５０の応答速度が低下する懸念があったので、一度使用した項目オブジェクト（のインスタンス）はメモリー中に常駐するようにし、次のリクエストの処理においても再利用することとした。その結果、項目オブジェクトを利用することによる応答時間の悪化はほとんど見られないか、十分許容範囲内に収まることが確認された。
【０１１４】
［フレームワークの構築］
図１９に基本フレームワークの構造を模式的に示す。図１９を参照して、基本フレームワーク３４０は、セッション変数取得部３４２、権限チェック部３４４、ＤＢコネクション取得部３４６、メイン処理部３４８、ＤＢコネクション返却部３５０およびセッション変数保存部３５２からなる。これらのうち、セッション変数取得部３４２、権限チェック部３４４およびセッション変数保存部３５２は図１５に示したセッション変数取得部３００、セッション変数の保存部３１２などに対応する。ＤＢコネクション取得部３４６およびＤＢコネクション返却部３５０は図示しないデータベースの参照、更新に先立ってＤＢとのコネクションを確立し、処理後にはコネクションをコネクションプールに返却するためのものである。なお、本実施の形態では、ＤＢとのコネクション時間の短縮化を図るために、予め複数個のＤＢコネクションを確立しておき、リクエストに応じてこれらコネクションをそれら要求に割り当て、処理が終了するとコネクションをプールに返却する構成をとっている。
【０１１５】
基本フレームワーク３４０では、メイン処理部３４８以外の部分については予め実装してあるが、メイン処理部３４８の内容については何も実装されていない。開発するプログラム部分３６０は、メイン処理部３４８に対する差分プログラミングにより実装する。そのためプログラマーとしてはセッション管理、コネクション管理の部分について特に意識する必要はない。
【０１１６】
開発するプログラム部分３６０は、フォーム変数取得部３６２、ＳＱＬ組立部３６４、ＳＱＬ実行部３６６、データ加工部３６８およびＨＴＭＬ出力部３７０を含む。これらはそれぞれ、図１５に示すＦｏｒｍ／ＵＲＬ変数取得部３０２、ＳＱＬ組立部３０４、ＳＱＬ実行部３０６、データ加工部３０８およびＨＴＭＬ出力部３１０に相当する。これらの部分についてはいくつかの部品が予め用意されており、プログラマーはその中から必要な部品を選択して使用することができる。その結果、メイン処理のコーディング量を大幅に削減することができる。
【０１１７】
［項目オブジェクトの管理］
既に述べたように、項目オブジェクトはデータベースの項目自体をオブジェクトクラスとして定義し、アプリケーション実行時にインスタンス生成してメモリに常駐するよう構成されている。このとき、多数のリクエストに対して個別に項目オブジェクトのインスタンスを生成していたのでは、メモリが浪費されることになるので、本実施の形態のシステムでは、項目オブジェクト管理用のクラスを設け、このクラスのインスタンスであるオブジェクトによってデータベースの各項目について一つの項目オブジェクトのインスタンスのみを生成し、複数のアプリケーションでこのインスタンスを共通に利用することとしている。
【０１１８】
図２０にこの概念を示す。図２０を参照して、アプリケーションプログラム３８２、３８４などは、項目オブジェクト（たとえば項目オブジェクト３８６）を利用したいときには、項目オブジェクト管理のためのオブジェクト３８０に対して項目オブジェクト３８６の要求を出す。項目オブジェクト管理のためのオブジェクト３８０はこの要求に応答して、項目オブジェクト３８６がメモリ上にあるか否かを調べ、ある場合には項目オブジェクト３８６を要求を出したアプリケーションに対して返す。項目オブジェクト３８６を受けたアプリケーション（たとえばアプリケーションプログラム３８２）は、こうして受取った項目オブジェクト３８６を用いて前述したような処理を実行する。項目オブジェクトの要求を受取ったときに、該当する項目オブジェクトがメモリ上に存在していないときには、項目オブジェクト管理のためのオブジェクト３８０は当該オブジェクトを生成してからその項目オブジェクトをアプリケーションに対して返す。
【０１１９】
なおここで「項目オブジェクトを返す。」という処理は、Ｃ＋＋などでは当該オブジェクトのメモリ上のポインタをアプリケーションに戻り値として返す、ということである。Ｊａｖａの場合にはポインタが隠ぺいされているため、こうした処理は単に「オブジェクトを返す」と呼ばれる。
【０１２０】
図２１を参照して、項目オブジェクト管理のためのオブジェクト３８０が実行する処理について説明する。項目オブジェクト管理のためのオブジェクト３８０は、アプリケーションから項目オブジェクトに関する要求があるか否かを判定し（４００）、要求があるまで待機する。実際の実装形式としては、以下の処理は項目オブジェクト管理のためのオブジェクト３８０が備えている、項目オブジェクトをアプリケーションに返すためのメソッドとなっている。したがってアプリケーションは、自己が必要としている項目オブジェクト名をパラメータとして項目オブジェクト管理のためのオブジェクト３８０のこのメソッドを呼出すだけでよい。
【０１２１】
さて、アプリケーションによって呼出されると（ステップ４００においてＹＥＳ）、要求された項目オブジェクトがメモリ上にあるか否かが判定される（４０２）。実際には、項目オブジェクト管理のためのオブジェクト３８０は生成済みの項目オブジェクトの管理テーブルを維持しており、この管理テーブル内に当該項目オブジェクト名が存在しているときにはメモリ上にその項目オブジェクトがあり、テーブル内に項目オブジェクト名が存在していないときにはその項目オブジェクトはまだインスタンス生成されていないと判定する。
【０１２２】
要求された項目オブジェクトがメモリ上にないと判定された場合、その要求された項目オブジェクトのインスタンスを生成する（４０４）。そしてその項目オブジェクトを管理テーブルに追加する（４０６）。そして処理はステップ４０８に進む。一方ステップ４０２で、要求された項目オブジェクトが既にメモリ上に存在していると判定された場合には直接ステップ４０８に制御が進む。
【０１２３】
ステップ４０８では、こうして生成された項目オブジェクト、または管理テーブル上で見い出された項目オブジェクトを、この項目オブジェクトを要求したアプリケーションに対して返し、再び次の要求を待つ処理（４００）に戻る。
【０１２４】
以上のような制御構造を有するメソッドによって、項目オブジェクト管理のためのオブジェクト３８０の機能が実装されている。
【０１２５】
［部品化の効果］
以上のように本実施の形態のシステム開発環境では、フレームワーク、共通部品、および項目オブジェクトを部品化し、再利用することが可能となった。図２２（１）に示されるように、従来の部品化の手法では、プログラム全体４２０のうち共通部品４２４の部分の比率はかなり低く、アプリケーションごとに個別に作成しなければならない個別プログラム４２２の部分が相対的に大きな比重を示していた。それに対し本発明によれば、部品よりも低い層の部分に項目オブジェクト４３８を実装することにより、各部品からデータ項目に対応した情報およびメソッドを取り除き、項目オブジェクトにまとめて定義することができるようになった。その結果、共通部品４３６の各部品がスリムになり、しかも業務に固有のロジックを各部品で実装する必要が少なくなったため、部品化の対象範囲が広がった。
【０１２６】
また、項目オブジェクト４３８の実装により、アプリケーションプログラムにデータ名称やデータ桁数を記述する必要がなくなった。その結果、アプリケーションプログラムをデータと分離してより抽象化することが可能となり、再利用のためのフレームワーク４３２を準備することが可能となった。その結果、個別にプログラムしなければならない個別プログラム４３４の部分の比重は相対的に小さくなった。
【０１２７】
また、データ定義、データの操作のためのメソッドなどを項目オブジェクトにまとめたため、データ名称、データの桁数、エラーチェック方法などを利用者の要求に応じて変更する場合にも、項目オブジェクトの中の変更で済むことになった。アプリケーションプログラム本体の変更を行なう必要はないため、ユーザ要求の変更に伴うプログラムの変更などによってバグが発生するおそれが少なくなり、品質の向上を図ることが可能となった。ユーザの業務にあわせてデータ名称の変更を行なうことも項目オブジェクトの中で行えるため、カスタマイズが容易になるという効果が得られた。
【０１２８】
さらに、項目オブジェクトに複数種類の項目名称を準備している。たとえば第１の項目名称は日本語、第２の項目名称は英語、などとしておき、プログラム実行時には、与えられたパラメータにしたがって特定の項目名称を選択するようなロジックとしておく。すると、プログラム自体のロジックは全く変更することなく、実行時のパラメータを変えることだけにより、アプリケーションプログラムの言語を容易に切り替えることができる。エラーメッセージなど複数言語での処理が必要な全ての部分について同様の機構を準備しておけば、言語の切替は完全に行えることになる。
【０１２９】
以上のように本実施の形態では、項目オブジェクトという概念を導入し、項目オブジェクトを実装することによりアプリケーションプログラムの構造を変更し、その結果部品化の範囲を拡大することができた。さらにその結果、フレームワークを準備することにより、さらに個別プログラムの量を少なくすることが可能となった。
【０１３０】
［再利用可能なプログラムの作成］
フレームワーク構築のポイントは、プログラムの再利用である。しかし、オブジェクト指向言語の特徴である継承による差分プログラミングにはある欠点がある。それは、継承では元となるプログラムの一部を上書きする新しいプログラムを追加するが、そのためには継承元のプログラムの内部構造を全て理解しなければならないということである。さもないと、上書きした結果、プログラム全体として動作がおかしくなる可能性がある。
【０１３１】
また、継承元のプログラムが修正された場合に、上書きしたプログラムが正常に動作するという保証はない。たとえば上書きされたメソッドの名前が継承元のプログラムにおいて変更された場合には、上書きしたプログラムは正常には動作しなくなるであろう。
【０１３２】
したがって、継承による差分プログラミングは保守性を考慮して適用していく必要がある。その結果、差分プログラミングを、業務内容の改善にあわせて随時メンテナンスしていく必要のなる業務プログラムへ適用することは必ずしも容易ではない。特に、業務プログラムが稼動するシステムではプログラム本数が数百〜数千本となることもある。その場合、作業を行なうシステムエンジニアおよびプログラマーの数も多くなり、継承による差分プログラミングを考慮しながらプログラムの設計・製造を行なうことは、人材の確保の面でも、開発納期を確保する面でも困難である。
【０１３３】
そこで、この実施の形態のシステムではさらに、プログラミングの枠組みは第１の実施の形態で述べたように項目オブジェクトによるものとした上で、さらにプログラムをモジュール化し、必要なモジュールを自由に組み合わせることによってプログラムを開発・変更する機構を採用した。
【０１３４】
［モジュール化構成］
図２３に、このシステムにおける図１３に示す画面の遷移に関する内部構造の全体イメージを示す。図２３を参照して、このシステムでは、メインプログラム４５０から照会モジュール４５２、登録モジュール４５４、更新モジュール４５６および削除モジュール４５８に遷移することができる。各モジュールにはページ処理４６０、４６２、４６４、４６６などが１または複数個準備されており、メインプログラム４５０からページ番号を指定して各モジュールを呼出すことにより、当該モジュールの指定されたページが表示されるようになっている。
【０１３５】
図２４に、本実施の形態において上記したようなページ遷移を実現するためのシステムの内部構造を示す。図２４を参照して、このシステムは、メインプログラム４７０と、照会モジュール４７２と、登録モジュール４７４と、更新モジュール４７６と、削除モジュール４７８と、メインプログラム４７０からパラメータを受取って、指定されたモジュールの指定されたページを表示するように各モジュールを制御するためのコントローラ４８０とを含む。コントローラ４８０もまたその実体はコントローラクラスと呼ばれるクラスのインスタンスである。
【０１３６】
照会モジュール４７２〜削除モジュール４７８はいずれもメインプログラム４７０によって生成されるが、コントローラ４８０もまたメインプログラム４７０によってインスタンス生成される。コントローラ４８０は、対応のメインプログラム４７０によって生成されたモジュール４７２〜４７８が登録される管理テーブルを管理しており、メインプログラム４７０からパラメータを与えられると、以下に説明するような比較的単純なアルゴリズムによって適切なモジュールの適切なページが表示されるような制御を行なう。
【０１３７】
図２５に照会モジュール４７２などの各モジュールの基本構造を示す。こうしたモジュールもそれぞれのクラスのインスタンスとしてプログラム実行時に生成される。図２５に示されるように、たとえば照会モジュール４７２は、メニュー表示文字列、パラメータなどを含む各種のプロパティ４９０と、これらプロパティを用いてメニューにメニュー表示文字列を追加するメソッド、メインプログラム４７０から与えられるパラメータによって当該モジュール内に適切なページがあればそれを表示する処理を行なうページ制御をするメソッド、第１のページ処理メソッド、第２のページ処理メソッドなどを含む１または複数のメソッド４９２等を含む。
【０１３８】
全てのモジュールを通じて、ページ処理メソッドに対応するページ番号は基本的にユニークである。したがって、メインプログラム４７０があるページ番号を指定してコントローラ４８０を起動すると、そのページ番号に対応したページ処理メソッドが一意に定まり、実行される。ただし、後述するようにページ番号が重なることも許容されるが、その場合にはそのうちの一つ（最後にコントローラ４８０に登録されたもの）のみが実行される。そうした機構により、ページ処理の交換が容易に行なえるという効果があるがその詳細について以下に述べる。
【０１３９】
図２６にメインプログラム４７０の処理の概略をフローチャート形式で示す。図２６を参照して、メインプログラム４７０は最初に自己の処理内で利用するモジュールのインスタンスを全て生成する（５００）。次に、メインプログラム４７０はコントローラ４８０のインスタンスを生成する（５０２）。こうして生成されたコントローラ４８０に予め実装されているモジュール登録メソッドを呼出し、ステップ５００でインスタンス生成した全てのモジュールについてコントローラ４８０に登録する。このときコントローラ４８０は、モジュールの登録順に関する情報を保存している。
【０１４０】
続いて、クライアントＰＣ上で実行されているブラウザからの要求を待ち（５０６）、要求があればその要求に対応した処理を行なうページ番号を指定して、コントローラ４８０のモジュール実行メソッドを呼ぶ。その結果をブラウザに送信した後、制御はステップ５０６に戻る。
【０１４１】
図２７にコントローラ４８０は、自己のメソッドの呼出があると、どの呼出があったかを判断し（５２０）、その結果にしたがって実行メソッド５２２、登録メソッド５２４などを実行する。登録メソッドでは、メインプログラム４７０が生成したモジュールのインスタンスを特定する情報を管理テーブル内に登録する。このとき、前述したとおり登録順に関する情報も保持される。
【０１４２】
図２８に実行メソッド５２２の詳細を示す。まず、最初に画面上に表示されるメニューを作成する処理を行なう（５３０）。この処理については図２９を参照して後述する。
【０１４３】
続いて、図２７に示した登録メソッドで管理テーブルに新しく登録された順番で各モジュールを順に呼出していく。このとき、各モジュールにはパラメータとしてページ番号を与える。後述するように各モジュールは、与えられたページ番号と一致するページ処理メソッドがあればそれを実行して「処理済み」という結果を返し、与えられたページ番号と一致するページ処理メソッドがなければ何もせず「未処理」という結果を返す。コントローラ４８０は、ステップ５３２の処理の結果、モジュールから「処理済み」という結果が戻って来たか否かを判定し、「未処理」という結果が戻ってきたら次のモジュールに対してステップ５３２の処理を繰返す。「処理済み」の結果が戻ってきたら実行メソッドは終了である。
【０１４４】
図２９に図２８のステップ５３０の内容を示す。図２９を参照して、コントローラ４８０はまず、空のメニュータグ（ストリング）を作成し、登録テーブルの先頭のモジュールに渡す（５５０）。各モジュールはメニュータグを受けると、自己が持つメニュー表示文字列のこのメニュータグに追加してコントローラ４８０に返す。コントローラ４８０は、モジュールからメニュータグを受取り（５５２）、全てのモジュールに対してこの処理を行なったか否かを判定する（５５４）。全てのモジュールに対して処理が完了していないときは、コントローラ４８０は次のモジュールにメニュータグを渡し（５５６）、以下ステップ５５２〜５５４の処理を繰返す。
【０１４５】
全てのモジュールに対してメニュータグを渡し、受取る処理が終了したら、その結果得られたメニュータグをブラウザに渡す処理を行なう（５５８）。この処理により、ブラウザ画面上には、各モジュールが持っているメニュー表示文字列が並んでメニュー形式で表示されることになる。
【０１４６】
さて、図２８のステップ５３２でコントローラ４８０によって呼出された各モジュールは以下のようなページ実行メソッドを実行する。図３０を参照して、まず当該モジュールは、パラメータとしてコントローラ４８０から与えられたページ番号に該当するページが自モジュール内にあるか否かを判定する（５７０）。ある場合にはそのページを実行し（５７２）、「処理済み」の結果を返す。ない場合には何もせず「未処理」の結果を返す。
【０１４７】
以上のように、テーブルに新しく登録されたモジュールから順番に遡ってモジュールを呼出していく。その結果、同じページ番号のページ処理メソッドを持つモジュールが複数存在する場合、新しく登録されたモジュールのページ処理メソッドのみが実行され、古いモジュールのページ処理メソッドは実行されない。こうして、特定のページ処理を新しいものと置き換えることができる。この関係を図３１に示す。
【０１４８】
図３１を参照して、図２４に示されるシステムに新照会モジュール５８０が追加して登録されたものとする。このモジュール５８０は照会モジュール４７２より新しく登録されたので、照会モジュール４７２よりも先にコントローラ４８０によって呼出される。また図３１に示されるように、新照会モジュール５８０は、ページ制御メソッドの他にページ番号（１１）に相当するページ処理メソッド５８２を持ち、このページ番号が照会モジュール４７２が有するページ処理メソッドのうちの一つのページ番号と一致するものとする。すると、ページ番号１１を呼出す場合、最初に新照会モジュール５８０のページ処理メソッド５８２が呼出される。その結果新照会モジュール５８０からコントローラ４８０に対して「処理済み」の結果が返される。照会モジュール４７２のページ処理（１１）のメソッドが呼出されることはない。
【０１４９】
この構成では、照会モジュール４７２のページ処理（１１）のメソッドを変更しても、新照会モジュール５８０のページ処理メソッド５８２は全く影響を受けない。したがってモジュール間、ページ処理メソッド間を独立したものとすることができ、保守性の高い業務プログラムを差分プログラムによって効率良くカスタマイズすることができるようになる。
【０１５０】
以上のようなモジュール構成でプログラムを開発することにより、以下のような効果を得ることができる。
【０１５１】
（１）  モジュールが処理単位で独立しているため、作成が容易であり、メンテナンスも容易になる。
【０１５２】
（２）  必要な機能のモジュールを自由に組み合わせて使うことができる。
（３）  モジュールの入れ替え・追加が容易に行えるため、プログラムのカスタマイズが容易である。
【０１５３】
以上、本願発明を実施の形態に基づいて説明してきたが、本願発明はこれら実施の形態のシステムに限定されるわけではない。本願発明の権利範囲は、特許請求の範囲の各請求項の記載によって定められるべきである。本願明細書に開示された実施の形態の各構成要素と均等の構成要素を用いたものも本願発明の権利範囲に含まれる。
【図面の簡単な説明】
【図１】  本願発明に係るプログラム開発システムを実現するためのコンピュータの外観図である。
【図２】  本願発明に係るプログラム開発システムを実現するためのコンピュータのブロック図である。
【図３】  本発明の一実施の形態におけるアプリケーションプログラム作成手順を示すフローチャートである。
【図４】  項目オブジェクトの概念を説明するための模式図である。
【図５】  項目オブジェクトをＤＢ定義情報から抽出するツールのブロック図である。
【図６】  ＤＢ定義ファイルの例を示す図である。
【図７】  項目オブジェクトのデータ定義ファイルの例を示す図である。
【図８】  ＤＢ定義ファイルから項目オブジェクトのデータ定義ファイルを作成する処理のフローチャートである。
【図９】  項目オブジェクトのデータ定義ファイルをインタラクティブに修正する際の画面を示す図である。
【図１０】  項目オブジェクトのデータ定義ファイルをインタラクティブに修正する際の画面を示す図である。
【図１１】  項目オブジェクトのデータ定義ファイルをインタラクティブに修正する際の画面を示す図である。
【図１２】  項目オブジェクトのデータ定義ファイルをインタラクティブに修正する際の画面を示す図である。
【図１３】  業務アプリケーションの画面の一例を示す図である。
【図１４】  本発明の一実施の形態において、項目オブジェクトを使用したアプリケーションサーバの概念を説明するための図である。
【図１５】  アプリケーションサーバの実装すべき機能を説明するための図である。
【図１６】  本発明の一実施の形態にしたがって、項目オブジェクトを利用したアプリケーションが動作する際の、オブジェクトおよびアプリケーション間の関連を示す図である。
【図１７】  メインプログラムのコーディング例の一部を示す図である。
【図１８】  フォーム部品を実現する処理のフローチャートである。
【図１９】  フレームワークと開発するプログラム部分との関係を示す図である。
【図２０】  項目オブジェクト管理オブジェクトによる項目オブジェクトの管理方法を説明するための図である。
【図２１】  項目オブジェクト管理のための処理のフローチャートである。
【図２２】  本発明の一実施の形態によるフレームワーク構築の効果を説明するための図である。
【図２３】  本発明の一実施の形態によるモジュール制御の概念を示す図である。
【図２４】  本発明の一実施の形態によるモジュール制御のための、オブジェクトおよびアプリケーション間の関連を示す図である。
【図２５】  モジュールの構成を概念的に示す図である。
【図２６】  モジュール処理を取入れたメインプログラムの概略フローチャートである。
【図２７】  コントローラオブジェクトの動作を説明するためのフローチャートである。
【図２８】  コントローラオブジェクトの実行メソッドの制御構造を示すフローチャートである。
【図２９】  コントローラオブジェクトによるメニュー作成処理のフローチャートである。
【図３０】  各モジュールに実装されているページ実行メソッドのフローチャートである。
【図３１】  ページの入れ替えを行なう際のオブジェクトおよびアプリケーション間の関連を示す図である。
【図３２】  従来のイントラネットワークによって構築したシステムの構成例を示すブロック図である。
【符号の説明】
１５０，２８０，２８２  項目オブジェクト、１６２  ＤＢ作成ツール、２５４，２５６  ブラウザ、２６０  Ｊａｖａサーブレットエンジン、２９０  フォーム部品、４７０  メインプログラム、４７２  照会モジュール、４７４  登録モジュール、４７６  更新モジュール、４７８  削除モジュール、５８０  新照会モジュール。
【図１】
0004136271.tif 000003
【図２】
0004136271.tif 000004
【図３】
0004136271.tif 000005
【図４】
0004136271.tif 000006
【図５】
0004136271.tif 000007
【図６】
0004136271.tif 000008
【図７】
0004136271.tif 000009
【図８】
0004136271.tif 000010
【図９】
0004136271.tif 000011
【図１０】
0004136271.tif 000012
【図１１】
0004136271.tif 000013
【図１２】
0004136271.tif 000014
【図１３】
0004136271.tif 000015
【図１４】
0004136271.tif 000016
【図１５】
0004136271.tif 000017
【図１６】
0004136271.tif 000018
【図１７】
0004136271.tif 000019
【図１８】
0004136271.tif 000020
【図１９】
0004136271.tif 000021
【図２０】
0004136271.tif 000022
【図２１】
0004136271.tif 000023
【図２２】
0004136271.tif 000024
【図２３】
0004136271.tif 000025
【図２４】
0004136271.tif 000026
【図２５】
0004136271.tif 000027
【図２６】
0004136271.tif 000028
【図２７】
0004136271.tif 000029
【図２８】
0004136271.tif 000030
【図２９】
0004136271.tif 000031
【図３０】
0004136271.tif 000032
【図３１】
0004136271.tif 000033
【図３２】
0004136271.tif 000034