JP2006338477A - 情報処理装置とシステム開発方法 - Google Patents

Abstract

【課題】
設計情報をクライアントの設計への変換作業を定型化し、設計品質の向上を図る装置の提供。
【解決手段】
構築対象のシステムの設計仕様（クライアントプロセス、アクション定義、実行権限定義、ページ定義、画面レイアウト定義等）を規定した設計情報を記憶装置より入力し、システムで実装されるフレームワーク部品を制御するフレームワーク制御装置を備え、同一の設計情報を用いて、設計情報を異なる複数のアーキテクチャに実装可能としてなる。
【選択図】
図５

Description

本発明は、情報処理システムに関し、特に、業務システム等のシステム設計に好適な装置と方法に関する。

従来より用いられている典型的なシステム開発手法においては、システムの設計仕様を規定した設計情報を、例えばクライアントの設計に反映する場合、人手で行われ、もっぱら、担当エンジニアのスキル（技量）にまかされている。

また、クライアントの処理とサーバのロジックが分割され、双方のインタフェースを個別に定義して実装する必要がある。

さらに、システムの設計開発において、設計と実装の概念が明確に分離されていない。実装の制限に大きく左右された設計や、実装時に再度設計し直さなければならないような設計例も多く発生する。

上記したように、従来のシステム開発手法においては、設計情報をクライアントの設計への変換を、担当エンジニアのスキルにまかされているため、設計品質等にばらつきがおおく、作業工数の見積り等も困難である。また、エンジニアのスキルに依存するため、開発コストの低減も困難である。

本発明が解決しようとする主たる課題は、設計情報のクライアントの設計への変換作業を定型化し、設計品質の向上を図る装置及び方法を提供することにある。本発明で解決される他の課題等は、以下の説明からも明らかとされる。

本発明は上記課題を解決するため、概略以下の構成とされる。

本発明の１つのアスペクトに係る装置は、構築対象のシステムの設計仕様を規定した設計情報を格納した記憶装置より、前記設計情報を入力し、システムで実装される部品を制御し、同一の設計情報を用いて、設計情報を異なる複数のアーキテクチャに実装可能としてなる制御装置を備えている。

本発明において、前記設計情報は、クライアントのプロセスの定義情報と、アクションの定義情報、及び、アクションの実行権限の定義情報とを含む。

本発明において、画面のページの定義情報、前記ページに対応した画面のレイアウト定義情報を含む。

本発明において、前記定義情報に基づき、実際にアクションを実装する前の段階で設計の動作検証を行うシミュレーション手段を備えた構成としてもよい。

本発明において、前記クライアントのデバックを行う手段を備えた構成としてもよい。

本発明において、前記フレームワーク制御装置は、前記定義情報に対応したフレームワーク部品を制御し、設計情報から直接に実装システムを実現可能としている。

本発明において、ページ、画面のレイアウトを再定義することで、もとの設計情報を変更することなく、画面レイアウトの仕様変更に対応可能としている。

本発明において、クライアントプロセスは、１つ又は複数のコンテンツを有し、編集可能なデータ一覧画面ごとに予め用意されたステレオタイプ属性を設定し、
ステレオタイプ属性に必要な入出力項目を設定する。

本発明において、ステレオタイプとして、
選択肢を提供する画面、
データの照会画面、
データの編集画面、
データ一覧の照会画面、
編集可能なデータ一覧画面、
編集結果の紹介画面を含む。

本発明において、プロセス間のフロー定義を含む。

本発明において、アクションの定義情報は、アクション名と、実行する処理を含む。

本発明において、画面のページの定義情報はページ名、クライアントプロセス、画面レイアウト、ページ遷移情報を含む。

本発明において、画面のステレオタイプとして、選択肢を提供する画面、データ照会画面、編集画面、データ一覧照会画面、情報表示画面、検索条件、操作状態、確認ダイアログ、システムエラーダイアログ、警告ダイアログ、レポート画面、開始画面、ログイン、ログアウト画面を含む。

本発明において、フレームワーク部品として画面ステレオタイプに対応したGUI部品を備えた構成としてもよい。

本発明において、コンテンツに対応するステレオタイプを入力し、データベースの処理コマンドに変換する手段を備え、処理コマンドが前記データベースに対して発行される構成としてもよい。

