16
¥ll<}¤»Q'2¤ spokesperson coutactperson Utrecht University, Utrecht, The Netherlands OCR Output C. Balke, W. Lourens International Christian University, Tokyo, Japan Y. Nakagawa., T. Yamagata. SSC Laboratory, Dallas, Texas, USA H. Johnstaid SEFT, Research Institute for HEP, Helsinki, Finland J. Klem DAPNIA-SEI Saclay, Gif-sur- Yvette, France T. Hansl—K0za.necka Rutherford Appleton Laboratory, UK R. W. Clifft, S. M. Fisher NIKHEF, Amsterdam, The Netherlands K. Bos.2, W. Heubers, E. Wassenaar, R. Wilhelm LAL, Univ. de Paris-Sud, Orsay, France C. Arnault, G. Barrand, A. Schaffer Institute of Nuclear Physics, Krakow, Poland A. Sobala KEK, Japan K. Amako, J. Kanzaki, T. Sasaki, Y. Takaiwa University of Edinburgh, UK D. J. Candlin CERN, Geneva, Switzerland C. Onionsl, M. Pimia, A. Poppleton, J. P. Porte, G. Poulard, S. Qian F. Bruyant, M. Dodgson, V. Irmocente, W. Jank, V. Karimaki, University of Birmingham, UK S. O’Nea1e gt. -3 I • Experiments . 7* ‘ " Software Development for LHC •• Object Or1e11ted Approach to March 2, 1994 __ , tj le, @$7, DRDC/P55 SC00000225 IEIIII It ....1./ DRDC /9.. l\\\\\\\\\\\l\\\l\\l\\l\\\l\\\lllll\\\l CERN LIBRARIES, GENEVA

1./ DRDC /9.. SC00000225 , tj le, @$7, March 2, 1994 ... · A. Sobala KEK, Japan K. Amako, J. Kanzaki, T. Sasaki, Y. Takaiwa University of Edinburgh, UK D. J. Candlin CERN, Geneva,

  • Upload
    hanhi

  • View
    214

  • Download
    0

Embed Size (px)

Citation preview

¥ll<}¤»Q'2¤

spokespersoncoutactperson

Utrecht University, Utrecht, The Netherlands OCR OutputC. Balke, W. Lourens

International Christian University, Tokyo, JapanY. Nakagawa., T. Yamagata.

SSC Laboratory, Dallas, Texas, USA

H. Johnstaid

SEFT, Research Institute for HEP, Helsinki, Finland

J. Klem

DAPNIA-SEI Saclay, Gif-sur- Yvette, France

T. Hansl—K0za.necka

Rutherford Appleton Laboratory, UKR. W. Clifft, S. M. Fisher

NIKHEF, Amsterdam, The Netherlands

K. Bos.2, W. Heubers, E. Wassenaar, R. Wilhelm

LAL, Univ. de Paris-Sud, Orsay, France

C. Arnault, G. Barrand, A. Schaffer

Institute of Nuclear Physics, Krakow, Poland

A. Sobala

KEK, JapanK. Amako, J. Kanzaki, T. Sasaki, Y. Takaiwa

University of Edinburgh, UK

D. J. Candlin

CERN, Geneva, SwitzerlandC. Onionsl, M. Pimia, A. Poppleton, J. P. Porte, G. Poulard, S. Qian

F. Bruyant, M. Dodgson, V. Irmocente, W. Jank, V. Karimaki,

University of Birmingham, UK

S. O’Nea1e

gt. -3 I • Experiments. 7* ‘

"

Software Development for LHC•• Object Or1e11ted Approach to

March 2, 1994__ , tj le, @$7,DRDC/P55SC00000225

IEIIII It ....1./ DRDC /9..l\\\\\\\\\\\l\\\l\\l\\l\\\l\\\lllll\\\lCERN LIBRARIES, GENEVA

will be tried and professional training will be organized. OCR Outputenhances a different, and hopefully better, project management. Management toolsof this R&D project. We propose to also study in this project how the OO approachhave been defined in a preceding study and some of which will be defined in the courseThese studies will be carried out with various well—defined prototypes, some of whichAided Software Engineering tools and implementation languages will be evaluated.ied to select the most appropriate for the High Energy Physics case. Some Computerissues of this approach: OO analysis and design. Several methodologies will be studoping the code for LHC experiments. The authors of this proposal will learn the key

