CMS TN/95-139

An Object Oriented Approach to CMS Reconstruction Softwarea

CMS and RD41 Collaborations

V.Innocente, M.Marino
CERN, Geneva, Switzerland

CMS has joined several R&D projects to test if and how Object Orientation can be
applied to its software. We describe here how a prototype of the reconstruction software
for the CMS inner tracker has been used to study Object Oriented Analysis and Design.

1 CMS software requirements

The CMS [1] software requirements and computing resources will far exceed those
of any existing high energy physics experiment. The size of the collaboration will
also set special requirements on the organization of the software activities.
Software will be written by a large number of geographically dispersed physicists
and software specialists. Its lifespan will exceed any of the preceding experiments -
it is likely that the original designers will leave the experiment while the software is
still in use. The software should cope with the changes in the detector, in computing
technologies and in user requirements - Such changes will be inevitable during the
long lifetime of the experiment. Therefore, software has to be designed keeping in
mind not only performance but also exibility, maintainability, quality assurance
and automatic documentation.
To reduce the software complexity, and increase the probability that the code
can be learned, maintained, ported, modied, and extended more easily, software
systems has to be built out of loosely coupled components with a well dened
behavior, and a completely hidden implementation. This will localize any required
change in a single component or, at worse, in its close collaborators. Object Oriented
(OO) technologies are a promising way to achieve such a result.

2 OO R&D in CMS
A R&D eort is being produced to test if and how Object Orientation can be applied
to CMS software. In particular we have launched a project, in the framework of
RD41 [2] (MOOSE), aimed at developing a prototype of the reconstruction software
for the CMS inner tracker using OO technologies.
presented at
a CHEP conference, September 1995, Rio de Janeiro, Brasil
1
2.1 The choice of the method and of the language
The analysis and design of complex software requires the use of well dened methods
to ensure consistency, traceability and uniformity.
We have evaluated several OO methods [3] to understand their applicability
to HEP software problems. We have found that a \Responsibility Driven Ap-
proach" [4], which permits to obtain a model with distributed responsibilities among
the various collaborating objects, is the most suited to the problem of HEP event
reconstruction.
Among the various methods which support such an approach, we have chosen
the Booch Method [5] to base our prototype upon because it:
 is complete, from analysis to code maintenance;
 supports both a distributed responsibility approach and a data driven ap-
proach;
 does not impose a strict procedure in the use of its components;

 has clear syntax and unambiguous semantics;

 is widely used and seems that it will be supported long into the future;

 is implemented by a performant CASE-tool (Rational Rose/C++).

We have also decided to use C++ as programming language because it is the
only OO language which today satises all the following requirements which we
believe are essential for a language to be used to develop the CMS software:
 it will be supported and further developed in a standardized way;
 it is widely used inside and outside HEP community;
 it has extensive program (class) libraries available;

 it is available, as native compiler, on all computer platforms used in CMS;

 it is supported by symbolic debuggers and CASE tools;

 it permits easy interface and data sharing with C or FORTRAN code;

 it is supported by commercial applications likely to be used in CMS for GUI,

visualization, database management etc.
3 The CMS inner tracker prototype: Analysis & Design
We chose to reconstruct tracks in the CMS inner tracker making use of a \track
following method" [6]: First a candidate track is built from few hitsbon the detec-
tor units farthest away from the interaction vertex. This candidate track is then
bin our case a hit is a cluster of contiguous strips or pixels which red when a particle crossed
the detector.
2
 Current Detector Unit

Next Layer
r Vertex
z
Figure 1: A simplied r ? z view of the CMS inner tracker: A candidate track,
built from two hits and the vertex, is extrapolated from the current detector to
next layer where compatible hits are searched for in an interval dened by the
extrapolation error.

extrapolated into the \next layer" of detector units in the direction of the vertex
and hits lying inside an error interval around the crossing point are selected (see
gure 1). The candidate track is followed till the detector units closest to the vertex
and, if it passes some quality criteria (2, number of hits etc.), it is accepted. We
chose this reconstruction method because is well known and broadly used in HEP.
Therefore it does not require any \physics analysis" eort which would distract
from the software modeling.
3.1 Dynamic model
We started to build a model of the reconstruction software describing the set of
scenarios (use cases) that fully realize the system functionalities. Each scenario
depicts a task to be performed by the system. As we walked through each scenario,
we \identied the objects that participate in the scenario, the responsibility of each
object, and how those objects collaborate with other objects, in terms of operations
each invokes upon the other" [5].
3.2 The main scenario
The main scenario describes how to nd a hit on the following layer:
 The next layer is built out of all neighbors of the current detector unit which
