LHCb Software strategy
LHCb Technical Note
Issue:
Revision:
1
1
Reference:
Created:
Last modified:
LHCb 98-025 COMP
21 october 1997
6 february 1998
Prepared By:
LHCb computing subgroup
Editor: Eric van Herwijnen
LHCb Software strategy
LHCb Technical Note
Issue:
1
Table of Contents
Reference:
Revision:
Last modified:
LHCb 98-025 COMP
1
6 february 1998
Abstract
This document describes the software strategy of the LHCb experiment.
 The main objective is to reuse designs and code wherever possible;
 We will implement an architecturally driven design process;
 This architectural process will be implemented using Object Technology;
 We aim for platform indepence; try to take advantage of distributed computing and will use industry
standards, commercial software and profit from HEP developments;
 We will implement a common software process and development environment.
One of the major problems that we are immediately faced with is the conversion of our current code from
Fortran into an Object Oriented language and the conversion of our current developers to Object
technology.
Some technical terms related to OO programming are defined in Annex A.
Document Status Sheet
Table 1 Document Status Sheet
1. Document Title: LHCb Software Strategy
2. Document Reference Number:
3. Issue
page i
4. Revision
5. Date
6. Reason for change
Draft 1
1
11 Dec 97
First version
Draft 1
2
30 January 98
Incorporated comments from reviewers
Version 1
0
6 february 98
First released version
LHCb Software strategy
LHCb Technical Note
Issue:
1
Table of Contents
Reference:
Revision:
Last modified:
LHCb 98-025 COMP
1
6 february 1998
Table of Contents
1.
INTRODUCTION .................................................................................................................................................... 1
2.
OBJECTIVES ........................................................................................................................................................... 2
2.1.
2.2.
2.3.
2.4.
2.5.
3.
ARCHITECTURALLY DRIVEN DEVELOPMENT PROCESS ....................................................................... 5
3.1.
3.2.
3.3.
3.4.
4.
REUSE.................................................................................................................................................................. 2
COMMON ARCHITECTURE .................................................................................................................................... 3
SUPPORT .............................................................................................................................................................. 3
LICENSING MODEL ............................................................................................................................................... 4
EVOLUTION ......................................................................................................................................................... 4
COMPONENTS ...................................................................................................................................................... 5
TOOLKITS ............................................................................................................................................................ 6
FRAMEWORKS ..................................................................................................................................................... 6
APPLICATIONS ..................................................................................................................................................... 7
TECHNOLOGICAL ASPECTS ............................................................................................................................. 8
4.1.
WHY OBJECT TECHNOLOGIES? ............................................................................................................................ 8
4.1.1.
Object modeling gives re-usability ............................................................................................................. 8
4.1.2.
Re-using existing frameworks makes coding easier and faster ................................................................... 8
4.1.3.
Encapsulation enables the creation of components .................................................................................... 9
4.1.4.
Technical prerequisites are in place ........................................................................................................... 9
4.2.
OBJECT ORIENTED LANGUAGES .......................................................................................................................... 9
4.3.
PLATFORM INDEPENDENCE ................................................................................................................................ 11
4.4.
DISTRIBUTED COMPUTING................................................................................................................................. 12
4.5.
USE OF INDUSTRY STANDARDS AND COMMERCIAL SOFTWARE .......................................................................... 13
4.6.
HEP-WIDE DEVELOPMENTS ............................................................................................................................... 13
5.
SOFTWARE PROCESS AND ENVIRONMENT ............................................................................................... 15
5.1.
5.2.
5.3.
6.
HUMAN ASPECTS ................................................................................................................................................ 18
6.1.
6.2.
6.3.
6.4.
7.
THE SOFTWARE DEVELOPMENT PROCESS ........................................................................................................... 15
QUALITY CONTROL ............................................................................................................................................ 16
DOCUMENTATION .............................................................................................................................................. 17
MIGRATION STRATEGY ...................................................................................................................................... 18
PROFILE AND SKILLS .......................................................................................................................................... 19
COLLABORATIVE ASPECTS ................................................................................................................................. 20
TRAINING .......................................................................................................................................................... 21
CURRENT SITUATION AND EVOLUTION .................................................................................................... 22
7.1.
7.2.
7.3.
OFF-LINE COMPUTING........................................................................................................................................ 22
ON-LINE COMPUTING ......................................................................................................................................... 22
INFORMATION MANAGEMENT ............................................................................................................................ 22
8.
CONCLUSIONS ...................................................................................... ERROR! BOOKMARK NOT DEFINED.
9.
REFERENCES ........................................................................................................................................................ 25
page ii
LHCb Software strategy
LHCb Technical Note
Issue:
1
Introduction
Reference:
Revision:
Last modified:
LHCb 98-025 COMP
1
6 february 1998
List of Figures
FIG. 1 THE CORBA ARCHITECTURE (BY THE OMG) ......................................................................................................... 12
page iii
LHCb Software strategy
LHCb Technical Note
Issue:
1
Introduction
Reference:
Revision:
Last modified:
LHCb 98-025 COMP
1
6 february 1998
List of Tables
TABLE 2 CURRENT LHC++ COMPONENTS ......................................................................................................................... 13
iv
page iv
LHCb Software strategy
LHCb Technical Note
Issue:
1
Introduction
Reference:
Revision:
Last modified:
LHCb 98-025 COMP
1
6 february 1998
1. Introduction
The aim of this document is to describe the software strategy for the LHCb experiment. It accompanies the
documents “LHCb Computing Model” [1], “LHCb Computing Tasks” [2] and “LHCb Project Plan for
Computing” [3] as technical notes that support the computing section of the LHCb Technical Proposal, to
be presented to the LHCC in spring 1998.
We are developing software for a new experiment that is scheduled to start in the year 2005. This
experiment is being started from scratch. A new detector is being designed, with new hardware, new
electronics and new software. There will be a particularly intense use of software in the triggering process
(levels 1,2 and 3). The participants in LHCb have a large experience by their participation in previous
experiments. Indeed, by far the largest majority of the scientists involved in LHCb are currently heavily
involved in other, running experiments.
All aspects of LHC experiments [4],[5] are at least an order of magnitude larger than those of experiments
running today. The infrastructure is larger, the number of staff is larger, the amount of data is larger, the
required CPU power is larger, the code is larger and so on. We therefore need a much better quality control
than has been the case in physics experiments so far.
On the other hand, we can now profit from better design tools and a new paradigm, Object Orientation,
without which it would be difficult to manage this increase in scale. Whilst young collaborators are
proficient in these new technologies, many of the staff currently involved in LHCb are not. Closing the
culture gap by bringing everyone up to equal speed as soon as possible will be a major problem.
It is of key importance to have a well-defined software strategy and investment in project management and
planning. In this document we will describe the goals of our software strategy. We will describe our
objectives and how we will achieve them by using an architecturally driven development process. Then we
will describe the most important strategies to follow, containing a justification for Object Technologies and
a description of how we will organize the activities so that we can meet the challenges that face us.
page 1
LHCb Software strategy
LHCb Technical Note
Issue:
1
Objectives
Reference:
Revision:
Last modified:
LHCb 98-025 COMP
1
6 february 1998
2. Objectives
The objectives of our software strategy are:
 Reuse of design and code;
 Apply an architecturally driven design process;
 Put in place a solid support infrastructure;
 Organize software licenses centrally;
 Evolve with new technology.
