JP2005196291A - ユーザインタフェースアプリケーション開発プログラム、および開発装置 - Google Patents

Abstract

【課題】 例えばＵＭＬを用いて、ユーザインタフェースを持つアプリケーションプログラムの完全な自動生成を可能とする。
【解決手段】 ユーザインタフェースアプリケーション開発プログラムにおいて、画面および／または処理とデータを入出力するオブジェクトとの間の関連付けを行うことが可能なアプリケーション開発用仕様書データを読み込むステップと、画面および／または処理とオブジェクトとの間の関連付けを含んで仕様書データを自動的に解釈し、ユーザインタフェースアプリケーションプログラムを生成するステップとを備える。
【選択図】図１

Description

本発明はプログラムの開発方式に係り、さらに詳しくはユーザインタフェースを持つアプリケーションプログラムの完全な自動生成を可能とし、プログラムの開発効率と、保守性を向上させることができるユーザインタフェースアプリケーション開発プログラム、および開発装置に関する。

近年ソフトウエアの設計方法として、オブジェクト指向技術を用いた方法が広範囲に用いられている。特にＵＭＬ（Ｕｎｉｆｉｅｄ Ｍｏｄｅｌｉｎｇ Ｌａｎｇｕａｇｅ）というプラットフォームに依存しない言語と、オブジェクト指向言語、例えばＪａｖａ（登録商標）とを組み合わせたＷｅｂアプリケーションの開発方式が注目されている。

このようなソフトウエアの開発方法としては、できるだけプログラムあるいはその部品の自動生成が可能な方法が望まれている。このようなプログラムの自動生成については次のような従来技術がある。
特開平６−２３０９４９号公報「プログラム自動生成装置」 特開平１１−２３７９８２号公報「ソフトウエア部品開発支援装置」 特開２０００−３３９１４９号公報「状態遷移モデル作成方法および装置」 特開２０００−１１６９１１号公報「オブジェクト指向プログラムの自動生成装置」

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

特許文献２には、オブジェクト指向ソフトウエアにおいて再利用可能な部品の開発を行うために、ある問題領域のアプリケーションに共通となる要求仕様を分析して得られる仕様の不変／変動部に関する情報を利用して、再利用可能な部品の開発を支援する技術が開示されている。

特許文献３には、状態遷移モデルの作成において状態抽出、入力イベント抽出、アクション抽出、および出力イベント抽出に必要とされる時間を短縮することができる技術が開示されている。

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

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

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

特許文献３では、状態遷移表に加えて、さらにメッセージシーケンスチャートを記述する必要があり、プログラムの自動生成までには手間がかかるという問題点があった。
特許文献４では、動的部分の定義を抽出し、ステートマシンツリーを構築した後に、静的部分と統合してプログラムコードを生成する必要があり、最終プログラム製品の開発までには、手数を要するという問題点があった。

次に、前述のようにオブジェクト指向におけるプログラムの自動開発において、プラットフォームに依存しない言語としてのＵＭＬがあるが、この言語は一般的なプログラム言語のように文法や構文が規定され、それによってプログラムを作成し、コンパイルを行うというものではなく、オブジェクト指向におけるクラスやオブジェクトなどの要素を用いたモデリングを、例えばアクティビティ図などの図面を表記することによって行うところに特徴がある。

しかしながら、もともとＵＭＬには画面遷移の特徴をすべて表現できる表記法が存在せず、画面遷移に関する部分の設計表記には困難があるという問題点があった。その結果、画面遷移の部分についてのみ、全く異なる表記法を導入するなどの必要があり、開発者は両方の表記法を習得しなくてはならないというような煩雑さがあった。このような問題点を解決するための従来技術に関して次の文献がある。
ｈｔｔｐ：／／ｗｗｗ−６．ｉｂｍ．ｃｏｍ／ｊｐ／ｓｏｆｔｗａｒｅ／ｗｅｂｓｐｈｅｒｅ／ｄｅｖｅｌｏｐｅｒ／ｗｓａｄ／ｗｏｒｋｓｈｏｐ／ｖ５／ｉｎｄｅｘ．ｈｔｍｌ 「Ｓｔｒｕｔｓ アプリケーション開発（後編）」

この文献は画面遷移図からユーザインタフェースを自動生成する装置を開示しているが、この技術ではＵＭＬと異なる表記法を用いて画面遷移で使用されるオブジェクトを表記することが可能であるが、処理ロジックを含むアプリケーションの完全な生成を行うことができず、ユーザはこの技術によって途中まで生成されたソースを読みながら、生成されない範囲のプログラム生成を行わなければならないという問題点があった。

具体的には、この技術においては第１に画面遷移ロジック、およびプログラムの制御の流れやデータの流れに関して、画面、および処理で使用されるデータの入出力の対象オブジェクトは何であるかを明確にすることができず、第２に画面のレイアウトの名称を指定したり、画面上に表れるボタンの名称を指定する方法がなく、第３に画面処理モジュールの間におけるオブジェクトの受け渡しの順序を正確に表現する方法がないという問題点があった。

本発明の課題は、上述の問題点に鑑み、例えばＵＭＬを用いたプログラムの自動生成に関して、例えば画面、および処理と、入出力データとしてのオブジェクトとの間の関連付けを行うことが可能なアプリケーション開発用仕様書データの表記を可能とすることによって、オブジェクト指向のプログラムの完全な自動生成を可能とすることである。

図１は、本発明のユーザインタフェースアプリケーション開発プログラムの原理的な機能ブロック図である。同図は、ユーザインタフェースアプリケーションのプログラムを自動生成するためのプログラムの原理的な機能ブロック図であり、ステップＳ１で仕様書データの読込が行われ、ステップＳ２でプログラムの生成が行われる。

ステップＳ１では、画面と処理とが記述される形式の画面遷移図に相当する仕様書データであって、画面、および／または処理と、入出力データとしてのオブジェクトとの間の関連付けを行うことが可能なアプリケーション開発用仕様書データが読み込まれ、ステップＳ２で読み込まれた仕様書データが、前述の画面、または処理とオブジェクトとの間の関連付けを含んで自動的に解釈され、ユーザインタフェースアプリケーションプログラムの生成が行われる。

発明の実施の形態においては、前述のオブジェクトが画面表示の処理に対応するオブジェクトであり、前述の仕様書データがその処理と表示される画面に対するデータ入出力オブジェクトとの関連付けに加えて、画面レイアウトを示すこともでき、あるいはオブジェクトが、画面遷移に関連する処理であって、外部の処理を読み出すための処理に対応し、仕様書データの前述の関連付けがその関連する処理に対するそれぞれ複数の入力オブジェクト、または出力オブジェクトの順序を示すこともできる。

