Case hierarchy design: Warranty and recall

Consider the following requirements for an automobile manufacturing company automating a warranty claim application. Two primary processes are supported by the application: a Warranty Claim process and a Recall process.

A customer brings a car to the dealership for a warranty claim because something is not working correctly. The dealer assesses the problem with the car, enters the claim details into the application, and then receives verification from the application that the repair is covered under warranty. The dealer is subsequently compensated for the work by the car manufacturer.

Every warranty claim includes one or more claim tasks. Each claim task represents the work that must be completed to resolve the claim. Most warranty claims are simple and have a single Pay Dealer claim task. Some warranty claims require more complex processing if disputes are involved.

Recalls are separate from warranty claims. Recalls cover the entire process from initially notifying customers when a recall is necessary to compensate the dealer for the work completed to support the recall. One particular type of claim task is a Part Return. This claim task stands apart from others in that it requires an additional set of business rules, and the process is different.

The following table summarizes the process requirements.

Design a case structure to support this application.

At least two cases are possible: Recall and Warranty Claim.

Recall has no dependencies but does have a distinct process. You might represent Recall as a stand-alone case.

You have several design options for the Warranty Claim case.

One option is to create a stand-alone Warranty Claim case with conditional subprocesses spawned for each type of claim task. This approach is easy to implement, but it limits extensibility and the ability to specialize the claim tasks.

Another option is to create the Warranty Claim case with a subcase for each claim task. This design option offers the flexibility to create specialized claim tasks such as Parts Return. The Warranty Claim case is the parent, or cover, case of the Claim Task case since the Warranty Claim depends on all Claim tasks resolving before the warranty Claim case can be resolved.

The Parts Return case type being implemented as a pattern-inheriting subclass of the ClaimTask class indicates that PartsReturn is a specific type of ClaimTask case. It is important not to confuse subclasses and subcases as being synonymous. The hierarchy for subcases is established within the Case Type rule. Subcase hierarchy is a case type structure decision with respect to different cases. A subclass, on the other hand, indicates that an is-a relationship exists. Class relationship is a class structure decision with respect to different classes.

Not enough information is provided in the requirements to determine which solution is more suitable for the Claim Task case design. If there are many specialization or extensibility requirements for the application, the latter design for the Claim Task case is more suitable.