Diseño de la jerarquía de subcasos
3 Tareas
1 h 30 minutos
Escenario
La aplicación Front Stage está desarrollada con un solo caso de evento y casos hijo para cada proceso de servicio. Hay otras decisiones que tomar con respecto a la cardinalidad y la instanciación de los casos hijo.
Analice los requerimientos clave de esta aplicación para determinar el mejor diseño para los casos hijo y cómo se inician los casos hijo. Para cada tipo de caso hijo, revise los diseños alternativos viables, y enumere los pros y los contras de cada uno. Genere una recomendación para la estructura de casos hijo más apropiada para la aplicación. Los requerimientos clave para considerar son los siguientes:
- Procesos: la preparación meteorológica, la solicitud de habitaciones de hotel y la funcionalidad de estacionamiento se deben ejecutar de forma independiente.
- Extensibilidad: debe ser posible especializar o ampliar la aplicación de reservas para admitir diferentes tipos de lugares.
- Reportes: se deben definir reportes para eventos que muestren ingresos, costos y ganancias (ganancias por tipo de evento).
- Datos: los usuarios no deben poder ver la información financiera.
- UI: cotización del cliente, revisión del gestor de eventos y pantallas de reserva de hotel.
Tareas detalladas
1 Identificar opciones de diseño
Clima
Existen dos opciones para el proceso meteorológico:
- Cree siempre el caso hijo del clima.
- Cree condicionalmente el caso hijo cuando se esperen precipitaciones.
Opción 1: crear siempre un caso hijo meteorológico
En esta opción, siempre se crea un subcaso meteorológico para cada evento aprobado. La demora para esperar la fecha y hora de la verificación del clima se implementa en el caso del clima.
Opción 2: crear condicionalmente un caso hijo meteorológico si se pronostican precipitaciones
En esta opción, la precipitación es verificada por el caso de evento en la fecha y hora deseadas. El caso hijo meteorológico se crea si solo hay precipitaciones en el pronóstico y se requiere preparación meteorológica. Esta opción se puede implementar de una de cuatro maneras disponibles:
- Pause el caso del evento usando una figura de espera hasta la fecha y hora deseadas. Consulte el pronóstico meteorológico. Cree condicionalmente el caso meteorológico si se pronostican precipitaciones.
- Dentro de un flujo paralelo o de spin-off dentro del caso de evento, verifique el clima en la fecha y hora deseadas. Cree condicionalmente el caso meteorológico si se pronostican precipitaciones.
- Ponga en cola la tarea de verificación del clima para un agente. El agente realiza el pronóstico meteorológico en la fecha y hora deseadas y crea condicionalmente el caso hijo del clima si se pronostican precipitaciones.
- Haga que un Procesador de colas postergado verifique el pronóstico del tiempo en la fecha y hora deseadas. Cree condicionalmente el caso hijo del clima si se pronostican precipitaciones.
Estacionamiento
El caso de estacionamiento es sencillo y se crea condicionalmente solo cuando se selecciona la opción de servicio de estacionamiento. Debido a su simplicidad, no se consideran otras opciones para esto.
Reserva de hotel
Hay al menos dos opciones de diseño viables para las solicitudes de habitaciones de hotel. La primera consiste en crear un caso único de servicios de hotel que represente todas las solicitudes de habitaciones de hotel. La segunda consiste en tener varios casos de solicitudes de habitaciones de hotel individuales (uno por hotel solicitado).
Opción 1: Caso único de hotel
Se crea un caso único de hotel cuando se selecciona la opción de servicio de hotel. Los objetos de datos que representan a cada hotel están contenidos en el caso del hotel.
Opción 2: Casos hijo por hotel
Se crea un caso de hotel separado para las habitaciones de un hotel solicitado cuando se selecciona la opción de servicio de hotel. Los casos hijo que representan a cada hotel solicitado están cubiertos por el caso padre de reserva de eventos.
2 Evaluar opciones de diseño
Clima
Como se muestra en la siguiente tabla, crear siempre un caso hijo meteorológico es más ventajoso que crear condicionalmente un caso hijo meteorológico.
| Diseño | Pros | Contras |
|---|---|---|
| Crear siempre un caso hijo meteorológico (opción 1) |
|
|
| Crear un caso hijo meteorológico de forma condicional (opción 2) |
|
|
Estacionamiento
El caso de estacionamiento es sencillo y se crea condicionalmente solo cuando se selecciona la opción de servicio de estacionamiento. Debido a su simplicidad, no se consideran otras opciones para esto.
Reserva de hotel
Como se muestra en la siguiente tabla, crear un caso hijo por hotel es más ventajoso que crear un caso único de hotel.
| Diseño | Pros | Contras |
|---|---|---|
| Caso único de hotel |
|
|
| Caso hijo por hotel |
|
|
3 Recomendar la mejor opción de diseño
Caso hijo meteorológico
De acuerdo con el principio de encapsulación de la programación orientada a objetos, el caso de evento delega todas las tareas relacionadas con el clima a un caso meteorológico. Al implementar el clima como un caso hijo separado, existe la posibilidad de crear una aplicación meteorológica en la que cualquier aplicación, no solo la aplicación Booking (Reservas), podría usarse como una aplicación incorporada. Si la concesión de licencias es una preocupación, se debe considerar otra opción.
Casos hijo de hoteles
Cuando un cliente selecciona la opción Hotel Services (Servicios de hotel), se crean varios casos hijo de hotel en lugar de un único caso hijo de hotel. Se prefiere un caso hijo por hotel porque:
- Los requerimientos de bloqueo de la aplicación se cumplen por completo.
- Los requerimientos de la UI son más fáciles de satisfacer.
- Un caso hijo por diseño de hotel tiene un mayor potencial de especialización.
Caso hijo de estacionamiento
Cuando el cliente selecciona la opción Parking and Shuttle Services (Servicios de estacionamiento y transporte), se crea un solo caso hijo de estacionamiento.
Disponible en la siguiente misión:
¿Quiere ayudarnos a mejorar este contenido?