Workbook for BaBar Offline Users - Object Oriented Software
This workbook chapter alerts people coming from non-OO backgrounds
that they have something new to learn. This section does not attempt
to teach all about OO, but instead refers the user to other
introductory documents already on the web.
The BABAR Computing System software is developed with an
Object-Oriented methodology, implemented primarily in C++, on several
Unix platforms. Whether one will be writing code, reading code, or
using analysis tools, OO is important for understanding BaBar
software. OO is a programming methodology that transcends an
individual language. C++ and Java are two languages that have been
designed to support the Object-Oriented paradigm. It is possible, and
quite common for individuals from non-OO backgrounds to write non-OO
programs in C++. Mastering OO extends beyond learning the syntax of a
new language, it involves developing a different perspective and
revising one's approach to programming.
Any discussion about Object Oriented programming relies
heavily on the associated terminology and a key set of
concepts. This section serves to define some of the terminology
and discuss the concepts that are central to Object-Orientation.
Many people with programming experience in languages such as Fortran
or C are familiar with a functional or procedural paradigm. Data is
passed to a function or routine which then performs the desired action
or changes. Memory addresses can be passed to functions which are then
able to change the information stored in that location. In
object-oriented paradigms a designated segment of data comprises an
object, which can be instructed to "act upon
itself". The code that defines the nature of an object, what
memory fields are stored (instance variables)and what
actions/changes of these values it can perform (methods), are
united as a class. An object is a specific instance of a
class.
A good first introduction to this paradigm is Object
Oriented Programming (For a novice, by a novice) written by Simon
Patton. The following definitions are from this document.
- Abstraction
-
The set of essential characteristics, relevant to the
problem, that distinguish an object from all other types
of items. These characteristics will include features
such as state, behavior, and identity.
- Class
-
A set of real or conceptual items that have the same
set of possible states and share the same behaviours.
- Object
-
An individual entity that can either be perceived
physically or mentally and that can be operated upon.
An object has a definite state, behaviour and identity.
The code that defines a class combines the instance
variables and the methods into one unit. To protect
the integrity of an object the modes of interacting with
an object's data are restricted. A set of methods and
designated instance variables are made available to the
client by an interface. The operations that
comprise the interface are the only legal ways for a
client to interact with the class. The details of the code,
the implementation, are thus separated from the
user and the objects are encapsulated.
- Encapsulation
-
The hiding of the details of the implementation of an
object behind an interface. The object can only be accessed
through the interface.
- Interface
- The `view' that the rest of the system has
of an object. This usually consists of the set of
operations derived during abstraction
of the object.
Classes may contain objects of other class types as instance
variables. This may take the form of composition
or/and inheritance. Both composition and inheritance
accommodate a more natural construction of complex classes
and allows reuse of code. Inheritance is the special case
when a class (subclass) is a specialization of the
class from which it inherits (super class). A mnemonic
device for telling inheritance from composition is whether the
new class "is a" kind of the original class (inheritance), or
"has a" included class as part of it (composition).
- Inheritance
-
A relationship between two classes, one class (the subclass)
is a specialization of the other class (superclass). The
subclass has access to the structure and behaviour of the
superclass, and will usually change and/or extend these properties.
Bob Hathaway of Geodesic Systems Inc has compiled an OO Frequently
Asked Questions page. The web site covers basic OO terminology and
concepts in a technical and abstract manner. The information is of a
theoretical nature and often includes discussion of how concepts
differ amongst object oriented languages.
OO
FAQ
An ideal programming design is that OO applications are written
as peer-to-peer collaborating objects. Whereas procedural designs
rely heavily on a main() function to manage the
application, OO design aspires to grant more equality of control
to the objects within the application. Objects interact and
communicate with each other by sending and receiving requests
or messages. The goal in OO design is to achieve a consistent set
of objects whose behavioural characteristics - their interfaces -
allow the set up of collaborations (an expandable set) which
fulfill the requirements of the application-to-be. Classes are
designed to accommodate all possible use cases that
will arise in the application.
Benefits of OO
Why OO helps, especially on large projects like BaBar software.
Object Oriented programming offers a powerful model for writing
computer software. Objects are "black boxes" which send and
receive messages. This approach speeds the development of new
programs, and, if properly used, improves the maintenance,
reusability, and modifiability of software.
Encapsulation of the instance variables and methods of a class
behind an interface provides protection and control. This
segmentation of code makes large software projects more manageable
and allows many individuals to work on interrelated aspects of a
project without conflict. Software is more robust when made
independent of the implementation of any given class by a
constant interface. The larger a project the greater the impact
and importance of code reuse. Inheritance and composition allows
common code to be consolidated into a class that can be incorporated
into many other classes. Inheritance also provides a means to create
uniform behaviour and system-wide compatibility among groups of classes.
C++: The OO language selected by BaBar
We have adopted Object Oriented Programming as our preferred style and
to benefit fully from the power of this approach we need to adopt an
object oriented programming language. The programming language of
choice for BaBar is C++. When the decision was made, consideration of
the available languages, including the availability and cost of
compilers, support for different platforms, development and debugging
tools, and interfaces to databases etc. showed that C++ was the only
viable choice. If this decision were being made today, other viable
options such as Java, would be strong candidates.
The BaBar reconstruction software is written almost exclusively
in C++. This is also true for the online system, although C may be
used in cases where no C++ compilers are available (some single board
computers).
The detailed simulation is based upon the GEANT4 package, which
is written in object-oriented C++. The standard package
for the specialization of GEANT4 for the BaBar detector is called
MOOSE (Monolithic Object-Oriented Simulation Executable).
MOOSE implements the four basic steps in the simulation:
- Generation of the underlying physics event;
- Particle transport and calculation of the idealized energy deposits in the detector;
- Overlaying of backgrounds and digitization of the energy deposits;
- Reconstruction.
(Some people still use an older 3-step procedure, with a package
called BOGUS for steps 1 and 2, SimApp for step 3, and Bear for step 4,
but this is being phased out.)
Learning OO
Designing in OO and writing OO code in the C++ language are covered in
a later section of this workbook, the
OO Courses and References subsection of Writing Code.
General related documents:
Author:
Tracey Marsh
Contributors:
Neil Geddes, Simon Patton,
Joseph Perl
Page maintained by:
Jenny Williams
Last modification: 18 June 2005
Last significant update: 6 June 2005
|
