System Evolution via Model-driven Design

A. Branson

, J.-M. Le Goff

, R. McClatchey

and J. Shamdasani

Centre for Complex Cooperative Systems, University of the West of England, Coldharbour Lane, Bristol, U.K.

CERN, 1217 Geneva 23, Switzerland

Keywords:

Description-driven, Model Evolution, Dynamic Requirements, System Reconﬁguration.

Abstract:

Software engineers frequently face the challenge of systems whose requirements change over time to adapt

to organizational reconﬁgurations or external pressures. Evolving user requirements present a considerable

software engineering challenge, all the more so in an environment in which business agility demands shorter

development times and responsive prototyping. This paper presents a system called CRISTAL which was

developed at CERN in Geneva. CRISTAL is based on the concept of so-called ’description-driven’ change

management that enables system development which is responsive to changes in user requirements and facili-

tates dynamic system reconﬁguration as required.

1 INTRODUCTION

The principal motivation in carrying out this research

was to address the requirements scientists working on

the Large Hadron Collider (LHC) accelerator project

at CERN which reached its ﬁnal phase of construction

and testing in 2009. The Compact Muon Solenoid

(CMS) (The CMS Collaboration and Chatrchyan,

S. et al., 2008) is one of the four main experiments

of the LHC; it contains the so-called Electromagnetic

Calorimeter (ECAL) detector. Its design and con-

struction were carried out between 1995 and 2008 and

form the subject of this paper.

A research project, entitled CRISTAL (Cooper-

ating Repositories and an Information System for

Tracking Assembly Lifecycles) (Estrella, F. et al.,

2003) was established, using pure object oriented

computing technologies where possible, to facilitate

the management of the engineering data collected at

each stage of construction of CMS. CRISTAL is a dis-

tributed product data and workﬂow management sys-

tem which uses a database for its repository, a multi-

layered architecture for its component abstraction and

dynamic object modelling for the design of the ob-

jects and components of the system. These techniques

are critical in handling the complexity of such a data-

intensive system and to provide the ﬂexibility to adapt

to the changing production scenarios typical of any re-

search production system. The CRISTAL system has

been based on a so-called description-driven approach

in which all logic and data structures are described by

meta-data, which can be modiﬁed and versioned

online as the design of the detector changes. A

description-driven system (DDS) architecture (Es-

trella, F. et al., 2003) is an example of a reﬂective

meta-layer architecture. DDSs make use of meta-

objects to store domain-speciﬁc system descriptions

(e.g. items, processes, lifecycles, goals, agents and

outcomes) which control and manage the lifecycles

of instances or domain objects. As objects, reiﬁed

system descriptions of DDSs can be organized into

libraries conforming with frameworks for modelling

of languages, and to their adaptation for speciﬁc do-

mains.

The meta-data and the instantiated elements of

data are stored in the database; the evolution of the

design is tracked by versioning the changes in the

meta-data over time. Thus description-driven systems

make use of meta-objects to store domain-speciﬁc

system descriptions that control and manage the life-

cycles of domain objects (i.e. instances of the meta-

object deﬁnitions). The separation of the descrip-

tions from their instances allows them to be speci-

ﬁed and managed and to evolve independently and

asynchronously. This separation is essential in han-

dling the complexity issues facing many web-based

computing applications and facilitates interoperabil-

ity and reusability with system evolution. Separating

descriptions from their instantiation allows new ver-

sions of deﬁned objects (and their descriptions) to co-

exist with older versions. The reader is directed to

previous publications on DDS for further background

142

Branson A., Le Goff J., McClatchey R. and Shamdasani J..

System Evolution via Model-driven Design.

DOI: 10.5220/0003970101420145

In Proceedings of the 14th International Conference on Enterprise Information Systems (ICEIS-2012), pages 142-145

ISBN: 978-989-8565-11-2

 2012 SCITEPRESS (Science and Technology Publications, Lda.)

