1. Maria Grazia Pia, INFN Genova Maria Grazia Pia INFN Genova, Italy Maria.Grazia.Pia@cern.ch Advanced software engineering in simulation development and applications

2. Maria Grazia Pia, INFN Genova The lesson learned... Courtesy of NASA/CXC/SAO

3. Maria Grazia Pia, INFN Genova Why software engineering in experimental physics? ] Software engineering is somewhat new to the HEP/astroparticle environment l other engineering branches more consolidated in this environment (mechanics, electronics, accelerators etc.) ] Benefits derive from a rigorous approach to software l the lesson can be learned from the world of software professionals! l even the most talented professionals need an organized environment to do cooperative work l advanced technology cannot be fully effective without an organizational framework Software Engineering plays a fundamental role in Geant4 Software process SPI User requirements OOAD Quality Assurance

4. Maria Grazia Pia, INFN Genova 25 years WWW Start SPS 1976 W and Z observed 1983 Start LEP 1989 WWW End LEP 2000

5. Maria Grazia Pia, INFN Genova Evolution of software ] 10 years mean in every domain (HW,SW,OS) l ~12 market cycles l 1 revolution l … and the trend towards a greater variability l …together with the evolution of requirements! ] Consequences l Today’s software will not be the final one l We should foresee change

6. Maria Grazia Pia, INFN Genova Object Oriented technology object model ] OO technology is built upon a sound engineering foundation, whose elements are called the object model ] The object model encompasses the principles of l abstraction l encapsulation l modularity l hierarchy l typing l concurrency l persistence brought together in a synergistic way Geant4 is based on Object Oriented technology

7. Maria Grazia Pia, INFN Genova The dream of any software… ] The Open Closed Principle Open for extension, Closed for modification l A software module that is designed to be reusable, maintainable and robust must be extensible without requiring modification l new features are added by adding new code, rather than by changing old, already working, code l The primary mechanisms behind are abstraction and polymorphism

8. Maria Grazia Pia, INFN Genova ADT (Interface) ] Abstract Data Type: it is a class that defines only methods, that must be implemented by derived classes ] No implementation constraint ] Depending on the implementation language, it can be l C++ pure virtual function l Java Interfaces ] High flexibility l Many different implementations derived from, and interchangeable with, the ADT ] Minimize the coupling between components l Each component can evolve independently l Reduce the chain of dependencies

9. Maria Grazia Pia, INFN Genova Large scale software ] Large scale software systems l Well defined and homogeneous structure (architecture) l Partition into manageable units (components) l Communication between components defined in a unique way (interfaces)

10. Maria Grazia Pia, INFN Genova The Toolkit approach A toolkit is a set of compatible components l each component is specialised for a specific functionality l each component can be refined independently to a great detail l components can be integrated at any degree of complexity l components can work together to handle inter-connected domains l it is easy to provide (and use) alternative components l the simulation application can be customised by the user according to his/her needs l maintenance and evolution - both of the components and of the user application - is greatly facilitated...but what is the price to pay? l the user is invested of a greater responsibility l he/she must critically evaluate and decide what he/she needs and wants to use

11. Maria Grazia Pia, INFN Genova OO technology in Geant4 è Open to evolution l extensibility, implementation of new models and algorithms without interfering with existing software l the user can extend the toolkit with his/her model and data OO design fundamental for distributed parallel approach l every part can be developed, refined, maintained independently l Problem domain decomposition and OOAD result into a unidirectional dependency of class categories Transparency decoupling from implementation Flexibility alternative models and implementations Interface to external software, without dependencies databases for persistency visualisation libraries tools for UI etc.

12. Maria Grazia Pia, INFN Genova The benefits of software engineering  The way to progress is to study and improve the way software is produced better technology only helps once the organizational framework is set there is evidence that going for new technology instead of improving the process can make things worst  The practices of SPI are well established, and have been applied in a large number of organizations for several years the results prove that the economical benefits are largely worth the investment early defect detection, time to market, and quality also improve, to the point that the return on investment for SPI is about 500% better softwarelower cost predictable resource allocationstime estimates The goal: producing better software at lower cost, within predictable resource allocations and time estimates, and happier users of the software  the people involved  the organization of the development process  the technology used Three key components:

