The Eclipse Object ManagementSystem

by A. Alderson, M. F. Bott and M. E. Falla

Configuration management is a vital element in successful softwaredevelopment. Automation to assist configuration management will beof great benefit in improving productivity and quality in softwareproduction. Eclipse is an integrated project support environmentbeing developed as part of the Alvey Programme. The Eclipse ObjectManagement System provides automated assistance for configurationmanagement. This paper describes the approach taken in Eclipse andgives details of the concepts embodied in the Eclipse ObjectManagement System.

1 Introduction

Configuration management is defined as'the discipline of identifying the compo-nents of a continuously evolving systemfor the purposes of controlling changes tothese components and maintainingintegrity and traceability throughout thelife cycle' [ 1 ]. It is a vital service to everyphase of the life cycle and to the projectcontrol function. It must record, supplyand control the information on which, andthe context in which, all other tools andmethods of the life cycle operate.

Configuration management must re-cord the history of all information used bythe project to enable traceability. It mustalso incorporate change control into thehistorical record to ensure security andintegrity. At all times all outputs from thelife cycle must be of known status and thelocation of all copies must be known. Thecost of failure in configuration manage-ment can be severe. The products mayprove unmaintainable and operationallydeficient.

Configuration management requires ahighly disciplined approach to develop-ment, and large quantities of informationmust be collected, maintained, controlledand related to the continuing evolution ofthe system. It is clear that computer assis-tance, particularly in the case where acomputer is used as the host supportenvironment, should be advantageousand achievable.

Eclipse is an integrated project supportenvironment (IPSE) which is beingdeveloped by a consortium led by Soft-ware Sciences Ltd., a.nd supported by theGK Alvey Programme. The other mem-bers of the consortium are CAP (Scien-tific) Ltd., Learmonth Burchett Manage-ment Systems, the Universities ofLancaster and Strathclyde and the Univer-sity College of Wales, Aberystwyth [2].

In creating IPSEs the software industryis building the context in which tools toautomate the production of software willrun. One of the most important elementsof that context must be configurationmanagement.

This paper describes the approach toconfiguration management taken byEclipse and gives details of the EclipseObject Management System whichimplements that approach.

2 Automating configurationmanagement

In 1983 the GK Department of Trade andIndustry, the National EconomicDevelopment Office and the NationalComputing Centre produced the STARTSguide [3] with the aid of British industry.The guide provides advice on choosingsoftware tools for managing and control-ling size and complexity. STARTS identi-fied configuration management as amajor area in which productivity could be

Software Engineering Journal January 1986

improved by the provision of automatedtools.

The guide highlighted two unexpectedfacts. The first was the considerable dis-agreement concerning the meanings ofsome configuration terms. The second,and undoubtedly related to the first, wasthe scarcity of suitable tools with which toautomate control.

Configuration management has beenformulated as a set of management goalsand administrative procedures focusedon various terms such as configurationbaseline, status accounting, configura-tion identification and change control.Successful 'paper' systems have beenoperated [4]. Simple transformations ofthese from paper to use computerdatabases are possible. However, thesemiss the important opportunity for auto-matic data collection from the develop-ment process itself, which would assist inthis most onerous and error-prone aspectof configuration management.

Software development focuses uponphases such as specification, design, cod-ing, testing and maintenance. It deals withsource code, object code, compilation,link-editing and modules. In order forconfiguration management to function amapping must exist between terms usedby managers and those used bydevelopers. Without this, effective datacollection is impossible. Unfortunately it isin the developer's domain where defi-nitions of important terms such as ver-sion, variant and revision do not findwidespread acceptance (even the appro-priate British Standard [ 1 ] uses but doesnot define version).

A tool developer may, of course,choose some consistent set of definitionsof these terms and define a completemapping. However, this could lead to aproduct which is significantly at variancewith the working practices of a large partof the potential market. The desire toavoid this difficulty has led us to seek an

39

underlying model of the softwaredevelopment process onto which variousmeanings can be superimposed.

3 A model of the softwaredevelopment process

