WO2004104824A1

WO2004104824A1 - ユーザインタフェースアプリケーション開発装置および開発方法

Info

Publication number: WO2004104824A1
Application number: PCT/JP2003/006536
Authority: WO
Inventors: Takahide Matsutsuka; Masahiko Kamo
Original assignee: Fujitsu Limited
Priority date: 2003-05-26
Filing date: 2003-05-26
Publication date: 2004-12-02
Also published as: US20050235260A1; JPWO2004104824A1

Abstract

ユーザインタフェースを持つアプリケーションプログラムを自動生成し、プログラムの開発効率と保守性を上げることを目的とする。アプリケーション開発装置は、画面と処理とが交互に記述された形式の画面遷移図に相当し、画面と表示入力データ項目との関連付け、および表示入力データ項目と画面レイアウトとの間の関連付けがなされた仕様書データを読み込む仕様書データ読込部と、その仕様書データを用いてアプリケーションプログラムを自動生成するプログラム生成部とを備える。

Description

明細書ユーザインタフェースアプリケーション開発装置および開発方法技術分野

本発明はプログラムの開発および実行方式に係わり、更に詳しくはュ一ザインタフエースを持つアプリケーションのプログラムを自動生成することを可能とし、プログラムの開発効率と保守性を上げるユーザィンタフエースアプリケーション開発装置、および開発方法に関する。

背景技術