本発明の他のアスペクトに係る方法は、構築対象のシステムの設計仕様を規定した設計情報を格納する記憶装置と、コントローラを備えた情報処理装置を用いたシステムの開発方法であって、前記設計情報は、クライアントのプロセスの定義情報と、アクションの定義情報、及び、アクションの実行権限の定義情報と、画面のページの定義情報と、前記ページに対応した画面のレイアウト定義情報とを含み、
前記コントローラが、前記記憶装置から設計情報を読み出し、ユーザインタフェース、画面レイアウト、アクションプログラムのフレームワーク部品を制御し、フレームワーク制御を行うステップを含む。

本発明によれば、設計品質を向上し、仕様の抜けや矛盾を防止し、開発の効率化に貢献する。

また、本発明によれば、クライアントの処理とサーバーのビジネスロジックを透過的に扱える構造とし、ユースケース・アクティビティのプロセスからクライアントのプロセスを抽出することにより、クライアントの処理とサーバーのビジネスロジックのプロセスを透過的に扱うことを可能とし、新サービスの追加や仕様の変更時にクライアント、サーバー双方を個別に修正する必要をなくし、迅速なリリースを行うことを可能としている。

本発明によれば、クライアント設計工程では、実装について意識せずに設計を進めることができ、実装工程で用意するフレームワーク部品は、設計工程で定義した情報を直接入力として利用できる。

さらに、本発明によれば、抽象度の高い設計により、同じ設計情報を利用して異なるアーキテクチャのクライアントに実装することができ、クライアント設計は実装アーキテクチャに依存しない。

本発明によれば、 業務ルールを分離し、クライアントのプロセスから自由に呼び出すことができ、ルールはクライアントのソースコードとは別に管理されるため、業務ロジックと業務ルールを別々に保守管理することができる。

本発明によれば、実装前の設計情報チェックを確実に行うことができる。

本発明によれば、フレームワークで提供されるデバッグ機能を用いることで、デバッグを容易可する。

本発明によれば、クライアントでの回帰テストツールを使用して、仕様変更時等に、テストを確実に行うことができる。

本発明についてさらに詳細に説述すべく、添付図面を参照して以下に説明する。最初に、本発明の一実施形態における、クライアント設計について説明する。本発明において、クライアント設計は、以下のように行われる。

（Ａ１）ユースケース分析・設計結果をクライアント設計に明確に反映する。

本実施例においては、設計情報をクライアントの設計に反映の作業を定型化し、設計品質を向上し、カタログデータの使用により、仕様の抜けや矛盾を防止している。

（Ａ２）クライアントの処理とサーバのビジネスロジックを透過的に連携する。

従来手法では、クライアントの処理とサーバのロジックが明確に分割され、双方のインタフェースを個別に定義、実装することが必要とされているのに対し、本発明によれば、クライアントの処理とサーバのロジックを透過的に扱える構造とされている。ユースケース・アクティビティのプロセスからクライアントのプロセスを抽出することにより、クライアントの処理とサーバのロジックのプロセスを透過的に扱うことができる。この手法では、新サービスの追加や仕様の変更時に、クライアント、サーバ双方を個別に修正する必要がなくなり、迅速なリリースを行うことができる。

（Ａ３）設計工程と実装工程を明確に分離する。

本発明においては、クライアント設計工程では、実装について意識せずに設計を進めることができる。また、実装工程で用意するフレームワーク部品は、設計工程で定義した情報を、直接入力として利用する機能を備える。この機能を使用し、設計工程と実装工程を明確に分離する。

（Ａ４）クライアント設計を実装アーキテクチャに依存しないようにする。

上記（Ａ３）により、設計工程と実装工程を明確に分離したことで、設計情報の抽象度を大幅に向上することができる。そして、抽象度の高い設計により、同じ設計情報を利用して異なるアーキテクチャのクライアントに実装することができる。

（Ａ５）業務ルールを分離し、クライアントのプロセスから自由に呼び出すことができる。

ルールエンジンでの業務ルールの呼び出しをクライアントから自由に行うことができる。ルールは、クライアントのソースコードとは別に管理されるため、業務処理と、業務ルールとを別々にメンテナンスすることができる。

（Ａ６）実装前の設計情報チェックを確実に行う。

