1 / 11

Forum for Architectural Guidelines and OO Design Patterns in HEP Software Development

This session aims to promote discussion and learning from the experience of building software in High Energy Physics. Topics include establishing guidelines for architects, documenting architectural design patterns, and documenting OO design patterns. Additionally, the session explores concerns related to frameworks, performance, migration, language choice, participation, and collaboration.

brandond
Download Presentation

Forum for Architectural Guidelines and OO Design Patterns in HEP Software Development

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. Architecture SessionDiscussionMarseillesSeptember 1999 John Harvey CERN / LHCb

  2. Technical Forum • Continue to promote discussion between interested parties • Continue to learn from others experience - successes and failures • Document this experience and make information widely available • Promote the notion that every software production unit should appoint an architect • All architects would be encouraged to participate in this forum

  3. Architectural Guidelines • Establish a set of guidelines for architects to follow…examples could be • components should be orthogonal to each other i.e. use of a particular histogramming component should not imply use of a particular visualisation component • underlying model for interfaces • suggestions on packaging i.e. physical design • document architectural design patterns that experiments are using • Important to agree to adhere to these guidelines to avoid problems that can be anticipated in advance

  4. OO Design Patterns • Document OO design patterns that have been used for building typical HEP algorithms e.g. track finding • Pull out experience from existing experiments such as BaBar, CDF, D0… • Document those patterns that did not work as well • Information needs to be well distilled • Spawn another technical forum? • Theme for a parallel session at CHEP?

  5. Java • Create a study group to assess the impact of Java • consolidate on experience we have gained so far e.g. JAS, WIRED... • assess suitability through realistic prototypes e.g. track reconstruction • study problems of mixing with other languages • study interfacing with other frameworks like GEANT4 • if outcome of studies positive, plan for HEP-wide Java library

  6. I) Framework Worries - seems to be too intricate - modularity is often not evident - serious issue is that modifications to code are difficult to make if they were not foreseen from the beginning Q1: What helps to give an architecture and a framework an understandable and easy to use interface? Q2: Why do people find making changes difficult?

  7. 2) Performance Worries - performance is a fundamental requirement for our data processing needs and the OO approach results in overheads which impairs performance Q1: Does an architecture force compromises to performance? Q2: Is there a trade-off between quality and maintainability on the one hand and performance on the other and if so what performance penalty is acceptable? Q3: Are there real examples which demonstrate penalties (or benefits) to performance?

  8. 3) Migration Worries - a change to OO does not allow an adiabatic change from existing software - all existing investment in FORTRAN code is lost - the best programming method should be used to execute a given task (e.g. languages close to mathematical reasoning for certain algorithms) Q1: How can an architecture/framework help in the migration to OO? Q2: Are there examples where this has been managed successfully?

  9. 4) Language Worries - C++ is heavy to use and leads to nasty problems which are difficult to debug (e.g. memory leaks) - several years experience are needed and initial developments have to be redone from scratch - the complexity of C++ is not needed and a mature C++ code is often difficult to understand Q1: Do these problems stem from an absence of architecture/framework? Q2: Is C++ an appropriate language, or is it a system programmer's language? Q3: Are we doing enough to investigate the use of other languages such as Java?

  10. 5) Participation Worries - many skills and too much time is spent on solving mundane problems such as those related to language, memory management, library management - only a restricted number of people can participate effectively Q1: Can an architecture help to identify areas where physicists contribute? Q2: What skills does an algorithm developer need to have to contribute effectively?

  11. 6) Collaboration Worries - reuse does not seem to work in practice Q1: How can an architectural vision help us to be more efficient in the production of code? Q2: Should we be trying to agree on integration standards and are we doing enough to develop standard HEP libraries that we can all share?

More Related