近年ソフトウエアの設計方法として、オブジェクト指向技術を用いた方法が広範に用いられている。特に U M L (ユニファイド ' モデリング ' ランゲージ）というプラットフォームに依存しない言語と、ォブジェクト指向言語、例えば J a V a とを組み合わせた W e bアプリケーションの開発方式が注目されている。

このようなソフトゥェァの開発方法としては、できるだけプログラムあるいはその部品の自動生成が可能な方法が望まれている。このようなプログラムの自動生成については次のような従来技術がある。

特許文献 1

特開平 6— 2 3 0 9 4 9号公報「プログラム自動生成装置」

特許文献 2

特開平 1 1一 2 3 7 9 8 2号公報「ソフトウエア部品開発支援装置」特許文献 3

特開 2 0 0 0— 3 3 9 1 4 9号公報「状態遷移モデル作成方法および装置」特許文献 4

' 特開 2 0 0 0— 1 1 6 9 1 1号公報「オブジェクト指向プログラムの自動生成装置」

特許文献 1には、制御対象システムを構成するュニットの変更にあたつて、変更のなかったユニットに関する仕様を再利用することができ、ソフトウェアの生産効率を向上させ、またュニットの数が多くなった場合にもコンパクトで簡明な仕様記述を行なうことができるプログラム自動生成装置が開示されている。

特許文献 2には、オブジェクト指向ソフトウェアにおいて再利用可能な部品の開発を行うために、ある問題領域のアプリケーションに共通となる要求仕様を分析して得られる仕様の不変 Z変動部に関する情報を利用して、再利用可能な部品の開発を支援する技術が開示されている _D 特許文献 3には、状態遷移モデルの作成において状態抽出、入カイべント抽出、アクション抽出、および出力イベント抽出に必要とされる時間を短縮することができる技術が開示されている。

特許文献 4には、オブジェクト指向プログラムの開発において静的部分のプログラムコードの自動生成と共に動的部分のプログラムコードの自動生成を行なって、ソフトウエア開発の作業効率を向上させることができるプログラムの自動生成装置が開示されている。

しかしながらまず特許文献 1では、状態遷移モデルでユニット間の関係を記述しなければならない。例えばユーザィンタフェースアプリケーシヨンにおける、クライアント側の画面と表示データ項目、画面レイァゥトの関係を状態遷移モデルで記述しなければならず、開発に手間がかかるという問題点があった。

特許文献 2では、要求仕様の分析モデルが設計情報に変換され、ォブジェクト指向のソフトウエア部品が開発されるが、設計モデルの定義によって、例えば W e bアプリケーションのプログラムに自動変換することは困難であった。

特許文献 3では、状態遷移表に加えて、更にメッセージシーケンスチヤートを記述する必要があり、プログラムの自動生成までには手間がかかるという問題点があった。

特許文献 4では、動的部分の定義を抽出し、ステートマシンツリーを構した後に、静的部分と統合してプログラムコードを生成する必要があり！、最終プログラム製品の開発までには、手数を要するという問題点があった。

'

発明の開示

本発明の目的は、ユーザィンタフェースアプリケーションの開発においてプログラム開発用仕様書データの作成に工夫を加えることによって、ユーザインタフェースアプリケーションプログラムの自動生成を容易にす開発装置、および開発方法を提供することである。

本発明のユーザィンタフェースアプリケーション開発装置は、仕様書データ読み込み手段と、プログラム生成手段とを備える。

仕様書データ読み込み手段は、画面と処理とが交互に記述される形式、例えば 1つの画面と 1つ以上の処理とが交互に記述される形式の画面遷移図に相当し、画面と表示入力データ項目との間の関連付け、および表示入力データ項目と画面レイアウトとの関連付けがなされたプログラム開発用仕様書データを読み込むものであり、プログラム生成手段は、この仕様書データを用いて、ユーザィンタフェースアプリケーションのプ口グラムを自動生成するものである。

また本発明のユーザインタフェースアプリケーション開発装置は、仕様書データ読み込み手段と、処理実行手段とを備える。仕様書データ読み込み手段は、前述と同様のプログラム開発用仕様書データを読み込み、処理実行手段は読み込まれた仕様書データを解釈し、その解釈結果に対応して、ユーザインタフェースアプリケーションの処理を実行するものである。

更に本発明のユーザインタフェースアプリケーション開発装置は、仕様書データ読み込み手段とプログラム生成手段とを備える。

仕様書データ読み込み手段は、それぞれ対応する処理が定められる複数の画面の間での遷移が記述された形式の画面遷移図に相当し、画面と表示入力データ項目との間の関連付け、および表示入力データ項目と画面レイァゥトとの間の関連づけがなされるべきプログラム開発仕様書データを読み込むものであり、プログラム生成手段は、その仕様書データを用いて、ユーザインタフェースアプリケーションのプログラムを自動生成するものであり、仕様と前述の 2つの関連づけの内容が変更されながら、プログラムが反復的に開発される。

以上のように本発明によれば、プログラム開発用仕様書データとして工夫された形式、すなわち画面と処理とが交互に記述される形式の画面遷移図に相当する仕様書データを用いて、ユーザインタフェースアプリケーシヨンのプログラムの自動生成、またはアプリケーションの処理の実行が行われる。

'

図面の簡単な説明

図 1は、本発明のユーザィンタフェースアプリケーション開発装置の原理構成ブロック図である。

図 2は、ユーザインタフェースアプリケーション開発のための定義の全体像を示す図である。

図 3は、画面遷移定義の例を示す図である。図 4は、画面遷移定義における画面レイァゥト定義の例を示す図である。 .

図 5は、ビジネスフロー定義の例を示す図である。

図 6は、画面項目定義の例を示す図である。

図 7は、定義の省略を行なう.場合に最低限必要な画面遷移定義の説明図である。

図 8は、省略が行なわれる場合の画面遷移の例の説明図である。図 9は、ユーザインタフェースアプリケーションの自動生成の説明図である。

図 1 0は、自動生成ツールを用いたプログラム作成処理の基本フローチヤ一トである。

図 1 1は、自動生成されたアプリケーションの構造を説明する図である。

図 1 2は、定義体を解釈しながら処理を行なう動作形式を説明する図である。

図 1 3は、仕様生成ツールによる外部仕様文書生成の説明図である。図 1 4は、外部仕様生成処理の基本フローチャートである。

図 1 5は、デバッグツールによる命令実行箇所などの検出の説明図である。

図 1 6は、テストデータ生成とテスト実行動作の説明図である。図 1 7は、定義体修正の影響範囲検出動作の説明図である。

図 1 8は、ユーザィンタフェースアプリケーションの反復開発の説明図である。発明を実施するための最良の形態

図 1は本発明のユーザィンタフェースアプリケーション開発装置の原理構成ブロック図である。同図において開発装置 1は、仕様書データ読み込み部 2と、プログラム生成部 3とを備える。

仕様書データ読み込み部 2は、画面と処理とが交互に記述される形式の画面遷移図に相当し、画面と表示入力データ項目との間の関連づけ、および表示入力データ項目と画面レイァゥトとの間の関連づけがなされたプログラム開発用仕様書データ、例えば U M L言語で書かれた仕様書データを読み込むものであり、プログラム生成手段 3は、その仕様書データ、および例えばビジネスフロー定義図などを用いて、プラットフォームに依存した形式のユーザィンタフェースアプリケーションプロダラムを、例えば Java Server Pages (JSP) /Servl et用の自動生成ツールを用いて自動生成するものである。

ここで J S P /Servl etは J a v a言語により W e bサーバ処理を行レ、、 H T M L形式のファイルを W e bブラウザに送るものである。

ユーザインタフェースアプリケーション開発装置 1は、図示しない制約条件チェック部を更に備えることも可能である。制約条件チェック部は、表示入力データ項目に対応して設けられる制約条件をチェックし、その条件が満足されない時に画面遷移図上での画面から処理への遷移を禁止するものであり、この場合、制約条件に対応して制約条件のチエツク箇所を指定する情報が与えられ、制約条件チェック部がその指定に対応してチェックを行なうことも可能である。

またユーザィンタフヱースアプリケーション開発装置 1は、更に図示しないアプリケーション検証部を備えることもできる。アプリケーション検証部は表示入力データ項目に対応してテストデータを生成し、そのテストデータを生成されたプログラムに投入してプロダラムの検証を行なうものである。この場合、アプリケーション検証部がプログラムの検証結果を保存し、プログラム開発用仕様書データなどが変更された時に、同一のテストデータを用いて変更後のプログラムを検証した結果と比較して、アプリケーション変更の影響範囲を検出することもできる。

更にユーザインタフェースアプリケーション開発装置 1は、図示しない画面生成部を更に備えることもできる。画面生成部は、表示入力データ項目に対応して、あらかじめ定められた画面レイアウトに関するルールに従って画面生成を自動的に行なうものである。またユーザィンタフエースアプリケーション開発装置 1は、外部仕様生成部を更に備えることもできる。外部仕様生成部は、プログラム開発用仕様書データに対応し、ユーザィンタフェースアプリケ——ンョンのモデルを表す内部仕様の情報を、あからじめ定められた定義に従ってフィルタリングし、外部仕様を表すための追加情報と合わせて外部仕様文書を自動生成するものである。

ユーザインタフェースアプリケーション開発装置は、更にデバッグ部を備えることもできる。デバッグ部はプログラム生成部によって生成されたプログラムのデバッグを行なうものであり、プログラム生成部がプ口グラムの自動生成にあたってプログラム内にイベントを発行する命令を埋め込み、デバッグ部がデバッグ時にそのイベントを受け取り、ィべント発行命令の埋め込み箇所をプログラムの実行箇所として識別することもでき、またプログラム生成部がィベント発行に対応する処理としてブレークボイントを示す情報を設定し、デバッグ部がその情報を検出した時、画面上でそのブレークボイントに対応する部分を強調することもでき、更にィベントにそのィベント発行命令の埋め込み箇所で扱われるデータを埋め込み、そのデータと仕様書データを表す図上でのクラスとを識別子によって対応づけ、デバッグ部がイベントを受け取った時、そのデータの種類と値とを検出することもできる。この場合、デバッグ部が検出されたデータの値を保存し、アプリケーションが変更された後のデバッグ時に同一箇所のデータと比較し、アプリケーション変更の影響範囲を検出することもできる。

次に本発明のユーザィンタフェースアプリケーション開発装置は、図 1のプログラム生成部 3に代わって処理実行部を備えることもできる。処理実行部は仕様書データ読み込み部 2によって読み込まれた仕様書データを解釈し、その解釈結果に対応して、ユーザインタフェースアプリケーションの処理を実行するものである。

またユーザィンタフェースアプリケーション開発装置 1は、図 1におけると同様に、仕様書データ読み込み部 2と、プログラム生成部 3とを備える。但し、仕様書データ読み込み部 2は、それぞれ対応する処理が定められる複数の画面の間での遷移が記述された形式の画面遷移図に相当し、画面と表示入力データ項目との間の関連づけ、および表示入力データ項目と画面レイァゥトとの間の関連づけがなされるべきプログラム開発仕様書データを読み込むものであり、プログラム生成部 3はその仕様書データを用いてユーザィンタフェースアプリケーションのプログラムを自動生成するものである。そして前述の対応する処理の内容などを変しながら、仕様書データ読み込み部 2とプログラム生成部 3との動作を操り返すことによって、例えば分析、設計、実装、および検証のフエーズを繰り返すプログラムの反復開発を行なうことができる。

次にユーザインタフェースアプリケーションの開発方法として、画面と処理とが交互に記述される形式の画面遷移図に相当し、画面と表示入力データ項目との間の関連づけ、および表示入力データ項目と画面レイアウトとの間の関連づけがなされたプログラム開発用仕様書データを読み込み、その仕様書データを用いて、ユーザインタフェースアプリケーシヨンのプログラムを自動生成する方法が用いられ、この方法を実現するためのプログラムが用いられる。図 2は本実施形態におけるユーザィンタフエースアプリケーション開発のための定義の全体像である。同図において定義は画面遷移定義 1 1、ビジネスフロー定義 1 2、画面項目定義 1 3、および画面レイァゥト定義 1 4によって構成され、ビジネスフロー定義 1 2は外部コンポーネント 1 5、および中間データ定義 1 6 と関連している。

画面遷移定義 1 1は、図示しない初期状態と最終状態、画面ァクティビティ 2 1、処理ァクテイビティ 2 2、パラメータ 2 3、ァクティビティ間遷移 2 4、パラメータ間フロー 2 5、および画面遷移定義 1 1全体の中での部分的な画面遷移を示す画面遷移ァクティビティ 2 6によって、画面遷移の状態を表現するものである。

初期状態と最終状態は、それぞれ画面遷移が開始される位置と終了する位置を定義するものであり、画面ァクティビティ 2 1は画面レイァゥト定義 1 4の参照処理と、入力パラメータ、出力パラメータを持ち、入力パラメータを基に画面レイァゥトを利用して画面表示を行なう。例えばクライアント（ユーザ）側から入力されたデータは出力パラメータに代入される。

処理ァクティビティ 2 2は、ビジネスフロー定義 1 2の参照処理と、入力パラメ一タ、出力パラメータを持ち、入力パラメータをビジネスフローに渡して処理の実行を依頼し、処理が終了した時点でビジネスフロ一から出力されるデータを出力パラメータに代入する。

パラメータ 2 3はデータオブジェクトを示し、画面項目定義 1 3によつて定義される。関連するパラメータ間フロー 2 5では、フローが出力パラメータから入力パラメータに対するものとして定義され、後述するように出力パラメータの内容が入力パラメータに代入される。

アクティビティ間遷移 2 4には、次のようなルールがあるものとする。 ① 初期状態からは処理ァクティビティ 2 2のみに遷移できる。 ② 画面ァクティビティ 2 1からは処理ァクティビティ 2 2のみに遷移できる。この遷移には条件としてァクションガードを付けることができる。このアクションガードとしての条件に対しては、クライアント側からサーバ側にィベントが送られるにあたってクライアント側で押されるポタンを割り付けることによって、そのガード条件が満足されたか否かが識別される。また画面ァクティビティ 2 1力、ら、後述するように "Retry Error" のガード付き遷移を記述した場合には、リ.トライとなる対象のターゲットは同一の画面ァクティビティとなる。

③ 処理アクティビティ 2 2からは画面アクティビティ 2 1、または処理アクティビティ 2 2、または最終状態のいずれかに遷移できる。画面遷移アクティビティ 2 6は、画面遷移定義 1 1の中での部分的な他の画面遷移図を参照するものであり、入力パラメータと出力パラメ一タを持つ。入力パラメータに入力された内容は参照先、すなわち別の図としての画面遷移図の入力パラメータとなる。参照先の画面遷移図側での処理が終了すると、その時の出力パラメータが画面遷移ァクティビティ 2 6の出力パラメータに代入される。

画面項目定義 1 3は画面表示のための項目を定義するものである。項目は名前と型から構成され、型としては文字列、整数、実数、日付、列挙、複合型などがあり、更に別途定義することも可能である。

画面項目定義 1 3によって定義される項目に対しては、画面項目制約定義 2 8が必要に応じて定義される。項目の型毎に次のような制約項目を設定することが可能である。制約の必要に応じて外部で定義することもできるため、制約はここにあるだけに限らない。

また制約として記述されている条件のチユックを画面上、すなわちクライアント側で行なうか、サーバで行うかを指定することができる。これによってアプリケーションとしてのプログラムの自動生成にあたってどの部分で処理を実行するコードを出力するかが決定される。

文字列に対する制約としては最小桁数制限、最大桁数制限、文字種制限、および必須入力などがある。必須入力とは、その文字列の入力が必ず必要か否かを指定するものである。

整数と実数については最小値制限、最大値制限、必須入力などの制約があり、日付については存在するかどうかや、必須入力などの制約がある。

列挙については単一選択制限、すなわち 1つだけを必ず選択するという制限や、必須入力などが、複合型については内包される項目についてそれぞれの制約内容が適用される。

次に図 2のビジネスフロー定義 1 2については図示しない初期状態と最終状態、ロジックアクティビティ 3 1、図示しない判断やパラメータ 3 2、アクティビティ間遷移 3 3、パラメータ間フロー 3 4、およびビジネスフローァクティビティ 3 5が定義され、処理の詳細が表現される。初期状態、最終状態はそれぞれビジネスフローを開始する位置と終了する位置を定義するものであり、ロジックアクティビティ 3 1は基本的に外部コンポーネント 1 5を参照する処理に相当し、入力パラメータと出力パラメータとを持つ。入力パラメータを外部コンポーネント 1 5に渡して処理の実行を依頼し、処理が終了した時点で外部コンポーネント 1 5の出力を出力パラメータに代入する。

図示しない判断は、入力パラメータを持ち、パラメータの内容に応じた分岐が行なわれる。パラメータ 3 2はデータオブジェクトを示し、画面項目定義 1 3、または中間データ定義 1 6によって定義される。

ァクティビティ間遷移 3 3は画面遷移定義 1 1におけるァクティビティ間遷移 2 4と同様にルールを持つ。そのルールとしては

① 初期状態からはロジックアクティビティ 3 1、条件判断、ビジネスフローアクティビティ 3 5、最終状態のいずれかに遷移できる。ロジックアクティビティ 3 1からは、初期状態からの遷移と同様の遷移ができる。更に条件判断からも、初期状態からと同様の遷移ができる。

② ビジネスフローアクティビティ 3 5、すなわち他のビジネスフロ一を参照するアクティビティからはロジックアクティビティ、条件判断、ビジネスフローァクティビティ、最終状態のいずれかに遷移ができる。パラメータ間フロー 3 4は、画面遷移定義 1 1におけると同様に出力パラメータから入力パラメータに対して定義され、出力パラメータの内容が入力パラメータに代入される。

外部コンポーネント 1 5は、ビジネスフロー定義 1 2の内部のロジックアクティビティ 3 1から参照され、必要な処理に対応するプログラムコードが記述されている。中間データ定義 1 6ではビジネスフロー定義 1 2の内部で利用される中間的なデータの項目定義が行なわれる。

以上説明した全てのモデル情報に対しては、追加項目としてコメント情報を追加することができる。このコメント情報は例えば自然言語のような非定型の形式で記述でき、開発の任意の段階でその記述や参照を行なうことができる。

図 3、図 4は画面遷移定義、図 5はビジネスフロー定義、図 6は画面項目定義の例の説明図である。本実施形態では仕様書データの記述形式としてアクティビティ図を利用した方法を基本として説明するが、記述形式としては例えば表形式を用いることも可能である。

図 3の画面遷移定義図において、初期状態 4 1 と最終状態 4 8、または 4 9 との間で、画面遷移が定義される。この画面遷移図では基本的に処理ァクティビティと画面ァクティビティとの間で交互に遷移が行なわれるような形式で画面遷移が定義される。まず初期状態 4 1から " Ini t ial i ze" の処理アクティビティ 4 2への遷移が記述され、次に " Input Screen" の画面ァクティビティ 4 3への遷移が行なわれる。

この処理ァクティビティ 4 2から画面ァクティビティ 4 3への遷移にあたっては、処理アクティビティ 4 2の 2つの出力パラメータの、画面. アクティビティ 4 3の 2つの入力パラメータへの代入を示すパラメータ間フローが点線によって示されている。また画面アクティビティ 4 3に対する "Retry Error" のガード付き遷移のターゲットが、同一の画面アクティビティ 4 3であることが示されている。

" Input Screen"の処理アクティビティ 4 3からの遷移としては "act ion=send" であるカヽ "Proceed Error" であるかの条件判断に対応して "Send" の処理アクティビティ 4 4、または "Handle Error" の処理ァクティビティ 4 6のいずれかへの遷移が行なわれる。

更に "Send" の処理アクティビティ 4 4からは "result" の内容によつて "Result Screen" の画面ァクティビティ 4 5、または "Handl e Er ror" の処理アクティビティ 4 6への遷移が行なわれ、 "Handl e Erro r" の処理アクティビティ 4 6からは "Error Screen" の画面ァクティビティ 4 7への遷移が行なわれる。

図 4は画面遷移定義図上での入力データ項目と画面レイァゥトの関連づけの説明図である。同図においては " Order" のアクティビティの 2 つの入力データ項目に対してそれぞれ "head, j sp" と "body, j sp" のレイァゥトが定義されていることが示されている。

図 5はビジネスフロー定義図の例である。この図は例えばレンタカーのビジネスに対応する。同図においては初期状態 5 0から "Check Cond iti ons" のロジックアクティビティ 5 1への遷移がまず行なわれるが、この遷移に対応して初期状態出力パラメータ 5 6からロジックァクティビティ 5 1の入力パラメータ 5 7に対するパラメータ間フロー、すなわち代入が行なわれることが示されている。またロジックアクティビティ 5 1力ら "Search" のロジックァクティビティ 5 2への遷移にあたっても、ロジックアクティビティ 5 1の出力パラメータ 5 8力ロジックァクテイビティ 5 2の入力パラメータに代入される。

条件判断 5 3の判断結果によって、結果 5 4が成功である場合には "Edi t Header A" のロジックァクティビティを経由して、結果 5 4が終了状態 5 5に与えられる。また結果が失敗である場合と、ロジックァタティビティ 5 1で例外が生じた場合には " Edit Header B" のロジックアクティビティを経由して、終了状態 5 5への遷移が行なわれる。いずれの場合にも、終了状態入力パラメータ 5 9が与えられる。

図 6は画面項目定義の例である。中間データ項目も同じ形式で定義される。同図左側はコンポジション集約を示すクラス図の例であり、右側は複合型の例を示すクラス図である。これらのクラス図において、例えば "Search Condition" というオブジェクトに対する操作（メソッド）は省略されている。

図 2で説明した定義は全体像を示すものであり、例えばユーザインタフェースアプリケーションの開発の初期の段階では一部を省略して記述することが可能である。図 7はそのような省略を行なう場合に最低限必要な画面遷移定義の説明図である。同図において画面遷移定義 1 1は、画面ァクティビティ 2 1 とァクティビティ間遷移 2 4だけによつて表現されている。

図 8はこのような省略が行なわれる場合の画面遷移の例の説明図である。同図においては初期状態から受注種別選択の画面ァクティビティへの遷移が行なわれた後に、ァクションが正式であるか内示であるかに対応して、正式受注登録、正式受注確認の画面への遷移が行なわれて最終状態に遷移するか、または内示受注登録、内示受注確認の画面ァクティビティへの遷移が行なわれて最終状態への遷移が行なわれるかが定義される。

図 7のように定義の省略を行なう場合、記述されない内容は以下のルールに従って生成されるものとする。画面レイアウト定義 1 4については、例えばクライアント側でァクションを指定するためのィベント発生用のボタンのみが存在するものとし、画面項目定義 1 3が作られている場合には、対応する画面レイァゥトはあらかじめ定められたルールによつて自動生成されるものとする。

画面遷移定義 1 1の内部の処理ァクティビティ 2 2については、何もしないァクティビティがあるものと仮定し、画面遷移ァクティビティ 2 6、すなわち他の画面遷移図の参照についてはそのような処理を利用せず、パラメータ 2 3についてはデータがないものと仮定し、パラメータ間フロー 2 5についてはパラメータが存在しないため、フローも存在しない。

画面項目定義 1 3については、一般的には表示入力項目が何もないものと仮定し、従って画面項目制約定義 2 8も何もないものと仮定する。ビジネスフロー定義 1 2についてもビジネスフローとして何もないものと仮定し、中間データ定義 1 6についてもビジネスフローが存在しないため、利用すべき中間データも存在しないものとする。このような最低限の状態から色々な定義を補うことによって、少しずつ定義を完全にすることができ、ユーザインタフェースアプリケーションの開発を段階的に進めることが可能となる。

図 2で説明したユーザインタフェースアプリケーション開発のための定義が完成するか、あるいは図 7で説明した省略形式の未完成の定義に相当する定義体に対して、プラットフオームに依存する自動生成ツールを用いることによって、ユーザインタフェースアプリケーションとしての W e bアプリケーション、またはクライアントアプリケーションを作成することができる。

図 9はそのような自動生成の説明図である。同図において定義体 6 1 に対して、例えば前述のように JSP/Servlet用の自動生成ツール 6 2 a を用いることによって、 JSP/Servlet用の W e bアプリケーション 6 3 aが作成される。

同様に We bサーバ上でページを生成する仕組の 1つとしての Active server Pages (ASP) . N E T用の自動生成ツール 6 2 bを用いることによって、 W e bアプリケーション 6 3 bが作成される。

またブラゥザにダウンロードして実行される Javaのクライアントソフトである Java Applet用の自動生成ツール 6 2 cを用いることによって、 Java Applet用のクライアントァプリケーシヨン 6 3 cが作成される。更に、グラフィックユーザインタフェースを簡単に作成するための、ベーシックを基にしたプログラミング言語としての Visual Basic用の自動生成ツール 6 2 dを用いることによって、 Visual Basic用のクライアントアプリケーション 6 3 dが作成される。

図 1 0は、このような自動生成ツールを用いた、ユーザインタフエ一スアプリケーションプログラム作成処理の基本フローチヤ一トである。同図において処理が開始されると、まずステップ S 1で、例えばテキスト形式の定義（体）が読み込まれ、ステップ S 2でその定義体が、例えば UML言語における內部モデル、例えば Java言語のォブジ-クトモデルに変換され、ステップ S 3でそのモデルが正当であるか否かのバリディテイチエックが行なわれる。このステップ S 3まではプラットフォームに依存しない処理である。

続いてステップ S 4で内部モデル構造がタ一ゲット、すなわちプラットフオームに依存する構造、例えば後述する図 1 1のような構造に変換され、ステップ S 5でプログラムとしての各ファイルが出力されて処理を終了する。

このような自動生成ツールを用いたプログラム作成、すなわち定義体の変換における JSP/Servl et 用の自動生成ツールの動作について更に述ベる。各定義体は次のルールに従って変換される。まず画面レイアウト定義は元々プラットフォームに依存するものであり、 J S Pによって記述される。

画面遷移定義については、 1つの画面遷移定義は 1つのビジネスクラスに変換される。画面ァクティビティは J S Pによる画面表示に対応し、処理ァクティビティは対応するビジネスクラスのメソッドの呼び出しに変換され、画面遷移アクティビティは他の画面遷移の呼び出しとなる。パラメータについては、画面ァクティビティのパラメータは画面に入力表示されるデータに対応し、 JSPへの入力となる Data Beanオブジェクトに変換される。

ビジネスクラスも同様に入出力されるデータに対応し、 Data Beanクラスに変換される。アクティビティ間の遷移については、表示する画面や処理の順番の規定に変換され、パラメータ間のフローに対しては、データの関連の作成が行なわれる。

画面項目定義については、項目定義そのものは Data Beanクラスに変換され、画面項目制約定義については前述のチェックサイトがクライアント側かサーバ側かの指定により、 W e bクライアント側のスクリプト言語である Java Script , または項目チヱッククラスに変換される。

ビジネスフローについては、ビジネスクラスの 1つのメソッドに変換される。ロジックアクティビティとしては、指定された外部のコンポ一ネントの呼び出しコードがビジネスクラスのメソッド内に作成され、ビジネスフローァクティビティについても同様に呼び出しコードが作成される。パラメータについてはァクティビティのデータとして設定され、ァクティビティ.間の遷移についてはその順番が生成され、パラメータ間のフローについてはデータの関連が作成される。

中間データ定義については、 Java Beanクラスに変換される。

図 1 1はこのようにして自動生成されたアプリケーションの動作を説明するための構造であり、すなわちモデル、ビュー、およびコントローラの M V Cモデルに相当する。

図 1 1において外部から、例えば全体を制御するためのコントロール servl et 6 5にリクエストが与えられると、データ力 SData Beanクラス 6 9 (データフォルダに相当）に設定され、ビジネスクラス 6 8が動かされる。ビジネスクラス 6 8は外部コンポーネント 7 1の呼び出しなどを行なって処理を実行し、処理中に Data Beanクラス 6 9のデータをリード /ライトし、また処理結果のデータをライトする。

その後 J S P 6 6に制御が移る。 J S P 6 6は画面表示用のものであり、 Data Beanクラス 6 9のデータを読みながら画面表示を行なう。その時、画面表示項目に制約がある場合は項目チェック用 Java Script 6 7がブラウザ側で動作し、制約項目違反があればエラーとして検出される。最初にコントロール Servl et 6 5側から Data Beanクラス 6 9にデータが与えられた場合にも、項目チェッククラス 7 0によって制約項目のチェックを行なうことができる。

このような動作を更に詳細に記述すると次のようになる。

1 . ブラウザにおいて送信ボタンが押される。

2 . 項目チヱック用 Java Script 6 7がデータ内容をチェックする。内容がエラーであり、「R_etry Error」遷移がある場合、送信を行なわずエラーメッセージを表示する。

3 · ブラゥザからコント口ール Server 6 5にリクエストが送られる。

4 . データを Data Beanクラス 6 9に設定し、項目チェッククラス 7 0 がその内容をチェックする。内容がエラーであり、「Retry Error」遷移がある場合、元の画面を再表示し、エラーを表示する。

5 . 現在のビジネスフローに対応したビジネスクラス 6 8を呼び出す。

6 . ビジネスフローの定義に従って外部コンポーネント 7 1を呼び出す。 7 . 画面遷移の定義に従って J S P 6 6に制御が移る。

8 . J S P 6 6力 Data Beanクラス 6 9よりデータを取得して表示する。本実施形態においては、図 9で説明したように、プラットフォームに依存しない定義体をブラットフオームに依存する自動生成ツールによつて読み込み、ユーザィンタフエースプログラムを自動生成する代わりに、定義体 6 1をそのまま解釈しながら、アプリケーションとして実際の処理を行なうことも可能である。図 1 2はそのような場合の動作形式の説明図である。同図においては画面レイアウト定義 7 6、画面遷移定義 8 1、ビジネスフロー定義 8 2、項目制約定義 8 3、画面項目定義 8 4、中間データ項目定義 8 5がそのまま与えられ、図 1 1の項目チェック用 Java Script 6 7に代わる： [ava Script生成エンジン 7 7、ビジネスクラス 6 8に代わるビジネスフ口一エンジン 7 8、 Data Beanクラス 6 9に代わるデータコントロールエンジン 7 9、項目チェッククラス 7 0に代わる項目チユックエンジン 8 0が備えられ、コンパイラとインタプリタとに相当する動作が実行される。

次に本実施形態では、画面項目定義から画面レイアウトを自動生成することができる。画面項目定義については、図 2で説明したように文字列、整数、実数、日付、列挙、複合型などの型があり、その型と画面レィァゥ卜における表示部品との対応づけを行なうことによって、自動生成が可能となる。その他の型が定義されている場合には、その型毎に画面レイァゥト生成のルールを定めることで、その型に対応することがでさる。本実施形態では型が文字列、整数、実数、日付である場合には、画面レイァゥトにおけるテキストフィールドに、列挙に対してはラジオボタンに、複合型に対しては表に対応させることによって、画面レイアウトの自動生成が可能となる。

次に外部仕様の生成について説明する。本実施形態では仕様を定義した定義体から、仕様生成ツールを用いることによって外部仕様の文書が生成される。一般にアプリケーションを実行するための内部仕様と、顧客に提供するための外部仕様には次のような違いがある。

外部仕様には顧客から要求された仕様や、外部仕様の著者などの非定型の追加情報が必要となる。定義体に用意されるコメントを記述するための欄を使って、これらの情報を付加することができる。

外部仕様としては、内部仕様に相当する定義体の全ての情報が必ずしも必要ではなく、仕様生成ツールによってこれらの情報をフィルタリングすることができる。また外部仕様には、逆に顧客特定のレイアウト情報などが必要であり、外部仕様のレイアウト定義を使って、これらの情報を追加することができる。さらに非定型の追加情報をモデルの拡張情報として、外部仕様の文書と内部仕様の文書とを合わせて、 1つのモデル情報として、ユーザインタフェースアプリケーション開発装置としてのコンピュータの記憶装置に格納することもできる。

図 1 3は自動生成ツールによるアプリケーションの自動生成と、仕様生成ツールによる外部仕様文書の生成の説明図である。図 9で説明した自動生成ツール 6 2による定義体 6 1からアプリケーション 6 3の自動生成と同時に、外部仕様 8 9を外部使用レイァゥト定義 8 7から仕様生成ツール 8 8によって自動生成することができる。

図 1 4はこの外部仕様生成処理の基本フローチャートである。同図においてまずステップ S 1、および S 2で図 1 0におけると同様に定義の読み込みと、内部モデルへの変換が行なわれる。そしてステップ S 3でバリディティチェックが行なわれ、プラットフオームに依存しない処理がここまでで終了する。

続いてステップ S 7で外部仕様レイァゥト定義 8 7の読み込みが行なわれ、ステップ S 8でレイアウトに内部モデルがはめ込まれる。例えば画面レイアウトとして図の表示領域と表の表示領域とが定められている場合には、例えば画面遷移図が図の表示領域に、またクラス情報が表の表示領域にはめ込まれ、ステップ S 9で作成された外部仕様 8 9が出力されて、処理を終了する。 '

本実施形態ではプログラムの実行時、あるいはデバッグ時に、命令の実行箇所を検出することを可能とするために、プログラム生成に際して定義上の実行位置を示すィベントを、定義上の実行位置が変わるたびに発行する命令が埋め込まれる。これによつてプログラムの実行時、あるいはデバッグ時に、命令の実行箇所や、イベントに付属しているデータの値の検出を行うことが可能となる。

図 1 5はこのような実行箇所検出と、ブレークボイント設定の例の説明図である。同図において、定義体 6 1側からデバッグ実行が指定されると、自動生成ツール 6 2を利用して①でアプリケーション 6 3が生成される。この時、定義上の各アクティビティとデータ項目に識別子を割りあて、生成されたコードによってそのアクティビティが実行される時、割りあてられた識別子をィベントとして送出するためのコードを挿入する。

②でァクテイビティがアプリケーション 6 3によって実行されるにあたって、イベントが発行される。イベントに画面項目 Cが指定されている場合には、図に示されるように画面項目 Cの値がイベントに付属させられて、デバッグツール 9 1に与えられる。デバッグツール 9 1は③でイベントを受け取り、受け取った識別子に該当する定義体上のァクティビティを認識することができる。

通常はその後も実行が継続されるが、 ④で示されるように識別子によつて識別される処理 Bに対応してブレークポィントが設定されている場合には、アプリケーションの実行は一旦停止され、該当するァクティビティがハイライト表示される。

更にデバッグツール 9 1は画面項目の認識も可能である。 ⑤で示されるように、画面項目 Cにはデータの値も付属しているため、処理 B側から入力されるデータの値を表示することもできる。

次に本実施形態におけるテストの実行について説明する。テストデータ生成ツールを利用して、画面項目定義と画面項目制約定義に基づいてテストデ一タを生成し、画面が表示された時にそのデータを自動入力することによって、テストを自動的に実行することができる。

図 1 6はこのテスト実行方式の説明図である。図 1 6において定義体 P 6 1から①で自動生成ツール 6 2によってアプリケーション Q 6 3が自動生成される。 . ' 定義体 P 6 1に対応して、 ②でテストデータ生成ツールによって画面項目 Cと画面項目制約 Dからテストデータ R 9 2が生成される。画面項目 Cは画面 Aからの出力 (ユーザによる入力) 、および処理 Bへの入力を表し、項目 E， F， Gから構成される。それぞれの項目に対しては制約が設定され、その制約は画面項目制約 Dによって定義される。

アプリケーション Q 6 2の実行時には、テストデータ R 9 2がアプリケ——ンヨン Q 6 2上のコント口一/レ Servletを呼び出す。

コント口ール Serv l etは、定義体の定義に従って画面からのデータ (テストデータ R ) を受け取って、項目チェッククラスを④で呼び出し項目 E， F， Gの内容が制約を満たすかどうかを判定する。 ' テストデータの生成はあらかじめ定められたルールに従って行なわれるものとする。ルールは型毎に定められる。ルールが定められていない型を定義した場合には、ルールもそれに伴って定めることによって、その型のテストデータを生成することができる。また次に記述されている型についても、必要に応じてルールの変更や追加を行なうことができる。文字列については最小桁数制限の制約に対応して、空文字列、（最小桁数一 1 ) 桁の文字数、（最小桁数）桁の文字列、および（最小桁数 + 1 ) 桁の文字列などのテストデータが生成される。このうち最初の 2つは制約に違反するテストデータとなり、このようなテストデータが用いられた場合にはヱラーが検出されなければならないことになる。

最大桁数制限の制約に対しては、空文字列、（最大桁数一 1 ) 桁の文字列、（最大桁数）桁の文字列、（最大桁数 + 1 ) 桁の文字列などのテストデータが、文字種制限の制約に対しては適合する文字列と、適合しない文字列のテストデータが作成され、必須入力の制約に対しては、空文字列と、空でない文字列とのテストデータが生成される。

整数および実数の型に対しては、最小値制限の制約に対応して（最小値一 1 ) 、（最小値）、および（最小値 + 1 ) のテストデータが、最大値制限の制約に対しては（最大値一 1 ) 、（最大値）、および（最大値 + 1 ) のテストデータが、また必須入力の制約に対しては未入力、すなわちデータを入力しない状態、および任意の数値のテストデータが用いられる。

