Paper | Title | Page |
---|---|---|
MOPPC087 | Tools and Rules to Encourage Quality for C/C++ Software | 303 |
|
||
Inspired by the success of the software improvement process for Java projects, in place since several years in the CERN accelerator controls group, it was agreed in 2011 to apply the same principles to the C/C++ software developed in the group, an initiative we call the Software Improvement Process for C/C++ software (SIP4C/C++). The objectives of the SIP4C/C++ initiative are: 1) agree on and establish best software quality practices, 2) choose tools for quality and 3) integrate these tools in the build process. After a year we have reached a number of concrete results, thanks to the collaboration between several involved projects, including: common build tool (based on GNU Make), which standardizes the way to build, test and release C/C++ binaries; unit testing with Google Test & Google Mock; continuous integration of C/C++ products with the existing CI server (Atlassian Bamboo); static code analysis (Coverity); generation of manifest file with dependency information; and runtime in-process metrics. This work presents the SIP4C/C++ initiative in more detail, summarizing our experience and the future plans. | ||
![]() |
Poster MOPPC087 [3.062 MB] | |
MOPPC143 | Plug-in Based Analysis Framework for LHC Post-Mortem Analysis | 446 |
|
||
Plug-in based software architectures are extensible, enforce modularity and allow several teams to work in parallel. But they have certain technical and organizational challenges, which we discuss in this paper. We gained our experience when developing the Post-Mortem Analysis (PMA) system, which is a mission-critical system for the Large Hadron Collider (LHC). We used a plugin-based architecture with a general-purpose analysis engine, for which physicists and equipment experts code plug-ins containing the analysis algorithms. We have over 45 analysis plug-ins developed by a dozen of domain experts. This paper focuses on the design challenges we faced in order to mitigate the risks of executing third-party code: assurance that even a badly written plug-in doesn't perturb the work of the overall application; plug-in execution control which allows to detect plug-in misbehavior and react; robust communication mechanism between plug-ins, diagnostics facilitation in case of plug-in failure; testing of the plug-ins before integration into the application, etc.
https://espace.cern.ch/be-dep/CO/DA/Services/Post-Mortem%20Analysis.aspx |
||
![]() |
Poster MOPPC143 [3.128 MB] | |