We propose to study the viability of the Object Oriented (OO) approach for devel

11 OCR OutputGlossary of acronyms

10Budget and Manpower

Industrial Participation

........5.7 Milestones

5.6 Prototype management

.........55 Teamwork

5.4 Desktop conferencing . .5.3 Consultancy .................52 Training

5.1 Scheme of meetings and workshopsProject Management

Pilot projects

3.4 Evaluation of languages ......

3.3 Evaluation of tools .........

3.2 Evaluation of methodologies ....3.1 Evaluation of the overall approach

Criteria for evaluation

2.5 The Object Management Group .» ..............

2.4 I/ O schemes2.3.3 Other languages of potential interest..................232 C++

................2.3.1 Eiffel

2.3 Implementation languages ........

2.2 CASE tools ................

2.1.4 The Fusion Method .......

2.1.3 The OO—AD methodology ....2.1.2 The Class Relation methodology2.1.1 The OMT methodology .....

2.1 Methodologies for analysis and design .

Areas of research

...............133 ECP / PT

...............132 CN /ASD...............

1.3.1 RD13

1.3 Relation to other groups .........1.2 Content of the proposal .........

................1.1 Introduction

Scope of the proposal

Contents

developments with other software components. This project will result in an evaluation of OCR OutputOMG will be studied and employed where appropriate to allow the compatibility of ourwill vary in scope and evolve with time. Those standards arising from the efforts of the

These investigations will be carried out within the context of a few pilot projects, which

• I/ O and data storage.

c OO languages and

of interest,c Computer Aided Software Engineering (CASE) tools to support the methodologies

o methodologies, possibly with minor extensions and adaptations,

software environment. Our programme consists of investigations of:implementation, and how this approach can best be applied to the HEP reconstructionlearn and understand the different elements of an OO approach to analysis, design andbeyond that depend on our experience at that time. The goal of this proposal is toWe present a work programme for two years in the first instance. Possible developments

1.2 Content of the proposal

model can then be used for the production of the final LHC software.graphically separated groups, and to adopt helpful project management techniques. This

While doing this work, we also hope to develop a style of working together in geocomparisons, as far as possible, with current practices.

to OO methodologies for High Energy Physics (HEP) software. We will make quantitativepropose to continue this work and study the benefits and possible disadvantages of movingthe application of the OO approach to software development for LHC experiments. We

A subgroup from within the ATLAS collaboration has already started to look intowhich aims to provide standards to allow interoperability of OO systems.the existence of the Object Management Group (OMG), representing some 300 companies,reductions in maintenance effort and cost. The industrial interest in OO is reflected bygains in conciseness of source code, clarity and freedom from errors, with correspondingapproach to analysis, design and implementation, and have reported very considerable

Recently large industrial software projects have adopted the object oriented (OO)software to achieve large rejection factors.getting the code right the first time as we will only have one chance and will rely uponalways possible to redo the reconstruction. At LHC we must be more concerned about

LEP experiments have not used complex software as part of the trigger, hence it isin the way that the whole software for an experiment is built.and data acquisition development. We believe that it is now time to also seek improvementschallenge of performing such experiments has already stimulated efforts in detector, triggerexperiment be designed, built and maintained to the highest engineering standards. Theand almost certainly experiment lifetime. It is therefore crucial that all elements of anin detector size and complexity, number of physicists, event size, bunch crossing rateThe LHC experiments will be larger and more complex than those at LEP and HERA,

1.1 Introduction

1 Scope of the proposal

areas. OCR Output

The OMG is an industrial consortium which is considering standardisation in all theseon I/ O technology.concern communication between applications and object persistency, both of which rely

The use of OO applications requires management facilities for their objects. This willthe code required for implementation in the chosen programming language.to automate this in the context of a chosen methodology. Such tools can generate part of

The life cycle is actually an iteration through the different phases and CASE tools helpis described using graphical and other higher level languages to represent the abstractions.and design. Specific models are built, showing different views of the desired system which