日付の型については、存在するかどうかの制約に対して、存在する日付、存在しない日付（2 0 0 3年 2月 2 9日など）、閏年で存在する日付（2 0 0 4年 2月 2 9日など）のテストデータが、また必須入力の制約に対しては未入力、または存在する日付のテストデータが生成される。列挙の型については、単一選択制限の制約に対して、未選択、すなわち全く選択の行なわれていないテストデータ、単一選択、 2個選択、および全選択のテストデータが、必須入力の制約に対しては未選択、単一選択、 2個選択、全選択のテストデータが作成される。

複合型のテストデータとしては、内包される項目についてそれぞれの制約内容を適用したテストデータが生成される。

次に仕様書データなどが変更された場合の影響範囲の検出について説明する。テストデータを利用して、定義体修正後の影響範囲の検出を行なうことができる。すなわちテストデータの生成とテスト実行とを説明した図 1 6の仕組において、ィベント発行のタイミングにおける命令の実行位置とデータを保存しておき、定義体を修正した後に同じテストデータを利用したテストを行なった時、同じィベント発行のタイミングにおける命令の実行位置とデータを保存されている値と比較することによつて、定義体修正の影響範囲を検出することができる。

図 1 7はこのような定義体修正後の影響範囲検出動作の説明図である。同図において、 ①で定義体 P 6 1からアプリケーション Q 6 2の自動生成とテストデータ R 9 2の生成が行なわれ、 ②でテストデータ R 9 2が呼び出され、アプリケーション Q 6 2の実行が行なわれる。そして③でィベント発行のタイミングにおいて、命令の実行位置とデータがデバッグツール S 9 1に渡され、 ④でその位置とデータが実行結果 Tとして保存される。