実施の形態においては、前述の仕様書データが、ユーザが次の状態遷移条件、例えば画面上でクリックするためのボタン名をさらに指定可能であることもできる。
また実施の形態において、仕様書データが画面遷移図上の１つ以上の終了状態にそれぞれ対応し、終了状態の識別子、例えば名前、例外を含む状態の種類、終了後の動作を記述する式、画面遷移図の呼出元に対する１つ以上の返り値、状態に対応する入出力オブジェクトと、入出力の順序をさらに定義可能であり、複数の画面遷移図間での呼出関係を含む終了状態の制御を可能とすることもでき、あるいは仕様書データが、画面遷移図上の開始状態に対応して、その状態に対応するデータ入出力オブジェクトと、入出力の順序をさらに定義可能であり、複数の画面遷移図間での呼出関係を含む開始状態の制御を可能とすることもできる。

実施の形態においては、仕様書データが、複数の画面遷移図の間で同一名称のオブジェクトの複数のインスタンスが同一であるか否かを、そのインスタンスに対するスコープの指定によりさらに区別可能であることも、また仕様書データが画面遷移図内の分岐処理に対応して、その分岐の条件を示すパラメータ入力オブジェクトをさらに指定可能であることもでき、さらに仕様書データが分散オブジェクト型コンポーネントのプロトコルに基いて、分散オブジェクト型コンポーネントの呼出を可能にするデータをさらに含むこともできる。

本発明のユーザインタフェースアプリケーション開発装置は、仕様書データ読込手段とプログラム生成手段とを備える。仕様書データ読込手段は、画面と処理とが記述される形式の画面遷移図に相当する仕様書データであって、画面、および／または処理と入出力データとしてのオブジェクトとの間の関連付けを行うことが可能なアプリケーション開発用仕様書データを読み込むものであり、プログラム生成手段は、前述の画面、または処理とオブジェクトの間の関連付けを含んで、読み込まれた仕様書データを自動的に解釈し、ユーザインタフェースアプリケーションプログラムを生成するものである。

本発明によれば、画面や処理を記述するアクティビティとオブジェクトの間のデータ入出力関係、外部のプログラムなどを呼び出す呼出アクティビティにおける入出力の指定、開始状態や終了状態に対応する制御など、例えば従来のＵＭＬの表記方法では表記することが困難であった仕様を新たに指定可能とすることにより、ユーザインタフェースを持つアプリケーションプログラムの完全な自動生成を行うことが可能となり、プログラムの開発、および保守効率の向上に寄与するところが大きい。

図２は、本発明におけるユーザインタフェースアプリケーション自動開発方式の全体説明図である。本発明の実施の形態においては、まずプラットフォームに依存しない、例えばＵＭＬによって記述された定義体１０が作成され、その定義体１０に対してプラットフォームに依存する自動生成ツールを用いることによって、ユーザインタフェースアプリケーションとしてのＷｅｂアプリケーション、またはクライアントアプリケーションが作成される。

図２において、例えばＪａｖａ Ｓｅｒｖｅｒ Ｐａｇｅｓ（ＪＳＰ）／Ｓｅｒｖｌｅｔ用の自動生成ツール１１ａを用いることによって、ＪＳＰ／Ｓｅｒｖｌｅｔ用のＷｅｂアプリケーション１２ａが作成される。同様にＷｅｂサーバ上でページを生成する仕組みの１つとしてのＡｃｔｉｖｅ Ｓｅｒｖｅｒ Ｐａｇｅｓ（ＡＳＰ）．ＮＥＴ用の自動生成ツール１１ｂを用いることによって、Ｗｅｂアプリケーション１２ｂが作成される。

またブラウザにダウンロードして実行されるＪａｖａ（登録商標）のクライアントソフトであるＪａｖａ Ａｐｐｌｅｔ用の自動生成ツール１１ｃを用いることによって、Ｊａｖａ Ａｐｐｌｅｔ用のクライアントアプリケーション１２ｃが作成される。

さらにグラフィックユーザインタフェースを簡単に作成するためのベーシックを基にしたプログラミング言語としてのＶｉｓｕａｌ Ｂａｓｉｃ用の自動生成ツール１１ｄを用いることによって、Ｖｉｓｕａｌ Ｂａｓｉｃ用のクライアントアプリケーション１２ｄが作成される。

図３は、本実施形態における各種の自動ツールを利用した、ユーザインタフェースアプリケーションに対する定義ファイルの生成からアプリケーションプログラムの実行、および検証までのユーザインタフェースアプリケーション開発方式の全体説明図である。同図において前述のように、例えばＵＭＬによって定義図／表１５が記述され、その記述に対応して仕様定義ツールによって仕様定義ファイル１６が作成される。

そして仕様定義ファイル１６を用いて、自動生成ツールによってプログラムに相当するソースコードや定義体など１７が自動的に生成され、その生成結果を用いて仕様実行エンジン１８によってその仕様、すなわちプログラムが実行され、検証ツールによって仕様実行結果が検証され、デバッグ情報が生成され、例えばイベント通知としてそのデバッグ情報が仕様定義ファイルに与えられ、必要に応じて仕様定義ファイルの修正が行われる。

図４は本実施形態において解決されるアプリケーション領域の説明図である。前述のように本実施形態におけるアプリケーション領域は、プラットフォーム非依存部２０を主体として構成されるが、当然プラットフォームに依存する画面デザイン２１と外部コンポーネント呼び出し２２とを含むことになる。

プラットフォーム非依存部２０は、本実施形態におけるユーザインタフェースアプリケーション開発の主体となる画面遷移２５、ロジックフロー２６と、ロジックフロー２６に対応するビジネスアクティビティ（ビジネスロジック）実装２７を主たる構成要素として含んでいる。画面遷移２５に対しては、画面項目の管理と表示内容編集が必要となり、ビジネスアクティビティ実装２７に対しては、入力値のチェック、入力値編集、およびパターン適用が必要となる。

図５は、本実施形態において作成される定義体の全体構成図である。同図において定義体は、図４のアプリケーション領域に対応して、画面遷移図３０、ロジックフロー図３１、データ定義図３２、および画面レイアウト３３によって基本的に構成されている。

画面遷移図３０は、画面とロジック（処理）とが必要に応じて、例えば交互に記述され、画面とロジックの間の遷移、各画面に関連する項目やレイアウトを表現するものであり、例えばＵＭＬアクティビティ図である。またロジックフロー図３１は、画面遷移図内のロジックの詳細を記述するものであり、例えば同様にＵＭＬアクティビティ図である。

また画面レイアウト３３は、画面のレイアウト情報を記述するものであり、Ｗｅｂアプリケーションの実装では、ＪＳＰページによって表現される。データ定義図３２は、アクティビティ図を含まないクラス図によって表現され、画面項目定義３４、列挙定義３５、および中間データ項目定義３６などの項目定義に利用される。