We take the view that software is createdby a series of transformations of one rep-resentation of the required system intoanother representation. In the macro view,requirement specifications are trans-formed into functional specifications, intodesign specifications and into code. In themicro view, source code is compiled toobject code which is link-edited intoexecutable binary. In the micro view,many of the transformations can be car-ried out automatically by software tools[5]. It is a goal of software engineering toextend the number of automatedtransformations.

We use the term 'object' to denote thesmallest unit of information manipulatedby our configuration management sys-tem. A transformation takes input objects(such as an Ada program library and anAda compilation unit) and produces out-put objects (such as an updated Ada pro-gram library and a listing). Thetransformation may be subject to variouscontrol parameters (such as 'optimise'). Itmay also depend indirectly on the use ofother objects (such as a particular versionof a compiler, operating system or evenhardware).

The transformation obviously is meantto model software tool execution, but itworks equally for processing undertakenby a human. Where the transformation isby tool execution we are in a positionautomatically to record the processing.We can record input objects, outputobjects, parameters and uses of otherobjects. For 'human' processing thesemust be recorded manually.

A transformation is the means by whichthe objects that are its outputs are derived.Each object has its derivation describedby the transformation which produced it.Whenever a transformation occurs a deri-vation record is created in the databaseunderlying the Eclipse Object Manage-ment System. The derivation record re-cords the identity of the transformationinvoked and its parameters. This deriva-tion record is then linked to the databaserecords relating to the input objects, theoutput objects and other used objects.

By recording, either automatically ormanually, each transformation and byrelating the inputs, outputs, usages andparameters together, we record the 'deri-vation' of the output objects. Since everyobject is the output of some transforma-tion, a complete derivation network isconstructed. The derivation network con-tains all the information needed to recre-ate any object recursively from its

precursors. The derivation network alsoenables impact analysis. By recording inthe derivation record inputs which are notoperated on by the transformation butwhich are related to it, we may relatechange control records and projectactivity records.

Eclipse is built on the SDS2 databasesystem developed and marketed by Soft-ware Sciences Ltd. and designed specifi-cally to support software development bylarge teams [6]. SDS2 employs a binarysemantic data model with bi-directionallinks. Data fields are inherently variablelength and a wide variety of data types issupported, including user-defined enu-merations and sets of links and sub-records.

As well as the database system, SDS2includes a sophisticated terminal inter-face supporting database update andbrowsing, a query language and appli-cation programs to support tasks such asactivity scheduling.

The fact that links in SDS2 are bi-direc-tional allows the network of derivation re-cords and object records to be traversedeasily in any direction. Any path throughthe derivation network consists of alter-nating derivation records and objectrecords.

4 Objects and items

The term 'object' is used to denote a unitof information stored and managed byEclipse. An object normally consists of acollection of control attributes togetherwith a 'body' containing user informationin any appropriate representation (forexample source code, natural languagetext, object code). In certain cases thebody may be absent. The definingcharacteristic of an object is that it is thesmallest unit that can be identified by theEclipse naming scheme and that can bemanipulated by the control and accessprocedures.

Objects, as we have described them,are adequate for the major purposes ofconfiguration control. They can representall outputs of the life cycle, enabling statusand location to be recorded. Their incor-poration in the derivation networkprovides for complete traceability. Relat-ing change control and project manage-ment records to the derivation recordsprovides for security and integrity. How-ever, there are issues relating to assistingthe development work itself which need tobe addressed. To illustrate this we willconsider the coding phase of softwaredevelopment.

In coding, a design is transformed intosource code. The source code will then becompiled. The compilation may finderrors. The source code will be edited andthen compiled, say successfully, to createan object code object. In this process two

source code objects and one object codeobject have been created. It is clear thatthe developer will consider the two sourcecode objects as two manifestations of thesame thing, and may, according to prefer-ence, refer to them as revisions, versionsor variants of that thing. Whatever thecase, the developer will wish to have aconvenient way of expressing and usingthis idea.

