Designing the subcase hierarchy
Archived
2 Tasks
10 mins
Scenario
The Front Stage application will be constructed with a single event case and child cases for each service process. There are additional decisions to make regarding the cardinality and instantiation of the child cases.
Analyze the key requirements for this application to determine the best design for the child cases and how the child cases will be started. For each child case type, review any viable alternative designs listing the pros and cons of each. Produce a recommendation for the most appropriate child case structure for the application. Key requirements to consider are:
- Processes — The weather prep, hotel rooms request, and parking functionality must be able to execute independently.
- Extensibility — It must be possible to specialize or extend the booking application to support different types of venues.
-
Reporting – Reports for events should be defined that display revenue, cost, and profit (profit by event type)
- Data — Users must not be able to see financial information.
- UI — Customer quotation, event manager review, and hotel booking screens.
Detailed Tasks
1 Solution detail
Weather child case
The amount of additional database storage required to support a weather child case, even if never accessed by a user, is inconsequential. In keeping with object-oriented programming encapsulation principle, it is desirable for the event case to delegate every task that is weather-related to a weather case. By implementing weather as a separate child case the potential exists to create a weather application on which any application, not just the Booking application, could use as a built-on application.
Hotel child cases
When a customer selects the Hotel Services option, multiple hotel child cases should be created as opposed to a single hotel child case. A child case per hotel, is preferred because:
- Application locking requirements are fully satisfied
- UI requirements are easier to satisfy
- A child case per hotel design has greater specialization potential
Parking child case
When the Parking and Shuttle Services option is selected by the customer, a single parking child case should be created.
2 Alternative approach analysis
Weather
Two options for the weather process are (1) to always create the weather child case, or (2) conditionally create the child case when precipitation is expected.
Option 1: Always create a weather child case
In this option, a weather sub case is always created for every approved event. The delay to wait for the weather check date-time is implemented in the weather case.
Option 2: Conditionally create a weather child case if precipitation is forecasted
In this option, the precipitation is checked by the Event case on the intended date-time. The weather child case is created only if there is precipitation in the forecast and weather preparation is required. This option could be implemented in one of four ways:
- Pause the Event case using a Wait shape until the desired date-time. Check the weather forecast. Conditionally create the weather case if precipitation is forecast.
- Within a parallel or spin-off flow within the Event case, check the weather at the desired date-time. Conditionally create the weather case if precipitation is forecast.
- Queue the check weather task to an agent. The agent performs the weather forecast at the desired date-time and conditionally creates the weather child case if precipitation is forecast.
-
Have a delayed Queue Processor check the weather forecast on the desired date-time. Conditionally create the weather child case if precipitation is forecast.
As shown in the following table, always creating a weather child case is more advantageous than conditionally creating a weather child case.
| Design | Pros | Cons |
|---|---|---|
| Always creating a weather child case (Option 1) |
|
|
| Conditionally creating a weather child case (Option 2) |
|
|
Parking
The parking case is straightforward and is only conditionally created when the parking service option is selected. Due to its simplicity, no other options are considered for this.
Hotel booking
Two options for the hotel case(s) are to create a single hotel case representing all hotels or multiple hotel cases (one for each hotel).
Option 1: Single hotel case
A single hotel case is created when the hotel service option is selected. Data objects representing each hotel are contained in the hotel case.
Option 2: Hotel child cases per hotel
As shown in the following table, creating a hotel child case per hotel is more advantageous than creating a single hotel case.
| Design | Pros | Cons |
|---|---|---|
| Single hotel case |
|
|
| Hotel child case per hotel |
|
|