クライアント設計の結果を実装前により確実に確認するために、設計情報の確認ツールを備えている。

（Ａ７）デバッグを容易化する。

フレームワークで提供されるデバッグ機能を用いて、クライアントを容易にデバッグできる。

（Ａ８）テストを確実に行う。

クライアントでの回帰テストツールを用い、仕様変更時に確実なテストを行うことができる。

次に、本発明の一実施例のクライアント設計の概要を説明する。クライアント設計では、図１に示すように、３層構造システム（クライアント、ビジネスロジック、データベース）のクライアント部分の設計が行われる。

図１において、クライアント（１０、２０）、ビジネスロジック（３０）、データベース（４０）それぞれの設計は、予め定められた一定のルールに基づき、常に、互いに連携して行われる。

また、現状のクライアントの実装方式には、WEB方式の実装（シンクライアント）、リッチクライアントとしての実装方式があり、ソフトウエアの再利用の観点およびメンテナンス性の観点から、これらの間での共通の設計方式が望まれる。

＜設計プロセスの連携＞
図２は、本実施例における設計プロセスの連携を説明する図である。特に制限されないが、ユースケース分析をもとに設計を進める場合、クライアント設計工程においても、このユースケース分析/設計にて作成した仕様を基に設計を行う。これにより、クライアントの設計とほかの部分の設計の連携を円滑に行うことができる。

また、設計仕様は、次の設計工程の入力にそのまま用いることができるように、それぞれカタログ化される。クライアント設計、ビジネスロジック設計、データベース設計のいずれにおいても、カタログ化された設計情報を入力として、設計を進める。

＜設計項目＞
図３は、本実施例におけるクライアントの設計項目の一例を示す図である。クライアント設計では、図３に示すように、下記記載の項目について設計を行う。

（Ｂ１）クライアントのプロセス
クライアントのプロセスフローを作成し、各プロセスの設計を行う。

（Ｂ２）クライアントのアクション
ユーザ（またはシステム）のアクションに対する処理の設計を行う。

（Ｂ３）実行権限管理
ユーザ、端末などに付与された権限により実行が規制されるアクションの定義を行う。

（Ｂ４）画面のページ遷移、状態遷移
設計対象システムにおける画面のページ遷移、状態の遷移を定義する。

（Ｂ５）画面のレイアウト
設計対象システムにおける画面の表示フォームを定義する。

次に、本発明の一実施例におけるクライアントの設計手順について説明する。図４は、
クライアント設計の手順を示す流れ図である。

＜クライアント・プロセスの抽出＞
ユースケース分析・設計にて作成したユースケース・アクティビティをもとにクライアントのプロセスを抽出する（図４のステップＳ１１）。ユースケース・アクティビティのプロセス粒度による、一般に、ユースケース・アクティビティの各プロセスに対し１つまたは複数のクライアント・プロセスが抽出される。

抽出されたクライアント・プロセスは、いくつかのコンテンツに分解され、それぞれのコンテンツごとに、ステレオタイプ属性を定義する。ステレオタイプ属性の種類・名称はあらかじめ定義されている。

また、ステレオタイプ属性に必要な入出力業務項目を定義する。このとき、業務ルールが対応する場合は、そのルール名を指定する。

各プロセス間のフロー（遷移）もここで定義する。ここで定義される主な項目を以下に示す。

・クライアント・プロセス
・コンテンツ
・ステレオタイプ属性
・入出力業務項目
・業務ルール名
・プロセスフロー

＜アクションの定義＞
次に、各クライアント・プロセスにおけるアクションを定義する（図４のステップＳ１２）。アクションは、オペレータの操作や、システムのイベントにより起動される処理である。定義したアクションについて、実行する処理を記述する。この部分は、後の実装工程で、プログラムとして実装される。

ここで定義する主な項目を以下に示す。

・アクション名
・アクションの処理

＜実行権限の定義＞
各アクションが規制の対象となる場合は、その規制の種別を定義し、実行権限を設定する（図４のステップＳ１３）。ここで定義する主な項目は、実行権限（規制種別）である。

上記ステップののち、設計情報を確認し修正が必要な場合、ステップＳ１１乃至Ｓ１３のいずれかに戻る。

