JP2006107478A - ワークフローを設計するための拡張可能フレームワーク - Google Patents

Abstract

【課題】 コンポーネント化されたワークフローモデルをビルドするためのユーザインターフェイスを提供すること。
【解決手段】 ワークフローの各ステップは、ワークフローステップの設計時の態様、コンパイル時の態様、および実行時の態様を記述するメタデータを持つアクティビティとしてモデル化される。ユーザは、ユーザインターフェイスを介してワークフローを作成するアクティビティを選択し、配置する。ワークフロー内のアクティビティのそれぞれに関連付けられたメタデータが収集され、ワークフローの永続的表現を作成する。ユーザは、カスタムアクティビティをオーサリングすることによりワークフローモデルを拡張する。
【選択図】 図１

Description

本発明の実施形態は、ワークフローモデリングの分野に関係する。特に、本発明の実施形態は、コンポーネント化された拡張可能ワークフローモデル（componentized and extensible workflow model）に関係する。

既存のシステムでは、ビジネス問題をモデル化することによりビジネス問題を高水準のワークフローにマッピングすることを試みる。しかし、現実世界のワークフローは、（ａ）実行およびモデリングの複雑さ、（ｂ）設計時のフローの構造に関する知識、（ｃ）静的に定義された、またはアドホック／動的な特性、（ｄ）ライフサイクルにおけるさまざまな時点でのフローのオーサリングおよび編集の容易さ、（ｅ）ビジネスロジックとコアワークフロープロセスとの弱いまたは強い関連などのさまざまな次元において異なる。既存のモデルでは、これらすべての要因に対応することはできない。

さらに、ほとんどの既存のワークフローモデルは、言語ベースのアプローチ（例えば、ＢＰＥＬ４ＷＳ、ＸＬＡＮＧ／Ｓ、およびＷＳＦＬ）またはアプリケーションベースのアプローチに基づいている。言語ベースのアプローチは、定義済み言語構文の閉じた集合を持つ高水準のワークフロー言語であり、これにより、ユーザ／プログラマに対するワークフロープロセスのモデル化が容易になる。ワークフロー言語は、言語構文の閉じた集合に対するすべての意味情報を備え、これによりユーザはワークフローモデルを構築できる。しかし、言語は、開発者側で拡張することはできず、ワークフローモデルを構成するプリミティブの閉じた集合となっている。言語は、ワークフローシステムベンダが出荷する言語コンパイラに結び付けられている。ワークフローシステム製品ベンダのみが、将来の製品バージョンにおいて新しい言語構文の集合を加えて言語を拡張することによりモデルを拡張することができる。このため、言語に関連付けられたコンパイラのアップグレードが必要となる。

アプリケーションベースのアプローチは、アプリケーション内に領域特有の問題を解決するためのワークフロー機能を備えるアプリケーションである。これらのアプリケーションは、本当に拡張可能であるとはいえず、またプログラム可能なモデルも持たない。

既存のアプローチでは、複雑さ、先見、動的ワークフロー、オーサリングの容易さ、およびビジネスロジックとコアワークフローとの関連度の強さの課題が適切に扱えない。さまざまなクラスのワークフローをモデル化するビジュアルワークフローデザイナ（visual workflow designers）を構築するために利用できる、拡張可能、カスタマイズ可能、および再ホスト可能な（re-hostable）ワークフローデザイナフレームワークはない。既存のシステムでは、ユーザがグラフィックスを利用してワークフロープロセスの設計を行い、開発者が選択したプログラミング言語によるビジネスロジックを関連付けることができるアプリケーション短期開発（ＲＡＤ）スタイルのワークフロー設計の経験を欠いている。さらに、インク対応ワークフローデザイナ（ink-enabled workflow designer）もない。

さらに、既存システムは、ワークフローの実行のための継ぎ目のないアドホックな、または動的な編集機能を備えていない。ワークフロープロセスは、本質的に動的であり移動性を有し、その形態は設計時には全く予見できない。ワークフロープロセスは、構造化様式で始まり、最終的には、その実行存続期間の過程で発展し変化する。ワークフロービルダが設計時にさまざまな種類のワークフローモデルをオーサリングするだけでなく、継ぎ目のない方式でアドホックな、または動的な変更を実行中のワークフローに加えられるようにするワークフローオーサリングフレームワーク（workflow authoring framework）が必要である。ワークフロープロセスが展開された後、実行されていても、ビジネス要件に変更があれば、多くの場合、現在実行中のワークフロープロセスを変更または編集せざるを得ない。ワークフロープロセスの実行時オーサリングを行えるシステムが必要である。

さらに、ワークフロープロセスでは、ワークフロープロセスの複数のステップにまたがる分野横断的な直交する、入り組んだ諸問題を取り扱う。例えば、ワークフロープロセスの一部が長い実行トランザクションに参加するように設計されているが、同じプロセスの他の部分は同時実行用に設計されている。同じワークフロープロセスのさらに他の部分では、追跡を必要とするが、他の部分ではビジネスまたはアプリケーションレベルの例外を扱う。特定のビヘイビアをワークフロープロセスの１つまたは複数の部分に適用する必要はない。

いくつかのワークフローモデリングアプローチは、すべての例外および人間介入を含むビジネスプロセス全体の完全なフローベースの記述を必要とするので実用的でない。これらのアプローチのいくつかは、例外が発生したときの追加機能を用意しているが、他のアプローチでは、ビジネスプロセスをモデル化するフローベースのアプローチの代わりに制約ベースのアプローチのみを採用する。既存システムでは、フローベースまたは制約ベースのアプローチのいずれかを実装する。このようなシステムは、柔軟性が低すぎて、ビジネスの数多くの一般的状況をモデル化できない。

したがって、これらの欠点およびその他の欠点の１つまたは複数を解放するためにコンポーネント化された拡張可能なワークフローモデルが望まれる。

本発明のいくつかの実施形態は、コンポーネント化されたワークフローモデルを構築する拡張可能なフレームワークを実現する。特に、ワークフロープロセスの各ステップは、ワークフローステップの設計時の態様、コンパイル時の態様、および実行時の態様を記述する関連コンポーネントモデルを持つ。さらに、開発者は、これらのコンポーネントをオーサリングすることによりコアワークフローモデルを拡張することができる。本発明は、高度に形式的なマシン同士のプロセス、制約ベースのアドホックなヒューマンワークフロー、およびフローベースのアプローチおよび制約ベースのアプローチの混合を持つワークフローを含む、さまざまな種類のワークフローの実行を調整するのに十分柔軟であり強力なワークフローエンジンを含む。ワークフローエンジンでは、実行中ワークフローに対するアクティベーション、実行、クエリ、および制御機能を使用できる。例えば、本発明では、実行ワークフローにアドホックな動的変更を加えることができる。ワークフローエンジンは、サーバおよびクライアント環境の両方を含むさまざまなホスト環境において再ホスト可能または埋め込み可能である。それぞれの特定のホスト環境では、ワークフローエンジンをサービスプロバイダ群に結合する。サービスプロバイダの集約機能により、特定のホスト環境で実行できるワークフローの種類が決定される。

本発明の他の実施形態では、ワークフローモデルをシリアライズするために拡張オーケストレーションマークアップ言語（extensible orchestration markup language）（ＸＯＭＬ）などの宣言形式を備える。宣言形式を使用すると、ユーザはコンポーネントの集合を書くことによりワークフローモデルを拡張することができる。ワークフロープロセスのさまざまなステップに対応する意味論は、コンパイル時に与えられたコンポーネントの意味論の妥当性を確認し、それを強制するアクティビティバリデータコンポーネント（activity validator component）内にカプセル化される。本発明の宣言形式の実施形態では、さらに、データの宣言およびデータとワークフローモデルのさまざまな要素との関連付けが可能である。宣言形式では、ワークフローを通じてデータを変換する操作をサポートする。例えば、この形式は、ワークフローモデル内のデータベースまたはファイル、コードスニペット、およびビジネスルールなどの外部データソースを宣言的に表す。

本発明の一実施形態では、さまざまなクラスのワークフローをモデル化するグラフィカル／ビジュアルワークフローデザイナを構築する拡張可能、カスタマイズ可能、および再ホスト可能なワークフローデザイナフレームワークを提供する。本発明の他の実施形態では、ユーザが任意のプログラミング言語によりグラフィックスを利用してワークフロープロセスの設計を行い、ビジネスロジックの関連付けを行うことができるようにするアプリケーション短期開発スタイルのワークフロー設計のエクスペリエンスをサポートする。本発明の実施形態は、さらに、ペンおよびタブレット技術を使用してインクもサポートする。本発明は、ユーザにより描画されたワークフローが内部表現に変換されるフリーフォームドローイングサーフェス（free form drawing surface）を備える。本発明は、既存のドローイングサーフェス上のインク編集（例えば、追加／削除アクティビティ）、および既存のワークフローのインク注釈（例えば、デザインサーフェス（design surface）に手書きされたコメント、提案、または注意喚起）を介してワークフローの作成および修正をサポートする。

本発明のさらに他の実施形態では、宣言的方法により分野横断的なビヘイビアを捕捉し、そのビヘイビアをワークフローモデルの選択された部分に適用するためのコンポーネントを備える。本発明の他の実施形態は、それに関連付けられているビヘイビアの背景状況においてワークフローモデルの選択された部分を実行する。本発明の実施形態は、フレームワーク、再利用可能コンポーネント、およびワークフロープロセスモデルの複数のステップにまたがる分野横断的な直交する入り組んだ諸問題を扱うための言語を提供する。

本発明の一態様によれば、方法は、ディスプレイおよびユーザインターフェイス選択装置を備えるコンピュータシステムにおいてワークフローをモデル化する。ワークフローはアクティビティを含み、ワークフローはビジネスプロセスをモデル化する。方法は、ディスプレイ上に複数のアクティビティを表示することを含む。方法は、さらに、ユーザインターフェイス選択装置を介してユーザからアクティビティの選択を受け取ることも含む。方法は、さらに、ディスプレイ上にアクティビティの受け取った選択を表示することも含む。方法は、さらに、ユーザインターフェイス選択装置を介してユーザから構造情報を受け取ることも含む。方法は、さらに、ワークフローを作成するために受け取った構造情報に従ってディスプレイ上にアクティビティの表示される選択を配列することも含む。

本発明の他の態様によれば、１つまたは複数のコンピュータ可読媒体は、ディスプレイおよびユーザインターフェイス選択装置を備えるコンピュータシステム内にワークフローをモデル化するためのコンピュータ実行可能コンポーネントを有する。ワークフローはアクティビティを含み、ワークフローはビジネスプロセスをモデル化する。コンポーネントは、ディスプレイ上に複数のアクティビティを表示するためのレンダリングコンポーネントを含む。コンポーネントは、さらに、ユーザインターフェイス選択装置を介してユーザからレンダリングコンポーネントにより表示されるアクティビティの選択を受け取るためのインターフェイスコンポーネントも含む。レンダリングコンポーネントは、さらに、ディスプレイ上に、インターフェイスコンポーネントが受け取ったアクティビティの選択を表示する。インターフェイスコンポーネントは、さらに、ユーザインターフェイス選択装置を介してユーザから構造情報を受け取る。コンポーネントは、さらに、ワークフローを作成するために受け取った構造情報に従ってディスプレイ上にアクティビティの選択を配列するデザイナコンポーネントも含む。

本発明のさらに他の態様によれば、システムはワークフローをモデル化する。ワークフローはアクティビティを含み、ワークフローはビジネスプロセスをモデル化する。システムは、複数のアクティビティを格納するためのメモリ領域を備える。システムは、さらに、メモリ領域に格納されている複数のアクティビティを表示するための表示領域も備える。システムは、さらに、ユーザからアクティビティの選択を受け取り、表示領域内にアクティビティの受け取った選択を表示し、ユーザから構造情報を受け取り、受け取った構造情報に従って表示領域内にアクティビティの表示される選択を配列してワークフローを作成するコンピュータ実行可能命令を実行するように構成されているプロセッサも備える。

それとは別に、本発明は、他のさまざまな方法および器具装置を含むことができる。

他の特徴は、一部は明白であり、また一部は以下で指摘される。

対応する参照文字は、図面全体を通して対応する部分を示す。
本発明のいくつかの実施形態では、ビジネスプロセスなどのプロセスを表すワークフローをモデル化する。ビジネスプロセスとは、予測可能で再現可能な成果が得られる従属する、順序付けられたタスク、アクティビティなどのことである。組織の運営手順、制度に関する実務知識、および情報資源を含めて、ビジネスプロセスは、効率よく、時機を逃すことなく定義済みのビジネス目的を達成するように設計される。効率的な環境では、プロセスの機能コンポーネントは、絶え間なく変化する企業要件に対処するために、容易に識別し、適合し、展開することができる。ワークフローは、ビジネスプロセス内のタスクとやり取りするエンドユーザのエクスペリエンスである。タスクは、アクティビティ、コンポーネントなどとしてモデル化され、それぞれ人またはマシンにより実行される一単位の作業である。一実施形態では、複数のアクティビティが一人のユーザ提示される。ユーザは、ワークフローを作成する複数のアクティビティを選択して編成する。作成されたワークフローは、実行され、ビジネスプロセスをモデル化する。図１を参照すると、ワークフロー１００の実施例は、タスクおよび制御フロー複合アクティビティを含んでいる。

一実施例では、オーケストレーションエンジンワークフローモデルは、さまざまなクラスのワークフローのモデリング、オーサリング、および実行をサポートする。実施例は、整然とした順序で、または非同期イベントの集合として実行される構造化されたステップの集合に関して与えられた問題をモデル化することを含む。オーケストレーションエンジンは、スケジュールの実行を調整する。スケジュールは、ツリー構造で階層的に配列されたアクティビティのきちんと整理された集合である。実行アクティビティの実行コンテキストおよび実行アクティビティから見える共有データは、スコープにより規定される。それぞれのアクティビティは、ワークフロープロセス内のステップに対するメタデータをカプセル化するコンポーネントを表す。アクティビティは、ワークフローモデルでの実行の基本単位であり、関連付けられたプロパティ、ハンドラ、制約、およびイベントを持つ。それぞれのアクティビティは、任意のプログラミング言語のユーザコードにより構成することができる。例えば、ユーザコードは、共通言語ランタイム（ＣＬＲ）言語で書かれたビジネスもしくはアプリケーションロジックまたはルールを表すことができる。それぞれのアクティビティは、ユーザコードでの実行へのインターセプト前フックおよびインターセプト後フック（pre-interception hooks and post-interception hooks）をサポートする。それぞれのアクティビティは、関連付けられたランタイム実行意味論およびビヘイビア（例えば、状態管理、トランザクション、イベント処理、および例外処理）を持つ。アクティビティは、他のアクティビティと状態を共有できる。アクティビティは、プリミティブなアクティビティであるか、または複合アクティビティにグループ化することができる。プリミティブつまり基本アクティビティは、下位構造（例えば、子アクティビティ）を持たず、したがって、ツリー構造内の葉ノードである。複合アクティビティは、下位構造を含む（例えば、これは、１つまたは複数の子アクティビティの親である）。

一実施形態では、アクティビティは、単純アクティビティ、コンテナアクティビティ、およびルートアクティビティの３種類がある。この実施形態では、モデルには１つのルートアクティビティがあり、ルートアクティビティの内側に単純アクティビティまたはコンテナアクティビティは全くないか、またはいくらかある。コンテナアクティビティは、単純またはコンテナアクティビティを含むことができる。ワークフロープロセス全体は、高位のワークフロープロセスを構築するアクティビティとして使用することができる。さらに、アクティビティは、中断可能であるか、または非中断可能とすることができる。非中断可能複合アクティビティは、中断可能アクティビティを含まない。非中断可能アクティビティには、アクティビティにブロックさせるサービスはない。

オーケストレーションエンジンは、アクティビティの集まりの例を示している。図２を参照すると、アクティビティ継承ツリーにアクティビティの実施例が示されている。図２に一覧として示されているアクティビティの実施例は、付録Ａで詳しく説明する。さらに、ユーザは、ワークフローモデルを拡張するために１つまたは複数のアクティビティを書くことができる。例えば、ユーザは、特定のビジネス問題、領域、ワークフロー標準（例えば、ビジネスプロセス実行言語）、またはターゲットプラットフォームに対するアクティビティを書くことができる。オーケストレーションエンジンは、例えば、コードを分析するサービス、型解決およびタイプシステム、シリアライズするサービス、およびレンダリングを含むアクティビティを書くためのさまざまなサービスの集合をユーザに提供することができる。

一実施形態では、それぞれのアクティビティは、メタデータ、インスタンスデータ、および実行ロジックの少なくとも３つの部分を持つ。アクティビティのメタデータは、構成することができるデータプロパティを定義する。例えば、いくつかのアクティビティは、アクティビティ抽象基本クラスで定義されているメタデータの共通集合を共有することができる。それぞれのアクティビティは、このクラスを拡張することによりそのニーズに応じて独自の追加メタデータプロパティを宣言する。
メタデータプロパティの値は、アクティビティが構成されたスケジュールのいくつかのインスタンスにわたってそのアクティビティのすべてのインスタンスにより共有される。例えば、ユーザがスケジュールＡを作成し、送信アクティビティをそれに追加した場合、送信アクティビティはそのメタデータの一部として識別情報（例えば、「００１」）を与えられる。スケジュールに追加される第２の送信アクティビティは、その独自の一意的な識別情報（例えば、「００２」）を受け取ることになる。スケジュールＡの複数のインスタンスが作成され、実行されると、送信「００１」のすべてのインスタンスはメタデータ値を共有する。対照的に、アクティビティのインスタンスデータは、実行スケジュールインスタンス内のアクティビティのインスタンスに特有のデータの集合を定義する。例えば、遅延アクティビティは、遅延アクティビティのタイムアウト値を表す日時値であるインスタンスデータに関する読み取り専用プロパティを与えることができる。この値は、遅延アクティビティが実行を開始した後利用可能になり、遅延アクティビティの１つ１つのインスタンスについて十中八九異なる。参照を「インスタンス」で修飾せずに、スケジュールのインスタンス、特にアクティビティおよびタスクのインスタンスを参照するのがふつうである。

複合アクティビティは、その子アクティビティの集合を他の要素として持つ。子アクティビティは、一実施形態ではメタデータと考えられる。オーケストレーションエンジンモデルでは、スケジュールのインスタンス内で実行時にこのメタデータを操作できることを明示している。新しい子アクティビティを実行スケジュールインスタンスの一部である複合アクティビティに追加し、そのスケジュールインスタンスに対するメタデータ（アクティビティツリー）のみが影響を受けるようにすることが可能である。

次に図３を参照すると、それぞれのアクティビティは、そのアクティビティに対するコンポーネントモデルを形成する関連付けられたコンポーネントの集合を持つ。関連付けられたコンポーネントの集合は、アクティビティエグゼキュータ（activity executor）、アクティビティデザイナ、アクティビティシリアライザ（activity serializer）、アクティビティバリデータ（例えば、意味チェッカー（semantic checker））、およびアクティビティコードジェネレータを含む。アクティビティエグゼキュータは、アクティビティに対する実行意味論を実装するステートレスコンポーネントである。アクティビティエグゼキュータは、アクティビティを実装するためのアクティビティのメタデータを操作する。コアスケジューラは、アクティビティエグゼキュータのサービスプロバイダとして機能し、アクティビティエグゼキュータにサービスを提供する。

アクティビティデザイナは、アクティビティの設計時ビジュアル表現を視覚的に表示する。アクティビティデザイナは、デザイナ階層内の１つのノードであり、テーマまたはスキンを作成して設定できる。アクティビティデザイナは、設計環境（例えば、アプリケーションプログラム）でホスティングされ、サービスを介してホスト設計環境とやり取りする。アクティビティバリデータでは、コンパイル時だけでなく実行時にもアクティビティ意味論を強制する。アクティビティバリデータは、ワークフローモデルのコンテキストに作用し、環境が提供するサービスを使用する（例えば、コンパイラ、デザイナ、またはランタイム）。バリデーションは、ワークフローのライフサイクルの各時点で実行される。構造準拠検査は、ワークフローのシリアライズ表現を作成するときに、コンパイルするときに、およびユーザの要求に対する応答として実行される。意味検査は、コンパイル時に実行するよりも実行時の方が強く、このため実行インスタンスのアクティビティツリー内のアクティビティの追加または置換などの実行時オペレーションの安全性を保証することができる。本発明では、例えば、定義済みインターフェイス要件への適合または準拠に関してアクティビティのそれぞれに関連付けられた意味論を評価する。

アクティビティシリアライザは、アクティビティのメタデータをシリアライズするコンポーネントである。アクティビティシリアライザは、さまざまなモデル／フォーマットシリアライザから呼び出される。ワークフローモデル全体が、拡張可能スキーマに基づいて宣言的マークアップ言語内にシリアライズされ、さらに、望むとおりに他のワークフロー言語に変換することができる。

一実施形態では、アクティビティのコンポーネントモデルは、コンピュータ可読媒体上にデータ構造体として格納される。データ構造体において、アクティビティデザイナは、アクティビティを視覚的に表現するためデータ（例えば、アイコン）を格納する画像フィールドにより表される。さらに、１つまたは複数の作者時刻フィールドでは、アクティビティに関連付けられているプロパティ、メソッド、およびイベントを定義するメタデータを格納する。アクティビティシリアライザは、作者時刻フィールドに格納されているメタデータをアクティビティの宣言的表現に変換するためのデータを格納するシリアライザフィールドにより表される。アクティビティジェネレータは、作者時刻フィールドに格納されているメタデータに関連付けられているソフトウェアコードを格納するビジネスロジックフィールドにより表される。アクティビティエグゼキュータは、ビジネスロジックフィールドに格納されているソフトウェアコードを実行するためのデータを格納するエグゼキュータフィールドにより表される。

スコープとスケジュール
実行アクティビティの実行コンテキストおよび実行アクティビティから見える共有データは、スコープにより規定される。スコープとは、コアアクティビティのうちの１つである。スコープは、変数および長時間実行しているサービスの状態をトランザクション意味論、エラー処理意味論、補正、イベントハンドラ、およびデータ状態管理とともにひとまとめにするための統一言語構文である。スコープは、関連付けられた例外およびイベントハンドラを持つことができる。一実施形態では、スコープは、トランザクション、アトミック、長時間実行、または同期化のスコープとすることができる。ユーザ変数に対するｒｅａｄ−ｗｒｉｔｅまたはｗｒｉｔｅ−ｗｒｉｔｅ アクセスが衝突する場合にユーザのために同時実行制御が用意される。スコープは、さらに、トランザクション境界、例外処理境界、および補正境界でもある。スコープはスケジュール内でネストすることができるので、さらに、名前が衝突することなく異なるスコープ（スコープがネストしているとしても）内で同じ名前により変数、メッセージ、チャネル、および相関関係集合を宣言することが可能である。

スケジュール内にネストされているスコープは、そのスケジュールのコンテキスト内でのみ実行可能である。スケジュールは、アプリケーション（例えば、スタンドアロンの実行可能エンティティ）として、またはライブラリ（例えば、他のスケジュールから呼び出すため）としてコンパイルすることができる。ライブラリとしてコンパイルされたスケジュールはすべて、実際に、他のスケジュール内から呼び出すことができる新しいアクティビティ型を構成する。スケジュールのメタデータは、パラメータの宣言を含む。

スケジュールが作成された後、作成されたスケジュールのインスタンスを実行できる。スケジュールインスタンスをアクティベートし、制御するプロセスは、オーケストレーションエンジンが埋め込まれているホスト環境に応じて異なる。オーケストレーションエンジンは、スケジュールをテストするために使用できる余計な機能のない「単純なホスト」を提供する。さらに、オーケストレーションエンジンは、サービス環境（つまり、ホスト）とやり取りするためエンジンおよび外部アプリケーションにより同様に使用される「サービスプロバイダ」モデル（例えば、アプリケーションプログラミングインターフェイス）の標準化を推進するアクティベーションサービスを提供する。アクティベーションサービスは、特定のスケジュール型のスケジュールインスタンスを作成し、その際に、任意選択で、パラメータを受け渡す。スケジュールインスタンスは、本質的に、実行スケジュールインスタンスのプロキシであり、インスタンス、スケジュールのメタデータ（アクティビティツリー）への参照、およびインスタンスのサスペンド、レジューム、および終了を実行するメソッドを一意に識別する識別子を含む。アクティベーションサービスは、さらに、与えられたスケジュールインスタンス識別子に基づいてスケジュールインスタンスを見つける操作もサポートする。

コードビサイド
スコープアクティビティは、スコープアクティビティのビジネスロジックを含む関連するコードビサイドクラスを持つことができる。スケジュールはそれ自体スコープであるため、スケジュールはコードビサイドクラスも持つことができる。スケジュール内にネストされているスコープも、それ独自のコードビサイドクラスを持つことができる。スコープ内でネストされているアクティビティは、共有データ状態およびビジネスロジックのコンテナとして働くスコープのコードビサイドクラスを共有する。例えば、コードアクティビティのメタデータは、コードビサイド内に特定のシグネチャを持つメソッドへの参照を含む。他の実施例では、送信アクティビティのメタデータは、特定のシグネチャのコードビサイドメソッドへのオプションの参照に加えてメッセージ宣言およびチャネル宣言への必須参照を含む。

コードビサイドの使用例としては、変数、メッセージ、チャネル、および相関関係集合の宣言、ｉｎ／ｏｕｔ／ｒｅｆパラメータの宣言、追加カスタムプロパティの宣言、送信するメッセージの準備、受信されたメッセージの処理、論理値を返すコードで表現されたルールの実装、ローカルで定義されている変数の操作、アクティビティメタデータおよびインスタンスデータの読み取り、アクティビティインスタンスデータの書き込み（例えば、実行されようとしているアクティビティに関するプロパティの設定）、イベントの発生、例外のスロー、横断的なネストされているスコープおよびスケジュール呼び出し境界を含む実行スケジュールインスタンスのアクティビティツリー内のアクティビティの階層の列挙およびナビゲート、実行スケジュールインスタンス内で複合アクティビティへの新規アクティビティの追加、実行スケジュールインスタンス内のアクティビティに関連付けられている宣言的ルールの変更、ならびに他の実行スケジュールインスタンスへの参照の取得および他の実行スケジュールインスタンスの操作が挙げられる。
ワークフローを設計するためのユーザインターフェイス
図４を参照すると、ブロック図は、ワークフローを作成するためにユーザと本発明との間で行われるやり取りを例示している。ユーザ４０２は、ディスプレイ４０４（例えば、表示装置、またはアプリケーションプログラムの実行環境内の表示領域）およびユーザインターフェイス選択装置４０６を対話形式で操作し、コンピュータ実行可能コンポーネントを介してワークフローを設計する。ワークフローをモデル化するためのコンピュータ実行可能コンポーネントは、コンピュータ可読媒体４１０などの１つまたは複数のコンピュータ可読媒体上に格納され、レンダリングコンポーネント４１２、インターフェイスコンポーネント４１４、デザイナコンポーネント４１６、およびバリデーションコンポーネント４１８を含む。レンダリングコンポーネント４１２は、ディスプレイ４０４上に複数のアクティビティを表示する。インターフェイスコンポーネント４１４は、ユーザインターフェイス選択装置４０６を介してユーザ４０２からレンダリングコンポーネント４１２により表示されるアクティビティの選択を受け取る。レンダリングコンポーネント４１２は、さらに、ディスプレイ４０４上に、インターフェイスコンポーネント４１４が受け取ったアクティビティの選択を表示する。インターフェイスコンポーネント４１４は、さらに、ユーザインターフェイス選択装置４０６を介してユーザ４０２から構造情報を受け取る。デザイナコンポーネント４１６は、ワークフローを作成するために受け取った構造情報に従ってディスプレイ４０４上にアクティビティの選択を配列する。バリデーションコンポーネント４１８は、定義済みインターフェイス要件への適合具合の意味論を評価する。