⑤で定義体 Pが修正され、定義体 P ' 6 1 が得られる。 ⑥で修正された定義体からアプリケーシヨン Q ' 6 2 'が生成され、以後⑦， ⑧で修正前と同様にテス 1、データ R 9 2が呼び出され、ィベント発行のタイミングで命令の実行位置とデータがデバッグツール S 9 1に渡され、 ⑨ で以前の実行結果 Tと比較することによって、データが異なっている場合には、その時の命令の実行位置とデータの内容が定義体 P ' 6 1 一上の位置として⑩で表示される。

次に本実施形態におけるユーザィンタフェースアプリケーションの開発過程に

ついて図 1 8を用いて説明する。本実施形態では、例えば図 7で説明した最低限の画面遷移定義から出発して分析、設計、実装、および検証のフェーズを反復的に繰り返すことによって、ユーザインタフェースァプリケーションの段階的な開発が可能となる。

まず分析フェーズでは、どのように定義体を記述すべきか、例えば顧客側の要求項目から分析が行なわれる。設計フェーズでは、分析フューズで得られる分析結果に基づき定義体が作成され、実装フェーズでは定義体からアプリケーションゃテストデータが生成され、最後の検証フエーズで生成されたアプリケーションにテストデータが投入され、アプリケーションの試験が行なわれる。試験の結果は定義体の位置として示すことができるため、修正が必要な場合は定義体のどの部分を変更すべきカ再び分析フェーズに戻って検討が行なわれる。

