Software engineering Geant4 rigorous approach to software Part II Software engineering Geant4 rigorous approach to software

Part II: outline Motivations for software engineering in HEP The software process Components of the software life-cycle Object Oriented technologies Brief digression on basic OO concepts OOAD in Geant4 Quality Assurance Standards

Why software engineering in HEP? Software engineering is somewhat new to the HEP environment other engineering branches more consolidated in this environment (mechanics, electronics, accelerators etc.) Benefits derive from a rigorous approach to software the lesson can be learned from the world of software professionals! even the most talented professionals need an organized environment to do cooperative work advanced technology cannot be fully effective without an organizational framework The question I am always asked at this point: Is there any room for creativity? Yes! Also in other disciplines a rigorous approach can be combined with creativity: architecture, music etc.

Software engineering strategies in Geant4 Software engineering plays a fundamental role in Geant4 The software process Requirements Analysis and Design Object Oriented methodologies Quality Assurance Testing Physics validation

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

The software process in Geant4 Based on the Booch methodology choice resulting from a thorough study of various models critically evaluated and adapted to the Geant4 peculiar environment Spiral-type software process: cycles of incremental analysis design  implementation  testing iterations

Requirements User requirements Software requirements Requirements are the quantifiable and verifiable behaviours that a system must possess constraints that a system must work within User requirements this phase defines the scope of the system Software requirements this is the analysis phase of a software project 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

Geant4 requirements Geant4 has adopted a rigorous approach to requirements user requirements collected from the user communities in the initial phase coded according the PSS-05 standard Geant4 User Requirements Document continuously updated

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

What is an object? G. Booch (in OOAD with Applications): “An object has state, behaviour and identity; the structure and behaviour of similar objects are defined in their common class”.

Some fundamental concepts in OOD -1 The Open Closed Principle Open for extension, Closed for modification A software module that is designed to be reusable, maintainable and robust must be extensible without requiring modification new features are added by adding new code, rather than by changing old, already working, code The primary mechanisms behind are abstraction and polymorphism The Liskov Substitution Principle Functions that use pointers or references to base classes must be able to use objects of derived classes without knowing it Derived types must be substitutable for their base types It is an important feature for conforming to the OCP

Some fundamental concepts in OOD -2 The Dependency Inversion Principle Modules that implement high level policy should not depend on the modules that implement low level details Both high level policy and low level details should depend on abstractions This ensures reusability and maintainability The interdependence makes a design rigid, fragile and immobile: a single change triggers a cascade of changes in dependent modules The Interface Segregation Principle Clients should not be forced to depend on interfaces that they do not use Polluted interfaces generate unnecessary couplings We want to separate interfaces whenever possible to avoid the disadvantages of couplings

Analysis Webster definitions: separation or breaking up of a whole into its fundamental elements or component parts a detailed examination of anything complex the practice of proving a mathematical proposition by assuming the result and reasoning back to the data or already established principles In the software world: it is the decomposition of a problem into its constituent parts it is accomplished by beginning with a set of stated requirements, and reasoning back from those requirements to a set of established software components and structures OOA is the act of determining the abstractions that underlie the requirements In OOA the components are objects and their collaborations

Design Design embodies the set of decisions that determine how the components will look like In OOD typically class inheritance and composition hierarchies are among the decisions OOA and OOD cooperate synergically they are best done concurrently The output of OOAD is a set of class and object diagrams, showing the static structure the collaborations

UML: Unified Modeling Language UML has the goal to become a common language for creating models of OO software UML represents a unification of the concepts and notations previously in use (Booch, OMT) UML is comprised of two major components: a Meta-model a notation UML has a standard data representation, that is called the Meta-model the Meta-Model is a description of UML in UML it describes the objects, attributes and relationships necessary to represents the concepts of UML within a software application UML notation is comprised of two major subdivisions: a notation for modeling the static elements of a design (classes, attributes, relationships...) a notation for modeling the dynamic elements of a design (objects, messages, finite state machines...)

An example of a class diagram

Another example of a class diagram

C++ OO technology and C++ are not equivalent! OO methodologies can be implemented in a variety of languages, not only in C++ One can write procedural code in C++, that is not object oriented C++ provides many features that make it suitable for OO implementations of large scale software projects An overview of C++ language features and OO technology is beyond the scope of these lectures Many textbooks, courses and online material are available as learning aids; a few references: I. Pohl, OO programming using C++ S. B. Lippman, J. Lajoie, C++ primer B. Stroustrup, The C++ programming language G. Booch, OO analysis and design R. Martin, Designing OO C++ applications using the Booch method

OOAD in Geant4 Geant4 fully exploits the power of OOAD The basic principles of OOD described in the previous transparencies are applied in Geant4 They ensure a software that is reusable, maintainable, robust, extensible OOAD is fundamental in Geant4 for a distributed parallel approach every part can be developed, refined, maintained independently Problem domain decomposition and OOAD result in a unidirectional dependency of class categories Booch/UML notations CASE Tool: Rational Rose

Benefits from OO technology The OO technology provides various benefits to Geant4 Transparency decoupling from implementation Flexibility alternative models and implementations Openness to evolution extensibility, implementation of new models and algorithms without interfering with existing software possibility for the user to extend the toolkit with his/her model and data Interface to external software, without dependencies databases for persistency visualisation libraries tools for UI etc.

Geant4 class category diagram

Quality Assurance Extensive use of Quality Assurance systems fundamental for a toolkit of wide public use Commercial tools Insure++, Logiscope etc. C++ coding guidelines scripts to verify their applications automatically Code inspections within working groups and across groups Testing Unit testing in most cases down to class level granularity Integration testing sets of logically connected classes Test-bench for each category eg.: test-suite of 375 tests for hadronic physics parameterised models System testing exercising all Geant4 functionalities in realistic set-ups Physics testing comparisons with experimental data Performance Benchmarks

Standards Geant4 is based on standards (ISO and de facto) STEP ODMG engineering and CAD systems ODMG RD45 OpenGL e VRML for graphics CVS for code management C++ as programming language UML as modeling language

System of Units Geant4 is independent from any system of units All numerical quantities are expressed with their units explicitly The user is not constrained to using any specific system of units in his/her application Have you heard of the “incident” with NASA’s Mars Climate Orbiter ($125 million)?