Views

Namespaces

Contents

[edit]

Discussion on Sofa architecture

File Sofa/doc/namespaces.cpp summarizes the current Sofa namespaces. Originally, the idea was:

  • Abstract models the high-level modularity: multimodal representation of an object
  • Core models the low-level modularity: decomposition of a BehaviorModel in a several components
  • Components gathers the derived components

Then a lot of things where added and we have lost a part of the original consistency. For instance:

  • Abstract is not abstract, because several classes have contain data and implement methods related to scenegraph, events, etc.
  • Core contains most of the abstract classes (Basic*), but not only
  • Component::Graph manipulates abstract objects, not actual components

The following figure is an attempt to illustrate current namespace dependency. A common horizontal line means that one namepace addresses the other. Namespace MyTypes shows the possible type customization.

image:namespaces.png

This figure is a bit complex and nested boxes do not mean nested namespace. Feel free to make it better (sources in Sofa/doc/namespaces.odg).


[edit]

Proposal 01

File Sofa/doc/namespaces-proposal-01.cpp is a proposal for a new namespace architecture, corresponding to the following figure. It is simpler, and nested boxes do mean nested namespace. It is of course incomplete, but it might be a source of inspiration to clean up the current Sofa namespace architecture. Feel free to duplicate and edit the sources of all these files to continue the discussion.


image:namespaces-proposal-01.png

Remarks on the proposed namespace architecture:

  • Component::Abstract is really abstract. It contains the abstract classes used both for high-level and low-level modularity (basically, the type-less part of what is currently in Core). No data type is visible at this level. Nothing else is abstract.
  • Default could be a good name for data types which can be replaced by others. Some of them can not (such as reference frame in Context, which is not customizable) but they can also be used as custom types in components (such as DoF).
  • Splitting Graph in Graph and Graph::Tree suggests that another execution model, such as a network of independent objects communicating with signals could be implemented as Graph::Network and replace Tree in the figure.


[edit]

Proposal 02

File Sofa/doc/namespaces-proposal-02.cpp is another proposal, based on the following criteria:

  • separate "standardized" classes from implementation and auxiliary classes
  • group classes related to each other
  • all dependencies are one-way, to classes and namespaces defined before in the document, which is why Utils namespace is first, and Default is before Framework (as BaseContext needs it)
  • limit the number of namespaces
  • limit the recursion level of sub-namespaces (max 3 levels currently)
  • limit redundancies (for instance components type such as Mass or ForceField is often already mentioned in the class name)

The proposed namespaces are:

  • Utils: Utility helper classes that we need, but that are not the core of the plateform
    • Basic design patterns and data structures (Factory, Dispatcher, fixed_array, vector, ...)
    • IO: Image and Mesh I/O
    • GL: GL drawing helper classes, no actual visual models
    • System: OS-specific classes
      • Thread: Portable multithreading helper classes (thread, mutex, ...)
  • Default: Default data types for the most common cases (1D/2D/3D vectors, rigid frames)
  • Framework: Base standardized classes
    • ObjectModel: Specifies how pointer to generic objects and context are handled, as well as the basic functionnalities of all objects (name, fields, ...)
    • Abstract classes defining the 'high-level' sofa models (BehaviorModel, VisualModel, CollisionModel, BasicMapping)
    • ComponentModel: A composent is defined as an object with a specific role in a Sofa simulation.
    • SimulationModel: Classes handling the whole simulation (attaching components, scheduling computations)
  • Components: Implementation of components
    • Topology
    • CommonBehavior: Components used for most simulated bodies
    • Deformable: Components used only for deformable bodies
      • Springs, FEM, Tensor
    • Rigid: Components used only for rigid bodies
    • Fluid: Components used only for fluids
      • LennardJones, SPH, Euler
    • Collision: Collision related components
    • Penality: Penality-based interactions
    • LagrangianMultipliers: LM based interactions
    • UserInteraction: User interactions (RayModel, RayPickInteractor, ...)
    • GL: OpenGL visual models
  • Simulation: Simulation data structure and scheduling (implementation of Framework::SimulationModel)
    • Tree: Run-time model for a tree structure (current Components::Graph namespace)
      • XML: XML I/O classes
    • AutomateScheduler: Automate-based multithread scheduler (current Components::Thread namespace)
  • GUI: User Interfaces (no change)
    • QT
    • FLTK


[edit]

Proposal 03

A nice thing in Proposal 02 is that the namespace hierarchy is well detailed and makes possible to easily split the binaries in a lot of libraries.

However, I was not able to draw a clear figure of namespace dependencies as in proposal 1. This is not nessarily a problem, as long as we can clearly explain the structure.

Practical suggestions have been commited in Sofa/doc/namespaces-proposal-03.cpp

Retrieved from "http://www.sofa-framework.org/components/com_mambowiki/index.php/Namespaces"