V.9 Tutorial 9: The module implementation policy (developers only)
This tutorial explains what is the implementation module policy and why it is important. A knowledge of object oriented techniques is a prerequisite to understand Tutorial 6.
Basically, the file EmptyModel.xml that you loaded in Tutorial 2 contains a module implementation policy. It means that it limits the number of classes available for selection in the "parameter" combo box of module panels (Figure 7). These classes inherits from a superclass and/or a set of interfaces.
In order to start the GuiKit, you need to use the same command lines which were required to start NMLPlay, but you need to put guikit.BasicApp instead of nmlplay.NMLPlay_2.
Load EmptyModel.xml. The window corresponding to Figure 4 will appear. In the implementation modules. In the "ImplementationModules" panel, there are a set of generic modules recognized. They correspond to the module attributes of NeuroML classes. Click on neuroml.model.cell.ModuleNeuron.module and then click on the "Edit" button. The window corresponding to Figure 41 will appear.
Figure 41 : inheritance policy for "neuroml.model.cell.ModuleNeuron.module"
As you can see the superclass is set to neuroml.util.module.BasicRunnableCellFactory. It is possible to remove the superclass by clicking on "Clean". A new one can be selected, and a set of interfaces can be included. The entire inheritance policy can be determined by browsing through all the modules from the ImplementationModules (Figure 42).
| Class (end of the name) | Superclass | Interfaces |
| ModuleNeuron.module |
neuroml.util.module. BasicRunnableCellFactory |
|
| GeneralProjection.sourceMethod | neuroml.sim.run.SourceMethod | |
| GeneralProjection.destMethod | neuroml.sim.run.DestMethod | |
| ModuleProjection.module | ||
| ModuleAttachment.destmethod | neuroml.sim.run.SourceMethod | |
| ModuleAttachment.sourcemethod | neuroml.sim.run.DestMethod | |
| ModuleProbe.module |
neuroml.util.module. BasicRunnableCellFactory |
|
| ModulePosition.module | neuroml.model.network.PositionModule | |
| ControlledSchedule.module | ||
| Module_I_Clamp.module | neuroml.model.I_Clamp.I_Clamp | |
| ModuleChannel.module | neuroml.ions_channels.Channel | |
| ModuleMeasurement.module |
Figure 42 entire inheritance policy
This is a very general and loose implementation policy. There are cases where the choices should be even more restricted. For instance, classes available for selections are common between:
- "GeneralProjection.destMethod" and "ModuleAttachment.destmethod"
- "GeneralProjection.sourceMethod" and "ModuleAttachment.sourcemethod"
- "ModuleNeuron.module" and "ModuleProbe.module"
In fact, it is unlikely that modules developed for "ModuleNeuron.module" work with "ModuleProbe.module" or modules developed for "ModuleProbe.module" work with "ModuleNeuron.module". Even though these modules would have a partial common behavior, it is unlikely that the NEOSIM simulation would work. So the user must ensure the consistency of his choices. Another implementation policy might be more suitable if there were many final users only working with the module Holger_modules.jar for example. It would then be better to restrict the superclass of "ModuleNeuron.module" to Holger_modules.module.iafneuron.IAFNeuronFactory and the superclass of "ModuleProbe.module" to Holger_modules.module.multiprobe.ProbeCtrlFactory.
Module implementation policies are not a critical aspect of the GuiKit. The GuiKit can be used without it. However, in an environment where many modules containing hundreds of classes are used and users are numerous, it is an important tool to enhance the user-friendliness of the application.