Composing with DSPOOM Objects: Networks and Processing Composites

The DSPOOM metamodel offers different mechanisms for composing with Processing objects. In this section we will show their features and intent. Composition in DSPOOM is not an absolute need as any model can be fully specified by a number of independent though coordinated Processing objects. Nevertheless, building self-contained sub-models (thus abstract subsystems) offers a number of advantages, namely:

1. Complexity and detail hiding. Submodels can act as intermediate layers that hide complexity from the user. This way we can choose what details will be promoted from one level to another and what formal view we want to offer the user of each layer.
2. Flow control automation. By building coherent and homogeneous compositions we are able to apply standardized approaches to automatic flow control in which an ``intelligent'' entity is able to manage data flow and process execution.
3. Efficiency and optimization. A composition can be a specialized grouping of Processing objects with a specific purpose and goal. By using information about the context in which each individual and possibly generic Processing object is used, we can manage to optimize the overall execution.

The two mechanisms for composing with Processing objects in a DSPOOM model are Networks and Processing Composites. Networks are dynamic compositions that can be modified at run time in any way by adding new Processing objects or modifying connections. Processing Composites are static compositions that are built on compile time and cannot be modified thereafter. These DSPOOM constructs were already graphically illustrated in figure 4.1.

Note that both mechanisms address the first of the three benefits previously enumerated. But while Networks promote the ability to use automatic flow control (benefit number 2), Processing Composites strive for efficiency (benefit number 3). As R. Dannenberg points out in [Dannenberg, 2004] it may seem at first sight that static composition is not useful in the general case as, although it can be more efficient, it is far less flexible. But experience indicates that static composition is preferred in many occasions due to a number of different advantages: it avoids dynamic patching and therefore becomes more efficient, it enables inlining and other performance tricks, it allows better debugging and finally and most important, users can reason better about their code when it is static.

In general the dynamic composition offered by Networks follows the Dataflow Architecture pattern while the static composition in Processing Composites follows the Adaptive Pipeline pattern (see 1.5.3). Networks are also somehow related to Max's, CSL's and OSW's patches ( see 2.5, 2.3.3, and 2.3.2) while Processing Composites are similar to Aura's instruments (see 2.3.2).