13. Maria Grazia Pia, INFN Genova Software life-cycle Various phases:  User Requirements definition  Software Requirements definition  Architectural Design  Detailed Design and construction  Delivery to the user  Operations ] Frequently the tasks of different life cycle phases are performed somewhat in parallel to consider them disjoint in time is a simplification ] It is however important l to distinguish them logically l to identify documents that are the outcome of the various phases

14. Maria Grazia Pia, INFN Genova The software process ] Complex domain, evolving, with many types of models available; some examples of software process models are, for instance: ] The Waterfall model l analysis  design  coding l each phase starts following the completion of the previous one ] The Iterative Incremental Development model l cycles of analysis  design  coding, with incremental refinement It is the set of actions, tasks and procedures involved in producing a software system, through its life-cycle

15. Maria Grazia Pia, INFN Genova Software process standards  Capability Maturity Model l Software Engineering Institute  SPICE, ISO 15504 l the path to an international standard ] PSS-05, ECSS l ESA Development or Engineering processes: system and software requirements analysis, software design, software construction, software integration and unit testing, software maintenance Documentation Configuration and Change Management Problem Resolution Quality Assurance and Measurement System Testing, Acceptance and Releasing Verification and Validation Reviews, Audits and Joint Reviews Project tasks Management Improvement Process Process Establishment Human resource Management Infrastructure User Support, Distribution Primary life-cycle of software development Supporting life-cycle Management process Organizational life-cycle User-supplier processes etc. Process categories

16. Maria Grazia Pia, INFN Genova The software process in Geant4 ] Spiral-type life-cycle model adopted in most domains l both iterative and incremental a large international collaboration complex software mature categories in production and maintenance mode as well as categories in full development sensitive and mission-critical user applications product with a long life-timeOOADimplementation testing  Software Process Improvement understand, determine and propose procedures to software development and maintenance gradual process, life-cycle driven regular assessment, according to the ISO 15504 model A challenge:

17. Maria Grazia Pia, INFN Genova Requirements Requirements are the quantifiable and verifiable behaviours that a system must possess constraints that a system must work within User requirements l this phase defines the scope of the system Software requirements l this is the analysis phase of a software project l builds a model describing what the software has to do (not how to do it) ] Requirements are subject to evolution in the lifetime of a software project! è ability to cope with the evolution of the requirements

18. Maria Grazia Pia, INFN Genova UR: capture ] Elicitation through interviews and surveys l Useful to ensure that UR are complete and there is wide agreement ] Joint workshops with user groups ] Direct requests from users to WG coordinators or members ] Use cases Various methodologies adopted User requirements evolve …and we should be able to cope with their evolution! ] The requirements derive from many sources, in diverse domains l HEP, astrophysics, space, medical etc. ] Analysis of existing Monte Carlo codes ] Study of past and current experiments ] Prototyping l Useful especially if requirements are unclear or incomplete l Prototype based on tentative requirements, then explore what is really wanted

19. Maria Grazia Pia, INFN Genova OOAD – extensively used for the initial generation of design documents – where required, also for reverse engineering (Hadronic Physics, Standard EM, LowE EM initially) Booch methodology for OOAD The life-cycle model adopted for most domains in Geant4 is both iterative and incremental  especially relevant in the physics domain! Spiral approach – has been chosen as the common language for documentation of designs and internal design reviews – old documents in Booch notation are being progressively updated and converted to UML UML notation Rational Rose CASE tool

20. Maria Grazia Pia, INFN Genova Quality Assurance Commercial tools l Insure++, CodeWizard, Workshop etc. C++ coding guidelines l scripts to verify their applications automatically Code inspections l within working groups and across groups l Walk-throughs with specialized tools for monitoring against violations of coding rules Checks on run-time memory management Checks for violations of the dependency structure of categories Performance benchmarks and monitoring Testing Unit testing l in most cases down to class level granularity Integration testing l sets of logically connected classes Test-bench for each category l eg.: test-suite of 375 tests for hadronic physics parameterised models System testing l exercising all Geant4 functionalities in realistic set-ups Physics testing l comparisons with experimental data Extensive use of QA systems in Geant4 fundamental for a toolkit of wide public use

21. Maria Grazia Pia, INFN Genova Risk factors Maturity of the experimental community? l to appreciate the need of a new software environment l to work in a simulation environment based on advanced software engineering l to invest in learning new technologies