A methodology is the set of methods and tools which supports the process of analysisimplementation languages, the 1/ O problem and the infiuence of the OMG in each area.in mind we have chosen to study methodologies and those tools which support them,of OO and later to assess whether or not OO is the right approach for HEP. With this

Our work is intended to allow us to make informed choices in each important areathe concepts of the problem.of thinking which encompasses all aspects of the life cycle by abstracting, i.e. identifyingments, designing the system, and coding and maintaining it. The OO approach is a wayphases of specifying the requirements in a problem statement, analysing those requireSoftware development is conventionally described as following a life cycle which includes

2 Areas of research

continued cooperation.in particular the installation of tools and the provision of training. We look forward toWe have benefited from the support offered to us by members of the ECP/PT group,

1.3.3 ECP / PT

include physics analysis tools like PAW in our initial work.discussions and possible collaboration. In the scope of this proposal we do not want to

conformant with the OO philosophy. We will follow these developments closely and seekcode. We are aware that there is interest within the CN division to try to make GEANTpackage. In our studies we will initially use data generated by GEANT as input to ourThe detector simulation for LHC experiments currently relies largely on the GEANT

1.3.2 CN/ASD

make sure that we join efforts on this subject and come to a common solution.RD13 members in our meetings. OO databases are part of the studies in RD13. We willware, as part of the work of RD13. We have greatly benefited from the participation ofA corresponding study is specifically directed towards trigger and data acquisition soft

1.3.1 RD13

1.3 Relation to other groups

with traditional methods.

the benefits and drawbacks of using OO technologies for HEP software systems, compared

Hewlett Packard company and has been used for the developments of some of their own OCR Output[5] describes a methodology for analysis and design which has been developed by theThe book ‘Object Oriented Development, The Fusion Method’ by Derek Coleman, et al.

2.1.4 The Fusion Method

model of OMT by a model which shows messages between objects.Booch [4], who is one of the pioneers in the OO design world. He replaces the functionalThis ‘Object Oriented Analysis and Design’ methodology is described in the book by

2.1.3 The OO-AD methodology

also provides dynamic and functional models.which is a group of classes and allows classes to be hidden inside a schema. ‘Objecteering’ Aand is described in the books by Ph.Desfray The model includes the notion of schemacompany. The methodology is based on an object model which, like OMT, is ER basedThe Class Relation methodology is supported by the ‘Objecteering’ tool from the Softeam

2.1.2 The Class Relation methodology

methodology.days was given at CERN by General Electric, the company which originally developed the

OMT is described in the book by James Rumbaugh et al.[2]. A training course of threemethods (services offered by objects of a class) which must then be assigned to classes.extra notation, to show scenarios of use of the system under development in order to findfunctional models, which resemble traditional data How diagrams with a small amount of[1] are used to show the transition from one state to another. OMT advocates a set ofdescribes the behavioural aspects of the individual classes. Nested finite state machinesone has to identify the objects in the system and how they are related. The dynamic modelstructural parts of the system and the relationships between them. To build this modelsystem. The object model (which is similar to the ER model) describes the static or ___The Object-Oriented Modeling Technique (OMT) [2] uses three models to describe a

2.1.1 The OMT methodology

Fusion method looks very promising as well.far given most attention to the OMT and ‘Class Relation’ methodologies. However thethem in pilot projects and others by reading the corresponding documents. We have so

Below are some of the methodologies which we have studied so far — some by usingto identify the ideal methodology or ccombination of methodologies for HEP applications.Trying several of them for the analysis and design of some realistic prototypes will allow usoping quite rapidly. Though similar in some aspects they differ considerably in details.

OO methodologies have been developed over the last five years. They are still develdescribes only data and not how to process them.was successfully applied in HEP experiments such as ALEPH and ZEUS. The ER modelIn the eighties the entity relationship (ER) model, which goes some way towards OO,Several analysis and design methods have been published and used with variable success.

2.1 Methodologies for analysis and design

or if a postcondition fails when leaving, an exception is raised. OCR Outputtions upon entering and leaving a method. If a precondition fails upon entering a method,Preconditions and postconditions, both integral parts of the language, implement asserparametrized classes, assertions, exception handling and automatic garbage collection.close link between design and implementation. Main features include simple syntax,Eiffel was designed by Bertrand Meyer [6] to follow pure OO principles. It allows a

