Processing Composites

A Processing Composite is a static composition of DSPOOM Processing objects. A Processing Composite is manually implemented by a developer and might be fine-tuned for efficiency reasons. But the list of included Processing objects and their connections may not be modified at run-time^4.3. It is a direct implementation of the Composite pattern as defined in the Gang of Four catalog [Gamma et al., 1995].

A Processing Composite object has one parent that acts as the composite and any number of children that act as components. Any child can in turn be the parent of other Processing objects recursively defining different levels of composition. A Processing Composite object is seen as a regular Processing object from the outside, even in a Network-like context. Therefore, and as it happens in the classical composite pattern, performing an operation on the Processing Composite means performing it in all its children recursively to the lowest level. Particularly:

• Constructing a Processing Composite means constructing all its children.
• Configuring a Processing Composite means configuring all its children.
• Starting or stopping a Processing Composite means starting or stopping all its children.
• Executing a Processing Composite means executing all its children.

The ``construction condition'' implies that the most usual way to construct a Processing Composite is by having its children as regular member attributes. These attributes will be constructed in their parent construction, they will be attached to the children list, and they will be notified of whom the parent is at that time.

The ``configuration condition'' means that a Processing Composite has to offer a configuration that at least contains a subset of all the configuration parameters in the children. The process of creating a composite configuration cannot be automated and depends on design decisions. The Processing Composite class developer has to choose what parameters will be promoted from the children to the parent layer of composition. This list of published configuration parameters will define the subset of all parameters that will be available for the user. It is important to note that in many situations, children Processing objects share common configuration parameters or have parameters with coupled semantics. For instance, all children Processing objects in a Processing Composite may have a SamplingRate attribute that needs to be consistent. Even in that same Processing Composite we may have a spectral domain Processing object that has a SpectralRange parameter that, although not equivalent, is directly coupled to the SamplingRate. Because of all of this it is not a good idea to simply build the composed configuration by aggregating individual children configurations.

The ``start/stop condition'' does not imply any complex control issues and can be easily automated.

And finally the ``execution condition'' is where all the flow control issues have to be solved. No automation can be offered at this level and it is the designer's responsibility to choose in what order the children will be executed or how intermediate data will be handled. On the other hand, in reward for this complexity the Processing Composite designer is in the position to optimize and fine-tune all execution and control issues that could not be addressed in a generic environment such as a Network (see below).

Figure 4.7: Processing Composite