画面項目定義３４は、画面表示のための項目を定義するものであり、項目は名前と型から構成され、型としては文字列、整数、実数、複合型などがある。列挙定義３５は、列挙項目の定義を行うものであり、また中間データ項目定義３６は、例えばロジックフロー図に相当するビジネスフロー定義の内部で利用される中間的なデータの項目定義に用いられる。なおロジックフロー図はビジネスロジックをビジネスアクティビティ間のフローとして表現したものである。

本実施形態においては、図５で説明した画面遷移図３０、およびロジックフロー図３１の表現例としてのＵＭＬアクティビティ図において、従来と異なる新たな表記法を用いることによって、ユーザインタフェースアプリケーションとしてのプログラムの完全な自動生成を可能とするものであり、そのようなアクティビティ図の具体例を図６を用いて説明する。

図５で説明した画面遷移図３０としてのＵＭＬアクティビティ図では、一般的に開始状態（初期状態）と終了状態（最終状態）との間で、画面を表すアクティビティと、処理（ロジック）を表すアクティビティとを、例えば交互に、あるいは複数の処理を連続して実行する形式で図面が記述される。

図６はロジックフロー図の簡単な例であり、開始状態４０と終了状態、ここでは２つの終了状態４２、４３との間のロジックフローが記述される形式となっており、ＥｘｅｃｕｔｅＳｅａｒｃｈ アクティビティ４１は、Ｃａｌｌアクティビティと呼ばれ、他のロジックフローや、モデルの外部を含む他のメソッドを呼び出すために使用されるアクティビティである。

本実施形態では、このようなロジックフローや画面遷移図において、アクティビティに対するデータ入出力を行なうオブジェクトの指定を可能とするとともに、コールアクティビティに対しては、呼出対象となるオブジェクトの指定を可能とするところに１つの特徴がある。なお各オブジェクトには識別子（ＩＤ）として名称が付加されており、この名称がクラスの型を示すものと解釈されてプログラムの生成が行われる。

例えばアクティビティ４１に対しては、２つのオブジェクトＵｓｅｒＢｅａｎ４４、ＳｅａｒｃｈＣｏｎｄｉｔｉｏｎＢｅａｎ４５からの入力データが与えられ、また開始状態４０からオブジェクトＳｅａｒｃｈＣｏｎｄｉｔｉｏｎＢｅａｎ４５に対して出力が与えられることが、ステレオタイプ＜＜ＮｉｊｏＩｎ＞＞、および＜＜ＮｉｊｏＯｕｔ＞＞の矢印によって示され、またオブジェクトＳｅａｒｃｈＵｔｉｌｉｔｙ４６が呼出対象となるオブジェクトであることが＜＜ＮｉｊｏＴａｒｇｅｔＩｎｓｔａｎｃｅ＞＞の矢印によって指定されている。

終了状態４２に関しては、オブジェクト４６の呼出結果に対応した処理が正常に終了した場合にオブジェクトＲｅｓｕｌｔＢｅａｎ４７に、例えば図６のロジックフローの呼出元への返り値が格納され、その返り値は終了状態４２への入力となる。なお本実施形態では、例えばオブジェクト４６を瞬間的な状態ではなく、アクティビティ４１などの状態がアクセスするオブジェクトフロー状態として定義する。

オブジェクト４６の呼出結果による処理が異常終了の場合には［ＳｅａｒｃｈＥｘｃｅｐｔｉｏｎ］のガード（遷移条件）が適用され、オブジェクトＳｅａｒｃｈＥｘｃｅｐｔｉｏｎ４８に例外が格納され、終了状態４３へのアクティビティ４１からの遷移が行われるとともに、その例外は終了状態４３に対する入力となる。

本実施形態におけるユーザインタフェースアプリケーションの完全な自動開発のために用いられる様々な新しい表記法についてさらに説明する前に、図７と図８を用いてプログラムの開発処理の基本的フローチャートを説明する。図７は、図２に対応してプラットフォームに依存する実際のアプリケーションプログラムを生成する処理の全体フローチャートである。同図において処理が開始されると、まずステップＳ１０で、例えばテキスト形式の定義（体）が読み込まれ、ステップＳ１２でその定義体が、例えばＵＭＬ言語における内部モデル、例えばＪａｖａ（登録商標）言語のオブジェクトモデルに変換され、ステップＳ１２でそのモデルが正当であるか否かのバリディティチェックが行われる。このステップＳ１２まではプラットフォームに依存しない処理である。

続いてステップＳ１３で、内部モデル構造がターゲット、すなわちプラットフォームに依存する構造に変換され、ステップＳ１４で図２で説明したようなプラットフォームに依存したアプリケーションプログラムとしてのファイルが出力されて処理を終了する。

図８は、図７のプラットフォームに依存しない処理としてのステップＳ１０からステップＳ１２の処理のうちで、特にステップＳ１０とＳ１１とを強調したプログラム自動生成処理のフローチャートである。同図において処理が開始されると、まずステップＳ２１で、例えばＵＭＬアクティビティ図によって表現された画面遷移図、ロジックフロー図など、図５で説明した定義体などが記述された仕様書が読み込まれ、ステップＳ２２でその仕様書が中間形式としてのＸＭＬテキスト形式にＸＭＩ（ＸＭＬ Ｍｅｔａｄａｔａ Ｉｎｔｅｒｃｈａｎｇｅ）によって変換される。その変換用には、市販のＵＭＬツール、またはフリーのツールを使用することができる。異なるＣＡＳＥツール間でのデータ変換のための標準フォーマットであるＸＭＩは、ＵＭＬの拡張部分を扱うことができ、仕様書に書かれているものは忠実にテキストに落とされるために、本実施形態において新しく定義される表記法を用いても、中間形式への変換は問題なく実行される。

続いてステップＳ２３で中間処理が行われる。この中間処理では、ステップＳ２２で出力された中間形式ファイルが読み込まれ、例えば図６で説明したようなアクティビティとオブジェクトの間の入出力関係、オブジェクトの呼出関係などの解釈が行われ、ステップＳ２４でその解釈に基いてプログラムとしてのファイルが生成されて処理を終了する。

以下本実施形態における仕様の新しい表記方式の具体例について、アクティビティ図の例に対応させて、図８のフローチャートにおけるステップＳ２３の中間処理、およびステップＳ２４のプログラム生成処理について説明する。

