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:
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).