(57)【要約】利用者インタフェースの一般的な仕様のためのモデル化システム。システムは、あらゆる実施のコンテキストから独立している方法において、非常に複合的であると共に動的な利用者インターフェースを有する利用者インターフェースを定義するための手段を提供する。利用者インターフェースの一部の構造上の特徴、及び動作の特徴が徐々に詳述された明細書を通じて、利用者インターフェースの分かり易い視覚表示から、全ての使用のコンテキストにおける利用者インターフェースの正確な定義までを導くモデル化システムが達成される。モデルにおいて取得された情報を使用して十分に実用的な利用者インタフェースコードを自動的に生成するツールが構築され得る。
2006510133.tif 000002
【特許請求の範囲】
【請求項１】
クライアント−サーバ環境において使用するために構成される利用者インターフェースを生成する方法であって、
利用者インターフェースの視覚表示を設計するためのエディタを提供する処理を有し、
前記エディタが、クライアントシステム上の表示装置上に表示される作業領域、及びタスクパネルを提供し、
前記作業領域が、その上で前記視覚表示を設計するために提供され、
前記タスクパネルが、視覚表示を設計する際に使用するための複数のエレメントを提供し、
前記エレメントの１つ以上が、前記クライアントシステムから遠く隔たって設置されたサーバシステムと関連付けられると共に、
前記タスクパネルの中から第１のアクターを選択する処理と、
前記第１のアクターを前記作業領域に挿入する処理と、
前記タスクパネルから選択された第２のアクターを前記作業領域に挿入する処理と、
前記第１のアクターと前記第２のアクターとの間の関係を図式的に定義する処理と、
前記第１のアクターと、前記第２のアクターと、それらの関係とから実行可能コードを生成する処理とを有し、
前記第１のアクターが、前記エレメントの内の１つであると共に、前記サーバシステムにおいて提供されたアプリケーション階層にアクセスするために必要とされるアプリケーションロジックを有するデータソースオブジェクトである
ことを特徴とする利用者インターフェースを生成する方法。
【請求項２】
前記第１のアクターと、前記第２のアクターと、それらの関係との標準的表示を生成する処理を更に有し、
前記実行可能コードが、前記標準的表示から生成される
ことを特徴とする請求項１に記載の方法。
【請求項３】
生成された前記実行可能コードが、第１のプラットフォームに対応し、
前記標準的表示が、第２のプラットフォームに関する実行可能コードを生成するために使用される
ことを特徴とする請求項１、または請求項２に記載の方法。
【請求項４】
前記作業領域にオペレータを挿入する処理と、
前記第２のアクターと前記オペレータとの間の関係を図式的に定義する処理と更に有し、
前記オペレータが、特定の方法でデータを処理するように構成される
ことを特徴とする請求項１から請求項３のいずれかに記載の方法。
【請求項５】
前記第１のアクターの識別子を、前記エディタの現在のインスタンスと関連付けられた作業セッションに記憶する処理を更に有し、
前記第１のアクターの識別子が、前記第１のアクターに所定のタスクを実行させるために、前記サーバシステムに記憶される前記第１のアクターを実行時間の間に呼び出すために使用される
ことを特徴とする請求項１から請求項４のいずれかに記載の方法。
【請求項６】
前記エディタを起動するために前記サーバシステムにログオンする処理を更に有する
ことを特徴とする請求項１から請求項５のいずれかに記載の方法。
【請求項７】
生成された前記実行可能コードを前記サーバシステム内のリポジトリに記憶する処理を更に有する
ことを特徴とする請求項６に記載の方法。
【請求項８】
前記サーバシステムが、企業ポータルを有し、
前記企業ポータルが、アプリケーション階層に専念する１つ以上のサーバと、複数のクライアントシステムとのインターフェースに専念する１つ以上のウェブサーバとを有する
ことを特徴とする請求項６、または請求項７に記載の方法。
【請求項９】
モデル化システムを使用する利用者インターフェースを生成する方法であって、
サーバシステムから、前記利用者インターフェースの視覚表示を設計するためのエディタをクライアントシステムに提供する処理を有し、
前記エディタが、前記クライアントシステム上の表示装置上に表示される作業領域、及びタスクパネルを提供し、
前記作業領域が、その上で前記視覚表示を設計するために提供され、
前記タスクパネルが、前記視覚表示を設計する際に使用するための複数のエレメントを提供し、
前記エレメントの１つ以上が、前記クライアントシステムから遠く隔たって設置された前記サーバシステムと関連付けられると共に、
前記作業領域上で利用者によって選択されたシナリオを表示する処理を有し、
前記シナリオが、前記利用者インターフェースに関する利用者要求に対応すると共に、複数の交互配置されたシーンを有し、
更に、
前記利用者から受信した入力に従って複数のシーンの各々を定義する処理と、
前記シナリオ、及び前記シーンで描写されたモデルの標準的表示を生成する処理と、
前記標準的表示から実行ファイルを生成する処理とを有し、
各シーンが、同時にアクティブ状態であると共に協調しているアクターを有し、
前記アクターが、行動のスレッドを表す専門の計算ユニットであり、
各シーンが、そのシーンと関連付けられた前記アクターの間の関係を図式的に定義することによって定義される
ことを特徴とする利用者インターフェースを生成する方法。
【請求項１０】
分散形コンピュータシステムにおいて利用者インターフェースを生成する方法であって、
第１の利用者によって選択された第１のビジネス関数コンポーネントをフロントエンドシステムの第１の表示領域に表示する処理と、
前記第１の利用者によって選択された第２のビジネス関数コンポーネントをクライアントシステムの第１の表示領域に表示する処理と、
前記第１のビジネス関数コンポーネントと前記第２のビジネス関数コンポーネントとの間の関係を形成する処理とを有し、
前記第１のビジネス関数コンポーネントが、サーバシステムにおいて提供された第１のビジネスアプリケーションにアクセスするために、第１のアプリケーションロジックと関連付けられ、
前記第２のビジネス関数コンポーネントが、前記サーバシステムにおいて提供された第２のビジネスアプリケーションにアクセスするために、第２のアプリケーションロジックと関連付けられ、
前記利用者インターフェースの視覚表示が、前記表示する処理と前記形成する処理とに基づいて作成される
ことを特徴とする利用者インターフェースを生成する方法。
【請求項１１】
前記視覚表示の標準的表示を生成する処理と、
前記標準的表示から実行可能な利用者インターフェースコードを生成する処理とを更に有し、
前記利用者インターフェースコードが、所望のデータを検索するために、前記サーバシステムにおいて提供された第１のアプリケーション、及び第２のアプリケーションにアクセスするように動作可能である
ことを特徴とする請求項１０に記載の方法。
【請求項１２】
前記利用者インターフェースコードを前記サーバシステム内のリポジトリに記憶する処理を更に有し、
前記第１のビジネスアプリケーションと前記第２のビジネスアプリケーションとが、異なるアプリケーションである
ことを特徴とする請求項１１に記載の方法。
【請求項１３】
前記視覚表示が、プレゼンテーションフォーマットを指定する第３のビジネス関数コンポーネントを有し、
前記方法が、
前記利用者インタフェースコードを前記サーバシステムと関連付けられたリポジトリに記憶する処理と、
前記利用者インターフェースコードにアクセスする要請を第２の利用者から受信する処理とを更に有し、
前記利用者インタフェースコードが、前記要請に応えて実行され、
前記コードが、前記第２の利用者によって望まれたデータを検索するために、前記サーバシステムにおいて提供された第１のアプリケーション、及び第２のアプリケーションにアクセスするために使用され、
前記第２の利用者のために検索されたデータが、前記第３のビジネス関数コンポーネントによって指定されたプレゼンテーションフォーマットに基づいて前記クライアントシステムの第２の表示領域に表示され、
前記第１の表示領域、及び前記第２の表示領域が、異なるクライアントシステムに関連付けられている
ことを特徴とする請求項１１、または請求項１２に記載の方法。
【請求項１４】
第１のビジネス関数コンポーネントを表示する処理と連動して、前記クライアントシステム内の第１のビジネス関数コンポーネントに関する第１の識別子を記憶する処理と、
第２のビジネス関数コンポーネントを表示する処理と連動して、前記クライアントシステム内の第２のビジネス関数コンポーネントに関する第２の識別子を記憶する処理とを更に有し、
前記第１の識別子、及び前記第２の識別子が、それぞれ、第１のアプリケーションロジック、及び第２のアプリケーションロジックにアクセスするために、実行時間において続いて使用される
ことを特徴とする請求項１０から請求項１３のいずれかに記載の方法。
【請求項１５】
前記視覚表示の標準的表示を生成する処理と、
前記標準的表示から実行可能な第１の利用者インターフェースコードを生成する処理とを更に有し、
前記第１の利用者インターフェースコードが、所望のデータを検索するために、前記サーバシステムにおいて提供された第１のアプリケーション、及び第２のアプリケーションにアクセスするように動作可能であり、
前記第１の識別子、及び前記第２の識別子が、前記標準的表示に書き込まれる
ことを特徴とする請求項１４に記載の方法。
【請求項１６】
前記標準的表示が、ＸＭＬをベースにした言語に基づいており、
前記第１のアプリケーション、及び前記第２のアプリケーションが、同じアプリケーションであっても良いし、または異なるアプリケーションであっても良い
ことを特徴とする請求項１５に記載の方法。
【請求項１７】
前記標準的表示から実行可能な第２の利用者インターフェースコードを生成する処理を更に有し、
前記第２の利用者インターフェースコードが、所望のデータを検索するために、前記サーバシステムにおいて提供された第１のアプリケーション、及び第２のアプリケーションにアクセスするように動作可能であり、
前記第１のコードが、第１のプラットフォームに対応すると共に、前記第２のコードが、前記第１のプラットフォームと異なる第２のプラットフォームに対応する
ことを特徴とする請求項１５、または請求項１６に記載の方法。
【請求項１８】
前記オペレータを前記第２のビジネス関数コンポーネントに関連付ける処理と、
前記第２のビジネス関数コンポーネントの出力ポートを前記オペレータの入力ポートと接続する処理とを更に有する
ことを特徴とする請求項１０から請求項１７のいずれかに記載の方法。
【請求項１９】
前記視覚表示の標準的表示を生成する処理と、
前記標準的表示から実行可能な利用者インターフェースコードを生成する処理とを更に有し、
前記第１の利用者インターフェースコードが、所望のデータを検索するために、前記サーバシステムにおいて提供された第１のアプリケーション、及び第２のアプリケーションにアクセスするように動作可能であり、
生成されたコードが、検証を必要としない
ことを特徴とする請求項１８に記載の方法。
【請求項２０】
生成されたコードが、性能のチューニングを必要としない
ことを特徴とする請求項１９に記載の方法。
【請求項２１】
前記オペレータは、データが第２のビジネス関数コンポーネントと関連付けられた第２のアプリケーションロジックと一致している状態を維持するように、第２のビジネス関数コンポーネントから受信されたデータを処理する
ことを特徴とする請求項１９、または請求項２０に記載の方法。
【請求項２２】
第１のビジネス関数コンポーネント、及び第２のビジネス関数コンポーネントが、再利用可能なアプリケーションコンポーネントである
ことを特徴とする請求項１０から請求項２１のいずれかに記載の方法。
【請求項２３】
前記再利用可能なアプリケーションコンポーネントが、ビジネスアプリケーションプログラムインタフェース（ＢＡＰＩ）、及びリモートファンクションコール（ＲＦＣ）を有する
ことを特徴とする請求項２２に記載の方法。
【請求項２４】
分散型コンピュータシステムであって、
第１の利用者によって選択された第１のビジネス関数コンポーネントをクライアントシステムの第１の表示領域に表示するための手段と、
前記第１の利用者によって選択された第２のビジネス関数コンポーネントを前記クライアントシステムの第１の表示領域に表示するための手段と、
前記第１のビジネス関数コンポーネントと前記第２のビジネス関数コンポーネントとの間の関係を形成するための手段とを備え、
前記第１のビジネス関数コンポーネントが、サーバシステムにおいて提供された第１のビジネスアプリケーションにアクセスするために、第１のアプリケーションロジックと関連付けられ、
前記第２のビジネス関数コンポーネントが、前記サーバシステムにおいて提供された第２のビジネスアプリケーションにアクセスするために、第２のアプリケーションロジックと関連付けられ、
利用者インターフェースの視覚表示が、表示する処理と形成する処理とに基づいて作成される
ことを特徴とするコンピュータシステム。
【請求項２５】
前記視覚表示の標準的表示を生成するための手段と、
前記標準的表示から実行可能な利用者インターフェースコードを生成するための手段とを更に備え、
前記利用者インターフェースコードが、所望のデータを検索するために、前記サーバシステムにおいて提供された第１のアプリケーション、及び第２のアプリケーションにアクセスするように動作可能である
ことを特徴とする請求項２４に記載のシステム。
【請求項２６】
前記利用者インタフェースコードを前記サーバシステム内のリポジトリに記憶するための手段を更に備える
ことを特徴とする請求項２５に記載のシステム。
【請求項２７】
前記視覚表示が、プレゼンテーションフォーマットを指定する第３のビジネス関数コンポーネントを有し、
前記システムが、
前記利用者インタフェースコードを前記サーバシステムと関連付けられたリポジトリに記憶するための手段と、
前記利用者インターフェースコードにアクセスする要請を第２の利用者から受信するための手段とを更に備え、
前記利用者インタフェースコードが、前記要請に応えて実行され、
前記コードが、前記第２の利用者によって望まれたデータを検索するために、前記サーバシステムにおいて提供された第１のアプリケーション、及び第２のアプリケーションにアクセスするために使用され、
前記第２の利用者のために検索されたデータが、前記第３のビジネス関数コンポーネントによって指定されたプレゼンテーションフォーマットに基づいて前記クライアントシステムの第２の表示領域に表示され、
前記第１の表示領域、及び前記第２の表示領域が、異なるクライアントシステムに関連付けられている
ことを特徴とする請求項２４から請求項２６のいずれかに記載のシステム。
【請求項２８】
コンピュータプログラムを有するコンピュータ読み取り可能な記録媒体であって、
前記コンピュータプログラムが、
第１の利用者によって選択された第１のビジネス関数コンポーネントをクライアントシステムの第１の表示領域に表示するためのコードと、
前記第１の利用者によって選択された第２のビジネス関数コンポーネントを前記クライアントシステムの第１の表示領域に表示するためのコードと、
前記第１のビジネス関数コンポーネントと前記第２のビジネス関数コンポーネントとの間の関係を形成するためのコードとを備え、
前記第１のビジネス関数コンポーネントが、サーバシステムにおいて提供された第１のビジネスアプリケーションにアクセスするために、第１のアプリケーションロジックと関連付けられ、
前記第２のビジネス関数コンポーネントが、前記サーバシステムにおいて提供された第２のビジネスアプリケーションにアクセスするために、第２のアプリケーションロジックと関連付けられ、
前記利用者インターフェースの視覚表示が、表示する処理と形成する処理とに基づいて作成される
ことを特徴とするコンピュータ読み取り可能な記録媒体。
【請求項２９】
前記視覚表示の標準的表示を生成するためのコードと、
前記標準的表示から実行可能な利用者インターフェースコードを生成するためのコードとを更に備え、
前記利用者インターフェースコードが、所望のデータを検索するために、前記サーバシステムにおいて提供された第１のアプリケーション、及び第２のアプリケーションにアクセスするように動作可能である
ことを特徴とする請求項２８に記載のコンピュータ読み取り可能な記録媒体。
【請求項３０】
クライアントシステムに接続されたサーバシステム上で提供されたアプリケーションと、
コンピュータ読み取り可能な記録媒体とを備えると共に、
前記コンピュータ読み取り可能な記録媒体が、
第１の利用者によって選択された第１のビジネス関数コンポーネントを前記クライアントシステムの第１の表示領域に表示するためのコードと、
前記第１の利用者によって選択された第２のビジネス関数コンポーネントを前記クライアントシステムの第１の表示領域に表示するためのコードと、
前記第１のビジネス関数コンポーネントと前記第２のビジネス関数コンポーネントとの間の関係を形成するためのコードとを備え、
前記第１のビジネス関数コンポーネントが、前記サーバシステムにおいて提供された１つ以上のビジネスアプリケーションにアクセスするために、第１のアプリケーションロジックと関連付けられ、
前記第２のビジネス関数コンポーネントが、前記サーバシステムにおいて提供された１つ以上のビジネスアプリケーションにアクセスするために、第２のアプリケーションロジックと関連付けられ、
前記利用者インターフェースの視覚表示が、表示する処理と形成する処理とに基づいて作成される
ことを特徴とするコンピュータシステム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、人間とコンピュータとの対話の分野に関すると共に、特に利用者インターフェースのモデル化に関するものである。
【背景技術】
【０００２】
本願は、その両方が参照されることによりここに組み込まれている、２００２年１１月１４日に出願された米国の仮特許出願60/426,097号と、２００３年６月１６日に出願された米国の仮特許出願60/479,017号とに対する優先権を主張する。
【０００３】
利用者インターフェースの構築、及び保守は、大きな複合的システムに関する中心的問題になっている。利用者インターフェースは、アプリケーションと利用者との間の橋渡しをするものであると共に、その結果、双方の複雑さに対処しなければならない。新しい技術と、利用者中心の問題との出現によって、対話型システムの利用者インターフェース部分は、ますます大きく、高価になっている。
【０００４】
更に速く、かつ更に有能な設備及びネットワークは、更に多くの機能性、及び更に多くの情報を利用者に提供しているが、しかし、それと同時に彼らを更に多くの命令、及びオプションによって苦しめている。利用者インターフェースは、利用者がそれらのタスクを実行するのを支援するために更に知的になる必要があると共に、学習するために更に簡単でかつ更に直観的である必要があり、そして、利用者によるカスタマイズが特定の利用者のニーズ、及び好みに合わせて調整され得ることを可能にする必要がある。
【０００５】
装置の広い範囲を横断して段階的に進むアプリケーションは、利用者に、ワークステーションの機能性の同じバージョン、または縮小バージョンを提供する必要がある。スピーチ、自然言語、及び手書き文字認識のような新しい様式は、成熟していると共に、利用者インターフェースに組み込まれる必要があるかもしれない。直接的操作、または動的な照会のような現代の対話技術は、利用者インターフェースにおける並列処理の高い度合いを必要とする。
【０００６】
全てのこれらの要因、及びその他は、利用者インターフェースを設計すると共に実行することを難しくする。従って、多くの概論は、ソフトウェアシステムの利用者インターフェース部分が、システムの開発努力全体の重要な部分を占めることを示す。例えば、プロジェクト、プラットフォーム、及び開発ツールの広い範囲で導かれた１つの概論は、利用者インターフェースに充てられるコードの評価と設計時間、実装時間、及び保守時間のパーセンテージは、典型的なソフトウェアプロジェクトにおいて約３０［％］から５０［％］であると報告する。
【０００７】
利用者インターフェースの開発の絶えず増加している問題を扱うことは、プログラミングに基づかない新しいアプローチの１つを必要とする。プログラミングなしで利用者インターフェースを指定するために、代数的仕様（algebraic specification）、文法をベースにした言語（grammar-based languages）、遷移図、法則をベースにしたシステム（rule-based systems）、及び実証による仕様（specification by demonstration）を含む異なる方法が過去に提案された。
【発明の開示】
【発明が解決しようとする課題】
【０００８】
しかしながら、これらの方法のうちのいずれもが広く採用されなかった。それらが理解しにくいと共に、十分に表現しておらず、そして通常は実行可能ではなく、従って不必要な追加の仕事と見なされるので、開発機関は形式仕様に抵抗する。その結果、利用者インターフェースの開発のための一般的な方法は、まだ主としてプログラミングに基づいている。
【課題を解決するための手段】
【０００９】
本発明は、手によるコーディングなしで利用者インターフェース（ＵＩ）を作成するためのモデル化システム、または視覚化ツールに関連している。モデル化システムは、一般的であると共に、宣言的な利用者インターフェースの仕様のためのものである。システムは、実施のコンテキストから独立している方法において、非常に複合的であると共に動的な利用者インターフェースを有する利用者インターフェースを定義するための手段を提供する。
【００１０】
本発明の実施例は、利用者インターフェースの設計が、容易に読まれると共に伝達され得るように、理解できる言葉で利用者インターフェースをモデル化するためのシステムに関連している。そのようなシステムは、好ましくは、適宜複合的であると共に動的な利用者インターフェースのモデル化を可能にするのに十分なように表現されるべきである。更に好ましくは、システムは、困難であると共にエラーを起こしやすいプログラミング処理が省略され得るように、利用者インターフェースモデルの実行可能コードへの自動翻訳を可能にするべきである。
【００１１】
一実施例において、モデル化システムは、以下の３つの原理を実現する。(i)人間によって理解されると共に設計されるように十分に簡単であること、(ii)情報処理アプリケーションの利用者インターフェースを広く多岐にわたって説明するのに十分なように表現されること、及び(iii)計算に基づいて細工しやすいこと、すなわち、実行可能な利用者インターフェースコードは、解釈、編集、または翻訳のいずれかによってそれから生成され得ること。
【００１２】
システム、もしくは視覚化ツールは、設計者が視覚的にＵＩモデルを作成することを可能にすると共に、その場合に、動作する利用者インターフェースを生成する、すなわち、視覚表示を実行可能コードに変換するコンピュータプログラムである。システムは、その中心において、（設計時間と、実行時間の両方に対する）モデル化エレメントの様々な一面を描写すると共に実行するオブジェクト指向のクラスの動的な収集物を有する。これらのクラスは、広げることができ、システムが拡張されると共に、ビジネスワークフロー（Business Workflow）、データベース図表（database schemas）等のような非ＵＩモデル化アプリケーションに等しい、広く多岐に渡るモデル化方法に適応されることを可能にしている。
【００１３】
本モデル化システムの一実施例は、“GUIMachine”モデル化システム（“GUIMachine ストーリーボード（Storyboard）”、または“GM ストーリーボード”、“GMモデル化システム”、または“ストーリーボード”とも言われる）であり、それは、利用者インターフェースの創造ための枠組である。
【００１４】
ＧＭモデル化システムは、異なるＵＩ装置及びレンダリング技術の特性における差異を要因の１つとして含めるモデルエレメント及び関連する規則のキット、コネクタ、またはライブラリの使用を通じて、異なる利用者インターフェース（ＵＩ）の種類に適合する。複数のＵＩ技術（“SAP EP5”及び“SAP EP6”、“HTMLB”、“WebDynPro”、“Net”等）に適合する１つの一般的なキットが本実施例に使用される。これは、設計者が、モデルそのものを調整せずにこれらの様々な技術に翻訳する１つのモデルを構築することのみを必要とするように、これらのＵＩ技術の全てに対して１つのモデルの使用を可能にする。
【００１５】
ＧＭモデル化システムにおいて、利用者インターフェースモデル、もしくはＧＭモデルは、設計推敲処理を通じて、利用者とアプリケーションの要求から生成される。利用者インターフェースのコンテキストの各々に関して、ＵＩの視覚表示である利用者インターフェースモデルは、コード生成処理を通じて利用者インターフェースコードに変換される。
【００１６】
本実施例において、課題解決プログラム、または“iView”を生成する方法は、パッケージを選択すると共に、選択されたパッケージと関連付けられたページを選択する処理を有する。選択されたページは、それに関連付けられた複数の“iView”を有している。第１のビジネス関数コンポーネントが選択される。第１のオペレータ（operator）が選択される。別の“iView”を生成するために、第１のビジネス関数コンポーネントの出力ポートは、第１のオペレータの入力ポートに接続される。第１のビジネス関数コンポーネントは、データを処理するかもしくは操作する第１のオペレータにデータを提供する。
【００１７】
方法は、同様に、第１のオペレータの出力ポートを第２のビジネス関数コンポーネントの入力ポートに接続する処理を有する。第２のビジネス関数コンポーネントの出力ポートは、第３のビジネス関数コンポーネントに接続される。一方、第１のオペレータの出力ポートは、第２のオペレータの入力ポートに接続されることができる。
【００１８】
一度、所望のビジネス関数コンポーネント、及びオペレータがある構成において選択されると共に配置されたならば、視覚化ツールは、問題解決プログラム、または“iView”に関するコードを生成する。一方、コードを生成するために個別のコンパイラが使用されることができる。生成されたコードは検証を必要としない。生成されたコードは性能のチューニングを必要としない。
【００１９】
別の実施例において、視覚化ツールを使用するプログラムを生成する方法は、ビジネス階層と関連付けられた再利用可能なアプリケーションコンポーネントを選択する処理を有する。ビジネス階層は、１つ以上のデータベースと関連付けられている。与えられた方法でデータを処理するように構成されたオペレータが選択される。再利用可能なアプリケーションコンポーネントは、オペレータと連結される。ポータルコンテンツ（portal content）コンポーネントは、再利用可能なアプリケーションコンポーネントとオペレータとの間の関係に従って生成される。再利用可能なアプリケーションコンポーネントは、ビジネスアプリケーションプログラムインターフェース（business application program interface：ＢＡＰＩ）、またはリモートファンクションコール（remote function call：ＲＦＣ）である。ポータルコンテンツコンポーネントは、“iView”である。
【００２０】
別の実施例において、利用者インターフェースを生成する方法が記述される。利用者インターフェースは、クライアント−サーバ環境において使用するために構成される。方法は、利用者インターフェースの視覚表示を設計するためのエディタを提供する処理を有し、エディタは、作業領域、及びフロントエンドシステム上の表示装置上で表示されるためのタスクパネルを提供し、作業領域は、その上で視覚表示を設計するために提供され、タスクパネルは、視覚表示を設計する際に使用するための複数のエレメントを提供し、エレメントの１つ以上は、フロントエンドシステムから遠く隔たって設置されたバックエンドシステムと接続される。第１のアクター（actor）がタスクパネルの中から選択され、第１のアクターは、エレメントのうちの１つであると共に、バックエンドシステムにおいて提供されるアプリケーション階層にアクセスするのに必要とされるアプリケーションロジックを有するデータソースオブジェクト（data source object）である。第１のアクターは、作業領域に挿入される。タスクパネルの中から選択された第２のアクターは、作業領域に挿入される。第１のアクターと第２のアクターとの間の関係は図式的に定義される。実行可能コードは、第１のアクターと、第２のアクターと、それらの関係とから生成される。
【００２１】
別の実施例において、モデル化システムを使用する利用者インターフェースを生成する方法は、利用者インターフェースの視覚表示を設計するためのエディタを提供する処理を有し、エディタは、作業領域、及びフロントエンドシステム上の表示装置上で表示されるためのタスクパネルを提供し、作業領域は、その上で視覚表示を設計するために提供され、タスクパネルは、視覚表示を設計する際に使用するための複数のエレメントを提供し、エレメントの１つ以上は、フロントエンドシステムから遠く隔たって設置されたバックエンドシステムと接続されると共に、作業領域上で利用者によって選択されたシナリオを表示する処理を有し、シナリオが、利用者インターフェースに関する利用者要求に対応すると共に、複数の交互配置されたシーンを有し、更に、利用者から受信した入力に従って複数のシーンの各々を定義する処理と、シナリオ、及びシーンで描写されたモデルの標準的表示を生成する処理と、標準的表示から実行ファイルを生成する処理とを有し、各シーンが、同時にアクティブ状態であると共に協調しているアクターを有し、アクターが、行動のスレッドを表す専門の計算ユニットであり、各シーンが、そのシーンと関連付けられたアクターの間の関係を図式的に定義することによって定義される。
【００２２】
別の実施例において、分散形コンピュータシステムにおいて利用者インターフェースを生成する方法は、第１の利用者によって選択された第１のビジネス関数コンポーネントをフロントエンドシステムの第１の表示領域に表示する処理と、第１の利用者によって選択された第２のビジネス関数コンポーネントをフロントエンドシステムの第１の表示領域に表示する処理と、第１のビジネス関数コンポーネントと第２のビジネス関数コンポーネントとの間の関係を形成する処理とを有し、第１のビジネス関数コンポーネントが、バックエンドシステムにおいて提供された第１のビジネスアプリケーションにアクセスするために、第１のアプリケーションロジックと関連付けられ、第２のビジネス関数コンポーネントが、バックエンドシステムにおいて提供された第２のビジネスアプリケーションにアクセスするために、第２のアプリケーションロジックと関連付けられ、利用者インターフェースの視覚表示が、表示する処理と形成する処理とに基づいて作成される。
【００２３】
別の実施例において、分散形コンピュータシステムは、第１の利用者によって選択された第１のビジネス関数コンポーネントをフロントエンドシステムの第１の表示領域に表示するための手段と、第１の利用者によって選択された第２のビジネス関数コンポーネントをフロントエンドシステムの第１の表示領域に表示するための手段と、第１のビジネス関数コンポーネントと第２のビジネス関数コンポーネントとの間の関係を形成するための手段とを備え、第１のビジネス関数コンポーネントが、バックエンドシステムにおいて提供された第１のビジネスアプリケーションにアクセスするために、第１のアプリケーションロジックと関連付けられ、第２のビジネス関数コンポーネントが、バックエンドシステムにおいて提供された第２のビジネスアプリケーションにアクセスするために、第２のアプリケーションロジックと関連付けられ、利用者インターフェースの視覚表示が、表示する処理と形成する処理とに基づいて作成される。
【００２４】
更にもう一つの実施例において、コンピュータ読み取り可能な媒体は、コンピュータプログラムを有する。コンピュータプログラムは、第１の利用者によって選択された第１のビジネス関数コンポーネントをフロントエンドシステムの第１の表示領域に表示するためのコードと、第１の利用者によって選択された第２のビジネス関数コンポーネントをフロントエンドシステムの第１の表示領域に表示するためのコードと、第１のビジネス関数コンポーネントと第２のビジネス関数コンポーネントとの間の関係を形成するためのコードとを備え、第１のビジネス関数コンポーネントが、バックエンドシステムにおいて提供された第１のビジネスアプリケーションにアクセスするために、第１のアプリケーションロジックと関連付けられ、第２のビジネス関数コンポーネントが、バックエンドシステムにおいて提供された第２のビジネスアプリケーションにアクセスするために、第２のアプリケーションロジックと関連付けられ、利用者インターフェースの視覚表示は、表示する処理と形成する処理とに基づいて作成される。
【００２５】
更にもう一つの実施例において、コンピュータシステムは、フロントエンドシステムに接続されたバックエンドシステム上で提供されたアプリケーションと、コンピュータ読み取り可能な媒体とを有する。コンピュータ読み取り可能な媒体は、第１の利用者によって選択された第１のビジネス関数コンポーネントをフロントエンドシステムの第１の表示領域に表示するためのコードと、第１の利用者によって選択された第２のビジネス関数コンポーネントをフロントエンドシステムの第１の表示領域に表示するためのコードと、第１のビジネス関数コンポーネントと第２のビジネス関数コンポーネントとの間の関係を形成するためのコードとを備え、第１のビジネス関数コンポーネントが、バックエンドシステムにおいて提供された１つ以上のビジネスアプリケーションにアクセスするために、第１のアプリケーションロジックと関連付けられ、第２のビジネス関数コンポーネントが、バックエンドシステムにおいて提供された１つ以上のビジネスアプリケーションにアクセスするために、第２のアプリケーションロジックと関連付けられ、利用者インターフェースの視覚表示が、表示する処理と形成する処理とに基づいて作成される。
【発明の効果】
【００２６】
ここで説明された利用者インターフェースモデル化システムは、多数の利益を提供する。システムは、利用者インターフェースの全ての異なる特徴が、純粋にモデル化言語の宣言的用語で表され得るように、宣言的に閉じられる。システムは、人間によって読まれると共に伝達されるのに十分に簡単な表示を提供する。システムは、計算に基づいて細工しやすく、従って、自動化された妥当性検査、シミュレーション、及び有効なモデルからの実用的な利用者インターフェースの生成を可能にする。システムは、有用性を維持する一方で使用のコンテキストにおける変化に耐える、順応性に富む利用者インターフェースモデルを宣言することに対する能力を備えている。システムは、更新性を奨励すると共に、少しの特別な開発戦略も実施しない。システムは、使用のコンテキストにおける、及び使用のコンテキストを横断する両方の強い並列構造を可能にする。システムは、その表示のために認識をベースにした記憶機構の機能を有効にする。システムは、それが描写する利用者インターフェースモデルの様々な特徴に対する拡張を可能にする。
【発明を実施するための最良の形態】
【００２７】
本発明に基づいたシステム、及び方法の原理、及び動作は、図、及び次の記述によって更によく理解されることができ、これらの図が実例となる目的でのみ与えられ、制限することを意味しないということが理解される。
【００２８】
本発明は、コードを書かずに利用者インターフェース（ＵＩ）を作成するためのモデル化システム、または視覚化ツールに関連している。システムは、あらゆる実施のコンテキストから独立している方法において、非常に複合的であると共に動的な利用者インターフェースを有する利用者インターフェースを定義するための手段を提供する。発明の好ましい実施例において、利用者インターフェースの一部の構造上の特徴、及び動作の特徴が徐々に詳述された明細書を通じて、利用者インターフェースの分かり易い視覚表示から、使用のコンテキストにおける利用者インターフェースの正確な定義までを導くモデル化システムが達成される。設計者によって作成されたＵＩの視覚表示を用いて、モデル化システムは、十分に実用的な利用者インターフェースコードを自動的に生成する。
【００２９】
図１は、クライアント−サーバ環境における対話型コンピュータシステムの一般化された図を説明する。対話型コンピュータシステム（サーバ）１００は、アプリケーションを一人以上の利用者（クライアント）に提供すると共に、一般的にバックエンドサブシステム１１０、及びフロントエンドサブシステム１２０に分割され得る。
【００３０】
バックエンドシステム１１０は、アプリケーションを主催すると共に、あらゆる数の記憶装置のハードウェア、ネットワーキング（networking）のハードウェア、及びサーバのハードウェアと同様に、アプリケーションソフトウェア１１１を有する。アプリケーションソフトウェアは、アプリケーションデータを記憶し、検索し、処理し、そして伝達するためのバックエンドシステムを制御するプログラムコードである。アプリケーションソフトウェアは、同様に中央処理装置上で実行されるか、またはあらゆる数の様々な構造の処理装置に分散され得る。アプリケーションソフトウェアは、同様に、中間の階層、またはビジネスロジック階層（business logic layer：ＢＬ）として当該技術において知られている。アプリケーションに関するデータは、データベース階層と関連付けられている。従って、バックエンドシステム１１０は、アプリケーション階層と、データベース階層の両方を有する。
【００３１】
フロントエンドシステム１２０は、システムの利用者と、バックエンドシステム上で動作するアプリケーションとの間の対話に関与する対話型コンピュータシステムの一部分である。フロントエンドシステムは、利用者インターフェースソフトウェア１２１、及びあらゆる数の入出力装置を有する。利用者インターフェースソフトウェアは、入力を分析すると共に解釈し、出力を設計すると共に提供し、そして利用者とアプリケーションソフトウェアとの間の対話を管理する。利用者インターフェースは、同様にマンマシンインターフェース（man-machine interface：ＭＭＩ）、ヒューマンコンピュータインターフェース（human-computer interface：ＨＣＬ）、またはプレゼンテーション階層（presentation layer：ＰＬ）として当該技術において知られている。簡単な１つの装置、１つのスレッド、１つの利用者インターフェースから、複雑な複数の様式、複数の装置、複数のスレッド、及びマルチユーザ（複数利用者）の利用者インターフェースまで、利用者インターフェースの広い範囲が当該技術において明らかにされる。
【００３２】
フロントエンドシステムは、それぞれ利用者の種類、入出力装置、及び利用者インターフェース技術の異なる組み合わせである、あらゆる数の利用者インターフェースのコンテキストを有することができる。例示を目的として、図１は、３つの典型的な利用者インターフェースのコンテキスト１２２ａ，１２２ｂ，１２２ｃを示す。利用者インターフェースのコンテキスト１２２は、利用者パラメータ（要求、目標、及び好み）、ハードウェアパラメータ（画面サイズ、メモリサイズ、ネットワーク帯域幅、入力装置）、ソフトウェアパラメータ（グラフィックスエンジン、プログラミング言語）、及び環境上のパラメータ（周囲のノイズ、照明条件、利用者の位置）に関して定義される。
【００３３】
一般的に、利用者インターフェースを開発することは、多数の考察事項を必要とする。その利用者がＵＩを用いて何をしたいかを知るための１つのニーズは、利用者が遂行することを望む可能性がある異なるタスクを定義すると共に、バックエンドシステム、及びフロントエンドシステムで処理されるべき異なるデータフォーマットを考慮する。
【００３４】
従って、利用者インターフェースソフトウェアの特別な実装例は、利用者インターフェースが使用されるコンテキストによって変わる。従って、異なる利用者インターフェースのコンテキストは、潜在的に異なるプログラミング言語で書かれ、異なるソフトウェアライブラリを使用し、そして、異なる利用者の目標及び要求のため、及び異なる装置制限のために作成される、利用者インターフェースソフトウェアの異なる種類に帰着する。これらの利用者インターフェースの種類は、アプリケーションコントラクト（application contract）１３０に従って情報を前後に通過させることによって、最終的にバックエンドシステム上の同じアプリケーションコードと通信する。これらの複雑さのために、複数のプラットフォームに対応する、またはビジネスロジックを組み込む、またはそのいずれでもある一般的なＵＩソフトウェアを作成することが可能である視覚化ツールを提供することは難しかった。
【００３５】
その結果、ＵＩソフトウェアは、主に、遅く、かつ困難であると共に、エラーを起こしやすい処理であるプログラミングに基づいている。更に、利用者インターフェースロジックがコードへ埋められるので、時を超えてそれを発展させると共に維持することは難しい。その上更に、利用者インターフェースの各種類は、多くの場合非常に少ないコードの再使用によって別々にコード化されなければならないので、利用者インターフェースの開発、及び保守は、バージョニング（versioning）、物流管理、及び一貫性の不安のために更に難しくなる。
【００３６】
図２は、本発明の一実施例による、プログラミングよりむしろモデル化に基づいた利用者インターフェースの開発のためにモデル化システムを説明する。利用者インターフェースの開発プロセスからプログラミングの必要性を消去することによって、本実施例は、同様にプログラミングと関連付けられた大部分の問題を消去すると共に、従って、利用者インターフェースの開発、及び保守のための費用効果が高い手段を提供する。
【００３７】
利用者インターフェースモデル２２０は、与えられたアプリケーションに関する利用者インターフェースの宣言的な仕様である。ＵＩモデル２２０は、設計者によって設計されたＵＩの視覚表示である。本実施例において、利用者インターフェースモデルは、ハードウェア装置、演算プラットフォーム、プログラミング言語、アプリケーションプロトコル、集団のスタイルガイド（company style guides）等のような、あらゆる実施にかかわる懸案事項とは無関係である。
【００３８】
利用者インターフェースモデルは、設計推敲処理２１１を通じて、利用者とアプリケーションの要求２１０から生成される。すなわち、ＵＩソフトウェアの視覚表示は、利用者とアプリケーションの要求を用いて作成される。利用者インターフェースモデルは、利用者インターフェースのコンテキスト２３１ａ、利用者インターフェースのコンテキスト２３１ｂ、及び利用者インターフェースのコンテキスト２３１ｃのそれぞれについて、コード生成処理２２１ａ、コード生成処理２２１ｂ、及びコード生成処理２２１ｃを通じて、利用者インターフェースコード２３０ａ、利用者インターフェースコード２３０ｂ、及び利用者インターフェースコード２３０ｃに変換される。従って、１つのモデル、または視覚表示は、異なるコンテキスト（例えば、ＰＣのコンテキスト、ＰＤＡのコンテキスト、及びテレビのコンテキスト）に対する、複数の異なる利用者インターフェースを作成するために使用される。
【００３９】
利用者インターフェースモデル、及びそれに起因するコードは、設計検証処理２１２によってオリジナルの要求と対照して比較される。要求に対する変更は、即座に利用者インターフェースコードに伝えられる、利用者インターフェースモデルに対する変更によって迅速に反映され得る。
【００４０】
特別な利用者インターフェースのコンテキストに関して、もしそれが全詳細におけるコンテキストの下で利用者インターフェースの異なる特徴の全てを捕える場合、利用者インターフェースモデルは、包括的である。利用者インターフェースモデルは、もしそれがアプリケーションによって要求された全ての異なる利用者インターフェースのコンテキストの定義を捕らえる場合、網羅的である。利用者インターフェースモデルは、もし各々及び全ての利用者インターフェースのコンテキストに関して網羅的であると共に包括的である場合、あらゆるものを包括する。
【００４１】
利用者インターフェースモデルは、もし、実際に動作する利用者インターフェースコードの生成を可能にする十分に詳述された情報をそれが捕らえる場合、実行可能である。利用者インターフェースモデルは、実行可能であるために、包括的であること及び網羅的であることのどちらも必要としない。詳細な情報が利用者インターフェースモデルから不足している場所において、適切なデフォルトの動作は、たとえ不完全でも動作する利用者インターフェースコードがまだ生成され得るように、コード生成処理によって仮定され得る。
【００４２】
本実施例において、モデル化システムは、ＵＩの視覚表示を作成するための複数の基本構成要素、及びコネクタと共に提供される。これらの構成要素、例えばビジネス関数は、選択されると共にお互いに結合される。情報の不足している一部分は、モデル化の処理を単純化するために、モデル化システムによって供給される。他の場合は、システム及び処理は全く複雑であると共に、手によるプログラミングに対する有意の利点を提供しない可能性がある。
【００４３】
例えば、１つのラインが２つのインタアクター（interactor）（例えば、患者の参照テーブルの一覧、及び患者の詳細な書類の一覧）を接続しているかが描かれる。このラインは、インタアクターの間のデータのバインディング（binding）を意味し、すなわち、それらは、両方とも同じデータセットの同期された一覧である。これらのインタアクターの内の１つに生じるあらゆる変更は、全ての可能な異なる対話を明白に明示しなくても、他方において即座に反映される。従って、患者の参照テーブルの一覧において新しい記録が選択されるときはいつでも、それは、患者の詳細な書類の一覧において即座に表示され、フィールドが書類の一覧において編集されるときはいつでも、テーブルの一覧における対応するセルは、新しい値で補充され、新しい行がテーブルの一覧に加えられるときはいつでも、書類の一覧は、対応すると共に新しい、そして空の書類を表示し、新しい照会が行われるときはいつでも、患者の新しいデータセットに帰着することにより、双方の一覧が従って更新される。２つの一覧の間の協調のこれらの動作の特徴が、それらの間のバインディングと関連付けられたプロトコルから暗示されるので、それらは、明白に提示されないと共に、その結果モデルをかなり簡素化する。
【００４４】
従って、本実施例によって採用された提案は、ＵＩモデルの厳しい定義が取得されるまで、テストされると共に次第に精製される仮の利用者インターフェースモデルを初めに作ることを必要とする。その結果生じる完成されたＵＩモデルは、好ましくはあらゆるものを包括する利用者インターフェースモデルである。これは、利用者ニーズに最もよくマッチする品質の利用者インターフェースに究極的に帰着する、迅速でかつ反復の利用者中心の（user-centered）設計処理を可能にする。もちろん、更にシンプルなＵＩモデルは、反復処理なしに、１度で取得されることができる。
【００４５】
図３Ａは、本発明の一実施例による利用者インターフェースモデル化システム（user interface modeling system：ＵＩＭＳ）３００を説明する。利用者インターフェースモデル３１０の分かり易い視覚表示が最初に作成される。利用者インターフェースモデルの機械読取可能な標準的表示（machine-readable canonic representation）３２０は、視覚表示から生成される。標準的表示は、利用者インターフェースコード３３０、すなわち実行可能コードに変換される。本実施例において、１つのＵＩモデル、または視覚表示３１０は、その場合に複数の異なるコンテキスト、またはプラットフォームのためのＵＩコードに変換されることができる１つの標準的表示に変換される。
【００４６】
一方、図３Ｂにおいて説明されたように、１つの標準的表示３５０は、複数の視覚表示３５２及び視覚表示３５４からか、または外部の遺産的情報源（legacy sources）３５６から生成されることができる。１つの標準的表示は、その場合に、複数の利用者インターフェースコード３５８、利用者インターフェースコード３６０、そして利用者インターフェースコード３６２、及び他の入力３６４（例えば、フォーマットされた文書）を生成するために使用される。ある場合において、視覚表示は、複数の利用者インターフェースコードを生成する前に、複数の標準的表示に変換されることができる。
【００４７】
視覚表示は、利用者インターフェースモデルの様々な特徴を設計するための、及び他の開発チームとモデル設計図を交信するための分かり易い手段を、簡単で、かつ直観的な図の形で提供する。視覚表示は、ＵＩが実行するべきである機能を指定する図面である。詳細な仕様書は、利用者インターフェースの一部分の構造上の特徴、及び動作の特徴の正確な定義を提供するために、視覚図面に取り付けられることができる。
【００４８】
本実施例において、視覚表示３１０は、（“ストーリーブックツール（Storybook tool）”、または“ストーリーボード”とも言われる）ＵＩＭＳエディタ３１１を用いて作成される。エディタは、同様に、作成された視覚表示３１０を編集して精製するために使用され、人間の設計者が、アプリケーション及び利用者中心の要求から利用者インターフェースモデルを詳述すると共に、モデル設計図を連続的に照合して更新することを可能にする。
【００４９】
同様にエディタは、視覚モデル表示を標準的表示３２０に変換する。標準的表示は、機械読取可能な方法で利用者インターフェースモデルを取得するための手段を提供し、すなわち、手によって書かれたＵＩコードとは違って、ＵＩロジックはコードには埋められない。一実施例において、標準的表示は、“ＧＵＩマシン言語（GUIMachine Language：ＧＭＬ）”と呼ばれる工業所有権を有する言語の形式である。本実装例において、“ＧＭＬ”は、ＸＭＬをベースにした（XML-based）言語である。標準的表示は、同様に他の機械読取可能な言語で表されることができる。
【００５０】
標準的表示は、純粋に構成管理機能、及び知識管理機能のサポートを含んでいる、利用者インターフェースモデルのために構造化されたＵＴＭＳリポジトリ３２１を提供することを可能にする。ＵＩＭＳリポジトリは、反復の利用者インターフェース設計処理の間に、モデルへの修正を促進するツールのためだけでなく、コード生成ツールのための情報源として使用され得る。
【００５１】
更に、ＵＩＭＳリポジトリは、文書の生成、オンラインヘルプの生成、取り消し／やり直しの容易さ、取引の容易さ、エラー回復の容易さ、ドラッグ＆ドロップの容易さ、（その設計が指定された特性を満たすことを確認するための）設計評論家、（エンドユーザーの行動をシミュレートするための）モデルシミュレータ、及びモデル検証ツールのような様々な領域において、二次ツール３４０によって開発され得る利用者インターフェース知識の意味的に豊かな情報源を生成する。
【００５２】
１つ以上のＵＩＭＳキット３３１は、疑似コードまたは本当に現実のプログラムコードの形で、利用者インターフェースモデルの標準的表示３２０から動作するコードを生成するための手段を提供する。キットは、利用者インターフェースモデルを、特定の利用者インターフェースのコンテキスト、またはコンテキストのグループにおいてモデル化された利用者インターフェースを正しく実装するプログラムコード、及び付随のデータ構造に位置づけるために必要な、情報及び手続きを含む。異なるキットは、技術的なプラットフォームまたはコンテキストに基づいてＵＩモデルの実行可能コードの異なるインスタンス（instance）を生成するために使用され、ここで各キットは、視覚表示の標準的表示を読むと共に、特別なコンテキストに関して実行可能なコードを出力するように構成される。
【００５３】
モデル化システムを自動化するために上述されたそれらのような付随のツールが開発されることになるということが予期されると同時に、モデル化システムのエレメント（element）の１つ以上が手動の手段のみを用いて実現し得るということがそれでもなお注目されるべきである。例えば、視覚表示は、ペン、及び鉛筆を使用して線図を描くことによって作成され得て、詳細な仕様書は、穴埋め仕様書（filling-in specification forms）によって書かれ得ると共に、コード生成さえもが、手によるコード化技術（hand-coding techniques）を使用して達成され得る。
【００５４】
上述のモデル化システムの必ずしも全てのエレメントが本発明の実施例のために必要とされるとは限らないことが同様に注目されるべきである。例えば、視覚表示のみを含む実施例は、早期の設計、及びプロトタイピング（prototyping）に関する（実行不可能な）利用者インターフェースモデルを作成するため、及び他の開発チームとの交信のために使用され得る。または、標準的表示、及び実装キットのみを含む別の実施例は、遺産的利用者インターフェース変換ツール（legacy user interface transformation tools）の基盤として使用され得る。本発明の他の実施例が、その更に広い特徴において、本発明からはずれずに作成され得ることは、当業者にとって明白である。
【００５５】
本実施例において、モデル化システムは、モデルの異なる表示の基礎となるモデル構造物の一般のセットに基づいている。モデル構造物は、利用者インターフェースが多くの点で映画と類似するので、熟知の映画用語を用いて説明される。
【００５６】
利用者インターフェースは、映画のように話を観察者に伝える。物語を話すことは、アクターによって最後まで演じられ、一連の緊張が和らげられたシーン（scene）を通じて進展する。シーンにおけるアクターは、規定された台本に従って行動すると共に、相互に、そして周囲と交信する。しかしながら、全ての観察者に常に同じ話を告げる映画と異なり、利用者インターフェースは、異なる話を、異なる利用者に告げることができるか、または同じ利用者にさえも告げることができる。従って、利用者インターフェースは、一種の対話型であると共に個別化された映画として描かれることができる。
【００５７】
映画の比喩的表現（movie metaphor）に基づいて、モデル化システムは、利用者インターフェースが使用され得る可能な方法を表す１つ以上のシナリオ（scenario）の収集物として、利用者インターフェースモデルを構築する。シナリオは、タスク、またはタスクのセットを達成するために利用者が順番にシステムを使用することができる場合の方法の利用法である。シナリオは、利用者中心の要求の分析から得られると共に、利用者の種類、利用者目的、及び利用者インターフェースのコンテキストによって決まる。
【００５８】
図４を参照すると、シナリオ４３０は、１つ以上の交互配置されたシーン４４０で作成され、ここで、各シーンは、利用者が同時に実行することができる密結合された行動のセットを表す。本実施例において、新しいシナリオのインスタンスは、埋め込まれたシーンの再定義されたセットを備えるシナリオの原型に基づいており、すなわち、ＵＩパターンに基づいている。従って、与えられたシナリオの選択は、続いて選択されるであろうシーンの種類を定義する。シナリオが実行されるとき、まさに１つのシーンが時間内のあらゆる時点でアクティブ状態であるように、それらのシーンは順次に最後まで演じられる。それらのシーンが最後まで演じられる順序は固定していないと共に、調整、及び繰返しを含んでいる動的な遷移によって制御されることができる。別の実施例において、新しいシナリオは、最初から作成されることができると共に、ネストされたサブシーン、及びサブシナリオの所望の組み合わせは、作成されたシナリオに加えられることができる。
【００５９】
シーンは、同時にアクティブ状態であると共に協調しているアクター４５０から成る。アクターは、行動のスレッドを表す専門の計算ユニットである。アクターは、（例えば、所定のタスク、または関数を実行するように構成された）ある専門技術を処理する内部の状態を備えていると共に、（例えば、受信されたデータを処理する）事象に反応することができる。アクターは、メッセージを通じて、利用者と、基本的なアプリケーションと、または相互に交信する。アクターは、人間の設計者によって指定された行動の台本に基づいて、メッセージを処理すると共に、メッセージに反応する。
【００６０】
例えば、医用情報システムのための利用者インターフェースは、以下のようないくつかのシナリオを有することができる。Ａ）医者は、診療所のコンピュータから、彼の患者の病歴を閲覧すると共に編集する、Ｂ）医者は、診療所のコンピュータから、または自宅の彼のパーソナルコンピュータから、彼の約束の予定を閲覧すると共に編集する、Ｃ）患者は、自宅の彼のパーソナルコンピュータから、彼の個人的病歴を閲覧する、及びＤ）救急隊員（first-aid worker）は、救急車内のモバイル機器上で患者の病歴を閲覧する。これらのシナリオの各々は、どのように特別な利用者のグループがあるコンテキストにおいてシステムを使用することになるかを説明する場合の利用法である。
【００６１】
例を続けると、医者が彼の患者の病歴を閲覧すると共に編集するシナリオＡは、以下のようないくつかのシーンを有することができる。Ａ１）名前によって患者を検索する、Ａ２）選択された患者の病歴を閲覧する、Ａ３）患者の病歴を指摘する、Ａ４）新たな入力を選択された患者の病歴に加える等。これらのシーンの各々は、前述のシナリオの間に何度も回繰り返されることができるが、しかしシーンの間には、ある暗黙の規制がある。例えば、医者は、患者の病歴（Ａ４）へ入力をいくつでも加えることができるが、しかし彼は最初に、全ての彼の患者のリストの中から患者を検索する（Ａ１）と共に、選択（Ａ２）しなければならない。
【００６２】
更に例を続けると、医者が名前によって患者を検索するシーンＡ１は、以下のようないくつかのアクターから構成されることができる。Ａ１ａ)名前の検索文字列を取得するために利用者と交信するアクター、Ａ１ｂ）与えられた検索名に適合する患者のリストを照会すると共に検索するためにアプリケーションと交信するアクター、及びＡ１ｃ）患者の結果リストを利用者に提示するためのアクター。
【００６３】
本実施例において、シーン及びシナリオは、両方とも合成されたアクターであり、すなわちサブシーン／サブシナリオを含む他のアクターのための入れ物である。シーンは空間的な構成である。シーンに含まれる全てのエレメントは、同時にアクティブ状態であるか、または目に見える。シーンは、どのようにサブエレメントが表示画面に配置されるかを定義する。シナリオは時間的な構成である。シナリオにおけるシーンのうちの１つだけは、同時にアクティブ状態である。シナリオは、その制御が１つのシーンから別のシーンに渡されるときの遷移の流れを定義する。一実装例において、シナリオ及びシーンは、特定のアプリケーションまたは利用者の要求に従って最初から作成される。
【００６４】
別の実装例において、モデル化システムは、パターンの実例（pattern paradigm）を使用すると共に、シーン、及びシナリオの原型を提供する。シーン、及びシナリオの原型は、サブシーン、またはアクターのようなサブエレメントの固定のセット、または有名なセットを提供されるシーン、及びシナリオの専門の種類である。設計者は、その場合、彼が特別な場合に必要とする特定のエレメントを事前に定義されたセットの中から選択すると共に、特異性によってそれらを割り当てることだけを必要とする。これは、多くの場合、繰り返し発生するモデルに構造物を再利用することを考慮して、急速なモデル構成を可能にする。ＵＩＭＳキット、またはキット拡張は、そのような事前に構成されたシーン／シナリオの原型のセットを、利用者インターフェースのあるクラスに提供するか、または特別な産業に提供するために使用され得る。更にもう一つの実装例において、モデル化システムは、最初からシーン、及びシナリオを作るのと同様に、設計者がシーン、及びシナリオの原型を使用することを可能にする。
【００６５】
図３Ｃ及び図３Ｄは、本発明の一実施例によるパターンパラダイムに基づくモデル化システムを説明する。シナリオ１は、複数のシナリオの中から選択される。シナリオ１は、複数のサブエレメント、またはシーンを備えている。これらのシーンは、シーンの原型、または骨組み（shells）である。シナリオ１の特性が定義される。
【００６６】
次に、選択されたシナリオのための第１のシーンは、シーンＢを選択すると共に、その特性を定義することによって作成される。シーンＢは、複数のサブエレメント、またはアクターを有している。これらのアクターの１つ以上は選択されると共に、それらの特性が定義される。選択されたアクターの間の関係が定義される。
【００６７】
一度、第１のシーンが作成されたならば、選択されたシナリオのための第２のシーンは、別のシーンの原型（例えば、シーンＦ）を選択すると共に、上述のステップを繰り返すことによって作成される。第１のシーンと第２のシーンとの間の遷移、または関係が定義され、それによって複数のシーンを有するシナリオを作成する。上述のステップは、シナリオ、または視覚表示に関して必要とされる多くのシーンを加えるために、繰り返されることができる。
【００６８】
本実施例において、視覚表示は、利用者インターフェースモデルが容易に表され得る簡単な線図の表記法である。大部分の線図、及びいくつかの複合記号は、経路によって接続されたノードを含む図表である。情報は、記号の大きさ、または配置ではなく、主として接続形態にある。視覚表示を定義するために使用される視覚の関係は、以下を含む。（i）（通常２次元の形（2-d shapes）に対する線の）接続、（ii）（境界を有する２次元の形（2D shapes）による記号の）包み込み、及び(iii)付属品（線図上の別の記号の“近く”にある１つの記号）。これらの視覚の関係は、文法的に説明された表記法の標準的な形を、図表におけるノードの接続に位置づける。
【００６９】
視覚の表記法は、２次元の表面上で描かれることを意図している。いくつかの形は、（立方体のような）３次元の形の２次元の投射であるが、しかしそれらは、まだ２次元の表面上の形として与えられる。基本的には、視覚の表記法において使用される３種類の図式的構造物である、記号、線図、及び経路がある。
【００７０】
記号は、視覚の表記法において更に分解されることができない原子状の形である。記号は、それからモデルの線図が組み立てられる基本の構成要素を構成する。
【００７１】
経路は、端点が付加される線分の系列である。経路は、その断片は図式的に処理されることができるけれど、概念的に１つの位相的なエンティティ（entity）である。断片は、その経路から離れて存在しない可能性がある。経路は、ぶら下がっている線がないように、一般的に両端において記号に付加される。
【００７２】
線図は、経路によって接続された記号の収集物を保持する制限された領域である。線図は、それ自体が別の線図の中に置かれ得る記号である。視覚表示は、従ってネストされた線図のツリー構造であり、ここで、ルートの線図は利用者インターフェースモデルの全体を表す。
【００７３】
視覚の表記法は、紙に書かれたとき、静的な視覚の表記法と呼ばれる。視覚の表記法は、ＵＩＭＳ設計者を通じて提示されたとき、動的な視覚の表記法と呼ばれる。静的な視覚の表記法、及び動的な視覚の表記法は、意味的に同等である。動的な表記法は新しい情報を全く加えないと同時に、視覚の表記法を閲覧すると共に操作することを更に容易にするズーミング（zooming）、イクスパンディング（expanding）、ナビゲーティング（navigating）、フィルタリング（filtering）、及び、他の対話のような能力、及び視覚化技術を提供する。
【００７４】
視覚表示におけるエレメントは、一意的に識別可能である。これは、同じ線図における、または他の線図における他のエレメントから、表現法、または規則においてエレメントを参照することを可能にする。エレメントは、それを所有している線図の中で固有の名前を割り当てられる。完全に限定されたエレメントの識別子は、エレメント名を線図の識別子及び全てのその原型に連結することによって形成される。
【００７５】
図４は、本発明の一実施例に基づいた視覚表示によって使用される特殊記号を説明する。当業者は、視覚表示が他の象徴的な語彙を用いて組み立てられ得ることを認識することになる。従って、本発明は、ここに提示された記号の特定の語彙に制限されない。
【００７６】
インフォセット（infoset）は、利用者インターフェースとアプリケーションコントラクト（application contract）に基づいたアプリケーションとの間で渡される情報ブロックである。情報サービス４２０の線図は、アプリケーションコントラクトを通じて利用者インターフェースに利用可能なサービスを定義するために使用される。特別なサービスによって提供されるインフォセットは、そのそれぞれの線図の中に描かれる。サービスは、別のサービスの中にネストされることができる。同様に、サービスは、インヘリタンス（inheritance）を通じて他のサービスを定義するための原型として使用されることができる。
【００７７】
インフォセットは、情報オブジェクトの構造化された収集物である。インフォセットの記号は、インフォセットの構造を示す。いくつかの一般のインフォセットの構造は、シングルトン（singleton）４２１（ちょうど１つのオブジェクトを保持する収集物）、リスト４２２（順序付けられたオブジェクトのリスト）、バッグ４２３（順序付けられていないオブジェクトのリスト）、クラスター４２４（ネストされたオブジェクトの収集物）、ツリー構造４２５（オブジェクトの階層型収集物）、及びグラフ４２６（連結されたオブジェクトの収集物）を有する。
【００７８】
インフォセット内の物体は、オブジェクトタイプのインスタンスである。オブジェクトタイプは、同様のオブジェクトのクラスを表すと共に、それらのデータフィールド構造を定義する。オブジェクトタイプは、シングルトン４２１と同じ記号を用いて描かれる。オブジェクトタイプは、インヘリタンスを通じて他のオブジェクトタイプを定義するための原型としての役目を果たすことができる。インフォセットは、オブジェクトタイプのあらゆる数のインスタンスであるオブジェクトを有することができる。インフォセットにおいて許されるオブジェクトタイプの記号は、インフォセットの記号の中に描かれる。
【００７９】
インフォセットの規則性は、インフォセットにおける包含に有効であるオブジェクトタイプの混合（mix）の手段である。規則的なインフォセットは、同じオブジェクトタイプの全てのインスタンスであるオブジェクトだけを含むことができる。不規則なインフォセットは、異なるオブジェクトタイプのインスタンスであるオブジェクトを含むことができる。もしインフォセットにおいて許される全てのオブジェクトタイプが同じ基本のオブジェクトタイプから継承される場合、インフォセットは、半規則的であると考えられる。
【００８０】
インフォセットは、それ自体がオブジェクトタイプであり、従って別のインフォセットの中に含まれ得ると共に、任意に複合的なインフォセットの構造の定義を可能にする。視覚的に、これは、含んでいるインフォセットの記号の中に包含されるインフォセットの記号を描くことによって示される。
【００８１】
オブジェクトタイプ、及びインフォセットが描かれる方法は、インフォセットの構造、及び規則性を反映する、一意的にモザイク模様にされた箱形に帰着する。この形は、インフォセットの構造上の形の抽象的署名であるインフォシェイプ（infoshape）と呼ばれる。アクターは、通常、特定のインフォシェイプ（例えば、インフォセットの通常のリストに関して設計されているテーブル一覧のインタアクター）を使用して作業をするために設計されている。
【００８２】
アクティブ状態のオブジェクトであるアクターと対照的に、インフォセットは、パッシブ状態のオブジェクトである。インフォセットは、本実施例において、ちょうど１つのアクターによって常に所有され、従って、インフォセット記号は、それを所有しているアクターの記号の中に描かれる。逆に、本実施例において、アクターは、ちょうど１つのインフォセットを常に所有している。インフォセットは、それを所有しているアクターによってのみ直接アクセスされ得る。
【００８３】
アクター４５０は、同時に起こるアクティブ状態のエンティティを、具体的な義務と共に表示する。同時処理は、アクターが、同じ環境において他のアクターと並列に存在すると共に、動作し得ることを意味する。アクターの実装は、カプセル化シェルによって周囲、及び他のアクターから隠されている。
【００８４】
アクターがその周囲と交信するように、そのカプセル化シェルは、情報が流れ込むか、または流れ出すことができるポートと呼ばれる開口部を備えている。視覚的に、アクターのポートは、アクターの端に描かれる。ポートの方向は、その記号によって示され、入力ポート４４５において、情報はアクターに流れこみ、出力ポート４４６において、情報はアクターから流れ出ると共に、双方向ポート４４７において、情報は両方の方向へ流れる。
【００８５】
交換される情報は、メッセージと呼ばれる不連続単位にまとめられる。メッセージは、インフォセットのインスタンスである。一般的に、メッセージは、アクターに対して利用できる唯一の通信手段である。カプセル化シェルのせいで、アクターの動きは、そのポートにおけるメッセージの流れを観察することによって、外側からのみ推論され得る。逆に、アクターの環境の知覚は、そのポートを通じて受信された情報に制限される。
【００８６】
アクター上の各ポートは、アクターの１つの専門のインターフェースを表す。ポートの属性のうちの１つは、ポートを通過することを許される有効なメッセージタイプのセット、及びそのポート上での正当なメッセージ交換シーケンスのセットを有する、ポートの関連付けられたプロトコルである。
【００８７】
メッセージのバインディングは、アクターの間の有効な通信の関係を明白に表示すると共に、抑制するために使用される。もし、２つのアクターが、それらの間にバインディングを有している場合、同じ階層における２つのアクターは直接通信し得る。バインディングは、あるアクターから別のアクターまでメッセージを運ぶ内在する通信チャンネルの抽象化である。バインディングは、非同期メッセージ４４１、または同期メッセージ４４２のどちらでもあり得る。妨害なしでバインディングする非同期メッセージ、すなわちメッセージを送った後で、その送り手は単に活動を続ける。同期メッセージのバインディングの場合には、受け手がそれ自身のメッセージによって返答するまで、送り手は遮断される。
【００８８】
バインディングは、一般的に、相互に互換性があるプロトコルを有するポートの間に描かれる。一般的に、通信の方向がポートの方向性から推論され得るので、バインディングは通信の方向を示さない。コンディション（condition）コネクタ４４３は、いくつかの動的な規則に応じて異なるアクターに対する経路が定められた条件付きのバインディングを定義するために使用されることができる。コンテニュエイション（continuation）コネクタ４４４は、線図の遠隔地に分岐するバインディングを定義するために使用されることができる。コンテニュエイションコネクタは、同様に、２つ以上のアクターに同時に分岐するバインディングを定義するために使用されることができる。
【００８９】
アクターは、原型をベースにしたインヘリタンスを通じて定義される。設計者は、ＵＩＭＳキットの中から適切なアクターの原型を選択すると共に、特性を指定することによって、及び反応を台本化することによって、必要とされる動きを修正する。このようにアクターの原型から直接定義されるアクターは、原子アクター（atomic actors）と呼ばれる。原子アクターそれ自体は、別の原子アクターのための原型としての役目を果たすことができる。新しいキットを提供する、または現存するキットを拡張することによって、利用できるアクターの選択は、様々なカスタマイズされた要求を満たすために、作成され得るか、または拡張され得る。
【００９０】
いくつかの一般に発生している原子アクターの原型は、インフォアクター（infoactor）−インフォセットを取得する、または修正するために、内在するアプリケーションと交信するアクターと、インタアクター（interactor）−インフォセットを見る、または編集するために、利用者と対話するアクターと、プレゼンター（presenter）−インターアクターの提示の形状、及びスタイルを制御するために使用されるアクターと、トランスフォーマー（transformer）−１つ以上のインフォセットを集合演算を使用する新しいインフォセットに変換するために使用されるアクターと、コラボレーター（collaborator）−マルチユーザ環境における並列のアクターのインスタンスの間を仲介をするために使用されるアクターとを有する。
【００９１】
アクターは、動作している利用者インターフェースにおいて何度も例示され得ると共に、全てのインスタンスは同じ動きを共有するが、しかし、各インスタンスはそれ自身の内部の状態を維持する。例えば、テーブル一覧のアクター（table view actor）は、頻繁に使用されたアクターの原型である。それは、スクロールや選択のようないくつかの一般的な機能性によって利用者に同様な物体の均一なリストを提示する、一般的な能力を表す。患者のリストを提示するためのアクターは、患者の属性とテーブルの列との間でマッピングを指定することによって、テーブル一覧のアクターに基づいて定義され得る。このアクターの異なるインスタンスは、同じワークステーション上、または異なったワークステーション上のいずれでも、患者の検索照会の結果を表示するために使用されることができる。全てのインスタンスは、同じ列構造によってテーブルを示すが、しかし各テーブルは、患者の記録の異なったリストを表示すると共に、別々にスクロールされ、かつ選択され得る。
【００９２】
タスクが１つの原子アクターによって効果的に表されるにはあまりにも複合的であるか、またはあまりにも多いとき、その場合に、それを同時に発生するアクターの収集物に分解するために、シーン４４０の線図を使用することが可能である。包含されたアクターの各々は、全体の機能性のサブセットに関与する。アクターのポートの間のメッセージのバインディングは、それらの特定の機能性を全体のタスクの機能性に結合するためにどのようにそれらのアクターが協調するかを定義する。
【００９３】
シーンは、それ自体がアクターである。シーンに含まれるアクターは、同じ方法で次々にサブシーンに更に分解されることができる。分解のこの処理は、任意のレベルに対して実行されることができる。シーンは、同様に、インヘリタンスを通じて他のシーンを定義するための原型として使用されることができる。
【００９４】
ポートは、モデルの更に高い階層によってシーンのインターフェースを定義するために、シーンの線図の端において描かれ得る。シーンのポートは、代表団の概念に相当する内部コンポーネントのアクターに接続され得る。シーンがモデルの更に高い階層から見られるとき、そのポートのみが目に見えると共に、そのコンポーネントのアクター、及びそれらのメッセージのバインディングを有するシーンの内部構造は隠されている。
【００９５】
タスクの構造、または動作が動的に変化し得るとき、その場合に、それを交互配置されたシーンの収集物に分解するために、シナリオ４３０の線図を使用することが可能である。シナリオにおけるシーンの各々は、特別なタスク状態／対話状態を表す。本実施例において、ちょうど１つの状態が時間内のあらゆる時点でアクティブ状態である。
【００９６】
トランジションの矢印４３１は、可能な状態遷移を示すためのシナリオ状態と、これらの遷移を誘発する事象との間に描かれる。遷移の方向は、矢印によって示される。イニシャル状態４３７、及びターミナル状態４３８は、それぞれ、どこでそのシナリオが発生し、そして終わるかを示す。インボケーション（invocation）４３２は、対象状態を実行すると共に、一度対象状態が終了すればソース状態に戻る遷移の特別な種類である。それは、２つの状態の間で対面している遷移のペアを描く代わりに使用される近道の表記法である。
【００９７】
コンディションコネクタ４３３は、いくつかの動的な規則に応じて異なる状態に分岐する条件付きの遷移を定義するために使用されることができる。コンテニュエイションコネクタ４３４は、線図の遠隔地に分岐する遷移を定義するために使用されることができる。オプションコネクタ４３５は、任意の状態のグループの内の１つに分岐する遷移を定義するために使用されることができる。レピティション（repetition）コネクタ４３６は、いくつかの動的な条件が満たされるまで、繰り返される遷移を定義するために使用されることができる。
【００９８】
シナリオは、それ自体がアクターである。シナリオに含まれるシーンは、同じ方法で次々にサブシナリオ、またはサブシーンに更に分解されることができる。分解のこの処理は、任意のレベルに対して実行されることができる。シナリオは、同様に、インヘリタンスを通じて他のシナリオを定義するための原型として使用されることができる。
【００９９】
ポートは、モデルの更に高い階層によってシナリオのインターフェースを定義するために、シナリオの線図の端において描かれ得る。シナリオのポートは、フォーク／ジョイン（fork/join）４４８コネクタを使用することによって、包含されるシーンに接続される。シナリオがモデルの更に高い階層から見られるとき、そのポートのみが目に見えると共に、その状態、及びそれらの遷移を有するシナリオの内部構造は隠されている。
【０１００】
コンテキストセレクタ４５１は、特別な利用者インターフェースのコンテキスト、またはコンテキストのグループを表す。コンテキストセレクタは、装置のクラス、または利用者の役割に従って階層を作成するゼネラリゼイションの矢印４５４によって関係付けられ得る。コンテキストセレクタがエレメントに適用されるとき、それは、モデルによるエレメントの使用を、そのコンテキストに属する利用者インターフェースのみに制限する。
【０１０１】
コンテキストセレクタは、それをエレメント記号の中に配置することによってエレメントに適用される。２つ以上のコンテキストセレクタは、同じエレメントに適用され得る。複数のコンテキストセレクタは、論理和結合される。ネガティブコンテキストセレクタ４５２は、エレメントからコンテキストを取り除くために使用され得る。
【０１０２】
エレメントに適用されるコンテキストセレクタは、それの包含された全てのエレメントによって継承される。追加のコンテキストセレクタは、包含されたエレメントに対して、更に制限する方法でのみ適用され得る。これは、更に高い階層が複数のコンテキストによって共有されると共に、更に低い階層が特定のコンテキストに制限される、統一された利用者インターフェースモデルの創造を可能にする。
【０１０３】
リモートコンテキストのセレクタ４５３は、利用者インターフェースのリモートインスタンス（remote instance）に属しているエレメントを指定するために使用される。リモートコンテキストを用いることによって、マルチユーザ環境における複数の利用者の間のメッセージと遷移とを統合することが可能である。
【０１０４】
パッケージ４１０の線図は、構成の目的に関するあらゆるモデルエレメントを一緒に集めるために使用される。他のパッケージを有して、パッケージはあらゆるエレメントを保持し得る。パッケージは、一般的に、再利用性の目的に対するモデルエレメントの定義を組織化するために使用される。
【０１０５】
ノート４６１は、文書化の目的に対するあらゆる線図のエレメントに付加されることができる。ブラケット４６３の記号は、ノートを線図のエレメントのグループに加えるために使用されることができる。プロパティ４６２の記号は、エレメントについての追加の仕様詳細を保持する、対応する特性のシートに参照を付けるために、あらゆる線図のエレメントに付加されることができる。
【０１０６】
アクターは、関数のモジュール方式に関するユニットを定義する。モデルの他の部分に影響を及ぼさずに、アクターの内部構造、または動作を修正することが可能である。複合的な機能性を実行するアクターは、各々が全体の機能性のサブセットに関与するコンポーネントアクターに分解される。分解のこの処理は、実際には機能の分解である。
【０１０７】
同様にアクターは、継承及び再使用のためにユニットを定義する。原子アクター、及び合成アクター（compound actors）の両方を他のアクターのための原型として使用することが可能である。アクターがちょうど１つの原型を有しているので、アクターが単一のインヘリタンスを使用するということが示唆される。複数のインヘリタンスは、本実施例におけるモデルによってサポートされない。好ましい方法は、複数のインヘリタンスを使用する代りに、他のアクターをアクターに組み込むと共に、アクター自身のインターフェースとしてそれらのインターフェースの一部を通過することである。
【０１０８】
同様にアクターは、処理のためにユニットを定義する。モデルにおける全てのアクターは、それ自身の実行のスレッドを有するアクティブ状態のオブジェクトである。アクターの状態は、再帰的に以下のように定義される。原子アクターの状態は、それ自身の状態である。合成シーンアクターの状態は、シーンのメンバーである全てのアクター（原子アクターまたは合成アクターのいずれか）の状態の結合である。合成シナリオアクターの状態は、アクティブ状態の現在のシーンの状態である。アクターによって状態が内部に維持されるので、アクターとの対話は、自由自在に一時中断されると共に再開され得る。
【０１０９】
従って、サーバかクライアントワークステーションのうちのどれでものいずれか上で、あらゆるプロセッサ上のアクターを創作することが可能である。創作中のアクターのインスタンスは、それが作成されたプロセッサから異なるプロセッサまで、まさに動かされ得る。アクターのインスタンスが創作される場所は、実施にかかわる問題であると共に、モデル化システムに影響を及ぼさない。従って、完全にクライアントワークステーション上で創作される利用者インターフェース、及び完全にアプリケーションサーバ上で創作される同等の利用者インターフェースを生成するために、両者の間のあらゆる組み合わせを生成するのと同様に、同じ利用者インターフェースモデルが使用され得る。
【０１１０】
このように見られたとき、結局、利用者インターフェースモデルは、（シーンを通じて）空間的、または（シナリオを通じて）時間的のいずれかにおいて、再帰的に構成される原子アクターの収集物である。トップレベルのシナリオの状態である利用者インターフェースの状態は、アクティブ状態のアクターの現在の構成、及びそれらの個々の状態で作成される。
【０１１１】
同時に発生すると共に協調するアクターの間の対話の状態の分配によって、モデル化システムは、非常に並列で、かつ組み立て式の構成を作成する。これは、複数の様式、アクセスチャネル、対話スレッド、及び利用者タイプとの複合的な利用者インターフェースを扱うと共に、利用者インターフェース設計の反復の性質に起因する一定の変更に耐えるための要因を可能にする秘訣である。
【０１１２】
図５は、本発明の一実施例によるモデル化システムが提供される企業のポータル５０２を説明する。ポータル５０２は、クライアント５０４を複数の情報源５０６に接続する。クライアント５０４は、フロントエンドシステムと関連付けられていると共に、情報源５０６は、バックエンドシステムと関連付けられている。バックエンドシステムは、クライアントと情報源とを接続するアプリケーション階層を有している。
【０１１３】
クライアント５０４は、インターネット、イントラネット、広域ネットワーク、ローカルエリアネットワーク等によってポータル５０２と連結されるパーソナルコンピュータ（ＰＣ）でも良い。ポータルは、利用者に、様々なアプリケーション及び情報に対する共通の入り口を提供するように構成される。
【０１１４】
本実施例において、ポータル５０２は異なる複数の技術を統合し、利用者が、企業の内部及び外部の両方にあるアプリケーション、及び情報にアクセスすることを可能にする。情報源５０６は、（ある企業に関する）外部のアプリケーション５１４、（ある企業に関する）内部のアプリケーション５１６、外部の文書ソース５１８、内部の文書ソース５２０、及びウェブ５２２を有する。
【０１１５】
ポータルは、統一サーバ５０８、ポータルサーバ５１０、及び知識管理部５１２を有する。統一サーバは、様々なソースからのアプリケーションと情報の両方の動的な統合を可能にするビジネス統一階層を提供するように構成される。ビジネス統一階層は、ポータルの利用者が、アプリケーション、及び情報を動的に統合することができるように、統一されたオブジェクトモデルの創造を可能にする。コンポーネントシステムにおいて提供された論理的ビジネスオブジェクトは、リポジトリに記憶される統一オブジェクトモデルを作成するために使用される。それらのオブジェクトは、利用者が１つの情報源から別の情報源に内容を動的に渡すことができるように、リンクによって相互に位置づけされる。
【０１１６】
論理的ビジネスオブジェクトは、組織の業務、管理、計画、または会計における物、概念、処理、または事象を表すために使用される。各ビジネスオブジェクトは、属性、関係、及び行動／事象を指定する。例えば、ビジネスオブジェクトは、システムの発注者、販売者、及び利用者を表すために使用されることができる。
【０１１７】
ポータルサーバは、クライアントと、例えば“iView”のような複数のプレゼンテーションコンポーネント（presentation component）を有するポータルコンテンツディレクトリ（portal content directory：ＰＣＤ）５３４と通信するウェブサーバ５３２を有する。ＰＣＤは、一実装例においてＵＩＭＳリポジトリ３２１、及びＵＩＭＳキット３３１を有している。ＰＣＤは、同様に役割を有するファイルをベースにしたディレクトリと、ポータルが対話するべきシステムである。一実装例において、ＰＣＤは“Java 2 Enterprise Edition（商標）”準拠のアプリケーションサーバ上で動作する。
【０１１８】
知識管理部（ＫＭ）５１２は、知識及び協調を管理するためのサービスのセットである。ＫＭ５１２は、データの物理的位置に関係なく、１つのビジネス管理プラットフォームの下で様々なビジネスツールを調和させるためのプラットフォームを提供する。一実装例において、ＫＭは、文書及び対応する文書属性の内容と、フォルダまたはツリー構造内の内容を組織化する分類エンジンと、そして情報を管理するための他のコンポーネントを管理するリポジトリの枠組を有する。
【０１１９】
図６は、本発明の一実施例による、利用者インターフェースモデルを作成するための処理６００を説明する。ステップ６０１において、利用者インターフェースの特別なコンテキスト（例えば、コンテキストＣ）に関する利用者の要求が、様々な方法、及び利用可能な手順に従って集められる。利用者の要求に基づいて、利用者タスクモデルが利用者インターフェースのコンテキストＣに関して定義され、すなわちどのようなステップが要求を満たすのに必要とされるかを決定する（ステップ６０２）。利用者タスクモデルは、利用者インターフェースのコンテキストの中での利用者の活動をサポートするのに必要とされるタスク（関数）の階層分解である。各タスクは、原子タスク（atomic task）か、並列配置または交互配置されたサブタスクで作られた合成タスク（composite task）のいずれかであり得る。利用者タスクは、複数のコンテキストに対して定義されることができる。
【０１２０】
情報モデルが定義され（ステップ６０３）、例えば、アプリケーション／ビジネス関数が選択されて呼び出される。このステップは、利用可能な手順のうちのどれでもにおいて、アプリケーションのビジネス階層を分析することを必要とし、ステップ６０２からの利用者タスクに関連する情報サービス、及びオブジェクトを識別すると共に、それらの構造、及びコントラクト（contract）を定義する。それに基づいて、情報モデルは、サービス線図、及びインフォセット記号を用いて定義される。
【０１２１】
ステップ６０２からの利用者タスクに基づいて、モデル構造がシナリオ、及びシーンのネストされた線図を用いて定義され（ステップ６０４）、例えば、シナリオ、シーン、及びアクターが選択される。交互配置されたサブタスクから構成されるタスクはシナリオの線図に位置づけられ、一方並列配置されたアクティブ状態のサブタスクから構成されるタスクはシーンの線図に位置づけられる。原子タスクは、適切な原子アクターに位置づけられる。
【０１２２】
ステップ６０４において識別されたシナリオ、シーン、及びアクターの動作の特徴は、更に詳細に定義され（ステップ６０５）、例えば、選択されたシナリオ、シーン、及びアクターの間の関係が定義される。各シナリオに関して、関連する遷移の流れが定義される。各シーンに関して、正確なメッセージのバインディング及びポートが定義される。必要とされる所で、アクターの特性、表現、及び動的な規則が定義される。
【０１２３】
ステップ６０４において識別された各シナリオ、シーン、及びアクターは、適切な表示画面に位置づけられると共に、そのレイアウトが定義され（ステップ６０６）、例えば、集められた情報のレイアウトの一覧が定義される。必要とされる所で、様式（Styles）、及び図表（graphs）がカスタマイズされる。モデルは、利用者インターフェースをシミュレートするか、または生成すると共に、ステップ６０１において集められた利用者の要求と対照して比較することによって確認される。ステップ６０２からステップ６０６は、利用者の要求が達成されるまで、モデルを洗練するために必要に応じて何回も繰り返される。ステップ６０１からステップ６０７は、利用者インターフェースによってサポートされる必要がある各コンテキストに対して繰り返される。
【０１２４】
上述されたモデル化システムは、単純な環境及び複雑な環境の両方において、広く多岐に渡るコンテキストに使用されることができる利用者インターフェースを作成するために使用されることができる。この発明者は、特定の機能に専念するサーバ、及びコンピュータの複数の階層を有する企業のポータル環境に、このモデル化システムを首尾よく実施した。企業のポータルのコンテキストにおいて実施されたモデル化システムは、“GUIMachine（“ＧＭ”）”モデル化システムと言われる。
【０１２５】
ＧＭモデル化システムは、ビジュアルオブジェクトをドラッグ＆ドロップすると共に、それらの間の関係を確立することによって、“ＵＩｓ”が迅速に、かつ容易に開発されることを可能にする視覚化ツールである。このツールは、データベースによって直接機能するよりはむしろ、ビジネス階層に接続するか、またはビジネス階層に作用するように機能する。従って、ツールは、メタデータ（または、データベースの構造）を読んで理解すると共に、ビジネスロジックを保護するために、ビジネス階層またはアプリケーション階層でデータを処理するように構成される。
【０１２６】
例えば、ツールは、ビジネス階層の一部であると共にデータベースの一部ではない販売注文のライフサイクルを追跡するために使用されることができる。ビジネス階層は、そのような情報を決定すると共に、選択されたテーブルに適切なフォーマットで格納する。従って、この視覚化ツールは、例えばリモートファンクションコール（Remote Function Calls：ＲＦＣ）、及びビジネスアプリケーションプログラムインターフェース（Business Application Program Interfaces：ＢＡＰＩｓ）のようなビジネス関数モジュール、またはビジネス関数コンポーネントを組み込むために、ビジネス階層に接続する。ビジネス関数コンポーネントは、ビジネス階層の一員であると共にビジネスロジックを有している再利用可能なアプリケーションコンポーネントである。
【０１２７】
視覚化ツールは、利用者インターフェースモデルの急速で、かつ効率的な合成を可能にする、利用者インターフェースパターンの事前設定の選択に基づいたパターンをベースにしたツールである。以下のステップは、“マスタ−詳細”パターンと呼ばれる、周知の利用者インターフェースパターンの例である。（１）会社ＡＢＣの全ての顧客に関するデータを取得する。（２）任意に、いくつかの基準によって顧客データをフィルタ処理すると共に分類する。（３）表にした一覧において結果を表示する。これがマスタの一覧である。（４）特別な顧客がマスタの一覧において選択されるときはいつでも、その顧客に関する注文データを取得する。（５）第２のテーブルの一覧において注文を表示する。これが詳細の一覧である。同じマスタ−詳細パターンは、利用者インターフェースの多くの例において認識され得ると共に、マスタの一覧の同じ概念を１つ以上の連結された詳細の一覧と全て共有するが、しかし、それぞれは、場合によってはマスタの一覧、及び詳細の一覧における異なるデータセットに置き換えられる。
【０１２８】
視覚化ツールは、あらゆる与えられたモデルと関連付けられるかどうかわからない。モデルは、特別なビジネスソリューションに合わせて調整される１つ以上のパッケージを有する。パッケージは、複数の統合された一覧（“iView”）を同様に備える１つ以上のページを有する。“iView”は、アプリケーション、記憶された文書、またはインターネットからデータを検索するポータルプレゼンテーションコンポーネント（portal presentation components）、またはポータルスニペット（portal snippets）であると共に、クライアントマシン上に検索されたデータをポータルコンテンツ（portal content）として表示する。
【０１２９】
図７Ａは、本発明の一実施例による、ＧＭモデル化システムの標準的表示のモデル化階層を説明する。標準的表示は、インフォメーションモデル階層７０１、インタラクションモデル階層７０３、及びプレゼンテーションモデル階層７０５という３つのメイン階層を有する。インフォメーションモデル階層７０１は、内在する最終段階のアプリケーションから受け取られ得るか、または内在する最終段階のアプリケーションに送られ得る、及び最終段階の関数に呼び出され得る情報オブジェクトを定義する。これは、利用者インターフェースと内在するアプリケーションとの間のコントラクト、またはプロトコルを実際に定義する。情報モデルは、アプリケーションの仕様から得られる。
【０１３０】
インタラクションモデル階層（interaction model layer）７０３は、利用者インターフェースを使用すると予想される利用者のタイプ、利用者インターフェースを使用することによって達成すると考えられるタスク、及び各タスクを実行するのに必要とされる特定の利用者インターフェースダイアログ（user interface dialogues）を定義する。インタラクション階層は、情報モデル階層から、及び利用者の要求の分析から得られる。
【０１３１】
プレゼンテーションモデル階層７０５は、利用者インターフェースが、トポロジー（どのようにエレメントが相互の中にネストされるか）、ジオメトリ（どのようにエレメントが表示画面に配置されるか）、及びスタイリング（どの色、フォント、グラフィックス等を使用するか）を含んで、どのように出現することになるかを定義する。プレゼンテーションモデル階層は、インタラクション階層から得られるが、しかしブランド設定、及び集団のスタイルガイドのような他の要求と同様に、人間工学設計の要求によっても決まる。
【０１３２】
上述の全てのモデル階層は、ハードウェア、ソフトウェア、及び利用者インターフェースコンテキストを集合的に定義する物理的パラメータの収集物である利用者インターフェースコンテキストモデルによって更に変わる。利用者インターフェースコンテキストモデルは、画面サイズのような制限的要因、入出力装置の存在等によって、他のモデル階層に制限を課すことができる。
【０１３３】
一実装例において、フォーマルモデル階層（formal model layers）は、表現を単純化すると共に、標準的表示を更に管理できる状態にするために、明示的に表現されない。もっと正確に言えば、各アクターは、情報、対話、及びプレゼンテーションの様相という３つの様相を有すると考えられ得る。アクターの３つの様相は、アクターの中で統合されるが、しかしアクターは、おおまかにそれら自体が連結される。これは、以下の更なる詳細において説明されるように、並列構造を可能にすると共に、モデルに対する迅速で、かつ付加的な修正を可能にするモデル化階層の分散された構成に帰着する。
【０１３４】
図７Ｂは、本発明の一実施例による、手動のコーディングなしでＧＭモデル化システムを使用する利用者インターフェースを作成するための処理７００を説明する。ＧＭモデル化システムは、企業のポータルと関連付けられた様々なアプリケーション、及び情報源にアクセスするためにアプリケーションロジックを組み込む利用者インターフェースを作成する。処理７００は、ＵＩモデル化システムの典型的な画面例である図８から図１６を用いて以下で説明される。
【０１３５】
処理７００は、ＵＩモデル化システムにアクセスするために、設計者がポータルクライアント５０４からポータルサーバ５１０に対してログオンする時に始まる（ステップ７０２）。一実施例において、モデル化システムは、専用のサーバ、すなわち“GUIMachine”サーバ（ＧＭサーバ）によって提供される。
【０１３６】
モデル化システム、またはＧＭストーリーボード（GM Storyboard）は、それによって開かれる。設計者がＧＭストーリーボードにログオンするとき、画面８０２（図８）が現れる。画面８０２は、作業領域８０６、及びタスクパネル（task panel）８００を含む。作業領域は、ＵＩの視覚化表示が設計されると共に、表示される場所である。作業領域は、設計タブ、レイアウトタブ、プレビュータブ、及びソースタブを有する。設計タブは、作業領域でＵＩを設計するために選択される。レイアウトタブは、“iView”のレイアウトをカスタマイズするために使用される。プレビュータブは、“iView”のロジックをプレビュー（下見）すると共に、有効とするために使用される。ソースタブは、ＧＭストーリーボードによって自動的に生成される“GUIMachine”言語（ＧＭＬ）コードを見るために使用される。ＧＭＬコードは、標準的表示３２０に対応する。
【０１３７】
タスクパネル８００は、作業領域で実行されつつあるタスクに関連したツールを表示する。タスクパネルは、ツールの異なるセットを表示するために複数の状態を有している。これらの状態は、“Get Started”、“Model Explorer”、“Logic Elements”、“Layout Styles”、“Field Definition”、“Element Properties”、“Data Sources”、“Code Compiler”、及び“Model Debugger”を有する。モデルが作業領域で開かれないとき、“Get Started”状態が現れると共に、設計者が既存のモデルを開くか、または空白のモデルを作成することを可能にする。“Model Explorer”状態は、モデルを表す階層型ツリー構造を表示する。ツリー構造は、モデル階層を修正すると共に、モデルを操作するために使用され得る。“Logic Elements”状態は、モデルの構築中のブロックを定義するために使用される。モデルエレメントを表すアイコンは、“Logic Elements”状態のタスクパネルにおいて表示される。“Layout Styles”状態は、“iView”のレイアウトをカスタマイズするために使用される。“Field Definition”状態は、“iView”において情報の流れを定義するときに使用される。“Element Properties”状態は、様々なモデルエレメントの特性を定義するために使用される。“Data Sources”状態は、ビジネス関数をモデルに取り込むために使用される。“Code Compiler”状態は、ポータルビジネスパッケージ（portal business packages）をコンパイルすると共に、配置するために使用される。“Model Debugger”状態は、あなたのモデルのロジックを有効とするために使用される。
【０１３８】
処理７００に戻って参照すると、新しい、または既存のＧＭモデルは、ＵＩの視覚化表示を作成するか、または修正するために開かれる（ステップ７０４）。画面９０２は、ステップ７０４（図９）を説明する。ＧＭモデルの名前が入力される。ＧＭモデルは、１つ以上のページ、及び１つ以上の“iView”を有する。“iView”は、例えばアプリケーション、及び／またはデータベースから特定のデータを検索すると共に、それらを指定された方法でクライアントに表示するような特定のタスクを実行するポータルプレゼンテーションコンポーネントである。“iView”は、利用者に表示される情報と同様に、必要とされるタスクを実行する両方のコンポーネントを参照するために使用されることができる。従って、用語“iView”は、言語“integrated view（統合された一覧）”から得られる。ページは、１つ以上の“iView”を有する入れ物である。“iView”は、アクター４５０に対応すると共に、例えばビジネス関数のような原子アクターから構成される。ページは、シナリオ４３０の特別な種類である。
【０１３９】
一度、ＧＭモデルが開かれたならば、高水準のエレメントがタスクパネル８００を使用するＧＭモデルに加えられる（ステップ７０６）。ＧＭモデルは、エレメントの階層を定義する。階層は、以下の高水準のエレメントであるページ、“iView”、及びモジュールのうちのどれでもを有することができる。ＧＭモデルにおけるページ、及び“iView”は、最終的にはポータルページ、及びポータルプレゼンテーションコンポーネントにコンパイルされる。モジュールは、モデルにおいてページ及び“iView”を編成するために使用されると共に、ほぼ同じような方法で、フォルダは、ファイル管理システムにおいてファイルを編成するために使用される。モジュールは、一実装例においてパッケージ４１０に対応する。
【０１４０】
ＧＭモデルに加えられた高水準のモデルエレメントに関する特性が定義される（ステップ７０８）。ページの名前、及び動作が定義される。ページの動作は、ポータルの利用者が、実行時間（runtime）においてページから“iView”を除去するか、または実行時間においてページの“iView”を再整理し得るかどうかということを含む。“iView”の名前、及び動作が定義される。“iView”の動作は、クライアントマシーン上のポータルページに、どのようにそれがロードされると共に組み込まれるかを定義する。
【０１４１】
それ以降、ステップ７０８で定義された“iView”は、データソース階層を作成し、ＵＩロジックを組み立て、そしてレイアウトをカスタマイズすることによって構築される（ステップ７１０）。データソース階層は、データソースの定義をモデルに加え、内在するアプリケーションのメタデータを定義する。例えば、リモートファンクションコール（Remote Function Calls：ＲＦＣｓ）、及びビジネスアプリケーションプログラムインターフェース（Business Application Program Interfaces：ＢＡＰＩｓ）は、顧客のリストを表示するために“iView”によって使用される。これらの“ＲＦＣｓ”、及び“ＢＡＰＩｓ”は原子アクターである。ここに使用されるように、データソース階層のコンポーネントは、データソースオブジェクトと言われる。ＵＩロジックは、ＵＩコンポーネント（例えば、様式一覧（form view）、リスト一覧（list view）、グリッド一覧（grid view））、及びそれらの間の接続を定義する。同様にＵＩロジックは、データソースオブジェクトに対するＵＩコンポーネントと、フィルタ、ソート関数、及び集合関数のようなデータオペレータとの間の接続を定義する。レイアウトは、“iView”の全ての目に見える特徴を定義する。図７Ｄは、データソース階層７５２、ＵＩロジック７５４、及びＵＩレイアウト７５６を有する典型的な“iView”７５０を説明する。
【０１４２】
ステップ７１２において、もし設計者が別の“iView”を構築することを望む場合、ステップ７０６からステップ７１０が繰り返される。図７Ｅは、第１の“iView”７６２、第２の“iView”７６４、イベンティング（eventing）７６６、及びレイアウト７６８を有するページ７６０を説明する。イベンティング７６６は、同じページ上の２つの“iView”の間でメッセージを送るために、エンタープライズポータルコミュニケーションメッセージング（Enterprise Portal Communication Messaging：ＥＰＣＭ）メカニズムを参照する。“GUIMachine”モデルにおいて、イベンティングは、ページ／シナリオ４３０における２つの“iView”シーン４４０の間の非同期メッセージバインディング４４１に対応する。各“iView”は、データソース階層、ＵＩロジック、及びＵＩレイアウトを有する。
【０１４３】
一度、ＧＭモデルが完成されたならば、モデルは、それがポータルコンテンツにアクセスするために使用され得るように、実行可能コードにコンパイルされると共に、ポータルに配置される（ステップ７１４）。ＧＭモデルが構築されつつあるので、ＧＭＬコード／モデル、または標準的表示は、自動的に生成される。視覚表示に行われたどのような変更も、同様に動的にＧＭＬモデル上で反映される。従って、作成された線図または視覚表示は、“本物の線図（live diagram）”である。
【０１４４】
図１４は、ソースタブを選択することによって見られ得るような、典型的な標準的表示を説明する。図１５によって示されたように、ＧＭＬコードは、ポータルによってサポートされる言語にコンパイルされる。同様にＧＭコンパイラは、エラーがないかどうかモデルをチェックすると共に、コンパイルされた内容を直接ポータルに配置する。適切なコンパイラを使用することによって、実行可能コードは、ＧＭＬモデルから、あらゆる対象のプラットフォームに対して生成され得る。本実施例の一実装例において、同じモデルが同時に異なるプラットホーム／言語にコンパイルされることができる。
【０１４５】
図７Ｃは、本発明の一実施例による、“iView”を更に詳細に構築するためのステップ７１０を説明する。“iView”構築ステップ７１０は、複数のサブステップ７２２からサブステップ７２８を有する。サブステップ７２２において、データソースが“iView”に加えられる。“GUIMachine”（ＧＭ）は、クライアントが、ポータルシステムランドスケープ（portal system landscape）において、ポータルの接続性の構成によって定義されたアプリケーションに接続することを可能にする。この接続から、所望の“ＲＦＣｓ”、または“ＢＡＰＩｓ”が“iView”に取り込まれることができる。取り込まれた“ＲＦＣｓ”、及び“ＢＡＰＩｓ”は、データソースオブジェクトと言われる。データソースオブジェクトは、アクター４５０に対応する。
【０１４６】
所望の“ＲＦＣｓ”、及び“ＢＡＰＩｓ”は、検索モジュールを使用するか、またはビジネスオブジェクトリポジトリをブラウズすることによって選択される。選択された“ＲＦＣｓ”、及び“ＢＡＰＩｓ”は、作業領域８０６にそれらをドラッグ＆ドロップすることによって“iView”に取り込まれる。図１０Ａは、データソースタスクバーから作業領域への関数モジュール“BAPI_GETLIST”、及び関数モジュール“BAPI_GETDETAIL”の取り込みを説明する。一度、これらのデータソースオブジェクトが作業領域に挿入されれば、それらの固有の名前が“iView”の標準的表示に書き込まれる。データソースオブジェクトの固有の名前は、それらのアドレスと対応する。これらの名前は、ポータルサーバから続いてこれらのビジネス関数を呼び出すために使用される。図１０Ｂは、サブステップ７２２に応答して自動的に生成されるＧＭＬコードを説明する。ＧＭＬコードの全文は、別表（Appendix）Ａとして提供される（本翻訳文では、便宜上、末尾に表１及び表２として示す）。
【０１４７】
一般的に、ＵＩロジックが定義される（ステップ７２４）ことに次いで、ＵＩロジックは、どんなＵＩコンポーネントが実行時間において利用者に提示されるか（例えば、“iView”がグリッド一覧またはリスト一覧にデータを表示するか、または特定のデータセットのために利用者が検索パラメータに入ることができる入力形式を表示するか）を定義すると共に、どのように利用者がコンポーネントと対話できるか（例えば、データ表示が静的であるかどうか、あるいは、データの特定のサブセットに対する検索を開始するか、またはより詳細な情報のために表示された記録を掘り下げることによって、利用者が画面に表示されたデータを操作し得るかどうか）を定義する。同様にＵＩロジックは、どのように情報がポータルアプリケーションから検索されるか、及びデータがクライアントマシン上で表示される前に例えばフィルタ、またはソートオペレータによって操作されるべきであるかどうかを制御する、内在するデータ照会を定義する。
【０１４８】
ＵＩロジックを定義するために、ＵＩコンポーネントオブジェクト、及びオペレータがモデルに加えられる。ＵＩコンポーネント、内在するデータソースオブジェクト（例えば、ＳＡＰ関数）、及びオペレータを含む全ての“iView”エレメントの間の情報の流れが指定される。
【０１４９】
図１１Ａは、ＵＩコンポーネントが“iView”に加えられる画面１１０２を説明する。画面１１０２は、“search form”１１０４、“BAPI_GETLIST”１１０６、“bank list”１１０８、“BAPI_GETDETAIL”１１１０、“bank address form”１１１２、及び“bank detail form”１１１４を有している。“search form”１１０４、インタアクターは、“BAPI_GETLIST”関数を呼び出すために加えられる。照会の結果は、“bank list”グリッドインタアクター１１０８に表示されることになる。利用者が“bank list”グリッド１１０８において何らかの行を選択するとき、“BAPI_GETDETAIL”１１１０は、対応するバンク（bank）キーによって呼び出されることになる。“BAPI_GETDETAIL”１１１０の結果は、“bank address form”１１１２、及び“bank detail form”１１１４に表示されることになる。上述の各々は、特別なタスクを実行するか、または特別なタスクを呼び出すように構成されるアクターである。それらが作業領域へ挿入されるので、それらが実行時間において続いてポータルサーバ−側コードから参照を付けられることができるように、それらの固有の名前は、ＧＭＬコードの形式で標準的表示に加えられる。
【０１５０】
それらの間の関係は、接続１１２２から接続１１３０によって定義される。接続１１２２は、“search form”１１０４の出力ポートを“BAPI_GETLIST”１１０６の入力ポートに接続する。接続１１２４は、“BAPI_GETLIST”の出力ポートを“bank list”１１０８の入力ポートに接続する。接続１１２６は、“bank list”１１０８の出力ポートを“BAPI_GETDETAIL”１１１０の入力ポートに接続する。接続１１２８は、“BAPI_GETDETAIL”の第１の出力ポートを“bank address form”１１１２の入力ポートに接続する。接続１１３０は、“BAPI_GETDETAIL”の第２の出力ポートを“bank detail form”１１１４の入力ポートに接続する。図１１Ｂは、画面１１０２の標準的表示を示す。図１１Ｂと関連付けられたＧＭＬコードは、別表（Appendix）Ｂで提供される（本翻訳文では、便宜上、末尾に表３、及び表４として示す）。
【０１５１】
接続は、データマッピング（data mapping）、データフロー（data flow）、またはデータバインディング（data binding）のためのものであり得る。データマッピングは、ＵＩコンポーネントまたはデータソースオブジェクトから、データソースオブジェクトに対する情報の流れ、例えば接続１１２２を定義する。この場合、情報は、データソースオブジェクトに内在するビジネス関数によって必要とされる入力である。もし“iView”におけるあるエレメントの出力が“iView”における別のエレメントの入力として使用される場合、データマッピングが実行される。
【０１５２】
データフローは、データソースオブジェクトからＵＩコンポーネントに対する情報の流れ、例えば接続１１２４、及び接続１１２８を定義する。データソースオブジェクトに内在するビジネス関数によって返されたデータは、ＵＩコンポーネントに表示される。データソースオブジェクトの出力が表示するためにＵＩコンポーネントに運ばれるとき、データの流れが発生する。例えば、単一のデータソースオブジェクトから複数のＵＩコンポーネントに対するデータの流れが定義されることができる。各出力ポートは、１つ以上のＵＩコンポーネントに接続することができる。ＵＩコンポーネントは、様式一覧（Form View）、リスト一覧（List View）、グリッド一覧（Grid View）、及びＨＴＭＬ一覧（HTML View）を有する。
【０１５３】
データバインディングは、ＵＩコンポーネントから別のＵＩコンポーネントに対する情報の流れを定義する。あるＵＩコンポーネントの出力ポートが別のＵＩコンポーネントの入力ポートと接続されるとき、データバインディングが発生する。この状況において、内在するデータセットは同じである。従って、あるＵＩコンポーネントに表示されたデータに対する変更は、他方のＵＩコンポーネントに影響を及ぼす。例えば、もしあなたの“iView”が、従業員のリスト及びそれらについての詳細を出力する関数を有する場合、あなたは、記録の選択が可能であるグリッド一覧に従業員名のリストを表示することができると共に、その場合に、グリッド一覧を、（ポータルの利用者によって）選択された従業員についての詳細を表示する様式一覧に接続することができる。
【０１５４】
１つ以上のオペレータは、返されたデータをＵＩコンポーネントに表示する前に、返されたデータを操作するためにＵＩロジックに挿入されることができる。例えば、データは、表示される前にフィルタ処理、または分類されることができる。オペレータは、データソースオブジェクトの入力ポート、及び出力ポートに接続される。オペレータは、“Filter”、“Sort”、“Sigma”、“Top”、“Bottom”、及び“Distinct”を有する。これらのデータオペレータは、データオペレータセクション１１４０上で説明される。
【０１５５】
サブステップ７２６において、“iView”のレイアウトは、利用者の好み、または利用者のニーズに従ってカスタマイズされる。“iView”ロジックが構築されるとき、デフォルトの“iView”のレイアウトが提供される。このデフォルトのレイアウトは修正され得ると共に、従って、情報の表示は、特定のニーズに合わせて調整されることができる。“iView”は、サブステップ７２６の後で完成される。図１２は、“iView”のレイアウトをカスタマイズするための画面１２０２を説明する。
【０１５６】
その後、構築された“iView”は、テストされることができる（ステップ７２８）。テストは、作業領域でプレビュータブを選択することによって実行される。図１３は、構築された“iView”の結果をプレビューするための画面１３０２を説明する。図１４は、構築された“iView”のＧＭＬモデル、または標準的表示を説明する。図１５は、図１４のＧＭＬモデルからコンパイルされた実行可能コードを説明する。図１６は、図１５からの実行可能コードを使用するクライアント側に表示されたポータルコンテンツを説明する。
【０１５７】
図１７は、本発明の一実施例による、ＧＭストーリーボードを用いて作成されたＧＭモデルの階層型構成を説明する。モデル１は、従業員データに関する第１のモジュール、及び顧客データに関する第２のモジュールを有する。各モジュールは、１つ以上のページを有する。各ページは、１つ以上の“iView”を有する。各“iView”は、１つ以上のビジネス関数、及びＵＩロジックを有する。例えば、従業員の詳細に関する“iView”２は、入力形式、出力様式、パーソナルデータグリッド、従業員“Getdata”、従業員“Getlist”、従業員“Changepassword”を有する。
【０１５８】
上記の記述は、当業者が、特定用途とその要件に関する状況において提供された発明を作り上げると共に使用することを可能にするために提示された。好ましい実施例に対する様々な変更は、当業者にとって明白であると共に、ここに定義された一般原則は、他の実施例に適用されることができる。従って、本発明は、示されると共に説明された特別な実施例に制限されることを意図していないが、しかしここに発表された原理、及び新規な特徴に沿って最も広い範囲を与えられるべきである。
【０１５９】
【表１】
2006510133.tif 000003
【０１６０】
【表２】
2006510133.tif 000004
【０１６１】
【表３】
2006510133.tif 000005
【０１６２】
【表４】
2006510133.tif 000006
【図面の簡単な説明】
【０１６３】
【図１】対話型コンピュータシステムを概略的に説明する図である。
【図２】本発明の一実施例による利用者インターフェースモデルを概略的に説明する図である。
【図３Ａ】本発明の一実施例による利用者インターフェースモデル化システムを概略的に説明する図である。
【図３Ｂ】本発明の一実施例による、複数の視覚表示、標準的表示、及び利用者インターフェースコードの間の関係を説明する図である。
【図３Ｃ】本発明の一実施例による、パターンパラダイムに基づくモデル化システムを説明する図である。
【図３Ｄ】本発明の一実施例による、パターンパラダイムに基づくモデル化システムを説明する図である。
【図４】本発明の一実施例による、ビジュアルモデル化言語の象徴的な構成を説明する図である。
【図５】本発明の一実施例によるモデル化システムが実施されることができる企業のポータルシステムを説明する図である。
【図６】本発明の一実施例による、利用者インターフェースのモデルを設計する方法を説明するフローチャートである。
【図７Ａ】本発明の一実施例による、モデル化システムの標準的表示のモデル化階層を説明する図である。
【図７Ｂ】本発明の一実施例による、企業のポータル環境において使用するための利用者インターフェースを設計する方法を説明するフローチャートである。
【図７Ｃ】本発明の一実施例による、ポータルプレゼンテーションコンポーネントを構築する方法を説明するフローチャートである。
【図７Ｄ】本発明の一実施例による、データソース階層、ＵＩロジック、ＵＩレイアウトを有するポータルプレゼンテーションコンポーネントを説明する図である。
【図７Ｅ】本発明の一実施例による、複数のプレゼンテーションコンポーネントを有するポータルページを説明する図である。
【図８】本発明の一実施例による“GUIMachine”が起動されるときに現れる画面を説明する図である。
【図９】本発明の一実施例による、利用者インターフェースの作成を開始するために新しいモデルを開くための画面を説明する図である。
【図１０Ａ】本発明の一実施例による、“GUIMachine”の作業領域に挿入されたデータソースオブジェクトを説明する図である。
【図１０Ｂ】図１０Ａの標準的表示を説明する図である。
【図１１Ａ】本発明の一実施例による、“iView”に対するＵＩロジックの定義を説明する図である。
【図１１Ｂ】図１１Ａの標準的表示を説明する図である。
【図１２】本発明の一実施例による、“iView”のレイアウトをカスタマイズするために使用される画面を説明する図である。
【図１３】本発明の一実施例による、“iView”によって取得された結果をプレビューするために使用される画面を説明する図である。
【図１４】本発明の一実施例による、構築された“iView”の標準的表示を表示するための画面を説明する図である。
【図１５】本発明の一実施例による、“iView”の標準的表示からコンパイルされた実行可能コードを表示するための画面を説明する図である。
【図１６】本発明の一実施例による、図１５の実行可能コードを用いて表示されるポータルコンテンツを説明する図である。
【図１７】本発明の一実施例による、“GUIMachine”を用いて作成されたモデルの階層型構成を説明する図である。
【符号の説明】
【０１６４】
１００    対話型コンピュータシステム（サーバ）
１１０    バックエンドサブシステム
１１１    アプリケーションソフトウェア
１２０    フロントエンドサブシステム
１２１    利用者インターフェースソフトウェア
１２２，１２２ａ，１２２ｂ，１２２ｃ    利用者インターフェースのコンテキスト
１３０    アプリケーションコントラクト（application contract）
２１１    設計推敲処理
２１０    利用者とアプリケーションの要求
２２０    利用者インターフェースモデル
２２１ａ，２２１ｂ，２２１ｃ    コード生成処理
２３０ａ，２３０ｂ，２３０ｃ    利用者インターフェースコード
２３１ａ    利用者インターフェースのコンテキスト
２３１ｂ    利用者インターフェースのコンテキスト
２３１ｃ    利用者インターフェースのコンテキスト
３００    利用者インターフェースモデル化システム（user interface modeling system：ＵＩＭＳ）
３１０    利用者インターフェースモデルの視覚表示
３１１    ＵＩＭＳエディタ
３２０    利用者インターフェースモデルの機械読取可能な標準的表示（machine-readable canonic representation）
３２１    ＵＴＭＳリポジトリ
３３０    利用者インターフェースコード
３３１    ＵＩＭＳキット
３４０    二次ツール
３５０    １つの標準的表示
３５２，３５４    視覚表示
３５６    遺産的情報源（legacy sources）
３５８，３６０，３６２    利用者インターフェースコード
３６４    他の入力
４１０    パッケージ
４２０    情報サービスの線図
４２１    シングルトン（singleton）
４２２    リスト
４２３    バッグ
４２４    クラスター
４２５    ツリー構造
４２６    グラフ
４３０    シナリオ
４３１    トランジションの矢印
４３２    インボケーション（invocation）
４３３    コンディションコネクタ
４３４    コンテニュエイションコネクタ
４３５    オプションコネクタ
４３６    レピティションコネクタ
４３７    イニシャル状態
４３８    ターミナル状態
４４０    シーン
４４１    非同期メッセージ
４４２    同期メッセージ
４４３    コンディションコネクタ
４４４    コンテニュエイションコネクタ
４４５    入力ポート
４４６    出力ポート
４４７    双方向ポート
４４８    フォーク／ジョインコネクタ
４５０    アクター
４５１    コンテキストセレクタ
４５２    ネガティブコンテキストセレクタ
４５３    リモートコンテキストセレクタ
４５４    ゼネラリゼイションの矢印
４６１    ノート
４６２    プロパティ
４６３    ブラケット
５０２    ポータル
５０４    クライアント
５０６    情報源
５０８    統一サーバ
５１０    ポータルサーバ
５１２    知識管理部
５１４    外部のアプリケーション
５１６    内部のアプリケーション
５１８    外部の文書ソース
５２０    内部の文書ソース
５２２    ウェブ
５３２    ウェブサーバ
５３４    ポータルコンテンツディレクトリ（portal content directory：ＰＣＤ）
６００    利用者インターフェースモデルを作成するための処理
７０１    インフォメーションモデル階層
７０３    インタラクションモデル階層
７０５    プレゼンテーションモデル階層
７５０    “iView”
７５２    データソース階層
７５４    ＵＩロジック
７５６    ＵＩレイアウト
７６０    ページ
７６２    第１の“iView”
７６４    第２の“iView”
７６６    イベンティング（eventing）
７６８    レイアウト
８００    タスクパネル（task panel）
８０２    画面
８０６    作業領域
９０２    画面
１１０２    画面
１１０４    “search form”
１１０６    “BAPI_GETLIST”
１１０８    “bank list”
１１１０    “BAPI_GETDETAIL”
１１１２    “bank address form”
１１１４    “bank detail form”
１１２２，１１２４，１１２６，１１２８，１１３０    接続
１３０２    画面
【図１】
2006510133.tif 000007
【図２】
2006510133.tif 000008
【図３Ａ】
2006510133.tif 000009
【図３Ｂ】
2006510133.tif 000010
【図３Ｃ】
2006510133.tif 000011
【図３Ｄ】
2006510133.tif 000012
【図４】
2006510133.tif 000013
【図５】
2006510133.tif 000014
【図６】
2006510133.tif 000015
【図７Ａ】
2006510133.tif 000016
【図７Ｂ】
2006510133.tif 000017
【図７Ｃ】
2006510133.tif 000018
【図７Ｄ】
2006510133.tif 000019
【図７Ｅ】
2006510133.tif 000020
【図８】
2006510133.tif 000021
【図９】
2006510133.tif 000022
2006510133.tif 000023
2006510133.tif 000024
2006510133.tif 000025
2006510133.tif 000026
【図１２】
2006510133.tif 000027
【図１３】
2006510133.tif 000028
【図１４】
2006510133.tif 000029
【図１５】
2006510133.tif 000030
【図１６】
2006510133.tif 000031
【図１７】
2006510133.tif 000032
【国際調査報告】
2006510133.tif 000033
2006510133.tif 000034
2006510133.tif 000035