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

2. 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

3. 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.

4. 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

5. 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

6. 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

7. 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

8. 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

9. 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

10. 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”.

11. 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

12. 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

13. 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

14. 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

15. 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...)

16. An example of a class diagram

17. Another example of a class diagram

18. 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

19. 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

20. 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.

21. Geant4 class category diagram

22. 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

23. 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

24. 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)?