一実施形態では、本発明は、インク対応であり、ユーザ４０２からワークフローの手描き表現を受け取るためのタッチスクリーン４３６を備える。本発明は、手描きワークフローをワークフローに変換する。インクワークフローの実施例が図５に示されている。ユーザ４０２が「ａｕｔｏ−ｒｅｃｏｇｎｉｚｅ」を選択した後、ワークフローは図６に示されているワークフローに変換される。インク対応実施形態を使用すると、ユーザ４０２は、タブレットコンピューティング装置と互換性のあるワークフローデザイナをビルドすることができる。インク対応ワークフローデザイナでは、ユーザ４０２は、ペン、ポインティング装置などをワークフロー作成プロセス全体にわたって使用することができる（例えば、追跡データの分析を含む最初のスケッチ段階から実行および実行後段階まで）。このような実施形態では、コンピュータ実行可能コンポーネントは、さらに、パレットコンポーネント４２２、レコグナイザコンポーネント４２０、スキンコンポーネント４２４、およびワークフローコンポーネント４２６を含む。パレットコンポーネント４２２は、複数のパレット要素を定義する。定義済みの複数のパレット要素はそれぞれ、複数のアクティビティのうちの少なくとも１つに対応する。インターフェイスコンポーネント４１４は、タッチスクリーン４３６を介してユーザ４０２から複数のグラフィック要素を受け取る。受け取った複数のグラフィック要素を配列してワークフローを作成する。レコグナイザコンポーネント４２０は、インターフェイスコンポーネント４１４が受け取った複数のグラフィック要素のそれぞれをパレットコンポーネント４２２によって定義されたパレット要素の１つに関連付け、ワークフローをタッチスクリーン４３６に表示するように関連付けられたパレット要素を配列する。スキンコンポーネント４２４は、受け取ったユーザ定義テーマをタッチスクリーン４３６に表示されるワークフローに適用する。ワークフローコンポーネント４２６は、レコグナイザコンポーネント４２０により配列された関連付けられたパレット要素に応じてワークフローを作成する。

特に、ユーザ４０２は、タブレットコンピューティング装置上にプロセスをグラフィックでスケッチする。本発明では、プロセスおよび、パラレル、決定、ループ、およびイベント／アクティベーション条件などのプロセスコンストラクトを対話形式で操作するためのさまざまなプロセス定義スイムレーン（swim lanes）をサポートする。その後、本発明のソフトウェアは、グラフィカルスケッチを、スケッチ中にオンザフライで、またはユーザ４０２によるスケッチが完了した後に、プロセス定義に変換する。次に、グラフィカルスケッチを、ディスプレイ４０４上で、標準の記号および要素を持つワークフローに置き換えることができる。ユーザ４０２は、表示されたワークフローを編集し、ワークフローのコメント（例えば、シングルユーザまたはマルチユーザのシナリオ）を追加または削除し、表示されているワークフロー要素に修正を加えることができる。特に、ユーザ４０２は、既存のワークフロー上でコメント、ノート、および／またはメモを描くか、または書くことにより注釈を付けることができ、本発明は、ワークフロー表現および周囲形状に関するインクの位置とともにインクを格納する。

さらに、ユーザ４０２は、追加スケッチを描画するか、または編集と解釈される標準ジェスチャー（例えば、削除、コピー、移動）を描画するか、または特定のアクティビティ型を挿入することにより、プロセス定義を修正することができる。本発明は、さらに、描画とプロセス定義との間のラウンドトリッピングをサポートする。例えば、プロセス定義は、描画が変化したときに更新され、またその逆も真である。

本発明では、描画を作成されたプロセス定義とともに格納する。一実施形態では、これは、ユーザ描画時にプロセス実行の進捗状況を示すために使用することができる。例えば、ビジネスアナリストは、ワークフローを描画し、それを、ワークフローをプロセス定義に変換し、コンパイルし、プロセス実行を開始する開発者に与える。ビジネスアナリストは、プロセス定義ビューまたはドローイングペインのいずれかの実行中のプロセスを見る。

本発明では、さらに、ユーザ４０２は、描くおよび／または書く操作を介して稼働中（例えば、実行中）ワークフローとやり取りすることができる。例えば、ユーザ４０２は、管理ビュー内の稼働中プロセスの実行（例えば、起動／停止／終了）を制御するか、またはペン、ポインティング装置などで入力を書き込むことによりワークフローと通信することができる。特定の形状を削除または挿入するなど本発明により認識されるジェスチャーは、ジェスチャーの定義済み集合に限られない。つまり、ユーザ４０２は、本発明のソフトウェアが認識するカスタムジェスチャーを作成することができる。

一実施形態では、本発明は、ビジネスアナリストを対象とするスタンドアロンアプリケーションとして具現される。他の実施形態では、本発明は、アプリケーションプログラムで使用するワークフローデザイナとして具現される。つまり、図４に例示されているコンポーネントは、アプリケーションプログラムの実行環境内で実行される。

他の実施形態では、プロセッサ４０８は、ワークフローをモデル化するコンピュータ実行可能命令を実行するように構成され、メモリ領域４２８にアクセスすることができる。メモリ領域４２８は、複数のアクティビティ４３０を格納する。プロセッサ４０８は、ユーザ４０２からアクティビティ４３０の選択を受け取り、ディスプレイ４０４上にアクティビティ４３０の受け取った選択を表示し、ユーザ４０２から構造情報を受け取り、受け取った構造情報に従ってディスプレイ４０４上にアクティビティ４３０の表示される選択を配列してワークフローを作成するコンピュータ実行可能命令を実行する。

タッチスクリーン４３６またはポインティング装置などに反応するディスプレイ４０４などの他のディスプレイを含む一実施形態では、メモリ領域４２８は、さらに、ディスプレイ４０４およびオプションによりポインティング装置を介してユーザ４０２から受け取った複数のグラフィック要素４３２を格納する。グラフィック要素４３２は、ワークフローを表すようにユーザ４０２により配列される。メモリ領域４２８は、さらに、それぞれアクティビティ４３０のうちの少なくとも１つに対応する複数のパレット要素４３４を格納する。このような実施形態では、プロセッサ４０８は、さらに、メモリ領域４２８に格納されているグラフィック要素４３２のそれぞれを複数のパレット要素４３４のうちの１つにマッピングし、マッピングされたパレット要素４３４に応じてワークフローを作成し、ディスプレイ４０４上にワークフローを表示するコンピュータ実行可能命令を実行するように構成される。

図４に例示されている要素は、アクティビティ４３０などの複数のアクティビティを表示する手段の実施例、アクティビティの選択を受け取る手段の実施例、ユーザ４０２から構造情報を受け取る手段の実施例、およびワークフローを作成するために受け取った構造情報に従ってアクティビティの表示された選択を配列する手段を実施例の構成要素となる。さらに、ポインティング装置は、デジタルペンまたはスタイラスなどを介して情報を伝達する手段の実施例を構成し、ディスプレイ４０４は、デジタルペンまたはスタイラスなどから入力を受け取る手段の実施例を構成し、プロセッサ４０８は、ユーザ４０２からグラフィック要素４３２などの複数のグラフィック要素を受け取ってそれに応じてワークフローを作成する手段の実施例の構成要素となる。

再び図４を参照し、次に図７を参照すると、流れ図は、ワークフローをモデル化する方法を例示している。この方法は、７０２でディスプレイ４０４上に複数のアクティビティ４３０を表示すること、７０４でユーザインターフェイス選択装置４０６を介してユーザ４０２からアクティビティ４３０の選択を受け取ること、７０６でディスプレイ４０４にアクティビティ４３０の受け取った選択を表示すること、７０８でユーザインターフェイス選択装置４０６を介してユーザ４０２から構造情報を受け取ること、および７１０でワークフローを作成するために受け取った構造情報に従ってディスプレイ４０４にアクティビティ４３０の表示される選択を配列することを含む。一実施形態では、複数のアクティビティ４３０を表示することは、複数のアクティビティ４３０をディスプレイ４０４上のパレット表示領域および／またはワークスペース表示領域内に表示することを含む。

次に図８を参照すると、タッチスクリーンの実施形態では、この方法は、さらに、８０２で定義されている複数のパレット要素のそれぞれが複数のアクティビティのうちの少なくとも１つに対応する複数のパレット要素を定義すること、８０４でワークフローを作成するために受け取った複数のグラフィック要素が配列されるタッチスクリーンを介してユーザから複数のグラフィック要素を受け取ること、８０６で受け取った複数のグラフィック要素のそれぞれを定義されているパレット要素のうちの１つに関連付けることにより受け取った複数のグラフィック要素のそれぞれを認識すること、および８０８でワークフローを表示するように関連付けられているパレット要素をタッチスクリーン上に配列することを含む。

一実施形態では、コンピュータ可読媒体４１０、４２８などの１つまたは複数のコンピュータ可読媒体は、図７および図８に例示されているメソッドを実行するコンピュータ実行可能命令を持つ。

ワークフローステンシル（Workflow Stencils）
ワークフローステンシル（例えば、ワークフローテンプレートまたはアクティビティパッケージ）は、ルートアクティビティおよびアクティビティの集合を含む。ステンシルは、領域および／またはホスト固有である。前者の実施例としては、構造化ワークフローステンシル、ヒューマンワークフローステンシル、および非構造化ワークフローステンシルがある。いくつかのステンシルは、場合によっては特定のホスト環境内で連携するように設計されている１つまたは複数のルートを含むアクティビティの集合として「閉じて」いてもよい。他のステンシルは、さまざまな程度で「開いて」いてもよい。ステンシルは、その拡張性ポイントを定める。例えば、開発者は、ＣｕｓｔｏｍＲｏｏｔおよび新しい抽象ＣｕｓｔｏｍＡｃｔｉｖｉｔｙを書いて、パッケージがＣｕｓｔｏｍＲｏｏｔであり、さらにＣｕｓｔｏｍＡｃｔｉｖｉｔｙから派生したアクティビティであると宣言する。

ＢＰＥＬまたはＸＬＡＮＧ／Ｓステンシルの実施例は、状態管理およびトランザクションに参加する、関連付けられたイベントおよび例外ハンドラを備える、コントラクトファーストモデル（contract first model）をサポートする、分析できる、正しく定義されたアクティベーションおよび終了ビヘイビアを持つ、という特性を有するルートアクティビティを含む。ステンシルの実施例は、さらに、メッセージング特有のアクティビティの集合（例えば、ＳｅｎｄおよびＲｅｃｅｉｖｅおよびその変種）およびＳｃｏｐｅ、Ｌｏｏｐ、Ｃｏｎｄｉｔｉｏｎ、Ｌｉｓｔｅｎ、およびＴｈｒｏｗなどの他の構造化アクティビティを含む。

Ｈａｌｉｆａｘ Ｓｔｅｎｃｉｌの実施例は、暗黙の状態管理関連の例外ハンドラ（０〜ｎ）、イベントベースのモデルをサポートする、適切に定義されたアクティベーションビヘイビアを持つ、および未定義の終了がある、という特性を備えるルートアクティビティを含む。ルートアクティビティは、０〜ｎのＥｖｅｎｔＤｒｉｖｅｎアクティビティを含む。それぞれのＥｖｅｎｔＤｒｉｖｅｎ Ａｃｔｉｖｉｔｙは、Ｈａｌｉｆａｘ Ａｃｔｉｏｎを表す。それぞれのＥｖｅｎｔＤｒｉｖｅｎ Ａｃｔｉｖｉｔｙは、関連付けられた状態管理プロトコルを有し、アトミックスコープ内で実行される。

デザイナフレームワーク（ユーザインターフェイス）
オーケストレーションエンジンは、ＷＹＳＷＹＧ方式でさまざまなクラスのワークフローモデルを設計するためのフレームワークを備える。例えば、図９を参照すると、ワークフローオーサリングするための高水準アプリケーションユーザインターフェイスは、ワークフローの指定にウィザードに依存している。このフレームワークは、開発者がビジュアルワークフローデザイナを書けるようにするサービスおよびビヘイビアの集合を含む。これらのサービスは、ワークフロープロセスのレンダリング、フローを描画するためのインク／タブレットのサポート、および元に戻す／繰り返し、ドラッグ／ドロップ、切り取り／コピー／貼り付け、ズーム、パン、検索／置換、ブックマーク、装飾、バリデーションエラー用のスマートタグ、アクティビティ用の有効なドロップターゲットインジケータ、自動レイアウト、ビューページ付け、ナビゲーションマーカー、ドラッグインジケータ、ヘッダ／フッタ付き印刷およびプレビューなどの効率的方法を提供する。このようなユーザインターフェイスを使用することで、タスクおよび制御フロー複合アクティビティ（例えば、シーケンス、パラレル、および条件付き）を含む単純なワークフローを構成することができる。ルール指定（例えば、条件付き分岐ロジック、ｗｈｉｌｅループロジック）、またはデータフロー指定（例えば、タスクＡの出力がタスクＢへの入力である）のいずれにも、コードの入力（または既存のコンパイル済みコードへの依存）は不要である。スケジュールのシリアライズされた表現（ルールおよびデータフローを含む）は、コードビサイドが必要ないいくつかのシナリオでは自己充足しており、完全である。

本発明のデザイナフレームワークを使用することで、本発明のオーケストレーションエンジンは、ソフトウェアコードをビジュアルな形でワークフローモデルに関連付ける機能をサポートするアプリケーション短期開発（ＲＡＤ）スタイルのビジュアルワークフローデザイナを含む。ワークフロー内のそれぞれのアクティビティは、関連付けられたアクティビティデザイナを備える。それぞれのアクティビティデザイナは、フレームワークサービスに関して作成される。本発明のフレームワークは、さらに、ビジュアルデザイナモデルも含む。ビジュアルデザイナモデルは、ワークフローモデルで記述された関係を介して互いにリンクされているアクティビティデザイナの集合を含む。図１０は、ワークフローデザイナの実施例を示す。ビジュアルデザイナおよびアクティビティデザイナについては、付録Ｂで詳しく説明する。本発明は、ユーザコードとワークフローモデルとの間のラウンドトリッピングをリアルタイムで可能にする「Ｃｏｄｅ−Ｂｅｓｉｄｅ」、「Ｃｏｄｅ−Ｗｉｔｈｉｎ」、および「Ｃｏｄｅ−Ｏｎｌｙ」を含むコードをワークフローモデルに関連付けるさまざまなモードを含む。本発明は、さらに、ユーザがワークフロー構築している最中にリアルタイムで意味論的エラーを提示する。

オーケストレーションエンジンデザイナでは、ユーザはそのために他の作成済みスケジュールを使用し、それらを使用して上位のスケジュールを再帰的に作成することができる。スケジュールのインライン展開では、ユーザはスケジュールコンテンツをインラインで表示し、コンテンツを切り取ったりコピーしたりすることができる。スケジュールのインライン展開を有効にし、スケジュールを読み取り専用にするには、インラインスケジュールに対して別のデザインサーフェスおよびデザイナホストを作成する。さらに、複合スケジュールデザイナはそれ独自の階層を持つ。呼び出されたスケジュールはロードされ、ユーザによってデザイナが展開されたときに表示される。一実施形態では、デザイナは、デザインサーフェス上でアクティビティドロップまたはコピーされた場合に縮小するプロパティは、呼び出し側アクティビティデザイナをホスティングされたスケジュールのルートデザイナに連鎖する。以下の関数は、デザイナからアクティビティの追加および削除を行うことを禁止する。
internal static bool AreAllComponentsInWritableContext(Icollection components)
internal static bool IsContextReadOnly(IServiceProvider serviceProvider)
これらの関数は、アクティビティが挿入されるコンテキストが書き込み可能かどうかをチェックするためにインフラストラクチャにより呼び出される。ホスティングされたデザイナでは、これらの関数はｆａｌｓｅを返す。さらに、プロパティの修正が禁止される。他の関数は、適切なコンポーネントからアクティビティデザイナをフェッチする。
internal static ServiceDesigner GetSafeRootDesigner(IServiceProvider serviceProvider)
internal static ICompositeActivityDesigner GetSafeParentDesigner(object obj)
internal static IActivityDesigner GetSafeDesigner(object obj)
一実施例では、ユーザはスケジュールを作成し、それをアクティビティとしてコンパイルする。コンパイルに成功すると、スケジュールはツールボックス上に表示される。ユーザは、コンパイルされたスケジュールの使用が望ましいスケジュールを開くか、または作成する。ユーザは、ツールボックスからコンパイル済みスケジュールをドラッグ＆ドロップする。縮小されたスケジュールデザイナがデザインサーフェスに示される。ユーザがドロップされたコンパイル済みスケジュールのコンテンツを表示したい場合、ユーザはそのスケジュールデザイナを展開して、呼び出されたスケジュールのコンテンツを読み取り専用状態でインライン表示する。呼び出されたスケジュールのインライン化により、ユーザはスケジュールデザイナ同士を切り換えなくても呼び出されたスケジュールを表示することができる。この機能は、既存のスケジュールを再利用して上位スケジュールを作成する開発者に有用な機能である。

テーマ／スキンを使用したデザイナフレームワークのカスタマイズのサポート
デザイナフレームワークを使用して書かれたワークフローデザイナは、ワークフローテーマを使用してカスタマイズすることができる。これらは、デザイナのさまざまな態様を宣言的に記述する拡張マークアップ言語（ＸＭＬ）ファイルとすることができる。ワークフローデザイナは、アクティビティを拡張するパートナのサポートをウィザードで対応している。ワークフローデザイナによりサポートされるユーザインターフェイス機能の例として、限定はしないが、元に戻す／繰り返し、ドラッグ／ドロップ、切り取り／コピー／貼り付け、ズーム、パン、検索／置換、ブックマーク、装飾、バリデーションエラー用のスマートタグ、アクティビティ用の有効なドロップターゲットインジケータ、自動レイアウト、ビューページ付け、ナビゲーションマーカー、ドラッグインジケータ、ヘッダ／フッタ付き印刷およびプレビュー、およびドキュメントアウトライン統合がある。ワークフローデザイナは、ＸＭＬメタデータを使用してデザイナのルック＆フィールをカスタマイズできるカスタムデザイナテーマ／スキンをサポートする。例えば、ワークフローデザイナは、ユーザからカスタマイズ情報を受け取る。ワークフローデザイナでは、バックグラウンドコンパイルをサポートする。一実施例では、スケジュールを設計しながらバリデーションエラーを調べるスマートタグおよびスマートアクションが用意される。ワークフローデザイナは、任意のコンテナ（例えば、アプリケーションプログラム、シェルなど）でホスティングすることができる。

オーケストレーションエンジンプログラムの一実施例は、送信はアクティビティが後に続く受信アクティビティを含む。このプロセスでは、メッセージを受信して、送出する。ユーザは、「Ｈｅｌｌｏ Ｗｏｒｌｄ」と呼ばれるプロジェクトを作成して、オーケストレーションアイテムをプロジェクトに追加する。ユーザは、その後、スコープアクティビティをデザインサーフェス上にドラッグ＆ドロップする。次に、ユーザは、送信アクティビティが後に続く受信アクティビティをスコープ上にドロップする。図１１は、デザイナ内の結果として得られるワークフロー１１００を例示している。それぞれのアクティビティデザイナは、オブジェクトモデル上のユーザインターフェイス表現を提供する。開発者は、オブジェクトモデルを直接プログラムして、アクティビティのプロパティを設定するか、またはデザイナを使用することができる。オーケストレーションエンジンデザイナを使用することにより、開発者はツールボックスからアクティビティを選択し、それをデザイナサーフェス上にドラッグすることができる。アクティビティがすでにスケジュールに入れられており、移動する必要がある場合、開発者は、それを選択して（それをクリックすることにより）、そのアクティビティを入れる必要のあるスケジュールの領域にドラッグすることができる。開発者がコントロールキーを押しながらドラッグ＆ドロップを行うと、選択されたアクティビティのコピーが作成される。

アクティブな配置では、可能なドロップポイント（ターゲット）をデザインサーフェス上にビジュアルインジケータとして用意する。自動スクロール機能も、ドラッグ＆ドロップのコンテキスト内で関与する。大きなスケジュールを取り扱う場合、現在ビューポート内にないデザイナの領域へのナビゲーションは、入れるスケジュールの領域に向かってアクティビティをドラッグすることによりアクセス可能である。

ドラッグ＆ドロップは、同じプロジェクト内のスケジュール間で、また同じソリューション内の他のプロジェクト内のスケジュール間でサポートされる。アクティビティがデザインサーフェス上に配置された後、開発者はそのアクティビティの構成を設定する。各アクティビティは、スケジュールが有効なものとなるように開発者が構成する一連のプロパティを持つ。これらのプロパティは、プロパティブラウザで編集可能である。すべてのアクティビティは、プロパティブラウザ内にどのようなプロパティを表示できるかを制御する。開発者がさまざまなアクティビティを構成するのを補助するため、デザイナはさまざまなダイアログまたは「サブデザイナ」を備えている。ダイアログは、それぞれ、アクティビティのさまざまなプロパティについて呼び出される。

オーケストレーションエンジンは、ツールボックス内に提示されるアクティビティをカスタマイズすることができる。開発者がカスタムアクティビティまたはスケジュールを作成する場合、最終結果はアセンブリである。ダイアログを使用することにより、開発者は、アセンブリロケーションに移動してブラウズし、そのアセンブリを選択してオーケストレーションエンジンアクティビティとして現れるようにすることができる。それとは別に、開発者は、オーケストレーションエンジンのインストールパス内にそのアセンブリを置くことができ、オーケストレーションエンジンアクティビティとして存在することになる。

アプリケーションプログラミングインターフェイス（ＡＰＩ）
他の実施形態では、本発明は、さまざまなワークフローオペレーションを実行するためのアプリケーションプログラミングインターフェイス（ＡＰＩ）を備える。ハードウェア、ソフトウェア、および１つまたは複数のアプリケーションプログラミングインターフェイスは、ワークフローをオーサリングする手段の実施例、アクティビティの１つまたは複数を選択してワークフローを作成する手段の実施例、ワークフローをシリアライズする手段の実施例、ワークフローの視覚的表示をカスタマイズする手段の実施例、ワークフローの妥当性確認を行う手段の実施例、ワークフローをコンパイルする手段の実施例、および型をワークフロー内のアクティビティのそれぞれに関連付ける手段の実施例の構成要素となる。

アクティビティ実行フレームワーク
スケジュールおよびスコープを除き、エンジンは、アクティビティを抽象エンティティとして表示し、単に、特定のアクティビティの特定のデータまたは意味論を知らずにアクティビティの実行を簡単に調整する。一実施形態では、４つのエンティティは、アクティビティ自体、実行中のアクティビティの親アクティビティ、実行中のアクティビティを閉じるスコープ、およびオーケストレーションエンジンの実行中にやり取りをする。それぞれのエンティティは異なる関数を持つ。

完了をアクティビティコーディネータに知らせることなくアクティビティの実行メソッドが戻る場合、そのアクティビティは、論理的待ち状態にあると識別される。このようなアクティビティは、オーケストレーションエンジンによりキャンセルするか、または継続することができる（例えば、待っているアイテムまたはイベントが利用可能になるか、または実行され、エンジンによりこれにアクティビティが通知された後）。

論理的待ち状態に決して入らないいくつかのアクティビティは、決してキャンセルできない。実施例は、送信アクティビティおよびコードアクティビティを含むが、これらは外部イベントまたはサブスクリプションへの要求なしで実行されるからである。スレッドを渡された後（つまり、実行メソッドがオーケストレーションエンジンにより呼ばれた後）、これらのアクティビティは完了するまで動作し続ける。完了を通知するまでスレッドを返さないので、オーケストレーションエンジンにはキャンセルする機会が決して与えられない。

オーケストレーションエンジンのランタイムは、ルールを使用して、オーケストレーションエンジンアクティビティが実行されるイベントをトリガする。オーケストレーションエンジンデザイナは、関連付けられたルールを実行時に評価し、イベントを取り出するユーザ機能を提供する。オーケストレーションエンジンデザイナを利用することで、ユーザは、拡張性アーキテクチャを用意することによりさまざまな種類のルール技術を使用できる。デザイナは、使用されるルールの型には関知しない。

一実施形態では、デザイナは、ルールをアクティビティに関連付ける手段として論理式ハンドラをサポートしている。これは、ユーザコードファイル内で、ユーザが値ｔｒｕｅまたはｆａｌｓｅを返すメソッドを書くことを意味し、それに基づいてルールがトリガされる。現在、Ｉｎｆｏ ＡｇｅｎｔおよびＢｕｓｉｎｅｓｓ Ｒｕｌｅｓ Ｅｎｇｉｎｅ（ＢＲＥ）を含むルールを評価するために使用することもできる複数の技術がある。これを達成するために、デザイナは、ルール技術開発者がデザイナでカスタムユーザインターフェイスをホスティングできるようにする拡張性アーキテクチャを備える。デザイナは、コードステートメントコレクションの形でルールをシリアライズするカスタムユーザインターフェイスライター向けの手段を用意している。デザイナは、コードステートメントコレクションが中に挿入されているユーザコードファイル内にブールハンドラを生成し出力する。オーケストレーションエンジンは、ルールライターにより使用することもできる既定のユーザインターフェイスを含む。ルール技術プロバイダは、カスタムルール宣言を作成し、そのカスタムルール宣言に関連付けられたユーザインターフェイスタイプエディタを書き、ルールユーザインターフェイスをホスティングするカスタムユーザインターフェイスを作成し、保存後にコードステートメントを生成することによりオーケストレーションエンジンデザイナにルールを追加する。

一実施例では、ユーザは、ルールがアタッチされる必要のあるアクティビティデザイナを選択し、プロパティブラウザでルールプロパティを特定し、ドロップダウン内の「ＲｕｌｅＥｘｐｒｅｓｓｉｏｎＨａｎｄｌｅｒ」を選択し（「Ｓｔａｔｅｍｅｎｔｓ」プロパティがユーザインターフェイス内のＲｕｌｅ Ｐｒｏｐｅｒｔｙの下に表示されるようにする）、「Ｓｔａｔｅｍｅｎｔｓ」プロパティ内のユーザコードメソッド名を指定し、ユーザインターフェイスタイプエディタを呼び出してルール特有のユーザインターフェイスをホスティングするダイアログを呼び出し、新しい述語行を作成しそれらをグループ化することによりダイアログ内でルールを定義する。ユーザインターフェイスは、ユーザコードファイルにメソッドを生成して出力する。メソッド名は、プロパティブラウザでユーザが指定したのと同じものである。ルールを作成することに相当するコードステートメントが、ルール用のユーザコードメソッド内に挿入される。

実行時のメッセージング
実行ワークフローでは、スケジュールに送られるメッセージは、特定のスケジュールインスタンス向けである。例えば、発注書＃１２３に対するインボイスをその発注書を発信した（例えば、送出した）のと同じスケジュールインスタンスに送り返さなければならない。受信メッセージと適切なスケジュールインスタンスとを照合するために、メッセージおよびスケジュールインスタンスは相関関係集合を共有する。相関関係集合は、メッセージ内の識別子フィールドがスケジュールインスタンスにより保持される同じ型の識別子と突き合わせて照合されることを意味する一価相関関係集合でよい。多プロパティ相関関係集合も、可能であり、データベーステーブル内の複数列主キーに類似している。

スケジュールインスタンスにより保持されている相関関係集合の値は、スケジュールインスタンスがメッセージを送出するか（例えば、値は送信発注書の識別子フィールドから取り出せる）、またはメッセージを受信するときに初期化される。その後、この相関関係集合値は、そのスケジュールインスタンスの状態の一部となる。後続の受信メッセージが到着すると、スケジュールインスタンス状態で保持されている相関関係集合値は、予想される型の受信メッセージにより保持されている識別子と突き合わせて照合される。一致が見つかった場合、相関関係集合は満たされ、メッセージがスケジュールインスタンスに配送される。

相関関係集合の実装はオーケストレーションエンジンおよびホスト環境に左右されるが、一実施形態では、ユーザは相関関係集合を宣言してスケジュールインスタンスを正しく動作するようにする。他の実施形態では、いくつかのアクティビティ（例えば、ＳｅｎｄＲｅｑｕｅｓｔ／ＲｅｃｅｉｖｅＲｅｓｐｏｎｓｅアクティビティおよびＲｅｃｅｉｖｅＲｅｑｕｅｓｔ／ＳｅｎｄＲｅｓｐｏｎｓｅアクティビティ）は、ユーザと無関係に相関関係集合をセットアップする。送信および受信アクティビティにより広範にわたるバリデーションチェックが実行され、相関関係集合が正しく初期化され、追随されるようにする。

実行ワークフローの動的編集
オーケストレーションエンジンは、さまざまな種類のワークフローをオーサリングする（そして、その後、ビジュアル化し、実行する）ためのフレームワークを提供する。実施例としては、ｅｖｅｎｔ−ｃｏｎｄｉｔｉｏｎ−ａｃｔｉｏｎ（ＥＣＡ）スタイルのワークフローまたは構造化フローまたはルール駆動フローがある。さらに、ワークフローのモデル化方法に関係なく、フレームワークにより、ユーザは設計時と同じ方法で、またはワークフロープロセスを再コンパイルしなくてもワークフロープロセスが実行しているときであってもワークフローをオーサリングまたは編集することができる。フレームワークを使用すると、ユーザはランタイムと高忠実度の設計時表現との間のラウンドトリッピングが可能になる。アドホックな変更は、プロセスモデルに対し実行時に加えられる変更である。ユーザは、そのスケジュールモデルを実行インスタンスに問い合わせ、モデルに変更を加えることができる。例えば、ユーザは、バッチ式でアクティビティの追加、削除、または置換を行うことができ、その後、バッチ変更をコミットまたはロールバックすることができる。一実施形態では、モデルは更新の後に妥当性確認が行われる。本発明の多くのワークフローシナリオでは、「設計時オーサリング」および「ランタイム実行」との間の分離のぼかし、またはさらには除去がある。