What is required in general is that theuser can give names in his commandswhich are bound to particular objects atthe time that those commands areexecuted. Different bindings of the samenames may occur for each separateexecution. Thus 'compile fred' before andafter 'edit fred' will cause different objectsto be compiled, i.e. those correspondingto the source of 'fred' before and afterediting (of course, any derivation recordscreated always reference the specificobject which was bound at the time ofexecution). Eclipse allows the user todefine names and associate objects bymeans of the synonym concept describedin the next Section.

Eclipse also allows objects to begathered into collections by associationwith 'items'; with the exception of 'orphan'objects (see Section 8) every object mustbelong to precisely one item. Eclipse thenallows the user to identify the requiredobject by identifying its owning item andthen describing how to select the requiredobject from among those owned by theitem. This is discussed further in the nextSection.

5 Naming

The basis of the naming scheme used inEclipse is the familiar tree structure; thenodes of the tree are known as 'cata-logues' and the leaves are items. The rootof the tree is a catalogue always known asOMEGA. Items and catalogues can be ref-erenced using a full path name in theUNIX manner and with a similar syntax.

An object may be named by naming theitem to which it belongs and then by giv-ing a rule for selecting the required objectfrom among those attached to the item.The rule consists of specifying the value ofone of the attributes of the objects. Theobject with the specified value in thatattribute is selected. All objects have theattribute CREATED, giving the date andtime at which the object was created, andthis can therefore be used to identify theobject. Many projects will wish to use aversion numbering or naming scheme oftheir own. They may achieve this byincluding an appropriate attribute in thedatabase schema.

However, the path name and theattribute value methods of naming can beinconvenient, so the more general andflexible concept of the synonym table has

40 Software Engineering Journal January 1986

been added. A synonym table defines amapping from a set of user-definednames to objects, items and catalogues.For items and catalogues, a synonymtable defines a user name as being a syn-onym for the path name. For objects, thesynonym table defines a variable-size,one-dimensional array of objects indexedby the sequence in which they wereentered into the table.

This array allows objects to be referredto by a user-defined name and an indexnumber. A positive value is an index fromthe start of the array; a negative value is anindex from the end of the array; no valueor zero indicates the last element of thearray. Whenever a name in a synonymtable occurs in the place of an outputobject in a transformation invocation, theidentity of the object produced is added tothe end of the corresponding array. In thisway the last entry in the array can be usedto correspond to the notion of latestrevision, version or variant.

A synonym table itself belongs to a cat-alogue for naming purposes in the sameway as an item. A synonym table is not anobject, but provision is made for record-ing a synonym table as an object and forrestoring a synonym table from an object.

The user has a further degree of controlover the binding of names by means ofthe search list. A search list is a sequenceof catalogue names and synonym tablesnotionally terminated with OMEGA. Whenseeking to bind a name, each entry in thecurrent search list is searched insequence until the first occurrence of thename is found. The search list defines thecontext in which the user is working.

6 Control attributes

Every unit is represented by a record inthe underlying SDS2 database. The rec-ord contains fields corresponding to thecontrol attributes of the unit, as well ascertain other control information used byEclipse. In the case of an object with abody, the body is held separately in anarea of the host operating system file storeprotected against normal user accessexcept via Eclipse. Control attributes canbe of any of the data types supported bySDS2.

Comparatively few control attributesare demanded by the Eclipse Object Man-agement System; the more significant ofthese are described below and in laterSections. Many tools, on the other hand,require a large number of controlattributes. In particular, control attributesof type link or set of links are the mecha-nism which tools use to record relation-ships between units.

It is also likely that individual projectswill want to introduce control attributes fortheir own purposes. Examples might bethe name of the person responsible for

the unit or a version identifier as alreadyreferred to. The underlying SDS2 facilitiesare sufficiently powerful to enable suchattributes to be exploited without the needfor special-purpose tools.

6.1 Transient objects

Once an object has been created, itcannot normally be deleted, although itmay be archived or even removed fromthe naming tree. However, if the item towhich it belongs has the attribute TRAN-SIENCE-PERMITTED' then the objectcan be created with the attribute TRAN-SIENT; such an object can then bedeleted by any user with the appropriateaccess permission. An item may also begiven the attribute TRANSIENCE-DEFAULT', in which case all objectsbelonging to that item which are createdsubsequently are given the attributeTRANSIENT', unless it is specificallystated otherwise.