2.1. Reuse
Not so long ago, the consumer electronics industry was producing console stereos that were sold more like
furniture than electronic devices. One large cupboard came with an integrated television, record player,
speakers, etc. Nowadays one has a huge offering of products that can be picked and mixed according to
need, taste and budget. In many ways, the software of physics experiments resembles the electronics
industry of 30 years ago. Our applications tend to be large, and contain every possible function under the
sun. Programmers spend much of their time maintaining, debugging and extending monolithic software.
Physicists are faced with a plethora of different data formats, inconsistent user interfaces and are locked into
proprietary software systems. Software has become too difficult to change.
There is no evidence that we can speed up the software development process itself. The only way out of the
“software malaise” is to make the software development process more economic by extracting more use out
of a given piece of software.
We therefore aim at maximizing the reuse of our software components wherever possible. For example:
an event display can be reused to display both on-line and off-line events
geometry description can be reused by all subdetector components
subdetector components can be reused by reconstruction and simulation programs
the data storage model, description, data access method can be reused wherever there is a data
management issue
a controls component could be reused for both run controls and slow controls
2
page 2
LHCb Software strategy
LHCb Technical Note
Issue:
1
Objectives
Reference:
Revision:
Last modified:
LHCb 98-025 COMP
1
6 february 1998
2.2. Common architecture
Traditionally, large software projects are managed by splitting them up into a hierarchy of seemingly
disconnected activities. This typically results in, for example, two distinct groups for on-line and off-line
computing, several different controls groups etc. Rather than such a ‘divide and conquer’ approach, which
encourages strict application domains with impenetrable boundaries between them, we have opted for an
architecturally driven approach. Part of the architectural design is the identification of basic building blocks
at three levels: patterns, components and frameworks. By using this process we will identify common
architectures at various places in the experiment.
These common architectures can then be applied to different application domains and we can reuse many
components. Thanks to a common architecture there will be no barriers between applications domains. For
example, to get commonality between the on-line and off-line computing areas, we intend to:
provide a common infrastructure and apply common working principles
make use of common databases
define a single access method to data
define a common detector geometry description
define a common graphical user interface
ensure optimal communication between participants of on-line and off-line activities
share resources, for example use DAQ computers for doing Monte Carlo production during
shutdown periods
use common trigger and reconstruction algorithms for both real and simulated data, and for off-line
and high level triggers
There should also be a common architecture inside an application domain, such as on-line computing. For example, we
should have a:
common infrastructure and working principles for DAQ and Controls
the same for Workflow Control, Run Control, Safety Control, Slow Control, Interface with the LHC
We will aim at minimizing the diversity of hardware and minimize the dependence of the software
environment on hardware. The same principles for the design of software will be applied throughout the
experiment. There should be as much standardization as possible on one computing environment, that
should not be prohibitively expensive for outside CERN users, bearing in mind that collaborating institutes
will have their own hardware anyway. There should be a single software production process and
development environment.
2.3. Support
In view of restricted resources, we should have a common support for office automation, information
exchange, documentation guidelines, project management, training and so on. We will recommend a
page 3
LHCb Software strategy
LHCb Technical Note
Issue:
1
Objectives
Reference:
Revision:
Last modified:
LHCb 98-025 COMP
1
6 february 1998
standard set of office tools, create templates for documentation, and create procedures for publications on
the Web.
2.4. Licensing model
LHCb should have a licensing model that ensures minimal costs and equal access where common software
is used. No institute should be penalized for running LHCb software for financing reasons. The
collaboration needs a licensing model that takes into account all the ramifications of commercial software
where software is financed by the collaboration.
COCOTIME has decided to include licenses in its annual funding exercise. This means that no licenses will
be required for centrally supported software (such as LHC++).
2.5. Evolution
The development and maintenance lifecycle is of the order of 20-30 years. It is impossible to predict what
computing technologies and facilities will be available in 2005. Our strategy is to have an architecturally
driven development process that focuses on the creation of reusable components. This should enable us to
evolve with technology.
4
page 4
LHCb Software strategy
LHCb Technical Note
Issue:
1
Architecturally driven development process
Reference:
Revision:
Last modified:
LHCb 98-025 COMP
1
6 february 1998
3. Architecturally driven development process
Demands on software quality are increasing. Event sizes and data volumes are far larger than for previous
generation experiments and the software used to process them is more complex due to the nature of the
events and the wide spectrum of detection techniques employed in the LHCb detector. Software algorithms,
similar to those used to reconstruct events, will be used by the LHCb trigger system to filter interesting
physics from uninteresting background processes. As manpower is limited, it is essential that we become
more efficient in the way we design code so that it can be reused as widely as possible throughout the
LHCb software system. We therefore place the emphasis on one overall architecture. In organising our
projects we have identified the development of reusable software components as one activity.
By architecture we mean the structuring paradigms, styles and patterns that make up our software systems.
The architecture should be designed by system architect(s) with visibility across multiple projects. This
provides opportunities for sharing concepts, design and code. The architects should promote the sharing of
common architectural constructs and frameworks.
The key aspect of the LHCb software architecture is that it will be constructed from re-usable components.
This section will recapitulate some fundamentals of architectural design. The definitions of components,
toolkits, frameworks and applications are the ones from common parlance, and are widely applied in the
computer literature. Please note that this is not an introduction to Object Oriented software development;
the architectural design principles given below could in principle be applied to any software technology.
Object technology simply makes it easier to follow the architectural design process. For an introduction to
Object technology, see [6], [7], [8], [9].
3.1. Components
Definition: A component is a self-contained element of software that can be controlled dynamically and
assembled to form applications. The principle of building from components is a common industrial practice,
where systems are constructed out of reusable tested components with known characteristics and welldefined connections.
Some examples of components in the context of the LHCb experiment are:
detector components
digitizations
tracks
controls components
graphical user interface
visualization components
The functionality of a component has to be carefully thought about. To make it reusable, a lot of effort
needs to go into its design. It takes time before a component is truly re-usable i.e. before it is complete and
page 5
LHCb Software strategy
LHCb Technical Note
Issue:
1
Architecturally driven development process
Reference:
Revision:
Last modified:
LHCb 98-025 COMP
1
6 february 1998
fully debugged. It takes time before a large number of components can be collected. Some can be
purchased. However they need to be assembled into larger components and standardized for our application
domains.
Software components are based on two closely related ideas: standard protocols and a small number of rich
classes. The protocols allow components to interoperate regardless of who developed them. The number of
classes must be small to minimize the dependency on specialized knowledge and such that the classes can
be easy to compose together. Since it must also be possible to implement anything we want, each class must
be functionally rich.
The following is a summary of advantages of using components:
Avoid duplication of work
Easy way to integrate (commercial) software
Makes code simpler to write, maintain and reuse
Enforces strict coding standards to a well defined interface
When correctly constructed, components can help the construction of distributed applications
3.2. Toolkits
Definition: A toolkit is a collection of one or more libraries of predefined software. The toolkit is used asis. An example is the CERN library, or its OO equivalent LHC++ [10] containing Geant 4, Iris Explorer and
Objectivity. Another example of a toolkit is HepVis, a library consisting of graphical objects capable of
representing the most common entities of a collider physics experiment. Users (physicists) do not make
changes to a toolkit, but use it off the shelf. Indeed, the IRIS Explorer visualization tool combined with the
Objectivity database allows the user to do data analysis without having to write a single line of code.
3.3. Frameworks
Definition: A framework is a set of prefabricated software building blocks (components) that programmers
can use, extend or customize for specific computing solutions. It provides a set of cooperating components
that make up a reusable design for a specific class of software. With frameworks, software developers don’t
have to start from scratch each time they write an application. Both the design and the code of a framework
can be reused.
Approximately half the code in a typical application is dedicated to routine operations that can be built once
and canned for re-use. Frameworks comprise components for communications, persistence, transaction
management, security, error handling, windowing etc. Data acccess will be via an SQL request to a remote
database via the network, and the result will be sent back asynchronously. The result of using appropriate
frameworks will be a high level of re-use offering very substantial savings.
A framework defines the overall structure of an application, and it captures the design decisions that are
common to the application domain of the framework. It emphasizes design reuse over code reuse; a
programmer uses a framework as a productivity tool to improve the quality of his code.
6
page 6
LHCb Software strategy
LHCb Technical Note
Issue:
1
Architecturally driven development process
Reference:
Revision:
Last modified:
LHCb 98-025 COMP
1
6 february 1998
Some examples of frameworks for physics experiments are:
ROOT [11], a framework for data analysis that provides histogramming, statistical analysis and
visualization tools, basic database functionality etc.
WIRED [12], a framework for interactive event display using the World Wide Web.
Frameworks function as follows. Imagine a Framework for physics event analysis. The task of the
framework is to provide an environment that informs the user when an event arrives, and to deliver the
event to the user. The framework handles all system aspects that the user doesn't care about, such as
initialization and messaging. It provides an analysis loop, with calls to initialization and messaging classes.
A special class informs the user when an event arrives. It contains empty methods to be supplied by the
user.
To make a physics analysis program, code needs to be written for the empty routines in the special class.
The framework takes care of all the other aspects.
Frameworks have the great advantage that they considerably simplify the maintenance of the code. In the
example above, all method calling is centralized and rarely needs to be changed. Polymorphism means we
can write different methods for different objects, without having to change the calling routine. If something
gets changed in the system, this will not affect the analysis code.
3.4. Applications
The application programs are the end products that we need to create. By using “LHCb standard” objects,
components, toolkits and frameworks we can ensure that our applications will be easier to maintain, since
we can vary any aspect of the system structure independently of other aspects.
Some examples of LHCb applications are:
Calibration and monitoring
Event analysis
Event reconstruction
Simulation
Event visualization
Independently of our architecture, we will need:
office software
systems and networking software
resource management
The management tasks (system, network, software) and engineering tasks (organization, quality assurance,
process guidelines, training and documentation) will be addressed later in this document.
page 7
LHCb Software strategy
LHCb Technical Note
Issue:
1
Technological aspects
Reference:
Revision:
Last modified:
LHCb 98-025 COMP
1
6 february 1998
4. Technological aspects
4.1. Why Object Technologies?
The Object Oriented paradigm will allow us to implement the software architecture described in the
previous chapter, that is based on reusable components.
In addition, we must follow trends in computing technology, both in hardware and software. Sound
principles of software engineering have led to the development of Object Technologies and these are now
widely supported by industry. These days computing professionals are trained in OO techniques.
Like other HEP collaborations working on new experiments (BaBar, STAR, Atlas, CMS, Alice), we expect
to follow these trends. Currently our software development activities, mainly simulation, use the existing
HEP codes written in FORTRAN. This will continue until a new framework based on the new OO toolkits,
currently under development, is made available. Although the number of people currently involved in these
software activities is relatively small (~15) we are aware that this situation will evolve rapidly with time.
There are some young staff with some training in computing familiar with Object Technologies. We give
high priority in the planning to provide a suitable OO software environment as soon as possible and training
people in the use of these new codes. The transition from the existing FORTRAN based developments to
the new developments must be carefully prepared.
4.1.1.
Object modeling gives re-usability
We believe that Object Orientation can help us achieve the re-usability goals stated above. Object modeling
naturally leads to re-usability.
By identifying the structuring paradigms, styles and patterns that make up our software systems we will
obtain opportunities for sharing concepts, designs and code across projects.
Common architectural constructs and frameworks can then be shared across projects. We must introduce
practices that encourage application of the same architecture over multiple projects.
The process of architecture design is a parallel activity to object modeling.
4.1.2.
Re-using existing frameworks makes coding easier and faster
By creating and re-using frameworks we can capture design decisions that are common across the LHCb
applications.
We can probably apply design patterns from other experiments, or HEP environments. If they don’t exist,
we will make our own.
8
page 8
LHCb Software strategy
LHCb Technical Note
Issue:
1
Technological aspects
Reference:
Revision:
Last modified:
LHCb 98-025 COMP
1
6 february 1998
Inside the framework, code has to be written whilst adhering to naming and calling conventions, reducing
any design decisions that have to be made.
The resulting applications will be faster to write and easier to maintain.
4.1.3.
Encapsulation enables the creation of components
By separating the interface from the implementation we achieve encapsulation
The use of encapsulation gives more maintainable and more reliable code
Use of standard interfaces enables easy creation of re-usable components
4.1.4.
Technical prerequisites are in place
The technical prerequisites for the adoption of Object Technologies are in place:
Mature object frameworks exist and are being used
development environments (languages etc.), ODBMS exist
A widely supported language independent object communication standard exists (CORBA)
The RD45 project has shown that for the quantities of data produced by LHC experiments, the
standard ‘linear’ data storage model does not scale. Object databases have been shown to perform
correctly (“Persistent Object Storage”).
4.2. Object Oriented Languages
Many aspects set the requirements for a computing language that fulfills our needs. The language should be
easy to use and result in understandable code. LHCb does not start up from an entirely virgin software
environment. In addition, the evolution of the software development process over the next 20 years has to
be considered.
Under the assumption that we want to use the OO paradigm in the future and that there already exists a
considerable amount of code that needs to be converted, the following issues have to be considered:
Software development with OO languages requires a change of thinking: traditionally a given
problem was expressed in terms of the data associated to it. In OO technology the description of the
problem is described in terms of behavior. The description of the data associated is only one of the
views; much more emphasis is put on the interaction of code fragments (objects) serving (a)
particular need(s). Data manipulations do not take place by direct manipulation of the data, but by
the calling object notifying the called object to manipulate its data; the “callee” changes state.
CASE (Computer Aided Software Engineering) tools can be used to describe the interaction between
objects and can therefore help to efficiently produce software. Some of these tools support basic
page 9
LHCb Software strategy
LHCb Technical Note
Issue:
1
Technological aspects
Reference:
Revision:
Last modified:
LHCb 98-025 COMP
1
6 february 1998
code generation facilities that ease the maintenance of individual code threads. It is clearly desirable
that the chosen language should be supported. These tools should be simple and self-explaining
To share designs and codes across working teams of programmers it is important to use unified
notations and diagrams.
The language should support the construction of decoupled building blocks (components,
frameworks), that allow reengineering of individual components without changing the usage of the
components.
The chosen language should follow industrial standards. This ensures not only the usability of “off
the shelf” components and libraries, but also the presence of appropriate development tools like
debuggers.
In view of the uncertainty about the available computing technology in 10 years time, the role of
performance may not be neglected.
Last, the chosen language should be easy to learn, or it should contain a subset that is easy to learn.
These requirements are independent of the OO paradigm. However, in order to achieve the goals with
minimal effort, the opportunities OO languages give – mainly in terms of maintenance, if applied correctly
– play an important role:
Support of abstraction. This is explained best with a simple example. Imagine a small database
invented by a user to store some information, e.g. beam spot points for a set of events. In the
beginning this database is probably simply an ASCII text file. Later, when this analysis code
becomes popular and the analyzed dataset large, obviously this database will for performance
reasons no longer work. It has to be converted using more efficient database technology. If in the
beginning these file accesses were object oriented implemented using an abstract database, then later
only the real instantiation of the database needs adaptation and not the calling code. Also the reverse
direction can be realized with minimal effort. Abstraction can be realized either by inheritance or
better directly using abstract classes defining only the interface, but no behavior.
Support for inheritance, which is partially equivalent to abstraction.
Today, there are two candidate OO languages for LHCb, namely C++ and Java. If an immediate choice
were necessary, C++ would perhaps be the favored language. The main advantages result from the fact that
C++ is the most commonly used OO language in commercial software development. Today it is difficult to
make any speculations which language will win the race – we cannot even influence it. It is important to
choose a language that allows the construction of loosely coupled components, because we might have to
face multiple migration steps – but hopefully these will only be gradual steps to convert OO code from
language a to language b. By using a single diagramming technique the implementation should become less
dependent on the choice of language.
An important consideration is also the dependence on external toolkits such as GEANT 4. Use of GEANT
4, which is written in C++, would practically constrain us to use C++.
Despite the fact that most Java implementations are still slow, and that Java does not easily allow shared
library use (you need to send them over the network, with your application), there are some aspects that
could make Java an interesting choice, even today:
1. The difference in performance between Java and C++ might disappear soon through specific
hardware and software improvements. Although no one knows exactly when this will be, it looks
likely that it could happen within a few years.
10
page 10
LHCb Software strategy
LHCb Technical Note
Issue:
1
Technological aspects
Reference:
Revision:
Last modified:
LHCb 98-025 COMP
1
6 february 1998
2. There is a lot of activity around Java in industry and in many cases (particularly for database,
distributed applications and GUIs) Java is a preferred choice over C++.
3. Java is distributed by design. It allows the construction of self contained software-agents that will
run on a collection of computers. This would permit the use of hundreds, perhaps thousands of
desktop machines while they are idle. Agent dispatchers are available commercially today.
4. It is well known (from the Atlas and CMS Computing Technical Proposals) that the major bottleneck
for LHC computing will be the cost and availability of network resources. Moving large amounts of
data over the network should therefore be avoided, in favour of exploitation to the maximum of local
CPU power. Data should be created where it is required.
5. The exploitation of this feature requires specially designed components, i.e. it has an impact on the
architecture.
6. Although in principle it is possible to call C++ methods from C++ classes in a Java program, no one
has ever tried using Geant 4 in a Java program, and this could cause some difficulties. There are no
plans to rewrite Geant 4 in Java. Building a CORBA interface to Geant 4 might also be a technical
(but difficult) possibility.
7. Java is superior to C++ as a language, because of its inherent network support, its automatic garbage
collection, the absence of pointers, the absence of multiple inheritance, and its built-in support for
multi-threading and thread synchronization. Although class libraries exist for C++, Java was
specifically designed for multi threading and networking so the resulting applications tend to be
more robust. It also allows the creation of platform independent graphics applications.
So far, no experiment that we know of has decided to use Java exclusively for all their software. As stated
before, provided we adopt an architectural approach, the question of which language to choose should not
be the primary issue.
4.3. Platform independence
From our experience with past (e.g. LEP) experiments, we know that it is difficult to foresee which
platform the software used by the LHCb experiment will run on. The systems in use today (Windows NT,
Linux, UNIX…) might already be obsolete when the experiment will start.
We note that the issue of Windows NT vs Linux seems to be the topic of a lively debate that we do not wish
to enter into at this point in time. For the moment the preferred platform is Windows NT; if there is a strong
reason, we will systematically evaluate the pros and cons of both and adjust our recommendation
accordingly.
Generally two issues have to be distinguished: source code and binary independence.
Platform dependence of source code creates huge maintenance loads: if platform dependent code is spread
uniformly over all applications or frameworks, the adaptation process is painful, whereas in case of
consequent use of special purpose objects, the adaptation is limited to a well defined set of code fragments.
Every release requires recompilation and relinking to create the binaries for all platforms in use. Strict usage
of abstraction/inheritance can solve this dilemma.
Binary independence (i.e. the same executable may run on a variety of platforms) naturally supports the
idea of distributed computing. The bootstrap to invoke remote procedure calls (RPC) is much easier in case
the executables are managed from a central place. In practice, however, it creates difficulties to distribute
page 11
LHCb Software strategy
LHCb Technical Note
Issue:
1
Technological aspects
Reference:
Revision:
Last modified:
LHCb 98-025 COMP
1
6 february 1998
computing, since not only data, but also the code must be ported to any possible platform used by the
community.
Despite these difficulties, we must be platform independent. Again, the architectural design approach
should guarantee this. The full software environment should be available on all the platforms in use by the
experiment.
4.4. Distributed Computing
The discussion about distributed computing boils down to two main issues:
1. Should the data go to the machine the process resides on or should the process delegate the
analysis/manipulation of the data to the machine where the data resides?
2. Is it more performant to do the data analysis/manipulation on a remote machine instead of the
desktop?
Whenever one of the mentioned issues is true, it is useful to delegate the computation task. The actual
delegation can be seen as starting up some remote “batch job”, which allows interaction and property
(method) manipulation. There are several technologies around supporting this feature:
CORBA (see Figure 1): a standard defined by the “Object Management Group” (OMG). The
interface description necessary to inform the caller about the capabilities of the callee has to be
written in IDML (Interface Definition Markup Language).
DCOM/OLE: Microsoft’s standard. IDML – Microsoft calls it ODL (Object Definition Language) is
hidden from the user by the development tools; the implementers only have to worry about the
implementation.
RMI: Delegation implementation used and implemented by Java. CORBA and RMI are soon to be
integrated.
Application Objects
Common Facilities
Object Request Broker
Object Services
Fig. 1 The CORBA architecture (by the OMG)
12
page 12
LHCb Software strategy
LHCb Technical Note
Issue:
1
Technological aspects
Reference:
Revision:
Last modified:
LHCb 98-025 COMP
1
6 february 1998
4.5. Use of industry standards and commercial software
LHCb will use industry standards wherever possible, and rely on commercial software instead of local
development. As mentioned in section 2.4, a centralized licensing policy for collaborating institutes will be
put in place.
ODMG-93 by “Object Database Management Group” (ODMG) is one of the most important standards. It
handles integration of Objects, Object Database Management Systems (ODBMS) and object-oriented
languages (C++, Java, and Smalltalk).
4.6. HEP-wide developments
LHC++ is a working group, which provides a rough equivalent of the current CERNLIB for future HEP
experiments, including LHC experiments. Current LHC++ strategy includes these components:
Transient
Persistent
GEANT-4, MCLIBS++
HepExplorer
IRIS Explorer
HepVis, HepInventor
OpenGL, OpenInventor, Master Suite
The NAG C library (with C++ headers)
CLHEP
HepODBMS.h
LAPACK++ / TNT
Standard C++ Libraries
ODBMS (Objectivity/DB) +
persistent STL
Table 2 Current LHC++ components
The focus of LHC++ is on (industry) standard solutions. The LHC++ team currently recommends the
following commercial packages and standards, and we intend using them:
OpenGL is the industry standard for graphics, originally developed by Silicon Graphics. Several
implementations exist for C++. Sun is developing an OpenGL compatible graphics class library for
Java.
Open Inventor is a 3D graphics toolkit to build interactive graphics applications.
MasterSuite is a toolkit for data visualization (histogramming, charts, and movies).
IRIS Explorer is a toolkit for scientific data visualization.
page 13
LHCb Software strategy
LHCb Technical Note
Issue:
1
Technological aspects
Reference:
Revision:
Last modified:
LHCb 98-025 COMP
1
6 february 1998
Objectivity/DB is an object database that provides persistency services for GEANT-4 and
experimental data.
NAG C library is a library of mathematics routines.
GEANT4 is a project that re-designs the CERN major simulation package for an object-oriented
environment using C++. The product is continuously compared with the functionality provided by the last
FORTRAN version of GEANT (3.21). This project is fundamentally testing the suitability of the objectoriented approach for simulation in HEP, where performance is a crucial issue. The major subdomains of
the project are:
Events and tracks management - manages the generation of events, interfaces to event generators,
and any produced secondary particles
Tracking management - propagates a particle by analyzing the factors limiting the step and applying
the relevant physics processes
Particle interactions in matter - manages the interactions of particles in matter, including the
definition of materials, particles, physics processes and their parameterizations
Geometry - manages the geometrical definition of the detector and the computation of distances to
solids (also in magnetic field)
Hits and digitization - manages the creation of hits and their use for the digitization phase
Visualization framework - manages the visualization of solids, trajectories and hits
Interfaces – includes GUI to ODBMS, Reconstruction and Parameter management
A persistent Object Manager for HEP is a project to investigate object persistence for HEP. Main target
is event data, but it handles objects of all kinds (histograms, calibration and alignment data, detector
geometry data, production control data, etc.). The main goals of the RD45’s class library HepODBMS,
which uses Objectivity/DB, are:
Provide an insulation layer for HEP applications to minimize database vendor and release
dependencies
Simplify the porting of existing applications to an ODBMS to minimize code changes to provide
persistence
Provide high level base classes
Clustering & locking strategies, database session and transaction control
Event collections, selection predicates, tagDB access, indexing
Limited support for transient/persistent mode switching
14
page 14
LHCb Software strategy
LHCb Technical Note
Issue:
1
Software process and environment
Reference:
Revision:
Last modified:
LHCb 98-025 COMP
1
6 february 1998
5. Software process and environment
The LHCb software project will be organized in sub-projects and teams that are formed in an architecturally
driven way. A complete description of this organization is given in the note “Project Plan for Computing”
[3]. Here we highlight some aspects of our migration strategy, the software development process, the
quality of the process, documentation, collaborative aspects and training.
5.1. The software development process
It is important that software written for the experiment be sufficiently well engineered and sufficiently well
documented to make it useable and maintainable throughout the lifetime of the experiment, spanning many
generations of programmers. Three key components drive all improvements in software development
productivity: the PEOPLE involved, the organization of the development PROCESS, and the
TECHNOLOGY used. The human aspects are discussed in chapter 6. Here we concentrate on the process
and the technology.
Experience shows that the most reliable and maintainable software is obtained when it is produced
according to a well-defined development process, encompassing all phases of the software lifecycle
(analysis, design, and coding, commissioning, maintenance).
The "Software Process Improvement" activity has been applied and standardized in many large
organizations. It is based on a software process model which defines the lifecycle phases and activities
associated with them. A set of deliverables is defined for each phase (e.g. user requirements, software
requirements, architectural design, design and code, release notes and operational notes, but also
measurements of software metrics, compliance with coding conventions etc.) and must be made available in
order to proceed to the next phase.
In addition, LHCb requires the software process to:
be flexible and transparent enough to accommodate the different programming backgrounds of our
colleagues without discouraging them from contributing to the project;
support an evolutionary approach to software development, since the software requirements will not
be known in sufficient detail from the outset and will in any case evolve with time;
support teams working in a world-wide distributed fashion
allow us to place more stringent requirements on mission critical code (e.g. trigger algorithms), than
on less critical code (e.g. analysis algorithms).
Various activities and tasks are performed during the software development process to go from the user
requirements to the delivered product. The machine can often help the human, sometimes even
automatically, to avoid errors, work faster and concentrate the attention at the conceptual level. A software
development environment integrating at least some if not all the tools in the list below (which is intended as
an example and is not complete) must support the software process. The environment should be
homogeneous across the hardware platforms supported in the experiment. We intend using the services of
the (at time of press so-called) IT-IPT group to advise us [14].
page 15
LHCb Software strategy
LHCb Technical Note
Issue:
1
Software process and environment
Reference:
Revision:
Last modified:
LHCb 98-025 COMP
1
6 february 1998
Software engineering (CASE) tools using the Unified Modeling Language (UML), or Rational Rose
(a choice to be made)
Language sensitive editors with templates that facilitate conformance with coding conventions and
programming styles
Compilers, linkers, debuggers
Code management (e.g. cvs)
Configuration management (e.g. BaBar extensions to cvs)
Documentation tools (e.g. LIGHT). Design documents manuals and the code itself are all part of the
documentation.
Quality control software
For project planning purposes we use MS Project
Standard test programs for testing new releases of existing code
5.2. Quality control
The quality of a software system is governed by the quality of the process used to develop and maintain it.
A high quality process is characterized by the following activities: project management and tracking,
verification and validation, configuration management, documentation and team communication. It
involves supplying the Organization, Methods and Tools (OMT) for supporting all steps of the software
production lifecycle i.e. requirements analysis, design, implementation, testing and maintenance.
Quality control affects all components of the LHCb Computing Project:
Reconstruction: Currently the release of new versions of the main software components is a painful process.
Problems are being detected by end-users and a new release goes through several iterations before it finally
enters production. This is at best a very inefficient use of manpower and at worst leads to inter-personal
tensions. These problems can be attributed to an almost total lack of effort dedicated to controlling quality.
Online: The schedule for the online system must allocate sufficient time for commissioning. If there are
many flaws in the logic or implementation of the dataflow system, the MTBF (Mean Time Between
Failure) will be small. Even if the time taken to diagnose each error is small, a delay in the schedule and a
reduction in the subsequent data taking efficiency will result. The possible causes for errors should be
anticipated and the strategy for dealing with them developed. Provision of diagnostic tools will be essential.
Software for measuring operator and data-taking efficiencies, deadtimes etc. will be needed for maintaining
high efficiency once the experiment is brought into operation.
Trigger: The correctness of the software used to implement trigger algorithms must be validated. Any
failure of the trigger software will impact the quality of the physics and therefore the highest standards of
quality control must be followed. Tools for validating the design and implementation of the trigger software
would be invaluable. Tools for evaluating the complexity of different components of the code (e.g.
Logiscope) will indicate which areas deserve special attention and will also indicate where problems are
most likely to occur.
16
page 16
LHCb Software strategy
LHCb Technical Note
Issue:
1
Software process and environment
Reference:
Revision:
Last modified:
LHCb 98-025 COMP
1
6 february 1998
We should also use techniques like visual inspections of architecture and design documents as well as for
code itself, and very importantly, establish written procedures to be followed in case of code changes,
problem tracking and reporting in the style of ISO 9000.
5.3. Documentation
Documentation is an important aspect of software development. It should cover the following aspects:
1. Introduction to LHCb software: Computing environment, tools and methods, responsibilities. This
should allow a newcomer to understand the framework. A particular emphasis should be put on the OO
philosophy and tools, as this is new for almost all collaborators. Training material should also be
available.
2. Documentation for the developer, describing code, functions, data structures and storage format. Most of
it should be automatically extracted from the code itself, to ensure that the documentation is up-to-date.
A system like LIGHT was shown to be very valuable, to easily display codes and link it to other
documentation.
3. Release notes to log the technical changes, allowing tracing back unwanted effects. An updated
documentation must be part of the requirement before a software release.
4. Documentation for the end-user, how to run one of the LHCb applications, how to analyze the data. This
includes also a description of the data structures, and of the tools/packages to access them, from the user
point of view.
The documentation must be easily accessible online (WWW) but also on paper, and with proper indexing.
The preferred text processing system is FrameMaker, although currently LaTeX is used because of its good
support for mathematical equations and Word is used for small documents. The advantages of FrameMaker
are:
it runs on Unix, Mac and PC;
it is recommended and supported by the IT/IPT group;
it works well for large documents;
it is a modern userfriendly, industrial strength product;
equation support is adequate for most non-theoretical physics documents;
it has very powerful text composition facilities, and is very good at positioning figures and tables.
Templates for notes, URD's and TDR's will be made available. All source files will be archived on the Web
server. Documents that will have a lifetime equivalent to that of the experiment will be stored in
SGML/XML.
page 17
LHCb Software strategy
LHCb Technical Note
Issue:
1
Human aspects
Reference:
Revision:
Last modified:
LHCb 98-025 COMP
1
6 february 1998
6. Human aspects
6.1. Migration strategy
The OO culture has to be introduced into new projects very carefully. Some of the issues that have to be
addressed can be summarized as follows:
The investment in current systems needs to be preserved, whilst at the same time legacy thinking needs to
be changed. At present there is a rather limited software production activity, mainly centered around the
SICB simulation program. However with time more people will be involved and so the longer existing
practices are continued the more difficult it will be to make the transition. A strategy for managing the
transition phase must be produced with the highest priority. The Project Plan for Computing [3] describes in
detail how we plan to deal with this, and we reproduce the task schedule for transition to OO in Figure [2]:
Hands-on experience is a pre-requisite for proper learning of object skills. Learning by doing is the best
way to understand object orientation. For this to be effective it is important to assemble the basic tools such
that a suitable OO framework can be given to the novice OO programmer. The scope of these tools should
be at least equivalent to the tools he has been used to using as a FORTRAN programmer.
Intensive training programs should not be embarked on until this software environment is in place and not
until the OO student is ready to practice his newly acquired skills. Training/consultancy succeeds according
to the competence and experience of the consultant.
In most cases there is limited experienced manpower available and one of the goals is to effect knowledge
transfer between staff. In all cases people provide the vehicle for technology and knowledge transfer and
therefore provide the key to success. Mentors with a strong track record of building OO software are
required, preferably in many different contexts (real-time, information systems etc.).
Even though we have people with some considerable OO experience, particularly in the on-line domain, the
technology itself is evolving (and improving) rapidly and so the education process is continuous.
We will benefit greatly from the expertise in the IPT team since this group provides support to individual
projects wishing to start with OTs. They popularize OT through news services, library, and awareness
seminars, in-house training and by maintaining a library of software tools. Over a period of time we can
hope for some direct participation by IPT staff in our projects. Rotation of staff throughout the wider
organization will help to spread experience and will bridge barriers between experiments.
18
page 18
LHCb Software strategy
LHCb Technical Note
Issue:
1
Human aspects
ID
1
Task Nam e
SICB development
3
SICB data production
4
Freeze SICB simulation development
5
Freeze SICB reconstruction development
7
8
SICB disposal
Common Components
Object model LHCB geometry
10
Storage model LHCB geometry (ODBMS)
11
Numerical library (LHC++)
12
Histogramming library (LHC++)
13
Visualisation library (LHC++)
15
Common components ready
Simulation
16
Raw data object model
17
Raw data storage (ODBMS)
18
GEANT4 framework - beta release
19
GEANT4 based SICB development
20
GEANT4 framework in production
21
22
G4 based SICB ready
Reconstruction
23
Object Model for Reconstruction Objects
24
Storage model for reconstruction objects
25
Framework for Reconstruction Program
26
Reconstruction environment ready
27
OO based reconstruction development
28
29
1998
1999
20
O N D J F M A M J J A S O N D J F M A M J J A S O N D J F M A M J
OO environment
9
14
LHCb 98-025 COMP
1
6 february 1998
FORTRAN environment
2
6
Reference:
Revision:
Last modified:
OO based reconstruction program ready
Analysis
30
Object model for Analysis objects
31
Storage model for analysis objects
32
Framework for Analysis Program
33
Object model for physics objects
34
Storage model for Physics objects
35
Analysis environment ready
36
OO based analysis development
37
OO based analysis program ready
Fig. 2 Task Schedule for planning transition to OO programming
6.2. Profile and skills
We need people with a range of competences, equipped with the right skills for the job they have to do:
People with skills in system architecture are needed to define the structure of the software, to choose
technologies and adopt appropriate standards. They must deliver design documents and the guidelines for
software production using the selected technologies. They must have considerable experience of designing
large software systems and a good up-to-date knowledge of computing.
page 19
LHCb Software strategy
LHCb Technical Note
Issue:
1
Human aspects
Reference:
Revision:
Last modified:
LHCb 98-025 COMP
1
6 february 1998
People with skills in software engineering are needed to develop the basic building blocks. High standards
of quality must be maintained, as these will constitute the reusable components. Strict quality control
procedures must be applied for the most sensitive code, such as the algorithms used in the high level
triggers. Reference documents and user guides will have to be produced. They will be expected to have
formal training in methods and tools used to support all phases of the software development life cycle.
People skilled with software tools are needed to select and maintain the software tools used to facilitate the
building of the LHCb software. They must be able to install tools in the standard LHCb environment on all
supported platforms, be able to support physicists in the use of the tools. They will manage the codebase
and be responsible for distribution of code. They will manage production of simulation data and
reconstructions on all recorded data and operate the tools used to keep track of all LHCb datasets.
Physicists must be familiar with the basic tools and frameworks developed by the computing group. They
must be trained to use the standard supported languages and have access to the LHCb datasets. They must
be be able to use the standard LHCb procedures for managing code and data.
6.3. Collaborative aspects
The World Wide Web has proven its usefulness in many different contexts as a cheap and convenient way
of distributing information. Currently the Web plays a significant role in the communication between the
members of the collaboration for:
Distribution and archival of documents, technical notes and other publications in various formats
Data entry and consultation of the collaboration database
Publication of latest news, announcements of meetings etc.
Remailer using special interest groups defined in the collaboration database, with automatic
archiving of emails
News like discussion groups
We foresee that the role of the Web will continue to increase in the near future, providing:
Distribution of software
A tape database
Batch production scheduling
Event display
Net meeting facilities
As a world-wide collaboration LHCb has other special requirements such as video conferencing. It is
understood that CERN is providing a new video conferencing service in the near future that we anticipate
using as required. On the other hand, it should be noted that LHCb has a rather small amount of American
collaborators (where video conferencing facilities are fairly easy to find) and a rather large amount of
Eastern European collaborators (where video conferencing facilities are difficult to find and are expensive
to use). Use of Web conferencing tools may be a cheaper option in certain cases.
20
page 20
LHCb Software strategy
LHCb Technical Note
Issue:
1
Human aspects
Reference:
Revision:
Last modified:
LHCb 98-025 COMP
1
6 february 1998
6.4. Training
Only a small fraction of the physicist community has reached the level of expertise in Object-Oriented
design and C++ programming that is needed to produce high quality and reliable software. This is a crucial
point since a lack of manpower inside the Collaboration with appropriate skills will pose significant
problems. We must take the need for training very seriously which implies that the responsibility for
training organization must be clearly established. Gaining the experience required to produce efficiently
good OO software takes time. In order to gather physicists from the collaboration to the core software
development, it is important to organize this training effort as soon as possible. It is important also to
organize the training outside CERN, taking into account the needs of collaborators from outside institutes.
The manager of the SEG should be helped in his task by local collaborators with the responsibility of
organizing training in their own country.
The lectures of Paul Kunz are a good starting point to gain familiarity with C ++ syntax, and basic OO
principles. These must be followed by at least two series of lectures, with an emphasis on analysis and
design. Another way to get people involved in C++ developments is to provide them with sample codes and
well-defined projects. The analysis package is a good starting point in this respect. Physicists with some
experience in C++ should also spend some of their time in helping C++ beginners, and more formal tutorials
should be organized during the Collaboration meetings and the various software workshops. More formal
tutorials should be organized for sub-system specific developers, on the use of databases for example.
page 21
LHCb Software strategy
LHCb Technical Note
Issue:
1
Current situation and evolution
Reference:
Revision:
Last modified:
LHCb 98-025 COMP
1
6 february 1998
7. Current situation and evolution
7.1. Off-line computing
The public LHCb offline software for simulation, reconstruction and analysis is grouped together in the
SICB package [15]. SICB comprises approximately 100 K lines of Fortran 77 code, representing some 10
person years of work. In addition, physicists in the collaboration have private analysis code. This code will
have to be converted to an OO language.
The production environment is UNIX, running (at CERN) on the CSF and CERNSP computers. The code
manager CVS is used, plus a number of utility scripts. The SHIFT service is used for writing and reading
data onto magnetic tape. We have recently ported SICB to the CERN PC Simulation Facility (PCSF),
running the Windows NT operating system and are starting Monte Carlo production runs on Windows NT.
The favorable price performance ratio of the PCSF could mean that it might be of interest to collaborating
institutes. Windows NT is the most used desktop platform in the experiment today.
LHCb is producing approximately 2 Tera bytes of data for the studies relative to the Technical Proposal.
7.2. On-line computing
There is no public on-line code. For the testbeam we use Cascade, an off the shelf DAQ system. We do not
intend modifying this system for as long as possible, as the testbeam should not become a debugging
environment for the on-line system. The DAQ system is still very far from a detailed design.
We anticipate using of the order of several hundreds of microprocessors that will run the trigger code. The
speed of execution will be the main consideration in the design of the programming environment on these
processors. The current philosophy is to use the PC environment for development, while the processors
where the code will be executed will also be PC-like. These choices should be made in the context of a
shared development with other experiments.
The trigger code (a few thousands of lines) may be reused from the off-line code, if this is properly
designed. Perhaps certain routines will have to be written in a language that is highly optimized for speed
purposes.
7.3. Information management
LHCb has invested a considerable amount of effort in the organization and delivery of its information. We
are running the Microsoft Internet Information Server (http://LHCb.cern.ch) on a Windows NT 4 server,
with the Microsoft Index server's search engine, and Allaire's Cold Fusion to provide an interface to ODBC
compliant databases (we use Microsoft Access). The Java server allows the execution of Java applications
as CGI scripts. Microsoft Frontpage 97 is used to maintain our Web pages.
22
page 22
LHCb Software strategy
LHCb Technical Note
Issue:
1
Current situation and evolution
Reference:
Revision:
Last modified:
LHCb 98-025 COMP
1
6 february 1998
The collaboration database (BWHO) is contained in an MS Access database. It contains data on members of
the collaboration and LHCb documents; all data entry and consultation is done via the Web, using the Cold
Fusion interface to HTML forms. We anticipate that certain aspects of BWHO will change once the Java
interface to the CERN Personnel Database is made available by the AS division.
We have built a Java mail server that allows mailings to be sent to subdetector mailing lists stored on the
Web server. The mailing lists are dynamically composed via a query through Cold Fusion to the BWHO
databse. Mails are archived on the server, and also on the Aleph News server.
As mentioned before in this report, we anticipate that the function of the Web and Java will continue to
grow in the experiment.
page 23
LHCb Software strategy
LHCb Technical Note
Issue:
1
Conclusions
Reference:
Revision:
Last modified:
LHCb 98-025 COMP
1
6 february 1998
8. Conclusions
In this document we have described the software strategy of the LHCb experiment. The main objective is
to reuse designs and code wherever possible. We will implement an architecturally driven design process.
This architectural process will be implemented using Object Technology. We have discussed how this new
technology will affect the LHCb experiment. We aim for platform indepence; try to take advantage of
distributed computing and will use industry standards, commercial software and profit from HEP
developments. We will implement a common software process and development environment, and we have
outlined some possible choices with their advantages and disadvantages.
One of the major problems that we are immediately faced with is the conversion of our current code from
Fortran into an Object Oriented language and the conversion of our current developers to Object
technology.
24
page 24
LHCb Software strategy
LHCb Technical Note
Issue:
1
References
Reference:
Revision:
Last modified:
LHCb 98-025 COMP
1
6 february 1998
9. References

A. Pacheco, LHCb Computing model, LHCb/98-xxx, February 1998

P. Binko, LHCb Computing tasks, LHCb/98-xxx, February 1998

J. Harvey, Project plan for Computing, LHCb/98-026, February 1998

ATLAS Computing Technical Proposal, CERN/LHCC/96-43, 15 December 1996

CMS Computing Technical Proposal, CERN/LHCC 96-45, 19 December 1996

G. Booch, Object Solutions, Addison-Wesley, Menlo Park 1996

J. Rumbaugh et al., Object-Oriented Modeling and Design, Prentice Hall, Englewood Cliffs 1991

E. Yourdon, Object-Oriented Systems Design, Yourdon Press, Englewood Cliffs 1994

I. Graham, Object Oriented Methods, Addison-Wesley, Wokingham 1993

LHC++, Version 1.0 Users Guide, 3 November 1997

F. Rademakers, The Power of Object Oriented Frameworks,
http://root.cern.ch/root/Publications.html, 1996-1997

M. Dönszelmann, WWW Interactive Remote Event Display, http://www.cern.ch/WIRED/, 19961997

E. Gamma et al., Design Patterns, Addison-Wesley, Reading 1995

A. Khodabandeh, P. Palazzi, Software development: people, process, technology, CERN school of
Computing, Sopron Hungary 1195

A. Tsaregorodtsev, The SICB program, http://LHCb.cern.ch/software/
page 25
LHCb Software strategy
LHCb Technical Note
Issue:
1
References
Reference:
Revision:
Last modified:
LHCb 98-025 COMP
1
6 february 1998
Annex A Terms and definition
See ref. [13] for more technical details.
abstract class
A class whose main purposes it is to define a common interface for its subclasses.
application
A collection of components designed to solve a particular problem.
class
A way of organizing (object) instances. Its class defines an object's implementation. The class
specifies the object’s internal data and representation and defines the operations the object can
perform.
component
A self-contained element of software that can be controlled dynamically. It can be re-used and
assembled into applications.
concrete class
A class that is not an abstract class.
conformance
A way of organizing classes.
container
A parent class.
dynamic binding
The run-time association of a request to an object and one of its operations. When a request is sent
to an object, the particular operation that’s performed depends on both the request and the
receiving object. Different objects that support identical requests may have different
implementations of the operations that fulfill these requests.
encapsulation
The only way to get an object to perform an operation, and thus to change the object’s internal
data, is through a message. Because of this restriction, the object’s internal state is said to be
encapsulated; it can not be accessed directly, and its representation is invisible from outside the
object.
implementation
The code and variables that the designer has defined as being available to the instances of the
class.
inheritance
Sharing definitions and data between classes.
instance
An object instance.
26
page 26
LHCb Software strategy
LHCb Technical Note
Issue:
1
References
Reference:
Revision:
Last modified:
LHCb 98-025 COMP
1
6 february 1998
interface
The collection of an object’s methods.
framework
A set of cooperating components that makes up a reusable design for a specific class of software.
In OO technology, a framework provides architectural guidance by partitioning the design into
abstract classes and defining their responsibilities and collaborations. A developer customizes the
framework to a particular application by subclassing and composing instances of framework
classes.
message
A request to an object, identifying a required service without implementing the mechanism.
Messages are often accompanied by arguments (which can contribute to service identification)
and often return something. Messages are the only way to get an object to execute an operation.
method
A service given by an object. Every method declared by an object specifies the method’s name,
the objects it takes as parameters and its return values.
object instance
An object is created by instantiating a class. The object is said to be an instance of the class. The
instantiation process allocates storage for the object’s internal data (made up of instance
variables) and associates the operations with this data. It encapsulates data along with processing
functions. Many similar instances of an object can be created by instantiating a class.
An object is a software agent, with meaning for the problem at hand, characterized by its
providing a well-defined related set of services.
The object possesses a set of variables and a data structure. Its services are related by sharing that
state.
Note the difference between an OO module and a procedural module created in a language such
as Fortran. OO objects have functions that are called methods (or member functions) and states
that are called instance variables (or data members)
parent class
A class inherited from by a subclass. Also called containers.
persistence
Persistent objects continue to exist beyond the lifetime of the process that created them.
polymorphism
The possibility to substitute objects that have identical interfaces for each other at run-time
(through dynamic binding). In other words, the same message can be sent to objects of different
types, while each object responds with its own appropriate mechanism.
reuse
Instead of solving every problem from first principles, expert object oriented
designers/programmers reuse solutions that worked for them (or for others) in the past. Reuse is a
constructive term, implying that a solution is shared in a controlled manner. It does not mean that
a solution is imposed, leaving the programmer without control.
signature
An object’s method.
page 27
LHCb Software strategy
LHCb Technical Note
Issue:
1
References
Reference:
Revision:
Last modified:
LHCb 98-025 COMP
1
6 february 1998
subclass
When a subclass inherits from a parent class, it includes the definitions of all data and operations
that the parent class defines. Objects that are instances of the subclass will contain all data defined
by the subclass and its parent(s).
toolkit
A collection of one or more libraries of predefined software, intended to be used off-the-shelf.
transience
Transient objects only exist during the lifetime of the process that created them.
type
A particular interface.
28
page 28