スケジュールインスタンスは、実際に、それらのインスタンスのスケジュール型について定義されているアクティビティ型（メタデータ）ツリーを他のインスタンスと共有する。しかし、スケジュールインスタンスは、実行を開始した後、新しいアクティビティの追加または宣言的ルールの操作を介してオンザフライで変更できる。そのような修正されたスケジュールインスタンスを取り出し、新しいスケジュール型として「名前を付けて保存」するか、またはより一般的に、インスタンスからシリアライズされた表現を単純に復元することが可能である。つまり、実行スケジュールインスタンスを、シリアライズし、その後、デザイナ（例えば、オーサリング環境）またはランタイムビジュアル化ツールに持ち込むことができる。

さらに、上級開発者は、スケジュールを丸ごとソフトウェアコードとしてオーサリングすることも可能である。スケジュール型を直接オーサリングする場合も、開発者は、単に、スケジュールのコードビサイドクラスのソフトウェアコードにＩｎｉｔｉａｌｉｚｅＳｃｈｅｄｕｌｅＭｏｄｅｌという静的メソッドを入れ、このメソッドに［ＳｃｈｅｄｕｌｅＣｒｅａｔｏｒ］属性でマークするだけである。一実施形態では、静的メソッドは、パラメータを取らず、Ｓｃｈｅｄｕｌｅオブジェクトを返す。随伴するシリアライズされたファイルはないが、スケジュールのシリアライズされた表現は、作成されるＳｃｈｅｄｕｌｅオブジェクトから復元できる。これは、単一のソフトウェアコードファイルを使用してスケジュールを作成できることを意味しているが、バリデーションチェックは、このファイルには実行されえない。オーケストレーションエンジンのコンパイルにより、スケジュール型の基礎となっているアクティビティツリーの構造上および意味論的な有効性が保証される。他の実施形態では、コンパイルおよびバリデーションを内部で実行し、実行される実際の型を生成するが、コードの入力は不要である。スケジュール型のコンパイルは、コンパイル時オブジェクトモデルから実行時オブジェクトモデルへの変換がない分、超軽量なプロセスとなっている。本質的に、コンパイルは、単に、スケジュールのオブジェクトモデル表現をコードビサイドと組み合わせて新しい型を生成するだけである。一実施形態では、基本的に、コンパイル済みコードビサイドがオブジェクトモデル内のアクティビティにより要求される内容と一致するか、またはコードビサイドがコンパイル済みフォーム（アセンブリ）内にすでに存在している可能性がある場合には、特定のスケジュールについてコードビサイドを全く生成する必要はないと考えられる。

シリアライズされたスケジュールをコンパイルする場合、そのスケジュールに対するコードビサイドとして実際に使用される既存のコンパイル済み型を指すことが可能である。このコンパイル済み型の派生型が作成され、この新しい型はコードビサイドとして使用され、一意的な型が新しいスケジュールを表すように作成されることが保証される。

シリアライゼーションアーキテクチャ
シリアライゼーションインフラストラクチャは、オーケストレーションエンジンのアクティビティツリーをシリアライズする、モジュール方式の、形式に依存しない、容易に拡張可能なメカニズムを提供する。

特に、呼び出し側（例えば、アプリケーションプログラムまたはユーザ）は、シリアライゼーションマネージャからシリアライザにオブジェクト（またはアクティビティ）Ａを要求する。オブジェクトＡの型のメタデータ属性により、オブジェクトＡは要求された型のシリアライザにバインドされる。次に、呼び出し側は、オブジェクトＡをシリアライズするようにシリアライザに要求する。続いて、オブジェクトＡのシリアライザはオブジェクトＡをシリアライズする。シリアライザは、遭遇するオブジェクト毎に、シリアライズしながら、シリアライゼーションマネージャに追加シリアライザを要求する。シリアライゼーションの結果が呼び出し側に返される。

オーケストレーションエンジンコンポーネントモデル内のすべてのアクティビティは、シリアライゼーションに参加することができる。シリアライザコンポーネントは、一実施形態ではアクティビティクラス自体の一部ではない。その代わりに、このコンポーネントは、アクティビティに関連付けられたクラス内のシリアライザ属性に注釈を入れることにより指定される。シリアライザ属性は、そのアクティビティ型のオブジェクトをシリアライズするために使用されるクラスを指す。他の実施形態では、ある１つのアクティビティ型のプロバイダコンポーネントが、そのアクティビティにより与えられる既定のシリアライザをオーバーライドする。

デザイナシリアライゼーションは、メタデータ、シリアライザ、およびシリアライゼーションマネージャに基づく。メタデータ属性は、型をシリアライザに関係付けるために使用される。「ブートストラッピング」属性は、シリアライザを持たない型に対しシリアライザを提供するオブジェクトをインストールするために使用することができる。シリアライザは、特定の１つの型またはある範囲の複数の型をシリアライズする方法を認識するオブジェクトである。それぞれのデータ形式に対して１つの基本クラスがある。例えば、オブジェクトをＸＭＬに変換する方法を認識するＸｍｌＳｅｒｉａｌｉｚｅｒ基本クラスが考えられる。本発明は、特定のシリアライゼーション形式に関係しない一般的なアーキテクチャである。シリアライゼーションマネージャは、オブジェクトグラフをシリアライズするために使用されるさまざまなシリアライザに対する情報ストアとなるオブジェクトである。例えば、５０個のオブジェクトのグラフは、すべてそれ独自の出力を生成する５０個の異なるシリアライザを持つことができる。シリアライゼーションマネージャを、これらのシリアライザが使用して、必要な場合に互いに通信し合うことができる。

一実施形態では、ジェネリックなオブジェクトメタデータを使用するシリアライザに結合されたシリアライゼーションプロバイダを使用することにより、与えられた型に対するシリアライザを用意する機会がオブジェクトに与えられるコールバックメカニズムを実現する。ＡｄｄＳｅｒｉａｌｉｚａｔｉｏｎＰｒｏｖｉｄｅｒなどのメソッドを通じて、シリアライゼーションマネージャにシリアライゼーションプロバイダを用意することができる。シリアライゼーションプロバイダは、ＤｅｆａｕｌｔＳｅｒｉａｌｉｚａｔｉｏｎＰｒｏｖｉｄｅｒＡｔｔｒｉｂｕｔｅなどの属性をシリアライザに追加することによりシリアライゼーションマネージャに自動的に追加できる。

一実施形態では、オブジェクトはｘｍｌ要素としてシリアライズされる、オブジェクトのプロパティは単純プロパティ（例えば、ｘｍｌ属性としてシリアライズされる）または複合プロパティ（子要素としてシリアライズされる）として分類される、オブジェクトの子オブジェクトは子要素としてシリアライズされる、というルールに従って形式が示される。子オブジェクトの定義は、オブジェクト毎に異なることがある。以下の実施例は、子オブジェクトの１つとしてＳｅｎｄアクティビティを持つ、ｗｈｉｌｅアクティビティのシリアライゼーションである。

シリアライゼーションに使用される言語がＸＯＭＬである一実施形態では、それぞれのＸＯＭＬ要素は、スケジュールがコンパイルされるときにそれぞれのオブジェクトにシリアライズされる。オブジェクトは、単純型と複合型の両方を含む。各アクティビティのＸＯＭＬ表現の間のマッピングとオーサリングオブジェクトモデルへのマッピングについて、次に説明する。ＸＯＭＬのシリアライゼーションは、プリミティブアクティビティと複合アクティビティとで異なる。

プリミティブアクティビティに対する単純型は、アクティビティタイプに関する属性としてシリアライズされる。プリミティブアクティビティに対する複合型は、子要素としてシリアライズされる。例えば、以下に、ＳｅｎｄアクティビティのＸＯＭＬ表現を示す。

プリミティブ型のシリアライゼーションと同様に、複合アクティビティに対する単純型は、アクティビティ型に関する属性としてシリアライズされる。しかし、定義により、複合アクティビティはネストされたアクティビティをカプセル化したものである。それぞれのネストされているアクティビティは、他の子要素としてシリアライズされる。例えば、以下に、ＷｈｉｌｅアクティビティのＸＯＭＬ表現を示す。

プロセス／ワークフロービューとシリアライズされた表現との間に強い関係が存在する。ワークフローのシリアライズされた（例えば、ＸＯＭＬ）表現またはワークフローのコードビサイドでオーサリングした場合、他方は変更を受ける。そのため、アクティビティ（または複合アクティビティの場合にはその構成要素部分）に対するＸＯＭＬを修正すると、開発者がプロセス／ワークフロービューの切り換えを行うときにプロセス／ワークフロービューに直接反映される。逆も言える。プロセス／ワークフロービュー内のアクティビティを修正すると、ＸＯＭＬ内に適切な修正が生じる。例えば、プロセス／ワークフロービュー内でアクティビティを削除すると、同じアクティビティについてＸＯＭＬ内のＸＭＬ要素も削除される。ラウンドトリッピングは、プロセス／ワークフロービューとコードビサイドとの間にも生じる。

ＸＯＭＬコードを作成するときに、ＸＯＭＬ定義が定義済みインターフェイス要件に適合していない場合、違反しているＸＭＬ要素は、下線が付けられるか、または開発者がそれとわかるように他の何らかの方法で視覚的に識別される。開発者がプロセスビューに切り換えた場合、ＸＯＭＬ内にエラーがあると警告され、デザイナがリンクを表示するので、開発者はそのリンクをクリックして、違反している要素にナビゲートする。この同じエラーは、タスクペインにも表示され、そのエラーをダブルクリックすると、開発者はＸＯＭＬの違反要素にナビゲートされる。

ＸＯＭＬファイルからのアクティビティツリーの作成（デシリアライゼーション）
一実施形態では、ＣｒｅａｔｅＥｄｉｔｏｒＩｎｓｔａｎｃｅ（）関数が、ＤｅｓｉｇｎＳｕｒｆａｃｅオブジェクトを作成し、その後、ＤｅｓｉｇｎＳｕｒｆａｃｅオブジェクト上でＢｅｇｉｎＬｏａｄ（）関数を呼び出して実際のローダオブジェクトをその中に渡し、最後に、ＢｅｇｉｎＬｏａｄ（）でＤｅｓｉｇｎｅｒＬｏａｄｅｒ（）関数を呼び出す。ＰｅｒｆｏｒｍＬｏａｄ（）関数は、テキストバッファオブジェクトを読み込み、それをオーケストレーションエンジンコンポーネントモデル階層にデシリアライズする。本発明は、階層内を辿り、アクティビティをデザインサーフェスに挿入し、コンポーネントをＶｉｓｕａｌ Ｓｔｕｄｉｏにロードする。

本発明は、さらに、ＸＯＭＬの変更を監視し、階層およびアイテム識別の変更を追跡して、Ｖｉｓｕａｌ Ｓｔｕｄｉｏのキャッシュ内の値を更新する。二次ドキュメントデータリストは、オーケストレーションエンジンデザイナが作用する、ユーザには見えない二次ドキュメントのリストを含む。例えば、ユーザはコードビサイドファイルを開いていないが、ユーザがオーケストレーションエンジンデザイナ内で変更を加えた場合に、コードビサイドファイルに変更が加えられる。このファイルはユーザには見えないので、ファイルは二次ドキュメントとして保持されるＸＯＭＬファイルが保存されると、必ず、二次ドキュメントも自動的に保存される。これらのファイルの１つの名前が変更されるか、またはファイルが削除された場合、本発明では、それに応じて、対応する二次ドキュメントオブジェクトを更新する。

オブジェクトツリーのデシリアライゼーションガイドラインの例を以下に示す。ｘｍｌ要素は、まず、親オブジェクトのプロパティとして取り扱われる。親オブジェクトが要素のタグ名を持つプロパティを持たない場合、その要素は親オブジェクトの子オブジェクトとして取り扱われる。ｘｍｌ要素は、親オブジェクト上の単純プロパティとして取り扱われる。

上記のシリアライズされたコードを使用するデシリアライゼーションの実施例では、＜Ｗｈｉｌｅ＞要素は、ｘｍｌ名前空間情報を使用して作成されたオブジェクトとして取り扱われる。＜ＣｏｎｄｉｔｉｏｎＲｕｌｅ＞要素は、Ｗｈｉｌｅアクティビティのプロパティとして取り扱われる。＜ＣｏｄｅＥｘｐｒｅｓｓｉｏｎＲｕｌｅＤｅｃｌａｒａｔｉｏｎ＞要素は、値がＣｏｎｄｉｔｉｏｎＲｕｌｅプロパティに適用されるオブジェクトとして取り扱われる。最初に、＜Ｓｅｎｄ＞要素がＷｈｉｌｅアクティビティのプロパティとして試みられるが、「Ｗｈｉｌｅ」アクティビティは、名前「Ｓｅｎｄ」のプロパティを持たず、したがって、＜Ｓｅｎｄ＞要素はオブジェクトとして取り扱われ、ｗｈｉｌｅアクティビティの子アクティビティとして取り扱われる。＜Ｍｅｓｓａｇｅ＞要素は、Ｓｅｎｄアクティビティのプロパティとして取り扱われる。Ｓｅｎｄ 上のＭｅｓｓａｇｅプロパティは読み取り専用なので、Ｍｅｓｓａｇｅ要素のコンテンツは、Ｍｅｓｓａｇｅオブジェクトのコンテンツと考えられる。同様のルールが、＜ＯｎＢｅｆｏｒｅＳｅｎｄ＞および＜ＴｙｐｅｄＣｈａｎｎｅｌ＞要素のデシリアライゼーションに適用される。

ＸＯＭＬコードがきちんとした形でない、ＸｏｍｌＤｏｃｕｍｅｎｔがＸＯＭＬコード内の第１の要素でなく、ＸＯＭＬコード内の第１のアクティビティがデシリアライザできないという第１の条件の下では、ＸＯＭＬデシリアライゼーションは決定的に失敗する開発者に対して、ＸＯＭＬビューからプロセス／ワークフロービューから切り換える場合に、違反している側のＸＭＬ要素にナビゲートするためのエラーメッセージが提示される。

オーケストレーションエンジンデザイナのホスティング
デザイナフレームワークは、どのようなアプリケーションプログラムでもホスティングできる。これは、サードパーティのアプリケーションでそれぞれの環境においてワークフローをレンダリングするのに非常に有用な機能である。またこれにより、サードパーティは、デザインサーフェスを再ホスティングおよびカスタマイズすることで、オーケストレーションエンジンデザイナ周辺のツールを開発することができる。本発明のフレームワークでは、ホスティングコンテナアプリケーション側でエディタおよび／またはテキストバッファなどのサービス群を用意することを想定している。

デザイナを再ホストする１ステップでは、ローダおよびデザインサーフェスを作成する。ローダは、ＸＯＭＬファイルをロードし、アクティビティホストインフラストラクチャを構築する役割を持つ。デザインサーフェスは、その中にデザイナホストインフラストラクチャを保持し、デザインサーフェスをホスティングし、それとやり取りするサービスを提供する。デザインサーフェスは、サービスコンテナだけでなくサービスプロバイダとしても機能する。一実施例では、以下のコードを実行して、ＸＯＭＬドキュメントをロードし、その中にアクティビティを保持するデザイナホストを構築する。

以下のサービスでは、デザイナで異なる機能を使用できる。ＩＳｅｌｅｃｔｉｏｎＳｅｒｖｉｃｅ関数は、選択されたオブジェクトを保持する。ＩＴｏｏｌｂｏｘＳｅｒｖｉｃｅ関数は、ツールボックスとのやり取りを管理する。ＩＭｅｎｕＣｏｍｍａｎｄＳｅｒｖｉｃｅ関数は、メニューとのやり取りを管理する。ＩＴｙｐｅＰｒｏｖｉｄｅｒ関数を使用すると、タイプシステムを利用できる。さらに、高度なデザイナ機能を使用可能にするデザイナホスティング環境が提供する追加サービスもありえる。

タイプシステムは、本発明のコンポーネントモデルフレームワーク内の一コンポーネントである。デザイナがプロジェクトシステムの内側でホスティングされる場合、ＴｙｐｅＰｒｏｖｉｄｅｒオブジェクトがプロジェクト毎に作成される。プロジェクト内のアセンブリ参照はタイププロバイダへプッシュされる。さらに、プロジェクト内のユーザコードファイルが解析され、単一コードコンパイル単位が作成され、タイププロバイダへプッシュされる。また、本発明は、タイプシステム内で型を変更させることが可能なプロジェクトシステム内のイベントを監視し、その変更に対する応答として型を再ロードする適切な呼び出しをタイププロバイダに対し実行する。

元に戻す／繰り返し
スケジュールを作成し、正しく構築した後、開発者は一連の実行済みオペレーションをロールバックしたい場合がある。本発明の「元に戻す」および「繰り返し」機能を使用すると、どのアクティビティが直接影響を受けているかを例示する視覚的フィードバックが得られる。例えば、アクティビティ上でプロパティの変更が元に戻される場合、影響を受けたアクティビティは選択状態になる。複数のオブジェクトの削除が元に戻される場合、関わっているすべてのオブジェクトが、スケジュールに復元されるときに選択状態になる。Ｕｎｄｏ／Ｒｅｄｏ（元に戻す／繰り返し）は、他の分野における多くのアプリケーション全体を通して使用される共通の機能であり、その意味はよく理解されている。オーケストレーションエンジンデザイナでは、Ｓａｖｅ後に、元に戻す／繰り返しアイテムがパージされることはない。さらに、元に戻す／繰り返しは、プロセス／ワークフロービューで、ＸＯＭＬビューで、開発者がビューを切り換えた場合に、およびコードビサイド内で実行することができる。

Ｕｎｄｏ／Ｒｅｄｏは、プロセス／ワークフロービュー内のアクション、つまり、アクティビティのドラッグ＆ドロップ（例えば、ツールボックスからデザインサーフェスにアクティビティをドラッグする、スケジュールの一部分から他の部分にアクティビティを移動する、一方のデザイナから他方のデザイナにアクティビティを移動する）、アクティビティの構成（例えば、アクティビティのプロパティを指定する）、および切り取り／コピー／貼り付け／削除のアクションに対し用意されている。

一実施形態では、シリアライズされたビュー（例えば、ＸＯＭＬビュー）は、テキストエディタ標準の元に戻す／繰り返しオペレーションを備えるＸＭＬエディタである。本発明のデザイナは、プロセス／ワークフロービュー内で加えられた変更を示すフィードバックを開発者に提示し、その後、シリアライズされたビュー内で元に戻した結果として、シリアライズされたコードは失われる。開発者がプロセス／ワークフロービュー内のスケジュールの一部分を構築し、シリアライズされたビューに切り換えて、その後、元に戻す／繰り返しオペレーションを実行することに決めた場合、警告が表示される。

動作環境の例
図１２は、コンピュータ１３０の形態の汎用コンピューティング装置の一実施例を示している。本発明の一実施形態では、コンピュータ１３０などのコンピュータは、例示され、本明細書で説明されている他の図で使用するのに適している。コンピュータ１３０は、１つまたは複数のプロセッサまたは演算処理装置１３２およびシステムメモリ１３４を備える。例示されている実施形態では、システムバス１３６は、システムメモリ１３４を含むさまざまなシステムコンポーネントをプロセッサ１３２に結合する。バス１３６は、メモリバスまたはメモリコントローラ、周辺機器バス、アクセラレイティッドグラフィックスポート、およびさまざまなバスアーキテクチャのどれかを使用するプロセッサまたはローカルバスを含む数種類のバス構造のうちの１つまたは複数を表している。例えば、限定はしないが、このようなアーキテクチャとしては、Ｉｎｄｕｓｔｒｙ Ｓｔａｎｄａｒｄ Ａｒｃｈｉｔｅｃｔｕｒｅ（ＩＳＡ）バス、Ｍｉｃｒｏ Ｃｈａｎｎｅｌ Ａｒｃｈｉｔｅｃｔｕｒｅ（ＭＣＡ）バス、Ｅｎｈａｎｃｅｄ ＩＳＡ（ＥＩＳＡ）バス、Ｖｉｄｅｏ Ｅｌｅｃｔｒｏｎｉｃｓ Ｓｔａｎｄａｒｄｓ Ａｓｓｏｃｉａｔｉｏｎ（ＶＥＳＡ）ローカルバス、およびＭｅｚｚａｎｉｎｅバスとも呼ばれるＰｅｒｉｐｈｅｒａｌ Ｃｏｍｐｏｎｅｎｔ Ｉｎｔｅｒｃｏｎｎｅｃｔ（ＰＣＩ）バスがある。

コンピュータ１３０は、通常、少なくともある種の形態のコンピュータ可読媒体を備える。コンピュータ可読媒体は、揮発性および不揮発性媒体、取り外し可能および取り外し不可能媒体を含み、コンピュータ１３０によってアクセスできる媒体であればどのような媒体でもよい。例えば、限定はしないが、コンピュータ可読媒体は、コンピュータ記憶媒体および通信媒体を含む。コンピュータ記憶媒体は、コンピュータ可読命令、データ構造体、プログラムモジュール、またはその他のデータなどの情報を格納する方法または技術で実装される揮発性および不揮発性、取り外し可能および取り外し不可能媒体を含む。例えば、コンピュータ記憶媒体は、ＲＡＭ、ＲＯＭ、ＥＥＰＲＯＭ、フラッシュメモリまたはその他のメモリ技術、ＣＤ−ＲＯＭ、デジタル多目的ディスク（ＤＶＤ）またはその他の光ディスク記憶装置、磁気カセット、磁気テープ、磁気ディスク記憶装置またはその他の磁気記憶装置、または所望の情報を格納するために使用することができ、しかもコンピュータ１３０によりアクセスできるその他の媒体を含む。通信媒体は、通常、コンピュータ可読命令、データ構造体、プログラムモジュール、または搬送波もしくはその他のトランスポートメカニズムなどの変調データ信号によるその他のデータを具現するものであり、任意の情報配信媒体を含む。当業者は、信号内の情報を符号化するなどの方法により特性のうちの１つまたは複数が設定または変更される変調データ信号を熟知している。有線ネットワークまたは直接配線接続などの有線媒体、ならびに音響、ＲＦ、赤外線、およびその他の無線媒体などの無線媒体は、通信媒体のいくつかの実施例である。上記のいずれの組み合わせもコンピュータ可読媒体の範囲に含まれる。

システムメモリ１３４は、取り外し可能な、および／または取り外し不可能な、揮発性および／または不揮発性メモリの形のコンピュータ記憶媒体を備える。例示されている実施形態では、システムメモリ１３４は、読み取り専用メモリ（ＲＯＭ）１３８およびランダムアクセスメモリ（ＲＡＭ）１４０を含む。起動時などにコンピュータ１３０内の要素間の情報伝送を助ける基本ルーチンを含む基本入出力システム１４２（ＢＩＯＳ）は、通常、ＲＯＭ １３８に格納される。通常、ＲＡＭ １４０は、演算処理装置１３２に直接アクセス可能な、および／または演算処理装置１３２によって現在操作されているデータおよび／またはプログラムモジュールを格納する。例えば、限定はしないが、図１２は、オペレーティングシステム１４４、アプリケーションプログラム１４６、その他のプログラムモジュール１４８、およびプログラムデータ１５０を例示している。

コンピュータ１３０はさらに、その他の取り外し可能／取り外し不可能な揮発性／不揮発性コンピュータ記憶媒体を備えることもできる。例えば、図１２は、取り外し不可能な不揮発性磁気媒体への読み書きを行うハードディスクドライブ１５４を例示している。図１２は、さらに、取り外し可能不揮発性磁気ディスク１５８への読み書きを行う磁気ディスクドライブ１５６、およびＣＤ−ＲＯＭまたはその他の光媒体などの取り外し可能不揮発性光ディスク１６２への読み書きを行う光ディスクドライブ１６０を示している。動作環境の実施例で使用できる他の取り外し可能／取り外し不可能な揮発性／不揮発性コンピュータ記憶媒体としては、限定はしないが、磁気テープカセット、フラッシュメモリカード、デジタル多目的ディスク、デジタルビデオテープ、ソリッドステートＲＡＭ、ソリッドステートＲＯＭなどがある。ハードディスクドライブ１５４、および磁気ディスクドライブ１５６、および光ディスクドライブ１６０は、通常、インターフェイス１６６などの不揮発性メモリインターフェイスによりシステムバス１３６に接続される。

図１２に例示されている上記のドライブまたは他の大容量記憶装置およびその関連コンピュータ記憶媒体は、コンピュータ１３０用のコンピュータ可読命令、データ構造体、プログラムモジュール、およびその他のデータを格納する機能を備える。例えば、図１２では、ハードディスクドライブ１５４は、オペレーティングシステム１７０、アプリケーションプログラム１７２、その他のプログラムモジュール１７４、およびプログラムデータ１７６を格納するものとして例示されている。これらのコンポーネントは、オペレーティングシステム１４４、アプリケーションプログラム１４６、その他のプログラムモジュール１４８、およびプログラムデータ１５０と同じである場合もあれば異なる場合もあることに留意されたい。オペレーティングシステム１７０、アプリケーションプログラム１７２、その他のプログラムモジュール１７４、およびプログラムデータ１７６に対しては、ここで、異なる番号を割り当てて、最低でも、それらが異なるコピーであることを示している。

ユーザは、キーボード１８０、およびポインティング装置１８２（例えば、マウス、トラックボール、ペン、またはタッチパッド）などのなどの入力装置またはユーザインターフェイス選択装置を通じてコマンドおよび情報をコンピュータ１３０に入力することができる。他の入力装置（図に示されていない）としては、マイク、ジョイスティック、ゲームパッド、衛星放送受信アンテナ、スキャナなどがある。これらの入力装置およびその他の入力装置は、システムバス１３６に結合されているユーザ入力インターフェイス１８４を通じて演算処理装置１３２に接続されるが、パラレルポート、ゲームポート、またはユニバーサルシリアルバス（ＵＳＢ）などの他のインターフェイスおよびバス構造により接続することもできる。モニタ１８８またはその他の種類の表示装置も、ビデオインターフェイス１９０などのインターフェイスを介してシステムバス１３６に接続される。モニタ１８８のほかに、コンピュータはプリンタおよびスピーカなどの他の周辺出力装置（図に示されていない）を備えることが多く、これらは出力周辺機器インターフェイス（図に示されていない）を通じて接続することができる。

コンピュータ１３０は、リモートコンピュータ１９４などの１つまたは複数のリモートコンピュータへの論理接続を使用してネットワーク接続環境で動作することができる。リモートコンピュータ１９４は、パーソナルコンピュータ、サーバ、ルータ、ネットワークＰＣ、ピア装置、またはその他の共通ネットワークノードとすることができ、通常は、コンピュータ１３０に関して上で説明されている要素の多くまたはすべてを含む。図１２に示されている論理接続は、ローカルエリアネットワーク（ＬＡＮ）１９６およびワイドエリアネットワーク（ＷＡＮ）１９８を含むが、他のネットワークを含むこともできる。ＬＡＮ １３６および／またはＷＡＮ １３８は、有線ネットワーク、無線ネットワーク、それらの組み合わせなどとすることができる。このようなネットワーキング環境は、オフィス、企業全体にわたるコンピュータネットワーク、イントラネット、および大域的コンピュータネットワーク（例えば、インターネット）では一般的である。

ローカルエリアネットワーキング環境で使用される場合、コンピュータ１３０は、ネットワークインターフェイスまたはアダプタ１８６を介してＬＡＮ １９６に接続される。ワイドエリアネットワーキング環境で使用される場合、コンピュータ１３０は、通常、インターネットなどのＷＡＮ １９８上で通信を確立するためモデム１７８またはその他の手段を備える。モデム１７８は、内蔵でも外付けでもよいが、ユーザ入力インターフェイス１８４、またはその他の適切なメカニズムを介してシステムバス１３６に接続される。ネットワーク接続環境では、コンピュータ１３０またはその一部に関して示されているプログラムモジュールは、リモートメモリ記憶装置（図に示されていない）に格納されうる。例えば、限定はしないが、図１２には、リモートアプリケーションプログラム１９２がメモリ装置に常駐しているように例示されている。図に示されているネットワーク接続は実施例であり、コンピュータ間の通信リンクを確立するのに他の手段が使用されうる。

一般に、コンピュータ１３０のデータプロセッサは、コンピュータのさまざまなコンピュータ可読記憶媒体にさまざまな時点において格納された命令を使ってプログラムされる。プログラムおよびオペレーティングシステムは、通常、例えば、フロッピー（登録商標）ディスクまたはＣＤ−ＲＯＭで配布される。そこから、コンピュータの補助記憶装置にインストールまたはロードされる。実行時に、それらは少なくとも一部はコンピュータの主記憶装置にロードされる。本明細書で説明されている発明は、これらおよび他のさまざまな種類のコンピュータ可読記憶媒体を含むが、ただしそのような媒体にマイクロプロセッサまたはその他のデータプロセッサに関して以下で説明されるステップを実装する命令またはプログラムが格納されている場合である。本発明は、さらに、本明細書で説明されている方法および手法に従ってプログラムされた場合にコンピュータ自体も含む。