are reachable by the candidate track;
 For each detector unit in next layer a set of compatible hits (clusters in our
model) is formed with all hits which lie in an error interval around the crossing
3
 point between the candidate track and the detector unit itself;
 the best hit (the one which minimize the track 2 ) is added to the candidate
track;
 If no good hits are found, an ineciency is assumed and hits are searched for
on the next second layer;
 If even the search for good hits on the next second layer fails, the pattern
recognition starts again from a new hit (if any) on the current detector unit.
This scenario is actually split in two primary scenarios which describe the main
path:
 get next detector unit to process,
 good hit found in current detector unit;
and three secondary scenarios describing the other alternatives:
 good hit found on another detector unit of the current layer,
 good hit found in the second next layer,
 no good hit found.

Retrieve next detector unit

from the next layer and
clusters compatible with the theInnerTracker
candidate track.
5: InterceptTrack
theCandidate 4: SetCompatibleClusters (VTrajectory &)
Track (VTrajectory &)
G

1: NextLayer (VTrajectory &)

P thePossibleDUs
7: NextDetUn
(TListOfCluster *&) 3: NextLayer (VTrajectory &,
VDetectorUnit &)
G

theTracking
Region
2: NextLayer 6: Cross
(VTrajectory &) (VTrajectory &)

8: NextDetUn ( ) F
theCurrentDetector
P
Unit
theCurrent VSurface
Layer

Figure 2: Object Interaction Diagram describing the scenario \Get next detector
unit to process"

Figure 2 shows the Object Interaction Diagram for the \get next detector unit
to process" scenario.
4
 TLayer
(from CMS Detector Model)
{n} VMainComponent
TTrackingRegion (from CMS Detector Model)
0..n AddLayer( )
Instance( )
1 RemoveLayer( ) Update 1
fCurrentDetUn : VDetectorUnit 1
fgInstance : TTrackingRegion
| Next2ndLayer( )
| NextDetUn( ) A
{1}

VFitStrategy
(from CSM Fit Strategies)
1 F

A
1 1

fAdoptedFitter 1

Fit TCandidateTrack
11 AddClusterDetUn( ) TCluster
AdoptFitStrategy( ) (from CMS Detector Model)
EvaluateTrack( ) {n}
Instance( ) 1 3..n
1 1 ProcessClusters( )
VTrajectory Reconstruct( )
{1}
(from CSM Fit Strategies)

CMS Pattern Recognitor Category

Figure 3: Class Diagram for the \CMS Inner Tracker Pattern Recognition". For
the class and method names we followed the Taligent [7] convention: Classes
whose name starts with V (for Virtual) are abstract classes which can not be
instantiated. Classes whose name starts with T (for Type) are concrete classes
which can be instantiated.

3.3 Static model

Once the key objects and their responsibilities have been identied we proceeded
to dene the classes, to which objects belongs, and the relationships between these
classes. The classes are organized into \Categories" according to the domain they
belong to. Figure 3 shows a Class Diagram representing two classes of the \CMS
inner tracker Pattern Recognition" category (TCandidateTrack and TTrackingRe-
gion) and their relationships with classes of other categories which are relevant to
the scenario we just described. Figure 4 shows the complete Class Diagram for the
\CMS Detector" category. At the early stages of the development process we es-
tablished only \acquaintance" relationships between classes to model the existence
of a \communication channel" between two collaborating objects. The decision on
how to implement them (as inheritance, composition or use) was deferred to a later
stage, when we had a more detailed understanding of the class structure.
3.4 The iterative process
The analysis and design continued iterating between the dynamic and static views
of the model (object interaction diagrams and class diagrams). At the same time
we started to build a toy implementation with a real object structure but dummy
methods to test and prove object collaboration.
During the iterations (and the renement of the implementation) the class struc-
ture stabilized and the focus shifted towards reducing the complexity of the model.
In particular we:
5
 VMainComponent TLayer
TOtherDetector | Build( )
Component NextLayer( )
NextSecondLayer( ) 1 1 NextDetUn( )
{n}
| SetSeed( ) Build
Instance( )
{1}
1 1

