maria grazia pia, infn genova 1 part ii software engineering geant4 rigorous approach to software
TRANSCRIPT
Maria Grazia Pia, INFN Genova 1
Part II
Software engineering Geant4
rigorous approach to software
Maria Grazia Pia, INFN Genova 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
Maria Grazia Pia, INFN Genova 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.
Maria Grazia Pia, INFN Genova 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
Maria Grazia Pia, INFN Genova 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
Maria Grazia Pia, INFN Genova 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
Maria Grazia Pia, INFN Genova 7
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
Maria Grazia Pia, INFN Genova 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
Maria Grazia Pia, INFN Genova 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
Maria Grazia Pia, INFN Genova 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”.
Maria Grazia Pia, INFN Genova 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
Maria Grazia Pia, INFN Genova 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
Maria Grazia Pia, INFN Genova 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
Maria Grazia Pia, INFN Genova 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
Maria Grazia Pia, INFN Genova 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...)
Maria Grazia Pia, INFN Genova 16
An example of a class diagram
Maria Grazia Pia, INFN Genova 17
Another example of a class diagram
Maria Grazia Pia, INFN Genova 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
Maria Grazia Pia, INFN Genova 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
Maria Grazia Pia, INFN Genova 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.
Maria Grazia Pia, INFN Genova 21
Geant4 class category diagram
Maria Grazia Pia, INFN Genova 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
Maria Grazia Pia, INFN Genova 23
Standards
Geant4 is based on standards (ISO and de facto)
STEP engineering and CAD systems
ODMG RD45
OpenGL e VRML for graphics
CVS for code management
C++ as programming language
UML as modeling language
Maria Grazia Pia, INFN Genova 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)?