ケース階層デザイン：保証とリコール

自動車メーカーが保証請求アプリケーションを自動化する場合の要件について考えてみましょう。 このアプリケーションでは、Warranty ClaimプロセスとRecallプロセスという主に2つのプロセスをサポートしています。

ある顧客が、車の調子が悪いので保証を受けたいとディーラーに車を持ち込まれました。 ディーラーが車の不具合を調べ、請求内容をアプリケーションに入力すると、アプリケーションでは保証の対象となる修理であるという確認が示されます。 ディーラーはその後、自動車メーカーから作業費を受け取ります。

すべての保証請求には、1つまたは複数の請求タスクが含まれます。 各請求タスクは、請求を解決するために完了しなければならない作業を表します。 ほとんどの保証請求はシンプルで、1つのPay Dealer請求タスクが含まれます。 保証請求の中には、異議申立が発生した場合、複雑な処理を必要とするものがあります。

リコールは保証請求とは別に処理されます。 リコールには、リコールが必要なことを顧客に最初にお知らせすることから、リコール対応のためにディーラーが完了した作業に対する費用の支払いまで、すべてのプロセスが含まれます。 請求タスクの1つに、Part Returnがあります。 この請求タスクは、他のタスクと異なり、追加のビジネスルールが必要で、プロセスも異なります。

次の表は、プロセス要件をまとめたものです。

このアプリケーションをサポートするケース構造を設計します。

少なくともRecallとWarranty Claimという2つのケースが考えられます。

Recallには従属関係はありませんが、明確なプロセスがあります。 Recallは独立したケースとして表されます。

Warranty Claimケースには、いくつかの設計オプションがあります。

1つのオプションは、個別にWarranty Claimケースを作成し、請求タスクの種類ごとに条件付きのサブプロセスを生成することです。 この方法は実装が簡単ですが、請求タスクの拡張性や専門化に限界があります。

もう一つの方法は、Warranty Claimケースを作成し、各請求タスクのサブケースを作成することです。 この設計オプションでは、Parts Returnなどの専門化された請求タスクを柔軟に作成できます。 Warranty Claimケースは、解決される前に、すべての請求タスクが解決されることに依存するため、Warranty ClaimケースはClaim Taskケースの親ケース、またはカバーケースとなります。

ClaimTaskクラスのパターン継承サブクラスとして実装されたParts Returnケースは、Claim Taskケースの特定のタイプであることを示しています。 サブクラスとサブケースを同義語として混同しないことが重要です。 サブケースの階層は、Case Typeルールの中で設定されます。 サブケース階層とは、さまざまなケースに関してケースタイプ構造を決定することです。 一方、サブクラスは、is-aの関係が存在することを示します。 クラス関係とは、さまざまなクラスに関してクラス構造を決定することです。

Claim Taskケースの設計において、どのソリューションがより適しているかを判断するための要件には、十分な情報が含まれていません。 アプリケーションに特殊性や拡張の要求が多い場合は、後者のClaim Taskケースの設計がより適しています。