DSPOOM as a Classification of DSP Objects

As presented in section 1.2.4 a metamodel such as DSPOOM aims at abstracting commonalities between a set of related models and presenting an abstract ``model of models''. Abstract metaclasses are actually acting as concrete class classifiers and as a matter of fact the relation between a metaclass (abstract class in the metamodel) and a concrete class is the same as the relation existing between a concrete class and its instances.

The infrastructure offered by CLAM and reviewed in the previous chapter can be understood as a set of objects and the way they interact. Most of these objects belong to three classes: Processing, ProcessingData and Network. These classes define the way that most CLAM objects contribute to the configuration of a given application, being this application in itself a CLAM model of a particular system. The three classes are abstract and therefore cannot be instantiated by themselves, but they define the model a CLAM system will comply to. In other words, a CLAM model can be described by the way that particular instances of these classes behave and interact in between them.

In a similar way DSPOOM classifies objects into four categories: objects that process (Processings), objects that hold data necessary for the process (Processing Data), objects that connect or interface (such as ports, data nodes or controls), and application or system-level objects.

Of these categories, the first two are much more important in their scope and the other two can be seen as auxiliary but necessary for completing the metamodel. The basic idea is to separate objects that encapsulate a process called Processing objects and objects that undergo a certain process encapsulating a kind of data object and are called Processing Data objects. This clear separation between data and process objects is not exclusive of CLAM but can be found more or less explicitly in different environments reviewed in chapter 2. See for instance the clear separation between virtual processors and virtual data in the VDSP framework in section 2.2. Each of this categories forms an abstract class of the DSPOOM Metamodel. Thus, a particular model, instance of the metamodel cannot instantiate objects of this class directly but instances of the subclasses related to the model under study.

Therefore, and simplifying the four-category metamodel, a DSPOOM based model can be viewed as a set of Processing objects deployed as an interconnected network. Each Processing can retrieve Processing Data tokens and modify them according to some algorithm. Programmers can keep control over the Processing Data flow between Processing or they can delegate this task to one of the many possible automated Flow Control schedulers. When a set of Processing objects is arranged they form a new processing. Thus the new processing can be used as an abstraction of the whole composition. DSPOOM Processings are compositional and scalable. Processing objects can be grouped on compile-time as Processing Composites, or dynamically on run-time as Networks.

DSPOOM is first, and above all, and object-oriented metamodel. Nevertheless, and as a consequence of applying good object-oriented practices, a graphical model of computation very much related to Process Networks and Actor-Orientation has emerged (see section 1.5 for an overview of this technology).

After this first introduction we will first present the main two metaclasses (i.e. Processing and Processing Data) in more detail. We will then present the composition capabilities of the framework. In the next sections we will analyze the object-oriented features of the metamodel and will relate it to existing graphical models of computation.

Figure 4.1: Basic elements in DSPOOM