図９は、例えば画面遷移図としてのアクティビティ図の一部を示し、ＰｒｅｐａｒｅＣｏｎｄｉｔｉｏｎ５０というＣａｌｌアクティビティ、すなわち処理を表すアクティビティからＣｏｎｄｉｔｉｏｎＩｎｐｕｔ５１という画面表示用アクティビティへの遷移と、このアクティビティ５１からＥｘｅｃｕｔｅＳｅａｒｃｈ４１とＱｕｉｔ５３の２つのアクティビティへの分岐が示されている。ここでアクティビティ５１は、例えばＪＳＰ画面表示を表すオブジェクトであり、このようなアクティビティをＵＩ（ユーザインタフェース）アクティビティと呼ぶことにする。アクティビティ５０の処理終了後に、その結果に対応して画面表示が実行される。

このアクティビティ５１と、２つのオブジェクト４４、４５との間には依存関係があり、図６で説明したようにこれら２つのオブジェクトは、ＵＩオブジェクト５１に対する画面表示のための入力データを示すオブジェクトであることが表記され、またオブジェクト４５は、同時にＵＩアクティビティ５１からの出力データを示すオブジェクトであることも表記されている。すなわちユーザが画面において入力したデータは、画面から見るとオブジェクト４５への出力の意味を持つことになる。

ＵＩアクティビティ５１から２つのアクティビティ４１と５３への分岐は、例えばユーザが画面上で２つのボタンのいずれを押すかによって分岐が決定される。アクティビティ４１、５３への矢印にそれぞれつけられているガード（遷移条件）としての［ｓｅａｒｃｈ］、および［ｑｕｉｔ］が画面上のボタン名に相当し、ユーザがどちらのボタンを押すかによって分岐が決定される。

図９において、ＵＩアクティビティ５１は、ＳｃｒｅｅｎＬａｙｏｕｔ５２というプロパティと関連付けられ、ＪＳＰにおける画面レイアウトを表すことができる。図１０は、この画面レイアウトに関連するアクティビティ図の一部を示す。図９のＳｃｒｅｅｎ Ｌａｙｏｕｔ５２には、ｍａｉｎ．ｊｓｐとして画面がヘッドペインと、ボディーペインとの２つの部分からなることが記述されており、図１０においてＵＩアクティビティ５１がＵｓｅｒＢｅａｎオブジェクト４４と、ＳｅａｒｃｈＣｏｎｄｉｔｉｏｎＢｅａｎオブジェクト４５とを表示するにあたり、ヘッドペインにｈｅａｄ１．ｊｓｐというレイアウトファイルを利用してオブジェクト４４を表示し、ボディーペインにｃｏｎｄ．ｊｓｐというレイアウトファイルを利用してオブジェクト４５の表示を行うことが指定されている。

図９、図１０に対応して図８のステップＳ２３における中間処理、ステップＳ２４におけるプログラム生成処理について説明する。
ステップＳ２３では中間形式ファイル（ＸＭＩ）を読み込んで
（１） 作成するＪＳＰファイル名（ＣｏｎｄｉｔｉｏｎＩｎｐｕｔ．ｊｓｐ）をアクティビティ名のＣｏｎｄｉｔｉｏｎＩｎｐｕｔから特定する。
（２） ＸＭＩではＩＤで関連付けされているレイアウト情報（ｍａｉｎ．ｊｓｐ）とそのｐａｎｅ名（ｈｅａｄ／ｂｏｄｙ）およびｐａｎｅに連結するｊｓｐファイル（ｈｅａｄ＝ｈｅａｄ１．ｊｓｐ／ｂｏｄｙ＝ｃｏｎｄ．ｊｓｐ）をＰａｎｅＬａｙｏｕｔ定義から特定する。
（３） それぞれのｐａｎｅとｐａｎｅで使うオブジェクトとの関連付けを特定する。
（４） ＣｏｎｄｉｔｉｏｎＩｎｐｕｔから出ている２つの線のアクション名［ｓｅａｒｃｈ］［ｑｕｉｔ］からボタン名を特定する。
（５） オブジェクトとそのメソッドの関連付けを特定する。

ステップＳ２４では上記の情報に基づいてファイルを作成する。
（１） 表示ｈｅａｄ１．ｊｓｐ／ｃｏｎｄ．ｊｓｐ／ＣｏｎｄｉｔｉｏｎＩｎｐｕｔ．ｊｓｐを作成し、ｐａｎｅおよびそこで使われるオブジェクトとのリンクタグを埋め込む。
（２） 上記ファイルにボタンとオブジェクトリンクタグを埋め込む。
（３） ボタンと関連付けされた処理メソッドをテーブルに書き出す。（このテーブルは、このテーブルを読み込む仕様のＳｅｒｖｌｅｔに対応する。そのような動作に対応しない場合には、ファイルに直接メソッドを呼び出すリンクを埋め込む）
（４） 処理メソッドプログラムを書き出す。具体的には次のようになる。

ＣｏｎｄｉｔｉｏｎＩｎｐｕｔ．ｊｓｐ：
略．．
＜ｉｎｃｌｕｄｅ ｐａｎｅ＝“ｈｅａｄ”／＞
＜ｉｎｃｌｕｄｅ ｐａｎｅ＝“ｂｏｄｙ”／＞
略．．
ｈｅａｄ１．ｊｓｐ：
略．．
＜ｊｓｐ：ｕｓｅＢｅａｎ．．．ｉｄ＝ｈｅａｄ．．．ｃｌａｓｓ＝“ＵｓｅｒＢｅａｎ”／＞
略．．
ｃｏｎｄ．ｊｓｐ：
略．．
＜ｊｓｐ：ｕｓｅＢｅａｎ．．．ｉｄ＝ｂｏｄｙ．．．ｃｌａｓｓ＝“ＳｅａｒｃｈＣｏｎｄｉｔｉｏｎＢｅａｎ”／＞
＜ｉｎｐｕｔ ｖａｌｕｅ＝“ｓｅａｒｃｈ”ｔｙｐｅ＝“ｓｕｂｍｉｔ”ｎａｍｅ＝“ｓｅａｒｃｈ○○”／＞
＜ｉｎｐｕｔ ｖａｌｕｅ＝“ｑｕｉｔ”ｔｙｐｅ＝“ｓｕｂｍｉｔ”ｎａｍｅ＝“ｑｕｉｔ××”／＞
略．．
テーブル：
略．．
ＳｅａｒｃｈＣｏｎｄｉｔｉｏｎＢｅａｎ；ｓｅａｒｃｈ○○＝ＥｘｅｃｕｔｅＳｅａｒｃｈ．ｓｅａｒｃｈ＿ｍｅｔｈｏｄ
ＳｅａｒｃｈＣｏｎｄｉｔｉｏｎＢｅａｎ；ｑｕｉｔ××＝Ｑｕｉｔ．ｑｕｉｔ＿ｍｅｔｈｏｄ
略．．

