1 / 21

Maria Grazia Pia INFN Genova, Italy Maria.Grazia.Pia@cern.ch

Advanced software engineering in simulation development and applications. Maria Grazia Pia INFN Genova, Italy Maria.Grazia.Pia@cern.ch. The lesson learned. Courtesy of NASA/CXC/SAO. Why software engineering in experimental physics?.

vlora
Télécharger la présentation

Maria Grazia Pia INFN Genova, Italy Maria.Grazia.Pia@cern.ch

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


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

  2. The lesson learned... Courtesy of NASA/CXC/SAO

  3. Why software engineering in experimental physics? • Software engineering is somewhat new to the HEP/astroparticle 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 Software Engineering plays a fundamental role in Geant4 Software process SPI User requirements OOAD Quality Assurance

  4. WWW Start SPS 1976 W and Z observed 1983 Start LEP 1989 End LEP 2000 WWW 25 years

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

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

  7. The dream of any software… • 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

  8. 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 • C++ pure virtual function • Java Interfaces • High flexibility • Many different implementations derived from, and interchangeable with, the ADT • Minimize the coupling between components • Each component can evolve independently • Reduce the chain of dependencies

  9. Large scale software • Large scale software systems • Well defined and homogeneous structure (architecture) • Partition into manageable units (components) • Communication between components defined in a unique way (interfaces)

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

  11. OO technology in Geant4 OO design fundamental for distributed parallel approach • every part can be developed, refined, maintained independently • Problem domain decomposition and OOAD result into a unidirectional dependency of class categories • Open to evolution • extensibility, implementation of new models and algorithms without interfering with existing software • the user can extend the toolkit with his/her model and data • 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. The benefits of software engineering The goal: producing better software at lower cost, within predictable resource allocations and time estimates, and happier users of the software • the peopleinvolved • the organization of the development process • the technology used Three key components: • 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%

  13. 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 to distinguish them logically to identify documents that are the outcome of the various phases Software life-cycle

  14. The software process • Complex domain, evolving, with many types of models available; some examples of software process models are, for instance: • 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 It is the set of actions, tasks and procedures involved in producing a software system, through its life-cycle

  15. Capability Maturity Model Software Engineering Institute SPICE, ISO 15504 the path to an international standard PSS-05, ECSS 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 Software process standards Process categories Primary life-cycle of software development Supporting life-cycle Management process Organizational life-cycle User-supplier processes etc.

  16. OOAD testing implementation The software process in Geant4 • 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-time • Spiral-type life-cycle model adopted in most domains • both iterative and incremental A challenge: • 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

  17. Requirements Requirements are the quantifiable and verifiable • behavioursthat a system must possess • constraintsthat 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

  18. Elicitation through interviews and surveys 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 UR: capture Various methodologies adopted • Analysis of existing Monte Carlo codes • Study of past and current experiments • Prototyping • Useful especially if requirements are unclear or incomplete • Prototype based on tentative requirements, then explore what is really wanted • The requirements derive from many sources, in diverse domains • HEP, astrophysics, space, medical etc. User requirements evolve …and we should be able to cope with their evolution!

  19. OOAD Spiral approach The life-cycle model adopted for most domains in Geant4 is both iterative and incremental  especially relevant in the physics domain! Booch methodology for OOAD • 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 • extensively used for the initial generation of design documents • where required, also for reverse engineering • (Hadronic Physics, Standard EM, LowE EM initially) Rational Rose CASE tool

  20. Commercial tools Insure++, CodeWizard, Workshop etc. C++ coding guidelines scripts to verify their applications automatically Code inspections within working groups and across groups Walk-throughs with specialized tools for monitoring against violations of coding rules Checks on run-time memory management Checks forviolations of the dependency structure of categories Performance benchmarks and monitoring 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 Quality Assurance Extensive use of QA systems in Geant4 fundamental for a toolkit of wide public use

  21. Risk factors • Maturity of the experimental community? • to appreciate the need of a new software environment • to work in a simulation environment based on advanced software engineering • to invest in learning new technologies

More Related