The new software

• Introduction
• Brief history
• Software architectures
• ATLAS software process
• Domains

What is the new software?

• OO design and implementation, requires a language change
• ASP, engineering standards for construction and maintenance
  • systematic management
  • documentation
  • peer review
  • iterative process

Why replace the current software?

Not maintainable with reasonable effort, over 20 years and 160 institutes.

Probably true for any HEP-traditional software, not just SLUG/DICE.

Brief history November 1992 study group formed
Then learning and prototyping
R.Brun (CN) gets interested and proposes three R&D projects

• framework
• simulation
• database

These become

• RD41 (MOOSE) June 1994
• RD44 (GEANT4) November 1994
• RD45 December 1994

December 1996 CTP completed, based on OO and ASP
June 1997 CTP approved
June 1997 ATLAS software workshop in Edinburgh

Software architectures Where are the routines?
Where are the data?
FORTRAN
The routines are all at the same level.
The data in named COMMON (F4, 1970's), then in blank COMMON (HYDRA, BOS, ZEBRA).
Some design, documentation and access control with ADAMO (RDB ideas).
No serious use of F77 (STRUCTURE, RECORD).
The data form a single tree-structured entity.
The routines act on the data, but have no organization.

OO
An object

• has internal state
• offers services to query and/or alter the state

ECAL state

• detector description
• current digis
• reconstructed clusters
• ...

ECAL services

• addDigi(digi)
• findClusters
• ...

Sphere

• centre (position vector)
• radius
• setRadius
• move
• expand

Practicality

• state is data (basic values or references)
• services are routines (functions)

Both data and routines can be

• public (interface)
• private to the object itself

Close association of routines and data and hiding non-interface features give
encapsulation
maintainability

ATLAS software process

Three main deliverables

• requirements
• design
• coding

Coding is more lightweight than it was. Being physicists, we prototyped code, and then found the importance of design. Finally, requirements!

We need input from you.

A deliverable is a set of documents. It is reviewed by a small ad-hoc group

• check against input
• check against standards
• assess quality

All deliverables evolve; their status is examined in each cycle, four times/year. Other reviewable documents include the ASP itself and the design and coding standards.

Domains

• Control
• Visualisation
• Event
• Geometry
• Magnetic Field
• Inner Detector
• Calorimetry
• Muon Detector
• Reconstruction
• Simulation
• Trigger

Calibration? Analysis? ...?