2.3.1 Eiffel

C++ for its world wide acceptance.analysis environment. Our main interest so far has been in Eiffel for its elegance andinterest not so much for the reconstruction code but rather for the interactive physics

The earlier OO languages were normally interpreted. These languages are still oflanguages to interact.

follow the rules laid out by the OMG it should be easy for objects represented by differentto be sure that the language chosen can easily be interfaced to other languages. Also if we

To be able to make use of existing (FORTRAN) code and other external code we haveharder to read and to correlate with the design.profit fully from the possibilities which the OO approach offers and the code would besome of the constructs would then become very complicated. One would be unable toIn principle an OO design could be coded in a non-OO programming language, however,

2.3 Implementation languages

justified for the different tools.for those not originally involved in developing it. We will study how much this claim isconvenient it is to use. Tools claim to make it easier to understand the design of a systemhas to be studied to what extent the tool covers the corresponding methodology and howuse them for prototype work and evaluate them following the criteria described below. Itanalysis and design for the code we have to write for the LHC detectors. We intend to

One of the goals of this R&D work is to learn how to use those tools effectively forpossibly using meta-case technology.some simple prototypes which are described later. We consider also building our own tool

We have some experience with a tool supporting OMT and the Objecteering tool onthen for the generation of code.They can often be used for the assignment of attributes and methods to the classes anding the classes and their relationships and have ways to assign names and cardinalities.sophisticated hypertext format. They generally support at least the object model describSome tools include the problem statement in the simple form of flat text, others in a moreThe tools provide a graphical user interface to support the life cycle described above.

2.2 CASE tools

methodologies.

software projects. This methodology claims to be a ‘fusion’ of the good concepts of other

OODBMS interface. OCR Output

takes care of inter—application object communication and could be used as the basis of anOne OMG standard is CORBA (Common Object Request Broker Architecture) which

tions for commercially available object environments}world—wide organisation dedicated to producing a framework and specificability, reusability and interoperability of software. The OMG is the leading"The Object Management Group (OMG) is dedicated to maximising the porta

statement:

The OMG was formed in April 1989. It has now some 300 members and has the mission

2.5 The Object Management Group

data taking.Good commercial solutions to the I/O problem should be available by the time of LHC

our work with them.

important role in the project. They are also being studied by RD13 and we will coordinateObject Oriented Data Base Management Systems (OODBMS) should also play an

solution for the large data volume of LHC.want to build, we must consider the short term solutions without pretending to find thewill watch the progress of this work. However, because we need I/ O for the prototypes we

There are plans to work on an evolution of the Zebra I/ O system towards OO and weproduced at LHC.1/ O and data storage are difhcult and critical areas as very large volumes of data will be

2.4 I/O schemes

Sather is an academic development derived from Eiffel.correct for certain deficiencies and omissions in C++. It is partly interpreted.

C+© is a new language from AT&T Bell which is not a superset of C and claims tolanguage so it will become genuinely object oriented.has been established which is expected to include inheritance and polymorphism in thecontrol system. The ANSI standard has to be reviewed every 5 years, so a project Ada-9xis, the language used in many very large projects such as the North American air traffic

Ada was initiated and used by the U.S. Department Of Defense. It has been, and stillbeing a good language to grasp the OO point of view.OO language in that everything is viewed as an object, even integers. It is reported asXerox. Smalltalk is both a language and a software development environment. It is a pureSmalltalk is an interpreted language which was created in 1967 by a research group of

2.3.3 Other languages of potential interest

people know it and that many class libraries and tools exist.commonly used language in the software industry which has the advantage that manyimportantly OO programming features, amoungst other features. C++ is by far the mostsome sense C++ is a better C. It provides type checking, overloaded functions and mostC++ was designed by Bjarne Stroustrup at ATXLT Bell Labs [7] and is a superset of C. In

2.3.2 C++

generate code in the chosen programming language. OCR Outputfacility with which this can be done becomes a criterion. Finally the tool must be able toand use. It may be necessary to customize a tool to our specific needs, in which case theIt is important that the tool effectively supports the methodology and is easy to learn

