JP4471250B2 - アプリケーションフレームワーク用アーキテクチャ - Google Patents

Description

【０００１】
（技術分野）
本発明は、コンポーネントモデルに基づいて、いろいろなアプリケーションに適合できるアプリケーションフレームワークに関するものである。
【０００２】
（発明の背景）
治療におけるような特定のアプリケーション領域において、例えば病院で実行される業務は、部門をまたがっており、各人が異なる役割を持っている数人を必要とする。これらの調整されたアクティビティは、一般的には"ワークフロー"と呼ばれ、例としては、患者が病院"システム"を通じて移動するときに生じる処理である。第１のステップは"入院"であり、その後に検査、それから詳細な検査およびイメージングが後に続くこともある。これには、他の試験、あるいは治療のための勧告を有する情報の精査が続く。この企業規模のワークフローにおいて処理をするいろいろなツールがある。例えば、この処理のイメージング部分において、イメージング（スキャナコンソール）、イメージ精査および治療システムに対して必要とされる特定のソフトウェアツールがある。したがって、この企業規模のワークフローにおいて処理をするソフトウェアツールを、簡単に統合できることが望ましい。
【０００３】
したがって、単一アプリケーションフレームワークに対する要求がある。このフレームワークは、異なるソースからのコンポーネントをいろいろなコヒーレント"アプリケーション"を生成するように混合できる方法を規定すべきである。この方式は、フレームワークがこれらのコンポーネントの使用に欠くことができないことを意味していない。すなわち、個別のコンポーネントがフレームワークの範囲外で使用できることが望ましい（例えば、フレームワークのサービスを必要としない簡単なアプリケーションはあるが、このアプリケーションは、このアーキテクチャのために生成されるコンポーネントのいくつかをなお使用できるべきである）。
【０００４】
アプリケーションが"複合アプリケーション"および複数のユーザに及ぶアプリケーション（すなわち、企業規模のワークフロー）の両方に関する場合、所与の"アプリケーション"は、このメインアプリケーション内にサブワークフローを有するメインワークフローによって規定されてもよいことに注目してもよい。ここでの目的は単一の"アプリケーション"だけを考察することにある。すなわち、有用な相違は、（フレームワークによってサポートされるべき）アプリケーション内の"ワークフロー"があることと、例えば、病院内に、より高いレベルの"ワークフロー"がさらにあることを考察することにある。
【０００５】
特定のワークフローのユーザは、異なるインタフェースあるいはパラダイムを有する異なるベンダーからのコンポーネントを使用しなければならない。したがって、ユーザは、新しい手順を再学習しなけれならず、エラーの発生や非効率につながる。典型的なアプリケーションでは、ユーザには、データ、および同時にこのデータで実行される"プロトコル"あるいはタスクのセットのためのセレクタが提供される。企業規模のワークフローのより強い統合によって、このモデルを、データおよびプロトコルが外部で（例えば、ワークリストにおいて）指定できるように生成すべきである。
【０００６】
（発明の概要）
したがって、本発明は、アプリケーションが、ユーザに可視又は不可視の複数のレベルの機能性の周りに形成されるように、アプリケーションのためのフレームワークを提供することを目的とする。機能性の３つのレベルが、下記のように提供される。
【０００７】
フレームワークは、選択されたワークフローによってユーザをガイドする機能性も提供する。
【０００８】
第１のレベルはプロセスである。これは、データのセットと適用される処理ステップの定義とを要約するので、"プロトコル"と呼ぶこともできる。プロセスインスタンスの例は、２Ｄプロトコルにおいて観察できる調査である。このレベルはフレームワークによって管理される。すなわち、同時にアクティブである複数の"プロセス"があり得る（例えば、ユーザは１つのプロセスに対して１つの調査を精査し、ある点で異なる患者からの調査の精査に切り換えることができる。すなわち、フレームワークは、アクティブと成り得る異なるプロセスインスタンスを管理する）。簡単なケースにおいて、システムは、このレベルの選択を隠し、単一のプロセスをユーザに提供する。プロセスは、"アクティビティ"のセットからなり、アクティビティのプロパティおよび外部ルールに基づいて１つのアクティビティから次のアクティビティへの自動制御フローの可能性を有する。
【０００９】
第２のレベルはサブプロセスである。これは階層において次のレベルとしてリスト化されるが、実際はアクティビティのグルーピングそのものである。このアクティビティの集合体は、再使用に有用であり、ナビゲーションおよび共有ツールを有するアクティビティのグルーピングに対して好都合である。
【００１０】
通常、プロセスは、予めプログラム化されたロジックに基づかずに、エンドユーザがアクティビティを見えるように、アクティビティの順序を切り換える柔軟性を有することを必要とする場合もある。したがって、サブプロセスレベルは、アクティビティ間をナビゲートし、プロセスにおける現在の位置を示すユーザインタフェースを提供する。
【００１１】
第３のレベルはアクティビティである。これはフレームワークによって明確にサポートされる階層の最低レベルである（必要とされるならば、アクティビティはより深いモデルを内部で提供できる）。アクティビティは、任意の処理の結果として変更され、従ってプロセス内のアクティビティの順序付けを実行するために使用できる外部プロパティを有する。アクティビティをプロセスに（実行時間に）ダイナミックに加えるかあるいは取り除くことができるので、例えば、プロセスは、初期のアクティビティの結果に基づいて、異なる機能性を提供できる。各アクティビティは、別個のコンポーネントとして実行される。
【００１２】
さらに、"プロセス定義"は、"プログラム"、すなわちプロセスを含む処理ステップである。これは、アクティビティ、ツールおよび制御ロジックを要求プロセスに対して具体化できるように、プロセスが開始される前に、固定記憶装置から引き出されねばならない。"プロセスインスタンス"は、プロセスの実行バージョン、すなわち、プロセス定義と実行中に使用されるデータおよび状態情報を示している。フレームワークは、複数のプロセスインスタンスをサポートでき、ユーザにとって、これは単に、異なるデータおよび処理を使用でき、フォーグラウンドタスクに切り換えることができる異なるコンテキストのように見える。
【００１３】
フレームワークが異なるソースからのアクティビティの再使用をサポートするために、ユーザインタフェースモデルを規定することが望ましい。ここで、行われた方式は、"ツール"に対するサポートの追加によって、上記のレベルの各々のＵＩの領域への直接マッピングである。ＵＩの最大部は現アクティビティに対して割り当てられる。すなわち、これはここでは"ワークエリア"と呼ばれる。階層における２つのレベル（"プロセス選択"および"サブプロセスナビゲーション"）およびツールサポートは、ＵＩに割り当てられた３つの別個の制御エリアである。このモデルの詳細は下記の副節にある。
【００１４】
このモデルは、アクティビティに関連した"ツール"のモデルを明確にサポートする。ツールに対するサポートは、どんなＵＩ機構がツールに対してサポートされる必要があるかという問題を提起する。最も簡単なモデルとして、ＵＩの単一領域が、任意の方法で自由にこれを使用できるツールとともにあることを仮定する。ビューイングワンド（ViewingWand)のようなアプリケーションは、付加的ツールエリア、（順に特定パラメータ設定に対するポップアップウインドウを有する）アイコンボタンを有する第２のツールエリアに対するサポートも必要とする。したがって、フレームワークは、複数のツールエリアが有り得るより一般的なモデルをサポートすべきである。しかしながら、第１のインプリメンテーションは単一のツールエリアに固守するが、複数のツールエリアに対する後のサポートを妨げないことが示唆される（本願はこれを含むように更新されることが予想される）。
【００１５】
（好ましい実施例の詳細な説明）
図１を参照すると、このフレームワークを使用する"アプリケーション"に関連するデフォルトのユーザインタフェースの概略が示されている。このインタフェースは、４つのエリア、すなわちワークエリア、プロセスセレクタ、サブプロセスナビゲータおよびツールエリアを規定する。デフォルトの構成は、右側にワークエリアを有し、左側に他の３つの領域を単一列に積み重ねている。
【００１６】
このワークエリアは、一般的には、画像のディスプレイ、あるいはアクティビティが必要とする任意の補助的なユーザインタフェースに使用される。現アクティビティはワークエリアを所有する。フレームワークはワークエリアの所有権を調停する。ワークエリアの内容はアクティビティ間で保持されてもよい。すなわち、エリアの内容の記述は、"共有データコンテキスト"に記憶されたプロパティを使用して共有できる。
【００１７】
このエリアの内容は"任意"であるけれども、アクティビティは内容についての情報を共有する必要がある可能性がある。例えば、表示画像のある操作を可能にするアクティビティは、領域におけるウィンドウのレイアウト、このレイアウト内に表示するために使用されるパイプライン、表示されているデータのパラメータ等を決定できる必要がある。この情報は"共有データコンテキスト"の一部となる。
【００１８】
共有ツールエリアでは、アクティビティはワークエリアを"所有する"だけであるけれども、アクティビティは、所定のツールの存在に興味があることをフレームワークに通知できる。各アクティビティはいくつかのツールセットを使用でき、これらのセットはオーバーラップしてもよい。ツールエリアはツールマネージャによって所有される。すなわち、これは、個別のツールに対するコンテナの役目を果たすコンポーネントそれ自体である。ツールマネージャは特有のＵＩを有する。すなわち、例えば、ツールマネージャは、タブカードモデルを使用して個別のツールを表示できる。ツールマネージャはコンポーネントそれ自体であるので、ツールマネージャは異なるマネージャと取り換えることができる。各ツールは、単に、コンテナ（例えばタブカード）によって各ツールに手渡された領域にＵＩを表示するユーザインタフェースである。ツールは、ユーザ動作に基づいてインタラクティブコンテキストにプロパティを設定することによって、アクティビティと対話する。その結果、現アクティビティはそれ自体のふるまいを更新するためにこれらのプロパティを使用できるようになる。
【００１９】
図２は、現アクティビティがボリュームレンダリングタスクである場合、このエリアに提供されうるツールの例である。本例では、ツールマネージャはタブカードコンテナである。
【００２０】
本モデルの最小エンティティは、"アクティビティ"である。各アクティビティは、アクティブである場合に、"ワークエリア"の所有権を有する。アクティビティは、共通ツールに興味を示すこともでき、そのとき、フレームワークがそれを"ツール"エリアに入れるように構成する。これらのツールは、フレームワークによって仲介されるユーザ入力を提供する。例えば、ツール出力はインタラクティブコンテキストにおけるプロパティに配置され、アクティビティはこれらのプロパティの変化を通知される。
【００２１】
アクティビティの内容は任意であるが、１つの例はボリュームレンダリングコンポーネントであってもよい。このコンポーネントは、"レンダセレクタ"、"ライトコントロール"、および"クリッピングツール"のようなツールに興味を示し、そうすると、フレームワークが（上記に示すように）ツールエリアにインストールするように構成する。共通ツールに加えて、アクティビティは、ワークエリアからユーザ入力を受信できる（例えば、ウィンドウＷ／Ｌはマウスの移動を介して変更可能であってもよい）。ワークエリアを所有するアクティビティは、いかなる目的に対してもこのエリアからマウスイベントを使用する自由を有し、もちろんこのエリアの任意の種類のユーザインタフェースを表示できる。
【００２２】
アクティビティはいかなる目的に対してもワークエリア内でマウスを自由に使用できるが、マウスイベントが（インタラクティブコンテキストのプロパティとして）レポートされるでことが好ましい。このように、現ツールがマウスイベントを使用することもできる（例えば、Ｗ／Ｌツールはマウスイベントを使用して現Ｗ／Ｌ値を更新し、現Ｗ／Ｌ値は、インタラクティブコンテキストのプロパティに折り返しレポートされる）。
【００２３】
階層におけるサブプロセスは、実際はプロセスにおけるアクティビティによるナビゲーションを助けるためだけにある。このエリアは、コンポーネントによっても所有されるので、異なるＵＩモデルは適切なコンポーネントを供給することによって実行できる。このレベルに対するいくつかの可能な代替の表示がある。すなわち、
ａ）現アクティビティ、およびナビゲーションのための次／前／最終ボタンの名前のディスプレイ（対応する動作が許可されない場合、多分非アクティブである）。
ｂ）アクティビティ名を有し、ネットワークダイアグラムで表されたフロービュー（非常に大きくウィンドウにはめ込むことができない場合、多分スクロールされる）。アクティビティボックスの選択は、現アクティビティをこのアクティビティに切り換える（さらに、いくつかの遷移は不許可にされてもよく、これはグレイ表示によって示すことができる）。図３は第１のＵＩの例を示す。
【００２４】
図１に戻って参照すると、プロセスエリアはコンポーネントでもある。このエリアは適切なプロセスセレクタコンポーネントを供給することによってカスタマイズ可能である。このエリアは下記、すなわち、データセレクタを呼び出すボタン（マッチングプロセス定義の選択を含む）；プロセスインスタンスを切り換える機構（１つ以上がアクティブである場合）；および現データセットについての情報（例えば、患者名）を表示する。
【００２５】
データセレクタは、データソースのブラウジング（例えば、１つ以上ある場合、ソースの中から選択）、次に患者／調査／シリーズ等の選択を可能にする。この時点で、ユーザには、このデータで呼び出すことができるプロセス定義（基本的にはプロトコル）の選択が示される。
【００２６】
この例のセレクタが唯一取り得るわけではない。他のモデルは、"データセレクタ"が単にワークリスト（外部ワークフローエンジンから得られる）を表示し、それから、ユーザが処理する次の項目を選択できる。これは、使用するデータセットおよび使用するプロセス定義を含む。
【００２７】
セレクタの他の例は反対のモデルを使用する例である。すなわち、ユーザは、プロセス定義（プロトコル）を選択し、それから、候補データセットが選択のために表示される。これの例は、ユーザが"心臓"プロトコルを選択し、それからこのプロトコルに適しているデータセットが示される場合である。
【００２８】
所与のプロセスセレクタは、このエリアで表示される情報のレベルの制御も可能にしてもよい。例えば、
状態情報だけ‐ディスプレイは、現プロセス（例えば、その型式）および現データセット（例えば、患者名）についての情報を示すだけである。
データセットを（データベースから）選択するユーザインタフェース、及びそのデータを見るために使用できるプロセス定義のリスト。
編集可能プロセスリスト。これは、ユーザ（多分、上級エンドユーザあるいはアドミニストレータ）が、新しいあるいはカスタマイズされたプロセス定義を組み立てる必要がある場合である。この場合のＵＩは、予め規定されたプロセス定義のリスト；および各規定されたプロセスに対して、プロセスを構成するサブプロセス；および各サブプロセスに対して、プロセスが含むアクティビティを示してもよい。ＵＩは、新しいプロセス定義のコピー、編集および形成を可能にする。プロセス（例えば、現在のサブセット）をフィルタリングする機構も必要である。アクティビティの順序付けに対するロジックをプログラム化できる、他のＵＩも必要である。
【００２９】
インタフェースをカスタマイズできるようにしてもよい。前述されるように、特定のアプリケーションは、デフォルトのユーザインタフェースのある部分が表示されないよう要求するかもしれない可能性がある。したがって、フレームワークは、プロセスおよびサブプロセスビューア（ナビゲータ）に対して隠し、およびプログラム可能レベルの選択をサポートすべきある。デフォルトは、プロセス、サブプロセスおよび共通ツールエリアをスクリーンの左側で表示することである。これらのエリアの相対サイズは、構造化可能であるべきである。フレームワークによっても、これらのエリアはエッジ（最上部、最下部、左および右）のいずれかに配置できるべきである。これらのエリアを浮動させるよう考慮すべきである（マイクロソフトビジュアルスタジオのツールエリアのように"ドック可能"であるように）。
【００３０】
前述のように、３つのエリア（プロセス、サブプロセスおよびツール）の内容はそれ自体のコンポーネントであるので、これらのエリアのルックおよび機能性はこれらの制御の代替のバージョンを提供することによっても詳細にカスタマイズできる。
【００３１】
完全に柔軟であるために、プロセス、サブプロセスおよび共通ツールエリアは非表示にできるべきである。このモードで実行される場合、ユーザインタフェースは外部に提供されねばならない。すなわち等価入力は、フレームワークによって提供されるＡＰＩと結合している実行時を通して提供されねばならない。このモードはフレームワークをなお使用する。フレームワークなしでアクティビティ（すなわち、これらのコンポーネント）を使用することもでき、その場合、プロセスインスタンスが全くなく（したがって、共有データが全然ない）、コンテナは適切な入力（ユーザからのデータセットおよび入力）を直接提供しなければならない。
【００３２】
上記の検討は、ユーザインタフェースがデスクトップ環境にフィットする方法についての説明を全然行っていない。これを実行する２つ以上の可能な方法がある。すなわち、ＵＩを、インターネットエクスプローラのようなウェブブラウザに埋め込むか、あるいはアクティブエックス（ActiveX）制御を処理するある他のコンテナによってホストすることができる。ＩＥ４．０および次のウィンドウズおよびＮＴのリリースの場合、この機能は、システムのデスクトップおよび他のツールの多くに拡張されるので、システム設計者にとって多数の選択がある。
【００３３】
アーキテクチャはアクティブエックスモデルに基づいている。これは、アクティブエックスモデルがマイクロソフトオペレーティングシステムを実行するシステムに限定されることを意味していない。アクティブエックスはＮＴおよびウィンドウズ９５でサポートされるが、マッキントッシュおよびいろいろのＵＮＩＸバージョンでも早めにサポートされる。もちろん、これらのアーキテクチャのいずれかのフレームワークの使用は、そこで必要とされる個別のコンポーネントがこのアーキテクチャに対しても形成される必要があることを意味する。
【００３４】
アクティブエックスモデルの使用は、コンポーネントの実行のための言語も示していない。すなわち、アクティブエックス制御を生成できる任意の言語を使用できる（これは現在はＶＣ＋＋、ＶＢ５．０およびＪＡＶＡを含む）。
【００３５】
前の節ではユーザインタフェースを論議したが、その内訳説明は、どのように基本的なコンポーネントが構造化されるべきであるかも示している。
【００３６】
図４を参照すると、アーキテクチャの概略が示され、下記の論議はコンポーネントの各々をより詳細に説明している。
【００３７】
フレームワークコンポーネントは、アーキテクチャの中心となる。フレームワークコンポーネントはアクティブエックスコンポーネントそのものであるが（そのため、他のコンテナにおいてホストにされる）、フレームワークコンポーネントは他のコンポーネントのためのコンテナとして機能する。このコンポーネントは、全ＵＩ、すなわちワークエリア及びプロセス／サブプロセス／共通ツールのエリアを包含する。このコンポーネントは、（上記ＵＩ節に関して説明したように）エリアのカスタム化を可能にする特性を有する。このコンポーネントは、プロセス定義、サブプロセス記述およびアクティビティについての情報のデータベース（ライブラリ）にインタフェースするモジュールを含んでいる。このモジュールは、プロセスセレクタ／エディタ（別個のコンポーネント）およびプロセス定義（アクティビティおよびアクティビティ間の順序付けのためのロジックのシーケンス）の記憶および検索をサポートしている。
【００３８】
このモジュールは、アクティビティの順序付けを管理するモジュールを含んでいる。このモジュールはプロパティのセットを調べる。これらのプロパティの変化は、若干のロジックの評価を生じ、次に次の動作を決定する。例えば次のアクティビティに移るかあるいはプログラムされたアクティビティの変更さえも引き起こす。このアクティビティは、順序付けのためのモジュールとだけ相互作用するが、内部的には、例えば、外部ワークフローエンジンの使用など、外部インプリメンテーションに依存し得る。サブプロセスナビゲータは、この機能性を利用する。
【００３９】
このサブプロセスナビゲータは、共通データコンテキストを管理するモジュールを含んでいる。これは、順序付けのために必要とされる情報から論理的に分離される（情報は異なって実行されてもよい）。現コンテキストの情報は、現データセットのようなものおよび一時的情報も含んでいる。一時的情報は、スクリーンレイアウト、使用中のＰｒＳパイプライン等のようなものを含んでいる。フレームワークは、特定の情報を必要とするべきでないし、また特定の属性の存在に頼るべきでもない。しかしながら、共働するアクティビティは情報を共用できるので、データが現共通データコンテキストで見つけだされる方法についての規約があることは重要である。このアイディアは、ＤＩＣＯＭオブジェクトモデルが取り入れらるので、アクティビティが、現共通データコンテキストの患者、調査、シリーズあるいは画像のオブジェクトを探すということにある。フレームワークはこれらのオブジェクトのプロパティを保持する。規約によって、１つのプロパティは、データベースの対応するレコードのポインタとなる（下記のＯＬＥ‐ＤＢ節参照）。他の候補プロパティはこれらのオブジェクトからのデータをロードした保存器オブジェクトの外部ハンドルである。現共通データコンテキストのこれらのオブジェクトは、（アクティビティがプロパティとして明確にそれを追加しない限り）それ自体でデータベースに記憶された情報を保持しない。すなわち、アクティビティがこの情報に対するデータソースに直接進むと予想される。
【００４０】
プロセスセレクタは、アクティブエックス制御である。このアクティブエックス制御はＵＩのプロセス領域を所有する。この領域内で、（ＵＩ節で前述されたように）アクティブエックス制御は所定の情報を表示し、データセレクタを呼び出すこともできる。使用される特定のデータセレクタは構造化可能である。
【００４１】
データセレクタは、ユーザがデータセットおよび使用されるプロセス定義を選択できるクラスのコンポーネントである。ＵＩ節は、このコンポーネントのために使用できるいくつかの異なるモデルを前述した。
【００４２】
このクラスの１つの例は、ユーザが読み出すべき次のものを選択できるようにするワークリストを示すコンポーネントである。項目の選択によって、中央ワークフローエンジンは、この状態を反映するように更新される（それで、他のユーザは同時に同じ調査を読めない）。このクラスの他の例は、（例えばＯＬＥ‐ＤＢエニュメレータからの）データソースの選択、次に、一致するプロセス定義の選択とともに患者、調査、シリーズの選択を可能にするより通常的なモデルである。
【００４３】
一旦データセットおよびプロセスが選択されると、データセットは、新しい共有コンテキストの基礎を形成し、このプロセスは、具体化され、次にサブプロセスエリアでナビゲートされるアクティビティを規定する。
【００４４】
サブプロセスナビゲータコンポーネントは、現プロセスのアクティビティをナビゲートするために使用できるＵＩを表示する役割を果たす。このコンポーネントはスクリーン上に領域を与えられる（構造化可能）。それはナビゲーションを実際に実行するフレームワークのサービスを使用する。
【００４５】
ツールコンテナコンポーネントは、特定のアクティビティが"現"である間、アクティブであるツールのセットを管理する。ツールコンテナはこれらのツール間をナビゲートする手段を提供する。例えば、このコンテナはタブカードモデルを使用してもよい。
【００４６】
アクティビティはツールのクラスのサービスを要求する。したがって、"ウィンドウ幅およびレベル調整"を提供するツールが有り得る。フレームワークはこのようなマッピングのレジストリを有し、特定のアクティビティが具体化される場合、フレームワークは、これらのクラスにその関与を登録し、それにより、フレームワークは、そのアクティビティが現行のものである場合に、表示するようにする。
【００４７】
フレームワークはプロセスをサポートするが、任意の作業が、フレームワークが含むアクティビティによって実際に実行される。アクティビティとして発生し得るコンポーネントの型式のいくつかの例は、下記を含む。
現共有データコンテキストにおける調査の基本的な２Ｄビューイングを行うコンポーネント。この機能性は、レイアウト制御、ズームおよびパン、映画等を含み、これらの制御に対するＵＩはツールを介して提供される。
ユーザが、注釈された画像を含むであろうレポートを記録できるコンポーネント。レポートの完成はユーザによって指示され、次に、遠隔ワークフローエンジンに現作業項目が完成したことの信号を出す。これは、次のアクティビティもトリガし、この場合、次のアクティビティは、第１のアクティビティ、すなわち表示ワークリストからの新しい作業項目の選択に単に戻されてもよい。
【００４８】
アクティビティであるコンポーネントの寿命時間はフレームワークによって制御される。フレームワークは、含んでいるプロセスが開始される場合、アクティビティを具体化し、プロセスが完了する場合、アクティビティを壊す。アクティビティが作成されると、アクティビティは共有データコンテキストへのアクセスを与えられる。フレームワークは"現"アクティビティの明確なモデルも有する。すなわち、アクティビティが"現"となる場合、アクティビティはワークエリアの所有権を得ることができる。アクティビティは、共有データコンテキストの属性（例えば、そこのオブジェクトのプロパティ）を設定し、得ることができる。このアクティビティは制御エリアの任意の属性も得て、設定できる。すなわち、この属性のセットはアクティビティの順序付けを制御する。
【００４９】
現共有データコンテキストの変化を通知するために使用される機構は、ＯＬＥ接続モデルに基づいてもよい。どんな場合でも、この機構はコンテキストの変化についてコンポーネントへの通知をサポートする。
【００５０】
ＯＬＥ‐ＤＢを、全データソースにアクセスする共通標準として使用する。データモデルは、ＤＩＣＯＭオブジェクトモデルに基づいている。フレームワークはこれらのアプリケーションを形成するために使用されるので、フレームワークはこれらと同じ規約を使用する。これは、データソースが、ＯＬＥ‐ＤＢを介して提供されるデータソースのインタフェースに対して、フレームワークの外部にあるままであることを意味する。
【００５１】
このフレームワークは、プロセスによって現在使用されるデータを含む現共有データコンテキストのモデルを提供する。このデータは、フレームワーク内に実際には記憶されない。すなわち、むしろフレームワークは、任意のプロパティを有することができるオブジェクトのセットを保有する。これらのオブジェクトは、ＤＩＣＯＭオブジェクトモデルを反映するある階層に結合される（これはデータ選択サービスを提供するコンポーネントによって作成される）。各オブジェクトのプロパティは、データソースのリファレンスを記憶するために使用される（多分、関連行識別子を有するＯＬＥ‐ＤＢ）。アクティビティは、アクティビティにわたって共有されるべきである情報を記憶するためにプロパティも使用する‐例えば、これらのオブジェクトに関連するピクセルデータのコピーを有する保存器におけるラスタの外部処理など。フレームワークは、プロパティの変化の通知をサポートする。
【００５２】
共有データに関連した他のサービスは、ＯＬＥ‐ＤＢを介して提供される（例えば、データのキャッシイング、トランザクション、変更の通知等）。アクティビティはこれらのサービスを直接に利用できる。
【００５３】
アクティビティは単一の共有データコンテキストだけを調べるが、フレームワークは、各々が異なるプロセスインスタンスの一部である（したがって異なるアクティビティおよびツールのセットを有する）複数のコンテキストを保持できる。このサポートは個別のアクティビティおよびツールから隠される。
【００５４】
このモデルは、データフローモデルよりもむしろ現データセットを含む、共有データコンテキストに基づいている。しかしながら、これは、データが一方のアクティビティから次のアクティビティに流れるモデルにマッピングできる。これは、現データコンテキストに入れられる１つのアクティビティの結果を有する（このアクティビティへの入力を取り換えない）ことによって実行できる。例えば、アクティビティがデータセットをとり入れ、それをフィルタリングする場合、出力それ自体は、現共有データコンテキストに単に生じる新しいデータセットでもよい。もちろん、この結果はフレームワークに明確に記憶される必要もないし、またフレームワークに明確に属している必要もない。すなわち、共有データコンテキストに追加された情報は、単に（保存器において）生成ラスタの処理であってもよい。
【００５５】
プロセスの目的は、１つのアクティビティから次のアクティビティに案内するロジックをシステムに埋め込むことにある。したがって、各アクティビティは、（通常ユーザ入力に基づいて）いくつかのタスクを実行し、それから共有データに対するいくつかの変更を行う。制御フローのために使用できる（これは共有データコンテキストとは別個である）１つあるいはそれ以上の属性も生成する。フレームワークは、これらの制御属性が変更されて他の属性が実行されるべきであることを示すかどうかを決定する場合は、常に、これらの制御属性を調べる。この決定は、これらの制御属性を調べる若干のプログラム可能なロジックによって行われる。前述のように、これはフレームワークであるいは多分（例えば、ワークフローエンジンで）さらに外部で実行できる。
【００５６】
フローのユーザ制御が提供される。デフォルトのふるまいは、予めプログラム化ロジックによって順序付けされるアクティビティのためのものであるが、ある場合には、プロセスのアクティビティ間で前後にジャンプできることがユーザに役立つ。これはユーザインタフェースのサブプロセスエリアに提供されたナビゲーションＵＩを使用して実行される。しかしながら、プロセスの全てのアクティビティは、所与の時間で実行可能でなくてもよい（例えば、いくつかは、スキップされたアクティビティによって通常生成される付加的情報を必要とするかもしれない）。フレームワークは、このような遷移を排除することによって、あるいは選択アクティビティをアクティブにするが非作動状態にすることによって、これを処理しなければならない。
【００５７】
図５（ａ）および（ｂ）を参照すると、ビューイングおよびリーディングアプリケーションインプリメンテーションが示されている。この構成では、プロダクトはウェブブラウザによってホストされる。最も簡単なレベルで、機能性は単に２Ｄビューアであり、見るべきシリーズは別個に指定される（例えば、ウェブページに埋め込まれた形式あるいは他の制御を使用して）。したがって、この入力は、見るデータセットおよびそれからデータが得られるべきＤＩＣＯＭサーバの位置に対する仕様である。
【００５８】
ページのイメージング部は単に矩形領域である。設計者は、フレームワークの残りなしで簡単な２Ｄビューイングコンポーネントを使用してこれを実現する。この場合、共有ツールエリアはなく、（共有データおよびナビゲーションのような）通常のフレームワークサービスは使用可能でない（このフレームワークサービスはこの場合必要ない）。重要な点は、この単一コンポーネント（２Ｄビューア）がフレームワークとともに作動できる同じコンポーネントであるということである。フレームワークがない場合、フレームワークは、これを検知するので、これらのサービスに頼らない。コンテナ（例えば、スクリプト）は、アクティビティのふるまいを制御するように適切な情報およびユーザ入力を供給しなければならない。
【００５９】
したがって、このアプリケーションによって使用される１個のアーキテクチャは２Ｄビューイングコンポーネントである。この制御はワークエリアのレイアウトを表示する。この制御には適切なＡＰＩによって入力データセットが明確に提供される。この制御は適切なＰｒＳパイプラインを設定し、レイアウト、ズーム／ｐａｒ、Ｗ／Ｌ等の制御を可能にする。そのふるまいの任意の制御は、（例えば、ウェブページ上にそのふるまいを規定する属性を設定するラッパスクリプトで表示される他の制御から）外部から提供できる。図５（ｂ）は、アクティビティ（２Ｄビューイングコンポーネント）が、このアプリケーションをサポートするためにシーンの裏でどのように動作するかを示している。
【００６０】
仮想プロダクトのシナリオでは、フレームワークのユーザは、下記の動作シーケンスを実行したい場合もある。
シリーズを選択する
２Ｄビューアを呼び出す
ＲＯＩを規定し、セーブする
画像を配置する
ハードコピーする
必要とされるステップ
必要とされるステップおよび生じる動作は下記のとおりである。
ホスト／形式（例えば、ＶＢ、すなわちウェブブラウザ）からフレームワークが具体化される。最初の構成はローカルデータベースに記憶されたパラメータに基づいている。下記の情報は始動でデータベースから抽出される。
候補プロセス定義
ナビゲーションコンポーネント
選択コンポーネント
ツールコンポーネント
ＵＩ構成
プロセス定義
構成データベースは個別のコンポーネントのための構成問題についても識別する。
患者選択が現れる（空間を占める）
セレクタは、ＯＬＥ‐ＤＢを使用してＤＢに照会し、患者リストを得る。
患者を選択する
選択された患者は、共有データコンテキストからＤＢ名／ハンドルを得る。
ユーザは選択を行う。これによりコンテキスト（１人の患者）を形成するセレクタが生じる。例えば、このオブジェクトのプロパティとして関連のＯＬＥ‐ＤＢハンドルを記憶する患者オブジェクトが形成される。
ユーザはシリーズ／画像を選択する。しかしながら、この画像はコンテキストに列挙され、この画像はこの点で"空"画像オブジェクトである。
ともかくも、プロセスは選択される。これは明示的であってもよいしあるいは暗黙的であってもよい。
次にナビゲーションエリアは具体化される。
第１のアクティビティが開始される（例えば、２Ｄビューア）。アクティビティはＵＩエリアを占める。
アクティビティ（２Ｄビューア）は、アクティビティがどのツールを望むかを示す（例えば、右エッジのスライダ）。
２Ｄビューアはデフォルトレイアウトを形成し、画像を表示する。
２Ｄビューアはマウスハンドラをインストールする
２Ｄビューアはツールを要求する。例えば、Ｗ／Ｌクラスツール、パンおよびズームツール等。
フレームワークはクラスを探し、クラスをツールコンテナの中に具体化する（例えば、デフォルトによって、タブを使用する）
ユーザがズームツールをドラッグする‐＞ツールはフレームワークに通信する‐＞フレームワークはアクティビティを呼び戻す
ユーザはビューポートを選択し、マウスをドラッグする‐＞アクティビティは情報をフレームワークに中継する‐＞フレームワークは、情報（例えば、フレームワークのＷ／Ｌ）を更新するツールを呼び出し、フレームワークはアクティビティを呼び出す
あるコンテキストのＲＯＩ（ツール？）を規定する‐＞コンテキストのＲＯＩを記憶する（？）
他のツールを有する画像を配置する
ＨＣツール；ＨＣ機能性（２Ｄビューアの一部、あるいは別個のＨＣコンポーネント？）
【００６１】
図６および図７は、アクティブである２つのプロセスインスタンス（およびしたがって共有データコンテキスト）がある場合、アクティブであるオブジェクトを示す。これらのオブジェクトの大部分（ツールコンポーネントおよびアクティビティコンポーネントを除く）は、フレームワークコンポーネント内に存在するので、外部から直接に見ることができない（アクティビティは、アクティビティインタフェースによって見えるるので、これらのオブジェクトによって提供されるサービスを使用する。）図６は、最高レベル、すなわちフレームワークおよびフレームワークが管理するコンテキストを示し、一方で、図７は、単一プロセスインスタンス（コンテキスト）の拡大図である。
フレームコンポーネント‐内訳説明する
【００６２】
（プログラムデータベースインタフェース）
データベースは命名されたプロトコルのリストを含む。
各プロトコルに関して、順序付けのための特定のロジックを有するアクティビティのリストがある。
各アクティビティは名前で識別され、各アクティビティを具体化できる情報を含む（例えば、クラスＩＤ、あるいはコードのためのＵＲＬを介して）。
各アクティビティは、プロセス専用プロパティのセットも有することができる（アクティビティクラスのプロパティは、例えば、レジストリを使用してこのコンポーネントによって直接処理されるようになる）。
【００６３】
（プロセスインスタンスマネージャ）
フレームワークによって、ユーザは２つ以上の"タスク"で作業できる。したがって、２つ以上のプロセスインスタンスがあり得て、各プロセスインスタンスはマネージャオブジェクトを有する。このオブジェクトは、下記のものを管理する。
・プロセス（すなわち、アクティビティのシーケンス）
・制御フローマネージャ
・制御プロパティマネージャ
・共有データマネージャ
・インタラクティブプロパティマネージャ
・共有ツールマネージャ
【００６４】
（制御フローマネージャ）
このオブジェクトはプロセスのアクティビティの寿命を管理する。このオブジェクトは、
・アクティビティを具体化し、壊す
・ナビゲーションに応じて各アクティビティをアクティブあるいは非アクティブにする
・シーケンス制御および制御プロパティに基づいてアクティビティ間の自動遷移をサポートする
【００６５】
（制御プロパティマネージャ）
このオブジェクトは、自動順序付けを実行するためにフロー制御マネージャによって使用されるプロパティのセットを管理する。これらのプロパティは持続性である必要がなく、プロセスデータベースからの値に基づいてこれらのプロパティを初期化することが必要となり得る。したがって、このオブジェクトが実行する機能は下記のとおりである。
・任意のプロパティの値の設定
・プロパティの変更のフロー制御マネージャへの通知
【００６６】
（インタラクティブプロパティマネージャ）
このオブジェクトは、ツールと各アクティビティとの間の通信のための手段であるプロパティのセットを管理する。フレームワークは、ツールインスタンスとアクティビティとの間のマッピングを保持するので、同じツールクラスはプロセスの２つ以上のアクティビティによって使用できる。
ツールおよびアクティビティの両方はこれらのプロパティを得て、設定でき、その変化を通知できる。
【００６７】
（共有データマネージャ）
このオブジェクトは、
・（任意）オブジェクトのセットを管理する。これらのオブジェクトはアクティビティ間にデータをパスさせる機構である。
・これらのオブジェクトの任意のプロパティのセットを可能にし、これらのオブジェクトの任意のプロパティを得る。
・プロパティ値は、タイプ、すなわちストリング、ｉｎｔ、フロート等を有する。
・プロパティは、"コールバック"修飾子も有し、それによって、オブジェクトは、ある値のプロバイダーとして登録でき、次に、この値が要求されるときは常に呼び出される。この機構は、高価となりえるタスクの繰り延べを可能にする。
・事象を、オブジェクトのこのプロパティへの関与を登録したコンポーネントに供給する。
・コールバック修飾子を有するオブジェクトのプロパティになされる場合に登録プロバイダーにリクエストを転送する。
【００６８】
（ツールマネージャ）
"プログラムデータベース"と同様に、このモジュールは、これらのツールを実行するアクティブエックス制御に対するツール名のマッピングを含むデータベースへのインタフェースを有する。このオブジェクトはツールの寿命も管理する‐このオブジェクトは、現アクティビティの好みに基づいてツールを（構造化可能ＵＩコンポーネントである）"ツールコンテナ"に挿入する。
【００６９】
（ＵＩマネージャ）
このオブジェクトは、４つの副領域、すなわちワークエリア、および３つの制御エリアに分割される全ユーザインタフェースエリアを管理する。このレベルでの構造化可能性、例えばこのエリアの相対サイズおよび位置決めがある必要がある。この設計は、ユーザ対話が領域（例えば、ビジュアルスタジオによって使用されるような"ドック可能"領域）を移動させることができることも考察すべきである。
【００７０】
（１．１．１．１プロセスエリア）
登録プロセスナビゲータはこのエリア内で具体化される。
【００７１】
（１．１．１．２アクティビティナビゲータ）
登録サブナビゲータはこのエリア内で具体化される。
【００７２】
（１．１．１．３共通ツールエリア）
登録ツールコンテナはこのエリア内で具体化される。
【００７３】
（１．１．１．４ワークエリア）
現アクティビティ（アクティブエックス制御）はここでインストールされる。
【００７４】
（アクティビティサポートインタフェース）
これらのインタフェースはアクティビティのライターに供給される。ここで使用される表記は特定の設計を意味しない‐使用される名前は、必要な機能性を識別するためにタグとして解釈されるべきである。
【００７５】
（構成）
この機能は、このプロトコル、すなわちこのプロセス定義のアクティビティのこのインスタンスと関連されるプロパティに専用である構成情報を提供する。クラスプロパティは、（例えば、レジストリを使用して）コンポーネントによって直接に処理されるように予想される。