＜ページの定義＞
クライアント・プロセスを実際の画面単位に分割または併合し、ページを定義する（図４のステップＳ１５）。ページは、実際の画面の大きさや選択したクライアントのアーキテクチャにより決定される。また、ページを画面レイアウトと対応させる。ここで定義する主な項目を以下に示す。

・ページ名
・対応するクライアント・プロセス
・対応する画面レイアウト
・ページ遷移

＜ 画面レイアウトの定義＞
各ページに対応させる画面のレイアウトを定義する（図４のステップＳ１６）。画面のレイアウトには、クライアントのステレオタイプに対応したＵＩコンポーネントの配置情報を定義する。

＜抽象設計と変更処理＞
上記したクライアント設計手順により、設計の抽象化が可能となる。この様子を図５に示す。

特に制限されないが、図５に示すように、ＵＭＬのユースアクティビティ分析、クライアントプロセス定義、コンテンツ（ステレオタイプ画面）、業務項目・業務ルール、アクション定義を含む設計情報（抽象設計）１００をフレームワーク制御部１０２が入力し、フレームワーク部品１０３を制御する。フレームワーク部品は、ＵＩコンポーネント、画面レイアウト、アクション定義に実装であるアクションプログラムを含む。

クライアントに抽象設計を導入すると、仕様変更などへの対応が容易になる。図６に、画面レイアウトを変更した場合の様子を示す。画面レイアウトの定義として、画面１、２の表示（ページ定義）を変更する場合、レイアウト変更のため、画面レイアウトとページ定義を再定義するだけでよい。これにより、もとの画面１、２は、新画面に変更させる。

＜ＸＭＬ定義＞
本実施例において、クライアント設計にて設計した情報は、ＸＭＬにて定義される。

各設計情報とＸＭＬファイルの関連の一例を図７に示す。XMLファイル［プロセス定義(<process>タグ)、アクション定義(<action>タグ)、実行権限定義(<permission>タグ)、ページ定義(<page>タグ)、画面レイアウト定義(<layout>タグ)］と定義項目よりなる。なお、実行権限はログイン時にフレームワークにて設定される。

XML形式で定義されたこれらの情報は、以下の目的に用いられる。

・HTMLドキュメントの生成
・設計ルールチェック
・設計情報のレビュー情報
・操作マニュアル作成時の入力
・シミュレーション・ツールによる実装前の動作チェック
・実行時のフレームワークへの入力情報
・実装プログラムのテンプレート生成
・回帰テスト情報の作成

図８は、クライアント設計で定義するＸＭＬファイル及びその相互参照関係を示す図である。プロセス定義、アクション定義、実行権限定義、レイアウト定義、ページ定義を有し、アクション定義はプロセス定義、実行権限定義を参照し、ページ定義は、プロセス定義、レイアウト定義を参照する。

図９は、プロセス定義XMLファイルの一例を示す図である。プロセス名、プロセスIDのほか、<contents>タグに、コンテンツ名、コンテンツID、コンテンツのステレオタイプ（この場合Menu）等が定義される。図９に示す例では、ステレオタイプがMenuの場合のメニュー項目の指定、メニュー項目ＩＤの定義、メニュー項目に表示するメッセージ、画面の説明行に表示されるメッセージ等が定義されるほか、各状態のコードとイベントが定義される（state condition> <event id>タグ）。

図１０はアクション定義ＸＭＬファイルの一例を示す図である。アクション名、イベント名、実装クラス、戻り値等が定義される。

図１１は実行権限定義ＸＭＬファイルの一例を示す図である。

実行権限コード、実行権限が必要なイベントが列挙される。

図１２は、ページ定義ＸＭＬファイルの一例を示す図である。ページ名、使用するレイアウト名、ページの表示面、UIコンポーネントIDとコンテンツの結合、ページ属性等が定義される。

図１３は、画面レイアウト定義ＸＭＬファイルの一例を示す図である。画面のレイアウト、使用するUIコンポーネント、配置等のパラメータ、表示枠情報（＜form＞タグ）を定義する。レイアウト定義は複数のコンテンツで共用することができる。