3.3 Evaluation of tools

comprehensible for non-specialists such that new people can understand the code.described by the model, and c0mprehensibility— are the diagrams used by the methodologyCriteria for the judgement of methodologies are completeness - can the problem be fullyto watch new methodologies as they are published during the lifetime of this proposal.on the most recent set because they seem to learn from each other. We will continueor less different methods have been published and used up to now. We will concentrateappropriate to the problem of event reconstruction in high energy physics. Some ten moreFirst we need to evaluate which of the methodologies for analysis and design are most

3.2 Evaluation of methodologies

inevitably be evaluated only through qualitative impressions gained in the pilot projects.We hope to get quantitative estimates for some of these criteria, while others will

to accept the OO approach and its consequences on the way of working.from the existing framework? Acceptability refers to the willingness of the collaborationa new detector element has to be incorporated into the code, how much can one profithas always been advertised as one of the important advantages of the OO approach. lfto other changes in requirements which will certainly occur. The concept of re-use of codecriterion judging how well the code can be adapted to changes in the detector layout andto massively parallel processor systems for which threads are needed. Adaptability is adrastic changes than going from operating system n to n+1 like, for example, changingthe package to a new platform. On the long time scale for the LHC we may foresee moredifficult to measure on a short time—scale like maintainability, e.g. how easy it is to port

However we feel that other criteria are at least equally important but will be moredevelopment time, actual development time, code size and ease of implementation.FORTRAN. Some obvious points of comparison are correctness, performance, estimatedprograms are obtained, with traditional high energy physics programs typically written inprotoype programs produced in the pilot projects, as well as the means by which theseAn overall judgement of the OO approach will be primarily based on a comparison of the

3.1 Evaluation of the overall approach

will evolve with experience.as applied to the HEP environment. This is not meant to be a complete list, but one thatWe present here an initial set of criteria by which we intend to evaluate an OO approach

3 Criteria for evaluation

acquisition, reconstruction, physics analysis and commercial products).guarantee a good link between all software components we will use (e.g. simulation, data

In this project we will study how our software could follow these specifications to

work. OCR Output

ologies, tools and languages. They will also provide an ideal introduction to OOe Smaller pilot projects will be used to do preliminary comparisons of different method

Other pilot projects will have different aims:pattern recognition algorithm.ibility of the methodology will be tested by extending the model to implement a differentgeneral experience of both the methodology and the language. In a second stage the fleximplemented using Eiffel. The first stage of this prototype should allow us to build updesigned using the Class Relation methodology with the Objecteering tool and is beingwill include shower detection, pattern recognition, track fitting and graphics. It is beingready underway, will reconstruct electrons in the barrel region of the ATLAS detector andand then carry out well defined subsets of the offline event analysis. One such project, alThese packages will read data from the ATLAS or CMS GEANT simulation programs

Efforts will be directed towards the writing of prototype reconstruction packages. Atechniques in HEP.Later work will reach a scale which should allow to show the suitability (or not) of OOdetailed assessment will be made as prototypes become both larger and more complex.well as providing information for assessments of methodologies, languages and tools. Morewill concentrate on trying out and gaining experience in applying OO techniques to HEP asMost of the effort of this R&D proposal will go into prototype development. Initial work

4 Pilot projects

Suitability for large projects This is a combination of the above factors.

the compiler and supporting tools allow changes to be made quickly.Fast development cycle This requires that the code is inherently readable, and that

Performance The compiled code must execute quickly.

Openness It must be easy to interface to other languages.

compiler and not at run time.is doing what it is expected to do. Coding errors should be found, if possible, by the

Robustness of generated system One must have confidence that the produced code

writing and reading and so the code is more likely to be what was intended.Simple syntax A simple and regular syntax makes the language easier to learn for both

not only the compiler but also associated libraries.Standard It must be easy to move code from one machine to another. Standards affect

opment environment.

Libraries and support tools Libraries should be available as well as a suitable devel

multiple sources and at affordable prices.Availability of compilers Compilers should be available on different platforms, from

emotional, so we must have clear criteria. Some of the following points are related.Though the language ought not to be a very important matter, it may be the most

3.4 Evaluation of languages

DEC have shown interest in joint projects in this field. OCR Outputindustry to test their platform specific products. Hewlett Packard, Silicon Graphics andon hardware which supports those tools. We will seek collaboration with the computeruse public domain tools like vat (for audio) and wb (a white board tool) and to standardizetime. Some testing has been done and the technique looks promising. It is our intention toseparated. It also allows for small desktop conferences for a limited number of people at apeople who work together on specific parts of the project even if they are geographicallygreat value to this project. It will make person to person communication possible forWe believe that the audio and video capabilities of modern Unix workstations will be of

5.4 Desktop conferencing

and at the larger workshops to monitor how the project evolves.that CERN could help us to identify a specialist to be present at the collaboration meetings

Another sort of consultancy will be needed for project management. We would hopeon the subject or tool in question.just learned. However, after a while the need will arise for contact with some specialistscourse on a specific subject, people will go off and work on their own with what they have

There will be a need for technical assistance or consultancy. For example, after a three day

5.3 Consultancy

two to three courses (of three to four days) per year.these training sessions. It can be expected that the members of this project will followhope to make use of the knowledge available at CERN to help us to select and organizeengineering, OO analysis and design, methodologies, tools, project management etc. Weexperience from preceding studies it is necessary to regularly follow courses on softwareto the level where one can contribute significantly to the project. Even for those who haveFor some authors of this proposal this is a new held and training is a good way to get up

5.2 Training

specific subjects or projects. These workshops will be held where it is most appropriate.Each year there will be four one-day collaboration meetings at CERN and workshops on

5.1 Scheme of meetings and workshops

5 Project Management

should only be envisaged after the satisfactory completion of several prototypes.sure that OO software can cope with the unexpected. However it is felt that this work

would have the advantage of subjecting groups to definitive time pressures and makingThe possibility of building test beam analysis software is also being considered. It

places.

partition our work and how to coordinate small projects being developed in differentto make good use of the available manpower and at the same time teach us how toFFREAD, the package to read datacards) will be defined. These projects allow us