例示の目的に関して、オペレーティングシステムなどのプログラムおよびその他の実行可能プログラムコンポーネントは、本明細書では異なるブロックとして例示されている。しかし、そのようなプログラムおよびコンポーネントは、コンピュータの異なる記憶装置コンポーネント内にさまざまな時点において常駐し、コンピュータの（複数の）データプロセッサにより実行されることは理解される。

本発明は、コンピュータ１３０を含む、コンピューティングシステム環境例に関して説明されているが、他の多くの汎用または専用コンピューティングシステム環境または構成で動作する。このコンピューティングシステム環境は、本発明の用途または機能の範囲に関する制限を示唆する意図はない。さらに、コンピューティングシステム環境は、動作環境例に例示されている１つのコンポーネントまたは複数のコンポーネントの組み合わせに関係する何らかの依存関係または要求条件がその環境にあるものと解釈すべきでない。本発明とともに使用するのに適していると思われるよく知られているコンピューティングシステム、環境、および／または構成の例として、パーソナルコンピュータ、サーバコンピュータ、ハンドヘルドまたはラップトップ装置、マルチプロセッサシステム、マイクロプロセッサベースのシステム、セットトップボックス、プログラム可能な家電製品、携帯電話、ネットワークＰＣ、ミニコンピュータ、メインフレームコンピュータ、上記システムまたは装置を含む分散コンピューティング環境などがある。

本発明は、１つまたは複数のコンピュータまたはその他の装置により実行される、プログラムモジュールなどのコンピュータ実行可能命令の一般的状況において説明することができる。一般に、プログラムモジュールは、限定はしないが、特定のタスクを実行する、または特定の抽象データ型を実装するルーチン、プログラム、オブジェクト、コンポーネント、およびデータ構造を含む。また、本発明は、通信ネットワークを通じてリンクされているリモート処理装置によりタスクが実行される分散コンピューティング環境で実施することもできる。分散コンピューティング環境では、プログラムモジュールをメモリ記憶装置などのローカルとリモートの両方のコンピュータ記憶媒体に配置できる。

ソフトウェアアーキテクチャの背景状況におけるインターフェイスは、ソフトウェアモジュール、コンポーネント、コード部分、またはコンピュータ実行可能命令の他のシーケンスを含む。例えば、インターフェイスは、第１のモジュールの代わりにコンピューティングタスクを実行するために第２のモジュールにアクセスする第１のモジュールを含む。第１および第２のモジュールは、一実施例では、オペレーティングシステムによって提供されるようなアプリケーションプログラミングインターフェイス（ＡＰＩ）、コンポーネントオブジェクトモデル（ＣＯＭ）インターフェイス（例えば、ピアツーピアアプリケーション通信用）、および拡張マークアップ言語メタデータ交換形式（ＸＭＩ）インターフェイス（例えば、複数のＷｅｂサービス間の通信用）を含む。

インターフェイスは、Ｊａｖａ（登録商標） ２ Ｐｌａｔｆｏｒｍ Ｅｎｔｅｒｐｒｉｓｅ Ｅｄｉｔｉｏｎ（Ｊ２ＥＥ）、ＣＯＭ、または分散ＣＯＭ（ＤＣＯＭ）の実施例などの密結合の同期実装であってよい。それとは別に、またはそれに加えて、インターフェイスは、Ｗｅｂサービスの場合のような疎結合の非同期実装とすることもできる（例えば、シンプルオブジェクトアクセスプロトコルを使用する）。一般に、インターフェイスは、密結合、疎結合、同期、および非同期という特性の任意の組み合わせを含む。さらに、インターフェイスは、標準プロトコル、専用プロトコル、または標準プロトコルと専用プロトコルとの任意の組み合わせに適合することができる。

本明細書で説明されているインターフェイスは、すべて、単一インターフェイスの一部であるか、または別々のインターフェイスもしくはそれらの任意の組み合わせとして実装することができる。これらのインターフェイスは、機能を提供するためにローカルまたはリモートで実行できる。さらに、これらのインターフェイスが含む機能は、例示されている、または本明細書で説明されている機能よりも多い場合も少ない場合もある。

例示され、本明細書で説明されている方法の実行または遂行の順序は、断りのない限り本質的ではない。つまり、これらの方法の要素は、断りのない限り任意の順序で実行することができ、それらの方法が含む要素は、本明細書で開示されている要素よりも多い場合も少ない場合もある。例えば、特定の要素を、他の要素の前に、他の要素と同時に、または他の要素の後に実行または遂行することは本発明の範囲であると考えられる。

本発明または本発明の（複数の）実施形態の要素を導入する際に、英文中の「ａ」、「ａｎ」、「ｔｈｅ」、および「ｓａｉｄ」という冠詞、したがって和文中の「１つの」、「その」、「前記」は、それらの要素が１つまたは複数あることを意味することを意図している。「備える」、「含む」、および「持つ、格納する、含む、備える」という言葉は、包含的であることを意図し、一覧に示されている要素以外にさらに要素がありうることを意味する。

上記の説明に照らして、本発明の複数の目的が達成され、他の有益な結果が得られることは理解されるであろう。

本発明の範囲から逸脱することなく上記の構成、製品、および方法にさまざまな変更を加えることが可能であるので、上記の説明に含まれ、付属の図面に示されているすべての事柄は、例示しているのであって、限定する意味はないと解釈するものとする。

付録Ａ
符号Ａでは、アクティビティのいくつかの実施例を説明する。

アクティビティの例およびその実装例
アクティビティの例としては、Ｓｅｎｄ、ＳｅｎｄＲｅｑｕｅｓｔ、ＳｅｎｄＲｅｓｐｏｎｓｅ、Ｒｅｃｅｉｖｅ、ＲｅｃｅｉｖｅＲｅｑｕｅｓｔ、ＲｅｃｅｉｖｅＲｅｓｐｏｎｓｅ、Ｃｏｄｅ、Ｄｅｌａｙ、Ｆａｕｌｔ、Ｓｕｓｐｅｎｄ、Ｔｅｒｍｉｎａｔｅ、ＩｎｖｏｋｅＳｃｈｅｄｕｌｅ、ＩｎｖｏｋｅＳｃｈｅｄｕｌｅｓ、Ｉｎｖｏｋｅ ＷｅｂＳｅｒｖｉｃｅ、ＤｏｔＮｅｔＥｖｅｎｔＳｏｕｒｃｅ、ＤｏｔＮｅｔＥｖｅｎｔＳｉｎｋ、Ｓｅｑｕｅｎｃｅ、Ｐａｒａｌｌｅｌ、Ｗｈｉｌｅ、ＣｏｎｄｉｔｉｏｎａｌＢｒａｎｃｈ、Ｃｏｎｄｉｔｉｏｎａｌ、Ｃｏｎｓｔｒａｉｎｅｄ、ＣｏｎｓｔｒａｉｎｅｄＡｃｔｉｖｉｔｙＧｒｏｕｐ（ＣＡＧ）、ＥｖｅｎｔＤｒｉｖｅｎ、Ｌｉｓｔｅｎ、ＥｖｅｎｔＨａｎｄｌｅｒｓ、ＥｘｃｅｐｔｉｏｎＨａｎｄｌｅｒ、ＥｘｃｅｐｔｉｏｎＨａｎｄｌｅｒｓ、Ｃｏｍｐｅｎｓａｔｅ、ＣｏｍｐｅｎｓａｔｉｏｎＨａｎｄｌｅｒ、Ｓｃｏｐｅ、およびＳｃｈｅｄｕｌｅがある。

アクティビティの実施例はそれぞれ、メタデータが関連付けられている。メタデータは、アクティビティに関連付けられたシリアライザによってワークフローの宣言的表現に移される。例えば、メタデータは、オプションのコードビサイドメソッドおよびオプションの相関関係集合のコレクションを含むことができる。

Ｓｅｎｄアクティビティ
オーケストレーションエンジンは、メッセージを送信する３つのアクティビティ（例えば、Ｓｅｎｄ、ＳｅｎｄＲｅｑｕｅｓｔ、およびＳｅｎｄＲｅｓｐｏｎｓｅ）を備え、それぞれ異なる使用事例を対象とする。さらに、これら３つのアクティビティは、何らかのメタデータを共有するので、抽象基本クラスが３つのすべての上位クラスとして定義され使用される。
Ｒｅｃｅｉｖｅアクティビティ
オーケストレーションエンジンは、メッセージを受信する３つのアクティビティ（例えば、Ｒｅｃｅｉｖｅ、ＲｅｃｅｉｖｅＲｅｑｕｅｓｔ、およびＲｅｃｅｉｖｅＲｅｓｐｏｎｓｅ）を備え、それぞれ異なる使用事例を対象とする。さらに、これら３つのアクティビティは、何らかのメタデータを共有するので、抽象基本クラスが３つのすべての上位クラスとして定義され使用される。
Ｃｏｄｅ
Ｃｏｄｅアクティビティは、メタデータで指示されているコードビサイドメソッドを実行する。

Ｄｅｌａｙ
Ｄｅｌａｙアクティビティは、その必須コードビサイドメソッドを実行してＤａｔｅＴｉｍｅ値を生成する。そのインスタンスデータのＴｉｍｅｏｕｔＶａｌｕｅプロパティをこの値に内部的に設定する。ＤａｔｅＴｉｍｅが過去であれば、Ｄｅｌａｙは即座に完了する。そうでなければ、タイマーが発火したときにＤｅｌａｙに通知するようにタイマーサブスクリプションをセットアップする。タイマーが発火した場合、Ｄｅｌａｙは通知され、完了する。
Ｆａｕｌｔ
Ｆａｕｌｔアクティビティは、その必須コードビサイドメソッドを実行してＥｘｃｅｐｔｉｏｎオブジェクトを生成する。その後、この例外をスローする。
Ｓｕｓｐｅｎｄ
Ｓｕｓｐｅｎｄアクティビティは、現在のスケジュールインスタンスをサスペンドする。
Ｔｅｒｍｉｎａｔｅ
Ｔｅｒｍｉｎａｔｅアクティビティは、現在のスケジュールインスタンスを終了する。

Ｉｎｖｏｋｅ Ｓｃｈｅｄｕｌｅ
ＩｎｖｏｋｅＳｃｈｅｄｕｌｅアクティビティは、スケジュールを呼び出す。

Ｉｎｖｏｋｅ Ｗｅｂ Ｓｅｒｖｉｃｅ
プロキシクラスを介してＷｅｂサービスを呼び出して、パラメータを指定通り受け渡し、受信する。

ＤｏｔＮｅｔＥｖｅｎｔ Ｓｉｎｋ
すでに呼び出されているスケジュールインスタンスにより指定イベントが発生したという通知が来るのを待つブロック。
ＤｏｔＮｅｔＥｖｅｎｔ Ｓｏｕｒｃｅ
指定イベントを発生し、即座に実行を完了する。
Ｓｅｑｕｅｎｃｅ
Ｓｅｑｕｅｎｃｅアクティビティは、一度に１つずつ、順序正しく子アクティビティの集合の実行を調整する。
Ｐａｒａｌｌｅｌ
Ｐａｒａｌｌｅｌアクティビティは、子アクティビティの集合を同時実行する。

Ｗｈｉｌｅ
子アクティビティを繰り返し実行する。
ＣｏｎｄｉｔｉｏｎａｌＢｒａｎｃｈ
Ｓｅｑｕｅｎｃｅの意味論に従って、子アクティビティを実行する。
Ｃｏｎｄｉｔｉｏｎａｌ
Ｃｏｎｄｉｔｉｏｎａｌアクティビティは、ＣｏｎｄｉｔｉｏｎａｌＢｒａｎｃｈアクティビティの順序付き集合を含む。
Ｃｏｎｓｔｒａｉｎｅｄ
ＣｏｎｓｔｒａｉｎｅｄアクティビティがＣＡＧにより実行を指示された場合、それがラップするアクティビティを単に実行するだけである。
ＣＡＧ（Ｃｏｎｓｔｒａｉｎｅｄ Ａｃｔｉｖｉｔｙ Ｇｒｏｕｐ）
ＣＡＧは、実行されると、そのイネーブルおよびディセーブル制約の評価に基づいて子アクティビティを実行（および再実行）する。
Ｔａｓｋ
１つまたは複数のプリンシパルにより実行される外部作業単位をモデル化する。
Ｅｖｅｎｔ Ｄｒｉｖｅｎ
実行が「イベント」アクティビティによりトリガされるアクティビティをラップする。

Ｌｉｓｔｅｎ
ｎ個の子ＥｖｅｎｔＤｒｉｖｅｎアクティビティの１つを条件付きで実行する。
Ｅｖｅｎｔ Ｈａｎｄｌｅｒｓ
ＥｖｅｎｔＨａｎｄｌｅｒｓアクティビティは、単純に、ＥｖｅｎｔＤｒｉｖｅｎアクティビティの集合を保持し、これを関連するＳｃｏｐｅが使用する。
Ｅｘｃｅｐｔｉｏｎ Ｈａｎｄｌｅｒ
スコープに対するキャッチブロックを表すメタデータで、アクティビティをラップする。
Ｅｘｃｅｐｔｉｏｎ Ｈａｎｄｌｅｒｓ
ＥｘｃｅｐｔｉｏｎＨａｎｄｌｅｒアクティビティの順序付き集合をラップする。
Ｃｏｍｐｅｎｓａｔｅ
完了した子スコープを補正する。
Ｃｏｍｐｅｎｓａｔｉｏｎ Ｈａｎｄｌｅｒ
スコープに対する補正ハンドラとして定義されている子アクティビティをラップする。

Ｓｃｏｐｅ
スコープは、トランザクション境界、例外処理境界、補正境界、イベント処理境界、およびメッセージ、変数、相関関係集合、およびチャネル宣言の境界（つまり、共有データ状態）である。
Ｓｃｏｐｅ内のアクティビティの実行は順次であり、したがって、含まれているアクティビティは、Ｓｅｑｕｅｎｃｅの場合のように、スコープが構築されたときに明示的に順序付けられる。
Ｓｃｈｅｄｕｌｅ
Ｓｃｈｅｄｕｌｅは、オーケストレーションエンジンが実行する唯一の最上位レベルのアクティビティである。
複合アクティビティ
制御フローを使用可能にする複合アクティビティ型は、Ｓｅｑｕｅｎｃｅ、Ｐａｒａｌｌｅｌ、Ｃｏｎｓｔｒａｉｎｅｄ Ａｃｔｉｖｉｔｙ Ｇｒｏｕｐ、Ｃｏｎｄｉｔｉｏｎａｌ、Ｗｈｉｌｅ、Ｌｉｓｔｅｎである。さらに、ＳｃｏｐｅおよびＳｃｈｅｄｕｌｅは、中にあるアクティビティの暗黙のシーケンス動作を含むコンテナとして動作する複合アクティビティ型である。

付録Ｂ
付録Ｂでは、ビジュアルデザイナおよび関連するアクティビティデザイナを説明する。

ビジュアルデザイナ
スケジュールは、一般に、多数のアクティビティからなる。それぞれのアクティビティはそれ自体の関連するデザイナを持つ。アクティビティがツールボックスからグラフィカルユーザインターフェイスのデザインサーフェス上にドラッグされた後、デザイナはグラフィカルユーザインターフェイス（ＵＩ）内にアイコンとして表される（例えば、Ｖｉｓｕａｌ Ｓｔｕｄｉｏ）。デザイナは、オーサリングオブジェクトモデル（ＡＯＭ）上にＵＩ表現を提供する。開発者は、オブジェクトモデルに対して直接プログラムし、アクティビティのプロパティを設定するか、またはデザイナを使用し、Ｖｉｓｕａｌ Ｓｔｕｄｉｏのプロパティブラウザを利用することができる。

アクティビティの作成および構成
スケジュールを作成することは、アクティビティおよびスケジュールを構成するタスクを定義することを含む。オーケストレーションエンジンデザイナを使用することにより、開発者はツールボックス（例えば、カテゴリオーケストレーションエンジンアクティビティの下にある）からアクティビティを選択し、それをデザイナサーフェス上にドラッグすることができる。アクティビティがすでにスケジュールに入れられており、移動する必要がある場合、開発者は、それを選択して（それをクリックすることにより）、そのアクティビティを入れる必要のあるスケジュールの領域にドラッグすることができる。開発者がコントロールキーを押しながらドラッグ＆ドロップを行うと、選択されたアクティビティのコピーが作成される。

アクティブ配置機能では、実行するコレクトバイコンストラクション意味論的バリデーション（correct by construction semantic validation）に基づいて可能なドロップ点（ターゲット）を視覚的インジケータとして与える。アクティビティは、スケジュール上のこれらのターゲットのどれにでもドラッグ＆ドロップすることができる。自動スクロール機能も、ドラッグ＆ドロップのコンテキストに参加する。大きなスケジュールを取り扱う場合、現在Ｖｉｓｕａｌ Ｓｔｕｄｉｏビューポート内にないデザイナの領域へのナビゲーションは、入れるスケジュールの領域に向かってアクティビティをドラッグすることによりアクセス可能である。ドラッグ＆ドロップは、同じプロジェクト内のスケジュール間で、また同じソリューション内の他のプロジェクト内のスケジュール間でサポートされる。アクティビティがデザインサーフェス上に配置された後、開発者はプロパティの集合を介してそのアクティビティの構成を設定する。これらのプロパティは、標準Ｖｉｓｕａｌ Ｓｔｕｄｉｏプロパティブラウザで編集可能である。それぞれのアクティビティは、プロパティブラウザ内にどのようなプロパティを表示できるかを制御する。

ダイアログのガイドライン
開発者がさまざまなアクティビティを構成するのを補助するため、デザイナはさまざまなダイアログまたは「サブデザイナ」を備えている。それぞれのダイアログは、アクティビティのさまざまなプロパティについて呼び出される。開発者は、プロパティブラウザ内で省略記号により注釈されている場合にプロパティに対しデザイナを呼び出すことができる。

タイプブラウザダイアログ
プロパティブラウザを通じてアクティビティを構成するときに、開発者側でプロパティまたはオブジェクトの型を指定する必要がある場合が多い。開発者は、必要とする型（例えば、Ｓｙｓｔｅｍ．Ｓｔｒｉｎｇ）を知っていれば、プロパティブラウザ内に直に打ち込む。タイプブラウザは、そのプロパティの予想される型と一致するプロジェクト内のコンパイルされたすべての参照アセンブリに対し視覚化を行う。アセンブリがタイプブラウズに表示される前に、最初に参照プロジェクトがコンパイルされなければならない。構成される特定のアクティビティプロパティに基づいて、タイプブラウザは、開発者に表示される型をフィルタ処理する。基本にアクティビティにより予期される型に応じて、タイプブラウザは、シリアライズ可能なクラスおよびインターフェイスおよびＩＣｏｍｐａｒａｂｌｅを実装するクラスをフィルタ処理する。例えば、ｓｅｎｄアクティビティのメッセージプロパティからブラウザを起動すると、ブラウザにはシリアライズ可能なクラスの一覧が表示される。オーケストレーションエンジンは、メッセージの型、ポートの型、および相関関係の型を第１のクラスのプロセス型として認識する。以下の表には、ＣＬＲ型を持つもののマッピングをまとめた。

一実施形態では、タイプブラウザのグラフィカルユーザインターフェイスは、サイズ変更できないが、２つのサブウィンドウのそれぞれに水平および垂直スクロールバーを用意している。左サブウィンドウの既定の並べ換え順は、現在のプロジェクトの参照アセンブリにリストされている型の名前に基づいて昇順である。右サブウィンドウ内には、「Ｔｙｐｅ Ｎａｍｅ」および「Ｆｕｌｌｙ Ｑｕａｌｉｆｉｅｄ Ｎａｍｅ」の２つの列が存在する。既定の並べ換え順は、「Ｔｙｐｅ Ｎａｍｅ」に基づき降順である。しかし、これらの列は両方とも並べ換え可能である。「Ｔｙｐｅ Ｎａｍｅ」列は、型名全体を表示するようにサイズ変更可能である。開発者がそれぞれのアセンブリにフォーカスを置くと、右サブウィンドウには、そのアセンブリ内に収納された選択（上述のような）に対し許容できる型が表示される。有効な型を選択した後、２つのサブウィンドウの下のテキストボックスに、型の名前およびそれが収められるアセンブリが示される。アセンブリ情報からは、アセンブリ名、バージョン番号、カルチャー、および公開キートークンが得られる。この選択が実行されるまでのテキストは、「ＰＩｅａｓｅ ｓｅｌｅｃｔ ａ Ｔｙｐｅ ｆｒｏｍ ｔｈｅ ｌｉｓｔ．」となっている。開発者は、最終的に、型を選択するか、またはブラウザから手を引くことを決定する。アクティビティのプロパティと一致する型が選択された場合、ＯＫボタンが有効になる。開発者がプロパティブラウザダイアログを再度呼び出すと、型および参照アセンブリは自動的に選択される。

アクティビティのさまざまなプロパティを開発者が構成するのを手助けするために用意されているもう１つの種類のブラウザは相関関係集合ブラウザである。実行スケジュールでは、スケジュールに送られるメッセージは、実際には、特定のスケジュールインスタンス向けである。例えば、発注書＃１２３に対するインボイスをその発注書を発信した（送出した）のと同じスケジュールインスタンスに送り返さなければならない。受信メッセージと適切なスケジュールインスタンスとを照合するために、メッセージおよびスケジュールインスタンスは相関関係集合と呼ばれるキーを共有する。相関関係集合は、ＳｅｎｄおよびＲｅｃｅｉｖｅアクティビティ上で定義される。Ｃｏｒｒｅｌａｔｉｏｎ Ｓｅｔ Ｂｒｏｗｓｅｒを使用して、相関関係集合の構成を補助する。定義すべき第１のアイテムは、相関関係集合の名前である。開発者が新しい相関関係集合を作成する場合、その名前を直接入力することができる。定義済み相関関係に加わるようにＳｅｎｄ／Ｒｅｃｅｉｖｅを構成する場合、ドロップダウンには、相関関係の名前が初期値として入る。このリストは、現在のプロジェクトのコードビサイドから取り出される。このダイアログの出力は、ここで詳しく説明されている構成に基づくコードビサイド内の相関関係変数である。例えば、文字列型の相関関係が作成された場合、形成される結果コードは、ｐｕｂｌｉｃ ＯＥＣｏｒｒｅｌａｔｉｏｎ＜Ｓｙｓｔｅｍ．Ｓｔｒｉｎｇ＞ＭｙＣｏｒｒｅｌａｔｉｏｎ＝ｎｅｗ ＯＥＣｏｒｒｅｌａｔｉｏｎ＜Ｓｙｓｔｅｍ．Ｓｔｒｉｎｇ＞（）；となるであろう。

開発者が入力する必要のある次の構成オプションは、この相関関係が関わるアクティビティが集合を初期化するかどうかである。デザイナの目的のために、このオプションはＴｒｕｅまたはＦａｌｓｅである。他の構成詳細では、相関関係集合の型を指定する。他のアクティビティの型を構成するのと同様にして、タイプブラウザを呼び出すことができる。開発者は、アクティビティが関わっている相関関係集合の追加および削除を行うことができる。しかし、相関関係がコードビサイド内で定義される結果として、アクティビティは、前のアクティビティ内で定義された相関関係内に関わることができる。さらに、相関関係を削除すると、実際には、コードビサイドにより生成されたコードではなく相関関係へのアクティビティの関与が取り除かれる。開発者が相関関係を表示させたくない場合、コードビサイドから定義を削除するのは開発者の役目である。

タブオーダーは、Ｃｏｒｒｅｌａｔｉｏｎ ｓｅｔ、名前、ドロップダウンピッカー、Ａｄｄ、Ｒｅｍｏｖｅ、ＯＫ、Ｃａｎｃｅｌ、およびＨｅｌｐである。複数の相関関係集合が定義されている場合、タブはＡｄｄの前、ドロップダウンピッカーの後の次の定義済み相関関係集合のところで停止する。開発者は、最終的に、相関関係の作成および／または削除を実行するか、またはブラウザから手を引くことを決定する。相関関係の名前および型が与えられた場合にＯＫボタンが有効になる。ＯＫをクリックすると、新しい相関関係集合に対するコードビサイドが生成され、アクティビティが定義された相関関係に追加される。キャンセルを選択するか、またはエスケープキーを叩くことで、開発者は、アクティビティに変更加えることなくブラウザを終了することができる。アクティビティが正しく構成されていない場合、デザイナは、それぞれのアクティビティのどれをどのように構成するか関する広範にわたるフィードバックを開発者に送る。

制約デザイナダイアログ
本発明では、スケジュールでどの制約技術を使用するかに関係なく、開発者側で制約をオーサリングできる。開発者がドラッグ＆ドロップメタファーを使用してコードを書くのは不自然なビヘイビアである。したがって、制約構成用のツールでは、マウスを使用し、さらにキーボードも使用して制約を定義する機能をサポートする。制約の最終的生成は、ＸＯＭＬに継続する。そこで、生成された制約は、既存のＸＯＭＬオブジェクトモデルと整合しており、開発者は制約定義を手編集することができる。制約生成のため用意されているＵＩは、ユーザが制約を作成し、さらにそれを修正するのを補助する。このことは、すでに生成されている（および場合によっては修正されている）制約とＵＩとの間のラウンドトリッピングを意味する。

ユーザモデル
制約定義を行えるようにするアクティビティが与えられた場合、開発者は、対応する制約プロパティを特定し、ドロップダウンにおいて、適切なドロップダウンを選択することにより制約を定義したいことを指示する。ハンドラの定義の後、制約エディタを呼び出すためにプロパティブラウザでプロパティに省略記号を注釈として入れる。開発者は、制約の名前を指定することができる。この名前は、制約定義の残りとともにＸＯＭＬに継続する。制約定義は、定義グリッド内の、ｏｐｅｒａｎｄ、ｏｐｅｒａｔｏｒ、ｖａｌｕｅ、およびｇｒｏｕｐ ｂｙの４つの列を使用して実行される。ｏｐｅｒａｎｄは、制約に関わるオペランドを含むドロップダウンである。開発者は、ドロップダウンに直接打ち込み、オートコンプリート機能を使用して所望のオペランドを素早く選択することができる。ｏｐｅｒａｔｏｒは、制約内で使用されるオペレータを定義するドロップダウンである。開発者は、オペレータをドロップダウンに直接打ち込むことができ、これにより、所望のオペレータを素早く選択できる。ｖａｌｕｅは、制約内で使用される開発者定義値である。制約を保存した後、この値と選択されたプロパティとが比較され、型が一致することを確認する。型が一致しない場合、「ｔｈｅ ｏｐｅｒａｎｄ ａｎｄ ｖａｌｕｅ ｔｙｐｅｓ ｄｏ ｎｏｔ ｍａｔｃｈ」などのメッセージが表示され、開発者は違反する述語に向けられる。ｇｒｏｕｐ ｂｙ列は、「ＡＮＤ」または「ＯＲ」を含む２つの受け入れ可能な値を持つドロップダウンである。制約定義が進むにつれ、開発者は、定義グリッドの下にある編集不可能なダイアログ内の制約を表示することができる。これにより、開発者は、より直截的な方法で制約を表示することができる。この出力は、（（Ａ＜３） ＡＮＤ （Ｂ＞Ｃ）） ＡＮＤ （Ｄ＝３）） ＯＲ （Ｆ＝５）というような形になるであろう。

アクティビティエラー処理：「Ｓｍａｒｔ Ｔａｇｓ」
本発明では、タイプブラウザ、相関関係集合ブラウザ、およびルールデザイナなどの特定のアクティビティを構成することを補助するいくつかのサブデザイナを備える。アクティビティが十分に構成されていない場合、アクティビティのデザイナは、感嘆符スマートタグに似たアイコンで装飾される。開発者は、このアイコンをクリックして、そのアクティビティに特有の構成エラーのドロップダウンリストを表示する。プロパティ構成に関係するエラーについては、選択によりフォーカスがプロパティブラウザに移動し、エラーがあるプロパティ上にフォーカスが置かれる。アイコンは、アクティビティのすべてのプロパティが有効であれば、消える。