図１１、および図１２は、図６で説明した呼出アクティビティの仕様の表記例の説明図である。前述のように呼出アクティビティは、Ｃａｌｌアクティビティと呼ばれ、図１１においてコールアクティビティとしてのＡｃｔｉｖｉｔｙ１ ５５は、２つのオブジェクト４４、４５との間に依存関係があり、これらのオブジェクトから入力データを受け取る。その時、処理の内容として２つの入力データがどの順序で与えられるべきか、すなわち入力パラメータの順序がインデックスの値として指定される。このインデックスの値を指定することによって入力データの数も指定されることになる。このように本実施形態では、アクティビティとオブジェクトを結ぶ線分に矢印を付け、またラベルと順番をつけたところに特徴がある。

図１１において、図６におけると同様にＣａｌｌアクティビティ５５は、ＬｏｇｉｃＨａｎｄｌｅｒクラス５６を呼び出しており、そのインスタンスの名前はｈａｎｄｌｅｒであることが示されている。さらにＡｃｔｉｖｉｔｙ１のオペレーションタグ付値で表されるロジックハンドラークラスのロジックオペーレーションメソッドが呼び出されることが示されている。

図８のフローチャートのステップＳ２３の中間処理では中間形式ファイル（ＸＭＩ）を読み込んで
（１） Ａｃｔｉｖｉｔｙ１が呼び出す対象は＜＜ＮｉｊｏＴａｒｇｅｔＩｎｓｔａｎｃｅ＞＞で示されるＬｏｇｉｃＨａｎｄｌｅｒクラス（インスタンス名はｈａｎｄｌｅｒ）であり、さらに、Ａｃｔｉｖｉｔｙ１のＯｐｅｒａｔｉｏｎタグ付き値で表されるＬｏｇｉｃＨａｎｄｌｅｒクラスのｌｏｇｉｃＯｐｅｒａｔｉｏｎメソッドを呼び出すことを特定する。
（２） ＸＭＩではＩＤで関連付けされている入出力情報を検索し、その順序（ｉｎｄｅｘを読み込み）も含めて特定する。この例ではＵｓｅｒＢｅａｎ，ＳｅａｒｃｈＣｏｎｄｉｔｉｏｎＢｅａｎが順に上記クラスのメソッドの入力パラメータとして使われていることが特定される
（３） ＜＜ＮｉｊｏＯｕｔ＞＞で関連付けさているＲｅｓｕｌｔＢｅａｎクラスのオブジェクトが出力されることを特定する。

ステップＳ２４では上記の情報に基いてファイルを作成する。
オペレーションの呼出部分を作成する。具体的には次のようになる。
ＬｏｇｉｃＨａｎｄｌｅｒ ｈａｎｄｌｅｒ＝ｎｅｗ ＬｏｇｉｃＨａｎｄｌｅｒ（）；
ＲｅｓｕｌｔＢｅａｎ ｒｅｓ＝ｈａｎｄｌｅｒ．ｌｏｇｉｃＯｐｅｒａｔｉｏｎ（ＳｅａｒｃｈＣｏｎｄｉｔｉｏｎＢｅａｎのオブジェクト、ＵｓｅｒＢｅａｎのオブジェクト）；

次に終了状態からの返り値の記述方法について説明する。例えば複数のアクティビティ図の間で、プログラムのサブルーチンに対応する部分的なアクティビティ図（モジュール）がある場合には、その部分的なアクティビティ図からその呼び出し元への返り値が終了状態に対応して必要となるが、その記述方法について図１２から図１５を用いて説明する。図１２は単一終了状態に付随する返り値の表記方法の説明図である。同図においては終了状態５８に付随する返り値は入力値としてのオブジェクト４７となり、この終了状態が含まれるオペレーションの仕様は次のように記述される。

ＲｅｓｕｌｔＢｅａｎ メソッド名（引数）；
図１２で、終了状態５８とオブジェクト４７との間に依存関係がない場合には、返り値が無いものとして扱われる。その場合、この終了状態５８が含まれるオペレーションの仕様は次のように記述される。

ｖｏｉｄ メソッド名（引数）；
図１３は終了状態に対応して式などを設定し、終了状態に対応する動作、および処理を指定する例である。同図において終了状態５８に対応してＵＲＬ５９が設定されており、終了状態５８から、例えばこのＵＲＬによって指定されるメニュー画面への移動動作を設定することが可能となる。

図１４は例外の終了状態に付随する返り値の記述例の説明図である。同図の例では、終了状態５９が含まれるオペレーションの仕様は、ＳｅａｒｃｈＥｘｃｅｐｔｉｏｎをｔｈｒｏｗｓ句に記述することにより、次のような形式となる。
返り値 メソッド名（引数） ｔｈｒｏｗｓＳｅａｒｃｈＥｘｃｅｐｔｉｏｎ；

図１５は複数の終了状態を含むアクティビティ図の例である。同図においてＡｃｔｉｖｉｔｙ１ ５５からの遷移が行われる終了状態ｎｏｒｍａｌ６１からは、２つのオブジェクト４４、４７が返り値となり、またＡｃｔｉｖｉｔｙ２ ６０からの遷移が行われる終了状態ｈｙｐｅｒ６２からの返り値はオブジェクト４５となる。そして終了状態６１からの返り値に対してはインデックスの値によってその順序が指定されている。終了状態６２からの返り値に対するインデックスは省略可能である。なお図の一番上のひし形は条件分岐を表す。この終了状態が含まれるオペレーションの仕様は次のように記述される。

ＮｉｊｏＲｅｓｕｌｔＳｅｔ メソッド名（引数）；
図８のフローチャートのステップＳ２３では中間形式ファイル（ＸＭＩ）を読み込んで
（１） この終了状態が含まれるオペレーションを検索し、メソッド名を特定する。
（２） 終了状態からリンクされた入力データが無しの場合には返り値としてｖｏｉｄを特定する。入力データが１つの場合はリンクされたオブジェクト名を返り値として特定する。例外の場合はｔｈｒｏｗｓ句として特定する。複数の終了状態を持つ場合は、全部を含むＮｉｊｏＲｅｓｕｌｔというクラスを作成し、その属性としてそれぞれの状態名と返り値のリンクおよび返り値のオブジェクトの順番を保持する。
（３） 式（ＵＲＬ）がリンクされているかどうかを検索し、特定する。

ステップＳ２４では上記の情報に基いてファイルを作成する。
（１） オペレーションのシグネチャを作成する時、それぞれのケースに応じたメソッドのシグネチャを書き出す。
（２） ＮｉｊｏＲｅｓｕｌｔの場合は、返り値をそのクラスの属性として、終了状態名に応じてＳｅｔ／Ｇｅｔするメソッドを作成する。