• Additional small projects such as an OO program control package (basically replacing

industry. We will seek contact with the relevant companies to discuss other joint projects. OCR Output

in our proposal other possible projects for collaboration with the computer and softwarewill be discussed with HP if a joint project can be defined. It is not difficult to identifyin close collaboration with HP and is by inside the company for program development. Itopment environment based on Softbench 3.0. The Fusion CASE tool has been developedin a joint project with ATLAS, has shown interest in introducing their OO software develY/Ve intend to generate interest in the computer industry for our project. Hewlett Packard,

6 Industrial Participation

come to an overall evaluation of the OO approach for reconstruction software in HEP.to study the impact of such changes. After the second year we should be in a position toflexibility has been achieved. It is possible that a different tool and language will be used A

In the second year we envisage a major upgrade of the full scale prototype to study ifwith a proposal for changes for subsequent years.technologies used. After the first year we will evaluate the project management and comewhich better describes our criteria for evaluating the different stages of design and theother technologies like tools, languages, etc. We will discuss and prepare a document

Moreover we plan to have small prototype projects designed to be used for testingcoding and testing can be evaluated.will be coded and tested with data so the full cycle(s) from analysis and design throughproject on which we have gone through a few cycles of analysis and design. This prototypepilot projects. It is our aim to achieve in the first year at least one completed prototypeIt is difficult to define milestones for the learning part of this proposal but less so for the

5.7 Milestones

as an eventual evolution to the Distributed File System of the Open Software Foundation.in relation with the newly adopted scheme of using Andrews File System in HEP as wellwe plan to use Concurrent Versions System (CVS). It has to be seen how this can be used Aorganising, peer reviews and documentation. For code maintenance and version controlcan be linked together to a working program. A person will be responsible for testing,will maintain a working version of each pilot project, such that at any time the partsideas have been discussed but need further thinking. One person must be identified whoIt will be discussed how prototypes can be best maintained and further developed. Some

5.6 Prototype management

plan to identify those tools, to obtain them and to learn how to use them for our work.ready in time. Many tools are used in industry for this sort of project management. Weby small teams. However, in the end, all the parts should fit together and should all bethat isolated projects will be identified for analysis and design which can be worked onan environment in which we will do better than in the past. It is inherent to this approachbelieve that the OO approach, together with modern techniques of communication createwhich is not new in high energy physics and has never been solved completely. However, weWorking together on this project with people who are in many different places is a problem

5.5 Teamwork

10 OCR Output

meetings or workshops per year outside of CERN.to meetings when their presence is essential. This assumes an attendance at threeused on an ad hoc basis for people from institutes with limited resources to travelThis item is mainly for the CERN participants on the project, but should also be

Travel: kCHF 70 per annum

consultant should be available for discussion and guidance afterwards.system analysis and design. In addition, to benefit the most from training courses athe workshops, and should be able to advise us primarily on project management anddays/year. A consultant should be present at the main meetings and during some ofIt is essential to have software consultants following the project for around 50Consultancy: kCHF75 per annum

databases. This assumes an average of 10 days training for 40 people.methodologies and on more specialised items, such as specific CASE tools and OOtraining office at CERN, on software project management, on analysis and designIt is the intention to set up a series of courses and training, in collaboration with theTraining: kCHF120 per annum

kCHF16 for one licence).and CASE tools. CASE tools are relatively expensive (e.g. Objecteering costsThis includes the cost of programming environments like (HP) Softbench, compilers,Software licences: kCHF200 per annum

the CERN people engaged in the project, particularly during the OO workshops.and other equipment which would enable people from outside to work closely withThis would allow us to equip a large oiiice at CERN with workstations, X terminals

Infrastructure: kCHF100

physicist with experience in software technologies.two of them could be research fellows, but at least one of them should be a senior

core group of people at CERN to work on a full time basis on the project. One or

software commitments in ATLAS and CMS. It is however felt desirable to create a

All of the people from CERN participating in this project have other importantmanpower: 3 full time people at CERN

Manpower and resources required are:given by CERN at an earlier stage of the research.consultancy, plus office space with workstations. Some of the support has already beeneventually have in LHC computing by centrally providing software licences, training andsible for the infrastructure for its people. We expect CERN to play the role that it shouldFollowing the DRDC recommendations, each of the participating institutes will be respon

7 Budget and Manpower

1]. OCR Output

