---

Computing Technical Design Report

3.2.1 An Object-Oriented Methodology

ATLAS has adopted an object-oriented development methodology, based primarily on the C++ programming language, but with some components implemented using FORTRAN and Java. A component-based model has been adopted, whereby applications are built up from collections of plug-compatible components based on a variety of configuration files. This capability is supported by a common framework that provides common data-processing support. This approach results in great flexibility in meeting the basic processing needs of the experiment and in responding to changing requirements throughout its lifetime. The heavy use of abstract interfaces allows for different implementations to be provided, supporting different persistency technologies, or optimized for the offline or high-level trigger environments.

A rather light-weight development process has been adopted, with emphasis on guidance and use of automated tools and extensive testing and validation rather than a rigid enforcement of strict protocols. Experience has shown that such an approach is better matched to the primarily physicist developer community of a high-energy physics experiment than a heavy-weight process. However, there are clearly potential disadvantages to such an approach in the areas of robustness and reliability, and more emphasis has been placed on the formal development process in core areas of the software.

3.2.2 Domain Decomposition

Several orthogonal domain decompositions have been identified. The first spans the ATLAS detector subsystems:

• Inner detector, which itself is comprised of the pixel detector, the silicon strip detector and the transition radiation tracker.
• Liquid argon calorimeter.
• Tile calorimeter.
• Muon spectrometer.

The primary data-processing activities that must be supported for all of these detector subsystems are:

• Event generation.
• Simulation.
• Pile-up.
• Digitization.
• Detector reconstruction.
• Combined reconstruction.
• Physics analysis.
• High-level triggering.
• Online monitoring.
• Calibration and alignment processing

Further domain decompositions cover the infrastructure needed to support the software development activity, and components that derive from the overall architectural vision. The overall structure is the following:

• Framework and Core Services . A common event processing framework has been adopted based on plug-compatible components and abstract interfaces. A variety of services such as scripting, detector geometry, and graphics have been developed in support of this framework. The overall architecture and common framework are described in Section 3.3 , "The Athena Framework". Particular core services are described in detail in Section 3.4 , "Data Access Model", Section 3.5 , "Detector Description" and Section 3.6 , "Graphics and Event Display"
• Event generators, simulation, pile-up and digitization . These are described in Section 3.8 , "Simulation"
• Event selection, reconstruction and physics analysis tools . These are described in Section 3.9 , "Event Selection and Reconstruction" and Section 3.10 , "Physics Analysis Tools"
• Calibration and alignment . The high-level requirements for sub-detector calibration and alignment are described in Section 3.7 , "Calibration and Alignment"
• Infrastructure . This provides the services that support the software development process including the source code repository, tools for building coherent releases of the software, and for testing and validating those releases, and documentation tools and services. This is described in detail in Section 3.14 , "Software Infrastructure"