図 1 8においては、図 7で説明した最低限の定義状態、すなわち最も小さい状態として、最も内側から分析フェーズが始まることが、右廻りに回転する実線として示されている。各フェーズを繰り返すことにより定義体の大きさなどは大きくなり、やがて最後の検証フェーズで修正が必要がないと判定された時点で開発を終了する。なお実装フェーズの線が細くなっているのは、前述のように本実施形態では自動生成ツールを用いて実際にプログラムコードを開発することは必ずしも必要がないこと、すなわち図 1 2で説明したように、各種の定義を読み込み、それらを解釈して実行することにより、プログラムコードそのものの生成が必ずしも必要がないことを意味している。

以上詳細に説明したように本発明によれば、画面と処理とを交互に記述する形式で、ユーザィンタフエースアプリケーションに対応する画面遷移図に相当するプログラム開発用仕様書データを作成し、そのデータを用いてユーザィンタフェースアプリケーションを自動生成することが可能となる。これによつてユーザィンタフェースアプリケーションの開発、および保守を容易にすることができ、また仕様書データなどの定義上でのデバッグをサポートすることができ、分析、設計、実装、および検証のフェーズを繰り返す反復開発が可能となり、プログラム開発の効率化と保守性の向上に寄与するところが大きい。産業上の利用可能性