1 fCompatibleClus
1 fPossibleDetUns
TInnerTracker
Instance( )
{1}

0 1
1
1
TListOfCluster TListOfDetUn
TODCDetUn {n} {n}
{n}
1
TITDetUn MadeOf 0
{n}

VDetectorUnit 1 SetCompatibles TPtOrdList

1
InterceptTrack( ) (from CMS Data Structures)
NextSecondLayer( )
NextLayer( )
1
0
0 TCluster
A
{n}
1

fNeighbors CMS Detector Category

Figure 4: Class Diagram for the \CMS Detector" category

 checked the encapsulation and the object couplings;

 tried to anticipate possible changes;
 looked for possible reuse;

 looked for possible generalizations and specializations (inheritance relation-

ships);
 balanced the use of inheritance versus composition or templates;

 identied design patterns [8];

For example, we localized the responsibilities of steering the pattern recognition
and tting in the CandidateTrack object while the responsibilities of interacting
with the detector components and in keeping the history of the pattern recognition
were assigned to the TrackingRegion.
The coupling between objects has been further reduced making use of abstract
classes to dene their interfaces. In this way concrete classes can be modied
or further specialized without aecting the client objects. To better specify the
common behavior of child classes, and avoid code duplication, the structure of
the main services has been dened in the parent abstract classes using \template
methods" [8, pag.325]. For instance, in the present model a single \inner tracker
detector unit" (TITDetUn) class exists. In the real case more specialized classes
will be required to model the various real detectors like silicon micro-strips, silicon
pixels and micro-strip gas chambers. These classes can be introduced at a later
6
stage without any change to the \VDetectorUnit" class and, most important, to its
clients.
Abstract classes are also used to model the trajectory extrapolation and tting
strategies used by the candidate track: it is probable that dierent algorithms will
be used at dierent stages of the track reconstruction: very fast in the rst steps of
the pattern recognition, very precise for tting some particularly interesting tracks
(like electron candidates). The use of abstract classes, and composition relationships
instead of inheritance, permits to instruct the CandidateTrack object with which
trajectory extrapolation and tting strategy to use (through the AdoptFitStrategy
method) without any change to the CandidateTrack implementation.

4 Conclusion
This project started only one year ago and a lot of time was spent understanding
what OO is about and, most important, what is not.
We have learned that encapsulation, distribution of responsibilities, localization
and isolation of the parts which are likely to change is what makes Object Oriented
code really less complex. We have also learned that inheritance has to be used with
caution: its early introduction in the model can produce too rigid structures which
are very dicult to change later.
We have found that following a method and using a CASE tool was very useful
and increased the productivity of well organized software. There are still areas where
more development is required, like how to use the dynamic model in the design phase
to specify in detail the behavior of the system. The current second generation OO
methods, like Booch and Fusion [9], have demonstrated their capability to evolve;
we believe that adopting an OO method can only be benecial to the development
of HEP software.

Acknowledgments
We wish to thanks all our colleagues of CMS and RD41 who have contributed
with discussions, criticisms and suggestions to the development of the prototype.
We are particularly indebted to W.Jank, R.Mount and M.Pimia - without their
encouragement and support this work would have never been started.

References
1. CMS Collaboration Technical Proposal, CERN/LHCC 94-38, (Geneva 1994)
2. RD41 Object Oriented Approach to Software Development for LHC Experi-
ment, CERN/DRDC 94-9, (Geneva 1994)
3. for a review of OO methods see:
OMG Object Analysis and Design, A.T.F.Hutt editor, (John Wiley & Sons,
New York, 1994).
4. R. Wirfs-Brock et al. Designing Object-Oriented Software, (Prentice Hall,
Englewood Clis, New Jersey, 1990).
7
5. G. Booch Object-Oriented Analysis and Design, (Benjamin-Cummings, Red-
wood City, California, 1994).
6. R.K. Bock et al. Data analysis techniques for high-energy physics experiment,
pag.175, (Cambridge University Press, Cambridge, UK, 1990).
7. Taligent Taligent's Guide to Designing Programs, (Addison-Wesley, Reading,
Massachusetts, 1994).
8. E. Gamma et al. Design Patterns, (Addison-Wesley, Reading, Massachusetts,
1994).
9. D. Coleman et al. Object-Oriented Development, The Fusion Method, (Pren-
tice Hall, Englewood Clis, New Jersey, 1994).