part ii n.
Skip this Video
Loading SlideShow in 5 Seconds..
Part II PowerPoint Presentation

Part II

3 Views Download Presentation
Download Presentation

Part II

- - - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript

  1. 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 • 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 extensiblewithout 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 • 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)?