アーキテクチャ・ジャーナル CAB および SCSF を使用したコンポジット スマート クライアントの設計 Mario Szpuszta2009/03/16 |
|
|
■WorkItem の設計とパッケージ化
WorkItem は、ユーザーがアプリケーションを使用して完了する必要のある特定のタスクのロジックをすべてカプセル化するコンポーネントです。このような役割を持つ WorkItem は、ユーザーに実際のビジネス機能をもたらすので、コンポジット スマート クライアントの最も重要な一元的要素となっています。CAB は、作業を連携して実行するための WorkItem の階層を管理できます。この目的のために、WorkItem にはコントローラ クラスおよびモデルを含む、1 つ以上のビュー (SmartPart) を含んでいるか、これらのビューについて認識しています。WorkItem は、どの SmartPart をどのようなタイミングで表示し、どのサブ WorkItem をどのようなタイミングで起動する必要があるかを認識しています。さらに、親 WorkItem は、特定のタスクのエントリ ポイントになります。最後に、WorkItem はすべての SmartPart およびサブ WorkItem に必要な状態を管理します。
コンポジット スマート クライアントの WorkItem を識別する方法は、2 種類あることが開発中にわかりました。これらはユース ケース指向のアプローチと、ビジネス エンティティ指向のアプローチです。これらについては、例を示しながら説明するのが最適です (これらの例は、この記事の目的に沿って示すもので、私が関与していたプロジェクトや他の金融グループのプロジェクトを表すものではありません)。
■ユース ケース指向の戦略
CAB のアーキテクチャの最大の利点の 1 つは、ユース ケース図に基づいて WorkItem を設計できることです。ほとんどの場合、ユースケースと WorkItem 間には 1 対 1 のマッピングを作成します。通常は、1 つのユース ケースが 1 つの WorkItem にカプセル化されます。したがって WorkItem は、ユース ケース (タスク) を完了するために必要なユーザー インターフェイス プロセスを実装し、そのために必要な要素すべてを統合するユース ケース コントローラにすぎません。図 4 に示すユース ケース図は、株式管理システム用に設計されたものです。このシステムは、証券取引 (株式ビジネス) に関して顧客とコンサルテーションを行い、顧客の証券取引要求に対応するために使用されてきました。
図 4: ユース ケース図の例 |
図 4 に示すユース ケースを実装しているアプリケーションは、顧客とのコンサルテーションを行うフロント オフィスの従業員と、証券取引を行うバック オフィスの従業員をサポートします。これを達成するために、まず 1 つのユース ケースを 1 つの CAB-WorkItem にマッピングします。ユースケース間の関係には、2 つの性質があります。ユース ケースは別のケースのサブ ユース ケースとなるか、その親以外のその他多くのユース ケースによって使用されます。もちろん、他のユース ケースによって再使用されない単なるサブ ユース ケースであるユース ケースは、サブ WorkItem となります。純粋なサブ ユース ケースは、その親以外からアクセスされないサブ WorkItem です。一方、その親だけでなく、数多くの他のユース ケースによって使用されるユース ケースは、直接アクセスできるか、親 WorkItem を経由してアクセスできるようにする必要があります。
■モジュール コントローラの WorkItem
親のユース ケースは、そのサブ WorkItem すべてのエントリ ポイントです。通常、モジュールには、モジュール ユース ケース コントローラと呼ばれるルート親 WorkItem があります。この WorkItem は、直接的なサブ WorkItem に必要な状態を管理し、これらに対して正しいコンテキストを提供します。通常、モジュール ユース ケース コントローラは、モジュールが他のモジュールに提供できるサービスを追加し、必要とする他のサービスへのサービス参照を取得し、そのサブ WorkItem のいずれかを起動するための UIExtenionSites およびコマンドを登録し、そのサブWorkItem を起動します。サブ WorkItem を持たない単純な WorkItem またはサブ WorkItem 自体は、通常は同じ手順を実行します。ただし、その階層レベルのみにおいて使用可能なサービスを登録する必要があります。モジュール ユース ケース コントローラの WorkItem は、モジュールがアプリケーションに読み込まれるたびに作成する必要があります。
■ユース ケースの除外
図 5 に示すユース ケース図を詳しく見てみると、すべてのユース ケースがWorkItem となるわけではないことに気づきます。“銀行連絡依頼” ユースケースを見てください。ここで、銀行の従業員のみが使用するスマート クライアントを設計する必要があったことを思い出してください。株式取引のコンサルテーションを求めている顧客 (“銀行連絡依頼” を経由して依頼) は、フロント デスクに直接出向くか、インターネット バンキングまたはネット バンキング ソリューション (あるいはその他) を利用できます。いずれの場合も、このユース ケースは銀行の従業員用スマート クライアントに統合する必要があるものではなく、むしろその反対です。“顧客識別” は、現在設計中のスマート クライアントの一部に含める必要があります。
図 5: ユース ケースの除外 |
別の例に、“オフライン コンサルテーション” ユース ケースがあります。これは、スマート クライアントに対してどのような意味を持っているでしょうか。これは個別の WorkItem となるものですか。これによってビジネス ロジックは変更されますか。答えはいいえです。したがって、これは個別の WorkItem にはなりません。ただし、このユース ケースは全く異なるもののインジケータになります。つまり、オフライン サポートの必要性を示すインジケータとなります。したがって、これは以前識別したインフラストラクチャ サービスに対して検証する必要があります。たとえば、Web サービス エージェントは、接続の検出、オフライン参照データ ストア、および更新メッセージ キューをサポートする必要があります。
■サブ WorkItem または WorkItem
一部の WorkItem は、親にもなります。ただし、これらはユース ケース図の中では単にサブ WorkItem として表示されます。通常これは、ユース ケースが論理的には親ユース ケースに属していても、詳細な分析の結果、元の親または他のサブ ユース ケースと状態、コンテキスト、またはその他を共有しておらず、その他の共通点にも依存していないことが判明した場合に発生します。その場合は、不要なオーバーヘッドを避けるために、これも親 WorkItem にする必要があります。図 6 に示すユース ケース図の “株式の検索” および “取引の検索” ユース ケースを見てください。これらのユース ケースは、株式書類または注文されたビジネス取引を検索するためのみに使用されています。これらは、その親 WorkItem の共有状態またはコンテキストには依存していません。そのため、これらは所属先のモジュール (具体的にはモジュール コントローラ WorkItem) によって登録されているコマンドを経由して呼び出される親 WorkItem 自体となるのに最適な候補です。
図 6: サブ WorkItem または親 WorkItem |
■WorkItem の識別要約
最後に、ユース ケース図を作成し、ユース ケースを WorkItem にマッピングし、ユース ケースの除外と WorkItem の階層のリファクタリングを行うと、図 7 に示すようなコンポジット スマート クライアント用の完全な WorkItem オブジェクト階層が得られます。
図 7: 前のユース ケースの WorkItem を示すクラス図 |
パフォーマンスと簡潔さを保つために、ユース ケース図と WorkItem はできるだけ単純にすることをお勧めします。前述したアプローチによる利点は、WorkItem の識別、特に WorkItem の再利用性の側面の識別において、明確で構造化された手段が得られることです。
■ビジネス エンティティ指向の戦略
小規模で単純なアプリケーションに対する単純なアプローチは、スマート クライアント アプリケーションによって処理されたビジネス エンティティに基づいて WorkItem を識別および構造化することです。この方法では、アプリケーションによって処理されたビジネス エンティティ一覧を作成します。一般的な例には、Customer、Product、Stock、StockCredit、StockDebit、および StockTransfer があります。これらの各エンティティに対して、WorkItem を作成します。StockTransfer は、StockCredit および StockDebit を組み合わせたものであるので、これらをサブ WorkItems として使用します。
INDEX | ||
[アーキテクチャ・ジャーナル] | ||
CAB および SCSF を使用したコンポジット スマート クライアントの設計 | ||
1.コンポジット スマート クライアントのアーキテクチャ ガイダンス | ||
2.コンポジット UI アプリケーション ブロック | ||
3.WorkItemを識別するユース ケース指向とビジネス エンティティ指向のアプローチ | ||
4.WorkItemのパッケージ化とスマート クライアント ソフトウェア ファクトリ | ||
「アーキテクチャ・ジャーナル」 |
- 第2回 簡潔なコーディングのために (2017/7/26)
ラムダ式で記述できるメンバの増加、throw式、out変数、タプルなど、C# 7には以前よりもコードを簡潔に記述できるような機能が導入されている - 第1回 Visual Studio Codeデバッグの基礎知識 (2017/7/21)
Node.jsプログラムをデバッグしながら、Visual Studio Codeに統合されているデバッグ機能の基本の「キ」をマスターしよう - 第1回 明瞭なコーディングのために (2017/7/19)
C# 7で追加された新機能の中から、「数値リテラル構文の改善」と「ローカル関数」を紹介する。これらは分かりやすいコードを記述するのに使える - Presentation Translator (2017/7/18)
Presentation TranslatorはPowerPoint用のアドイン。プレゼンテーション時の字幕の付加や、多言語での質疑応答、スライドの翻訳を行える
|
|