Maf3 - Part 1
0 likes440 views
The document outlines the components and functionality of the maf3 framework, detailing its modular architecture, core libraries, and quality assurance testing mechanisms. It describes key modules, such as mafcore for object management and mafqa for testing and performance monitoring, and their respective functionalities. Additionally, it highlights the automated QA script system designed to ensure coding conventions are met, which involves source generation, script execution, and result publication.
Maf3 - Part 1
- 1. Foundation Libraries Paolo Quadrani – Daniele Giunchi – Roberto Mucci
- 2. Dynamic Libraries’ list VXL/VNL (used by mafResources) Qxmlrpc (used by mafEventBus) Qt (used by mafCore) VTK (v5.4.2) (used by VTK Plugin Lib) ITK (v3.16)
- 3. VXL/VNL Support for multidimensional matrices Support for matrices calculations and serialization/de-serialization License : BSD-like /
- 4. Qxmlrpc (Qt based, LGPL) Library used for remote connection using XMLRPC protocol based on QtNetwork.
- 5. Cross platform set of libraries Unicode string Signal/slot communication mechanism Object’s properties accessible also from object’s ancestor Object introspection through the Meta Object QtCreator: Cross platform IDE http:// qt.nokia.com/downloads Qt: License LGPL
- 8. Main Concepts Modular Architecture Used pattern: Strategy Façade Factory Composition Memento Singleton Visitor
- 9. mafCore Module containing interface classes and basic objects. mafDefinitions.h contains All the references to Qt All the symbols used in all modules mafContract.h contains All the macros needed to define the design by contract implementation (REQUIRE, ISVALID, ENSURE)
- 10. Basic Objects mafObjectBase Allocable through the object factory. Enabled to send/receive events to/from the event bus. Enabled to be traversed by a visitor algorithm. mafObject Is able to generate its memento which store the object state.
- 11. Singletons These classes have only one instance and can be accessed from all the framework: mafObjectFactory Create an instance of a MAF object starting from a string or a typename mafIdProvider Create unique ID for the created object or event. mafObjectRegistry Keeps track of live objects mafMessageHandler Redefine the handler of (debug, warning…) messages
- 12. Core objects functionalities mafMemento mafContainerInterface, mafContainer<T> mafVisitor mafMonitor mafLogger
- 13. mafMemento Allow to store object’s state Access to its internal variables is enabled only to the generator object. Used for the Serialization/De-serialization Undo/Redo
- 14. mafContainerInterface mafContainer<T> Container for external data types Allow the replication of the public interface of the contained object It behaves like a proxy for the contained object It can be used as gate toward external framework or libraries.
- 15. mafVisitor This class implement the visitor pattern and in the same time the strategy one Allow to execute an algorithm over the visited object The behavior can be customized through sub-classing it Usage: have a tree structure, iterate over it visit each object with a mafVisitor.
- 16. mafMonitor Implemented following the strategy pattern Allow to monitor system resources like RAM, HDD space availability, CPU usage… Used actually into the mafQA module to monitor the RAM and HDD usage.
- 17. mafLogger Implemented following the strategy pattern. Logger types implemented are: mafLoggerConsole mafLoggerFile mafLoggerBuffer
- 18. HowTos How to register and create object: mafRegisterObject(mafCore::mafObject); mafObjectBase*obj=mafNEWFromString("mafCore::mafObject"); How to create an id with Id Provider: mafId myId = m_IdProvider->createNewId("TestObjectId"); How to create/destroy a singleton: m_ObjectRegistry = mafObjectRegistry::instance(); m_ObjectRegistry->ShutDown();
- 20. Test Suite Engine Module based on QTest testing mechanism. Implements the execution of multiple unit test . Enable the benchmark functionality to monitor performance issues on code. Each test suite module contains more unit test and generate only one executable.
- 21. mafQAManager mafQAManager represents the Facade class of the MAF3 QA Module. It supplies functionality to: Monitor: time performance memory usage storage usage validity of plug-ins Execute external script
- 22. mafQAManager API Some API of the class mafQAManager: time performance: void profilerStart(const mafString &comment = ""); void profilerStop(); RAM usage: void enableMemoryMonitor(bool enable = true); Storage usage: void enableStorageMonitor(bool enable = true); validity of plug-ins: bool pluginValidate(const mafString &plugin);
- 23. Usage example Code to monitor time performance: // Initialize the profiler m_QAManager->profilerInit(); // Start the profiler with a string comment. m_QAManager->profilerStart(“Example"); // snippet of code to be monitored. long int m = 0; int i = 0; for(; i < 5000000; i++) { m = calcToProfile(m); } // Stop the profiler to get the timing information m_QAManager->profilerStop(); // Show the results on console. m_QAManager->profilerViewResultsOnConsole(); Starting D:\Devel\MAF3\Install\bin\mafQATest.exe... ********* Start testing of mafQAManagerTest ********* Config: Using QTest library 4.6.2, Qt 4.6.2 PASS : mafQAManagerTest::initTestCase() PASS : mafQAManagerTest::mafQAManagerAllocationTest() QDEBUG : mafQAManagerTest::profilerTest() "Function Name: mafQAManager run number 1 Location: mafQAManager run number 1 Notes: Example Call Number: 1 mSecs: 31 PASS : mafQAManagerTest::profilerTest() PASS : mafQAManagerTest::runScriptTest() PASS : mafQAManagerTest::cleanupTestCase() Totals: 5 passed, 0 failed, 0 skipped ********* Finished testing of mafQAManagerTest ********* CONSOLE OUTPUT
- 24. mafQA scripts MAF3 QA System includes a series of scripts written in python that permit to compose rules that must be respected by the MAF3 coding convention . This automatic system can be invoked by external service (like Parabuild).
- 25. mafQA scripts (2) The system is composed by several components and it works as a state machine. To complete the entire cycle the needed steps are the following: Source Generation (ex: doxygen output) Generate python scripts Execute generated scripts Publish the results
- 26. 1. Source Generation Each rule needs a source directory in which extracts information from a specified file type. At present there are these source information used by scripts: Doxygen xml output MAF3 source directory.
- 27. 2. Generate python scripts Rules are contained into Groups. Rules are python scripts and define: An input configuration file An XSLT to format the output GeneratorQA.py create one script for each group which will process the rules in it.
- 28. 3. Execute generated scripts ScriptsLauncher.py fulfils the work of executing each generated script. The results are written xml files ready to be formatted with a style defined in XSLT files..
- 29. 4. Publish the results XSLT are applied to XML for HTML files generation. On Parabuild the QA check is performed in Linux and Windows Servers, but only on Linux one the results are published.
- 30. Implemented rules SourcesCommentRule: Check that comments inside sources are present in a range from 20% up to 40%. ClassDocumentationRule: Check that documentation respect the naming convention. ClassMethodsDocumentationRule: Check that methods documentation respect the naming convention. FileNamingRule: Check that filename respect the naming convention. CoverageTestRule: Check the ratio between classes with Test and all maf3 Classes. FunctionNamingRule: Check that functions respect the naming convention. VariableNamingRule: Check that variables respect the naming convention. GuideCreatorRule: Quote parts of the tests to generate a maf3 brief guide.
- 31. QA Scripts results page http://qa.openmaf.org/
Editor's Notes
- #22: - Allow to open the URL for the specific application and allows the user compile a poll (??) -Allow retrieving the application version and other related build information.
- #25: Therefore at each build session, there will be a new generation of automated scripts for the QA.
- #26: The entire cycle terminates with the publishing of the QA results over internet,
- #27: Most part of QA scripts takes advantage from doxygen XML output that is created as first step. A script can also base its execution over another kind of source directory like code directory, and even extract information discriminating files using regular-expression
- #28: Each RuleGroup and each Rule inside a rulegroup need an initialization file in order to handle parameters. Generally the initialization file of a RuleGroup contain the file type checked and the source directory, while the rule initialization file contains parameter which depends by the rule itself.
- #29: Results are subdivided into a number of files equals to the total number of rule.