Closed svlad-90 closed 3 years ago
DMA_Plantuml concept was developed to allow declaration of metadata for UML diagrams in the C++ source code: https://github.com/svlad-90/DLT-Message-Analyzer/pull/112 Now we will need to declare metadata for all major DMA classes and generate class diagrams out of that.
The scope of this task was reconsidered. No IController or sub-controller abstractions. No dependency registration. Only separation to a set of components with synchronous initialization. And ( what is also quite important ) a strict separation between the API and internal implementation.
Still, it will be a big step forward in the reduction of the complexity of the project, thus we are moving on. It would be possible to extend the scope of this task to cover dependencies, controllers, and sub-controllers later on. As part of the separate tasks. If needed.
Also, once the asynchronous part of the framework will be ready - we will be able to set up the asynchronous initialization. Once again, later on ☺
2 additional related PR-s: https://github.com/svlad-90/DLT-Message-Analyzer/pull/143 https://github.com/svlad-90/DLT-Message-Analyzer/pull/144
This task can finally be closed! ))
While creating a class diagram for https://github.com/svlad-90/DLT-Message-Analyzer/issues/51 is was identified, that the structure of classes becomes too coupled. Especially between "DMA base" and the other folders of the project. In order to reduce coupling, it is better to introduce the component abstraction.
CComponentRegistry class should be declared, which will register all components. The interface IComponent should be declared. The interface IController should be declared. Each root-level folder within the project should implement the IComponent interface. Each class, which is created within the specific component should implement IController and be registered as an internal controller. Each class, which comes from outside should implement IController and be registered as an external dependency. IComponent should be able to register multiple IController instances. IController should be able to register multiple IController instances as well, meaning that we might have sub-controllers ( and sub-sub-controllers, etc. ).
The component is responsible for the creation of its controllers and for the binding of all involved entities. The controller is responsible for the creation of its sub-controllers and for the binding of all involved entities.
IComponent has reference to all child IController-s. Each IController instance has references to its parent IController, parent IComponent ( if it is a sub-controller ), and child IController-s. Still, only CComponentRegistry has all the data. All IComponent and IController instances are getting dependency data from CComponentRegistry.
The final point would be to create a trace dump, which would represent the dependency map, which we could visualize in plantuml and analyze.