This page present the global design of the C++ version of Fs3d, and assumes the reader has a good understanding of design patterns (among others MVC and facade). A brief explanation about these may be found here: Design patterns.
This software implements the processing pipeline described below:
All these steps (described in further details on the Algorithm page) are implemented as plugins.
Processing step implementation:
Each step described above is implemented following the same pattern, described in the sections below.
Data types (Model)
The design is fully object-oriented, hence the data types aim to represent as much as possible the real-world objects (for example fs3dHeadData for the head model). These data types are located in the src/fs3dCore/data folder.
For processes taking many parameters, a specific structure is defined, so as to provide a unique interface and some convenience methods as equality operators, default constructors, and so on.
Abstractions (Controller)
A step of the process is represented by its abstraction, located in src/fs3dCore. An abstraction defines the inputs and outputs of a process (using the data types described above), and should be as atomic as possible. All abstractions have a semantic meaning and hence are header-only.
Plugins (Controller)
The concrete implementation is done through plugins. Several plugins may implement the same abstraction. A plugin implementing an abstraction is supposed to match exactly its interface, have no side effect. (In particular, no hypothesis should be done on which plugins were called before/will be called after).
Using abstractions
In order to make these steps as easily usable as possible, a convinience class wrap all the calls to the modules. This class is named fs3dPipeline and is located in src/fs3dCore. Calling the different steps is done through the GUI.
Graphical User Interface (view)
The GUI is divided into three parts: widgets acting as views for the dedicated data types, user interaction dedicated widgets, and application specific elements.
Views widgets
These widgets are located in src/fs3dWidgets. They are designed to offer convinients views of the data types defined by the platform (for example, fs3dEEGView is the graphical representation of the fs3dEEGData).
User interaction widgets
Some widgets (the ones displayed in the topmost banner) are used to set the different algorithms' parameters.
Application specific elements.
The widgets described above are the base component on which the application window is build. The main window aggregates all components, both graphics (all widgets are added to the main window) and software (the main window connect all the signals emitted by the widgets to the dedicated modules).
Global application design:
The application takes advantage of qt's qss facilities to provide a visually consistent environment. All the files required for handling qss are grouped in the folder src/fs3dGui. This allow to eventually offer different skins for the application, and to use existing one in the whole software suite.
Other features
The architecture described above is common for all processing steps. However there are some additional features that are handled slightly differently. These specificities are detailed below.
Additional modules
Some modules that are not in the main pipeline are provided for specific tasks. An overview of these modules and how they are integrated is provided below.
Direct problem solver
An executable is available to solve the direct problem. It may be used to generate known data for Fs3d. The architecture is exactly the same as described previously, with a dedicated abstraction, the corresponding implementations, and a dedicated GUI to set the inputs/ display the output.
Selection module
The selection module is optional. Contrary to other modules, it provides a set of selection policies, implemented as plugins, whose keys are displayed in a combo box by the fs3dSelectWidget. These module have a list of scans as input and the list of good scans (selected among the previous ones) as output. The aforementionned widget update the scan buttons' state according to the new selection.
Persistence
The persistence feature has two goals:
- save computation time by avoiding re-calculation when a module's parameters are unchanged.
- save on disk a partial execution, to be able to reload it after closing and re-opening the software.
This is implemented by a class named fs3dPersistenceManager, which implements, for each module, a method whose signature is
that is called by the pipeline before running a module, to determine if the persistence manager has already saved the results for this module and this parameter.
Additionally it provides an abstraction for saving the fs3dModuleParameter classes on the disk.
Synchronisation
Fs3d has the ability to link several views so they move together as soon as one of them is moved. This is done by a class named fs3dSyncManager, that is designed as an add-on: The views that should be synchronized register themselves to the manager, that will copy the camera's parameter (position and roll, the focal point always being the origin) to all the registered views, when a camera is moved.
Experimental features
These features are implemented as proofs of concepts, and may be outdated. An overview of these is provided as a basis for later developpement.
Rewriting the matlab code in C++ (outdated)
Several plugins are left from an attempt of rewritting Fs3d without matlab. The corticalmap one has two versions, one using armadillo only, one using flens above armadillo. These two plugins copy lots of data and hence are very slow. There is a plain C++ dipolefit plugin, that has not been properly tested. The plain C++ scan plugin has never been terminated, because some matlab function have no equivalent in C++.
Preprocessing (draft version)
The preprocessing module has not been developped further than the proof of concept state. For testing purpose, the behaviour for two activities or more is not the expected one (the activitieToEeg plugin is faulty). The GUI uses the main window of fs3d as a widget, and hence includes another subdirectory of the app folder.
Composer (outdated)
The composer was written with the old version of dtk, it doesn't use the composer extension mecanism, and hence is not compatible with the new releases of dtk.