本発明は、例えば W e bアプリケーションなどのユーザインタフヱ一スアプリケーションのプログラムを開発して、そのプログラムをユーザ対象のビジネス業者などに提供するソフトウェア開発産業などにおいて利用可能である。

Claims

請求の範囲

1 . ユーザィンタフェースアプリケーションの開発装置において、画面と処理とが交互に記述される形式の画面遷移図に相当し、画面と表示入力データ項目との間の関連付け、および表示入力データ項目と画面レイアウトとの間の関連付けがなされたプログラム開発用仕様書データを読み込む仕様書データ読み込み手段と、

該仕様書データを用いて、ユーザィンタフエースアプリケーションのプログラムを自動生成するプログラム生成手段とを備えることを特徴とするユーザインタフェースアプリケーション開発装置。

2 . ユーザインタフェースアプリケーションの開発装置において、画面と処理とが交互に記述される形式の画面遷移図に相当し、画面と表示入力データ項目との間の関連付け、および表示入力データ項目と画面レイァゥトとの間の関連付けがなされたプログラム開発用仕様書データを読み込む仕様書データ読み込み手段と、

該仕様書データを解釈し、該解釈結果に対応して、ユーザインタフエースアプリケーションの処理を実行する処理実行手段とを備える.ことを特徴とするユーザインタフェースアプリケーション開発装置。