(Estrella, F. et al., 2003; Estrella, F. et al., 2001).

At the outset of CRISTAL an approach was fol-

lowed that enabled both ECAL parts and the activ-

ities (both with the metadata of their speciﬁcations)

that were carried out on the parts to be saved side-by-

side in a structured database. In this way as the sci-

entists developed their research ideas we were able to

capture each design version and those parts and activ-

ities that were processed for that version. The produc-

tion version of CRISTAL was designed to satisfy a set

of requirements covering both the CMS ECAL needs

and the needs of commercial Business Process Man-

agement (BPM) users. This led to a generalization of

the concept of ’parts’ to that of ’items’ which were

intended to be applicable to describe any element of

any business process. The intention was to enable de-

velopers to deﬁne the objects central to the operation

of any business and to drive the design process from

the standpoint of how those objects (’items’) change

over time.

CRISTAL is, in essence, an application server

that abstracts all of its business objects into workﬂow

driven, version controlled ’Items’ which are instanti-

ated from descriptions stored in other Items (see Fig-

ure 1) and are managed on-the-ﬂy for target user com-

munities. Items contain:

• Workﬂows, that comprise of Activities to be exe-

cuted by Agents (either human users or mechani-

cal/ computational agents via an API), which then

generate:

• Events that detail each change of state of an Ac-

tivity. Completion events generate data, stored as:

• Outcomes which are XML documents from each

execution, for which:

• Viewpoints refer to particular versions (e.g. the

latest version or, in the case of descriptions, a par-

ticular version number).

• Properties are name/value pairs that name and

type items, they also denormalize collected data

for more efﬁcient querying, and

• Collections that enable items to be linked to each

other.

The CMS ECAL was made of thousands of sim-

ilar parts, all needing characterizing and assembling

in an optimal conﬁguration based on sets of detailed

measurements. Every component part was registered

as an Item in the CRISTAL database, each with its

barcode as an identiﬁer, stored as the CRISTAL prop-

erty ’Name’. Each part had a type, which functioned

as the item description, and was linked to the work-

ﬂow deﬁnition that each instance would follow in

order to collect its data and mount sub-parts. All

collected data and assembly information were stored

as outcomes attached to events, therefore the entire

history of every interaction with the application was

recorded. The result was a set of items representing

the top level components of the detector which con-

tained levels of substructure, all with their full pro-

duction history with all collected and calculated pro-

duction data attached in the correct context. On cre-

ation, an item contains no events, outcomes or view-

points (the context of the item). These are explicitly

generated later during execution of its workﬂow pro-

cesses. Initially an item contains properties to identify

it, its workﬂow and any collections of items it may

need, with all slots empty. The initial set of proper-

ties are created in the process of rendering a property

input form by exploiting the property description (it-

self an outcome stored in the item description), and

submitting it as an activity outcome of the description

item.

The basic functionality of CRISTAL is best il-

lustrated with an example: using CRISTAL a user

can deﬁne product types (such as Newcar spark plug)

and products (such as a Newcar spark plug with se-

rial number #123), workﬂows and activities (e.g. to

test that the plugs work properly, and mount them

into the engine). This allows products that are un-

dergoing workﬂow activities to be traced and, over

time, for new product types (e.g. an improved Newcar

spark plug) to be deﬁned which are then instantiated

