1 | <HTML> |
---|
2 | <HEAD> |
---|
3 | <META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1"> |
---|
4 | <META NAME="GENERATOR" CONTENT="Mozilla/4.04 [en] (X11; I; AIX 4.1) [Netscape]"> |
---|
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 | </HEAD> |
---|
11 | |
---|
12 | <BODY> |
---|
13 | <BR> |
---|
14 | |
---|
15 | <TABLE WIDTH="100%" > |
---|
16 | <TR> |
---|
17 | <TD> |
---|
18 | |
---|
19 | </A> |
---|
20 | <A HREF="index.html"> |
---|
21 | <IMG SRC="../../../../resources/html/IconsGIF/Contents.gif" ALT="Contents" HEIGHT=16 WIDTH=59></A> |
---|
22 | <A> |
---|
23 | <IMG SRC="../../../../resources/html/IconsGIF/PreviousGR.gif" ALT="Previous" HEIGHT=16 WIDTH=59></A> |
---|
24 | <A HREF="global.html"> |
---|
25 | <IMG SRC="../../../../resources/html/IconsGIF/Next.gif" ALT="Next" HEIGHT=16 WIDTH=59></A> |
---|
26 | </TD> |
---|
27 | |
---|
28 | <TD ALIGN=RIGHT> |
---|
29 | <FONT COLOR="#238E23"><FONT SIZE=-1> |
---|
30 | <B>Geant4 User's Guide</B></FONT></FONT> |
---|
31 | <BR><FONT COLOR="#238E23"><FONT SIZE=-1> |
---|
32 | <B>For Application Developers</B> </FONT></FONT> |
---|
33 | <BR><FONT COLOR="#238E23"><FONT SIZE=-1> |
---|
34 | <B>Toolkit Fundamentals</B> </FONT></FONT></TD> |
---|
35 | </TR> |
---|
36 | </TABLE> |
---|
37 | <P><BR> |
---|
38 | |
---|
39 | <CENTER> |
---|
40 | <FONT COLOR="#238E23"><FONT SIZE=+3> |
---|
41 | <B>3.1 Class Categories and Domains</B></FONT></FONT> |
---|
42 | </CENTER> |
---|
43 | <P><BR> |
---|
44 | |
---|
45 | <HR ALIGN="Center" SIZE="7%"> |
---|
46 | |
---|
47 | <P> |
---|
48 | <a name="3.1.1"> |
---|
49 | <H2>3.1.1 What is a class category?</H2></a> |
---|
50 | |
---|
51 | In the design of a large software system such as Geant4, it is essential to |
---|
52 | partition it into smaller logical units. This makes the design well organized |
---|
53 | and easier to develop. Once the logical units are defined independent to |
---|
54 | each other as much as possible, they can be developed in parallel without |
---|
55 | serious interference. |
---|
56 | <P> |
---|
57 | In object-oriented analysis and design methodology by Grady Booch <a href="#GBooch">[1]</a>, |
---|
58 | class categories are used to create logical units. They are defined as |
---|
59 | "clusters of classes that are themselves cohesive, but are loosely coupled |
---|
60 | relative to other clusters." This means that a class category contains |
---|
61 | classes which have a close relationship (for example, the "has-a" relation). |
---|
62 | However, relationships between classes which belong to different class |
---|
63 | categories are weak, i.e., only limitted classes of these have "uses" |
---|
64 | relations. The class categories and their relations are presented by |
---|
65 | a class category diagram. The class category diagram designed for |
---|
66 | Geant4 is shown in the figure below. Each box in the figure represents |
---|
67 | a class category, and a "uses" relation by a straight line. The circle |
---|
68 | at an end of a straight line means the class category which has this |
---|
69 | circle uses the other category. |
---|
70 | <P> |
---|
71 | <center> |
---|
72 | <IMG SRC="../../../../Welcome/IntroductionToGeant4/html/introductionToGeant4.src/classCategory.gif"> |
---|
73 | </center> |
---|
74 | <P> |
---|
75 | The file organization of the Geant4 codes follows basically the structure |
---|
76 | of this class cateogory. This <i>User's Manual</i> is also organized according |
---|
77 | to class categories. |
---|
78 | <P> |
---|
79 | In the development and maintenance of Geant4, one software team will |
---|
80 | be assigned to a class category. This team will have a responsibility to |
---|
81 | develop and maintain all classes belonging to the class category. |
---|
82 | <BR> |
---|
83 | <P> |
---|
84 | |
---|
85 | <HR> |
---|
86 | <a name="3.1.2"> |
---|
87 | <H2>3.1.2 Class categories in Geant4</H2></a> |
---|
88 | |
---|
89 | The following is a brief summary of the role of each class category in Geant4. |
---|
90 | <P> |
---|
91 | <ol> |
---|
92 | <li><b>Run and Event</b> |
---|
93 | <p> |
---|
94 | These are categories related to the generation of events, interfaces |
---|
95 | to event generators, and any secondary particles produced. Their roles |
---|
96 | are principally to provide particles to be tracked to the Tracking Management. |
---|
97 | <p> |
---|
98 | <li><b>Tracking and Track</b> |
---|
99 | <p> |
---|
100 | These are categories related to propagating a particle by analyzing the factors |
---|
101 | limiting the step and applying the relevant physics processes. The important |
---|
102 | aspect of the design was that a generalized Geant4 physics process (or |
---|
103 | interaction) could perform actions, along a tracking step, either localized |
---|
104 | in space, or in time, or distributed in space and time (and all the possible |
---|
105 | combinations that could be built from these cases). |
---|
106 | <p> |
---|
107 | <li><b>Geometry and Magnetic Field</b> |
---|
108 | <p> |
---|
109 | These categories manage the geometrical definition of a detector |
---|
110 | (solid modeling) and the computation of distances to solids |
---|
111 | (also in a magnetic field). The Geant4 geometry |
---|
112 | solid modeler is based on the ISO STEP standard and it is fully compliant |
---|
113 | with it, in order to allow in future the exchange of geometrical information with CAD |
---|
114 | systems. A key feature of the Geant4 geometry is that the volume definitions |
---|
115 | are independent of the solid representation. By this abstract interface |
---|
116 | for the G4 solids, the tracking component works identically for various |
---|
117 | representations. The treatment of the propagation in the presence of fields |
---|
118 | has been provided within specified accuracy. An OO design allows us to |
---|
119 | exchange different numerical algorithms and/or different fields (not only |
---|
120 | B-field), without affecting any other component of the toolkit. |
---|
121 | <p> |
---|
122 | <li><b>Particle Definition and Matter</b> |
---|
123 | <p> |
---|
124 | These two categories manage the the definition of materials and particles. |
---|
125 | <p> |
---|
126 | <li><b>Physics</b> |
---|
127 | <p> |
---|
128 | This category manages all physics processes participating in the interactions |
---|
129 | of particles in matter. The abstract interface of physics processes allows |
---|
130 | multiple implementations of physics models per interaction or per channel. |
---|
131 | Models can be selected by energy range, particle type, material, etc. Data |
---|
132 | encapsulation and polymorphism make it possible to give transparent access |
---|
133 | to the cross sections (independently of the choice of reading from an ascii |
---|
134 | file, or of interpolating from a tabulated set, or of computing analytically |
---|
135 | from a formula). Electromagnetic and hadronic physics were handled in a |
---|
136 | uniform way in such a design, opening up the physics to the users. |
---|
137 | <p> |
---|
138 | <li><b>Hits and Digitization</b> |
---|
139 | <p> |
---|
140 | These two categories manage the creation of hits and their use for |
---|
141 | the digitization phase. The basic design and implementation of the Hits |
---|
142 | and Digi had been realized, and also several prototypes, test cases and |
---|
143 | scenarios had been developed before the alpha-release. Volumes (not necessarily |
---|
144 | the ones used by the tracking) are aggregated in sensitive detectors, while |
---|
145 | hits collections represent the logical read out of the detector. Different |
---|
146 | ways of creating and managing hits collections had been delivered and tested, |
---|
147 | notably for both single hits and calorimetry hits types. In all cases, |
---|
148 | hits collections had been successfully stored into and retrieved from an |
---|
149 | Object Data Base Management System. |
---|
150 | <p> |
---|
151 | <li><b>Visualization</b> |
---|
152 | <p> |
---|
153 | This manages the visualization of solids, trajectories and hits, and |
---|
154 | interacts with underlying graphical libraries (the Visualization class |
---|
155 | category). The basic and most frequently used graphics functionality had |
---|
156 | been implemented already by the alpha-release. The OO design of the visualization |
---|
157 | component allowed us to develop several drivers independently, such as |
---|
158 | for OpenGL and OpenInventor (for X11 and Windows), DAWN, Postscript (via |
---|
159 | DAWN) and VRML. |
---|
160 | <p> |
---|
161 | <li><b>Interfaces</b> |
---|
162 | <p> |
---|
163 | This category handles the production of the graphical user interface |
---|
164 | (GUI) and the interactions with external software (OODBMS, reconstruction |
---|
165 | etc.). |
---|
166 | <p> |
---|
167 | </ol> |
---|
168 | <P> |
---|
169 | <hr> |
---|
170 | <p> |
---|
171 | <table> |
---|
172 | <tr><td valign=top><a name="GBooch">[1]</a> |
---|
173 | <td>Grady Booch, Object-Oriented Analysis and Design with Applications |
---|
174 | The Benjamin/Cummings Publishing Co. Inc, 1994, ISBN 0-8053-5340-2 |
---|
175 | </table> |
---|
176 | <P> |
---|
177 | <HR><A HREF="../../../../Authors/html/subjectsToAuthors.html"> |
---|
178 | <I>About the authors</A></I> |
---|
179 | </BODY> |
---|
180 | </HTML> |
---|