6.2 Objects without bodies

Objects without bodies have theattribute 'BODILESS'. The main use ofsuch objects is to represent particular ver-sions of software (or hardware) which aresignificant from the point of view of con-figuration control but which cannot con-veniently be held or represented as thebody of an object. Examples might beversions of the host operating system orthe target processor.

A second use of bodiless objects is torepresent objects which cannot yet becreated. This might be done, for example,when a production plan is formulated fora complex derived object (see Section 8)and it is desired to run analyses of thisplan.

6.3 Object types

Objects are assigned a type which isheld as a control attribute of the object.The only built-in type is the universal typewhich is the default type for all objects. Aproject will normally define its own set oftypes, but a tool may very well require thatcertain types exist — a Mascot (7) toolmight require, for example, that an inputobject should be of type ACP (activity,channel, pool) diagram.

Type names are global to an instance ofan Eclipse database. Types are structuredas a tree by the relationship of specialisa-tion; type A is a specialisation of type B ifevery object of type A is automatically typeB. All types are specialisations of the uni-versal type. Eclipse enforces the rule thatif type A is a specialisation of both types Band C, then either B is a specialisation of Cor C is a specialisation of B; this is suffi-cient to ensure that the set of types formsa tree.

Type checking of objects is carried outby Eclipse when executing transforma-tion procedures (see Section 7) and wheninvoking tools. Type compatibility isdefined modulo the type tree; i.e. if anobject of type A is specified as requiredthen the object provided must be of type Aor of a type which is a specialisation of A.Type information is also used to decidewhat data compression techniques, if any,should be applied when storing objects,for example whether to use differencingas in SCCS [8] or whether to apply Huff-man coding techniques to programminglanguage text.

7 Transformation procedures