Zebra Data Structure Management PackageRD13 R&D project no.13 : A Scalable Data Taking System for LHCR&D Research and Development

PAW Physics Analysis WorkstationOODBMS Object Oriented Data Base Management System

OO-AD Object Oriented Analysis and Design

OO Object Oriented

OMT Object—Oriented Modeling Technique

OMG Object Management Group

LEP Large Electron Positron Collider

LHC Large Hadron ColliderInput, OutputI / O

HERA Hadron Electro Ring Anlage

HEP High Energy Physics

GEANT GEometry ANd Tracking, a detector simulation package

ER Entity RelationshipElectronics and Computing for Physics, Programming TechniquesECP / PT

DRDC Detector Research and Development Committee

CVS Concurrent Versions SystemCN / ASD Computing and Networking, Application Software and Databases

CMS Compact Muon Solenoid

CORBA Common Object Request Broker Architecture

CERN European Organisation for Nuclear Research

CASE Computer Aided Software Engineering

ANSI American National Standards Institute

AFS Andrews File System

Acronym Explanation

8 Glossary of acronyms

12 OCR Output

[7] Bjarne Stroustrup, The C++ Programming Language, 1991 (2-nd edition).

Bertrand Meyer, Object-oriented Software Construction, 1988.[6]

Derek Coleman, Object Oriented Development, The Fusion Method, 1994.[5]

ISBN 0-8053-5340-2.

Grady Booch, Object Oriented Analysis and Design with Applications (2-nd edition),[4]

Phillipe Desfray, Object Oriented Modeling, Addison Wessley, 1994.Masson, 1992,

Philippe Desfray, Ingenierie des Objets, approche classe·relation, application a C++,[3]

James Rumbaugh, et al., Object-Oriented Modeling and Design, Prentice Hall, 1991.[2]

puter Programming 8 (1987).David Harel, Statecharts: a visual formalism for complex systems, Science of Com[1]

References