(57)【要約】ユーザインタフェースを持つアプリケーションプログラムを自動生成し、プログラムの開発効率と保守性を上げることを目的とする。アプリケーション開発装置は、画面と処理とが交互に記述された形式の画面遷移図に相当し、画面と表示入力データ項目との関連付け、および表示入力データ項目と画面レイアウトとの間の関連付けがなされた仕様書データを読み込む仕様書データ読込部と、その仕様書データを用いてアプリケーションプログラムを自動生成するプログラム生成部とを備える。
2004104824.tif 000002
【特許請求の範囲】
【請求項１】
ユーザインタフェースアプリケーションの開発装置において、
画面と処理とが交互に記述される形式の画面遷移図に相当し、画面と表示入力データ項目との間の関連付け、および表示入力データ項目と画面レイアウトとの間の関連付けがなされたプログラム開発用仕様書データを読み込む仕様書データ読み込み手段と、
該仕様書データを用いて、ユーザインタフェースアプリケーションのプログラムを自動生成するプログラム生成手段とを備えることを特徴とするユーザインタフェースアプリケーション開発装置。
【請求項２】
ユーザインタフェースアプリケーションの開発装置において、
画面と処理とが交互に記述される形式の画面遷移図に相当し、画面と表示入力データ項目との間の関連付け、および表示入力データ項目と画面レイアウトとの間の関連付けがなされたプログラム開発用仕様書データを読み込む仕様書データ読み込み手段と、
該仕様書データを解釈し、該解釈結果に対応して、ユーザインタフェースアプリケーションの処理を実行する処理実行手段とを備えることを特徴とするユーザインタフェースアプリケーション開発装置。
【請求項３】
ユーザインタフェースアプリケーションの開発装置において、
それぞれ対応する処理が定められるべき複数の画面の間での遷移が記述された形式の画面遷移図に相当し、画面と表示入力データ項目との間の関連付け、および表示入力データ項目と画面レイアウトとの間の関連付けがなされるべきプログラム開発仕様書データを読み込む仕様書データ読み込み手段と、
該仕様書データを用いて、ユーザインタフェースアプリケーションのプログラムを自動生成するプログラム生成手段とを備え、
前記対応する処理、および２つの関連付けの内容を変更しながら、仕様書データ読み込み手段とプログラム生成手段との動作を繰り返すことを特徴とするユーザインタフェースアプリケーション開発装置。
【請求項４】
前記表示入力データ項目に対応して設けられる制約条件をチェックし、該条件が満足されない時、前記画面遷移図上での画面から処理への遷移を禁止する制約条件チェック手段を更に備えることを特徴とする請求項１記載のユーザインタフェースアプリケーション開発装置。
【請求項５】
前記制約条件に対応して該制約条件のチェック箇所を指定する情報が与えられ、前記制約条件チェック手段が該指定に対応してチェックを行なうことを特徴とする請求項４記載のユーザインタフェースアプリケーション開発装置。
【請求項６】
前記表示入力データ項目と、該表示入力データ項目に関する制約条件とに対応してテストデータを生成し、該テストデータを前記生成されたプログラムに投入してプログラムの検証を行なうアプリケーション検証手段を更に備えることを特徴とする請求項１記載のユーザインタフェースアプリケーション開発装置。
【請求項７】
前記アプリケーション検証手段がプログラムの検証結果を保存し、前記プログラム開発用仕様書データが変更された時、同一のテストデータを用いて該変更後の検証結果と比較して仕様書データ変更の影響範囲を検出することを特徴とする請求項６記載のユーザインタフェースアプリケーション開発装置。
【請求項８】
前記表示入力データ項目に対応して、あらかじめ定められた画面レイアウトに関するルールに従って、自動的に画面生成を行なう画面生成手段を更に備えることを特徴とする請求項１記載のユーザインタフェースアプリケーション開発装置。
【請求項９】
前記プログラム開発用仕様書データに対応し、前記ユーザインタフェースアプリケーションのモデルを表す内部仕様の情報をあらかじめ定められた定義に従ってフィルタリングし、外部仕様を表すための非定型の追加情報と合わせて外部仕様文書を自動生成する外部仕様生成手段を更に備えることを特徴とする請求項１記載のユーザインタフェースアプリケーション開発装置。
【請求項１０】
前記追加情報をモデルの拡張情報として、前記外部仕様文書と内部仕様文書とを合わせて、１つのモデル情報として保存する記憶手段をさらに備えることを特徴とする請求項９記載のユーザインタフェースアプリケーション開発装置。
【請求項１１】
前記プログラム生成手段によって生成されたプログラムのデバッグを行なうデバッグ手段をさらに備えると共に、
前記プログラム生成手段がプログラムの自動生成にあたってプログラム内にイベントを発行する命令を埋め込み、
前記デバッグ手段が、デバッグ時に該イベントを受け取り、該イベント発行命令の埋め込み箇所をプログラムの実行箇所として識別することを特徴とする請求項１記載のユーザインタフェースアプリケーション開発装置。
【請求項１２】
前記プログラム生成手段が、前記イベント発行に対応する処理としてブレークポイントを示す情報を設定し、
前記デバッグ手段が該情報を検出した時、前記画面上で該ブレークポイントに対応する部分を強調することを特徴とする請求項１１記載のユーザインタフェースアプリケーション開発装置。
【請求項１３】
前記プログラム生成手段が、前記イベントに該イベント発行命令の埋め込み箇所で扱われるデータを埋め込み、該データと前記仕様書データを表す図上でのクラスとを識別子によって対応付け、
前記デバッグ手段がイベントを受け取った時、該データの種類とその値とを検出することを特徴とする請求項１１記載のユーザインタフェースアプリケーション開発装置。
【請求項１４】
前記デバッグ手段が前記検出されたデータの値を保存し、アプリケーションが変更された後のデバッグ時に同一箇所のデータと比較し、アプリケーション変更の影響範囲を検出することを特徴とする請求項１３記載のユーザインタフェースアプリケーション開発装置。
【請求項１５】
ユーザインタフェースアプリケーションの開発方法において、
画面と処理とが交互に記述される形式の画面遷移図に相当し、画面と表示入力データ項目との間の関連付け、および表示入力データ項目と画面レイアウトとの間の関連付けがなされたプログラム開発用仕様書データを読み込み、
該仕様書データを用いて、ユーザインタフェースアプリケーションのプログラムを自動生成することを特徴とするユーザインタフェースアプリケーション開発方法。
【請求項１６】
ユーザインタフェースアプリケーションの開発を行なう計算機によって使用されるプログラムにおいて、
画面と処理とが交互に記述される形式の画面遷移図に相当し、画面と表示入力データ項目との間の関連付け、および表示入力データ項目と画面レイアウトとの間の関連付けがなされたプログラム開発用仕様書データを読み込む手順と、
該仕様書データを用いて、ユーザインタフェースアプリケーションのプログラムを自動生成する手順とを計算機に実行させるためのプログラム。
【発明の詳細な説明】
【技術分野】  本発明はプログラムの開発および実行方式に係わり、更に詳しくはユーザインタフェースを持つアプリケーションのプログラムを自動生成することを可能とし、プログラムの開発効率と保守性を上げるユーザインタフェースアプリケーション開発装置、および開発方法に関する。
【背景技術】  近年ソフトウエアの設計方法として、オブジェクト指向技術を用いた方法が広範に用いられている。特にＵＭＬ（ユニファイド・モデリング・ランゲージ）というプラットフォームに依存しない言語と、オブジェクト指向言語、例えばＪａｖａとを組み合わせたＷｅｂアプリケーションの開発方式が注目されている。
このようなソフトウエアの開発方法としては、できるだけプログラムあるいはその部品の自動生成が可能な方法が望まれている。このようなプログラムの自動生成については次のような従来技術がある。
【特許文献１】  特開平６−２３０９４９号公報「プログラム自動生成装置」
【特許文献２】  特開平１１−２３７９８２号公報「ソフトウエア部品開発支援装置」
【特許文献３】  特開２０００−３３９１４９号公報「状態遷移モデル作成方法および装置」
【特許文献４】  特開２０００−１１６９１１号公報「オブジェクト指向プログラムの自動生成装置」
特許文献１には、制御対象システムを構成するユニットの変更にあたって、変更のなかったユニットに関する仕様を再利用することができ、ソフトウエアの生産効率を向上させ、またユニットの数が多くなった場合にもコンパクトで簡明な仕様記述を行なうことができるプログラム自動生成装置が開示されている。
特許文献２には、オブジェクト指向ソフトウエアにおいて再利用可能な部品の開発を行うために、ある問題領域のアプリケーションに共通となる要求仕様を分析して得られる仕様の不変／変動部に関する情報を利用して、再利用可能な部品の開発を支援する技術が開示されている。
特許文献３には、状態遷移モデルの作成において状態抽出、入力イベント抽出、アクション抽出、および出力イベント抽出に必要とされる時間を短縮することができる技術が開示されている。
特許文献４には、オブジェクト指向プログラムの開発において静的部分のプログラムコードの自動生成と共に動的部分のプログラムコードの自動生成を行なって、ソフトウエア開発の作業効率を向上させることができるプログラムの自動生成装置が開示されている。
しかしながらまず特許文献１では、状態遷移モデルでユニット間の関係を記述しなければならない。例えばユーザインタフェースアプリケーションにおける、クライアント側の画面と表示データ項目、画面レイアウトの関係を状態遷移モデルで記述しなければならず、開発に手間がかかるという問題点があった。
特許文献２では、要求仕様の分析モデルが設計情報に変換され、オブジェクト指向のソフトウエア部品が開発されるが、設計モデルの定義によって、例えばＷｅｂアプリケーションのプログラムに自動変換することは困難であった。
特許文献３では、状態遷移表に加えて、更にメッセージシーケンスチャートを記述する必要があり、プログラムの自動生成までには手間がかかるという問題点があった。
特許文献４では、動的部分の定義を抽出し、ステートマシンツリーを構築した後に、静的部分と統合してプログラムコードを生成する必要があり、最終プログラム製品の開発までには、手数を要するという問題点があった。
【発明の開示】
本発明の目的は、ユーザインタフェースアプリケーションの開発においてプログラム開発用仕様書データの作成に工夫を加えることによって、ユーザインタフェースアプリケーションプログラムの自動生成を容易にする開発装置、および開発方法を提供することである。
本発明のユーザインタフェースアプリケーション開発装置は、仕様書データ読み込み手段と、プログラム生成手段とを備える。
仕様書データ読み込み手段は、画面と処理とが交互に記述される形式、例えば１つの画面と１つ以上の処理とが交互に記述される形式の画面遷移図に相当し、画面と表示入力データ項目との間の関連付け、および表示入力データ項目と画面レイアウトとの関連付けがなされたプログラム開発用仕様書データを読み込むものであり、プログラム生成手段は、この仕様書データを用いて、ユーザインタフェースアプリケーションのプログラムを自動生成するものである。
また本発明のユーザインタフェースアプリケーション開発装置は、仕様書データ読み込み手段と、処理実行手段とを備える。
仕様書データ読み込み手段は、前述と同様のプログラム開発用仕様書データを読み込み、処理実行手段は読み込まれた仕様書データを解釈し、その解釈結果に対応して、ユーザインタフェースアプリケーションの処理を実行するものである。
更に本発明のユーザインタフェースアプリケーション開発装置は、仕様書データ読み込み手段とプログラム生成手段とを備える。
仕様書データ読み込み手段は、それぞれ対応する処理が定められる複数の画面の間での遷移が記述された形式の画面遷移図に相当し、画面と表示入力データ項目との間の関連付け、および表示入力データ項目と画面レイアウトとの間の関連づけがなされるべきプログラム開発仕様書データを読み込むものであり、プログラム生成手段は、その仕様書データを用いて、ユーザインタフェースアプリケーションのプログラムを自動生成するものであり、仕様と前述の２つの関連づけの内容が変更されながら、プログラムが反復的に開発される。
以上のように本発明によれば、プログラム開発用仕様書データとして工夫された形式、すなわち画面と処理とが交互に記述される形式の画面遷移図に相当する仕様書データを用いて、ユーザインタフェースアプリケーションのプログラムの自動生成、またはアプリケーションの処理の実行が行われる。
【図面の簡単な説明】  図１は、本発明のユーザインタフェースアプリケーション開発装置の原理構成ブロック図である。
図２は、ユーザインタフェースアプリケーション開発のための定義の全体像を示す図である。
図３は、画面遷移定義の例を示す図である。
図４は、画面遷移定義における画面レイアウト定義の例を示す図である。
図５は、ビジネスフロー定義の例を示す図である。
図６は、画面項目定義の例を示す図である。
図７は、定義の省略を行なう場合に最低限必要な画面遷移定義の説明図である。
図８は、省略が行なわれる場合の画面遷移の例の説明図である。
図９は、ユーザインタフェースアプリケーションの自動生成の説明図である。
図１０は、自動生成ツールを用いたプログラム作成処理の基本フローチャートである。
図１１は、自動生成されたアプリケーションの構造を説明する図である。
図１２は、定義体を解釈しながら処理を行なう動作形式を説明する図である。
図１３は、仕様生成ツールによる外部仕様文書生成の説明図である。
図１４は、外部仕様生成処理の基本フローチャートである。
図１５は、デバッグツールによる命令実行箇所などの検出の説明図である。
図１６は、テストデータ生成とテスト実行動作の説明図である。
図１７は、定義体修正の影響範囲検出動作の説明図である。
図１８は、ユーザインタフェースアプリケーションの反復開発の説明図である。
【発明を実施するための最良の形態】  図１は本発明のユーザインタフェースアプリケーション開発装置の原理構成ブロック図である。同図において開発装置１は、仕様書データ読み込み部２と、プログラム生成部３とを備える。
仕様書データ読み込み部２は、画面と処理とが交互に記述される形式の画面遷移図に相当し、画面と表示入力データ項目との間の関連づけ、および表示入力データ項目と画面レイアウトとの間の関連づけがなされたプログラム開発用仕様書データ、例えばＵＭＬ言語で書かれた仕様書データを読み込むものであり、プログラム生成手段３は、その仕様書データ、および例えばビジネスフロー定義図などを用いて、プラットフォームに依存した形式のユーザインタフェースアプリケーションプログラムを、例えばＪａｖａ  Ｓｅｒｖｅｒ  Ｐａｇｅｓ（ＪＳＰ）／Ｓｅｒｖｌｅｔ用の自動生成ツールを用いて自動生成するものである。
ここでＪＳＰ／ＳｅｒｖｌｅｔはＪａｖａ言語によりＷｅｂサーバ処理を行い、ＨＴＭＬ形式のファイルをＷｅｂブラウザに送るものである。
ユーザインタフェースアプリケーション開発装置１は、図示しない制約条件チェック部を更に備えることも可能である。制約条件チェック部は、表示入力データ項目に対応して設けられる制約条件をチェックし、その条件が満足されない時に画面遷移図上での画面から処理への遷移を禁止するものであり、この場合、制約条件に対応して制約条件のチェック箇所を指定する情報が与えられ、制約条件チェック部がその指定に対応してチェックを行なうことも可能である。
またユーザインタフェースアプリケーション開発装置１は、更に図示しないアプリケーション検証部を備えることもできる。アプリケーション検証部は表示入力データ項目に対応してテストデータを生成し、そのテストデータを生成されたプログラムに投入してプログラムの検証を行なうものである。この場合、アプリケーション検証部がプログラムの検証結果を保存し、プログラム開発用仕様書データなどが変更された時に、同一のテストデータを用いて変更後のプログラムを検証した結果と比較して、アプリケーション変更の影響範囲を検出することもできる。
更にユーザインタフェースアプリケーション開発装置１は、図示しない画面生成部を更に備えることもできる。画面生成部は、表示入力データ項目に対応して、あらかじめ定められた画面レイアウトに関するルールに従って画面生成を自動的に行なうものである。またユーザインタフェースアプリケーション開発装置１は、外部仕様生成部を更に備えることもできる。外部仕様生成部は、プログラム開発用仕様書データに対応し、ユーザインタフェースアプリケーションのモデルを表す内部仕様の情報を、あからじめ定められた定義に従ってフィルタリングし、外部仕様を表すための追加情報と合わせて外部仕様文書を自動生成するものである。
ユーザインタフェースアプリケーション開発装置は、更にデバッグ部を備えることもできる。デバッグ部はプログラム生成部によって生成されたプログラムのデバッグを行なうものであり、プログラム生成部がプログラムの自動生成にあたってプログラム内にイベントを発行する命令を埋め込み、デバッグ部がデバッグ時にそのイベントを受け取り、イベント発行命令の埋め込み箇所をプログラムの実行箇所として識別することもでき、またプログラム生成部がイベント発行に対応する処理としてブレークポイントを示す情報を設定し、デバッグ部がその情報を検出した時、画面上でそのブレークポイントに対応する部分を強調することもでき、更にイベントにそのイベント発行命令の埋め込み箇所で扱われるデータを埋め込み、そのデータと仕様書データを表す図上でのクラスとを識別子によって対応づけ、デバッグ部がイベントを受け取った時、そのデータの種類と値とを検出することもできる。この場合、デバッグ部が検出されたデータの値を保存し、アプリケーションが変更された後のデバッグ時に同一箇所のデータと比較し、アプリケーション変更の影響範囲を検出することもできる。
次に本発明のユーザインタフェースアプリケーション開発装置は、図１のプログラム生成部３に代わって処理実行部を備えることもできる。処理実行部は仕様書データ読み込み部２によって読み込まれた仕様書データを解釈し、その解釈結果に対応して、ユーザインタフェースアプリケーションの処理を実行するものである。
またユーザインタフェースアプリケーション開発装置１は、図１におけると同様に、仕様書データ読み込み部２と、プログラム生成部３とを備える。但し、仕様書データ読み込み部２は、それぞれ対応する処理が定められる複数の画面の間での遷移が記述された形式の画面遷移図に相当し、画面と表示入力データ項目との間の関連づけ、および表示入力データ項目と画面レイアウトとの間の関連づけがなされるべきプログラム開発仕様書データを読み込むものであり、プログラム生成部３はその仕様書データを用いてユーザインタフェースアプリケーションのプログラムを自動生成するものである。そして前述の対応する処理の内容などを変更しながら、仕様書データ読み込み部２とプログラム生成部３との動作を繰り返すことによって、例えば分析、設計、実装、および検証のフェーズを繰り返すプログラムの反復開発を行なうことができる。
次にユーザインタフェースアプリケーションの開発方法として、画面と処理とが交互に記述される形式の画面遷移図に相当し、画面と表示入力データ項目との間の関連づけ、および表示入力データ項目と画面レイアウトとの間の関連づけがなされたプログラム開発用仕様書データを読み込み、その仕様書データを用いて、ユーザインタフェースアプリケーションのプログラムを自動生成する方法が用いられ、この方法を実現するためのプログラムが用いられる。
図２は本実施形態におけるユーザインタフェースアプリケーション開発のための定義の全体像である。同図において定義は画面遷移定義１１、ビジネスフロー定義１２、画面項目定義１３、および画面レイアウト定義１４によって構成され、ビジネスフロー定義１２は外部コンポーネント１５、および中間データ定義１６と関連している。
画面遷移定義１１は、図示しない初期状態と最終状態、画面アクティビティ２１、処理アクティビティ２２、パラメータ２３、アクティビティ間遷移２４、パラメータ間フロー２５、および画面遷移定義１１全体の中での部分的な画面遷移を示す画面遷移アクティビティ２６によって、画面遷移の状態を表現するものである。
初期状態と最終状態は、それぞれ画面遷移が開始される位置と終了する位置を定義するものであり、画面アクティビティ２１は画面レイアウト定義１４の参照処理と、入力パラメータ、出力パラメータを持ち、入力パラメータを基に画面レイアウトを利用して画面表示を行なう。例えばクライアント（ユーザ）側から入力されたデータは出力パラメータに代入される。
処理アクティビティ２２は、ビジネスフロー定義１２の参照処理と、入力パラメータ、出力パラメータを持ち、入力パラメータをビジネスフローに渡して処理の実行を依頼し、処理が終了した時点でビジネスフローから出力されるデータを出力パラメータに代入する。
パラメータ２３はデータオブジェクトを示し、画面項目定義１３によって定義される。関連するパラメータ間フロー２５では、フローが出力パラメータから入力パラメータに対するものとして定義され、後述するように出力パラメータの内容が入力パラメータに代入される。
アクティビティ間遷移２４には、次のようなルールがあるものとする。
▲１▼  初期状態からは処理アクティビティ２２のみに遷移できる。
▲２▼  画面アクティビティ２１からは処理アクティビティ２２のみに遷移できる。この遷移には条件としてアクションガードを付けることができる。このアクションガードとしての条件に対しては、クライアント側からサーバ側にイベントが送られるにあたってクライアント側で押されるボタンを割り付けることによって、そのガード条件が満足されたか否かが識別される。また画面アクティビティ２１から、後述するように“Ｒｅｔｒｙ  Ｅｒｒｏｒ”のガード付き遷移を記述した場合には、リトライとなる対象のターゲットは同一の画面アクティビティとなる。
▲３▼  処理アクティビティ２２からは画面アクティビティ２１、または処理アクティビティ２２、または最終状態のいずれかに遷移できる。
画面遷移アクティビティ２６は、画面遷移定義１１の中での部分的な他の画面遷移図を参照するものであり、入力パラメータと出力パラメータを持つ。入力パラメータに入力された内容は参照先、すなわち別の図としての画面遷移図の入力パラメータとなる。参照先の画面遷移図側での処理が終了すると、その時の出力パラメータが画面遷移アクティビティ２６の出力パラメータに代入される。
画面項目定義１３は画面表示のための項目を定義するものである。項目は名前と型から構成され、型としては文字列、整数、実数、日付、列挙、複合型などがあり、更に別途定義することも可能である。
画面項目定義１３によって定義される項目に対しては、画面項目制約定義２８が必要に応じて定義される。項目の型毎に次のような制約項目を設定することが可能である。制約の必要に応じて外部で定義することもできるため、制約はここにあるだけに限らない。
また制約として記述されている条件のチェックを画面上、すなわちクライアント側で行なうか、サーバで行うかを指定することができる。これによってアプリケーションとしてのプログラムの自動生成にあたって、どの部分で処理を実行するコードを出力するかが決定される。
文字列に対する制約としては最小桁数制限、最大桁数制限、文字種制限、および必須入力などがある。必須入力とは、その文字列の入力が必ず必要か否かを指定するものである。
整数と実数については最小値制限、最大値制限、必須入力などの制約があり、日付については存在するかどうかや、必須入力などの制約がある。
列挙については単一選択制限、すなわち１つだけを必ず選択するという制限や、必須入力などが、複合型については内包される項目についてそれぞれの制約内容が適用される。
次に図２のビジネスフロー定義１２については図示しない初期状態と最終状態、ロジックアクティビティ３１、図示しない判断やパラメータ３２、アクティビティ間遷移３３、パラメータ間フロー３４、およびビジネスフローアクティビティ３５が定義され、処理の詳細が表現される。
初期状態、最終状態はそれぞれビジネスフローを開始する位置と終了する位置を定義するものであり、ロジックアクティビティ３１は基本的に外部コンポーネント１５を参照する処理に相当し、入力パラメータと出力パラメータとを持つ。入力パラメータを外部コンポーネント１５に渡して処理の実行を依頼し、処理が終了した時点で外部コンポーネント１５の出力を出力パラメータに代入する。
図示しない判断は、入力パラメータを持ち、パラメータの内容に応じた分岐が行なわれる。パラメータ３２はデータオブジェクトを示し、画面項目定義１３、または中間データ定義１６によって定義される。
アクティビティ間遷移３３は画面遷移定義１１におけるアクティビティ間遷移２４と同様にルールを持つ。そのルールとしては
▲１▼  初期状態からはロジックアクティビティ３１、条件判断、ビジネスフローアクティビティ３５、最終状態のいずれかに遷移できる。ロジックアクティビティ３１からは、初期状態からの遷移と同様の遷移ができる。更に条件判断からも、初期状態からと同様の遷移ができる。
▲２▼  ビジネスフローアクティビティ３５、すなわち他のビジネスフローを参照するアクティビティからはロジックアクティビティ、条件判断、ビジネスフローアクティビティ、最終状態のいずれかに遷移ができる。
パラメータ間フロー３４は、画面遷移定義１１におけると同様に出力パラメータから入力パラメータに対して定義され、出力パラメータの内容が入力パラメータに代入される。
外部コンポーネント１５は、ビジネスフロー定義１２の内部のロジックアクティビティ３１から参照され、必要な処理に対応するプログラムコードが記述されている。中間データ定義１６ではビジネスフロー定義１２の内部で利用される中間的なデータの項目定義が行なわれる。
以上説明した全てのモデル情報に対しては、追加項目としてコメント情報を追加することができる。このコメント情報は例えば自然言語のような非定型の形式で記述でき、開発の任意の段階でその記述や参照を行なうことができる。
図３、図４は画面遷移定義、図５はビジネスフロー定義、図６は画面項目定義の例の説明図である。本実施形態では仕様書データの記述形式としてアクティビティ図を利用した方法を基本として説明するが、記述形式としては例えば表形式を用いることも可能である。
図３の画面遷移定義図において、初期状態４１と最終状態４８、または４９との間で、画面遷移が定義される。この画面遷移図では基本的に処理アクティビティと画面アクティビティとの間で交互に遷移が行なわれるような形式で画面遷移が定義される。まず初期状態４１から“Ｉｎｉｔｉａｌｉｚｅ”の処理アクティビティ４２への遷移が記述され、次に“Ｉｎｐｕｔ  Ｓｃｒｅｅｎ”の画面アクティビティ４３への遷移が行なわれる。
この処理アクティビティ４２から画面アクティビティ４３への遷移にあたっては、処理アクティビティ４２の２つの出力パラメータの、画面アクティビティ４３の２つの入力パラメータへの代入を示すパラメータ間フローが点線によって示されている。また画面アクティビティ４３に対する“Ｒｅｔｒｙ  Ｅｒｒｏｒ”のガード付き遷移のターゲットが、同一の画面アクティビティ４３であることが示されている。
“Ｉｎｐｕｔ  Ｓｃｒｅｅｎ″の処理アクティビティ４３からの遷移としては“ａｃｔｉｏｎ＝ｓｅｎｄ”であるか、“Ｐｒｏｃｅｅｄ  Ｅｒｒｏｒ”であるかの条件判断に対応して“Ｓｅｎｄ”の処理アクティビティ４４、または“Ｈａｎｄｌｅ  Ｅｒｒｏｒ”の処理アクティビティ４６のいずれかへの遷移が行なわれる。
更に“Ｓｅｎｄ”の処理アクティビティ４４からは“ｒｅｓｕｌｔ”の内容によって“Ｒｅｓｕｌｔ  Ｓｃｒｅｅｎ”の画面アクティビティ４５、または“Ｈａｎｄｌｅ  Ｅｒｒｏｒ”の処理アクティビティ４６への遷移が行なわれ、“Ｈａｎｄｌｅ  Ｅｒｒｏｒ”の処理アクティビティ４６からは“Ｅｒｒｏｒ  Ｓｃｒｅｅｎ”の画面アクティビティ４７への遷移が行なわれる。
図４は画面遷移定義図上での入力データ項目と画面レイアウトの関連づけの説明図である。同図においては“Ｏｒｄｅｒ”のアクティビティの２つの入力データ項目に対してそれぞれ“ｈｅａｄ．ｊｓｐ”と“ｂｏｄｙ．ｊｓｐ”のレイアウトが定義されていることが示されている。
図５はビジネスフロー定義図の例である。この図は例えばレンタカーのビジネスに対応する。同図においては初期状態５０から“Ｃｈｅｃｋ  Ｃｏｎｄｉｔｉｏｎｓ”のロジックアクティビティ５１への遷移がまず行なわれるが、この遷移に対応して初期状態出力パラメータ５６からロジックアクティビティ５１の入力パラメータ５７に対するパラメータ間フロー、すなわち代入が行なわれることが示されている。またロジックアクティビティ５１から“Ｓｅａｒｃｈ”のロジックアクティビティ５２への遷移にあたっても、ロジックアクティビティ５１の出力パラメータ５８が、ロジックアクティビティ５２の入力パラメータに代入される。
条件判断５３の判断結果によって、結果５４が成功である場合には“Ｅｄｉｔ  Ｈｅａｄｅｒ  Ａ”のロジックアクティビティを経由して、結果５４が終了状態５５に与えられる。また結果が失敗である場合と、ロジックアクティビティ５１で例外が生じた場合には“Ｅｄｉｔ  Ｈｅａｄｅｒ  Ｂ”のロジックアクティビティを経由して、終了状態５５への遷移が行なわれる。いずれの場合にも、終了状態入力パラメータ５９が与えられる。
図６は画面項目定義の例である。中間データ項目も同じ形式で定義される。同図左側はコンポジション集約を示すクラス図の例であり、右側は複合型の例を示すクラス図である。これらのクラス図において、例えば“Ｓｅａｒｃｈ  Ｃｏｎｄｉｔｉｏｎ”というオブジェクトに対する操作（メソッド）は省略されている。
図２で説明した定義は全体像を示すものであり、例えばユーザインタフェースアプリケーションの開発の初期の段階では一部を省略して記述することが可能である。図７はそのような省略を行なう場合に最低限必要な画面遷移定義の説明図である。同図において画面遷移定義１１は、画面アクティビティ２１とアクティビティ間遷移２４だけによって表現されている。
図８はこのような省略が行なわれる場合の画面遷移の例の説明図である。同図においては初期状態から受注種別選択の画面アクティビティへの遷移が行なわれた後に、アクションが正式であるか内示であるかに対応して、正式受注登録、正式受注確認の画面への遷移が行なわれて最終状態に遷移するか、または内示受注登録、内示受注確認の画面アクティビティへの遷移が行なわれて最終状態への遷移が行なわれるかが定義される。
図７のように定義の省略を行なう場合、記述されない内容は以下のルールに従って生成されるものとする。画面レイアウト定義１４については、例えばクライアント側でアクションを指定するためのイベント発生用のボタンのみが存在するものとし、画面項目定義１３が作られている場合には、対応する画面レイアウトはあらかじめ定められたルールによって自動生成されるものとする。
画面遷移定義１１の内部の処理アクティビティ２２については、何もしないアクティビティがあるものと仮定し、画面遷移アクティビティ２６、すなわち他の画面遷移図の参照についてはそのような処理を利用せず、パラメータ２３についてはデータがないものと仮定し、パラメータ間フロー２５についてはパラメータが存在しないため、フローも存在しない。
画面項目定義１３については、一般的には表示入力項目が何もないものと仮定し、従って画面項目制約定義２８も何もないものと仮定する。
ビジネスフロー定義１２についてもビジネスフローとして何もないものと仮定し、中間データ定義１６についてもビジネスフローが存在しないため、利用すべき中間データも存在しないものとする。このような最低限の状態から色々な定義を補うことによって、少しずつ定義を完全にすることができ、ユーザインタフェースアプリケーションの開発を段階的に進めることが可能となる。
図２で説明したユーザインタフェースアプリケーション開発のための定義が完成するか、あるいは図７で説明した省略形式の未完成の定義に相当する定義体に対して、プラットフォームに依存する自動生成ツールを用いることによって、ユーザインタフェースアプリケーションとしてのＷｅｂアプリケーション、またはクライアントアプリケーションを作成することができる。
図９はそのような自動生成の説明図である。同図において定義体６１に対して、例えば前述のようにＪＳＰ／Ｓｅｒｖｌｅｔ用の自動生成ツール６２ａを用いることによって、ＪＳＰ／Ｓｅｒｖｌｅｔ用のＷｅｂアプリケーション６３ａが作成される。
同様にＷｅｂサーバ上でページを生成する仕組の１つとしてのＡｃｔｉｖｅ  ｓｅｒｖｅｒ  Ｐａｇｅｓ（ＡＳＰ）．ＮＥＴ用の自動生成ツール６２ｂを用いることによって、Ｗｅｂアプリケーション６３ｂが作成される。
またブラウザにダウンロードして実行されるＪａｖａのクライアントソフトであるＪａｖａ  Ａｐｐｌｅｔ用の自動生成ツール６２ｃを用いることによって、Ｊａｖａ  Ａｐｐｌｅｔ用のクライアントアプリケーション６３ｃが作成される。
更に、グラフィックユーザインタフェースを簡単に作成するための、ベーシックを基にしたプログラミング言語としてのＶｉｓｕａｌ  Ｂａｓｉｃ用の自動生成ツール６２ｄを用いることによって、Ｖｉｓｕａｌ  Ｂａｓｉｃ用のクライアントアプリケーション６３ｄが作成される。
図１０は、このような自動生成ツールを用いた、ユーザインタフェースアプリケーションプログラム作成処理の基本フローチャートである。同図において処理が開始されると、まずステップＳ１で、例えばテキスト形式の定義（体）が読み込まれ、ステップＳ２でその定義体が、例えばＵＭＬ言語における内部モデル、例えばＪａｖａ言語のオブジェクトモデルに変換され、ステップＳ３でそのモデルが正当であるか否かのバリディティチェックが行なわれる。このステップＳ３まではプラットフォームに依存しない処理である。
続いてステップＳ４で内部モデル構造がターゲット、すなわちプラットフォームに依存する構造、例えば後述する図１１のような構造に変換され、ステップＳ５でプログラムとしての各ファイルが出力されて処理を終了する。
このような自動生成ツールを用いたプログラム作成、すなわち定義体の変換におけるＪＳＰ／Ｓｅｒｖｌｅｔ用の自動生成ツールの動作について更に述べる。各定義体は次のルールに従って変換される。まず画面レイアウト定義は元々プラットフォームに依存するものであり、ＪＳＰによって記述される。
画面遷移定義については、１つの画面遷移定義は１つのビジネスクラスに変換される。画面アクティビティはＪＳＰによる画面表示に対応し、処理アクティビティは対応するビジネスクラスのメソッドの呼び出しに変換され、画面遷移アクティビティは他の画面遷移の呼び出しとなる。パラメータについては、画面アクティビティのパラメータは画面に入力表示されるデータに対応し、ＪＳＰへの入力となるＤａｔａ  Ｂｅａｎオブジェクトに変換される。
ビジネスクラスも同様に入出力されるデータに対応し、Ｄａｔａ  Ｂｅａｎクラスに変換される。アクティビティ間の遷移については、表示する画面や処理の順番の規定に変換され、パラメータ間のフローに対しては、データの関連の作成が行なわれる。
画面項目定義については、項目定義そのものはＤａｔａ  Ｂｅａｎクラスに変換され、画面項目制約定義については前述のチェックサイトがクライアント側かサーバ側かの指定により、Ｗｅｂクライアント側のスクリプト言語であるＪａｖａ  Ｓｃｒｉｐｔ、または項目チェッククラスに変換される。
ビジネスフローについては、ビジネスクラスの１つのメソッドに変換される。ロジックアクティビティとしては、指定された外部のコンポーネントの呼び出しコードがビジネスクラスのメソッド内に作成され、ビジネスフローアクティビティについても同様に呼び出しコードが作成される。パラメータについてはアクティビティのデータとして設定され、アクティビティ間の遷移についてはその順番が生成され、パラメータ間のフローについてはデータの関連が作成される。
中間データ定義については、Ｊａｖａ  Ｂｅａｎクラスに変換される。
図１１はこのようにして自動生成されたアプリケーションの動作を説明するための構造であり、すなわちモデル、ビュー、およびコントローラのＭＶＣモデルに相当する。
図１１において外部から、例えば全体を制御するためのコントロールｓｅｒｖｌｅｔ  ６５にリクエストが与えられると、データがＤａｔａ  Ｂｅａｎクラス６９（データフォルダに相当）に設定され、ビジネスクラス６８が動かされる。ビジネスクラス６８は外部コンポーネント７１の呼び出しなどを行なって処理を実行し、処理中にＤａｔａ  Ｂｅａｎクラス６９のデータをリード／ライトし、また処理結果のデータをライトする。
その後ＪＳＰ６６に制御が移る。ＪＳＰ６６は画面表示用のものであり、Ｄａｔａ  Ｂｅａｎクラス６９のデータを読みながら画面表示を行なう。その時、画面表示項目に制約がある場合は項目チェック用Ｊａｖａ  Ｓｃｒｉｐｔ６７がブラウザ側で動作し、制約項目違反があればエラーとして検出される。最初にコントロールＳｅｒｖｌｅｔ  ６５側からＤａｔａ  Ｂｅａｎクラス６９にデータが与えられた場合にも、項目チェッククラス７０によって制約項目のチェックを行なうことができる。
このような動作を更に詳細に記述すると次のようになる。
１．ブラウザにおいて送信ボタンが押される。
２．項目チェック用Ｊａｖａ  Ｓｃｒｉｐｔ６７がデータ内容をチェックする。内容がエラーであり、「Ｒｅｔｒｙ  Ｅｒｒｏｒ」遷移がある場合、送信を行なわずエラーメッセージを表示する。
３．ブラウザからコントロールＳｅｒｖｅｒ６５にリクエストが送られる。
４．データをＤａｔａ  Ｂｅａｎクラス６９に設定し、項目チェッククラス７０がその内容をチェックする。内容がエラーであり、「Ｒｅｔｒｙ  Ｅｒｒｏｒ」遷移がある場合、元の画面を再表示し、エラーを表示する。
５．現在のビジネスフローに対応したビジネスクラス６８を呼び出す。
６．ビジネスフローの定義に従って外部コンポーネント７１を呼び出す。
７．画面遷移の定義に従ってＪＳＰ６６に制御が移る。
８．ＪＳＰ６６がＤａｔａ  Ｂｅａｎクラス６９よりデータを取得して表示する。
本実施形態においては、図９で説明したように、プラットフォームに依存しない定義体をプラットフォームに依存する自動生成ツールによって読み込み、ユーザインタフェースプログラムを自動生成する代わりに、定義体６１をそのまま解釈しながら、アプリケーションとして実際の処理を行なうことも可能である。図１２はそのような場合の動作形式の説明図である。同図においては画面レイアウト定義７６、画面遷移定義８１、ビジネスフロー定義８２、項目制約定義８３、画面項目定義８４、中間データ項目定義８５がそのまま与えられ、図１１の項目チェック用Ｊａｖａ  Ｓｃｒｉｐｔ６７に代わるＪａｖａ  Ｓｃｒｉｐｔ生成エンジン７７、ビジネスクラス６８に代わるビジネスフローエンジン７８、Ｄａｔａ  Ｂｅａｎクラス６９に代わるデータコントロールエンジン７９、項目チェッククラス７０に代わる項目チェックエンジン８０が備えられ、コンパイラとインタプリタとに相当する動作が実行される。
次に本実施形態では、画面項目定義から画面レイアウトを自動生成することができる。画面項目定義については、図２で説明したように文字列、整数、実数、日付、列挙、複合型などの型があり、その型と画面レイアウトにおける表示部品との対応づけを行なうことによって、自動生成が可能となる。その他の型が定義されている場合には、その型毎に画面レイアウト生成のルールを定めることで、その型に対応することができる。
本実施形態では型が文字列、整数、実数、日付である場合には、画面レイアウトにおけるテキストフィールドに、列挙に対してはラジオボタンに、複合型に対しては表に対応させることによって、画面レイアウトの自動生成が可能となる。
次に外部仕様の生成について説明する。本実施形態では仕様を定義した定義体から、仕様生成ツールを用いることによって外部仕様の文書が生成される。一般にアプリケーションを実行するための内部仕様と、顧客に提供するための外部仕様には次のような違いがある。
外部仕様には顧客から要求された仕様や、外部仕様の著者などの非定型の追加情報が必要となる。定義体に用意されるコメントを記述するための欄を使って、これらの情報を付加することができる。
外部仕様としては、内部仕様に相当する定義体の全ての情報が必ずしも必要ではなく、仕様生成ツールによってこれらの情報をフィルタリングすることができる。また外部仕様には、逆に顧客特定のレイアウト情報などが必要であり、外部仕様のレイアウト定義を使って、これらの情報を追加することができる。さらに非定型の追加情報をモデルの拡張情報として、外部仕様の文書と内部仕様の文書とを合わせて、１つのモデル情報として、ユーザインタフェースアプリケーション開発装置としてのコンピュータの記憶装置に格納することもできる。
図１３は自動生成ツールによるアプリケーションの自動生成と、仕様生成ツールによる外部仕様文書の生成の説明図である。図９で説明した自動生成ツール６２による定義体６１からアプリケーション６３の自動生成と同時に、外部仕様８９を外部使用レイアウト定義８７から仕様生成ツール８８によって自動生成することができる。
図１４はこの外部仕様生成処理の基本フローチャートである。同図においてまずステップＳ１、およびＳ２で図１０におけると同様に定義の読み込みと、内部モデルへの変換が行なわれる。そしてステップＳ３でバリディティチェックが行なわれ、プラットフォームに依存しない処理がここまでで終了する。
続いてステップＳ７で外部仕様レイアウト定義８７の読み込みが行なわれ、ステップＳ８でレイアウトに内部モデルがはめ込まれる。例えば画面レイアウトとして図の表示領域と表の表示領域とが定められている場合には、例えば画面遷移図が図の表示領域に、またクラス情報が表の表示領域にはめ込まれ、ステップＳ９で作成された外部仕様８９が出力されて、処理を終了する。
本実施形態ではプログラムの実行時、あるいはデバッグ時に、命令の実行箇所を検出することを可能とするために、プログラム生成に際して定義上の実行位置を示すイベントを、定義上の実行位置が変わるたびに発行する命令が埋め込まれる。これによってプログラムの実行時、あるいはデバッグ時に、命令の実行箇所や、イベントに付属しているデータの値の検出を行うことが可能となる。
図１５はこのような実行箇所検出と、ブレークポイント設定の例の説明図である。同図において、定義体６１側からデバッグ実行が指定されると、自動生成ツール６２を利用して▲１▼でアプリケーション６３が生成される。この時、定義上の各アクティビティとデータ項目に識別子を割りあて、生成されたコードによってそのアクティビティが実行される時、割りあてられた識別子をイベントとして送出するためのコードを挿入する。
▲２▼でアクティビティがアプリケーション６３によって実行されるにあたって、イベントが発行される。イベントに画面項目Ｃが指定されている場合には、図に示されるように画面項目Ｃの値がイベントに付属させられて、デバッグツール９１に与えられる。
デバッグツール９１は▲３▼でイベントを受け取り、受け取った識別子に該当する定義体上のアクティビティを認識することができる。
通常はその後も実行が継続されるが、▲４▼で示されるように識別子によって識別される処理Ｂに対応してブレークポイントが設定されている場合には、アプリケーションの実行は一旦停止され、該当するアクティビティがハイライト表示される。
更にデバッグツール９１は画面項目の認識も可能である。▲５▼で示されるように、画面項目Ｃにはデータの値も付属しているため、処理Ｂ側から入力されるデータの値を表示することもできる。
次に本実施形態におけるテストの実行について説明する。テストデータ生成ツールを利用して、画面項目定義と画面項目制約定義に基づいてテストデータを生成し、画面が表示された時にそのデータを自動入力することによって、テストを自動的に実行することができる。
図１６はこのテスト実行方式の説明図である。図１６において定義体Ｐ６１から▲１▼で自動生成ツール６２によってアプリケーションＱ６３が自動生成される。
定義体Ｐ６１に対応して、▲２▼でテストデータ生成ツールによって画面項目Ｃと画面項目制約ＤからテストデータＲ９２が生成される。画面項目Ｃは画面Ａからの出力（ユーザによる入力）、および処理Ｂへの入力を表し、項目Ｅ，Ｆ，Ｇから構成される。それぞれの項目に対しては制約が設定され、その制約は画面項目制約Ｄによって定義される。
アプリケーションＱ６２の実行時には、テストデータＲ９２がアプリケーションＱ６２上のコントロールＳｅｒｖｌｅｔを呼び出す。
コントロールＳｅｒｖｌｅｔは、定義体の定義に従って画面からのデータ（テストデータＲ）を受け取って、項目チェッククラスを▲４▼で呼び出し、項目Ｅ，Ｆ，Ｇの内容が制約を満たすかどうかを判定する。
テストデータの生成はあらかじめ定められたルールに従って行なわれるものとする。ルールは型毎に定められる。ルールが定められていない型を定義した場合には、ルールもそれに伴って定めることによって、その型のテストデータを生成することができる。また次に記述されている型についても、必要に応じてルールの変更や追加を行なうことができる。
文字列については最小桁数制限の制約に対応して、空文字列、（最小桁数−１）桁の文字数、（最小桁数）桁の文字列、および（最小桁数＋１）桁の文字列などのテストデータが生成される。このうち最初の２つは制約に違反するテストデータとなり、このようなテストデータが用いられた場合にはエラーが検出されなければならないことになる。
最大桁数制限の制約に対しては、空文字列、（最大桁数−１）桁の文字列、（最大桁数）桁の文字列、（最大桁数＋１）桁の文字列などのテストデータが、文字種制限の制約に対しては適合する文字列と、適合しない文字列のテストデータが作成され、必須入力の制約に対しては、空文字列と、空でない文字列とのテストデータが生成される。
整数および実数の型に対しては、最小値制限の制約に対応して（最小値−１）、（最小値）、および（最小値＋１）のテストデータが、最大値制限の制約に対しては（最大値−１）、（最大値）、および（最大値＋１）のテストデータが、また必須入力の制約に対しては未入力、すなわちデータを入力しない状態、および任意の数値のテストデータが用いられる。
日付の型については、存在するかどうかの制約に対して、存在する日付、存在しない日付（２００３年２月２９日など）、閏年で存在する日付（２００４年２月２９日など）のテストデータが、また必須入力の制約に対しては未入力、または存在する日付のテストデータが生成される。列挙の型については、単一選択制限の制約に対して、未選択、すなわち全く選択の行なわれていないテストデータ、単一選択、２個選択、および全選択のテストデータが、必須入力の制約に対しては未選択、単一選択、２個選択、全選択のテストデータが作成される。
複合型のテストデータとしては、内包される項目についてそれぞれの制約内容を適用したテストデータが生成される。
次に仕様書データなどが変更された場合の影響範囲の検出について説明する。テストデータを利用して、定義体修正後の影響範囲の検出を行なうことができる。すなわちテストデータの生成とテスト実行とを説明した図１６の仕組において、イベント発行のタイミングにおける命令の実行位置とデータを保存しておき、定義体を修正した後に同じテストデータを利用したテストを行なった時、同じイベント発行のタイミングにおける命令の実行位置とデータを保存されている値と比較することによって、定義体修正の影響範囲を検出することができる。
図１７はこのような定義体修正後の影響範囲検出動作の説明図である。同図において、▲１▼で定義体Ｐ６１からアプリケーションＱ６２の自動生成とテストデータＲ９２の生成が行なわれ、▲２▼でテストデータＲ９２が呼び出され、アプリケーションＱ６２の実行が行なわれる。そして▲３▼でイベント発行のタイミングにおいて、命令の実行位置とデータがデバッグツールＳ９１に渡され、▲４▼でその位置とデータが実行結果Ｔとして保存される。
▲５▼で定義体Ｐが修正され、定義体Ｐ´６１´が得られる。▲６▼で修正された定義体からアプリケーションＱ´６２´が生成され、以後▲７▼，▲８▼で修正前と同様にテストデータＲ９２が呼び出され、イベント発行のタイミングで命令の実行位置とデータがデバッグツールＳ９１に渡され、▲９▼で以前の実行結果Ｔと比較することによって、データが異なっている場合には、その時の命令の実行位置とデータの内容が定義体Ｐ´６１´上の位置として▲１０▼で表示される。
次に本実施形態におけるユーザインタフェースアプリケーションの開発過程について図１８を用いて説明する。本実施形態では、例えば図７で説明した最低限の画面遷移定義から出発して分析、設計、実装、および検証のフェーズを反復的に繰り返すことによって、ユーザインタフェースアプリケーションの段階的な開発が可能となる。
まず分析フェーズでは、どのように定義体を記述すべきか、例えば顧客側の要求項目から分析が行なわれる。設計フェーズでは、分析フェーズで得られる分析結果に基づき定義体が作成され、実装フェーズでは定義体からアプリケーションやテストデータが生成され、最後の検証フェーズで生成されたアプリケーションにテストデータが投入され、アプリケーションの試験が行なわれる。試験の結果は定義体の位置として示すことができるため、修正が必要な場合は定義体のどの部分を変更すべきか、再び分析フェーズに戻って検討が行なわれる。
図１８においては、図７で説明した最低限の定義状態、すなわち最も小さい状態として、最も内側から分析フェーズが始まることが、右廻りに回転する実線として示されている。各フェーズを繰り返すことにより定義体の大きさなどは大きくなり、やがて最後の検証フェーズで修正が必要がないと判定された時点で開発を終了する。なお実装フェーズの線が細くなっているのは、前述のように本実施形態では自動生成ツールを用いて実際にプログラムコードを開発することは必ずしも必要がないこと、すなわち図１２で説明したように、各種の定義を読み込み、それらを解釈して実行することにより、プログラムコードそのものの生成が必ずしも必要がないことを意味している。
以上詳細に説明したように本発明によれば、画面と処理とを交互に記述する形式で、ユーザインタフェースアプリケーションに対応する画面遷移図に相当するプログラム開発用仕様書データを作成し、そのデータを用いてユーザインタフェースアプリケーションを自動生成することが可能となる。これによってユーザインタフェースアプリケーションの開発、および保守を容易にすることができ、また仕様書データなどの定義上でのデバッグをサポートすることができ、分析、設計、実装、および検証のフェーズを繰り返す反復開発が可能となり、プログラム開発の効率化と保守性の向上に寄与するところが大きい。
【産業上の利用可能性】  本発明は、例えばＷｅｂアプリケーションなどのユーザインタフェースアプリケーションのプログラムを開発して、そのプログラムをユーザ対象のビジネス業者などに提供するソフトウエア開発産業などにおいて利用可能である。
【図１】
2004104824.tif 000003
【図２】
2004104824.tif 000004
【図３】
2004104824.tif 000005
【図４】
2004104824.tif 000006
【図５】
2004104824.tif 000007
【図６】
2004104824.tif 000008
【図７】
2004104824.tif 000009
【図８】
2004104824.tif 000010
【図９】
2004104824.tif 000011
【図１０】
2004104824.tif 000012
【図１１】
2004104824.tif 000013
【図１２】
2004104824.tif 000014
【図１３】
2004104824.tif 000015
【図１４】
2004104824.tif 000016
【図１５】
2004104824.tif 000017
【図１６】
2004104824.tif 000018
【図１７】
2004104824.tif 000019
【図１８】
2004104824.tif 000020
【手続補正書】
【提出日】平成17年4月14日(2005.4.14)
【手続補正１】
【補正対象書類名】明細書
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【書類名】      明細書
【特許請求の範囲】
【請求項１】  ユーザインタフェースアプリケーションの開発装置において、
画面と処理とが交互に記述される形式の画面遷移図に相当し、画面と表示入力データ項目との間の関連付け、および表示入力データ項目と画面レイアウトとの間の関連付けがなされたプログラム開発用仕様書データを読み込む仕様書データ読み込み手段と、
該仕様書データを用いて、ユーザインタフェースアプリケーションのプログラムを自動生成するプログラム生成手段とを備えることを特徴とするユーザインタフェースアプリケーション開発装置。
【請求項２】  前記表示入力データ項目に対応して設けられる制約条件をチェックし、該条件が満足されない時、前記画面遷移図上での画面から処理への遷移を禁止する制約条件チェック手段を更に備えることを特徴とする請求項１記載のユーザインタフェースアプリケーション開発装置。
【請求項３】  前記表示入力データ項目と、該表示入力データ項目に関する制約条件とに対応してテストデータを生成し、該テストデータを前記生成されたプログラムに投入してプログラムの検証を行なうアプリケーション検証手段を更に備えることを特徴とする請求項１記載のユーザインタフェースアプリケーション開発装置。
【請求項４】  前記表示入力データ項目に対応して、あらかじめ定められた画面レイアウトに関するルールに従って、自動的に画面生成を行なう画面生成手段を更に備えることを特徴とする請求項１記載のユーザインタフェースアプリケーション開発装置。
【請求項５】  前記プログラム開発用仕様書データに対応し、前記ユーザインタフェースアプリケーションのモデルを表す内部仕様の情報をあらかじめ定められた定義に従ってフィルタリングし、外部仕様を表すための非定型の追加情報と合わせて外部仕様文書を自動生成する外部仕様生成手段を更に備えることを特徴とする請求項１記載のユーザインタフェースアプリケーション開発装置。
【請求項６】  前記プログラム生成手段によって生成されたプログラムのデバッグを行なうデバッグ手段をさらに備えると共に、
前記プログラム生成手段がプログラムの自動生成にあたってプログラム内にイベントを発行する命令を埋め込み、
前記デバッグ手段が、デバッグ時に該イベントを受け取り、該イベント発行命令の埋め込み箇所をプログラムの実行箇所として識別することを特徴とする請求項１記載のユーザインタフェースアプリケーション開発装置。
【請求項７】  ユーザインタフェースアプリケーションの開発装置において、
画面と処理とが交互に記述される形式の画面遷移図に相当し、画面と表示入力データ項目との間の関連付け、および表示入力データ項目と画面レイアウトとの間の関連付けがなされたプログラム開発用仕様書データを読み込む仕様書データ読み込み手段と、
該仕様書データを解釈し、該解釈結果に対応して、ユーザインタフェースアプリケーションの処理を実行する処理実行手段とを備えることを特徴とするユーザインタフェースアプリケーション開発装置。
【請求項８】  ユーザインタフェースアプリケーションの開発装置において、
それぞれ対応する処理が定められるべき複数の画面の間での遷移が記述された形式の画面遷移図に相当し、画面と表示入力データ項目との間の関連付け、および表示入力データ項目と画面レイアウトとの間の関連付けがなされるべきプログラム開発仕様書データを読み込む仕様書データ読み込み手段と、
該仕様書データを用いて、ユーザインタフェースアプリケーションのプログラムを自動生成するプログラム生成手段とを備え、
前記対応する処理、および２つの関連付けの内容を変更しながら、仕様書データ読み込み手段とプログラム生成手段との動作を繰り返すことを特徴とするユーザインタフェースアプリケーション開発装置。
【請求項９】  ユーザインタフェースアプリケーションの開発方法において、
画面と処理とが交互に記述される形式の画面遷移図に相当し、画面と表示入力データ項目との間の関連付け、および表示入力データ項目と画面レイアウトとの間の関連付けがなされたプログラム開発用仕様書データを読み込み、
該仕様書データを用いて、ユーザインタフェースアプリケーションのプログラムを自動生成することを特徴とするユーザインタフェースアプリケーション開発方法。
【請求項１０】  ユーザインタフェースアプリケーションの開発を行なう計算機によって使用されるプログラムにおいて、
画面と処理とが交互に記述される形式の画面遷移図に相当し、画面と表示入力データ項目との間の関連付け、および表示入力データ項目と画面レイアウトとの間の関連付けがなされたプログラム開発用仕様書データを読み込む手順と、
該仕様書データを用いて、ユーザインタフェースアプリケーションのプログラムを自動生成する手順とを計算機に実行させるためのプログラム。
【発明の詳細な説明】
【０００１】
【技術分野】
本発明はプログラムの開発および実行方式に係わり、更に詳しくはユーザインタフェースを持つアプリケーションのプログラムを自動生成することを可能とし、プログラムの開発効率と保守性を上げるユーザインタフェースアプリケーション開発装置、および開発方法に関する。
【０００２】
【背景技術】
近年ソフトウエアの設計方法として、オブジェクト指向技術を用いた方法が広範に用いられている。特にＵＭＬ（ユニファイド・モデリング・ランゲージ）というプラットフォームに依存しない言語と、オブジェクト指向言語、例えばＪａｖａとを組み合わせたＷｅｂアプリケーションの開発方式が注目されている。
【０００３】
このようなソフトウエアの開発方法としては、できるだけプログラムあるいはその部品の自動生成が可能な方法が望まれている。このようなプログラムの自動生成については次のような従来技術がある。
【０００４】
【特許文献１】  特開平６−２３０９４９号公報「プログラム自動生成装置」
【特許文献２】  特開平１１−２３７９８２号公報「ソフトウエア部品開発支援装置」
【特許文献３】  特開２０００−３３９１４９号公報「状態遷移モデル作成方法および装置」
【特許文献４】  特開２０００−１１６９１１号公報「オブジェクト指向プログラムの自動生成装置」
【０００５】
特許文献１には、制御対象システムを構成するユニットの変更にあたって、変更のなかったユニットに関する仕様を再利用することができ、ソフトウエアの生産効率を向上させ、またユニットの数が多くなった場合にもコンパクトで簡明な仕様記述を行なうことができるプログラム自動生成装置が開示されている。
【０００６】
特許文献２には、オブジェクト指向ソフトウエアにおいて再利用可能な部品の開発を行うために、ある問題領域のアプリケーションに共通となる要求仕様を分析して得られる仕様の不変／変動部に関する情報を利用して、再利用可能な部品の開発を支援する技術が開示されている。
【０００７】
特許文献３には、状態遷移モデルの作成において状態抽出、入力イベント抽出、アクション抽出、および出力イベント抽出に必要とされる時間を短縮することができる技術が開示されている。
【０００８】
特許文献４には、オブジェクト指向プログラムの開発において静的部分のプログラムコードの自動生成と共に動的部分のプログラムコードの自動生成を行なって、ソフトウエア開発の作業効率を向上させることができるプログラムの自動生成装置が開示されている。
【０００９】
しかしながらまず特許文献１では、状態遷移モデルでユニット間の関係を記述しなければならない。例えばユーザインタフェースアプリケーションにおける、クライアント側の画面と表示データ項目、画面レイアウトの関係を状態遷移モデルで記述しなければならず、開発に手間がかかるという問題点があった。
【００１０】
特許文献２では、要求仕様の分析モデルが設計情報に変換され、オブジェクト指向のソフトウエア部品が開発されるが、設計モデルの定義によって、例えばＷｅｂアプリケーションのプログラムに自動変換することは困難であった。
【００１１】
特許文献３では、状態遷移表に加えて、更にメッセージシーケンスチャートを記述する必要があり、プログラムの自動生成までには手間がかかるという問題点があった。
【００１２】
特許文献４では、動的部分の定義を抽出し、ステートマシンツリーを構築した後に、静的部分と統合してプログラムコードを生成する必要があり、最終プログラム製品の開発までには、手数を要するという問題点があった。
【００１３】
【発明の開示】
本発明の目的は、ユーザインタフェースアプリケーションの開発においてプログラム開発用仕様書データの作成に工夫を加えることによって、ユーザインタフェースアプリケーションプログラムの自動生成を容易にする開発装置、および開発方法を提供することである。
【００１４】
本発明のユーザインタフェースアプリケーション開発装置は、仕様書データ読み込み手段と、プログラム生成手段とを備える。
仕様書データ読み込み手段は、画面と処理とが交互に記述される形式、例えば１つの画面と１つ以上の処理とが交互に記述される形式の画面遷移図に相当し、画面と表示入力データ項目との間の関連付け、および表示入力データ項目と画面レイアウトとの関連付けがなされたプログラム開発用仕様書データを読み込むものであり、プログラム生成手段は、この仕様書データを用いて、ユーザインタフェースアプリケーションのプログラムを自動生成するものである。
【００１５】
また本発明のユーザインタフェースアプリケーション開発装置は、仕様書データ読み込み手段と、処理実行手段とを備える。
仕様書データ読み込み手段は、前述と同様のプログラム開発用仕様書データを読み込み、処理実行手段は読み込まれた仕様書データを解釈し、その解釈結果に対応して、ユーザインタフェースアプリケーションの処理を実行するものである。
【００１６】
更に本発明のユーザインタフェースアプリケーション開発装置は、仕様書データ読み込み手段とプログラム生成手段とを備える。
仕様書データ読み込み手段は、それぞれ対応する処理が定められる複数の画面の間での遷移が記述された形式の画面遷移図に相当し、画面と表示入力データ項目との間の関連付け、および表示入力データ項目と画面レイアウトとの間の関連づけがなされるべきプログラム開発仕様書データを読み込むものであり、プログラム生成手段は、その仕様書データを用いて、ユーザインタフェースアプリケーションのプログラムを自動生成するものであり、仕様と前述の２つの関連づけの内容が変更されながら、プログラムが反復的に開発される。
【００１７】
以上のように本発明によれば、プログラム開発用仕様書データとして工夫された形式、すなわち画面と処理とが交互に記述される形式の画面遷移図に相当する仕様書データを用いて、ユーザインタフェースアプリケーションのプログラムの自動生成、またはアプリケーションの処理の実行が行われる。
【００１８】
【発明を実施するための最良の形態】
図１は本発明のユーザインタフェースアプリケーション開発装置の原理構成ブロック図である。同図において開発装置１は、仕様書データ読み込み部２と、プログラム生成部３とを備える。
【００１９】
仕様書データ読み込み部２は、画面と処理とが交互に記述される形式の画面遷移図に相当し、画面と表示入力データ項目との間の関連づけ、および表示入力データ項目と画面レイアウトとの間の関連づけがなされたプログラム開発用仕様書データ、例えばＵＭＬ言語で書かれた仕様書データを読み込むものであり、プログラム生成手段３は、その仕様書データ、および例えばビジネスフロー定義図などを用いて、プラットフォームに依存した形式のユーザインタフェースアプリケーションプログラムを、例えばJava Server Pages(JSP)/Servlet用の自動生成ツールを用いて自動生成するものである。
【００２０】
ここでＪＳＰ／ServletはＪａｖａ言語によりＷｅｂサーバ処理を行 い、ＨＴＭＬ形式のファイルをＷｅｂブラウザに送るものである。
ユーザインタフェースアプリケーション開発装置１は、図示しない制約条件チェック部を更に備えることも可能である。制約条件チェック部は、表示入力データ項目に対応して設けられる制約条件をチェックし、その条件が満足されない時に画面遷移図上での画面から処理への遷移を禁止するものであり、この場合、制約条件に対応して制約条件のチェック箇所を指定する情報が与えられ、制約条件チェック部がその指定に対応してチェックを行なうことも可能である。
【００２１】
またユーザインタフェースアプリケーション開発装置１は、更に図示しないアプリケーション検証部を備えることもできる。アプリケーション検証部は表示入力データ項目に対応してテストデータを生成し、そのテストデータを生成されたプログラムに投入してプログラムの検証を行なうものである。この場合、アプリケーション検証部がプログラムの検証結果を保存し、プログラム開発用仕様書データなどが変更された時に、同一のテストデータを用いて変更後のプログラムを検証した結果と比較して、アプリケーション変更の影響範囲を検出することもできる。
【００２２】
更にユーザインタフェースアプリケーション開発装置１は、図示しない画面生成部を更に備えることもできる。画面生成部は、表示入力データ項目に対応して、あらかじめ定められた画面レイアウトに関するルールに従って画面生成を自動的に行なうものである。またユーザインタフェースアプリケーション開発装置１は、外部仕様生成部を更に備えることもできる。外部仕様生成部は、プログラム開発用仕様書データに対応し、ユーザインタフェースアプリケーションのモデルを表す内部仕様の情報を、あからじめ定められた定義に従ってフィルタリングし、外部仕様を表すための追加情報と合わせて外部仕様文書を自動生成するものである。
【００２３】
ユーザインタフェースアプリケーション開発装置は、更にデバッグ部を備えることもできる。デバッグ部はプログラム生成部によって生成されたプログラムのデバッグを行なうものであり、プログラム生成部がプログラムの自動生成にあたってプログラム内にイベントを発行する命令を埋め込み、デバッグ部がデバッグ時にそのイベントを受け取り、イベント発行命令の埋め込み箇所をプログラムの実行箇所として識別することもでき、またプログラム生成部がイベント発行に対応する処理としてブレークポイントを示す情報を設定し、デバッグ部がその情報を検出した時、画面上でそのブレークポイントに対応する部分を強調することもでき、更にイベントにそのイベント発行命令の埋め込み箇所で扱われるデータを埋め込み、そのデータと仕様書データを表す図上でのクラスとを識別子によって対応づけ、デバッグ部がイベントを受け取った時、そのデータの種類と値とを検出することもできる。この場合、デバッグ部が検出されたデータの値を保存し、アプリケーションが変更された後のデバッグ時に同一箇所のデータと比較し、アプリケーション変更の影響範囲を検出することもできる。
【００２４】
次に本発明のユーザインタフェースアプリケーション開発装置は、図１のプログラム生成部３に代わって処理実行部を備えることもできる。処理実行部は仕様書データ読み込み部２によって読み込まれた仕様書データを解釈し、その解釈結果に対応して、ユーザインタフェースアプリケーションの処理を実行するものである。
【００２５】
またユーザインタフェースアプリケーション開発装置１は、図１におけると同様に、仕様書データ読み込み部２と、プログラム生成部３とを備える。但し、仕様書データ読み込み部２は、それぞれ対応する処理が定められる複数の画面の間での遷移が記述された形式の画面遷移図に相当し、画面と表示入力データ項目との間の関連づけ、および表示入力データ項目と画面レイアウトとの間の関連づけがなされるべきプログラム開発仕様書データを読み込むものであり、プログラム生成部３はその仕様書データを用いてユーザインタフェースアプリケーションのプログラムを自動生成するものである。そして前述の対応する処理の内容などを変更しながら、仕様書データ読み込み部２とプログラム生成部３との動作を繰り返すことによって、例えば分析、設計、実装、および検証のフェーズを繰り返すプログラムの反復開発を行なうことができる。
【００２６】
次にユーザインタフェースアプリケーションの開発方法として、画面と処理とが交互に記述される形式の画面遷移図に相当し、画面と表示入力データ項目との間の関連づけ、および表示入力データ項目と画面レイアウトとの間の関連づけがなされたプログラム開発用仕様書データを読み込み、その仕様書データを用いて、ユーザインタフェースアプリケーションのプログラムを自動生成する方法が用いられ、この方法を実現するためのプログラムが用いられる。
【００２７】
図２は本実施形態におけるユーザインタフェースアプリケーション開発のための定義の全体像である。同図において定義は画面遷移定義１１、ビジネスフロー定義１２、画面項目定義１３、および画面レイアウト定義１４によって構成され、ビジネスフロー定義１２は外部コンポーネント１５、および中間データ定義１６と関連している。
【００２８】
画面遷移定義１１は、図示しない初期状態と最終状態、画面アクティビティ２１、処理アクティビティ２２、パラメータ２３、アクティビティ間遷移２４、パラメータ間フロー２５、および画面遷移定義１１全体の中での部分的な画面遷移を示す画面遷移アクティビティ２６によって、画面遷移の状態を表現するものである。
【００２９】
初期状態と最終状態は、それぞれ画面遷移が開始される位置と終了する位置を定義するものであり、画面アクティビティ２１は画面レイアウト定義１４の参照処理と、入力パラメータ、出力パラメータを持ち、入力パラメータを基に画面レイアウトを利用して画面表示を行なう。例えばクライアント（ユーザ）側から入力されたデータは出力パラメータに代入される。
【００３０】
処理アクティビティ２２は、ビジネスフロー定義１２の参照処理と、入力パラメータ、出力パラメータを持ち、入力パラメータをビジネスフローに渡して処理の実行を依頼し、処理が終了した時点でビジネスフローから出力されるデータを出力パラメータに代入する。
【００３１】
パラメータ２３はデータオブジェクトを示し、画面項目定義１３によって定義される。関連するパラメータ間フロー２５では、フローが出力パラメータから入力パラメータに対するものとして定義され、後述するように出力パラメータの内容が入力パラメータに代入される。
【００３２】
アクティビティ間遷移２４には、次のようなルールがあるものとする。
１）  初期状態からは処理アクティビティ２２のみに遷移できる。
２）  画面アクティビティ２１からは処理アクティビティ２２のみに遷移できる。この遷移には条件としてアクションガードを付けることができる。このアクションガードとしての条件に対しては、クライアント側からサーバ側にイベントが送られるにあたってクライアント側で押されるボタンを割り付けることによって、そのガード条件が満足されたか否かが識別される。また画面アクティビティ２１から、後述するように  “Retry  Error”のガード付き遷移を記述した場合には、リトライとなる対象のターゲットは同一の画面アクティビティとなる。
【００３３】
３）  処理アクティビティ２２からは画面アクティビティ２１、または処理アクティビティ２２、または最終状態のいずれかに遷移できる。
画面遷移アクティビティ２６は、画面遷移定義１１の中での部分的な他の画面遷移図を参照するものであり、入力パラメータと出力パラメータを持つ。入力パラメータに入力された内容は参照先、すなわち別の図としての画面遷移図の入力パラメータとなる。参照先の画面遷移図側での処理が終了すると、その時の出力パラメータが画面遷移アクティビティ２６の出力パラメータに代入される。
【００３４】
画面項目定義１３は画面表示のための項目を定義するものである。項目は名前と型から構成され、型としては文字列、整数、実数、日付、列挙、複合型などがあり、更に別途定義することも可能である。
【００３５】
画面項目定義１３によって定義される項目に対しては、画面項目制約定義２８が必要に応じて定義される。項目の型毎に次のような制約項目を設定することが可能である。制約の必要に応じて外部で定義することもできるため、制約はここにあるだけに限らない。
【００３６】
また制約として記述されている条件のチェックを画面上、すなわちクライアント側で行なうか、サーバで行うかを指定することができる。これによってアプリケーションとしてのプログラムの自動生成にあたって、どの部分で処理を実行するコードを出力するかが決定される。
【００３７】
文字列に対する制約としては最小桁数制限、最大桁数制限、文字種制限、および必須入力などがある。必須入力とは、その文字列の入力が必ず必要か否かを指定するものである。
【００３８】
整数と実数については最小値制限、最大値制限、必須入力などの制約があり、日付については存在するかどうかや、必須入力などの制約がある。
列挙については単一選択制限、すなわち１つだけを必ず選択するという制限や、必須入力などが、複合型については内包される項目についてそれぞれの制約内容が適用される。
【００３９】
次に図２のビジネスフロー定義１２については図示しない初期状態と最終状態、ロジックアクティビティ３１、図示しない判断やパラメータ３２、アクティビティ間遷移３３、パラメータ間フロー３４、およびビジネスフローアクティビティ３５が定義され、処理の詳細が表現される。
【００４０】
初期状態、最終状態はそれぞれビジネスフローを開始する位置と終了する位置を定義するものであり、ロジックアクティビティ３１は基本的に外部コンポーネント１５を参照する処理に相当し、入力パラメータと出力パラメータとを持つ。入力パラメータを外部コンポーネント１５に渡して処理の実行を依頼し、処理が終了した時点で外部コンポーネント１５の出力を出力パラメータに代入する。
【００４１】
図示しない判断は、入力パラメータを持ち、パラメータの内容に応じた分岐が行なわれる。パラメータ３２はデータオブジェクトを示し、画面項目定義１３、または中間データ定義１６によって定義される。
【００４２】
アクティビティ間遷移３３は画面遷移定義１１におけるアクティビティ間遷移２４と同様にルールを持つ。そのルールとしては
１）  初期状態からはロジックアクティビティ３１、条件判断、ビジネスフローアクティビティ３５、最終状態のいずれかに遷移できる。ロジックアクティビティ３１からは、初期状態からの遷移と同様の遷移ができる。更に条件判断からも、初期状態からと同様の遷移ができる。
【００４３】
２）  ビジネスフローアクティビティ３５、すなわち他のビジネスフローを参照するアクティビティからはロジックアクティビティ、条件判断、ビジネスフローアクティビティ、最終状態のいずれかに遷移ができる。
【００４４】
パラメータ間フロー３４は、画面遷移定義１１におけると同様に出力パラメータから入力パラメータに対して定義され、出力パラメータの内容が入力パラメータに代入される。
【００４５】
外部コンポーネント１５は、ビジネスフロー定義１２の内部のロジックアクティビティ３１から参照され、必要な処理に対応するプログラムコードが記述されている。中間データ定義１６ではビジネスフロー定義１２の内部で利用される中間的なデータの項目定義が行なわれる。
【００４６】
以上説明した全てのモデル情報に対しては、追加項目としてコメント情報を追加することができる。このコメント情報は例えば自然言語のような非定型の形式で記述でき、開発の任意の段階でその記述や参照を行なうことができる。
【００４７】
図３、図４は画面遷移定義、図５はビジネスフロー定義、図６は画面項目定義の例の説明図である。本実施形態では仕様書データの記述形式としてアクティビティ図を利用した方法を基本として説明するが、記述形式としては例えば表形式を用いることも可能である。
【００４８】
図３の画面遷移定義図において、初期状態４１と最終状態４８、または４９との間で、画面遷移が定義される。この画面遷移図では基本的に処理アクティビティと画面アクティビティとの間で交互に遷移が行なわれるような形式で画面遷移が定義される。まず初期状態４１から“Initialize”の処理アクティビティ４２への遷移が記述され、次に“Input  Screen”の画面アクティビティ４３への遷移が行なわれる。
【００４９】
この処理アクティビティ４２から画面アクティビティ４３への遷移にあたっては、処理アクティビティ４２の２つの出力パラメータの、画面アクティビティ４３の２つの入力パラメータへの代入を示すパラメータ間フローが点線によって示されている。また画面アクティビティ４３に対する“Retry Error”のガード付き遷移のターゲットが、同一の画面 アクティビティ４３であることが示されている。
【００５０】
“Input Screen"の処理アクティビティ４３からの遷移としては“action=send”であるか、“Proceed Error”であるかの条件判断に対応し て“Send”の処理アクティビティ４４、または“Handle Error”の処理アクティビティ４６のいずれかへの遷移が行なわれる。
【００５１】
更に“Send”の処理アクティビティ４４からは“result”の内容によって“Result Screen”の画面アクティビティ４５、または“Handle Error”の処理アクティビティ４６への遷移が行なわれ、“Handle Error ”の処理アクティビティ４６からは“Error Screen”の画面アクティビティ４７への遷移が行なわれる。
【００５２】
図４は画面遷移定義図上での入力データ項目と画面レイアウトの関連づけの説明図である。同図においては“Order”のアクティビティの２ つの入力データ項目に対してそれぞれ“head．jsp”と“body．jsp”のレイアウトが定義されていることが示されている。
【００５３】
図５はビジネスフロー定義図の例である。この図は例えばレンタカーのビジネスに対応する。同図においては初期状態５０から“Check Conditions”のロジックアクティビティ５１への遷移がまず行なわれるが、この遷移に対応して初期状態出力パラメータ５６からロジックアクティビティ５１の入力パラメータ５７に対するパラメータ間フロー、すなわち代入が行なわれることが示されている。またロジックアクティビティ５１から“Search”のロジックアクティビティ５２への遷移にあたっても、ロジックアクティビティ５１の出力パラメータ５８が、ロジックアクティビティ５２の入力パラメータに代入される。
【００５４】
条件判断５３の判断結果によって、結果５４が成功である場合には  “Edit Header A”のロジックアクティビティを経由して、結果５４が 終了状態５５に与えられる。また結果が失敗である場合と、ロジックアクティビティ５１で例外が生じた場合には“Edit Header B”のロジッ クアクティビティを経由して、終了状態５５への遷移が行なわれる。いずれの場合にも、終了状態入力パラメータ５９が与えられる。
【００５５】
図６は画面項目定義の例である。中間データ項目も同じ形式で定義される。同図左側はコンポジション集約を示すクラス図の例であり、右側は複合型の例を示すクラス図である。これらのクラス図において、例えば“Search Condition”というオブジェクトに対する操作（メソッド）は省略されている。
【００５６】
図２で説明した定義は全体像を示すものであり、例えばユーザインタフェースアプリケーションの開発の初期の段階では一部を省略して記述することが可能である。図７はそのような省略を行なう場合に最低限必要な画面遷移定義の説明図である。同図において画面遷移定義１１は、画面アクティビティ２１とアクティビティ間遷移２４だけによって表現されている。
【００５７】
図８はこのような省略が行なわれる場合の画面遷移の例の説明図である。同図においては初期状態から受注種別選択の画面アクティビティへの遷移が行なわれた後に、アクションが正式であるか内示であるかに対応して、正式受注登録、正式受注確認の画面への遷移が行なわれて最終状態に遷移するか、または内示受注登録、内示受注確認の画面アクティビティへの遷移が行なわれて最終状態への遷移が行なわれるかが定義される。
【００５８】
図７のように定義の省略を行なう場合、記述されない内容は以下のルールに従って生成されるものとする。画面レイアウト定義１４については、例えばクライアント側でアクションを指定するためのイベント発生用のボタンのみが存在するものとし、画面項目定義１３が作られている場合には、対応する画面レイアウトはあらかじめ定められたルールによって自動生成されるものとする。
【００５９】
画面遷移定義１１の内部の処理アクティビティ２２については、何もしないアクティビティがあるものと仮定し、画面遷移アクティビティ２６、すなわち他の画面遷移図の参照についてはそのような処理を利用せず、パラメータ２３についてはデータがないものと仮定し、パラメータ間フロー２５についてはパラメータが存在しないため、フローも存在しない。
【００６０】
画面項目定義１３については、一般的には表示入力項目が何もないものと仮定し、従って画面項目制約定義２８も何もないものと仮定する。
ビジネスフロー定義１２についてもビジネスフローとして何もないものと仮定し、中間データ定義１６についてもビジネスフローが存在しないため、利用すべき中間データも存在しないものとする。このような最低限の状態から色々な定義を補うことによって、少しずつ定義を完全にすることができ、ユーザインタフェースアプリケーションの開発を段階的に進めることが可能となる。
【００６１】
図２で説明したユーザインタフェースアプリケーション開発のための定義が完成するか、あるいは図７で説明した省略形式の未完成の定義に相当する定義体に対して、プラットフォームに依存する自動生成ツールを用いることによって、ユーザインタフェースアプリケーションとしてのＷｅｂアプリケーション、またはクライアントアプリケーションを作成することができる。
【００６２】
図９はそのような自動生成の説明図である。同図において定義体６１に対して、例えば前述のようにJSP/Servlet用の自動生成ツール６２ａ を用いることによって、JSP/Servlet用のＷｅｂアプリケーション６３ ａが作成される。
【００６３】
同様にＷｅｂサーバ上でページを生成する仕組の１つとしてのActive server Pages(ASP)．ＮＥＴ用の自動生成ツール６２ｂを用いることによって、Ｗｅｂアプリケーション６３ｂが作成される。
【００６４】
またブラウザにダウンロードして実行されるJavaのクライアントソフトであるJava Applet用の自動生成ツール６２ｃを用いることによって 、Java Applet用のクライアントアプリケーション６３ｃが作成される 。
【００６５】
更に、グラフィックユーザインタフェースを簡単に作成するための、ベーシックを基にしたプログラミング言語としてのVisual Basic用の自動生成ツール６２ｄを用いることによって、Visual Basic用のクライアントアプリケーション６３ｄが作成される。
【００６６】
図１０は、このような自動生成ツールを用いた、ユーザインタフェースアプリケーションプログラム作成処理の基本フローチャートである。同図において処理が開始されると、まずステップＳ１で、例えばテキスト形式の定義（体）が読み込まれ、ステップＳ２でその定義体が、例えばＵＭＬ言語における内部モデル、例えばJava言語のオブジェクトモデルに変換され、ステップＳ３でそのモデルが正当であるか否かのバリディティチェックが行なわれる。このステップＳ３まではプラットフォームに依存しない処理である。
【００６７】
続いてステップＳ４で内部モデル構造がターゲット、すなわちプラットフォームに依存する構造、例えば後述する図１１のような構造に変換され、ステップＳ５でプログラムとしての各ファイルが出力されて処理を終了する。
【００６８】
このような自動生成ツールを用いたプログラム作成、すなわち定義体の変換におけるJSP/Servlet 用の自動生成ツールの動作について更に述べる。各定義体は次のルールに従って変換される。まず画面レイアウト定義は元々プラットフォームに依存するものであり、ＪＳＰによって記述される。
【００６９】
画面遷移定義については、１つの画面遷移定義は１つのビジネスクラスに変換される。画面アクティビティはＪＳＰによる画面表示に対応し、処理アクティビティは対応するビジネスクラスのメソッドの呼び出しに変換され、画面遷移アクティビティは他の画面遷移の呼び出しとなる。パラメータについては、画面アクティビティのパラメータは画面に入力表示されるデータに対応し、JSPへの入力となるData Beanオブジェクトに変換される。
【００７０】
ビジネスクラスも同様に入出力されるデータに対応し、Data Beanク ラスに変換される。アクティビティ間の遷移については、表示する画面や処理の順番の規定に変換され、パラメータ間のフローに対しては、データの関連の作成が行なわれる。
【００７１】
画面項目定義については、項目定義そのものはData Beanクラスに変 換され、画面項目制約定義については前述のチェックサイトがクライアント側かサーバ側かの指定により、Ｗｅｂクライアント側のスクリプト言語であるJava Script、または項目チェッククラスに変換される。
【００７２】
ビジネスフローについては、ビジネスクラスの１つのメソッドに変換される。ロジックアクティビティとしては、指定された外部のコンポーネントの呼び出しコードがビジネスクラスのメソッド内に作成され、ビジネスフローアクティビティについても同様に呼び出しコードが作成される。パラメータについてはアクティビティのデータとして設定され、アクティビティ間の遷移についてはその順番が生成され、パラメータ間のフローについてはデータの関連が作成される。
【００７３】
中間データ定義については、Java Beanクラスに変換される。
図１１はこのようにして自動生成されたアプリケーションの動作を説明するための構造であり、すなわちモデル、ビュー、およびコントローラのＭＶＣモデルに相当する。
【００７４】
図１１において外部から、例えば全体を制御するためのコントロールservlet
６５にリクエストが与えられると、データがData Beanクラス６９（データフォルダに相当）に設定され、ビジネスクラス６８が動かされる。ビジネスクラス６８は外部コンポーネント７１の呼び出しなどを行なって処理を実行し、処理中にData  Beanクラス６９のデータをリード／ライトし、また処理結果のデータをライトする。
【００７５】
その後ＪＳＰ６６に制御が移る。ＪＳＰ６６は画面表示用のものであり、Data
Beanクラス６９のデータを読みながら画面表示を行なう。そ の時、画面表示項目に制約がある場合は項目チェック用Java Script６ ７がブラウザ側で動作し、制約項目違反があればエラーとして検出される。最初にコントロールServlet
６５側からData Beanクラス６９にデータが与えられた場合にも、項目チェッククラス７０によって制約項目のチェックを行なうことができる。
【００７６】
このような動作を更に詳細に記述すると次のようになる。
１．ブラウザにおいて送信ボタンが押される。
２．項目チェック用Java Script６７がデータ内容をチェックする。内 容がエラーであり、「Retry Error」遷移がある場合、送信を行なわず エラーメッセージを表示する。
３．ブラウザからコントロールServer６５にリクエストが送られる。
４．データをData Beanクラス６９に設定し、項目チェッククラス７０ がその内容をチェックする。内容がエラーであり、「Retry Error」遷 移がある場合、元の画面を再表示し、エラーを表示する。
５．現在のビジネスフローに対応したビジネスクラス６８を呼び出す。
６．ビジネスフローの定義に従って外部コンポーネント７１を呼び出す。
７．画面遷移の定義に従ってＪＳＰ６６に制御が移る。
８．ＪＳＰ６６がData Beanクラス６９よりデータを取得して表示する 。
【００７７】
本実施形態においては、図９で説明したように、プラットフォームに依存しない定義体をプラットフォームに依存する自動生成ツールによって読み込み、ユーザインタフェースプログラムを自動生成する代わりに、定義体６１をそのまま解釈しながら、アプリケーションとして実際の処理を行なうことも可能である。図１２はそのような場合の動作形式の説明図である。同図においては画面レイアウト定義７６、画面遷移定義８１、ビジネスフロー定義８２、項目制約定義８３、画面項目定義８４、中間データ項目定義８５がそのまま与えられ、図１１の項目チェック用Java Script６７に代わるJava Script生成エンジン７７、ビジネスクラス６８に代わるビジネスフローエンジン７８、Data Beanクラス６９ に代わるデータコントロールエンジン７９、項目チェッククラス７０に代わる項目チェックエンジン８０が備えられ、コンパイラとインタプリタとに相当する動作が実行される。
【００７８】
次に本実施形態では、画面項目定義から画面レイアウトを自動生成することができる。画面項目定義については、図２で説明したように文字列、整数、実数、日付、列挙、複合型などの型があり、その型と画面レイアウトにおける表示部品との対応づけを行なうことによって、自動生成が可能となる。その他の型が定義されている場合には、その型毎に画面レイアウト生成のルールを定めることで、その型に対応することができる。
【００７９】
本実施形態では型が文字列、整数、実数、日付である場合には、画面レイアウトにおけるテキストフィールドに、列挙に対してはラジオボタンに、複合型に対しては表に対応させることによって、画面レイアウトの自動生成が可能となる。
【００８０】
次に外部仕様の生成について説明する。本実施形態では仕様を定義した定義体から、仕様生成ツールを用いることによって外部仕様の文書が生成される。一般にアプリケーションを実行するための内部仕様と、顧客に提供するための外部仕様には次のような違いがある。
【００８１】
外部仕様には顧客から要求された仕様や、外部仕様の著者などの非定型の追加情報が必要となる。定義体に用意されるコメントを記述するための欄を使って、これらの情報を付加することができる。
【００８２】
外部仕様としては、内部仕様に相当する定義体の全ての情報が必ずしも必要ではなく、仕様生成ツールによってこれらの情報をフィルタリングすることができる。また外部仕様には、逆に顧客特定のレイアウト情報などが必要であり、外部仕様のレイアウト定義を使って、これらの情報を追加することができる。さらに非定型の追加情報をモデルの拡張情報として、外部仕様の文書と内部仕様の文書とを合わせて、１つのモデル情報として、ユーザインタフェースアプリケーション開発装置としてのコンピュータの記憶装置に格納することもできる。
【００８３】
図１３は自動生成ツールによるアプリケーションの自動生成と、仕様生成ツールによる外部仕様文書の生成の説明図である。図９で説明した自動生成ツール６２による定義体６１からアプリケーション６３の自動生成と同時に、外部仕様８９を外部使用レイアウト定義８７から仕様生成ツール８８によって自動生成することができる。
【００８４】
図１４はこの外部仕様生成処理の基本フローチャートである。同図においてまずステップＳ１、およびＳ２で図１０におけると同様に定義の読み込みと、内部モデルへの変換が行なわれる。そしてステップＳ３でバリディティチェックが行なわれ、プラットフォームに依存しない処理がここまでで終了する。
【００８５】
続いてステップＳ７で外部仕様レイアウト定義８７の読み込みが行なわれ、ステップＳ８でレイアウトに内部モデルがはめ込まれる。例えば画面レイアウトとして図の表示領域と表の表示領域とが定められている場合には、例えば画面遷移図が図の表示領域に、またクラス情報が表の表示領域にはめ込まれ、ステップＳ９で作成された外部仕様８９が出力されて、処理を終了する。
【００８６】
本実施形態ではプログラムの実行時、あるいはデバッグ時に、命令の実行箇所を検出することを可能とするために、プログラム生成に際して定義上の実行位置を示すイベントを、定義上の実行位置が変わるたびに発行する命令が埋め込まれる。これによってプログラムの実行時、あるいはデバッグ時に、命令の実行箇所や、イベントに付属しているデータの値の検出を行うことが可能となる。
【００８７】
図１５はこのような実行箇所検出と、ブレークポイント設定の例の説明図である。同図において、定義体６１側からデバッグ実行が指定されると、自動生成ツール６２を利用して[１]でアプリケーション６３が生成される。この時、定義上の各アクティビティとデータ項目に識別子を割りあて、生成されたコードによってそのアクティビティが実行される時、割りあてられた識別子をイベントとして送出するためのコードを挿入する。
【００８８】
[２]でアクティビティがアプリケーション６３によって実行されるにあたって、イベントが発行される。イベントに画面項目Ｃが指定されている場合には、図に示されるように画面項目Ｃの値がイベントに付属させられて、デバッグツール９１に与えられる。
【００８９】
デバッグツール９１は[３]でイベントを受け取り、受け取った識別子に該当する定義体上のアクティビティを認識することができる。
通常はその後も実行が継続されるが、[４]で示されるように識別子によって識別される処理Ｂに対応してブレークポイントが設定されている場合には、アプリケーションの実行は一旦停止され、該当するアクティビティがハイライト表示される。
【００９０】
更にデバッグツール９１は画面項目の認識も可能である。[５]で示されるように、画面項目Ｃにはデータの値も付属しているため、処理Ｂ側から入力されるデータの値を表示することもできる。
【００９１】
次に本実施形態におけるテストの実行について説明する。テストデータ生成ツールを利用して、画面項目定義と画面項目制約定義に基づいてテストデータを生成し、画面が表示された時にそのデータを自動入力することによって、テストを自動的に実行することができる。
【００９２】
図１６はこのテスト実行方式の説明図である。図１６において定義体Ｐ６１から[１]で自動生成ツール６２によってアプリケーションＱ６３が自動生成される。
定義体Ｐ６１に対応して、[２]でテストデータ生成ツールによって画面項目Ｃと画面項目制約ＤからテストデータＲ９２が生成される。画面項目Ｃは画面Ａからの出力（ユーザによる入力）、および処理Ｂへの入力を表し、項目Ｅ，Ｆ，Ｇから構成される。それぞれの項目に対しては制約が設定され、その制約は画面項目制約Ｄによって定義される。
【００９３】
アプリケーションＱ６２の実行時には、テストデータＲ９２がアプリケーションＱ６２上のコントロールServletを呼び出す。
コントロールServletは、定義体の定義に従って画面からのデータ（ テストデータＲ）を受け取って、項目チェッククラスを[４]で呼び出し、項目Ｅ，Ｆ，Ｇの内容が制約を満たすかどうかを判定する。
【００９４】
テストデータの生成はあらかじめ定められたルールに従って行なわれるものとする。ルールは型毎に定められる。ルールが定められていない型を定義した場合には、ルールもそれに伴って定めることによって、その型のテストデータを生成することができる。また次に記述されている型についても、必要に応じてルールの変更や追加を行なうことができる。
【００９５】
文字列については最小桁数制限の制約に対応して、空文字列、（最小桁数−１）桁の文字数、（最小桁数）桁の文字列、および（最小桁数＋１）桁の文字列などのテストデータが生成される。このうち最初の２つは制約に違反するテストデータとなり、このようなテストデータが用いられた場合にはエラーが検出されなければならないことになる。
【００９６】
最大桁数制限の制約に対しては、空文字列、（最大桁数−１）桁の文字列、（最大桁数）桁の文字列、（最大桁数＋１）桁の文字列などのテストデータが、文字種制限の制約に対しては適合する文字列と、適合しない文字列のテストデータが作成され、必須入力の制約に対しては、空文字列と、空でない文字列とのテストデータが生成される。
【００９７】
整数および実数の型に対しては、最小値制限の制約に対応して（最小値−１）、（最小値）、および（最小値＋１）のテストデータが、最大値制限の制約に対しては（最大値−１）、（最大値）、および（最大値＋１）のテストデータが、また必須入力の制約に対しては未入力、すなわちデータを入力しない状態、および任意の数値のテストデータが用いられる。
【００９８】
日付の型については、存在するかどうかの制約に対して、存在する日付、存在しない日付（２００３年２月２９日など）、閏年で存在する日付（２００４年２月２９日など）のテストデータが、また必須入力の制約に対しては未入力、または存在する日付のテストデータが生成される。列挙の型については、単一選択制限の制約に対して、未選択、すなわち全く選択の行なわれていないテストデータ、単一選択、２個選択、および全選択のテストデータが、必須入力の制約に対しては未選択、単一選択、２個選択、全選択のテストデータが作成される。
【００９９】
複合型のテストデータとしては、内包される項目についてそれぞれの制約内容を適用したテストデータが生成される。
次に仕様書データなどが変更された場合の影響範囲の検出について説明する。テストデータを利用して、定義体修正後の影響範囲の検出を行なうことができる。すなわちテストデータの生成とテスト実行とを説明した図１６の仕組において、イベント発行のタイミングにおける命令の実行位置とデータを保存しておき、定義体を修正した後に同じテストデータを利用したテストを行なった時、同じイベント発行のタイミングにおける命令の実行位置とデータを保存されている値と比較することによって、定義体修正の影響範囲を検出することができる。
【０１００】
図１７はこのような定義体修正後の影響範囲検出動作の説明図である。同図において、[１]で定義体Ｐ６１からアプリケーションＱ６２の自動生成とテストデータＲ９２の生成が行なわれ、[２]でテストデータＲ９２が呼び出され、アプリケーションＱ６２の実行が行なわれる。そして[３]でイベント発行のタイミングにおいて、命令の実行位置とデータがデバッグツールＳ９１に渡され、[４]でその位置とデータが実行結果Ｔとして保存される。
【０１０１】
[５]で定義体Ｐが修正され、定義体Ｐ´６１´が得られる。[６]で修正された定義体からアプリケーションＱ´６２´が生成され、以後[７]，[８]で修正前と同様にテストデータＲ９２が呼び出され、イベント発行のタイミングで命令の実行位置とデータがデバッグツールＳ９１に渡され、[９]で以前の実行結果Ｔと比較することによって、データが異なっている場合には、その時の命令の実行位置とデータの内容が定義体Ｐ´６１´上の位置として[10]で表示される。
【０１０２】
次に本実施形態におけるユーザインタフェースアプリケーションの開発過程について図１８を用いて説明する。本実施形態では、例えば図７で説明した最低限の画面遷移定義から出発して分析、設計、実装、および検証のフェーズを反復的に繰り返すことによって、ユーザインタフェースアプリケーションの段階的な開発が可能となる。
【０１０３】
まず分析フェーズでは、どのように定義体を記述すべきか、例えば顧客側の要求項目から分析が行なわれる。設計フェーズでは、分析フェーズで得られる分析結果に基づき定義体が作成され、実装フェーズでは定義体からアプリケーションやテストデータが生成され、最後の検証フェーズで生成されたアプリケーションにテストデータが投入され、アプリケーションの試験が行なわれる。試験の結果は定義体の位置として示すことができるため、修正が必要な場合は定義体のどの部分を変更すべきか、再び分析フェーズに戻って検討が行なわれる。
【０１０４】
図１８においては、図７で説明した最低限の定義状態、すなわち最も小さい状態として、最も内側から分析フェーズが始まることが、右廻りに回転する実線として示されている。各フェーズを繰り返すことにより定義体の大きさなどは大きくなり、やがて最後の検証フェーズで修正が必要がないと判定された時点で開発を終了する。なお実装フェーズの線が細くなっているのは、前述のように本実施形態では自動生成ツールを用いて実際にプログラムコードを開発することは必ずしも必要がないこと、すなわち図１２で説明したように、各種の定義を読み込み、それらを解釈して実行することにより、プログラムコードそのものの生成が必ずしも必要がないことを意味している。
【０１０５】
以上詳細に説明したように本発明によれば、画面と処理とを交互に記述する形式で、ユーザインタフェースアプリケーションに対応する画面遷移図に相当するプログラム開発用仕様書データを作成し、そのデータを用いてユーザインタフェースアプリケーションを自動生成することが可能となる。これによってユーザインタフェースアプリケーションの開発、および保守を容易にすることができ、また仕様書データなどの定義上でのデバッグをサポートすることができ、分析、設計、実装、および検証のフェーズを繰り返す反復開発が可能となり、プログラム開発の効率化と保守性の向上に寄与するところが大きい。
【０１０６】
【産業上の利用可能性】
本発明は、例えばＷｅｂアプリケーションなどのユーザインタフェースアプリケーションのプログラムを開発して、そのプログラムをユーザ対象のビジネス業者などに提供するソフトウエア開発産業などにおいて利用可能である。
【図面の簡単な説明】
【図１】  本発明のユーザインタフェースアプリケーション開発装置の原理構成ブロック図である。
【図２】  ユーザインタフェースアプリケーション開発のための定義の全体像を示す図である。
【図３】  画面遷移定義の例を示す図である。
【図４】  画面遷移定義における画面レイアウト定義の例を示す図である。
【図５】  ビジネスフロー定義の例を示す図である。
【図６】  画面項目定義の例を示す図である。
【図７】  定義の省略を行なう場合に最低限必要な画面遷移定義の説明図である。
【図８】  省略が行なわれる場合の画面遷移の例の説明図である。
【図９】  ユーザインタフェースアプリケーションの自動生成の説明図である。
【図１０】  自動生成ツールを用いたプログラム作成処理の基本フローチャートである。
【図１１】  自動生成されたアプリケーションの構造を説明する図である。
【図１２】  定義体を解釈しながら処理を行なう動作形式を説明する図である。
【図１３】  仕様生成ツールによる外部仕様文書生成の説明図である。
【図１４】  外部仕様生成処理の基本フローチャートである。
【図１５】  デバッグツールによる命令実行箇所などの検出の説明図である。
【図１６】  テストデータ生成とテスト実行動作の説明図である。
【図１７】  定義体修正の影響範囲検出動作の説明図である。
【図１８】  ユーザインタフェースアプリケーションの反復開発の説明図である。
【手続補正２】
【補正対象書類名】図面
【補正対象項目名】図１５
【補正方法】変更
【補正の内容】
【図１５】
2004104824.tif 000021
【手続補正３】
【補正対象書類名】図面
【補正対象項目名】図１６
【補正方法】変更
【補正の内容】
【図１６】
2004104824.tif 000022
【手続補正４】
【補正対象書類名】図面
【補正対象項目名】図１７
【補正方法】変更
【補正の内容】
【図１７】
2004104824.tif 000023
【国際調査報告】
2004104824.tif 000024
2004104824.tif 000025
2004104824.tif 000026
2004104824.tif 000027