デザインサーフェス機能
本発明のデザイナは、さらに、アクセス性の面で補助する他のＵＩオプションをいくつか用意している。プロセスビューの背景状況におけるこれらの機能の多くは、開発者が大規模なスケジュールを操作するのを補助するために用意されている。例えば、ｚｏｏｍを使用すれば、開発者はそのスケジュールの選択を広げることができる。スケジュールのズームイン／ズームアウトを行うメカニズムがいくつかあり、それぞれ特定の関数用に設計されている。一方法では、開発者は、特定のズーム割合を設定することによりスケジュール内にズームすることができる。割合の例は、４０％、６０％、８０％、１００％、１５０％、２００％、３００％、および４００％である。これらのレベルは、最上位のワークフローメニューを使用するか、またはスクロールバー上のコマンドボタンを使用して設定することができる。ワークフロービューにより、ユーザはズームレベルを設定できる。ズームレベルで、巨大なワークフローの拡張性問題に対処する。ズームレベルは、最上位のワークフローメニューを使用するか、またはスクロールバー上のコマンドボタンを使用して設定することができる。ズームレベルは、ワークフローの編集に影響を及ぼすことはないが、複数の座標系を使用するとワークフロービューでこれを達成できる。ワークフロービューは、ズーム率をキャッシュし、それをレンダリングおよび座標変換に使用する。ズーム率は描画で使用されるが、そのためには、Ｇｒａｐｈｉｃｓ．ＳｃａｌｅＴｒａｎｓｆｏｒｍメソッドで選択する。選択したら、グラフィックスオブジェクトを使用して実行されたすべての描画が、使用されるスケーリングに基づいて変換される。描画前に、すべての座標に倍率が掛けられる。ユーザが座標変換のためマウスを使ってアクションを実行する場合には、ズーム率も使用される。

他のメソッドでは、開発者は、Ｚｏｏｍ Ｉｎ／Ｚｏｏｍ Ｏｕｔオプションを垂直スクロールバーからのオプションとして選択することによりスケジュールのズームイン／ズームアウトを実行できる。これにより、カーソルが拡大鏡に切り換わることにより示されるデザイナの「モード」が変わる。開発者は、その後、ズームイン／ズームアウトが望まれているスケジュールの領域を「ラバーバンディング」することができる。Ｚｏｏｍ Ｉｎが選択された場合、マウスボタンをクリックするとデザイナが「ズームイン」する（Ｚｏｏｍ Ｏｕｔではその逆である）。しかし、開発者は、それぞれのモードにおいて、シフトキーを押し下げたままにして、Ｚｏｏｍ Ｉｎ／Ｏｕｔを切り換えることができる。最後に、いずれのモードも終了するためには、開発者が「Ｅｓｃａｐｅ」キーを叩いて、「既定の」モードに戻る。「既定の」モードの場合、開発者は、「Ｃｏｎｔｒｏｌ」キーを押したまま、マウスホイールでスクロールすると、Ｚｏｏｍすることができる。ズームレベルだと開発者はスケジュールを操作できいということはない。言い換えると、開発者は、ズームレベルに関係なくアクティビティの操作、追加／削除を実行できる。既定のズームレベルは１００％である。ズーム設定状態は、ビューに関係なく保存される。より具体的には、開発者がＸＯＭＬビュー、印刷プレビュー、またはコードビサイドに切り換えるか、あるいはスケジュールまたはソリューションを閉じた場合、ズーム状態は保存される。

Ｐａｎは、スケジュールを「掴み」、シフトする開発者向けの機能である。開発者がＰａｎモードを選択すると、カーソルは手のアイコンに変化する。開発者がマウスをクリックすると、手のアイコンがサーフェスを「掴む」ので、マウスを動かしてサーフェスをマウスの方向にシフトする。Ｐａｎは、垂直スクロールバーのオプションとしてアクセス可能である。パンモードの場合、開発者は、デザイナにアクティビティを追加／削除することはできない。Ｐａｎでは、特に、デザイナ内のスケジュールの現在のビューをシフトすることに注目する。

大きなスケジュールでは、開発者は、デザイナのズーム機能を利用せず、したがって可視でないスケジュールの一部を持つ場合がある。開発者は、それでも、ツールボックスから新しいアクティビティをドラッグして、スケジュールに追加できる機能を必要とする。このシナリオでは、開発者は、アクティビティを、スクロールしたいスケジュールの領域にドラッグし、「ａｕｔｏ ｓｃｒｏｌｌ ｚｏｎｅ」を入力した後、矢印が現れ、スケジュールはアクティビティがドラッグされる方向にシフトする。アクティビティが開発者がナビゲートを望む方向に画面の表示可能領域の１０％の領域に入ったときに、これらの矢印によりデザイナビューをアクティブにし、スクロールする。

特に、本発明は、ユーザがワークフローの一部にナビゲートし、その部分にフォーカスを置いて修正し、先に進んでワークフローの他の何らかの部分を編集するためのメカニズムを備える。オートパニング機能を使用すると、ユーザは、ワークフローのピクチャ全体を描画させることができ、拡大鏡を使用すると、ワークフローの特定の部分にズームオンすることができる。オートパニング機能は、ズーム機能およびオートスクロール機能と統合され、ユーザは実際に大きなワークフローに取り組むことができる。オートパニングプロセスを起動するには、ユーザは、垂直スクロールバー上に表示されている拡大鏡アイコンをクリックする。このアイコンをクリックすると、ワークフロービューはオートパニングモードに入る。このモードでは、ＴａｋｅＭａｇｎｉｆｉｅｒＳｎａｐＳｈｏｔを呼び出すことによりビューポート内に表示可能な現在のワークフロースナップショットをとることができる。この機能は、ズーム率を持たないメモリビットマップ内のワークフローのスナップショットをとる。これを実行した後、ワークフローのズーム率を計算し、ワークフローの大半がビューポート内で可視であるようにする。その後、マウスはＭａｇｎｉｆｉｅｒカーソルに変わる。カーソルのホットスポットは、ワークフローのメモリビットマップの部分にマッピングされる。その後、メモリビットマップのマッピングされた部分は、拡大鏡内に表示される。非常に大きなワークフローでは、ユーザがオートスクロール領域に入ると、オートスクロール機能が実行され、表示されるビューポートが修正される。オートスクロール機能が停止すると、新しいビューポートマップが捕捉される。ユーザがマウスを離すと、カーソルのホットスポットが実際のワークフロー部分にマッピングされ、その部分が画面の中心に置かれる。以下に、Ａｕｔｏ Ｐａｎｎｉｎｇの擬似コードを示す。
−ｉｆ ユーザがオートパニングモードに入る
−できる限りワークフローの大部分が表示されるようにズームレベルを設定する
−可視状態のワークフロービットマップを捕捉する
−ｉｆ ユーザがマウスをドラッグしている
−マウス座標を取得する
−それをワークフロービットマップにマッピングする
−マッピングされたワークフロービットマップをコピーすることにより拡大鏡を描画する
−ｉｆ マウスがオートスクロール領域に入り、ワークフローをスクロールできる
オートスクロールする
−ｅｌｓｅ ｉｆ ユーザがオートスクロール領域を出る
−可視状態のワークフロービットマップを再度捕捉する
−ｅｎｄｉｆ
−ｅｌｓｅ
−マウスを離した座標を取得する
−それをワークフロー領域にマッピングする
−ワークフロー領域を中央に揃える
−ｅｎｄｉｆ
一実施形態では、本発明は、ワークフローの右下に小さなパンウィンドウを表示することによりオートパニング機能をサポートし、そこでは、ユーザはワークフロー全体の表現をサムネイル形式で表示することができる。

大きなスケジュールをナビゲートするテーマの範囲内にある間に、開発者は、文書アウトライン機能により、スケジュールを一目で素早く見渡すことができ、アウトライン内のノードを選択することにより、デザイナを選択されたアクティビティにナビゲートすることができる。各ノードの子は、順序列内の配置に基づいて順序付けられる。ノードまたは葉をダブルクリックすると、開発者は、スケジュール内の選択されたアクティビティにナビゲートされる。インライン化されたスケジュールは、文書アウトライン内の単一ノードとして提示される。インライン化されたスケジュールを含むアクティビティは、文書アウトライン内の別のエントリとしては表示されない。任意の時点で、開発者は、機能仕様全体を通して定義されているすべてのスケジュールオペレーション（追加、削除、コピー、貼り付け、名前の変更など）を実行することができ、文書アウトラインはそれに応じて反映される。文書アウトライン内のアクティビティを複数選択すると、それに対応して、プロセス／ワークフロービュー内のアクティビティが選択される。コントロールキーを押したまま、文書アウトライン内のノードを選択すると、選択されたノードがハイライト表示になり、選択されたことを示す。スコープにおいてイベントおよび／または例外ハンドラが定義されている場合、これは、スコープと同じレベルで表示される。このため、開発者は、スコープデザイナのさまざまなページをめくっていかなければならないのに対して、スコープの全体を１箇所で見られる。

アクティブ配置では、コレクトバイコンストラクション意味論を評価する機能を使用して、スケジュール全体を通してどのアクティビティを配置できるかをポジティブに示す。開発者がツールボックスからデザイナにアクティビティをドラッグするときに、ターゲットがスケジュール上に表示される。開発者がターゲット位置付近にノードをドラッグすると、ターゲットがアクティブ化される。ドラッグされたアクティビティのアイコンがスナップし、オリジナルのターゲットを置き換える場合、アクティベーションは明白である。これが生じた場合、開発者は、マウスボタンを離してよく、ノードはアクティブターゲットにより示される位置でスケジュールにスナップする。複数選択ドラッグ＆ドロップのシナリオでは、表示されるターゲットは、すべての意味論的バリデーションを満たすターゲットであるべきである。

コンポジションという概念は、スケジュールまたは他のスケジュールおよびタスクのタスクに再帰的に含まれることを意味する。ワークフローデザイナを使用すると、開発者は、スケジュールをおよびタスクを作成し、その後、他のスケジュールおよびタスク内でそれらを呼び出す作業を簡単に行える。しかし、開発者が新しいスケジュールまたは新しいタスクのいずれかを作成する場合、必ず、Ｖｉｓｕａｌ Ｓｔｕｄｉｏは、ツールボックスを介してワークフローまたはタスクのコンパイルバージョンを（全ての型の）他のオーケストレーションエンジンプロジェクトから利用できるようにする。そのコンパイルされたワークフローまたはタスクを呼び出すには、開発者はそれをツールボックスからスケジュールにドラッグするが、これは他のアクティビティと全く同様である。スケジュールのインライン化では、新しい網羅的スケジュールにおいてこの新しいスケジュールまたはタスクを直接見ることができる。これは、網羅的スケジュールまたはタスクの内側の動作を見られる読み取り専用の確認機能である。

スケジュールまたはタスク内の複合アクティビティは、それ自体、展開または縮小できる。それぞれの展開または縮小の状態は保持される。したがって、外側のコンストラクト（パラレルまたはスコープなど）が縮小されているが、内側のコンストラクトが展開されていた場合、外側の展開で、展開されている内側はそのままである。これが読み取り専用ビューであるとすると、開発者は、インライン化されたスケジュール内に保持されているアクティビティを網羅的スケジュールにコピー／貼り付けし、ドラッグ＆ドロップすることができる。既定では、開発者がスケジュールを作成する場合、これはスケジュールインライン化に関わる。しかし、「呼ばれる側」スケジュールライターは「呼び出し側」スケジュールがそのスケジュールの内側の動作を表示することを望まないシナリオがある。呼ばれる側のスケジュールのオーサリング中に、開発者は、そのスケジュールがインライン化できないことを示すことができる。「呼び出し側」開発者がこの属性付きスケジュールをインライン化しようとした場合、「Ｔｈｅ Ａｕｔｈｏｒ ｏｆ ｔｈｉｓ ｓｃｈｅｄｕｌｅ ｄｏｅｓ ｎｏｔ ａｌｌｏｗ ｓｃｈｅｄｕｌｅ ｉｎｌｉｎｉｎｇ」というメッセージが表示される。

テーマ
オーケストレーションエンジンデザイナは、ホスト環境を提供する異なるアプリケーションでホスティングすることができる。他のアプリケーションの内側でホスティングされる場合、オーケストレーションエンジンデザイナのルック＆フィールをモーフィングし、ホスティングはアプリケーション内にブレンドすることができる。ユーザは、ユーザのニーズに応じて、Ｖｉｓｕａｌ Ｓｔｕｄｉｏ開発環境の内側でホスティングされている場合にデザイナのビジュアルパラメータを変更できる。テーマサポートにより、ユーザは、デザイナの実装に影響を与えたり、デザイナのコードを修正することなく、オーケストレーションエンジンデザイナのビジュアルパラメータを変更できる。

テーマサポートには、２つの部分があり、１つは開発時のものであり、もう１つは使用時のものである。開発時に、デザイナライターがワークフローに関わるアクティビティに対するデザイナを作成する場合である。デザイナを開発している間、デザイナライターは、テーマサポートに加わることができるようにデザイナを作成する。これは、開発者がデザイナの内側の構成可能ビジュアル化情報を抽象してデザイナテーマクラスに送り、その後、テーマ属性を使用してデザイナに関連付ける。その後、開発者は、デザイナビジュアル化をレンダリングしながらデザイナテーマクラスからの情報を使用する。

ユーザがデザイナを使用する場合、ユーザは、テーマファイルを書くことによりデザイナをモーフィングすることができる。テーマファイルは、それぞれのデザイナで予期されるビジュアル化パラメータを個々に記述するデザイナテーマのコレクションである。テーマファイルは、ユーザ側で、ＸＭＬファイルを手編集するか、または既定のＵＩを通じて作成できる。

テーマを使用することで、開発者は、ワークフローアクティビティの表示をカスタマイズすることができる。それぞれのアクティビティは、「テーマ付け」可能なプロパティの特定の集合を表す対応するデザイナを持つ。テーマを提供することで、さらに、ビジュアル化カスタマイズの拡張性を実現することによりワークフローデザイナをカスタマイズまたは再利用することが可能になる。Ｖｉｓｕａｌ Ｓｔｕｄｉｏ内では、開発者は、Ｔｏｏｌｓメニューへのナビゲート、Ｏｐｔｉｏｎｓの選択、Ｗｏｒｋｆｌｏｗ Ｄｅｓｉｇｎｅｒの選択、およびテーマの選択によりテーマが現在プロジェクトに適用されているものを構成することができる。

開発者は、新しいテーマを作成するか、または「Ｔｈｅｍｅ」ドロップダウンを使用して使用したいテーマを指定することができる。新しいテーマは、開発者が「Ｃｒｅａｔｅ ａ Ｎｅｗ Ｔｈｅｍｅ」を選択し、テーマファイルの名前を指定した場合に作成することができる。「Ｂｒｏｗｓｅ」ボタンを選択すると、Ｆｉｌｅ Ｄｉａｌｏｇが呼び出され、テーマＸＭＬファイルが検索される。Ｄｅｓｉｇｎｅｒドロップダウンでは、開発者は、アクティビティのグループ（ＰｒｉｍｉｔｉｖｅおよびＣｏｍｐｏｓｉｔｅ）、またはそれ自身テーマ付けされる特定のアクティビティを選択することができる。

テーマは、コアグループＰｒｉｍｉｔｉｖｅ（内部でＡｃｔｉｖｉｔｙＤｅｓｉｇｎｅｒから派生する）およびＣｏｍｐｏｓｉｔｅ（内部でＩＣｏｍｐｏｓｉｔｅＡｃｔｉｖｉｔｙＤｅｓｉｇｎｅｒから派生する）で適用できる。これらのツリーのそれぞれから継承するデザイナは、そのテーマを継承する。しかし、特定のアクティビティに対するデザイナは、それぞれ、個別にテーマ設定することができる。これが生じた場合、アクティビティデザイナの明示的テーマ設定は、継承されるビヘイビアよりも優先度が高い。例えば、ＡｃｔｉｖｉｔｙＤｅｓｉｇｎｅｒテーマが青色のテキストフォント色を持つ場合、すべてのデザイナはこのフォント色を使用する。しかし、テーマは、特に、フォント色として赤色を使用するコード形状を呼び出した場合、すべてのアクティビティは、赤色を表示するコード形状を除き、青色のテキストフォント色を表示する。

テーマでは、プロセスビューおよびスケジュールを含むアクティビティのそれぞれをカスタマイズできる。アクティビティデザイナのほとんどは、ＡｃｔｉｖｉｔｙＤｅｓｉｇｎｅｒおよびＩＣｏｍｐｏｓｉｔｅＡｃｔｉｖｉｔｙＤｅｓｉｇｎｅｒ（ＡｃｔｉｖｉｔｙＤｅｓｉｇｎｅｒから派生する）という２つのクラスから派生する。これらは、テーマ設定されている要素およびその対応するピッカーである。プロセスビューでは、テーマ設定される要素は、Ｔｈｅｍｅ Ｓｔｙｌｅ（Ｌａｒｇｅ／Ｍｅｄｉｕｍ／Ｓｍａｌｌ）、Ｓｈｏｗ Ｓｍａｒｔ Ｔａｇ（Ｙｅｓ／Ｎｏ）、Ｓｈｏｗ Ｓｃｒｏｌｌ Ｉｎｄｉｃａｔｏｒｓ（Ｙｅｓ／Ｎｏ）、Ｓｈｏｗ Ｄｒｏｐ Ｉｎｄｉｃａｔｏｒｓ（Ｙｅｓ／Ｎｏ）、Ｓｈｏｗ Ｓｈａｄｏｗ （Ｙｅｓ／Ｎｏ）、Ｗａｔｅｒｍａｒｋ（Ｙｅｓ／Ｎｏ）、Ｆｏｒｅｇｒｏｕｎｄ Ｃｏｌｏｒ（Ｃｏｌｏｒ Ｐｉｃｋｅｒ）、Ｂａｃｋｇｒｏｕｎｄ Ｃｏｌｏｒ（Ｃｏｌｏｒ Ｐｉｃｋｅｒ）、Ｓｈｏｗ Ｇｒｉｄ（Ｙｅｓ／Ｎｏ）、Ｄｒａｗ Ｍｏｎｏｃｈｒｏｍｅ（Ｙｅｓ／Ｎｏ）、Ｓｈｏｗ Ｇｒｉｄ（Ｙｅｓ／Ｎｏ）、Ｓｅｌｅｃｔｉｏｎ（例えば、Ｆｏｒｅｇｒｏｕｎｄ ＣｏｌｏｒおよびＰａｔｔｅｒｎ Ｃｏｌｏｒ）、Ｆｏｎｔ Ｆａｍｉｌｙ（Ｆｏｎｔ Ｐｉｃｋｅｒ）、Ｆｏｎｔ Ｓｔｙｌｅ（Ｆｏｎｔ Ｐｉｃｋｅｒ）、Ｄｒａｗ Ｒｏｕｎｄｅｄ（Ｙｅｓ／Ｎｏ）、Ｃｏｎｔｅｎｔ Ａｌｉｇｎｍｅｎｔ（Ｎｅａｒ／Ｆａｒ／Ｃｅｎｔｅｒ）、Ｓｈｏｗ Ｃｏｎｔｅｎｔ（Ｔｅｘｔ、Ｉｃｏｎ、Ｂｏｔｈ）、Ｓｈｏｗ Ｂｏｒｄｅｒ（Ｙｅｓ／Ｎｏ）、およびＣｏｎｎｅｃｔｏｒ（例えば、ＳｔａｒｔＣａｐおよびＥｎｄＣａｐ）である。

個々のアクティビティデザイナについて、Ｆｏｒｅｇｒｏｕｎｄ Ｃｏｌｏｒ（Ｃｏｌｏｒ Ｐｉｃｋｅｒ）、Ｂａｃｋｇｒｏｕｎｄ Ｃｏｌｏｒ（Ｃｏｌｏｒ Ｐｉｃｋｅｒ）、およびＢｏｒｄｅｒ（例えば、色とスタイル）をテーマ設定できる。個々の複合デザイナについては、Ｄｒｏｐ Ｓｈａｄｏｗ（Ｙｅｓ／Ｎｏ）およびＷａｔｅｒｍａｒｋ（Ｙｅｓ／Ｎｏ）をテーマ設定できる。

印刷プレビュー
他のアプリケーションと同様に、オーケストレーションエンジンデザイナは、Ｐｒｉｎｔ Ｐｒｅｖｉｅｗ（印刷プレビュー）機能を備える。この機能は、プロセス／ワークフロービューの視覚的レイアウトを変更し、現在選択されているプリンタが指定された場合にスケジュールを印刷する方法を反映する。概念的には、Ｐｒｉｎｔ Ｐｒｅｖｉｅｗは、既存のプロセス／ワークフロービュー上のもう１つのビューである。そのため、開発者は、それでも、慣れているすべてのスケジュール、アクティビティ、およびタスク操作を実行できる。Ｐｒｉｎｔ Ｐｒｅｖｉｅｗでは、開発者は、スケジュール操作が行われるときにリアルタイムで印刷の意味を理解することができる。プロセス／ワークフロービューは、全体として（ＳｍａｒｔＴａｇｓを含む） 印刷される。開発者は、Ｆｉｌｅ Ｍｅｎｕから「Ｐｒｉｎｔ Ｐｒｅｖｉｅｗ」を選択するか、または垂直スクロールバーの一番上のアイコンをクリックすることにより印刷プレビューを呼び出すことができる。呼び出されると、既定のビューは、オリジナルの４０％となる。

開発者は、さまざまなページレイアウトを指示し、余白、ヘッダ／フッタオプションなどの通常の文書機能を指定することができ、ワークフローを拡大縮小し、必要に応じて揃えることができる。サイズ変更不可能なＰａｇｅ Ｓｅｔｕｐダイアログ内には２つのタブがある。第１のタブには、ページ特有の日付が示される。Ｐａｐｅｒ Ｓｉｚｅ、Ｐａｐｅｒ Ｓｏｕｒｃｅ、およびＯｒｉｅｎｔａｔｉｏｎに対する値は、既定のプリンタから取り出される。余白は、既定では、すべての辺から１インチ（２．５４ｃｍ）である。最後に、倍率の既定値は、通常サイズの１００％に調整される。ページの中央揃えに既定値はない。Ｐａｇｅ Ｓｅｔｕｐダイアログの第２のタブでは、ＨｅａｄｅｒおよびＦｏｏｔｅｒオプションを扱う。余白に対する既定値は、０．５インチ（１．２７ｃｍ）および中央揃えである。印刷されるページのヘッダおよびフッタを用意する他の多くのアプリケーションと同様、テキストのテンプレートを作成できる。既定のテンプレートオプションには、以下のものがある。

これらのテンプレートオプションは、ヘッダとフッタの両方に利用できる。しかし、開発者は、「Ｃｕｓｔｏｍ」テキストボックスで独自のテキストを指定することができる。

アクセシビリティ＆キーボードナビゲーション
オーケストレーションエンジンデザイナは、アクティビティレベルによりあるアクティビティの構成されたスケジュール設定済みスケジュールをナビゲートする機能を備える。以下のキーボードナビゲーションがサポートされる。
−開発者は、上、下、左、および右矢印キーを使用してスケジュールをトラバースすることができる。
−複合アクティビティは、「＋」キーを使用して展開し、「−」を使用して縮小することができる。
−開発者は、ドラッグ＆ドロップ実行中に、ｅ−ｅｓｃａｐｅキーを叩くことによりそのオペレーションをキャンセルすることができる。
−Ｅｎｔｅｒキーを叩いても、アクティビティ上でダブルクリックすることと同じ効果が得られる。

ＵＩ永続性
デザイナは、ズーム、印刷プレビュー状態、スクロールバー位置、選択、および複合アクティビティの展開または縮小状態を含むアクティビティデザイナ特有の状態、スコープおよびスケジュールのワークフロー対例外対イベント状態、制約アクティビティグループ（ＣＡＧ）編集またはプレビューモード、プレビューアクティビティの現在アクティブになっているアクティビティ（例えば、ＣＡＧ、イベント、および例外の）、およびインライン化状態に対するＵＩ構成を保存することができる。

ＸＯＭＬビュー
スケジュールを作成するときに、開発者は、基本的に、ワークフローの編集可能なグラフィック表現（望まれている場合には必ずＸＭＬとして操作することも可能な）およびコードビサイド（例えば、Ｃ＃またはＶｉｓｕａｌ Ｂａｓｉｃ）の２つの別々のアイテムを操作している。この定義は、ＸＭＬまたはＸＯＭＬとして操作することができる。ＸＯＭＬは、スケジュールのＸＭＬ表現である。プロセス／ワークフローデザイナの目的は、開発者がこのＸＭＬを素早く生成することを手助けすることである。

開発者は、機能豊富なグラフィックプロセス／ワークフロービューとスキーマベースのＸＭＬビュー（ＸＯＭＬビュー）を切り換えることができる。これを実行するために、開発者は、ワークフロー設計ウィンドウの左下隅に配置されている小さなボタンを使用するか、またはホットキーＦ７（ＸＯＭＬ用）とＳｈｉｆｔ−Ｆ７（プロセス／ワークフロービュー用）を使用してビューを切り換えることができる。ＸＯＭＬエディタは、ＩｎｔｅｌｌｉＳｅｎｓｅ、カラー化、メソッドヒント、およびステートメントコンプリーションの機能を備える。開発者は、Ｃｏｎｔｒｏｌキーを押しながら、スペースバーを同時に押すことによりＩｎｔｅｌｌｉｓｅｎｓｅを呼び出すことができる。標準Ｃ＃／ＶＢエディタと同様に、ＸｏｍｌビューはＸｏｍｌ定義のアウトラインを作成する機能も備える。これは、右クリックして、「Ｏｕｔｌｉｎｇ」コンテキストメニューを選択することにより使用することができる。

テーマ属性
テーマをアクティビティデザイナに関連付けるには、アクティビティデザイナをＴｈｅｍｅＡｔｔｒｉｂｕｔｅで装飾する必要がある。この方法でデザイナライターはテーマ関連メタデータをデザイナに関連付けることができる。テーマインフラストラクチャでは、デザイナが作成されるときにこのメタデータをピックアップし、デザイナビジュアル化をレンダリングする必要が生じたときに必要に応じてデザイナに渡すことができる。以下に、テーマ属性をｓｅｎｄデザイナに関連付ける方法の実施例を示す。
Ｔｈｅｍｅ属性クラスは、デザイナに関連付けられたテーマオブジェクトの型およびテーマオブジェクトを初期化するイニシャライザＸＭＬの２つのパラメータをとる。イニシャライザＸＭＬは、オプションのパラメータである。

デザイナテーマをデザイナに関連付けることに加えて、デザイナライターはデザイナからビジュアル化データを抽象する。デザイナライターは、ＤｅｓｉｇｎｅｒＴｈｅｍｅ派生クラスを作成し、抽象されたデータをそのクラスに置く。その後、デザイナライターは、派生デザイナテーマクラスに、レンダリング、レイアウト作成などのオペレーションで使用されるパラメータを問い合わせる。ＤｅｓｉｇｎｅｒＴｈｅｍｅクラスは、すべてのデザイナテーマの派生元とする必要のある基本クラスである。このクラスは、テーマサポートに加わるためにすべてのデザイナが使用する基本情報を含む。ＤｅｓｉｇｎｅｒＴｈｅｍｅクラス内の基本データメンバは以下のとおりである。

上記のメンバは、個々のデザイナとテーマとの関連付けを提供する。それぞれのデザイナがそれ自体のレンダリングのための追加情報を持つ必要のある場合がある。これは、ＤｅｓｉｇｎｅｒＴｈｅｍｅクラスからデザイナ特有のテーマクラスを派生させ、特定の情報をそのクラス内に置くことにより実行される。

ＡｃｔｉｖｉｔｙＤｅｓｉｇｎｅｒＴｈｅｍｅクラスは、Ｓｅｎｄ、Ｒｅｃｅｉｖｅ、Ｄｅｌａｙなどの単純なデザイナのテーマを記述するために使用される。単純なデザイナは、それらの下に他のデザイナの階層を持たず、ＡｃｔｉｖｉｔｙＤｅｓｉｇｎｅｒＴｈｅｍｅクラスの情報に基づいてそれ自身をレンダリングすることができる。それぞれのデザイナは、自身のレンダリングのためＡｃｔｉｖｉｔｙＤｅｓｉｇｎｅｒＴｈｅｍｅクラスの初期化に使用される独自のイニシャライザＸＭＬを持つ。抽象された情報を記述するためにＡｃｔｉｖｉｔｙＤｅｓｉｇｎｅｒＴｈｅｍｅクラスを使用する各種デザイナは、ＡｃｔｉｖｉｔｙＤｅｓｉｇｎｅｒ、ＣｏｄｅＤｅｓｉｇｎｅｒ、ＣｏｍｐｅｎｓａｔｅＤｅｓｉｇｎｅｒ、ＤｅｌａｙＤｅｓｉｇｎｅｒ、ＦａｕｌｔＤｅｓｉｇｎｅｒ、ＩｎｖｏｋｅＷｅｂＳｅｒｖｉｃｅＤｅｓｉｇｎｅｒ、ＲｅｃｅｉｖｅＤｅｓｉｇｎｅｒ、ＲｅｃｅｉｖｅＲｅｑｕｅｓｔＤｅｓｉｇｎｅｒ、ＲｅｃｅｉｖｅＲｅｓｐｏｎｓｅＤｅｓｉｇｎｅｒ、ＳｅｎｄＤｅｓｉｇｎｅｒ、ＳｅｎｄＲｅｑｕｅｓｔＤｅｓｉｇｎｅｒ、ＳｅｎｄＲｅｓｐｏｎｓｅＤｅｓｉｇｎｅｒ、ＳｕｓｐｅｎｄＤｅｓｉｇｎｅｒ、およびＴｅｒｍｉｎａｔｅＤｅｓｉｇｎｅｒである。

