Connections between the Software Modules

There are basically three ways, how the software modules can be connected.

The all-in-one solution

First, there is the all-in-one solution, meaning that all software modules are combined in one application. This is the easiest and fastest way to implement, since all software modules can directly call methods from other modules (e.g., start of stimulus generation) and can access the data of all other software modules directly. However, if hardware devices are used which do not offer open access to their data but only the use of proprietary manufacturer software, an all-in-one solution might not be possible. These parts of the SCF implementation would then have to be excluded from the all-in-one solution and be accessed in another way. Moreover, the easy interchangeability of single module implementations by other, better implementations is not given anymore when using a all-in-one solution. Furthermore, if one software module crashes (e.g. data visualization), all other modules might stop working, too (depending on the concrete implementation).

The none-in-one solution

Second, all software modules could run separately, avoiding the disadvantages of the all-in-one solution at the expense of a more complex development, since this implies that the software modules have to communicate with each other: for controlling each other and for exchanging data. For instance, the software module for REM detection could send its data (the current REM status of the sleeper) to the user interaction and flow control module, which determines according to a rule (e.g. a waiting time rule) whether the stimulus generation should start, and then eventually sends a command to the stimulus generation module.

There are several ways on how to implement such a module communication, for example by storing the relevant information in a file or database, by using shared memory, socket programming and many more. All these connection types have their benefits and disadvantages; the interested reader is referenced to the specialized literature, e.g. Akhter and Roberts (2006).

The middle way

Third, a middle way between the all-in-one solution and the complete separate implementation could be chosen, by combining some of the modules into one software implementation.