＜クライアント制御機構＞
本実施例において、クライアントプログラムを実装し、実行するための基本制御機構（フレームワーク）について説明する。クライアント制御用のフレームワーク（「クライアント・アーキテクチャ」と呼ぶ）は、クライアント部分を制御するフレームワークとして位置づけられる。クライアント・アーキテクチャは以下の機能を備える。

・制御プログラム（コントローラ）
・画面フォーム
・ＵＩコンポーネント
・シミュレーション機構
・デバッグ機構
・テスト機構

図１４は、クライアント制御機構を説明する図である。以下、各機能を説明する。

＜制御プログラム（コントローラ）＞
クライアント・アーキテクチャは、MVC(モデル-ビュー-コントローラ)構造で作成され、制御プログラムは、このコントローラの役割を担う。制御プログラム（コントローラ）は次の機能を備える。

（１）セッション管理

セッション管理は操作者がクライアントにログインを行ってからログアウトをするまでのセッションの管理を行う。セッション管理により、操作者の対話のコンテキストが保護される。

（２）フロー制御

画面の遷移を管理する。XMLで定義したページ定義の記述にしたがって制御を行う。

（３）アクション呼び出し

オペレータの操作やシステムのイベントにより、アクション定義XMLに定義されているアクションを呼び出す。アクション定義XMLにより、アクションの戻り値に対する処理も行う。

（４）権限管理

各アクションを呼び出す際にそのアクションの実行権限を検査し、実行の規制を行う。また、画面を表示する際、実行権限のない機能を選択不可とするような管理も行う。

（５）メッセージ管理

画面に表示する各種メッセージを管理する。メッセージ文字列は、共通に管理する（国際化にも対応）。

（６）リポジトリ機構

クライアントのセッションごとにリポジトリ機構が提供され、セッション単位のオブジェクトの保存、クライアントプログラム間のデータの受け渡しなどに用いる。

（７）ログ機能

実行ログを管理する。

＜ 画面フォーム＞
画面の共通の枠を構成する標準部品であり。各画面は、１つの画面フォームを持つ。
各画面での画面フォームの指定はページ定義XMLに定義される。

画面フォームには以下の種別がある。

（１）基本画面フォーム

画面フォームのすべてのデフォルトが定義された部品である。
（２）拡張画面フォーム

基本画面フォームを各アプリケーションに合わせて拡張した部品である。

＜ＵＩコンポーネント＞
画面フォーム内に配置して使用するＧＵＩ部品であり、クライアント・プロセスのコンテンツのステレオタイプに対応して作成される。

クライアント・プロセスのコンテンツと画面に表示するＵＩコンポーネントの対応はページ定義XMLにて定義される。ＵＩコンポーネントには、以下の種別がある。

（１）基本ＵＩコンポーネント

各ステレオタイプ種別に対して必ず１つずつ存在し、そのステレオタイプのＵＩコンポーネントのデフォルトが定義される。

（２）拡張ＵＩコンポーネント

基本ＵＩコンポーネントを拡張して作成される。アプリケーションごとに、違う形状や機能のＵＩコンポーネントを対応させる場合は基本ＵＩコンポーネントを拡張して機能を追加する。

＜シミュレーション機構＞
設計の早期検証を行うために、実際のアクションなどの実装前にクライアント設計のXML情報を入力として動作検証、ウォークスルーなどを行う。XMLに定義された論理情報をもとにクライアントの動作をシミュレートする。

＜デバッグ機構＞
クライアントのデバッグを補助し、次のような機能を備える。

（１）クライアントの状態のリアルタイム表示

クライアント実行時の状態をリアルタイムに表示する。表示する主な項目を次に示す。

・セッションの状態
・実行中のプロセスID
・実行中のページID
・実行中のアクションID
・アクション戻り値
・各入力フィールドの値

（２）リポジトリの表示

クライアントプログラムがセッション単位に使用しているリポジトリの内容を表示する。

（３）実行ログ

実行中のログをそのレベルに応じて表示、保存する。ログは各クライアント・プログラム単位、および、メッセージレベル単位にオン／オフすることができる。

（４）サーバ機能のシミュレーション

サーバ機能が未実装でも、その機能をシミュレートする機能を備えている。実機サーバを使用せずにクライアント単独でのデバッグが可能となる。

＜テスト機構（回帰テスト）＞
プログラムの修正時などに必要な回帰テストを行う機能が用意される。実行するクライアントの画面操作を記録し、再実行する。

