# Following the Writer's Path to the Dynamically Coalescing Reactive Chains Design Pattern
## Appendix B.5.3 Solution: Augmenting the Application  
To apply the DCRC pattern to an application that satisfies the Context, we can augment the application with appropriate _software mechanisms_. For example, Figure 5 illustrates how a solution can augment an application's event handling to coalesce dependent events into larger-grained events without modifying the underlying event-handling mechanisms. Beginning with the application's II architecture (shown in panel 1), a solution first determines the dependency relationships between the components (panel 2 and also Figure 4) and then builds the corresponding dependency graph (panel 3). Then it can use the dependency graph to rearrange the component updates in any order that satisfies the dependency constraints (panel 4). In particular, the solution seeks to optimize the processing of an update cycle by performing all the updates in the cycle (the shaded area in Figure 4) directly as part of the processing of the first event. These software mechanisms may include some combination of libraries, frameworks, tools, and design and programming techniques. The various mechanisms should be _lightweight_. That is, they should execute efficiently and should not require extensive modifications to the existing application. The \"software mechanisms\" needed and the meaning of \"lightweight\" depend on the application's specific implementation technologies and performance requirements. For applications that satisfy the Context, a developer can augment the application's event-handling mechanisms to solve the Problem. In general, to construct a Solution, the developer needs to design, implement, and deploy three primary software mechanisms: one to build the dependency graph at startup of the application, one to rebuild the dependency graph when needed during the application's execution, and one to coalesce all the component updates in an update cycle into a single event. The construction of these software mechanisms involves an _augmentation workflow_ with three phases:  
1. _Augmentation analysis_, which requires _analyzing_ the application to identify how to add the necessary mechanisms;
2. _Augmentation development_, which requires _developing_ (i.e., designing and implementing) the mechanisms;3. _Augmentation incorporation_, which requires _incorporating_ the mechanisms into the operation of the application. Figure 6 summarizes the augmentation workflow, restating the tasks as questions to answer. Solution: Augmentation Analysis  
In the augmentation analysis phase, the solution developer must perform the three tasks AA1, AA2, and AA3 to analyze the original application and define the requirements for the new software mechanisms. 1. [label=(AA1)]
2. Examine the hierarchical structure to identify how a program can iterate through the components (i.e., accessing each component exactly once). 3. Examine the design and implementation of the components and the features of the implementation language to identify how a program can extract the dependency relationships between the components at run time. Task AA2 may involve the use of the existing features of the components or the reflection capabilities of the implementation language. If sufficient capabilities do not exist, we can design lightweight modifications that implement sufficient application-specific capabilities. 1. [label=(AA3)]
2. Examine the components and events to determine which of the relationships between the components to include in the dependency graph and which to exclude. To reduce transitional turbulence, the augmented application program can manipulate the components and relationships included, but cannot manipulate those excluded. Generally speaking, in task AA3 we include the component relationships arising from the application's custom code (which we can modify if needed) and exclude those in the supporting framework (which we cannot modify). We may also want to exclude any component relationship if that relationship represents an expensive computation or an arbitrary delay.