Diseño jerárquico de casos: garantía y recuperación
Diseño de casos
Considere los siguientes requerimientos de una empresa fabricante de automóviles que está automatizando una aplicación de reclamo de garantía. La aplicación respalda dos procesos principales: un proceso de reclamo de garantía y uno de recuperación.
Un cliente lleva el automóvil al concesionario para reclamar la garantía porque hay algo que no funciona correctamente. El concesionario evalúa el problema del automóvil, ingresa los detalles del reclamo en la aplicación y recibe la confirmación de la aplicación de que la garantía cubre la reparación. Posteriormente, el fabricante del automóvil compensa al concesionario por el trabajo.
En todos los reclamos de garantía, se incluyen una o más tareas de reclamo. Cada tarea de reclamo representa el trabajo que debe completarse para resolver el reclamo. La mayoría de los reclamos de garantía son simples y tienen una tarea de reclamo Pay Dealer. En algunos reclamos de garantía, se requiere un procesamiento más complejo si se incluyen disputas.
Las recuperaciones son independientes de los reclamos de garantía. Las recuperaciones abarcan todo el proceso, desde la notificación inicial a los clientes cuando es necesaria una recuperación para compensar al concesionario por el trabajo completado para respaldar la recuperación. Un tipo particular de tarea de reclamo es una Part Return. Esta tarea de reclamo se diferencia de otras porque requiere un conjunto adicional de reglas de negocio, y el proceso es distinto.
En la siguiente tabla, se resumen los requerimientos de procesos.
| Proceso | Descripción |
|---|---|
| Warranty Claim | Proceso completo: abarca desde la inicialización del cliente hasta la resolución. |
| * Claim Task | Se usan una o más para cada reclamo. |
| * Part Return | Es una tarea específica con reglas de negocio adicionales. |
| Recall | Proceso completo: abarca desde la notificación inicial hasta la compensación final al concesionario. |
Diseñe una estructura de casos para respaldar esta aplicación.
Solución
Son posibles al menos dos casos: Recall y Warranty Claim.
Recall no tiene dependencias, pero usa un proceso distinto. Podría representar Recall como un caso independiente.
Hay varias opciones de diseño para el caso Warranty Claim.
Una opción es crear un caso Warranty Claim independiente y que se generen subprocesos condicionales para cada tipo de tarea de reclamo. Este enfoque es fácil de implementar, pero limita la extensibilidad y la capacidad de especializar las tareas de reclamo.
Otra opción es crear el caso Warranty Claim con un subcaso para cada tarea de reclamo. Esta opción de diseño ofrece la flexibilidad para crear tareas de reclamo especializadas, como Parts Return. El caso Warranty Claim es el caso principal o cubierta del caso Claim Task, ya que Warranty Claim depende de la resolución de todas las tareas Claim para que pueda resolverse el caso Warranty Claim.
La implementación del tipo de caso Parts Return como subclase heredera de un patrón de la clase ClaimTask indica que PartsReturn es un tipo específico de caso ClaimTask. Es importante evitar la confusión de tomar las subclases y los subcasos como sinónimos. La jerarquía de los subcasos se establece dentro de la regla Case Type. La jerarquía de subcasos es una decisión sobre la estructura de tipo de caso con respecto a diferentes casos. Por otro lado, una subclase indica que existe una relación is-a. La relación de clases es una decisión sobre la estructura de clases con respecto a diferentes clases.
No se proporciona información suficiente en los requerimientos a fin de establecer qué solución es la más adecuada para el diseño del caso Claim Task. Si hay muchos requerimientos de especialización o extensibilidad para la aplicación, el último diseño para el caso Claim Task es más adecuado.
This Topic is available in the following Module:
¿Quiere ayudarnos a mejorar este contenido?