以下では、詳細パラメタについて説明する。

＜画面ステレオタイプ＞
画面ステレオタイプの例を一覧で図１５に示す。

コンテンツによる分類、振舞いによる分類について、それぞれ、ステレオタイプ、ID、ユースケースアクティビティのプロセスからの抽出、説明が一欄で示されている。

例えばユースケースアクティビティのプロセスからの抽出が「〜を選択する」の場合、選択肢を提供する画面のMenuが対応する。データの照会画面、編集画面、一覧照会画面、システム開始画面、ログイン、ログアウトで移る画面等に対応するステレオタイプが用意されている。

＜ＧＵＩ標準部品定義＞
プラットフォーム毎に、各画面ステレオタイプに対応するＧＵＩ標準部品が定義される。ＧＵＩ標準部品はフレームワーク部品として用意される。図１６にＧＵＩ標準部品の例を示す。

＜コンテンツ定義要素＞
コンテンツ定義では、ステレオタイプ別に定義に必要な要素が決まる。

図１７に、コンテンツ定義要素を示す。Menuは、選択肢を提供する画面であり、要素として、メニュー、メニュー項目を備え、メニューは子要素／属性として、メニュー名、メニュー項目を備え、メニュー項目は子要素／属性として、メニュー項目名、メニュー項目選択時のアクション名を備えている。

本発明の別の実施例において、コンテンツに対応するステレオタイプを入力し、データベース（図１のデータベースサーバ）の処理コマンド（例えばSQLコマンド）に変換する手段を備え、処理コマンドが前記データベースに対して発行される構成としてもよい。この場合、ユーザはSQL命令文を直接生成することなく、データ操作の設計仕様を記述するだけでよい。データ操作の設計仕様に対応するステレオタイプ（例えば図１５のデータに対する検索条件、グループ化条件、ソート条件の設定画面）から、例えばSQLコマンドの検索コマンド等が生成・発行される。

以上本発明を上記実施例に即して説明したが、本発明は上記実施例に限定されるものでなく、本発明の範囲内で当業者であればなし得るであろう各種変形、修正を含むことは勿論である。

本発明の一実施例における三層構造でのクライアントを説明する図である。 本発明の一実施例における設計プロセスの連携を説明する図である。 本発明の一実施例におけるクライアントの設計項目を説明する図である。 本発明の一実施例におけるクライアントの設計手順を説明する流れ図である。 本発明の一実施例におけるクライアントの抽象設計と実装を説明する流れ図である。 本発明の一実施例における画面レイアウト変更例を説明する図である。 本発明の一実施例におけるクライアンXML定義ファイルの一例を示す図である。 本発明の一実施例におけるクライアントで定義するXMLファイルを示す図である。 本発明の一実施例におけるプロセス定義XMLファイルの一例を示す図である。 本発明の一実施例におけるアクション定義XMLファイルの一例を示す図である。 本発明の一実施例における実行権限定義XMLファイルの一例を示す図である。 本発明の一実施例におけるページ定義XMLファイルの一例を示す図である。 本発明の一実施例における画面レイアウト定義XMLファイルの一例を示す図である。 本発明の一実施例におけるクライアント制御機構の構成を示す図である。 本発明の一実施例における画面ステレオタイプの一例を示す図である。 本発明の一実施例におけるGUI標準部品の一例を示す図である。 本発明の一実施例におけるコンテンツ定義要素の一例を示す図である。

符号の説明

１０ WEBクライアント
２０ リッチクライアント
３０ ビジネスロジック
４０ データベース
１００ 設計情報
１０１ クライアント
１０２ フレームワーク制御部
１０３ フレームワーク部品

Claims (18)

1. 構築対象のシステムの設計仕様を規定した設計情報を格納する記憶装置と、
   前記記憶装置より、前記設計情報を入力し、前記設計情報に対応する実装部品を制御し、前記設計情報に基づき、構築対象のシステムを実装可能としてなる制御装置と、
   を備えている、ことを特徴とする情報処理装置。