ＮｉｊｏＲｅｓｕｌｔ ｒｅｓ＝ｎｅｗ ＮｉｊｏＲｅｓｕｌｔ（）；
ｒｅｓ．ｓｅｔ（ｎｏｒｍａｌ，１，ＲｅｓｕｌｔＢｅａｎ）；
ｒｅｓ．ｓｅｔ（ｎｏｒｍａｌ，２，ＵｓｅｒＢｅａｎ）；
ｒｅｓ．ｓｅｔ（ｈｙｐｅｒ，１，ＳｅａｒｃｈＣｏｎｄｉｔｉｏｎＢｅａｎ）；
．．．．
（３） 式がリンクされている場合は次の動作として書き出す。

図１６は開始状態に付随する入出力オブジェクト表記方法の説明図である。同図において開始状態６３からアクティビティ５５への遷移が行われるが、同時に開始状態６３が２つのオブジェクト４４、４５を出力しており、そのオペレーションの仕様は次のようになる。
返り値 オペレーション名（ＵｓｅｒＢｅａｎ，ＳｅａｒｃｈＣｏｎｄｉｔｉｏｎＢｅａｎ）；

図８のフローチャートのステップＳ２３では中間形式ファイル（ＸＭＩ）を読み込んで
（１） この開始状態が含まれるオペレーションを検索し、メソッド名を特定する。
（２） 開始状態からリンクされた出力データが無しの場合はパラメータ無しとして特定する。リンクがある場合には、それぞれｉｎｄｅｘの順番に基いてＸＭＩファイルを検索して特定する。図１６の例では、ＵｓｅｒＢｅａｎが１つ目のパラメータ、２つ目のパラメータがＳｅａｒｃｈＣｏｎｄｉｔｉｏｎＢｅａｎのように特定する。

ステップＳ２４では上記の情報に基いてファイルを作成する。すなわちオペレーションに関するシグネチャの作成時にパラメータ名を書き出す。
次にアクティビティインスタンスのライフサイクル仕様の記述方法について、図１７と図１８を用いて説明する。一般に異なる画面遷移アクティビティ図上において、オブジェクトのスコープと識別子、例えば名前を指定することによって、同一のインスタンス、または異なるインスタンスに対するオペレーションを表現することができる。図１７においては、左側の画面遷移図では、Ｃｈｅｃｋ Ｃｏｎｄｉｔｉｏｎアクティビティ６５が、右側の画面遷移図では、Ｓｅａｒｃｈ Ｃｏｎｄｉｔｉｏｎアクティビティ６７が同じＳｅａｒｃｈＵｔｉｌｉｔｙオブジェクトフロー状態６６をそれぞれ指定しているが、これらのオブジェクトのインスタンスがそのスコープをＳｅｓｓｉｏｎとし、同じ名前を指定しているため、２つのオブジェクト６６のインスタンスが同一のものであることが指定されている。

オブジェクトの生存期間を示すスコープについては、５つの区別が可能なものとする。その種類としては、現在のフローに対応するページだけに有効なＬｏｃａｌ、クライアントからのリクエストに対して応答が返るまでの間有効なＲｅｑｕｅｓｔ、サーバ側で管理され、画面が変わってもオブジェクトが生かされるＳｅｓｓｉｏｎ、現在のアプリケーションの間有効なＡｐｐｌｉｃａｔｉｏｎ、およびシステム全体で有効なＳｙｓｔｅｍの５種類があるものとする。

図１８は、異なるインスタンスの指定方式の記述例である。同図においてはアクティビティ６５と６７が、それぞれ同じクラス６６を指定しているが、インスタンスの名前が異なることが示されている。

図１７、図１８に対応して図８のフローチャートの処理を説明する。ステップＳ２３では中間形式ファイル（ＸＭＩ）を読み込んで
（１） 図１８ではＣｈｅｃｋＣｏｎｄｉｔｉｏｎにリンクされたＮｉｊｏＴａｒｇｅｔＩｎｓｔａｎｃｅ情報を検索し、その名前からＳｅａｒｃｈＵｔｉｌｔｙクラスであることを特定する。関連情報としてＳｃｏｐｅがＳｅｓｓｉｏｎでオブジェクトの名前がｕｔｉｌ１であることを特定する。
（２） ＳｅａｒｃｈＣｏｎｄｉｔｉｏｎにリンクされたＮｉｊｏＴａｒｇｅｔＩｎｓｔａｎｃｅ情報を検索し、その名前からＳｅａｒｃｈＵｔｉｌｔｙクラスであることを特定する。関連情報としてＳｃｏｐｅがＳｅｓｓｉｏｎでオブジェクトの名前がｕｔｉｌ２であることを特定する。
（３） 上記でオブジェクトの名前およびＳｃｏｐｅが図１７のように一致する場合には、同じインスタンスを呼び出すものと特定し、ＣｈｅｃｋＣｏｎｄｉｔｉｏｎで使ったのと同じオブジェクトインスタンスをＳｅａｒｃｈＣｏｎｄｉｔｉｏｎで使えるようにする。
（４） Ｓｃｏｐｅまたは名前が違う場合には異なるインスタンスなので、別々のオブジェクトを生成して使うようにする。

ステップＳ２４では上記の情報に基いてファイルを作成する。
上記特定事項に基いて、同じインスタンスを呼び出す場合はオブジェクトの受け渡しができるようにプログラムを生成する。実際には、メソッドの外でセッションごとのオブジェクトを作成し、オブジェクトテーブルにて管理しておくので、メソッド内で使うときには名前で引いてくるだけでよい。

インスタンスが異なる場合の例を具体的に以下に示す。
ＣｈｅｃｋＣｏｎｄｉｔｉｏｎから呼び出されるＳｅａｒｃｈＵｔｉｌｔｙ．ｊａｖａクラスのメソッド
呼び出しターゲット＝セッションオブジェクトテーブルｇｅｔ（ｕｔｉｌ１）；
呼び出しターゲット＝ｃｈｅｃｋ（．．．）；
ＳｅａｒｃｈＣｏｎｄｉｔｉｏｎから呼び出されるＳｅａｒｃｈＵｔｉｌｔｙ．ｊａｖａクラスのメソッド
呼び出しターゲット＝セッションオブジェクトテーブルｇｅｔ（ｕｔｉｌ２）；
呼び出しターゲット＝ｓｅａｒｃｈ（．．．）；

図１９は、条件分岐に対する条件としてのパラメータ指定の記述方法の説明図である。図１５で説明したように、アクティビティ図ではひし形で条件分岐が表されるが、従来は条件自体は記述することができても、条件判断の対象となるパラメータを指定することはできなかった。ここでは依存関係のあるオブジェクトを条件判断に対する入力パラメータとすることで、条件判断のパラメータを表現することを可能する。すなわち図１９では、条件分岐６８と依存関係があり、入力を与えるオブジェクト４５の値を基にして分岐が行われる。オブジェクト４５のｎａｍｅプロパティが、“ｆｏｏ”であればアクティビティ６９へ、そうでなければアクティビティ６０への分岐が行われる。