以下にアクティビティデザイナクラスのメンバを示す。

ＣｏｍｐｏｓｉｔｅＤｅｓｉｇｎｅｒＴｈｅｍｅクラスは、ＰａｒａｌｌｅｌまたはＳｅｑｕｅｎｃｅなどの複合デザイナのビジュアル化情報を抽象するために使用される。このクラスは、Ｃｏｎｎｅｃｔｏｒｓのレンダリングに関係する情報および複合デザイナ内のヘッダ／フッタを保持する。ＡｃｔｉｖｉｔｙＤｅｓｉｇｎｅｒＴｈｅｍｅクラスのメンバに加えて、ＣｏｍｐｏｓｉｔｅＤｅｓｉｇｎｅｒＴｈｅｍｅクラスは、以下のプロパティを含む。

ＣｏｍｐｏｓｉｔｅＤｅｓｉｇｎｅｒＴｈｅｍｅが関連付けられている各種デザイナは、ＣｏｍｐｏｓｉｔｅＡｃｔｉｖｉｔｙＤｅｓｉｇｎｅｒ、ＣｏｍｐｅｎｓａｔｉｏｎＨａｎｄｌｅｒＤｅｓｉｇｎｅｒ、ＣｏｎｄｉｔｉｏｎａｌＤｅｓｉｇｎｅｒ、ＣｏｎｄｉｔｉｏｎｅｄＤｅｓｉｇｎｅｒ、ＥｖｅｎｔＤｒｉｖｅｎＤｅｓｉｇｎｅｒ、ＥｖｅｎｔＨａｎｄｌｅｒＤｅｓｉｇｎｅｒ、ＥｘｃｅｐｔｉｏｎＨａｎｄｌｅｒＤｅｓｉｇｎｅｒ、ＣｏｍｐｏｓｉｔｅＳｃｈｅｄｕｌｅＤｅｓｉｇｎｅｒ、ＬｉｓｔｅｎＤｅｓｉｇｎｅｒ、ＰａｒａｌｌｅｌＤｅｓｉｇｎｅｒ、ＳｃｏｐｅＤｅｓｉｇｎｅｒ、ＳｅｑｕｅｎｃｅＤｅｓｉｇｎｅｒ、ＧｅｎｅｒｉｃＴａｓｋＤｅｓｉｇｎｅｒ、ＷｈｉｌｅＤｅｓｉｇｎｅｒである。

ＰｒｅｖｉｅｗＤｅｓｉｇｎｅｒＴｈｅｍｅは、ＣＡＧ、ＥｘｃｅｐｔｉｏｎＨａｎｄｌｅｒｓＤｅｓｉｇｎｅｒなどのデザイナに関連付けられており、これらはその中の子デザイナのコレクションをアイテムストリップの形で表示する。このクラスは、アイテムストリップをレンダリングするために使用されるデータだけでなく、それらのアイテムが表示されるプレビューウィンドウも含む。ＣｏｍｐｏｓｉｔｅＤｅｓｉｇｎｅｒＴｈｅｍｅクラスのメンバのほかに、ＰｒｅｖｉｅｗＤｅｓｉｇｎｅｒＴｈｅｍｅクラスは以下のプロパティを含む。

ＰｒｅｖｉｅｗＤｅｓｉｇｎｅｒＴｈｅｍｅに関連付けられている各種デザイナは、ＡｃｔｉｖｉｔｙＰｒｅｖｉｅｗＤｅｓｉｇｎｅｒ、ＣＡＧＤｅｓｉｇｎｅｒ、ＥｖｅｎｔＨａｎｄｌｅｒｓＤｅｓｉｇｎｅｒ、およびＥｘｃｅｐｔｉｏｎＨａｎｄｌｅｒｓＤｅｓｉｇｎｅｒである。

ＡｍｂｉｅｎｔＴｈｅｍｅクラスは、ＷｏｒｋｆｌｏｗＶｉｅｗに関連付けられており、ＷｏｒｋｆｌｏｗＶｉｅｗのレンダリングに関する情報だけを含むわけではない。このクラスに含まれる情報は、選択、スマートタグ、展開ボタンなどのすべてのデザイナに適用される大域的ビジュアル化オプションに関係する。これに加えて、グリッド、ワークフロー背景、ウォーターマークなど何かを描画することに関する情報もこのクラスに含まれる。

ＤｅｓｉｇｎｅｒＴｈｅｍｅクラスのメンバのほかに、ＳｅｒｖｉｃｅＲｏｏｔＤｅｓｉｇｎｅｒＴｈｅｍｅクラスは以下のプロパティを含む。

テーマがデザイナに関連付けられた後、デザイナは、レイアウト、レンダリング、またはテーマパラメータが必要なその他のアクティビティを実行する場合にそれを使用する。ＧｅｔＤｅｓｉｇｎｅｒＴｈｅｍｅメソッドは、デザイナの型をパラメータとしてとる。このメソッドは、呼び出されると、Ｔｈｅｍｅクラスがデザイナに関連付けられたＤｅｓｉｇｎｅｒＴｈｅｍｅ派生テーマクラスを返す。次に、デザイナは、ＤｅｓｉｇｎｅｒＴｈｅｍｅ派生クラスのさまざまなパラメータにアクセスできるだけでなく、ＤｅｓｉｇｎｅｒＴｈｅｍｅクラスに関連付けられた資源を取得してデザイナをレンダリングすることもできる。テーマクラスは、現在のデザイナテーマ、そのテーマに関連付けられた資源、およびさらにはユーザがテーマを変更した場合のイベント発火を管理する役割を持つ。

Ｔｈｅｍｅクラスは、ＤｅｓｉｇｎｅｒＴｈｅｍｅｓを管理するインフラストラクチャを含む。以下に、Ｔｈｅｍｅクラスの機能を示す。
−ＤｅｓｉｇｎｅｒＴｈｅｍｅｓをシリアライズ／デシリアライズする。
−シリアライゼーションプロセスで発生したエラーを報告する。
−テーマが変化した場合にイベントを発火する。
−別のデザイナに関連付けられている、ＤｅｓｉｇｎｅｒＴｈｅｍｅクラスを管理する。
−テーマ資源を管理し、描画のため作成されたオブジェクトのキャッシュとして機能する。
−含まれるＤｅｓｉｇｎｅｒＴｈｅｍｅｓにより要求された資源解決を実行する。
テーマクラスは、デザイナでテーマをサポートできるように、以下のプロパティを公開している。

テーマクラスは、アクティビティデザイナをレンダリングするために使用されるデザイナテーマをすべて保持しており、そのため、資源およびテーマ情報を大域的に維持することができる。これらの資源はすべて、同じプロセスを持つデザイナの異なるインスタンスにまたがって共有される。このため、資源プールの漏れが防止されるだけでなく、デザイナがオブジェクトを作成し直さなくてもよいためパフォーマンスが高められる。

テーマクラスは、さらに、静的ＴｈｅｍｅＣｈａｎｇｅｄイベントも公開する。すべてのワークフロービューは、このイベントを監視する。ユーザが現在のテーマを変更した場合、テーマクラスによりすべてのワークフロービューが監視しているＴｈｅｍｅＣｈａｎｇｅｄイベントが発火する。その後、ワークフロービューは、ＩＡｃｔｉｖｉｔｙＤｅｓｉｇｎｅｒ．ＯｎＴｈｅｍｅＣｈａｎｇｅｄメソッドを呼び出すことにより、自分自身および含まれるデザイナを中継で送る。それぞれのデザイナは、このメソッドをオーバーライドし、テーマ変更イベントに対する応答としてカスタムアクションを実行することができる。

ユーザは、それぞれの個々のデザイナがそれ自身をレンダリングするために従わなければならないパラメータを記述する特定のテーマを書くことによりデザインサーフェスの表示をモーフィングすることができる。ユーザは、そのために、テーマファイルを書く。テーマファイルは、デザイナ毎にテーマパラメータを記述する個々のデザイナテーマセクションを含むＸＭＬファイルである。ユーザは、テーマファイルを手作業で作成するか、または既定のＵＩを使用することができる。

ＸＭＬファイルを手編集することは、テーマを作成する一手段である。テーマを作成する他の方法として、提供されているＵＩを使用する方法がある。Ｖｉｓｕａｌ Ｓｔｕｄｉｏ内にあるデザイナを使用する場合、テーマをカスタマイズするＵＩは、Ｔｏｏｌｓ−＞Ｏｐｔｉｏｎｓ−＞Ｗｏｒｋｆｌｏｗ Ｄｅｓｉｇｎｅｒ−＞Ｔｈｅｍｅｓの下に表示される。テーマＵＩは再ホスティング可能である。オーケストレーションエンジンデザイナがＶｉｓｕａｌ Ｓｔｕｄｉｏの外部でホスティングされる場合、ユーザは自前のダイアログを書いて、テーマＵＩをホスティングすることができる。ユーザは、Ｖｉｓｕａｌ Ｓｔｕｄｉｏの外部でテーマＵＩを再ホスティングするために、ＴｈｅｍｅＰａｇｅクラスを使用することができる。

テーマＵＩでは、テーマを作成する複数の手段を用意している。ユーザは、既存のテーマを選択するか、または既存のテーマを選択してそれらを修正し新しいテーマを作成することができる。ユーザは、テーマを修正した後、保存ボタンを選択することによりそのテーマを異なるテーマファイルとして保存することができる。テーマＵＩは、プロパティ構成およびデザイナプレビューの２つの異なるモードで動作する。ユーザは、プレビューモードボタンを使用することによりこれをめくってゆくことができる。

プロパティ構成モードでは、ユーザは個々のデザイナを選択できる。ドロップダウンからデザイナが選択された場合、デザイナに関連付けられたプロパティがプロパティブラウザに表示される。ユーザは、それらのプロパティをめくってゆき、デザイナの表示を修正することができる。個々のプロパティを修正した結果は、デザイナプレビューモードに入ることにより表示できる。デザイナプレビューモードでは、デザインサーフェスはダイアログ内にホスティングされる。一時的アクティビティツリーがメモリ内に作成され、個々のデザイナ上のテーマ変更の結果を示す。

オートスクロール
オートスクロール機能を使用すると、ユーザは、ドラッグ＆ドロップオペレーションを実行しながら、またはオートパニングを実行しながらワークフローの任意の部分に素早くナビゲートすることができる。オートスクロール機能は、オートスクロールインジケータを追加することにより強化される。オートスクロールインジケータは、ユーザがオートスクロールの可能な方向を理解することができるようにする視覚的手掛かりである。オートスクロールインジケータ機能により、デザイナの使い勝手が向上する。

ＷｏｒｋｆｌｏｗＶｉｅｗは、オートスクロールインジケータを表示する必要がある場合にそのことを示す論理値を返すＳｈｏｗＡｕｔｏＳｃｒｏｌｌＩｎｄｉｃａｔｏｒｓと呼ばれるプロパティをサポートする。ＷｏｒｋｆｌｏｗＶｉｅｗは、スクロールが可能な方向を示すビットマップを含む。オートパニングまたはドラッグ＆ドロップイベントの場合、ＷｏｒｋｆｌｏｗＶｉｅｗはクライアント領域のペインティングを要求する。ペインティング要求に対する応答として、描画ロジックをオーバーライドすることによりオートスクロールインジケータを半透明に描画する。

ユーザは、ビューポートに入りきらないワークフローを持つことが多い（任意の時点においてワークフロービューの一部がユーザに見える）。このような場合、ワークフロービューは関連する水平および垂直スクロールバーを持つ。これは、ユーザがツールボックスから新しいオブジェクトをドラッグしようとして、可視でないワークフローの部分にドロップしたい、またはワークフロー内のアクティビティの順序を変更したい場合には、よくあることである。これは、小さなワークフローについてはクロールせずに可能であるが、大きなワークフローでは、ユーザがビューポートの外にオブジェクトをドロップしたい場合にデザイナをスクロールする必要がある。ワークフロービューに実装されているオートスクロール機能を使用すると、ユーザがマウスをドラッグし、オートスクロールゾーン上でホバリングすると、ワークフローをスクロールすることができる。以下に、これを実行する方法を例示する擬似コードを示す。

−すべてのドラッグ＆ドロップメッセージについて
メッセージがドラッグホバーならば
ワークフロービューがビューポートに入りきらなければ
辺にそってワークフローの１０％をとることによりオートスクロールゾーンを計算する
−マウスアクションの座標がオートスクロールゾーンおよびワークフロービュースクロール内に入るならば
−オートスクロールタイマーをトリガする
−オートスクロールゾーン内のマウス位置に基づいてスクロール位置を加減する
−さもなければ
−オートスクロールタイマーを停止する
コネクタ装飾のドラッグ＆ドロップ
この機能により、ドラッグ＆ドロップオペレーションの使い勝手が向上する。ユーザがコンポーネントのドラッグを開始すると、デザイナは、ドラッグされたコンポーネントのドロップを可能にするそれらのコネクタを自動的に区別する。カーソルがコネクタに十分近づくと、ドラッグされた画像がコネクタにスナップインする。ワークフロービューは、アクティビティ上に装飾を追加する装飾サービスを含む。装飾サービスにより、すべてのアクティビティの描画が実行された後、アクティビティは通常使用されるＵＩグリフを描画することができる。これにより、グリフはどれも他のアクティビティによって上書きされず、グリフに対し特別な処置が講じられることが保証される。現在、アクティビティはさまざまな種類のグリフをサポートし、これらは不十分な構成、選択、選択可能なコネクタ、ブレークポイントなどを含む。装飾サービスクラスは、ワークフロービューのプライベートヘルパークラスとして表示することができる。装飾サービスは、グリフがアクティブになったときにグリフを異なる形で表現する役割を持つ。グリフは、グリフ上でユーザが実行するマウスアクションに基づいてアクティブになりうるが、これらはマウスホバーまたはマウスクリックを含む。アクティブなグリフは、それがアクティブな場合に基づいて異なるアクションを実行でき、これはドロップダウンメニューの表示またはプロパティブラウザへのナビゲーションのトリガ、アクティビティ上にスマートタグアクショングリフを表示するバリデーションルーチンのトリガなどを含む。アクティビティ上にグリフを追加することに加えて、装飾サービスでは、さらに、ＩＰｒｏｐｅｒｔｙＶａｌｕｅＵｌＳｅｒｖｉｃｅを使用してプロパティブラウザ上にグリフを追加する。装飾サービスは、グリフに関連付けられているデザイナアクションをＶｉｓｕａｌ Ｓｔｕｄｉｏ ＩＤＥのタスクリストに追加する役割を持つ。

作成後、装飾サービスは、どのアクティビティデザイナがグリフを表す必要を感じるかに基づいて異なるイベントの監視を開始する。これらのイベントは以下を含む。
ＩＣｏｍｐｏｎｅｎｔＣｈａｎｇｅＳｅｒｖｉｃｅ
ＣｏｍｐｏｎｅｎｔＣｈａｎｇｅｄ：コンポーネントプロパティが変更された場合にトリガされる。
ＣｏｍｐｏｎｅｎｔＡｄｄｅｄ：新しいコンポーネントが追加された場合にトリガされる。
ＣｏｍｐｏｎｅｎｔＲｅｍｏｖｅｄ：コンポーネントが削除された場合にトリガされる。
ＩＳｅｌｅｃｔｉｏｎＳｅｒｖｉｃｅ
ＳｅｌｅｃｔｉｏｎＣｈａｎｇｅｄ：デザイナのＳｅｌｅｃｔｉｏｎが変更された場合に発火する。
ＩＰｒｏｐｅｒｔｙＶａｌｕｅＵＩＳｅｒｖｉｃｅ
ＡｄｄＰｒｏｐｅｒｔｙＶａｌｕｅＵｌＨａｎｄｌｅｒ：プロパティブラウザ内で選択変更またはプロパティリフレッシュが生じたときに発火する。
ＩＴｙｐｅＰｒｏｖｉｄｅｒ
ＴｙｐｅｓＣｈａｎｇｅｄ：新しい型がタイプシステムに追加／削除された場合に発火する。

上記のイベントの１つがトリガされた場合には必ず、装飾サービスは次のアイドル状態のメッセージを待つ。アイドル状態のメッセージで、装飾サービスはアクティビティデザイナに、グリフに関連付けられているデザイナアクションを更新するよう要求し、表示可能なデザイナを無効化する。デザイナアクションの要求により、バックグラウンドバリデーションがトリガされる。更新されたデザイナアクションを取得した後、装飾サービスは、選択されたデザイナに関連付けられているアクションをタスクリストに入れ、さらに、ＩＰｒｏｐｅｒｔｙＶａｌｕｅＵＩＳｅｒｖｉｃｅでＮｏｔｉｆｙＰｒｏｐｅｒｔｙＶａｌｕｅＵＩＩｔｅｍｓＣｈａｎｇｅｄ関数を呼び出すことによりプロパティブラウザに変更を通知し、これはさらに、プロパティがプロパティブラウザ内のプロパティ上でｃｏｎｆｉｇ.Ｉｃｏｎを必要としていることを示す。このアイコンがクリックされると、そのプロパティに関連付けられているデザイナアクションがトリガされる。その後、装飾サービスはすべてのデザイナを通り、そのグリフを取得し、デザイナの上にグリフを描画する。マウスホバーまたはクリックがグリフのどれかの上で発生すると、装飾サービスはグリフをアクティブ化し、デザイナアクションを表示する。

アクティビティデザイナにより返されるグリフはすべて、ＤｅｓｉｇｎｅｒＧｌｙｐｈと呼ばれる抽象クラスから派生する。このクラスは、グリフのそれぞれに関係するビヘイビアを定義する。以下に、ＤｅｓｉｇｎｅｒＧｌｙｐｈクラスのクラス定義を示す。以下の表は、ＤｅｓｉｇｎｅｒＧｌｙｐｈクラスのメソッドのそれぞれとその使用法について説明している。

グリフは、関連付けられたＤｅｓｉｇｎｅｒＡｃｔｉｏｎｓを持つ場合も持たない場合もある。デザイナアクションは、ユーザがグリフをアクティブ化した場合に実行される必要のあるユーザアクションの集合である。ＤｅｓｉｇｎｅｒＡｃｔｉｏｎクラスは、ユーザアクションを示すために使用される。ＤｅｓｉｇｎｅｒＡｃｔｉｏｎクラスは、メニューアイテムを表示するために使用されるＤｅｓｉｇｎｅｒＶｅｒｂというクラスから派生する。ＤｅｓｉｇｎｅｒＡｃｔｉｏｎは、装飾サービスによりタスクアイテムを追加する場合にも使用される。
以下に、さまざまな目的のためにデザイナにより現在使用されている各種のグリフを示す。

現在のドラッグされたオブジェクトを受け入れることが可能なコネクタを示すアイコンが、装飾サービスを通じて描画される。ＩＤｅｓｉｇｎｅｒＳｅｒｖｉｃｅはプロパティ「ＩＣｏｍｐｏｎｅｎｔ［］ ＤｒａｇｇｅｄＣｏｍｐｏｎｅｎｔｓ」を公開するが、これにより、すべてのアクティビティデザイナは、ドラッグされたオブジェクトにアクセスし、すべてのコネクタと突き合わせてテストすることができる（一部のデザイナでは、それらのコネクタの部分集合だけでドロップできる）。パブリックオーバーライドＤｅｓｉｇｎｅｒＧｌｙｐｈ［］ Ｇｌｙｐｈｓメソッドを通じてすべての装飾グリフに対するアクティビティが求められた場合、
−ＩＤｅｓｉｇｎｅｒＳｅｒｖｉｃｅのＤｒａｇｇｅｄＣｏｍｐｏｎｅｎｔｓプロパティにアクセスすることによりデザインサーフェスが現在ドラッグ＆ドロップオペレーションの最中であるかチェックする
−すべてのコネクタについて、
−ＣａｎＩｎｓｅｒｔＡｃｔｉｖｉｔｉｅｓ（）を呼び出して、コネクタがドロップオペレーションを許容するか確認する
−ＤｅｓｉｇｎｅｒＨｅｌｐｅｒｓ．ＩｓＣｏｎｔｅｘｔＲｅａｄＯｎｌｙ（）によりデザイナが読み取り専用サイトにないかチェックする（スケジュールを呼び出す）
−そのコネクタに対するＣｏｎｎｅｃｔｏｒＤｒａｇＤｒｏｐＧｌｙｐｈのインスタンスを作成する
ドラッグされた画像とともにカーソルが、ドロップが有効になっている領域上をホバリングすると、ドラッグされた画像はコネクタの真ん中にスナップする。
−ＯｎＤｒａｇＥｎｔｅｒ（）およびＯｎＤｒａｇＯｖｅｒ（）イベントは、ＷｏｒｋｆｌｏｗＤｒａｇＥｖｅｎｔＡｒｇｓのインスタンスを第１のパラメータとして取得する
−ＷｏｒｋｆｌｏｗＤｒａｇＥｖｅｎｔＡｒｇｓは、ドラッグされたデザイナを所定の点にスナップしたいことをデザイナが示すようにできるプロパティｐｕｂｌｉｃ Ｐｏｉｎｔ ＳｎａｐＩｎＰｏｉｎｔ｛｝を持つ。
−ＷｏｒｋｆｌｏｗＶｉｅｗコントロールは、ドラッグされた画像をデザイナが要求したかチェックし、
−画像の半透明モードを削除する
−デザイナ要求位置に画像を置く
−ＳｅｑｕｅｎｔｉａｌＡｃｔｉｖｉｔｙＤｅｓｉｇｎｅｒは、ＯｎＤｒａｇＥｎｔｅｒ（）およびＯｎＤｒａｇＯｖｅｒ（）の両方のイベントをオーバーライドし、所有していれば現在のドロップターゲットの真ん中を示す。

パンニング／ズーミングツール
本発明は、ツールとして、Ｚｏｏｍ Ｉｎ／Ｏｕｔ（ズームレベルの増減、およびクリックした点の周りのビューの中央揃え）およびＰａｎ（クリックするとデザインサーフェスを「掴み」、ドラッグしてあちこち動かせる手）を含む。すべてのツールはマウスおよびキーボードイベントの処理を完全にオーバーライドするので、戦略デザインパターンは、すべてのイベントを処理する置き換え可能なＩＤｅｓｉｇｎｅｒＭｅｓｓａｇｅＦｉｌｔｅｒオブジェクトを作成する。インターフェイスＩＤｅｓｉｇｎｅｒＭｅｓｓａｇｅＦｉｌｔｅｒは以下のように定義される。

これらの関数は、マウスイベントハンドラ、キーボードイベントハンドラ、およびメッセージフィルタおよびその状態に基づいてＷｏｒｋｆｌｏｗＶｉｅｗカーソルの形状を変更するＵｐｄａｔｅＣｕｒｓｏｒ（）関数に分けられる。

ワークフロービュー自体は、デザイナメッセージフィルタの既定のビヘイビアを実装する。ズーム機能（Ｚｏｏｍ ＩｎおよびＺｏｏｍ Ｏｕｔ毎に１つ、ユーザはＳｈｉｆｔキーを押してＩｎ／Ｏｕｔモードを切り換えることができる）およびパニング機能に２つのメッセージフィルタが存在する。

ＸｏｍｌＤｏｃｕｍｅｎｔＲｏｏｔＶｉｅｗ
ＸｏｍｌＷｉｎｄｏｗＰａｎｅによって作成されるコントロールは、ＸｏｍｌＤｏｃｕｍｅｎｔＲｏｏｔＶｉｅｗである。このコントロールは、垂直スクロールバーおよび水平スクロールバーを持つ。さらに、水平スクロールバーの左側と垂直スクロールバーの下側にタブボタンがある。水平スクロールバーのタブボタンは、複数のビューのホスティングを表示するために使用される。第１のタブでは、ワークフロービューであるｓｕｒｆａｃｅ．ＧｅｔＶｉｅｗ（）によって返されるビューをホスティングし、第２のタブへは、Ｍｉｃｒｏｓｏｆｔ Ｘｍｌエディタをホスティングする。水平スクロールバー内のタブを変更すると、適切なビュー変更イベントが発火する。これはＩＶｉｅｗＣｒｅａｔｉｏｎＳｅｒｖｉｃｅを使用してビューを作成する。異なるビュー作成サービスをフックすることにより、さらにビューを追加することができる。以下に、ＩＶｉｅｗＣｒｅａｔｉｏｎＳｅｒｖｉｃｅのインターフェイス定義を示す。

このサービスの実装は以下を実行する。

この方法で作成されたすべてのビューは、ＩＤｅｓｉｇｎｅｒＶｉｅｗから継承しなければならない。以下に、ＩＤｅｓｉｇｎｅｒＶｉｅｗのインターフェイス定義を示す。

Ｖｉｅｗ Ｓｃｏｐｅ
これは、デザイナに追加した場合のスコープの既定のビューである。このオプションを選択すると、開発者はこのビューに戻ることができる。
Ｖｉｅｗ Ｅｘｃｅｐｔｉｏｎｓ
このオプションを選択すると、ＵＩがインプレースで変更され、Ｓｃｏｐｅに関連付けられている例外が表示される。これは、Ｔｒａｎｓａｃｔｉｏｎ ＴｙｐｅがＬｏｎｇ Ｒｕｎｎｉｎｇ（長時間実行）またはＮｏｎｅ（なし）の場合に有効にされる。言い換えると、このメニューは、Ｔｒａｎｓａｃｔｉｏｎ ＴｙｐｅがＡｔｏｍｉｃ（アトミック）の場合には利用できないということである。
Ｖｉｅｗ Ｅｖｅｎｔｓ
このオプションを選択すると、ＵＩがインプレースで変更され、Ｓｃｏｐｅに関連付けられているイベントハンドラが表示される。
Ｖｉｅｗ Ｃｏｍｐｅｎｓａｔｉｏｎ
このオプションを選択すると、ＵＩがインプレースで変更され、Ｓｃｏｐｅで定義されているＣｏｍｐｅｎｓａｔｉｏｎが表示される。これはＴｒａｎｓａｃｔｉｏｎ型プロパティがＬｏｎｇ ＲｕｎｎｉｎｇまたはＡｔｏｍｉｃに設定されている場合に有効である。

その他のＵＩ機能
ワークフローをより視覚的に目立たせるために、ワークフロー内に表示されるアクティビティのそれぞれにシャドウを追加する視覚的深さを設定できる。これは視覚的喚起力を加えるが、ワークフロー内のすべてのアクティビティに対しシャドウを描画しなければならないので、ユーザ対話操作をわずかにスローダウンさせる。視覚的深さは０から４までとすることができる。この数値に基づいて、シャドウ深さ（shadow depth）が決定される。視覚的深さが設定されたら、ワークフローを描画する毎に、メモリスナップショットを作成し、グレースケール変換をビットマップに適用する。その後、このグレースケールビットマップは、Ｇｒａｐｈｉｃｓオブジェクトへの視覚的深さを使用してユーザにより指定されたオフセットでレンダリングされる。その後、メモリスナップショットの背景を透明にし、それをグレースケールビットマップの上にコピーする。こうして、ワークフローに３Ｄ効果を与える。

ワークフロービューは、さまざまなレイアウトをサポートしており、ユーザには、ワークフローのさまざまな表現を提示できる。この機能は、さらに、ワークフローの印刷プレビューを表示するためにも使用される。ユーザは、印刷プレビューモードのときに、ワークフローを編集し、余白を設定し、ヘッダ／フッタを追加することができる。これにより、ユーザは、ワークフローの印刷方法をはっきり理解できる。ワークフロービューは、IWorkflowLayoutと呼ばれるインターフェイスを通じて複数のレイアウトをホスティングする。このインターフェイスにより、ＷｏｒｋｆｌｏｗＶｉｅｗは、さまざまなレイアウトを描画する際に使用される情報を取得することができ、またそれらのレイアウトで座標変換、拡大縮小、および描画などの特定のオペレーションを実行することができる。
以下に、新しいレイアウトを作成するために実装されるプロパティおよびメソッドを示す。