3 . ユーザインタフェースアプリケーションの開発装置において、それぞれ対応する処理が定められるべき複数の画面の間での遷移が記述された形式の画面遷移図に相当し、画面と表示入力データ項目との間の関連付け、および表示入力データ項目と画面レイアウトとの間の関連付けがなされるべきプログラム開発仕様書データを読み込む仕様書データ読み込み手段と、

該仕様書データを用いて、ユーザインタフェースアプリケーションのプログラムを自動生成するプログラム生成手段とを備え、前記対応する処理、および 2つの関連付けの内容を変更しながら、仕様書データ読み込み手段とプログラム生成手段との動作を繰り返すことを特徴とするユーザィンタフースアプリケーション開発装置。

4 . 前記表示入力データ項目に対応して設けられる制約条件をチェックし、該条件が満足されない時、前記画面遷移図上での画面から処理への遷移を禁止する制約条件チェック手段を更に備えることを特徴とする請求項 1記載のユーザィンタフエースアプリケーション開発装置。

5 . 前記制約条件に対応して該制約条件のチェック箇所を指定する情報が与えられ、前記制約条件チコ二ック手段が該指定に対応してチェックを行なうことを特徴とする請求項 4記載のユーザインタフェースアプリケーション開発装置。

6 . 前記表示入力データ項目と、該表示入力データ項目に関する制約条件とに対応してテストデータを生成し、該テストデータを前記生成されたプログラムに投入レてプログラムの検証を行なうアプリケ一ション検証手段を更に備えることを特徴とする請求項 1記載のユーザィンタフエースアプリケーション開発装置。 .