【００７６】
（共有データ）
この機能性は、"現共有データコンテキスト"にある共有データ、すなわち、アクティビティが実行するプロセスインスタンスに関連する共有データコンテキストを処理するために必要である。

【００７７】

【００７８】

【００７９】

【００８０】
(ツールサポートインタフェース）
これらのインタフェースはツールコンポーネントのライター向きである：

【００８１】
（プロセスナビゲータがインタフェースをサポートする）
プロセスナビゲータは、プロセスインスタンス間の切り換え、プロセスインスタンスを作成、壊し、実行するデータおよびプロセスを選択するＵＩを提供する必要がある。プロセスナビゲータは、（現患者のような）ある状態情報を表示することも必要であるので、これらの目的のための"共有データ"インタフェースおよびＯＬＥ‐ＤＢを使用する。
【００８２】

【００８３】

【００８４】

【００８５】
（プロセス制御コンポーネント）
このコンポーネントは、プロセスナビゲーション機能を示すデモで使用できる例である。このコンポーネントは下記であるべきである。

【００８６】
（データセレクタコンポーネント）
このコンポーネントは、データソースのブラウジングのためにおよび患者／調査／シリーズの階層を横切るためにＯＬＥ‐ＤＢを直接使用する。
このコンポーネントは"プロセス定義"（上記）のために規定されたインタフェースも使用する。

【００８７】
（サブプロセスナビゲータコンポーネント）
このコンポーネントはサブプロセスナビゲーション機能を示すデモで使用できる。このコンポーネントは下記のことをするべきである。

【００８８】
（ツールコンテナ）
このコンポーネントはツールのセットの簡単なコンテナである。このコンポーネントは、既存のアクティブエックスコンポーネントが直接に使用できることであることであってもよい（例えば、タブカードコントローラはデモに対して有用である）。
【００８９】
（２Ｄビューア−アクティビティ）
このコンポーネントは"アクティビティ"である‐したがって、このコンポーネントは上記に列挙されたアクティビティサポートインタフェースを使用する。このコンポーネントがアクティブであるとき、このコンポーネントはワークエリアの所有権を有する。このコンポーネントが作成されるとき、このコンポーネントは下記のことをする。

アクティビティが最初にアクティブになる場合、アクティビティが下記のことをする。

このコンポーネントは新しい入力、すなわちワークエリアのユーザ対話あるいはツールからの入力に応答すべきである：

アクティビティが壊された場合、アクティビティが下記のことをするべきである。

【００９０】
（ツール−２Ｄズーム／パン制御）
このコンポーネントは、簡単なＵＩを提供し、ユーザがズームおよびパンを設定できる。作成時、このコンポーネントは下記のことをするべきである。

ユーザがＵＩ要素を変化する場合、ＵＩが下記のことをするべきである。

アクティビティそのものはツールによって観察されるプロパティを変える場合、ツールが下記のことをするべきである。
そのＵＩを更新し、新しい設定に反映する。
【００９１】
（ツール‐ウィンドウ幅およびレベル調整）
ＵＩ及びプロパティが異なることを除いて、これは基本的に上記の例と同じである。
【００９２】
図８は、いくつかのあるシナリオ中に具体化されてもよいコンポーネントの概略の他の例である。上部レベルで、"フレームワーク"と呼ばれるアクティブエックス制御がある。この制御はコンテナでもあり、この制御は、含む制御の間でＵＩの分割を管理する。ＵＩの分割に加えて、このコンテナは、いくつかの制御を形成し、管理する。制御のＵＩ構成およびＩＤは、レジストリから、次にプロセスデータベースから得られる（プロセスの定義はここに含まれる）。
【００９３】
"プロセスセレクタＵＩ"とラベルを付けられたコンポーネントは、一旦フレームワークが開始すると、構成で識別され、ＵＩで作成され、表示される。次に、コンポーネントは、データセットの選択を使用し、プロセステンプレートをデータセットに関連付けることができる構造化可能"データセレクタ"制御を表示できる。
【００９４】
フレームワークは複数のプロセスインスタンス（あるいはコンテキスト）をサポートし、これは、"ＦＰｒｏｃｅｓｓ１"とラベルを付けられたあるコンポーネントおよび"ＦＰｒｏｃｅｓｓ２"とラベルを付けられた他のコンポーネントによって上記のダイヤグラムに示される。このオブジェクトは実際はフレームワークの一部である（オブジェクトは同じｄｌｌ内に供給される）。しかしながら、たとえオブジェクトがフレームワークコンテナなしに使用されることが予想されないとしても、これを別々の制御として保持することはより便利であり得る。［これはなお決定されるべきである。すなわち、現プランはこれをフレームワーク内で内部的に使用されるクラスとして実行すべきであるが、別個のプロセスを別個のＣＯＭオブジェクトとして管理することはより容易であるように見える場合、このオブジェクトはこの方法を実行される（しかしなお同じｄｌｌの一部として供給される）］
【００９５】
ＦＰｒｏｃｅｓｓはそれ自体コンテナである。それは単一プロセス定義に関し、関連データコンテキストを有する。ＦＰｒｏｃｅｓｓの作成は、プロセステンプレートの装備ならびにデータ、例えば共有されるデータオブジェクトの定義を識別するのに必要な情報を必要とする（これは、ＦＰｒｏｃｅｓｓ内で処理されるので、ダイヤグラムに直接に表示されない）。
【００９６】
ＦＰｒｏｃｅｓｓインスタンスは、ＵＩエリアの中の３つ（サブプロセスナビゲータ、ツールエリア、およびワークエリア）を管理する。サブプロセスエリアは、さらに構造化可能である制御によって占められる。このクラスのＩＤはフレームワークによって復元され、ＦＰｒｏｃｅｓｓに利用される。
【００９７】
同様に、"ツールマネージャ"コンポーネントは構造化可能であり、そのＩＤは、復元され、フレームワークによってＦＰｒｏｃｅｓｓに利用される。ＦＰｒｏｃｅｓｓは、"ツール"を示す制御および"アクティビティ"である制御を管理する。これらの中のＩＤは、ＦＰｒｏｃｅｓｓが開始される場合、ＦＰｒｏｃｅｓｓコンポーネントに供給されるプロセステンプレートに含まれる。
【００９８】
プロセス選択エリアは、（構成されるにつれて）この制御によって占められる。そのタスクは、アクティブタスクと作成プロセスあるいは新規プロセスとの間の選択を可能とすることにある。このプロセスは、図９に示されるように全く簡単なＵＩを有し、この場合"新規プロセス"プッシュボタンが他の制御、すなわち"データセレクタ"のクラスからの制御使用となる。この制御も構造化可能であり、その役割は、フレームワークのアクティビティによるその後の使用に対してプロセステンプレートおよびデータセットの選択に対してユーザインタフェースを提供することにある。"プロセス終了"ボタンは現アクティブプロセスを停止する（現プロセスはドロップダウンリストボックスに表示されたプロセスである）。
【００９９】
下記のことは、データセレクタの一例を説明する。この構造化可能な制御は、"プロセスセレクタ"（上記）によって具体化され、この制御は使用するデータおよびプロセスを決定する役割を果たす。一般的に、これは、ユーザがデータセット（あるいは複数のデータセット）を選択し、次にプロセス（プロトコル）をこのデータと併用できることによって実行される。しかしながら、異なるモデルも使用できる。例えば、このプロセスは最初に選択する必要があるかもしれず、その結果、選択できる可能なデータセットのサブセットを決定する。他のモデルは、データセットがたとえ予め決定されたプロセス（プロトコル）で外部で（例えば、企画ワークフローエンジンで）決定されるモデルである。この場合、セレクタは可能なワーク項目のリストをユーザに示すことだけを必要とする（項目の選択は使用するデータセットおよびプロセスを意味する）。
【０１００】
一般に、プロセス（プロトコル）に応じて、サポートされる必要があるかもしれない異なる選択機構がある。例えば、
・単一画像選択
・単一シリーズ（３Ｄ、ＭＰＲ等に対して）
・２シリーズ（統合に対して）
・複数シリーズ、単一調査あるいは患者（精査、読み取り）
・任意の選択
【０１０１】
データセレクタの一例は、データが従来の患者‐調査‐シリーズ‐画像階層に記憶されているという仮定であり、このセレクタは、互いに無関係の画像およびプロセスの任意の選択を可能にする。さらに、セレクタは、デモ目的のために共有データコンテキストに現在示されているこれらの患者、調査、シリーズおよび画像のオブジェクトを示している。
【０１０２】
ユーザインタフェースは、３つの異なる画像を有するタブカードの形で構成される。
【０１０３】
タブ"データベース選択"上の第１の画像は、制御の左側にデータベース−患者‐調査‐シリーズ‐画像階層の階層画像および制御の右側のリストには現シリーズの画像のリストを表示する。２つのボタンによって、ユーザはリスト画像のサブセットあるいはリスト画像の全てのいずれかを選択できる。
【０１０４】
図１１に示す第２の画像は、同様に、タブ"共有コンテキスト"上の画像であり、共有データコンテキストの現内容を示す。
【０１０５】
図１２に示された第３の画像は、データベースの階層画像も繰り返す。第３の画像は所望のプロセス（プロトコル）の選択のための簡単なリストおよびボタンを提供する。例データセレクタはビジュアルベーシックで実行される。これには２つの利点がある。まず第一に、この制御の大部分はユーザインタフェースであり、ビジュアルベーシックはユーザインタフェースの非常に高速で、便利な形成を可能にする。第二に、顧客がビジュアルベーシックでアクティビティコンポーネントを作成したいことはないことではない。したがって、若干の経験を累積することは有用である。
【０１０６】
ユーザシナリオは全く簡単である。すなわち、１．最初にユーザにはデータベース選択タブが表示される。ユーザは、データベース階層の下方にナビゲートし、１つあるいはそれ以上のシリーズおよび患者から１つあるいはそれ以上の画像を選択する。２．それから、ユーザは、共有コンテキストタブを選択し、共有コンテキストが必要とされるデータを正確に含むことを検証する。３．ユーザは、プロセス選択タブを選択し、データのために実行されるプロトコルを選択する。
【０１０７】
あるロジックは、少なくとも１つの画像および少なくとも１つのプロセスの選択を強制するように実行されてもよい。
【０１０８】
システムの他のコンポーネントとの対話によって、データセレクタの一例は、下記のものとインタフェースする。
・データベース；使用可能なデータベースはシステムレジストリからロードされ、ＡＤＯによってアクセスされる
・共有コンテキスト；オブジェクトおよびプロパティは、共有コンテキストから引き出され、共有コンテキストに形成されなければならない
・プロセスデータベース；使用可能なプロセスは引き出されなければならない
選択エリア；これはデータセレクタのためのコンテナであり、選択プロセスを通知される必要がある。
【０１０９】
データセレクタは、若干の設計時間ふるまいを有するアクティブエックス制御である（タブセレクタはアクティブであり、いろいろなリストおよびボタンは、制御で移動及びサイズ化される）。
【０１１０】
本発明はある特定の実施例に関して説明されているけれども、添付された特許請求の範囲において概略される本発明の目的および範囲を逸脱せずに、多様な修正が当業者には明らかである。
【図面の簡単な説明】
本発明のより良い理解は下記の図面とともに詳細な説明を参照することによって得られる。
【図１】ユーザインタフェース（ＵＩ）の概略図である。
【図２】ツールマネージャの概略図である。
【図３】サブプロセスＵＩの概略図である。
【図４】システムアーキテクチャの概略図である。
【図５ａ】ＵＩの他の実施例である。
【図５ｂ】２Ｄビューイングコンポーネントのためのサポートプロセスを示す概略図である。
【図６】フレームワークおよびフレームワークが管理するコンテキストの概略図である。
【図７】単一プロセスインスタンスの拡大概略図である。
【図８】システムコンポーネントを示す他の概略図である。
【図９】プロセスナビゲータＵＩの概略図である。
【図１０】データベース選択および関連ビューの概略図である。
【図１１】データベース選択および関連ビューの概略図である。
【図１２】データベース選択および関連ビューの概略図である。

Claims (19)

1. コンピュータで実行されるフレームワークのアプリケーション内のワークフローをモニタするためにコンピュータで実行される方法であって、
   前記ワークフローは、前記アプリケーションの外部からの一組のアクティビティのうちから少なくとも１つのアクティビティを調整することを含み、前記フレームワークは、複数レベルの機能性を有し、さらに、前記アプリケーションで用いるために、前記アプリケーションの外部の異なるソースからの複数の前記アクティビティを前記ワークフローに対して調整することができ、さらに、ユーザと前記アプリケーションとの間の対話を容易にするためのユーザインタフェースを有し、前記アプリケーションが、アクティビティレベルにて前記一組のアクティビティを有し、前記アクティビティは、複数の異なるソースから選択可能であり、
   前記方法は、
   ａ）プロセスレベルにて、データ記憶装置からプロセス定義を選択するステップであって、前記プロセス定義は、前記アクティビティの調整に従って、前記ワークフローの期間にデータセットを処理するためのプロセスステップのセットを定義し、それにより前記プロセスステップは前記一組のアクティビティに関連付けられるステップと；
   ｂ）前記データ記憶装置から前記データセットを選択するステップと；
   ｃ）前記プロセス定義に従って前記アプリケーションの外部の異なるソースからの複数の前記アクティビティを組み合わせるために、前記アプリケーションを開始するステップと；
   ｄ）サブプロセスレベルにて、前記ワークフローをモニタするために、前記プロセス定義に従って、前記一組のアクティビティから選択されたアクティビティ間をナビゲートするステップと；さらに、
   ｅ）前記少なくとも１つのアクティビティのそれぞれを、前記プロセスステップにおけるそれぞれのプロセスステップの間に前記データセットに適用するために前記プロセス定義を実行し、それによって、後に利用する出力データのセットを生成するための前記データセットに含まれる少なくとも１つのプロパティが修正されるステップと、
   を含む、コンピュータで実行される方法。
2. 請求項１に記載の方法において、前記複数レベルの機能性の少なくとも幾つかを、前記ユーザインタフェースの異なる領域に割り当てるステップをさらに含む方法。
3. 請求項２に記載の方法において、前記ユーザインタフェースが、画像のディスプレイを提供するためのスクリーンを含む、方法。
4. 請求項３に記載の方法において、前記一組のアクティビティから選択された現アクティビティを、前記スクリーンのワークエリアに割り当てるステップをさらに含み、前記ワークエリアは、前記スクリーンの表面エリアの補助的な部分を有する方法。
5. 請求項４に記載の方法において、前記現アクティビティによる前記ワークエリアの所有をモニタするステップをさらに含む方法。
6. 請求項２に記載の方法において、少なくとも２つのプロセス定義を同時に処理するステップを更に含む方法。
7. 請求項６に記載の方法において、前記ユーザインタフェースのワークエリアへの割り当てのために、アクティブなアクティビティの間から選択するステップを更に含む方法。
8. 請求項７に記載の方法において、前記アプリケーションが、現アクティビティにわたって前アクティビティの再利用をさらにサポートし、前記前アクティビティは、前記一組のアクティビティから選択される方法。
9. 請求項２に記載の方法において、前記ユーザインタフェースの前記異なる領域に表示された情報のレベルをモニタするステップをさらに含む方法。
10. 請求項２に記載の方法において、現アクティビティによって、前記ユーザインタフェースの前記異なる領域をマネージングするステップを含む方法。
11. 請求項１に記載の方法において、前記アプリケーションのユーザによる、前記一組のアクティビティの実行順序をダイナミックにモニタするステップをさらに含む方法。
12. 請求項１１に記載の方法において、ルールのセット又はアクティビティのプロパティのセットに基づいて、前記一組のアクティビティにおける前記選択されたアクティビティ間の制御フローを自動化するステップをさらに含む方法。
13. 請求項１に記載の方法において、前アクティビティから得られる前記出力データセットに基づいて、前記一組のアクティビティの演算機能性をモニタするステップをさらに含む方法。
14. 請求項１に記載の方法において、ツールによって前記一組のアクティビティのパラメータを設定するステップをさらに含み、前記パラメータが、前記一組のアクティビティの演算動作を更新する方法。
15. 請求項１４に記載の方法において、前記ユーザインタフェースの異なる領域に、前記ツールを割り当てるステップをさらに含む方法。
16. 請求項１５に記載の方法において、前記ユーザインタフェースの前記ツール領域にツールをインストールするステップをさらに含み、前記ツールが、前記プロセス定義により要求される方法。
17. 請求項１に記載の方法において、共有データコンテキストにおいて、前記ユーザインタフェースのワークエリアの内容のプロパティを共有するステップをさらに含む方法。
18. 請求項１７に記載の方法において、情報目的の共有のために、前記一組のアクティビティのうちの１つを調整することによって、前記共有データコンテキストにアクセスするステップをさらに含む方法。
19. 請求項１〜１８のいずれか一項に記載の方法を実行するための、コンピュータで実行可能な命令を含むコンピュータ読み取り可能な媒体。

Images