デザイナは、既定のレイアウトおよび印刷プレビューレイアウトをサポートする。既定のレイアウトは、ワークフローの単純な表現である。このレイアウトでは、ワークフローは、ビューポート内の中央に揃えられ、レイアウトは決して、描画されるワークフローの表現を変えない。Ｐｒｉｎｔ Ｐｒｅｖｉｅｗレイアウトは、ページの上にワークフローを描画することによりワークフローの表現を著しく変える。印刷プレビューレイアウトは、印刷文書からのデータおよびページ設定データを取得して、ページサイズ、拡大縮小、および最大範囲を計算し、ヘッダ／フッタをレンダリングする。印刷プレビューレイアウトは、ワークフローをプリンタに出力する方法を示す。このモードでは、ユーザは余白を設定し、ヘッダ／フッタの表示のされ方を確認し、必要に応じてワークフローを拡大縮小し、位置揃えをすることができる。印刷プレビューレイアウトでは、さらに、ユーザはプレビューしながらワークフローを修正することができる。印刷プレビューレイアウトは、ワークフロービットマップの複数の断片をつなぎ合わせで作成し、異なる複数のページとしてレンダリングする。

ユーザがＷｏｒｋｆｌｏｗＶｉｅｗ上でオブジェクトのドラッグを開始すると、ドラッグ＆ドロップインジケータが表示される。ドラッグ＆ドロップインジケータは、どのオブジェクトがドラッグ＆ドロップオペレーションによりデータとして現在キャッシュされているかをユーザに視覚的に示す。ワークフロービューがドラッグエンターイベントを受け取ったら、ドラッグされたコンポーネントのデシリアライズおよびキャッシュを試みる。その後、ビューでは、一時的ビットマップを作成し、そのコンポーネントのアイコンおよび説明をその上に描画することによりメモリビットマップの形でドラッグされたコンポーネントの視覚的表現を作成する。次に、このメモリビットマップは、マウスカーソルとともに描画され、どのオブジェクトがドラッグされているかを示す。ドラッグオペレーションが終了すると、ワークフロービューはキャッシュされているビットマップおよびコンポーネントを破壊する。

ワークフロービューは、２種類の座標系をサポートする。物理座標系と呼ばれるクライアント座標系（Ｗｉｎｆｏｒｍｓコントロールでも使用する）および論理座標系。クライアント座標系では、コントロールの左上の点は０，０であり、ＸおよびＹ座標は、垂直および水平方向に増え、この陳述は、スクロールバーが存在しない場合のみ真である。スクロールバーが存在する場合、Ｗｉｎｄｏｗｓ（登録商標）コントロールの左上、つまり０，０は、スクロールバー位置である。クライアント座標系は、さらに、拡大率の影響も受ける。論理座標系では、すべてのオブジェクトは常に０，０からｍ，ｎにマッピングされ、この座標系は、スクロール位置または拡大率の影響を受けない。ワークフロー内で表されるすべてのアクティビティにより格納される座標は、論理座標の形式をとる。この方法で、アクティビティは、スクロール位置または拡大率の影響を受けない。

ワークフロービューは、論理座標とクライアント座標との間の座標の変換に使用される以下の関数の集合を持つ。点が変換される場合、本発明では、拡大率およびスクロール位置の両方を考慮するが、Ｓｉｚｅが変換される場合には、本発明では、Ｚｏｏｍ率のみを考慮する。