図８のフローチャートのステップＳ２３では中間形式ファイル（ＸＭＩ）を読み込んで
（１） 分岐と分岐に関連する入力データＳｅａｒｃｈＣｏｎｄｉｔｉｏｎＢｅａｎを検索して特定する。
（２） ＳｅａｒｃｈＣｏｎｄｉｔｉｏｎＢｅａｎクラスのインスタンスがｃｏｎｄと表記されていることから
分岐からの条件文［ｃｏｎｄ．ｎａｍｅ＝“ｆｏｏ”］と［ｅｌｓｅ］の行き先ａｃｔｉｖｉｔｙを特定する。

ｉｆ文の条件にｃｏｎｄ．ｎａｍｅ＝“ｆｏｏ”が入り、ｔｒｕｅの場合にはＡｃｔｉｖｉｔｙ３に行くことがわかり、ｆａｌｓｅの場合にはＡｃｔｉｖｉｔｙ２に行くことがわかる。

ステップＳ２４では上記の情報に基いてファイルを作成する。
上記仕様を反映するプログラムを書き出す。具体的には次のようになる。
ｉｆ（ｃｏｎｄ．ｎａｍｅ＝“ｆｏｏ”）
Ａｃｔｉｖｉｔｙ３のターゲットクラス．メソッド名（）；
ｅｌｓｅ
Ａｃｔｉｖｉｔｙ２のターゲットクラス．メソッド名（）；

最後に分散オブジェクト型コンポーネントの呼出仕様の記述方式について図２０によって説明する。ここでは、分散オブジェクト型コンポーネントの代表アプリケーションとして、サーバサイドＪａｖａにおける技術仕様であるＥＪＢ（Ｅｎｔｅｒｐｒｉｓｅ Ｊａｖａ Ｂｅａｎｓ）コンポーネントを考え、Ｅｎｔｉｔｙ Ｂｅａｎを例として説明する。このようなＥＪＢに代表される分散コンポーネントをアクティビティ図において呼び出すことによって、例えばフローチャートなどでやり取りを書いた場合の欠点、すなわち実際の動作で何度にもわたってリクエスト、レスポンスが発生し、それらをいちいち記述しなくてはならないという欠点を避けることができる。このような分散コンポーネントにおける処理は定型のため、コンフィグレーション情報さえあれば、ユーザが書くべきコードを組み立てることは容易である。このＥＪＢアクティビティは、このような定型処理で扱われる情報を表す例として代表的なものである。

図８のフローチャートのステップＳ２３では中間形式ファイル（ＸＭＩ）を読み込んで
（１） ＣａｌｌｉｎｇＭｙＥｎｔｉｔｙＢｅａｎアクティビティのステレオタイプがＮｉｊｏＥＪＢであることを特定し、ＥＪＢコンポーネントを呼び出すための情報を探す。
（２） ＜＜ＮｉｊｏＴａｒｇｅｔＩｎｓｔａｎｃｅ＞＞でＦｉｎｄｅｒが付いていないので、ＭｙＥｎｔｉｔｙＢｅａｎが呼び出すクラスであることがわかる。
（３） Ｆｉｎｄｅｒに指定されていないＥｎｔｉｔｙＡｒｇｕｍｅｎｔＢｅａｎが＜＜ＮｉｊｏＩｎ＞＞であることからｄｏＢｕｓｉｎｅｓｓのパラメータとなることを特定する。
（４） ＣａｌｌｉｎｇＭｙＥｎｔｉｔｙＢｅａｎのタグ付き値からＪＮＤＩ名＝ＭｙＥｎｔｉｔｙＢｅａｎ，ＥＪＢのタイプがＳｅｓｓｉｏｎではなくＥｎｔｉｔｙ、ＦｉｎｄｅｒＯｐｅｒａｔｉｏｎ＝ＭｙＥＪＢＨｏｍｅ．ｆｉｎｄＢｙＰｒｉｍａｒｙＫｅｙ、呼び出しＯｐｅｒａｔｉｏｎがＭｙＥｎｔｉｔｙＢｅａｎクラスのｄｏＢｕｓｉｎｅｓｓメソッドであることを特定する。
（５） ＜＜ＮｉｊｏＴａｒｇｅｔＩｎｓｔａｎｃｅ＞＞Ｆｉｎｄｅｒに指定されているＨｏｍｅオブジェクトと同じく、Ｆｉｎｄｅｒに指定されている入力オブジェクトがＦｉｎｄｅｒＡｒｇｕｍｅｎｔＢｅａｎＨｏｍｅオブジェクトの同じＦｉｎｄｅｒパラメータであることを特定する。
（６） ＜＜ＮｉｊｏＯｕｔ＞＞には、ＲｅｓｕｌｔＢｅａｎがあり、これが出力オブジェクトとなる。もう１つはＥＪＢＥｘｃｅｐｔｉｏｎラベルが付いているので、例外時に出力されるＥｘｃｅｐｔｉｏｎクラスであることがわかる。例外時にはこのオブジェクトを出力してＡｃｔｉｖｉｔｙ３に移行し、正常時はＡｃｔｉｖｉｔｙ２に移行する。

ステップＳ２４では上記の情報に基いてファイルを作成する。この例では以下の内容のコードが生成される。
１． ＪＮＤＩタグ付き値が指定されているために、ＭｙＥｎｔｉｔｙＢｅａｎをキーとしてＭｙＥＪＢＨｏｍｅオブジェクトを取得する。呼び出した結果得られたオブジェクトはＭｙＥＪＢＨｏｍｅオブジェクトフロー状態で示されるオブジェクトに格納される。
２． ＭｙＥＪＢＨｏｍｅのｆｉｎｄＢｙＰｒｉｍａｒｙＫｅｙメソッドを呼び出す。その際、ＦｉｎｄｅｒＡｒｇｕｍｅｎｔＢｅａｎオブジェクトフロー状態で示されるオブジェクトを引数とする。呼び出した結果得られたオブジェクトはＭｙＥｎｔｉｔｙＢｅａｎオブジェクトフロー状態で示されるオブジェクトに格納される。
３． 上記で得られたＭｙＥｎｔｉｔｙＢｅａｎに対し、ｄｏＢｕｓｉｎｅｓｓメソッドを呼び出す。引数はＥｎｔｉｔｙＡｒｇｕｍｅｎｔＢｅａｎオブジェクトフロー状態で示されるオブジェクトが使用される。結果はＲｅｓｕｌｔＢｅａｎに格納される。例外の場合、ＥＪＢＥｘｃｅｐｔｉｏｎに格納される。