A transformation is initiated by the userinvoking a transformation procedure. Atransformation procedure is held as anobject in the Eclipse database (with thecontrol attribute TRANSFORMATION-PROCEDURE'). Its body consists of aninterface specification together with a setof host operating system commands, in aslightly modified form. The interfacespecification identifies the names andtypes of the formal parameters to thetransformation procedure; these are inputand output objects and character stringarguments.

When invoking a transformation pro-cedure, the user supplies names as actualparameters. Eclipse binds these namesas discussed in Section 5. Eclipse checksthe types of the objects as discussed inSection 6.3, and then makes the bodiesavailable in host operating files. Refer-ences to formal parameters within thehost operating system commands arereplaced by the names of these files (or, inthe case of output objects, the names oftemporary files to be used to hold them).These commands are then executed bythe operating system. On completion ofthese commands Eclipse moves the out-put objects back into the database andupdates the synonym tables as required.

Transformation procedures form themechanism which allows existing toolsavailable under the host operating systemto be used by Eclipse. At the same time itavoids the need for the ordinary user to befamiliar with that operating system andretains a large measure of security againstviolations of the integrity of the Eclipsedatabase. Great care is needed in prepar-ing transformation procedures in order toensure that they always leave the databasein a consistent state, and it is assumedthat the access right required to createtransformation procedures will be zeal-ously guarded.

8 Derivation procedures

In a large software system, the creation ofuseful products normally involves several

Software Engineering Journal January 1986 41

steps, for example text pre-processing,macro expansion, compilation and link-ing. While the whole of such a process canbe defined by a single transformation pro-cedure, this is inadvisable. Greater flex-ibility is achieved by definingtransformation procedures, each of whichcauses a single transformation. Usingsequences of such transformation pro-cedures allows complex systems to becreated. However, repeatedly enteringsuch sequences is inconvenient for theuser. To overcome this, derivation pro-cedures have been introduced.

A derivation procedure is a para-meterised sequence of transformationprocedure invocations and other Eclipsecommands. The user invokes the wholesequence by invoking the derivation pro-cedure. Eclipse processes each com-mand and transformation procedureinvocation in turn. Before a transforma-tion procedure invocation is executedEclipse checks whether the objects thatwould be output already exist (the actualcheck is whether there exist objects withprecisely the same derivation as would becreated for the objects that would be out-put as a consequence of execution). If theoutput objects do exist, there is no need toexecute that invocation and processingcontinues with the next command.

Eclipse's ability to avoid unnecessaryexecution of transformation procedures isan incentive to create simple transforma-tion procedures and combine them usingderivation procedures. This gives Eclipsemore scope for avoiding unnecessarywork than if the user creates complextransformation procedures.

The language in which derivation pro-cedures are written is, approximately,similar in power to the UNIX shell, withcalls to UNIX commands replaced by callsto transformation procedures and toother Eclipse commands with filenamesreplaced by references to databaseobjects. The important characteristics ofthe language are that it is independent ofthe host operating system (and hardware)and that any procedure written in it is

guaranteed to leave the Eclipse databasein a consistent state.

Objects produced in the course ofexecuting a derivation procedure neednot necessarily belong to an item. Suchobjects are known as orphan objects and,in order to be accessible, must berecorded in a synonym table.

Provision is made for the delayedexecution of derivation procedures, in thefollowing sense. The procedure isinvoked, its syntax is checked and itsoperation is simulated to ensure that allthe operations requested are legal (forexample input objects exist and the userhas right of access to them) and to obtainany input required interactively. The pro-cedure is then queued for subsequentexecution (for example overnight). Therecan, of course, be no guarantee that thedatabase will not have changed by thetime the procedure is run, in such a waythat execution of the procedure is nolonger legal. Nonetheless, this provisiongoes a long way towards avoiding the irri-tation caused when a long system-build-ing operation is submitted for overnightrunning, only to fail as a result of some

carelessness.

9 Conclusions

The features of the Eclipse Object Man-agement System described in this paperare of the nature of 'meta-features'. Theycan only be properly evaluated when theproduct is used to support a real projectwith its own standards and using a meth-odology supported by automated tools.Such evaluations, by organisations out-side the consortium, are already plannedand, indeed, form an integral part of theAlvey Programme in SoftwareEngineering.

The Eclipse project itself is developinga number of tools which utilise the ObjectManagement System. In particular, a ver-sion controlled Ada program library andassociated tools are being produced [9].

10 Acknowledgments

The authors would like to thank the AlveyDirectorate for financial support for theproject and their many colleagues whohave contributed to the work described.

11 References

1 'Configuration management of computer-based systems'. British Standards Institution, BS6488,1984

2 ALDERSON, A., BOTT, M. F., and FALLA, _M. E.: 'An overview of the Eclipse project', inMcDERMID, J. A. (Ed.): 'Integrated project support environments' (Peter Peregrinus, 1985)

3 The STARTS guide. Software tools for application to real-time systems'. (JK Department ofTrade and Industry/National Economic Development Office Guide, National Computing Cen-tre, Manchester, England, 1983

4 BUCKLE, J. K.: 'Software configuration management' (MacMillan, 1982)5 CHEATHAM, T. E. Jr.: 'Comparing programming support environments', in HCNKE, H. (Ed.):

'Software engineering environments' (North-Holland, 1981)6 'SDS2 overview'. Software Sciences Ltd., Macclesfield, England, 19847 The official handbook of Mascot'. Mascot II, Issue 2, RSRE, Malvern, Worcestershire, England,

Mar. 19838 ROCHKIND, M. J.: The source code control system', IEEE Transactions, 1975, SE-1, (4), pp.

364-3709 PIERCE, R. H.: 'Ada in the Eclipse project support environment', in BARNES, J. G. P., and

FISHER, G. A. Jr. (Eds.): 'Ada in use'. Proceedings of Ada International Conference, Paris, May1985

A. Alderson and M. E. Falla are with Software Sciences Limited, London & Manchester House,Park Street, Macclesfield, Cheshire SKI 1 6SR, England, and M. F. Bott is with the Department ofComputer Science, University College of Wales, Aberystwyth SY23 2AX, Wales.

42 Software Engineering Journal January 1986