7 . 前記アプリケーション検証手段がプログラムの検証結果を保存し、前記プログラム開発用仕様書データが変更された時、同一のテストデータを用いて該変更後の検証結果と比較して仕様書データ変更の影響範囲を検出することを特徴とする請求項 6記載のユーザィンタフェースアブリケーション開発装置。

8 . 前記表示入力データ項目に対応して、あらかじめ定められた画面レィァゥトに関するルールに従って、自動的に画面生成を行なう画面生成手段を更に備えることを特徴とする請求項 1記載のユーザィンタフエースアプリケーション開発装置。

9 . 前記プログラム開発用仕様書データに対応し、前記ユーザインタフエースアプリケーションのモデルを表す内部仕様の情報をあらかじめ定められた定義に従ってフィルタリングし、外部仕様を表すための非定型の追加情報と合わせて外部仕様文書を自動生成する外部仕様生成手段を更に備えることを特徴とする請求項 1記載のユーザインタフェースアブリケーシヨン開発装置。

1 0 . 前記追加情報をモデルの拡張情報として、前記外部仕様文書と内部仕様文書とを合わせて、 1つのモデル情報として保存する記憶手段をさらに備えることを特徴とする請求項 9記載のユーザィンタフェースァプリケーション開発装置。

1 1 . 前記プログラム生成手段によって生成されたプログラムのデバッグを行なうデバッグ手段をさらに備えると共に、

前記プログラム生成手段がプログラムの自動生成にあたってプロダラム内にィベントを発行する命令を埋め込み、

前記デバッグ手段が、デバッグ時に該イベントを受け取り、該ィベント発行命令の埋め込み箇所をプログラムの実行箇所として識別することを特徴とする請求項 1記載のユーザィンタフェースアプリケーション開発装置。

1 2 . 前記プログラム生成手段が、前記イベント発行に対応する処理としてブレークボイントを示す情報を設定し、

前記デバッグ手段が該情報を検出した時、前記画面上で該ブレークポイントに対応する部分を強調することを特徴とする請求項 1 1記載のュ一ザインタフエースアプリケーション開発装置。

1 3 . 前記プログラム生成手段が、前記イベントに該イベント発行命令の埋め込み箇所で扱われるデータを埋め込み、該データと前記仕様書データを表す図上でのクラスとを識別子によって対応付け、

前記デバッグ手段がィベントを受け取った時、該データの種類とその値とを検出することを特徴とする請求項 1 1記載のユーザィンタフエースアプリケーション開発装置。

1 4 . 前記デバッグ手段が前記検出されたデータの値を保存し、アプリケーションが変更された後のデバッグ時に同一箇所のデータと比較し、 ' アプリケーション変更の影響範囲を検出することを特徴とする請求項 1 3記載のユーザィンタフェースアプリケーション開発装置。

1 5 . ユーザィンタフェースアプリケーションの開発方法において、画面と処理とが交互に記述される形式の画面遷移図に相当し、画面と表示入力データ項目との間の関連付け、および表示入力データ項目と画面レイァゥトとの間の関連付けがなされたプログラム開発用仕様書データを読み込み、

該仕様書データを用いて、ユーザィンタフェースアプリケーションのプログラムを自動生成することを特徴とするユーザィンタフェースァプリケーション開発方法。

1 6 . ユーザインタフェースアプリケーションの開発を行なう計算機によって使用されるプログラムにおいて、

画面と処理とが交互に記述される形式の画面遷移図に相当し、画面と表示入力データ項目との間の関連付け、および表示入力データ項目と画面レイァゥトとの間の関連付けがなされたプログラム開発用仕様書データを読み込む手順と、

該仕様書データを用いて、ユーザィンタフェースアプリケーションのプログラムを自動生成する手順とを計算機に実行させるためのプロダラム„