2. 前記制御装置は、同一の設計情報を用いて、前記設計情報を互いに異なるアーキテクチャに実装可能としてなる仮想マシンを備えている、ことを特徴とする請求項１記載の情報処理装置。
3. 前記設計情報は、クライアントのプロセスの定義情報と、アクションの定義情報、及び、アクションの実行権限の定義情報とを少なくとも含む、ことを特徴とする請求項１記載の情報処理装置。
4. 前記設計情報が、画面のページの定義情報、前記ページに対応した画面のレイアウト定義情報を含む、ことを特徴とする請求項３記載の情報処理装置。
5. 前記制御装置は、前記記憶装置から設計情報を読み出し、ユーザインタフェース、画面レイアウト、アクションプログラムのフレームワーク部品を制御し、フレームワーク制御を行う、ことを特徴とする請求項４記載の情報処理装置。
6. 前記定義情報に基づき、実際にアクションを実装する前の段階で、設計の動作検証を行うシミュレーション手段をさらに備えている、ことを特徴とする請求項４記載の情報処理装置。
7. 前記定義情報に基づき、設計対象システムのデバックを行う手段をさらに備えている、ことを特徴とする請求項４記載の情報処理装置。
8. 前記制御装置は、前記定義情報に対応したフレームワーク部品を制御し、前記設計情報から、直接に、構築対象となる実装システムを実現可能としてなる、ことを特徴とする請求項４記載の情報処理装置。
9. ページの定義情報、画面のレイアウトを再定義することで、もとの設計情報を変更することなく、画面レイアウトの仕様変更に対応可能としてなる、ことを特徴とする請求項４記載の情報処理装置。
10. クライアントプロセスは、１つ又は複数のコンテンツを有し、編集可能なデータ一覧画面ごとに予め用意されたステレオタイプ属性を設定し、ステレオタイプ属性に必要な入出力項目を設定する、ことを特徴とする請求項３又は４記載の情報処理装置。
11. クライアントのプロセスの定義情報が、プロセス名とプロセスID、コンテンツ名とコンテンツID、ステレオタイプ名、業務項目名、業務ルール、アクション名、プロセス間の遷移情報を含む、ことを特徴とする請求項３記載の情報処理装置。
12. アクションの定義情報は、アクション名と、実行する処理を含む、ことを特徴とする請求項３記載の情報処理装置。
13. 画面のページの定義情報はページ名、クライアントプロセス、画面レイアウト、ページ遷移情報を含む、ことを特徴とする請求項４記載の情報処理装置。
14. ステレオタイプとして、
    選択肢を提供する画面、
    データの照会画面、
    データの編集画面、
    データ一覧の照会画面、
    編集可能なデータ一覧画面、
    編集結果の紹介画面、
    情報表示画面、
    操作内容説明画面、
    データに対する検索条件、グループ化条件、ソート条件の設定画面、
    業務操作の状態の表示画面、
    確認ダイアログ、
    システムエラーダイアログ、
    警告ダイアログ、
    システム開始画面、
    ログイン画面、
    ログアウトで移る画面、
    のうちの少なくとも１つを含む、ことを特徴とする請求項１１記載の情報処理装置。
15. ステレオタイプが、画面間の推移、セーブポイント以降の編集内容を取り消す、サーバの機能を呼び出し、データを保存する、ログアウト可能な画面の少なくとも１つを含む、ことを特徴とする請求項１１記載の情報処理装置。
16. フレームワーク部品として画面ステレオタイプに対応したGUI部品を備えている、ことを特徴とする請求項５記載の情報処理装置。
17. コンテンツに対応するステレオタイプを入力し、データベースの処理コマンドに変換する手段を備え、
    処理コマンドが前記データベースに対して発行される、ことを特徴とする請求項１記載の情報処理装置。
18. 構築対象のシステムの設計仕様を規定した設計情報を格納する記憶装置と、コントローラを備えた情報処理装置を用いたシステムの開発方法であって、
    前記設計情報は、クライアントのプロセスの定義情報と、アクションの定義情報、及び、アクションの実行権限の定義情報と、
    画面のページの定義情報と、前記ページに対応した画面のレイアウト定義情報と、
    を含み、
    前記コントローラが、前記記憶装置から設計情報を読み出し、ユーザインタフェース、画面レイアウト、アクションプログラムのフレームワーク部品を制御し、フレームワーク制御を行うステップを含む、ことを特徴とするシステム開発方法。
    
    

Images