1 | <!-- ******************************************************** --> |
---|
2 | <!-- --> |
---|
3 | <!-- [History] --> |
---|
4 | <!-- Converted to DocBook: Katsuya Amako, Aug-2006 --> |
---|
5 | <!-- Changed by: Katsuya Amako, 4-Aug-1998 --> |
---|
6 | <!-- Changed by: Michel MAIRE, 3-Aug-1998 --> |
---|
7 | <!-- Changed by: Katsuya Amako, 30-Nov-1998 --> |
---|
8 | <!-- Changed by: Dennis Wright, 20-Nov-2001 --> |
---|
9 | <!-- Proof read by: Joe Chuma, 28-Jun-1999 --> |
---|
10 | <!-- --> |
---|
11 | <!-- ******************************************************** --> |
---|
12 | |
---|
13 | |
---|
14 | <!-- ******************* Section (Level#1) ****************** --> |
---|
15 | <sect1 id="sect.ClassCate"> |
---|
16 | <title> |
---|
17 | Class Categories and Domains |
---|
18 | </title> |
---|
19 | |
---|
20 | <!-- ******************* Section (Level#2) ****************** --> |
---|
21 | <sect2 id="sect.ClassCate.WhatIsClassCate"> |
---|
22 | <title> |
---|
23 | What is a class category? |
---|
24 | </title> |
---|
25 | |
---|
26 | <para> |
---|
27 | In the design of a large software system such as Geant4, it is |
---|
28 | essential to partition it into smaller logical units. This makes |
---|
29 | the design well organized and easier to develop. Once the logical |
---|
30 | units are defined independent to each other as much as possible, |
---|
31 | they can be developed in parallel without serious interference. |
---|
32 | </para> |
---|
33 | |
---|
34 | <para> |
---|
35 | In object-oriented analysis and design methodology by Grady Booch |
---|
36 | <citation> |
---|
37 | <xref linkend="biblio.booch1994" endterm="biblio.booch1994.abbrev" /> |
---|
38 | </citation> |
---|
39 | , class categories are used to |
---|
40 | create logical units. They are defined as "clusters of classes that |
---|
41 | are themselves cohesive, but are loosely coupled relative to other |
---|
42 | clusters." This means that a class category contains classes which |
---|
43 | have a close relationship (for example, the "has-a" relation). |
---|
44 | However, relationships between classes which belong to different |
---|
45 | class categories are weak, i.e., only limitted classes of these |
---|
46 | have "uses" relations. The class categories and their relations are |
---|
47 | presented by a class category diagram. The class category diagram |
---|
48 | designed for Geant4 is shown in the figure below. Each box in the |
---|
49 | figure represents a class category, and a "uses" relation by a |
---|
50 | straight line. The circle at an end of a straight line means the |
---|
51 | class category which has this circle uses the other category. |
---|
52 | |
---|
53 | <figure id="fig.G4ClassCategory"> |
---|
54 | <title> |
---|
55 | Geant4 class categories |
---|
56 | </title> |
---|
57 | |
---|
58 | <mediaobject> |
---|
59 | <imageobject role="fo"> |
---|
60 | <imagedata fileref="./AllResources/Fundamentals/classCategory.jpg" |
---|
61 | format="JPG" contentwidth="7.0cm" align="center" /> |
---|
62 | </imageobject> |
---|
63 | <imageobject role="html"> |
---|
64 | <imagedata fileref="./AllResources/Fundamentals/classCategory.jpg" |
---|
65 | format="JPG" align="center" /> |
---|
66 | </imageobject> |
---|
67 | </mediaobject> |
---|
68 | </figure> |
---|
69 | </para> |
---|
70 | |
---|
71 | <para> |
---|
72 | The file organization of the Geant4 codes follows basically the |
---|
73 | structure of this class cateogory. This <emphasis>User's Manual</emphasis> |
---|
74 | is also organized according to class categories. |
---|
75 | </para> |
---|
76 | |
---|
77 | <para> |
---|
78 | In the development and maintenance of Geant4, one software team |
---|
79 | will be assigned to a class category. This team will have a |
---|
80 | responsibility to develop and maintain all classes belonging to the |
---|
81 | class category. |
---|
82 | </para> |
---|
83 | |
---|
84 | </sect2> |
---|
85 | |
---|
86 | |
---|
87 | <!-- ******************* Section (Level#2) ****************** --> |
---|
88 | <sect2 id="sect.ClassCate.ClassCateInGeant4"> |
---|
89 | <title> |
---|
90 | Class categories in Geant4 |
---|
91 | </title> |
---|
92 | |
---|
93 | <para> |
---|
94 | The following is a brief summary of the role of each class category |
---|
95 | in Geant4. |
---|
96 | |
---|
97 | <orderedlist spacing="compact"> |
---|
98 | <listitem><para><emphasis role="bold">Run and Event</emphasis> |
---|
99 | <para>These are categories related to the generation of events, |
---|
100 | interfaces to event generators, and any secondary particles |
---|
101 | produced. Their roles are principally to provide particles to be |
---|
102 | tracked to the Tracking Management. |
---|
103 | </para> |
---|
104 | </para></listitem> |
---|
105 | <listitem><para><emphasis role="bold">Tracking and Track</emphasis> |
---|
106 | <para>These are categories related to propagating a particle by |
---|
107 | analyzing the factors limiting the step and applying the relevant |
---|
108 | physics processes. The important aspect of the design was that a |
---|
109 | generalized Geant4 physics process (or interaction) could perform |
---|
110 | actions, along a tracking step, either localized in space, or in |
---|
111 | time, or distributed in space and time (and all the possible |
---|
112 | combinations that could be built from these cases). |
---|
113 | </para> |
---|
114 | </para></listitem> |
---|
115 | <listitem><para><emphasis role="bold">Geometry and Magnetic Field</emphasis> |
---|
116 | <para>These categories manage the geometrical definition of a detector |
---|
117 | (solid modeling) and the computation of distances to solids (also |
---|
118 | in a magnetic field). The Geant4 geometry solid modeler is based on |
---|
119 | the ISO STEP standard and it is fully compliant with it, in order |
---|
120 | to allow in future the exchange of geometrical information with CAD |
---|
121 | systems. A key feature of the Geant4 geometry is that the volume |
---|
122 | definitions are independent of the solid representation. By this |
---|
123 | abstract interface for the G4 solids, the tracking component works |
---|
124 | identically for various representations. The treatment of the |
---|
125 | propagation in the presence of fields has been provided within |
---|
126 | specified accuracy. An OO design allows us to exchange different |
---|
127 | numerical algorithms and/or different fields (not only B-field), |
---|
128 | without affecting any other component of the toolkit. |
---|
129 | </para> |
---|
130 | </para></listitem> |
---|
131 | <listitem><para><emphasis role="bold">Particle Definition and Matter</emphasis> |
---|
132 | <para>These two categories manage the the definition of materials and |
---|
133 | particles. |
---|
134 | </para> |
---|
135 | </para></listitem> |
---|
136 | <listitem><para><emphasis role="bold">Physics</emphasis> |
---|
137 | <para>This category manages all physics processes participating in the |
---|
138 | interactions of particles in matter. The abstract interface of |
---|
139 | physics processes allows multiple implementations of physics models |
---|
140 | per interaction or per channel. Models can be selected by energy |
---|
141 | range, particle type, material, etc. Data encapsulation and |
---|
142 | polymorphism make it possible to give transparent access to the |
---|
143 | cross sections (independently of the choice of reading from an |
---|
144 | ascii file, or of interpolating from a tabulated set, or of |
---|
145 | computing analytically from a formula). Electromagnetic and |
---|
146 | hadronic physics were handled in a uniform way in such a design, |
---|
147 | opening up the physics to the users. |
---|
148 | </para> |
---|
149 | </para></listitem> |
---|
150 | <listitem><para><emphasis role="bold">Hits and Digitization</emphasis> |
---|
151 | <para>These two categories manage the creation of hits and their use |
---|
152 | for the digitization phase. The basic design and implementation of |
---|
153 | the Hits and Digi had been realized, and also several prototypes, |
---|
154 | test cases and scenarios had been developed before the |
---|
155 | alpha-release. Volumes (not necessarily the ones used by the |
---|
156 | tracking) are aggregated in sensitive detectors, while hits |
---|
157 | collections represent the logical read out of the detector. |
---|
158 | Different ways of creating and managing hits collections had been |
---|
159 | delivered and tested, notably for both single hits and calorimetry |
---|
160 | hits types. In all cases, hits collections had been successfully |
---|
161 | stored into and retrieved from an Object Data Base Management |
---|
162 | System. |
---|
163 | </para> |
---|
164 | </para></listitem> |
---|
165 | <listitem><para><emphasis role="bold">Visualization</emphasis> |
---|
166 | <para>This manages the visualization of solids, trajectories and hits, |
---|
167 | and interacts with underlying graphical libraries (the |
---|
168 | Visualization class category). The basic and most frequently used |
---|
169 | graphics functionality had been implemented already by the |
---|
170 | alpha-release. The OO design of the visualization component allowed |
---|
171 | us to develop several drivers independently, such as for OpenGL, Qt and |
---|
172 | OpenInventor (for X11 and Windows), DAWN, Postscript (via DAWN) and |
---|
173 | VRML. |
---|
174 | </para> |
---|
175 | </para></listitem> |
---|
176 | <listitem><para><emphasis role="bold">Interfaces</emphasis> |
---|
177 | <para>This category handles the production of the graphical user |
---|
178 | interface (GUI) and the interactions with external software |
---|
179 | (OODBMS, reconstruction etc.). |
---|
180 | </para> |
---|
181 | </para></listitem> |
---|
182 | </orderedlist> |
---|
183 | </para> |
---|
184 | |
---|
185 | |
---|
186 | </sect2> |
---|
187 | </sect1> |
---|