Class Categories and Domains
What is a class category?
In the design of a large software system such as Geant4, it is
essential to partition it into smaller logical units. This makes
the design well organized and easier to develop. Once the logical
units are defined independent to each other as much as possible,
they can be developed in parallel without serious interference.
In object-oriented analysis and design methodology by Grady Booch
, class categories are used to
create logical units. They are defined as "clusters of classes that
are themselves cohesive, but are loosely coupled relative to other
clusters." This means that a class category contains classes which
have a close relationship (for example, the "has-a" relation).
However, relationships between classes which belong to different
class categories are weak, i.e., only limitted classes of these
have "uses" relations. The class categories and their relations are
presented by a class category diagram. The class category diagram
designed for Geant4 is shown in the figure below. Each box in the
figure represents a class category, and a "uses" relation by a
straight line. The circle at an end of a straight line means the
class category which has this circle uses the other category.
The file organization of the Geant4 codes follows basically the
structure of this class cateogory. This User's Manual
is also organized according to class categories.
In the development and maintenance of Geant4, one software team
will be assigned to a class category. This team will have a
responsibility to develop and maintain all classes belonging to the
class category.
Class categories in Geant4
The following is a brief summary of the role of each class category
in Geant4.
Run and EventThese are categories related to the generation of events,
interfaces to event generators, and any secondary particles
produced. Their roles are principally to provide particles to be
tracked to the Tracking Management.
Tracking and TrackThese are categories related to propagating a particle by
analyzing the factors limiting the step and applying the relevant
physics processes. The important aspect of the design was that a
generalized Geant4 physics process (or interaction) could perform
actions, along a tracking step, either localized in space, or in
time, or distributed in space and time (and all the possible
combinations that could be built from these cases).
Geometry and Magnetic FieldThese categories manage the geometrical definition of a detector
(solid modeling) and the computation of distances to solids (also
in a magnetic field). The Geant4 geometry solid modeler is based on
the ISO STEP standard and it is fully compliant with it, in order
to allow in future the exchange of geometrical information with CAD
systems. A key feature of the Geant4 geometry is that the volume
definitions are independent of the solid representation. By this
abstract interface for the G4 solids, the tracking component works
identically for various representations. The treatment of the
propagation in the presence of fields has been provided within
specified accuracy. An OO design allows us to exchange different
numerical algorithms and/or different fields (not only B-field),
without affecting any other component of the toolkit.
Particle Definition and MatterThese two categories manage the the definition of materials and
particles.
PhysicsThis category manages all physics processes participating in the
interactions of particles in matter. The abstract interface of
physics processes allows multiple implementations of physics models
per interaction or per channel. Models can be selected by energy
range, particle type, material, etc. Data encapsulation and
polymorphism make it possible to give transparent access to the
cross sections (independently of the choice of reading from an
ascii file, or of interpolating from a tabulated set, or of
computing analytically from a formula). Electromagnetic and
hadronic physics were handled in a uniform way in such a design,
opening up the physics to the users.
Hits and DigitizationThese two categories manage the creation of hits and their use
for the digitization phase. The basic design and implementation of
the Hits and Digi had been realized, and also several prototypes,
test cases and scenarios had been developed before the
alpha-release. Volumes (not necessarily the ones used by the
tracking) are aggregated in sensitive detectors, while hits
collections represent the logical read out of the detector.
Different ways of creating and managing hits collections had been
delivered and tested, notably for both single hits and calorimetry
hits types. In all cases, hits collections had been successfully
stored into and retrieved from an Object Data Base Management
System.
VisualizationThis manages the visualization of solids, trajectories and hits,
and interacts with underlying graphical libraries (the
Visualization class category). The basic and most frequently used
graphics functionality had been implemented already by the
alpha-release. The OO design of the visualization component allowed
us to develop several drivers independently, such as for OpenGL, Qt and
OpenInventor (for X11 and Windows), DAWN, Postscript (via DAWN) and
VRML.
InterfacesThis category handles the production of the graphical user
interface (GUI) and the interactions with external software
(OODBMS, reconstruction etc.).