as products (e.g. updated Newcar spark plug #124)

which are traced in parallel to pre-existing ones. The

application logic is free to allow or deny the inclusion

of older product versions in newer ones (e.g. to use

up the old stock of spark plugs). Similarly, versions

of the workﬂow activities can co-exist and be run on

these products. All versions of items in the produc-

tion history are simply viewed as items allowing the

capture of many versions of items and their coexis-

tence in CRISTAL. Further detail of the the CRISTAL

database can be found in (Branson, A. et al., 2012).

2 CRISTAL IN PRACTICE

This section outlines how the CRISTAL system per-

formed in practice at CERN. The CRISTAL software

was developed over the period 1997-2000 and was

delivered for use at CMS early in 2000, when the

data from the characterization and the physical mea-

surement of the 70,000 lead tungstate crystals began.

CRISTAL collected initial data against a data model

residing in Objectivity but it suffered from numerous

performance limitations. After signiﬁcant redesign

CRISTAL V2 was made available to the CMS ECAL

SystemEvolutionviaModel-drivenDesign

143

Figure 1: Model vs. description in Cristal 2.

user community from 2003 and it remained in opera-

tion over the following ﬁve to six years. Each ECAL

crystal generated between 2-3Mbytes of information

which was mainly gathered in an automated data ac-

quisition system which characterised the crystals in

batches over a period of 8-10 hours for each batch

of 30 crystals. Due to the vast numbers of crystals

(100,000s) to measure it was important that this data

acquisition process was reliable, consistent and that

the mean time between failures was very high. Some

batches required re-characterisation and some crys-

tals needed to be replaced; the whole data acquisi-

tion process took around ﬁve years to complete. It

was the responsibility of one CRISTAL software en-

gineer (the so-called application maintainer) to en-

sure as smooth operation as possible of the data ac-

quisition and to provide round-the-clock accessibility

to the CRISTAL database. Where changes were re-

quired to the descriptions handled by CRISTAL the

procedure outlined above was followed.

In the CMS experiment, production models

change over time. Detector parts of different model

versions must be handled over time and coexist with

other parts of different model versions. Separating

details of model types from the details of single parts

allows the model type versions to be speciﬁed and

managed independently, asynchronously and explic-

itly from single parts. In capturing descriptions sep-

arate from their instantiations, system evolution can

be catered for while production is underway this pro-

vides continuity in the production process and de-

sign changes can be reﬂected quickly into produc-

tion. The approach of reifying a set of simple design

patterns as the basis of the description-driven archi-

tecture for CRISTAL has provided the capability of

catering for the evolution of a rapidly changing re-

search data model. In the six years of operation of

CRISTAL it has gathered over 50 GBytes of data and

been able to cope with 25 evolutions of the underly-

ing data schema without code or schema recompila-

tions. During the years of near-continuous operation,

the descriptions went from beta to production then

through years of (relatively few) alterations of the do-

main logic which necessitated very little change in the

actual server software, illustrating the ﬂexibility of the

CRISTAL approach.

3 LESSONS LEARNT FROM

BUILDING CRISTAL

Probably the main lesson learned from the CRISTAL

project in coping with change was to develop a data

model that had the capacity to cover multiple types of

data (be they products or activities, atomic or com-

posite in nature) and at the same time was elegant

in its simplicity. To do this a systemically consis-

tent approach to data modelling was needed: de-

signers needed to think in a way that would facili-

tate system ﬂexibility, would enable rapid change and

would ease the burden of maintenance from the out-

set of the design process. The approach that was

followed in designing CRISTAL was to concentrate

on the essential enterprise objects and descriptions

(products, activities, user roles, outcomes, events)

that could be needed during the lifetime of the sys-

ICEIS2012-14thInternationalConferenceonEnterpriseInformationSystems

144

tem no matter from which viewpoint that data is ac-

cessed. Thus the system was allowed to be open in

design and ﬂexible in nature and the elegance of its

design was not limited from being viewed from one or

several application-led standpoints (e.g. BPM, EAI,

CRM, PDM,WfMS). Rather we enabled the traceabil-

ity of enterprise objects over the lifetime of the sys-

tem as the primary goal of the system and left the

application-speciﬁc views to be deﬁned as and when

they became required. It is this that we see as the main

and unique contribution of the CRISTAL approach

(a ’description-driven’ one) to building ﬂexible and

maintainable systems and we believe this makes a

signiﬁcant contribution to how moel-driven enterprise

systems can be implemented. These were not simple

design skills; designers needed to be able to think con-

ceptually, abstracting the characteristics of everyday

objects into ’items’ with associated metadata and to

be able to represent that complexity in a concrete data

model. Great beneﬁts in terms of maintainability and

ﬂexibility resulted from being able to treat many dif-

ferent system objects (workﬂows, events, outcomes,

items) in a single standardised manner. The impor-

tance of instantiation and description in formulating a

generic CRISTAL data model cannot be overempha-

sised. They are the foundations on which description-

driven systems development is based.

Importance was placed on the involvement of

users at all stages of the development of CRISTAL.

We regard this as one of the prime reasons for the

eventual success of the project. Although initially it

was hoped that high-end expert users would be able

to develop workﬂows themselves, in practice this was

not possible. Instead the users collaborated closely

with the designers to establish a much clearer idea of

the implications of their requirements, and with a full

understanding of the functionality that their workﬂow

must provide. This could then be implemented with

veriﬁable accuracy against what the user originally

wanted. Essentially this approach, centred on the

identiﬁcation of items and their descriptions, led to

a very intuitive way of representing requirements and

absorbing them, as and when they emerged, into the

evolving data model. On the negative side the users

necessarily did not always know at the outset what

their ﬁnal requirements would be for data and pro-

cess management, often leading to disruptive changes

in design decisions. On the positive side, the users

were not locked into a ’static’ product: CRISTAL was

evolving to cater for their requirements and could be

made responsive to their needs.

Control of evolving requirements was a particu-

larly challenging problem. New user requirements

needed to be addressed at the application level which,

as a consequence, induced requirements at the domain

implementation level which in turn passes its own re-

quirements down to the kernel level. The result of

this was that there could be a considerable number

of potential feature conﬁgurations of the CRISTAL

kernel needed to meet all possible requirements from

the user. Since CRISTAL was conceived as a model-

driven system, an attempt was made to follow best

software engineering practice in implementing fea-

tures associated with object orientation (e.g. inher-

itance, polymorphism, deferral of commitment, etc)

to ensure reuse and extensibility. Whenever a new

design modiﬁcation was needed, the approach taken

therefore was always to implement as open and as

ﬂexible a solution as the design allowed in order not to

constrain future extensions. In practice, however, this

“second guessing quickly” led to feature creep and

spiralling complexity which was at risk of compro-

mising the system development process. To address

this situation the approach that we adopted was to

make the implementation of new requirements as in-

tuitive as possible with as simple functionality as nec-

essary to cope with the requirements, thereby preserv-

ing the elegance of the original (description-driven)

design. This led to a closely connected set of system

functionalities which was easy to maintain and to dy-

namically extend as and when needed. In addition this

much simpler system has the virtue of being signiﬁ-

cantly easier for users, developers and administrators

new to the system to pick up and start working with.

The ﬂexible nature of the DDS approach has recently

enabled the use of CRISTAL as a provenance man-

agement tool in the neuGRID project (for studies of

Alzheimer’s disease) (Anjum, A. et al, 2010).

REFERENCES

Anjum, A. et al (2010). Reusable Services from the

neuGRID Project for Grid-Based Health Applica-

tions. Studies in Health Technology and Informatics,

147:283–288.

Branson, A. et al. (2012). Evolving Requirements: Model-

Driven Design for Change. Information Systems. Un-

der ﬁnal review.

Estrella, F. et al. (2001). Meta-data Objects as the Basis

for System Evolution. In Proceedings of the Second

International Conference on Advances in Web-Age In-

formation Management, WAIM ’01, pages 390–399.

Springer-Verlag.

Estrella, F. et al. (2003). Pattern Reiﬁcation as the Basis for

Description-Driven Systems. Journal of Software and

System Modelling, 2(2):108–119.

The CMS Collaboration and Chatrchyan, S. et al. (2008).

The CMS experiment at the CERN LHC. Journal of

Instrumentation, 3:S08004.

SystemEvolutionviaModel-drivenDesign

145