Architecture Session Discussion Marseilles September 1999

1
Architecture SessionDiscussionMarseillesSeptemb
er 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
  followexamples 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?