論理座標から物理座標への変換：
Point TransformToPhysicalCoOrd(Point point, bool mapToLayout)
Size TransformToPhysicalSize(Size size)
Rectangle TransformToPhysicalViewPort(Rectangle logicalViewPort)
物理座標から論理座標への変換：
Point TransformToLogicalCoOrd(Point point, bool mapToLayout)
Size TransformToLogicalSize(Size size)
Rectangle TransformToLogicalViewPort(Rectangle physicalViewPort
作成した後、ワークフロービューは、ＩＤｅｓｉｇｎｅｒＳｅｒｖｉｃｅと呼ばれるサービスをサービスコンテナに追加する。アクティビティデザイナおよび他のホストは、ＩＤｅｓｉｇｎｅｒＳｅｒｖｉｃｅに対しクエリを実行し、ワークフロービューおよび下のＷｉｎｄｏｗｓ（登録商標）コントロールと通信する。以下に、ＩＤｅｓｉｇｎｅｒＳｅｒｖｉｃｅの定義を示す。このインターフェイスでサポートしているプロパティ、メソッド、およびイベントは、２つの主要なカテゴリ、デザインサーフェスによりサポートされるＵＩ機能、つまりＺｏｏｍ、ＶｉｓｕａｌＤｅｐｔｈ、Ｐｒｉｎｔｉｎｇなどおよびワークフローを適切にレンダリングするために公開されるＷｉｎｆｏｒｍｓコントロール機能に分けられる。

ワークフロービューは、ワークフロー内のそれぞれのアクティビティデザイナの仮想ウィンドウコントロールのビヘイビアをシミュレートする。このビヘイビアは、アクティビティデザイナが実際のウィンドウコントロールでなくても、ワークフロービューはウィンドウメッセージをＷｉｎｄｏｗｓ（登録商標）コントロールと全く同じ方法で送ることを意味する。このために、すべてのマウスメッセージにおいて、ワークフロービューでは、ヒットテストを使用してマウスカーソルの下にあるデザイナを見つけ出してそれをバッファリングし、その後、エンター、ホバー、移動、および出るメッセージを適宜送る。デザイナがマウスカーソルの下にある状態および他の重要なマウス情報を保持するために、ワークフロービューではＭｏｕｓｅＥｖｅｎｔＤａｔａと呼ばれるデータ構造体を使用する。ＭｏｕｓｅＥｖｅｎｔＤａｔａ構造体は、メッセージをアクティビティデザイナに送る経路を適宜決めるために使用される。

ＤｅｓｉｇｎｅｒＤａｔａデータ構造体は、ワークフロービューにより、下にあるウィンドウコントロールに関係する情報をアクティビティインデザイナおよびレイアウトに伝達するために使用される。この情報は、文字列サイズを測定し、デザイナサイズを計算する際に非常に重要である。ＶｉｅｗｐｏｒｔＤａｔａデータ構造体は、ワークフロービューにより、ビューポートに関連付けられた情報をアクティブなレイアウトに伝達するために使用される。この情報は、拡大縮小、平行移動などを含む。ＨｉｔｔｅｓｔＤａｔａデータ構造体は、ワークフロービューにより、アクティビティデザイナからヒットテスト関係情報を取得するために使用される。ヒットテストデータは、マウスがアクティビティデザイナのどの部分にヒットしたかを示す。ＲｅｎｄｅｒｉｎｇＨｉｎｔデータ構造体は、デザイナにより、アクティビティデザイナをレンダリングするために使用される。レンダリングヒントには、色、フォント、アイコン、およびアクティビティデザイナを描画するために使用できるテキスト関係描画情報がある。

アルゴリズム例
描画アルゴリズムの例を以下に示す。
−メモリ内Ｂｉｔｍａｐを作成することによりメモリ装置コンテキスト上でワークフローをペイントする
−ビットマップ背景を塗りつぶす
−ルートアクティビティデザイナの描画を呼び出すことによりすべてのデザイナを描画する
−ルートアクティビティデザイナは、その中のすべてのデザイナ上で再帰的にＤｒａｗを呼び出す
−すべてのデザイナは、描画される前に可視領域ないにあるかどうかをチェックする
−装飾サービスの描画を呼び出すことにより装飾を描画する
−ユーザがビューポート上でマウスをドラッグした場合にドラッグ矩形を描画する
−Ｉｆ ユーザが視覚的深さを設定している場合
−視覚的深さオフセットでオリジナルの装置コンテキスト上にビットマップを描画する
−ビットマップを透明にする
−オフセットなしで上にビットマップを描画する
−Ｅｎｄｉｆ
−アクティブなレイアウト上で描画を呼び出す
−印刷プレビューについては、メインビットマップをつなぎ合わせて複数のページを描画する
−既定では、メインビットマップを直接描画する
−Ｉｆ ユーザがドラッグ＆ドロップモードに入っている場合
−ドラッグされるコンポーネントのスナップショットを描画する
−Ｅｎｄｉｆ
−Ｉｆ 拡大鏡が表示されている場合
−拡大鏡の枠を描画する
−拡大領域を拡大されたビットマップ上にマッピングする
−拡大されたビットマップを拡大領域内に描画する
−Ｅｎｄｉｆ
レイアウトのアルゴリズムの例を以下に示す。
−ルートデザイナ上でＯｎＬａｙｏｕｔＳｉｚｅを呼び出す
−ルートデザイナおよび他の複合デザイナは、子デザイナ上でＯｎＬａｙｏｕｔＳｉｚｅを呼び出す
−複合デザイナは、子レイアウトに基づいてそのサイズを計算する
−ルートデザイナ上でＯｎＬａｙｏｕｔＰｏｓｉｔｉｏｎを呼び出す
−ＲｏｏｔＤｅｓｉｇｎｅｒおよび他の複合デザイナは、子デザイナ上でＯｎＬａｙｏｕｔＰｏｓｉｔｉｏｎを呼び出す
−デザイナはその親の位置に基づいて位置を設定する
−アクティブなレイアウトのＵｐｄａｔｅを呼び出す
−レイアウトは、レイアウトをレンダリングするために必要に応じてその中のデータ構造体を更新する
−ルートデザイナの位置を更新し、レイアウトにより要求されたとおり適宜ルートデザイナの位置を揃える
−ルートデザイナを使用して範囲を計算するアクティブなレイアウトの範囲に基づいてスクロールバーのスクロール範囲を更新する
イベント送出のアルゴリズムの例を以下に示す。
−Ｆｏｒ すべてのマウスイベントについて
−どのイベントが発生したかについてデザイナをチェックする
−ＩＡｃｔｉｖｉｔｙＤｅｓｉｇｎｅｒインターフェイスを使用して出るイベントを前のほうのデザイナに送る
−ＩＡｃｔｉｖｉｔｙＤｅｓｉｇｎｅｒインターフェイスを使用してどのイベントが発生したかについてエンター／ホバーイベントを現在のデザイナに送る
−現在のデザイナをバッファリングして、次のイベントを待つ
−Ｅｎｄｆｏｒ
削除のアルゴリズムの例を以下に示す。
−ＩＳｅｌｅｃｔｉｏｎＳｅｒｖｉｃｅを使用して現在の選択されているデザイナを取得する
−デザイナに関連付けられているすべての最上位アクティビティを取得する。これは、ユーザが複数選択を実行し、また親および子デザイナを選択してｄｅｌｅｔｅを押す場合があるためである。
−Ｆｏｒ すべての最上位アクティビティについて
−それぞれの最上位アクティビティの親デザイナを取得する
−Ｉｆ 子アクティビティを持つ親デザイナ上のＣａｎＲｅｍｏｖｅＡｃｔｉｖｉｔｙがｔｒｕｅを返した場合
−子アクティビティを持つ親デザイナ上で、ＲｅｍｏｖｅＡｃｔｉｖｉｔｙを呼び出す
−Ｅｎｄｉｆ
−Ｅｎｄｆｏｒ
−最後に削除されたアクティビティの親を取得し、それを選択する
ワークフローデザイナのキーボードおよびコマンドの経路選択
デザイナは、サービスＩＭｅｎｕＣｏｍｍａｎｄＳｅｒｖｉｃｅをコマンド経路選択に使用する。このサービスを実装するのはホストの役目である。型ＣｏｍｍａｎｄＳｅｔは、サポートされているコマンドの無構造のリストを含む（ＣｏｍｍａｎｄＳｅｔＩｔｅｍ−Ｓｙｓｔｅｍ．ＣｏｍｐｏｎｅｎｔＭｏｄｅｌ．Ｄｅｓｉｇｎ．ＭｅｎｕＣｏｍｍａｎｄから派生する）。それぞれのコマンドは、ＣｏｍｍａｎｄｌＤ（グループＩＤおよびアイテムＩＤからなる）、コマンドを実行するためのハンドラ、およびそのステータスについてクエリを実行するハンドラ（有効、可視など）を含み、それらのコマンドは、作成後、ＩＭｅｎｕＣｏｍｍａｎｄＳｅｒｖｉｃｅ．ＡｄｄＣｏｍｍａｎｄ（）を使用してサービス内に投入される。ＵＩキュー（キーボード、マウスオペレーション、メニューコマンド）は、ホスティングアプリケーション（ＶＳ、Ｚａｍｍ）により、または場合によってはワークフロービューにより、ＣｏｍｍａｎｄＩＤに解釈される。例えば、最上位メニューアイテムが選択された場合に適切なコマンドを呼び出すのはホストの役目である。しかし、ワークフロービューがフォーカスが置かれている間マウスオペレーションおよびキーボードを処理する。さらに、個々のデザイナに関連付けられた特別なコマンドであるＤｅｓｉｇｎｅｒＶｅｒｂｓが、アクティビティデザイナ内で宣言され、ＩＭｅｎｕＣｏｍｍａｎｄＳｅｒｖｉｃｅにより自動的に収集される。

コマンドステータスは、選択が変更されると必ず評価される（ＩＳｅｌｅｃｔｉｏｎＳｅｒｖｉｃｅを通じて追跡される）。常時現在のステータスを取得するために、ＣｏｍｍａｎｄＳｅｔＩｔｅｍの代わりにＩｍｍｉｄｉａｔｅＣｏｍｍａｎｄＳｅｔＩｔｅｍ （ＣｏｍｍａｎｄＳｅｔＩｔｅｍから派生）を使用する。

印刷
クラスＷｏｒｋｆｌｏｗＰｒｉｎｔＤｏｃｕｍｅｎｔおよびＩＤｅｓｉｇｎｅｒＳｅｒｖｉｃｅインターフェイス上のパブリックプロパティＰｒｉｎｔＤｏｃｕｍｅｎｔは印刷をサポートしている。ＷｏｒｋｆｌｏｗＰｒｉｎｔＤｏｃｕｍｅｎｔ自体は、実際の描画を実行するためそれを作成したＷｏｒｋｆｌｏｗＶｉｅｗへの参照を保持する。プリンタの解像度は画面解像度と異なるので、実際の印刷を開始する前に、印刷文書ではプリンタのグラフィックを使用してワークフローを再レイアウトし、すべてのページを印刷し、その後、ＷｏｒｋｆｌｏｗＶｉｅｗに、画面グラフィックを再び使用してレイアウトを実行するよう要求する。

アクティビティデザイナインターフェイス
ＩＡｃｔｉｖｉｔｙＤｅｓｉｇｎｅｒインターフェイスは、ワークフローに参加する必要があるすべてのアクティビティデザイナにより実装される。これは、デザイナが他のデザイナおよびワークフロービューと対話するためのプロトコルである。ワークフロービューは、ＩＡｃｔｉｖｉｔｙＤｅｓｉｇｎｅｒインターフェイスを探し、イベントのレンダリング、レイアウト、またはデザイナへの転送を行う。ＩＡｃｔｉｖｉｔｙＤｅｓｉｇｎｅｒインターフェイスをサポートすることで、すべてのデザイナは、デザイナが実際にはウィンドウコントロールから派生しないとしてもウィンドウコントロールのように動作することができる。このインターフェイスを使用すると、さらに、ワークフロービューおよび装飾サービス、メニューコマンドサービスのような他のデザイナインフラストラクチャも、デザイナと情報をやり取りすることができる。ＩＡｃｔｉｖｉｔｙＤｅｓｉｇｎｅｒインターフェイスから派生されたデザイナは、階層を持ち得ないが、階層を持つためには、デザイナは、ＩＣｏｍｐｏｓｉｔｅＡｃｔｉｖｉｔｙＤｅｓｉｇｎｅｒインターフェイスを実装する必要がある。以下に、ＩＡｃｔｉｖｉｔｙＤｅｓｉｇｎｅｒの定義を、プロパティおよびメソッドに関する詳細とともに示す。

ＩＣｏｍｐｏｓｉｔｅＡｃｔｉｖｉｔｙＤｅｓｉｇｎｅｒ：
ＩＣｏｍｐｏｓｉｔｅＡｃｔｉｖｉｔｙＤｅｓｉｇｎｅｒは、階層を持ちうる、つまり子を持ちうるデザイナによって実装される。複合デザイナは、それ自身とその子すべてを保持する必要がある。ＩＣｏｍｐｏｓｉｔｅＡｃｔｉｖｉｔｙＤｅｓｉｇｎｅｒインターフェイスを使用することで、複合デザイナは、その子に関する情報を公表し、子デザイナの追加および削除を行う機能を提供し、キーボードナビゲーションを有効にする。以下に、ＩＣｏｍｐｏｓｉｔｅＡｃｔｉｖｉｔｙＤｅｓｉｇｎｅｒの定義を、プロパティおよびメソッドに関する詳細とともに示す。

単純デザイナ
ＡｃｔｉｖｉｔｙＤｅｓｉｇｎｅｒクラスは、デザイナの最も単純な実装を表す。ワークフロー内のアクティビティに関連付けられたすべてのデザイナは、ＡｃｔｉｖｉｔｙＤｅｓｉｇｎｅｒから派生する。ＡｃｔｉｖｉｔｙＤｅｓｉｇｎｅｒクラスは、ＩＡｃｔｉｖｉｔｙＤｅｓｉｇｎｅｒインターフェイスから継承し、そのインターフェイスの既定の実装を提供する。ワークフロービューは、ＩＡｃｔｉｖｉｔｙＤｅｓｉｇｎｅｒインターフェイスを使用してデザイナと対話する。ＡｃｔｉｖｉｔｙＤｅｓｉｇｎｅｒクラスは、通常、デザイナの描画のため超軽量実装を必要とするデザイナによって継承される。これらのデザイナには、子または階層がない。アクティビティデザイナが備える機能としては、基本レイアウトロジック、レンダリングサポート（例えば、アイコン、説明、枠線、内部、および背景を描画することによる）、ヘルプテキストのレンダリング、すべてのデザイナにより必要とされる既定のグリフを返すこと、ＤｅｓｉｇｎｅｒＶｅｒｂｓを介したコンテキストメニューの表示、設計時特有のプロパティのフィルタ処理、既定のイベント発生、既定のヒットテスト、バリデーションのトリガ、ツールチップの表示、およびキーボードナビゲーションへの参加がある。
public abstract class ActivityDesigner:ComponentDesigner, IActivityDesigner

複合デザイナ
ＣｏｍｐｏｓｉｔｅＡｃｔｉｖｉｔｙＤｅｓｉｇｎｅｒは、階層を持つデザイナである（例えば、下に子がいる）。ＣｏｍｐｏｓｉｔｅＡｃｔｉｖｉｔｙＤｅｓｉｇｎｅｒは、それ自体のすべての態様だけでなくその子をも管理する役割を持つ。これは、さらに、イベントを転送するためにその子と情報のやり取りをする必要もある。ＣｏｍｐｏｓｉｔｅＡｃｔｉｖｉｔｙＤｅｓｉｇｎｅｒに含まれるアクティビティデザイナコレクションを修正する要求がある場合には必ず、アクティビティが削除される必要のある場所を指定するコンテキスト（ＣｏｎｔｅｘｔＢａｓｅ）を渡される。ＣｏｎｔｅｘｔＢａｓｅは各ＣｏｍｐｏｓｉｔｅＡｃｔｉｖｉｔｙＤｅｓｉｇｎｅｒ派生クラスにより特殊化され、これにより、それらに特有のコンテキストを指定するようにできる。これの例として、ＳｅｑｕｅｎｔｉａｌＡｃｔｉｖｉｔｙＤｅｓｉｇｎｅｒがあるが、これは、ＣｏｎｎｅｃｔｏｒＣｏｎｔｅｘｔと呼ばれるクラスをＣｏｎｔｅｘｔＢａｓｅから派生させてＣｏｎｔｅｘｔＢａｓｅを特殊化する。ＣｏｍｐｏｓｉｔｅＡｃｔｉｖｉｔｙＤｅｓｉｇｎｅｒクラスは、ＩＣｏｍｐｏｓｉｔｅＡｃｔｉｖｉｔｙＤｅｓｉｇｎｅｒインターフェイスから派生し、それに対する既定の実装を提供する。ＣｏｍｐｏｓｉｔｅＡｃｔｉｖｉｔｙＤｅｓｉｇｎｅｒが備える機能は、デザイナの展開／縮小、ドラッグ＆ドロップインジケータ、自己および子のレイアウト、自己および子の描画、子のヒットテスト、および階層からのアクティビティの挿入／削除を含む。
public abstract class CompositeActivityDesigner:ActivityDesigner, ICompositeActivityDesigner

ＣｏｍｐｏｓｉｔｅＡｃｔｉｖｉｔｙＤｅｓｉｇｎｅｒは、抽象クラスであり、勝手に存在することはできないのでインスタンス化できない。Ｓｅｑｕｅｎｔｉａｌ、Ｐａｒａｌｌｅｌ、およびＣＡデザイナは、このクラスのすべての特殊化である。
ＳｅｑｕｅｎｔｉａｌＡｃｔｉｖｉｔｙＤｅｓｉｇｎｅｒ
ＳｅｑｕｅｎｔｉａｌＡｃｔｉｖｉｔｙＤｅｓｉｇｎｅｒクラスは、下に子を持つすべてのデザイナを表し、すべての子は連続して順序付けられる。子は、子の順序を修正するためにも使用されるコネクタと呼ばれるリンクにより接続される。ＳｅｑｕｅｎｔｉａｌＡｃｔｉｖｉｔｙＤｅｓｉｇｎｅｒクラスは、ＣｏｍｐｏｓｉｔｅＡｃｔｉｖｉｔｙＤｅｓｉｇｎｅｒの特殊化であり、コネクタ起動およびエンドビットマップ描画、すべての子の順次レイアウトおよびそれらをリンクしているすべてのコネクタの更新、子同士をつなぐコネクタの描画、ドラッグ＆ドロップが実行されたときのドロップ領域のハイライト表示、コネクタのヒットテスト、上向きおよび下向き矢印を使用する順次キーボードナビゲーション、およびコネクタのグリフを返す操作といった機能を備える。

internal abstract class SequentialActivityDesigner: CompositeActivityDesigner

上記のデザイナはすべて、ＳｅｑｕｅｎｔｉａｌＡｃｔｉｖｉｔｙＤｅｓｉｇｎｅｒの特殊化であり、すべて主に描画が異なる。これらのデザイナはすべて、ワークフロー内でそれ自体を表す特別な手段を持つが、すべて、ＳｅｑｕｅｎｔｉａｌＡｃｔｉｖｉｔｙＤｅｓｉｇｎｅｒによって提供される共通機能を取り除いている。

ＰａｒａｌｌｅｌＡｃｔｉｖｉｔｙＤｅｓｉｇｎｅｒ
ＰａｒａｌｌｅｌＡｃｔｉｖｉｔｙＤｅｓｉｇｎｅｒは、ＣｏｍｐｏｓｉｔｅＡｃｔｉｖｉｔｙＤｅｓｉｇｎｅｒのもう１つの特殊化であり、複数のＳｅｑｕｅｎｔｉａｌＡｃｔｉｖｉｔｙＤｅｓｉｇｎｅｒｓを含む。これらのＳｅｑｕｅｎｔｉａｌＡｃｔｉｖｉｔｙＤｅｓｉｇｎｅｒｓはそれぞれ、並列デザイナにおける分岐である。並列デザイナは、複数の順次デザイナのレイアウト、さらに分岐を追加するためのドラッグ＆ドロップインジケータ、左および右矢印キーを使用することにより並列分岐間を横断するためのキーボードナビゲーション、および複数の並列分岐をリンクするための描画コネクタといった特殊化された機能を備える。
internal abstract class ParallelActivityDesigner: CompositeActivityDesigner

Ｃｏｎｄｉｔｉｏｎａｌ、Ｌｉｓｔｅｎ、およびＰａｒａｌｌｅｌデザイナは、追加描画ロジックがそれらに関連付けられているＰａｒａｌｌｅｌＡｃｔｉｖｉｔｙＤｅｓｉｇｎｅｒの特殊化である。

ＡｃｔｉｖｉｔｙＰｒｅｖｉｅｗＤｅｓｉｇｎｅｒ
ＡｃｔｉｖｉｔｙＰｒｅｖｉｅｗＤｅｓｓｉｇｎｅｒは、順次デザイナであるが、コレクションバッグの形で複数のデザイナのコレクションを表示することができる。ＡｃｔｉｖｉｔｙＰｒｅｖｉｅｗＤｅｓｉｇｎｅｒは、フィルムストリップのメタファーを使用してこのコレクションを表示する。特定のデザイナが選択された場合、その表現は、アクティビティプレビューデザイナがホスティングするプレビューウィンドウ内に表示される。ＡｃｔｉｖｉｔｙＰｒｅｖｉｅｗＤｅｓｉｇｎｅｒは、編集モードとプレビューモードの２つのモードを持つ。プレビューモードでは、ユーザは選択されているデザイナを修正することはできない。このモードでは、ユーザは、スクロールしなくても、デザイナの表現全体を見ることができる。編集モードでは、デザイナを修正することができる。ＡｃｔｉｖｉｔｙＰｒｅｖｉｅｗＤｅｓｉｇｎｅｒが備える機能は、アクティビティのコレクションを表示するためのプレビューストリップ、現在選択されているアクティビティのプレビュー、および選択されたデザイナの編集機能を含む。
internal abstract class ActivityPreviewDesigner: SequentialActivityDesigner

Ｓｃｏｐｅ ＆ Ｓｅｒｖｉｃｅデザイナ
ＳｃｏｐｅデザイナおよびＳｅｒｖｉｃｅデザイナは、特別なデザイナである。これらはそれぞれ、例外、イベント、およびそれらに関連付けられた補正を持つことができる。ＳｃｏｐｅおよびＳｃｈｅｄｕｌｅは、さらに、ユーザコードファイル内でそれらに関連付けられたクラスも持ち、ユーザはそれらのクラス内のスコーピングを行うことができる。ＳｃｏｐｅデザイナおよびＳｅｒｖｉｃｅデザイナは、他のデザイナと異なる形で例示されており、ウォーターマークを表示し、またドロップシャドウを描画することによりハイライト表示する。

ＳｃｏｐｅデザイナおよびＳｅｒｖｉｃｅデザイナは、ユーザがビューを次々にめくってゆき例外、イベント、およびそれらに関連付けられている補正をさらけ出せるようにビューを変更することができる。ユーザがＳｅｒｖｉｃｅまたはＳｃｏｐｅアイコン上でホバリングした場合、ドロップダウンパレットが現れ、そこでユーザは例外、イベント、または補正ビューの１つを選ぶことができる。次に、デザイナビューがめくられ、その選択されたビューに含まれるアクティビティが表示される。ユーザは、任意の時点にビューのどれか１つに属するアクティビティのみを表示できる。ビューをめくる動作は、ＳｃｏｐｅまたはＳｃｈｅｄｕｌｅに含まれる子アクティビティをフィルタ処理することにより実行される。ＳｃｏｐｅおよびＳｃｈｅｄｕｌｅは、ＥｘｃｅｐｔｉｏｎＨａｎｄｌｅｒｓ、ＥｖｅｎｔＨａｎｄｌｅｒｓ、およびＣｏｍｐｅｎｓａｔｉｏｎのうちの高々１つをその子として持つ。デザイナは、ユーザが見ているビューに基づいて、それらの子を除去し、選択されたビュー内に表示できる子アクティビティのみを表示するという形で、複数のビューをサポートする効果を実現している。Ｓｃｈｅｄｕｌｅデザイナは、通常、ワークフロービュー内のルートデザイナとして設定される。
internal class ScopeDesigner: SequentialActivityDesigner
internal class ServiceDesigner: ScopeDesigner

ＳｅｒｖｉｃｅＲｏｏｔＤｅｓｉｇｎｅｒ
ＳｅｒｖｉｃｅＲｏｏｔＤｅｓｉｇｎｅｒは、Ｄｅｓｉｇｎｅｒ Ｈｏｓｔに含まれるＲｏｏｔコンポーネントに関連付けられる。これは、デザイナウィンドウペイン内でその後ホスティングされるワークフロービューを作成する必要がある。ＳｅｒｖｉｃｅＲｏｏｔＤｅｓｉｇｎｅｒは、さらに、ツールボックスアイテムをダブルクリックすることによりワークフロー内にツールボックスアイテムを追加する機能を備えるＩＴｏｏｌＢｏｘＵｓｅｒインターフェイスもサポートする。

設計時ディスクリプタ
オーサリングオブジェクトモデルのそれぞれのアクティビティは、設計時にそのビヘイビアを記述するメタデータを持つ。これは、アクティビティ（デザイナ）だけでなくプロパティグリッドのビヘイビア（命名、説明、フィルタ処理、プロパティエディタなど）を関連付ける操作を含む。Ｔｙｐｅｓ＼Ｐｒｏｐｅｒｔｙ＼Ｅｖｅｎｔ設計時ビヘイビアは、以下の属性のうちの０個以上を使用して記述される。
−ＳＲＣａｔｅｇｏｒｙＡｔｔｒｉｂｕｔｅ−オーケストレーションエンジン属性。ローカライズされたカテゴリ名を与える。
−ＳＲＤｅｓｃｒｉｐｔｉｏｎＡｔｔｒｉｂｕｔｅ−オーケストレーションエンジン属性。ローカライズされた説明を与える。
−ＥｄｉｔｏｒＡｔｔｒｉｂｕｔｅ−ＵＩＴｙｐｅＥｄｉｔｏｒを提供する。
−ＴｙｐｅＣｏｎｖｅｒｔｅｒ−フィルタ処理、値リスト、および型の変換の機能を備える。
−ＢｒｏｗｓａｂｌｅＡｔｔｒｉｂｕｔｅ−設計時にメンバを表示＼非表示にする。

ＳＲＣａｔｅｇｏｒｙおよびＳＲＤｅｓｃｒｉｐｔｉｏｎは、資源名と文字列との間の単なるマッピングである。ほとんどのエディタ（ＵＩＴｙｐｅＥｄｉｔｏｒ）は、ダイアログ（ＣｏｒｒｅｌａｔｉｏｎＳｅｔｓＤｉａｌｏｇのような）またはドロップダウンリストを処理するためのマネージャである。ＰｒｏｐｅｒｔｙＤｅｓｃｒｉｐｔｏｒは、設計時のプロパティを処理し、既定のＴｙｐｅＣｏｎｖｅｒｔｅｒ、カスタムＴｙｐｅＣｏｎｖｅｒｔｅｒ（上記のように属性として宣言されている）、またはＴｙｐｅＤｅｓｃｒｉｐｔｏｒのいずれかによりプロパティを渡される。

ＵＩ Ｔｙｐｅ Ｅｄｉｔｏｒｓは、オーケストレーションエンジンＣｏｍｐｏｎｅｎｔモデルにおけるさまざまなプロパティのためのエディタとなる。プロパティブラウザでは、それらを使用して、省略またはドロップダウンを表示し、エディタを起動する。

型コンバータ
型コンバータは、他の型へ／他の型からオブジェクトを変換するメソッドを備え、設計時にオブジェクトプロパティを表すＰｒｏｐｅｒｔｙＤｅｓｃｒｉｐｔｏｒリストを提供し、プロパティグリッドのプロパティのドロップダウン内で使用される値を与えることが可能である。

以下に、オーケストレーションエンジンＣｏｍｐｏｎｅｎｔモデルで実装されるＴｙｐｅＣｏｎｖｅｒｔｅｒｓのいくつかを示す。
−ＤｅｃｌＴｙｐｅＣｏｎｖｅｒｔｅｒ
すべてのアクティビティの型コンバータへの基本クラス。アクティビティオブジェクトを文字列に／文字列から変換するためＣａｎＣｏｎｖｅｒｔＦｒｏｍ（）、ＣａｎＣｏｎｖｅｒｔＴｏ（）、ＣｏｎｖｅｒｔＦｒｏｍ（）、ＣｏｎｖｅｒｔＴｏ（）を実装する（プロパティグリッド内のアクティビティの名前を表示する、名前編集でアクティビティを作成できるようにする）。また、ＧｅｔＳｉｔｅ（）でもサービスへのアクセスを提供する。
−ＨａｎｄｌｅｒＤｅｃｌＴｙｐｅＣｏｎｖｅｒｔｅｒ
イベントに対する型コンバータ。ＤｅｃｌＴｙｐｅＣｏｎｖｅｒｔｅｒから派生する。ＩＥｖｅｎｔＢｉｎｄｉｎｇＳｅｒｖｉｃｅを使用して互換性のあるハンドラを表示するＧｅｔＳｔａｎｄａｒｄＶａｌｕｅｓ（）を実装する。
−ＶａｒｉａｂｌｅＤｅｃｌＴｙｐｅＣｏｎｖｅｒｔｅｒ
変数（メッセージ、チャネル、相関関係など）用の型コンバータ。ＤｅｃｌＴｙｐｅＣｏｎｖｅｒｔｅｒから派生する。ＩＦｉｅｌｄＢｉｎｄｉｎｇＳｅｒｖｉｃｅを使用して互換性のある変数フィールを表示するＧｅｔＳｔａｎｄａｒｄＶａｌｕｅｓ（）を実装する。さらに、型コンバータは、「Ｎａｍｅ」プロパティを除去し、ジェネリック型として現れる型プロパティの特別なｐｒｏｐｅｒｔｙＤｅｓｃｒｉｐｔｏｒを設定する。

プロパティディスクリプタ
プロパティディスクリプタは、設計時サービスをアクティビティオブジェクトに提供する。これは、名前、説明、カテゴリ、型コンバータ情報だけでなく、プロパティ値を取得／設定する場合の追加機能も備える。既定では、ＴｙｐｅＣｏｎｖｅｒｔｅｒは、ＰｒｏｐｅｒｔｙＤｅｓｃｒｉｐｔｏｒｓをすべてのプロパティに用意する。しかし、ＴｙｐｅＣｏｎｖｅｒｔｅｒは、その型の異なる設計時ビヘイビアを与えるためにそれらを削除、追加、またはラップすることができる。

以下に、オーサリングオブジェクトモデルで実装されるＰｒｏｐｅｒｔｙＤｅｓｃｒｉｐｔｏｒｓの一部を示す。
−ＤｙｎａｍｉｃＰｒｏｐｅｒｔｙＤｅｓｃｒｉｐｔｏｒ
オーサリングオブジェクトモデル内のすべてのプロパティディスクリプタへの基本クラス。既定のプロパティディスクリプタを囲むラッパを実装し、それらのメソッドすべてをそのラッパにデリゲートする。さらに、オブジェクトから直接的に（コンポーネントである場合）、またはｌＲｅｆｅｒｅｎｃｅＳｅｒｖｉｃｅを介して、オブジェクトサイトにアクセスできるようにする。
−ＶａｒｉａｂｌｅＤｅｃｌＰｒｏｐｅｒｔｙＤｅｓｃｒｉｐｔｏｒ
すべての変数（メッセージ、チャネル、相関関係など）用のプロパティディスクリプタ。以下のようにコードビサイドフィールドを用意するためＳｅｔＶａｌｕｅ（）をオーバーロードする。
−設定する変数とそのサイトを取得する。
−含むスコープのサイトを取得する。
−含むスコープのＩＦｉｅｌｄＢｉｎｄｉｎｇＳｅｒｖｉｃｅを取得する。それぞれのスコープは、フィールドの独自の集合が含まれるそれ独自のＩＦｉｅｌｄＢｉｎｄｉｎｇＳｅｒｖｉｃｅを持つ。
−サービスによりフィールド名の妥当性を確認する。
−デザイナトランザクションを開く。
−値を保存する。
−ＩＦｉｅｌｄＢｉｎｄｉｎｇＳｅｒｖｉｃｅ．ＣｒｅａｔｅＦｉｅｌｄ（）を呼び出して、フィールドをコードビサイドファイルに追加する。
−トランザクションをコミットする。
−ＨａｎｄｌｅｒＤｅｃｌＰｒｏｐｅｒｔｙＤｅｓｃｒｉｐｔｏｒ
すべてのハンドラ用のプロパティディスクリプタ。以下のようにコードビサイドフィールドを用意するためＳｅｔＶａｌｕｅ（）をオーバーロードする。
−設定するＨａｎｄｌｅｒＤｅｃｌａｒａｔｉｏｎとそのサイトを取得する。
−ＩＥｖｅｎｔＢｉｎｄｉｎｇＳｅｒｖｉｃｅを取得する。
−デザイナトランザクションを開く。
−ＬｏｃａｌＥｖｅｎｔＤｅｓｃｒｉｐｔｏｒを作成する。
−イベントのＰｒｏｐｅｒｔｙＤｅｓｃｒｉｐｔｏｒを取得し（ｅｖｅｎｔＢｉｎｄｉｎｇＳｅｒｖｉｃｅ．ＧｅｔＥｖｅｎｔｐｒｏｐｅｒｔｙ（）を使用して）、それにＨａｎｄｌｅｒＤｅｃｌａｒａｔｉｏｎを設定する。
−ＨａｎｄｌｅｒＤｅｃｌａｒａｔｉｏｎオブジェクトの「Ｎａｍｅ」プロパティを設定する。
−トランザクションをコミットする。
−ＡｒｒａｙＥｌｅｍｅｎｔＰｒｏｐｅｒｔｙＤｅｓｃｒｉｐｔｏｒ
コレクション内のアイテムを表すプロパティディスクリプタ。コレクションアイテム−例えば、Ｃｏｒｒｅｌａｔｉｏｎ Ｓｅｔｓ−はプロパティディスクリプタを持たないため（それらのプロパティではない）、ＡｒｒａｙＥｌｅｍｅｎｔＰｒｏｐｅｒｔｙＤｃｓｃｒｉｐｔｏｒでは、それらがプロパティであるかのようにディスクリプタをフェイクし、それにより、プロパティブラウザの内側にそれらを表示するようにできる。このプロパティディスクリプタは、上述のプロパティディスクリプタのどれかによりラップされるように設計された。
−ＬｏｃａｌＥｖｅｎｔＤｅｓｃｒｉｐｔｏｒ
ハンドラ宣言を表すＥｖｅｎｔＤｅｓｃｒｉｐｔｏｒ。オーサリングオブジェクトモデル内のハンドラは、実際のイベントではなく、プロパティであるので、使用されるＩＥｖｅｎｔＢｉｎｄｉｎｇＳｅｒｖｉｃｅに独自のＥｖｅｎｔＤｅｓｃｒｉｐｔｏｒｓを導入する。

ＩＣｕｓｔｏｍＴｙｐｅＤｅｓｃｒｉｐｔｏｒの使用
ＩＣｕｓｔｏｍＴｙｐｅＤｅｓｃｒｉｐｔｏｒは、コンポーネントに対しディスクリプタを設定するための代替え手段である。コンポーネント自体はインターフェイスを実装し、ディスクリプタを、型コンバータ、既定値などとして提供する。ＧｅｎｅｒｉｃＡｃｔｉｖｉｔｙ、ＩｎｖｏｋｅＷｅｂＳｅｒｖｉｃｅＡｃｔｉｖｉｔｙ、およびＩｎｖｏｋｅＳｃｈｅｄｕｌｅはこのインターフェイスを実装する。

ＩＥｘｔｅｎｄｅｒＰｒｏｖｉｄｅｒの使用
これは、設計時プロパティをコンポーネントに導入するためのさらに他の手法である。拡張クラスＲｕｌｅＰｒｏｐｅｒｔｙＰｒｏｖｉｄｅｒＥｘｔｅｎｄｅｒは、ルールプロパティをＳｅｒｖｉｃｅＤｅｓｉｇｎｅｒに提供する。プロパティは、ＰｒｏｖｉｄｅＰｒｏｐｅｒｔｙＡｔｔｒｉｂｕｔｅを介してエクステンダクラスを修飾し、その属性のゲッターおよびセッターを実装し、エクステンダクラスをコンポーネントのサイト（Ｓｃｈｅｄｕｌｅ．Ｓｉｔｅ）を通じてアクセス可能なＩＥｘｔｅｎｄｅｒＰｒｏｖｉｄｅｒＳｅｒｖｉｃｅクラス（この場合は、ＲｕｌｅＰｒｏｐｅｒｔｙＰｒｏｖｉｄｅｒＥｘｔｅｎｄｅｒにより実装される）に追加することにより追加される。

拡張性のサポート
Ｓｙｓｔｅｍ．Ｗｏｒｋｆｌｏｗ．ＣｏｍｐｏｎｅｎｔＭｏｄｅｌ．Ｄｅｓｉｇｎ名前空間は、さまざまな再利用可能なクラスを用意しており、ユーザはそれを使って、独自のアクティビティデザイナを作成し、それらをオーケストレーションエンジンデザイナにプラグインとして追加する。以下に、ユーザが使用できるクラスの一覧を示す。
−ＡｃｔｉｖｉｔｙＤｅｓｉｇｎｅｒ：ＡｃｔｉｖｉｔｙＤｅｓｉｇｎｅｒを使用すると、ユーザは、下に他のアクティビティの階層を持たない単純なアクティビティを追加できる。ユーザは、このデザイナから継承する必要があり、またビットマップ、説明、および描画をカスタマイズできる。
−ＳｅｑｕｅｎｔｉａｌＡｃｔｉｖｉｔｙＤｅｓｉｇｎｅｒ：ＳｅｑｕｅｎｔｉａｌＡｃｔｉｖｉｔｙＤｅｓｉｇｎｅｒを使用すると、ユーザは、複数のアクティビティを含むことができるデザイナを書くことができる。これらのアクティビティはすべて、順次配列され、コネクタ線を使ってリンクされる。ユーザは、このクラスから派生させることができ、カスタム配色、説明、アイコンなどを用意できる。
−ＰａｒａｌｌｅｌＡｃｔｉｖｉｔｙＤｅｓｉｇｎｅｒ：ＰａｒａｌｌｅｌＡｃｔｉｖｉｔｙＤｅｓｉｇｎｅｒを使用すると、ユーザは、並列様式で配列された、複数の複合アクティビティを持つことができるアクティビティデザイナを書くことができる。また、このクラスを使用することで、ユーザは、説明、アイコン、色などをカスタマイズできる。このクラスは、継承を通じて拡張できる。
−ＯｒｃｈｅｓｔｒａｔｉｏｎＥｎｇｉｎｅＴｏｏｌｂｏｘＩｔｅｍ：ＯｒｃｈｅｓｔｒａｔｉｏｎＥｎｇｉｎｅＴｏｏｌｂｏｘＩｔｅｍを使用すると、ユーザは、カスタムツールボックスアイテムを作成することができる。このクラスでは、ユーザは、シリアライゼーションを制御できる。このクラスでは、アクティビティがデザイナの中に追加される場合にユーザがカスタムＵＩをポップアップするために使用するフックを用意している。ユーザは、継承を通じてこのクラスを再利用できる。ユーザは、ＴｏｏｌＢｏｘＩｔｅｍ属性を使用してツールボックスアイテムを用意する必要がある。

−ＴｙｐｅＢｒｏｗｓｅｒＥｄｉｔｏｒ：ＴｙｐｅＢｒｏｗｓｅｒＥｄｉｔｏｒを使用すると、ユーザは、デザイナに用意されている型をブラウズすることができる。このクラスは、Ｓｙｓｔｅｍ.Ｔｙｐｅ型のプロパティに関連付けることで使用される。ユーザは、ＵＩＴｙｐｅＥｄｉｔｏｒ属性を使用して、このクラスをプロパティに関連付ける。

−ＴｙｐｅＣｏｎｖｅｒｔｅｒクラス：オーケストレーションエンジンコンポーネントモデルは、独自の型コンバータをユーザ側で定義できるさまざまな型コンバータを備えている。型コンバータはすべて、継承を通じて拡張することにより使用することができる。

−ＤｅｓｉｇｎｅｒＧｌｙｐｈ：ＤｅｓｉｇｎｅｒＧｌｙｐｈクラスは、ユーザがデザイナの上にカスタムグリフを描画する場合に使用できる。一番上のＺ順で描画する必要がある視覚的グリフをいくつか表示したい場合がある。ＤｅｓｉｇｎｅｒＧｌｙｐｈクラスは、このようなグリフを描画するために使用することができる。このクラスは、継承を通じて拡張することにより使用できる。
−ＤｅｓｉｇｎｅｒＡｃｔｉｏｎ：ユーザは、ＤｅｓｉｇｎｅｒＡｃｔｉｏｎｓをＤｅｓｉｇｎｅｒＧｌｙｐｈｓに関連付けることができる。ユーザがＤｅｓｉｇｎｅｒＧｌｙｐｈｓをクリックすると、アクションが表示される。カスタムデザイナアクションは、ＤｅｓｉｇｎｅｒＡｃｔｉｏｎから継承することにより作成できる。

タスクおよび制御フロー複合アクティビティを含むワークフローの実施例を示す図である。 アクティビティ継承ツリーの実施例を示す図である。 コンポーネントモデルの実施例を示す図である。 ワークフローを作成するためにユーザと本発明との間で行われるやり取りを示すブロック図である。 インクワークフロー（inked workflow）の実施例を示す図である。 図５のインクワークフローから変換されたワークフローを示す図である。 ワークフローを作成するためにユーザと本発明との間で行われるやり取りを示す流れ図である。 タッチスクリーン実施形態におけるインクワークフローの認識を示す流れ図である。 ワークフローの指定にウィザードに依存する、ワークフローオーサリングするための高水準アプリケーションユーザインターフェイスを示す図である。 ワークフローデザイナの実施例を示す図である。 送信アクティビティが後に続く受信アクティビティを含むオーケストレーションプログラムを示す図である。 本発明を実装することができる１つの好適なコンピューティングシステム環境の一実施例を示すブロック図である。

符号の説明

４０２ ユーザ
４０４ ディスプレイまたは表示装置または表示領域
４３６ タッチスクリーン
４０６ ユーザインターフェイス選択装置
４０８ プロセッサ
４１０ コンピュータ可読媒体
４１２ レンダリングコンポーネント
４１４ インターフェイスコンポーネント
４１６ デザイナコンポーネント
４１８ バリデーションコンポーネント
４２０ レコグナイザコンポーネント
４２２ パレットコンポーネント
４２４ スキンコンポーネント
４２６ ワークフローコンポーネント
４２８ メモリ領域
４３０ アクティビティ
４３２ グラフィック要素
４３４ パレット要素
１３２ 演算処理装置
１３４ システムメモリ
１３６ システムバス
１４４ オペレーティングシステム
１４６ アプリケーションプログラム
１４８ その他のプログラムモジュール
１５０ プログラムデータ
１６６ 不揮発性メモリインターフェイス
１７０ オペレーティングシステム
１７２ アプリケーションプログラム
１７４ その他のプログラムモジュール
１７６ プログラムデータ
１８４ ユーザ入力インターフェイス
１８６ ネットワークインターフェイス
１９０ ビデオインターフェイス
１９２ リモートアプリケーションプログラム
１９６ ローカルエリアネットワーク
１９８ ワイドエリアネットワーク

Claims (20)

1. アクティビティ（４３０）を含みビジネスプロセスをモデル化するワークフローをモデル化するためのシステムであって、
   複数のアクティビティ（４３０）を格納するためのメモリ領域（４２８）と、
   前記メモリ領域（４２８）に格納されている前記複数のアクティビティ（４３０）を表示するための表示領域（４０４）と、
   プロセッサ（４０８）であって、
   ユーザ（４０２）から前記アクティビティ（４３０）の選択を受け取るコンピュータ実行可能命令と、
   前記表示領域（４０４）内にアクティビティ（４３０）の前記受け取った選択を表示するコンピュータ実行可能命令と、
   前記ユーザ（４０２）から構造情報を受け取るコンピュータ実行可能命令と、
   ワークフローを作成するために前記受け取った構造情報に従って前記表示領域（４０４）内にアクティビティ（４３０）の前記表示される選択を配列するコンピュータ実行可能命令とを実行するように構成されたプロセッサ（４０８）を備えることを特徴とするシステム。
2. さらに、ポインティング装置を備え、前記メモリ領域（４２８）は、前記ワークフローを作成するために配列されている複数のグラフィック要素（４３２）を格納し、前記複数のグラフィック要素（４３２）は前記表示領域（４０４）およびポインティング装置を介して前記ユーザ（４０２）から受け取られ、前記メモリ領域（４２８）はさらにそれぞれ前記複数のアクティビティ（４３０）のうちの少なくとも１つに対応する複数のパレット要素（４３４）を格納することを特徴とする請求項１に記載のシステム。
3. 前記プロセッサ（４０８）は、さらに、
   前記メモリ領域（４２８）内に格納されている前記グラフィック要素（４３２）のそれぞれを前記複数のパレット要素（４３４）のうちの１つにマッピングするコンピュータ実行可能命令と、
   前記マッピングされたパレット要素に応じて前記ワークフローを作成するコンピュータ実行可能命令と、
   前記ワークフローを前記表示領域（４０４）に表示するコンピュータ実行可能命令とを実行するように構成されることを特徴とする請求項１または２に記載のシステム。
4. さらに、前記複数のアクティビティ（４３０）を表示することと、前記アクティビティ（４３０）の前記選択を受け取ることと、前記ユーザ（４０２）から前記構造情報を受け取ることと、ワークフローを作成するために前記受け取った構造情報に従ってアクティビティ（４３０）の前記表示される選択を配列することのうちの１つまたは複数に対する手段を含むことを特徴とする請求項１乃至３のいずれかに記載のシステム。
5. さらに、前記表示領域（４０４）を含む表示装置（４０４）と、前記プロセッサ（４０８）とともに動作可能なユーザインターフェイス選択装置（４０６）とを備えることを特徴とする請求項１乃至４のいずれかに記載のシステム。
6. 前記プロセッサ（４０８）は、前記ユーザ（４０２）から前記複数のグラフィック要素（４３２）を受け取り、ワークフローをそれに応じて作成する手段を備え、前記表示領域（４０４）は、ユーザインターフェイスを備え、前記表示領域（４０４）は、アプリケーションプログラムの実行環境内で表示できるように適合されることを特徴とする請求項１乃至５のいずれかに記載のシステム。
7. ディスプレイ（４０４）およびユーザインターフェイス選択装置（４０６）を備えるシステムにおいて、アクティビティを含みビジネスプロセスをモデル化するワークフローをモデル化するための方法であって、
   前記ディスプレイ（４０４）上に複数のアクティビティを表示することと、
   前記ユーザインターフェイス選択装置（４０６）を介してユーザ（４０２）から前記アクティビティ（４３０）の選択を受け取ることと、
   前記ディスプレイ（４０４）上にアクティビティ（４３０）の前記受け取った選択を表示することと、
   前記ユーザインターフェイス選択装置（４０６）を介して前記ユーザ（４０２）から構造情報を受け取ることと、
   ワークフローを作成するために前記受け取った構造情報に従って前記ディスプレイ（４０４）上にアクティビティ（４３０）の前記表示される選択を配列することとを含むことを特徴とするコンピュータ化された方法。
8. さらに、複数のパレット要素（４３４）を定義することを含み、前記定義された複数のパレット要素（４３４）のそれぞれは前記複数のアクティビティ（４３０）のうちの少なくとも１つに対応することを特徴とする請求項７に記載のコンピュータ化された方法。
9. さらに、前記ユーザインターフェイス選択装置（４０６）を介して前記ユーザ（４０２）からカスタマイズ情報を受け取ることと、前記受け取ったカスタマイズ情報に応じて前記表示される複数のアクティビティ（４３０）を調整することとを含むことを特徴とする請求項７または８に記載のコンピュータ化された方法。
10. さらに、前記アクティビティ（４３０）の１つとの関連付けのため前記ユーザインターフェイス選択装置（４０６）を介して前記ユーザ（４０２）からビジネスロジックを受け取ることを含むことを特徴とする請求項７乃至９のいずれかに記載のコンピュータ化された方法。
11. さらに、前記ユーザインターフェイス選択装置（４０６）を介して前記ユーザ（４０２）からユーザ定義アクティビティを受け取ることを含み、前記ユーザ定義アクティビティは、１つまたは複数の関連付けられた意味論を持ち、さらに、定義済みインターフェイス要件に適合しているか調べるために前記意味論を評価することを含み、前記ユーザ定義アクティビティを前記評価結果に応じて前記アクティビティのうちの１つとして格納することを含むことを特徴とする請求項７乃至１０のいずれかに記載のコンピュータ化された方法。
12. さらに、前記作成されたワークフローをユーザ指定言語に翻訳するコマンドを受け取ることを含むことを特徴とする請求項７乃至１１のいずれかに記載のコンピュータ化された方法。
13. さらに、タッチスクリーン（４３６）を介して前記ユーザ（４０２）から、 前記表示されているワークフローに対する変数、前記ワークフローに対するコメント、アクティビティの前記配列され、表示されている選択への訂正のうちの１つまたは複数を受け取ることを含むことを特徴とする請求項７乃至１２のいずれかに記載のコンピュータ化された方法。
14. ディスプレイ（４０４）およびユーザインターフェイス選択装置（４０６）を備えるシステムにおいて、アクティビティ（４３０）を含みビジネスプロセスをモデル化するワークフローをモデル化するためのコンピュータ実行可能コンポーネントを収めた１つまたは複数のコンピュータ可読媒体（４１０）であって、前記コンピュータ実行可能コンポーネントは、
    前記ディスプレイ（４０４）上に複数のアクティビティ（４３０）を表示するレンダリングコンポーネント（４１２）と、
    前記ユーザインターフェイス選択装置（４０６）を介してユーザ（４０２）から前記レンダリングコンポーネント（４１２）により表示される前記アクティビティ（４３０）の選択を受け取るためのインターフェイスコンポーネント（４１４）であって、前記レンダリングコンポーネント（４１２）はさらに前記インターフェイスコンポーネント（４１４）により受け取ったアクティビティ（４３０）の前記選択を前記ディスプレイ（４０４）上に表示し、前記インターフェイスコンポーネント（４１４）はさらに前記ユーザインターフェイス選択装置（４０６）を介して前記ユーザ（４０２）から構造情報を受け取るインターフェイスコンポーネント（４１４）と、
    ワークフローを作成するために前記受け取った構造情報に従って前記ディスプレイ（４０４）上にアクティビティ（４３０）の前記選択を配列するためのデザイナコンポーネント（４１６）を含むことを特徴とするコンピュータ可読媒体。
15. さらに、複数のパレット要素（４３４）を定義するパレットコンポーネント（４２２）を含み、前記定義された複数のパレット要素（４３４）のそれぞれは前記複数のアクティビティ（４３０）のうちの少なくとも１つに対応し、前記インターフェイスコンポーネント（４１４）は、前記インターフェイス選択装置（４０６）を介して前記ユーザ（４０２）から複数のグラフィック要素（４３２）を受け取り、前記受け取った複数のグラフィック要素（４３２）は前記ディスプレイ（４０４）上に表示される前記アクティビティ（４３０）の選択に対応し、前記アクティビティ（４３０）の前記選択は前記ワークフロー作成するように配列されることを特徴とする請求項１４に記載のコンピュータ可読媒体。
16. さらに、前記インターフェイスコンポーネント（４１４）によって受け取った前記複数のグラフィック要素（４３２）のそれぞれを前記パレットコンポーネント（４２２）によって定義された前記パレット要素（４３４）の１つに関連付け、前記ワークフローを前記ディスプレイ（４０４）に表示するように前記関連付けられたパレット要素（４３４）を配列するレコグナイザコンポーネント（４２０）を含むことを特徴とする請求項１４または１５に記載のコンピュータ可読媒体。
17. 前記インターフェイスコンポーネント（４１４）は、さらに、前記ユーザインターフェイス選択装置（４０６）を介して前記ユーザからユーザ定義アクティビティを受け取り、前記ユーザ定義アクティビティは１つまたは複数の意味論が関連付けられており、さらに定義済みインターフェイス要件に適合しているか調べるために前記意味論を評価するバリデーションコンポーネント（４１８）を含むことを特徴とする請求項１４乃至１６のいずれかに記載のコンピュータ可読媒体。
18. 前記レンダリングコンポーネント（４１２）は、さらに、前記受け取ったユーザ定義アクティビティを前記バリデーションコンポーネント（４１８）の結果に応じて前記ディスプレイ（４０４）上に前記複数のアクティビティ（４３０）のうちの１つとして表示し、前記インターフェイスコンポーネント（４１４）は、さらに、前記アクティビティ（４３０）の１つに関連付けられたビジネスロジックを受け取り、前記レンダリングコンポーネント（４１２）、インターフェイスコンポーネント（４１４）、およびデザイナコンポーネント（４１６）は、アプリケーションプログラムの実行環境内で実行され、前記インターフェイスコンポーネント（４１４）は、グラフィカルユーザインターフェイスおよびアプリケーションプログラミングインターフェイスのうちの１つまたは複数を含むことを特徴とする請求項１４乃至１７のいずれかに記載のコンピュータ可読媒体。
19. 前記ディスプレイ（４０４）は、タッチスクリーン（４３６）を備え、前記インターフェイスコンポーネント（４１４）は、前記ビジネスロジックを前記ワークフロー内の前記配列されたパレット要素の１つに対応する前記アクティビティ（４３０）の１つに関連付けることを特徴とする請求項１４乃至１８のいずれかに記載のコンピュータ可読媒体。
20. さらに、ユーザ定義テーマを前記タッチスクリーン（４３６）上に表示される前記ワークフローに適用するためのスキンコンポーネント（４２４）を含み、さらに、前記レコグナイザコンポーネント（４２０）により配列された前記関連付けられたパレット要素に従って前記ワークフローを作成するためのワークフローコンポーネント（４２６）を含むことを特徴とする請求項１４乃至１９のいずれかに記載のコンピュータ可読媒体。
    
    

Images