Oscar Software Framework Manual Hierarchy and Modules

Go to Table of Contents.

Hierarchy and Modules

The framework main 'class' contains an object (struct OSC_FRAMEWORK), where it stores references to all modules as member variables. On creation, no modules are loaded and the framework provides no functionality. As the desired modules are loaded by the application, the set of accessible functions increases. It is important to note that the application calls the methods of the module directly, the framework provides only a container where the modules are aggregated.

The arrows represent function calls. To the application, the framework presents itself as one big entity, but the function calls are effectively only executed in the corresponding modules.

At the time being, all modules are implemented as singletons, i.e. it is not possible to create two instantiations of the same module or two frameworks in the same process. This is mainly because of the limitations of the target platform (dynamic memory allocation should be avoided). For most modules it makes no sense having multiple copies anyway (image processing, modules bound to a single hardware entitiy). Others contain a fixed, but configurable number of sub-entities (like GPIO signals, or IPC channels).

Each module also contains a list of dependencies, which must be loaded upon module creation. These are other modules required by that module.

In the image, for example, Module 2 depends on Modules 1 and 3, and Module 3 itself depends on Module 4. The application does not need to be aware of the relationship between the modules, since the dependencies are automatically resolved during module loading. For this purpose, each module object contains a reference count, keeping track of how many users still depend on the existence of the module and thus determining when it can be unloaded. The dependencies may differ between the target and host implementation. Although the modules depend on each other, the encapsulation is enforced, i.e. one module may only use public functions of the API of another module, and has no access to its inner variables and workings. There are also modules that are not intended to be used by the application directly, but are rather only shared helpers for other modules (e.g. for the simulation on the host architecture).

• A public header with the API functions and declarations belonging to that module. This header file is included in the main header file oscar.h which in turn is used by the application.
• A private header with the object structure containing member variables of the module (equal to the private members of a class body) and private methods and definitions of that module (that class). This header is therefore required by the source code implementing the module.

The framework itself also contains, apart from the main header with all the API definitions, a private header with its own declarations. Additionally there exists a header file oscar_intern.h which declares the symbols only used within the framework, like facilities for loading and unloading dependencies and the framework object structure. This organisation reflects the object-oriented fashion of the software design. Each module contains public (in module_pub) and private methods (in module_priv.h. It also contains a set of private member variables in its object structure in (in module_priv.h).