以上の説明ではＵＭＬの画面遷移図、ロジックフロー図などのアクティビティ図を例として本発明の実施形態を説明したが、本発明の適用対象としてのプログラムの自動生成はＵＭＬに限定されないことは当然である。

本発明は例えばＷｅｂプログラムなど、ユーザインタフェースを持つアプリケーションプログラムを開発する必要のあるすべての産業、例えばそのようなプログラムをユーザ対象のビジネス業者などに提供するソフトウエア開発産業などにおいて利用可能である。

本発明のユーザインタフェースアプリケーション開発プログラムの原理的な機能ブロック図である。 本実施形態におけるユーザインタフェースアプリケーションプログラムの全体的な開発方式を説明する図である。 本実施形態における仕様書定義からその仕様実行までの全体方式の説明図である。 本実施形態におけるプラットフォームに依存しないアプリケーション領域の説明図である。 本実施形態における仕様書データに相当する定義体の説明図である。 ロジックフロー内のコールアクティビティの例を説明する図である。 定義体読込からプログラムファイル出力までの全体処理フローチャートである。 本実施形態における仕様書データ読込からプログラム生成までの全体処理フローチャートである。 アクティビティとデータ入出力オブジェクトとの間の関係付けの表記方法の説明図である。 画面アクティビティと画面表示レイアウトとの関係付けの表記方法の説明図である。 オブジェクトからアクティビティへのデータの入力順序の表記方法の説明図である。 終了状態からの返り値の表記方法の説明図である。 終了状態に対応する動作を指定する式の表記方法の説明図である。 例外の終了状態からの返り値の表記方法の説明図である。 複数の終了状態からの返り値の表記方法の説明図である。 開始状態とオブジェクトとの間のデータ入出力関係の表記方法の説明図である。 異なる画面遷移図間における同一インスタンスの表記方法の説明図である。 １つの遷移図内における同一オブジェクトの異なるインスタンスの表記方法の説明図である。 分岐処理に対するオブジェクトからの分岐条件パラメータの入力の表記方法の説明図である。 分散オブジェクト型コンポーネント呼出仕様の表記方法の説明図である。

符号の説明

１０ 定義体
１１ 自動生成ツール
１２ アプリケーション
１５ 定義図／表
１６ 仕様定義ファイル
１７ ソースコード、定義体等
１８ 仕様実行エンジン
２０ プラットフォーム非依存部
２１ 画面デザイン
２２ 外部コンポーネント呼び出し
２５ 画面遷移
２６ ロジックフロー
２７ ビジネスアクティビティ実装
３０ 画面遷移図（アクティビティ図）
３１ ロジックフロー図（アクティビティ図）
３２ データ定義図
３３ 画面レイアウト（ＪＳＰ）
３４ 画面項目定義（クラス図）
３５ 列挙定義（クラス図）
３６ 中間データ項目定義（クラス図）

Claims (10)

1. ユーザインタフェースアプリケーションのプログラムを自動生成するためのプログラムであって、
   画面と処理とが記述される形式の画面遷移図に相当する仕様書データであって、画面、および／または処理と入出力データとしてのオブジェクトとの間の関連付けを行うことが可能なアプリケーション開発用仕様書データを読み込むステップと、
   該読み込まれた仕様書データを、前記画面、および／または処理とオブジェクトとの間の関連付けを含んで自動的に解釈し、ユーザインタフェースアプリケーションプログラムを生成するステップとを計算機に実行させるためのユーザインタフェースアプリケーション開発プログラム。
2. 前記オブジェクトが画面表示の処理に対応するオブジェクトであり、前記仕様書データが該処理と表示される画面に対するデータ入出力オブジェクトとの関連付けに加えて、画面レイアウトをさらに示すことを特徴とする請求項１記載のユーザインタフェースアプリケーション開発プログラム。
3. 前記オブジェクトが画面遷移に関連する処理であって、外部の処理を呼び出すための処理に対応し、前記仕様書データが前記関連付けにおいて該関連する処理に対するそれぞれ複数の入力オブジェクト、または出力オブジェクトの順序を示すことを特徴とする請求項１記載のユーザインタフェースアプリケーション開発プログラム。
4. 前記仕様書データが、表示された画面上でユーザが次の状態遷移条件をさらに指定可能であることを特徴とする請求項１記載のユーザインタフェースアプリケーション開発プログラム。
5. 前記仕様書データが、前記画面遷移図上の１つ以上の終了状態にそれぞれ対応して、該終了状態の識別子、例外を含む状態の種類、終了時の動作を記述する式、画面遷移図の呼出元に対する１つ以上の返り値、該状態に対応するデータ入出力オブジェクトと入出力の順序をさらに定義可能であり、複数の画面遷移図間での呼出関係を含む終了状態の制御を可能とすることを特徴とする請求項１記載のユーザインタフェースアプリケーション開発プログラム。
6. 前記仕様書データが、前記画面遷移図上の開始状態に対応して、該状態に対応するデータ入出力オブジェクトと、入出力の順序をさらに定義可能であり、複数の画面遷移図間での呼出関係を含む開始状態の制御を可能とすることを特徴とする請求項１記載のユーザインタフェースアプリケーション開発プログラム。
7. 前記仕様書データが、複数の画面遷移図の間で同一名称のオブジェクトの複数のインスタンスが同一であるか否かを、該インスタンスに対するスコープの指定によりさらに区別可能とすることを特徴とする請求項１記載のユーザインタフェースアプリケーション開発プログラム。
8. 前記仕様書データが、前記画面遷移図内の分岐処理に対応して、該分岐の条件を示すパラメータ入力オブジェクトをさらに指定可能であることを特徴とする請求項１記載のユーザインタフェースアプリケーション開発プログラム。
9. 前記仕様書データが、分散オブジェクト型コンポーネントのプロトコルに基いて、分散オブジェクト型コンポーネントの呼出を可能にするデータをさらに含むことを特徴とする請求項１記載のユーザインタフェースアプリケーション開発プログラム。
10. ユーザインタフェースアプリケーションの開発装置において、
    画面と処理とが記述される形式の画面遷移図に相当する仕様書データであって、画面、および／または処理と入出力データとしてのオブジェクトとの間の関連付けを行うことが可能なアプリケーション開発用仕様書データを読み込む仕様書データ読込手段と、
    該読み込まれた仕様書データを、前記画面、および／または処理とオブジェクトの間の関連付けを含んで自動的に解釈し、ユーザインタフェースアプリケーションプログラムを生成するプログラム生成手段とを備えることを特徴とするユーザインタフェースアプリケーション開発装置。
    
    

Images