Design patterns for description-driven systems in High Energy Physics

Computer Physics Communications 140 (2001) 1–12www.elsevier.com/locate/cpc

Design patterns for description-driven systemsin High Energy Physics

Nigel Bakera,∗, Alain Bazanb, Guy Cheveniera, Florida Estrellaa, Zsolt Kovacsa,Jean-Marie Le Goffc, Richard McClatcheya, Peter Martina

a Centre for Complex Cooperative Systems, UWE, Bristol BS16 1QY, UKb LAPP, IN2P3, Annecy-le-Vieux, France

c EP Division, CERN, Geneva 1211, Switzerland

Abstract

In data modeling, product information has most often been handled separately from process information. The integration ofproduct and process models in a unified data model could provide the means by which information could be shared betweenHigh Energy Physics (HEP) groups throughout the system lifecycle from design through to production. Recently attemptshave been made to integrate these two separate views of systems through identifying common data models. This paper relatesdescription-driven systems to multi-layer architectures through the CRISTAL project and reveals where existing design patternsfacilitate the integration of product and process models, where patterns are missing or require enrichment for integration. Itreports on the construction of a so-called description-driven system which integrates Product Data Management (PDM) andWorkflow Management (WfM) models through a common meta-model. 2001 Elsevier Science B.V. All rights reserved.

Keywords: Database design; Description-driven systems; Data management; High-energy physics

1. Description-driven systems

‘Description-driven systems’ can be defined as sys-tems in which the definition of a domain-specific con-figuration is captured in a computer-readable form.This definition can be interpreted by applications toachieve domain-specific goals. In a description-drivensystem definitions are separated and managed inde-pendently from instances. This allows the definitionsto be specified and to evolve asynchronously frominstantiations (and executions) of those definitions.Description-driven systems require computer-readablemodels both for definitions and for instances. These

* Corresponding author.E-mail address: [email protected] (N. Baker).

models are loosely coupled — coupling takes placewhen instances are created or when a definition, cor-responding to existing instantiations, is modified. Thecoupling is loose since the lifecycle of each instan-tiation is independent from the lifecycle of its corre-sponding definition.

One example of the use of description-driven sys-tems is in a workflow management system (WfM [1])where the business process model defines the instanti-ated workflows and the definitions are managed sepa-rately from the instantiations. WfM systems are oftenbuilt on a multi-layer architecture. In WfM systems theworkflow instances (such as activities or tasks) corre-spond to the lowest level of system abstraction — theinstance layer (see Fig. 1). In order to instantiate theworkflow objects a workflow scheme is required. This

0010-4655/01/$ – see front matter 2001 Elsevier Science B.V. All rights reserved.PII: S0010-4655(01)00250-8

2 N. Baker et al. / Computer Physics Communications 140 (2001) 1–12

Fig. 1. A four-layer meta-modeling architecture.

scheme describes the workflow instances and corre-sponds to the next layer of abstraction — themodellayer. In order for the workflow scheme itself to bebuilt, a further model is required to store the seman-tics for the generation of the workflow scheme. Thismodel (i.e. a model describing another model) is thenext layer of system abstraction — themeta-modellayer (see Fig. 1).

The semantics required to adequately model ap-plication-specific information will, in most cases, bedifferent. For example, the semantics for describingProduct Data Management (PDM [2]) systems (prod-uct types, product composition types, etc.) will bevery different from those describing WfM systems(activity types, activity composition types, actor types,etc.). To facilitate integration between (in this casePDM and WfM) meta-models a universal type lan-guage capable of describing all meta-information is re-quired. The common approach is to define an abstractlanguage which is capable of defining another lan-guage for specifying a particular meta-model, in otherwordsmeta–meta-information. The accepted concep-tual framework for meta-modeling is based on anarchitecture with four layers: Fig. 1 illustrates thefour-layer meta-modeling architecture adopted by theOMG, based on the ISO 11179 standard.

Themeta–meta-model layer is the layer responsiblefor defining a general modeling language for specify-ing meta-models. This top layer is the most abstract

and must have the capability of modeling any meta-model. It comprises the design artifacts in commonto any meta-model. At the next layer down a (do-main specific) meta-model is an instance of a meta–meta-model. It is the responsibility of this layer todefine a language for specifying models, which is it-self defined in terms of the meta–meta types of themeta–meta modeling layer above. Examples of ob-jects at this level from manufacturing include work-flow process description, nested subprocess descrip-tion and product descriptions. A model at layer two isan instance of a meta-model. The primary responsibil-ity of the model layer is to define a language that de-scribes a particular information domain. Example ob-jects for the manufacturing domain would be product,measurement, production schedule, composite prod-uct. At the lowest level user objects are an instanceof a model and describe a specific information and ap-plication domain.

2. Implementing description-driven systems

Object-oriented systems provide the mechanismsfor the capture of system description at a high levelof abstraction — descriptive objects themselves havestate and methods — and are therefore suitable forbuilding description-driven systems. When implement-ing a description-driven system based on objects, the

N. Baker et al. / Computer Physics Communications 140 (2001) 1–12 3

descriptive element, which holds information aboutanother object is called a ‘meta-object’ — meta-objects manage the meta-data required to implementdescription-driven systems. The ‘meta-’ prefix is usedin the same manner, as it was used for meta-models,i.e. it describes the connection between objects of dif-ferent layers of abstraction in description-driven sys-tems. Note also that the usage of the term meta-objectdenotes that the system not only ‘stores’ the descrip-tive information but also manages it (i.e. it has data,methods and state). The following sections investigatethe design patterns required to integrate process andproduct model based on a multi-layered architecture.

2.1. Patterns

Some design patterns, appropriate for handlingmeta-data in a multi-layer architecture (such as theComposite and Iterator [3] patterns), have been well-specified. Gamma defines the Composite pattern in thefollowing way: “Compose objects into tree structuresto represent part-whole hierarchies. The Compositepattern lets clients treat individual objects and compo-sitions of objects uniformly”. According to Gamma,the Iterator pattern “provides away to access the ele-ments of an aggregate object sequentially without ex-posing its underlying representation”. These patternsare studied later in this paper.

Blaha and Premerlani [4], have extended the OMTnotation to help specify patterns. A number of patternshave been added to the OMT language to provide “ahigher level of building blocks for models than thebase primitives of class, association and generaliza-tion”. They also introduce cyclicity into the compos-ite pattern. Of particular interest to the subject of thispaper are the Graph, Item Description and Homomor-phism patterns of [4]. The next sections take patternsdescribed in [4] and enrich these patterns to provideintegration of process and product (meta-)models.

2.2. Item Description pattern

Coad’s [5] Item Description pattern shows the as-sociation between descriptions and instances. In prin-ciple this pattern is the manifestation of the relation-ship between meta-objects and objects. This patterndescribes consecutive layers of description-driven sys-tems. The association between Items and Item De-

scriptions can be an aggregate and can support link at-tributes and qualifiers. This mechanism is essential tothe separation of instantiation from definition, as re-quired by the multi-layer architecture of description-driven systems where semantics are required for theinstantiation of Items from an Item Description.

2.3. Homomorphism pattern

Fig. 2 shows that two Item Descriptions can be re-lated and an association can be defined between them— this is referred to as the Homomorphism patternin [6]. As a consequence of the use of the Item De-scription pattern and the fact that semantics have beenadded to the association between Item Descriptions,there will necessarily be semantics attached to the as-sociation of one (instantiated) Item to another (instan-tiated) Item. According to [6] “Homomorphisms aremost likely to occur for complex applications that dealwith meta-data”. Since there are relationships betweenelements in each layer (e.g., a relationship betweenItem Descriptions) it is natural that the Homomor-phism pattern appears between layers. The Homomor-phism pattern is therefore fundamental to description-driven systems.

As an example of the use of this pattern, con-sider two Item Descriptions: the familiar car andcar model and a production process and productionprocess model. In this example, there are many instan-tiations of cars of a particular model and productionactivities of a particular process model. An associa-tion can be specified between a car model and a pro-duction process model — i.e. information specific tothe execution of a production process model on a spe-cific car model. When an instantiation of the produc-tion process is performed on a particular car, detailssuch as the operational conditions must be specified.These operational conditions may be derived from theinformation on the association between car model andproduction process model. That is, the semantics of theassociation between the instantiated Items can be de-rived from the semantics on the association betweenthe corresponding Item Descriptions.

2.4. Version pattern

In description-driven systems it is important to keeptrack of versions of definitions and instantiations of


Fig. 2. The Item Description and Homomorphism pattern.

Fig. 3. The Version pattern.

these definitions. Fig. 3 proposes a Version patternthat can facilitate individual and collective versioning.This pattern provides the functionality of both theCheckIn/CheckOut Model and Composition Modelsof configuration management. In this pattern eachVersionedObject manages a set of individual versionsof itself, each instance having a versionId and beingreferred to as a VersionedObjectProperty.

Note that, in principle, a VersionedObject and a Ver-sionedObjectProperty make up one object. Propertiesare separated from attributes in order to distinguish be-tween meta-object data which is either versioned ornot versioned, respectively. Changing an object’s at-tributes does not version the object whereas changing

an object’s properties will version it. In addition tohandling versioning of an individual object, this pat-tern allows for versioning of a collected set of objects,called a Release. This is achieved by defining a class ofobjects called ReleaseManagers which are specializa-tions of VersionedObjects. ReleaseManagers are ver-sioned and each version, the ReleaseManagerPropertyclass, manages a collection of versioned objects. TheReleaseManager maintains a list of added or removedobjects in a release. Static versioning is therefore han-dled by this pattern. The propagation of changes ina release to dependent objects (i.e. the notification ofchanges to dependent objects and the nature of the de-pendencies) is described in the following section.


Fig. 4. The Publisher/Subscriber pattern.

Fig. 5. The Complex Directed Graph pattern.

2.5. Publisher/Subscriber pattern

To facilitate dynamic version management, whichcannot be handled by the Version pattern alone, usecan be made of Gamma et al.’s Observer pattern [3],otherwise referred to as the Publish/Subscribe pattern.Fig. 4 shows this pattern. In this pattern a publisherItem (or meta-object) sends out notifications whichwill reach all subscriber Items without the Publisherknowing who the Subscribers are and how many Sub-scribers there are. In UML [7] this can be representedby a directed association as shown by the arrow be-tween Publisher and Subscriber in Fig. 4. This patternis useful in handling versions of meta-objects whenthere are dependencies between the meta-objects butthe meta-objects are not tightly coupled.

2.6. Graph pattern

The general form of a graph is shown in Fig. 5where nodes are linked to other nodes. In an undi-rected graph an edge connects any two nodes, whereas

in a directed graph an edge connects a source node to asink node. In addition, a directed graph can have nodeswith any number of edges. Complex graphs make adistinction between branch and leaf nodes, whereassimple graphs do not. In an acyclic graph, when thegraph has been traversed repetitively from parent tochild nodes, there are no instances where traversalleads to a node being a child of itself. Cyclic graphscan allow this form of recursion. The complex Di-rected Acyclic Graph pattern of [4] does not allow se-mantics to be added to the association between nodesas branches (see Fig. 5), consequently there is no wayof identifying, and associating attributes or methodsto, a particular instance of the link.

3. Providing description-driven systems featuresusing meta-objects

The following sections investigate how a set ofdesign patterns can be used as the basis of the designof a description-driven system which can handle


complexity, facilitate the integration of product andprocess data models, reduce the effects of schemaevolution and provide for inter-operability betweenobject-based systems.

3.1. Handling complexity

Earlier it was stated that scalability problems insystem design can be eased if descriptive informationis held both at the model and meta-model layersof a multi-layer architecture. The Item Descriptionpattern combined with the Directed Acyclic Graphpattern provides the mechanism by which this can beachieved.

Fig. 6 shows a combination of the Item Descrip-tion and Directed Acyclic Graph patterns. The com-bination of the patterns is established by decomposingan Item Description into its constituent Item Descrip-tions. In other words, an Item Description can be ei-ther elementary or composite in nature and thereforesome Item Descriptions can be made up of other ItemDescriptions. Consider the car and car model exam-ple of earlier. A particular description of a car modelis composed of other descriptions: e.g., descriptionsof the engine, the chassis, the drive-system (front-axlesystem, rear-axle system, wheels, tyres, etc.). Someof these descriptions are elementary, e.g., the wheelsand some composite, e.g., the drive-system. The as-sociation between a Composite Item Description andits children will hold semantics such as the numberof constituent descriptions of a common type (e.g.,four wheels of a single wheel description). However,as stated earlier, a simple combination of the Item De-

scription and Directed Acyclic Graph patterns as de-scribed in [4] does not enable the identification ofa particular constituent Item Description within itsComposite Item Description. In the example, it is notpossible to determine which wheel is located at whichwheel position.

Consequently the combined patterns require en-richment by the introduction of another meta-objectwhich captures the membership of an Item Descriptionwithin its Composite Item Description(s). Fig. 7 showsthe Enriched Directed Acyclic Graph and Item De-scription combined pattern. An Item Description canbe part of many different Composite Item Descrip-tions, e.g., one wheel description could be employedin both the front-axle system and the rear-axle system.One instance of the Composite Member meta-objectwill hold the full semantics of the membership of aparticular Item Description in a single Composite ItemDescription. In other words, it is possible to determinewhich wheel is located in which axle system and inwhich location in that axle system.

When a particular Item Description is instantiatedinto an Item the composition of that Item is determinedby traversing the graph of its Item Description. Theresult will be a hierarchy of Items organized as a treein which each node is of a particular Item Description.In the car example the car is made up of a chassis,an engine, a drive-system (comprising front- and rear-axle systems each of which is composed of twowheels, etc.). The tree is as deep as there are layersin the directed acyclic graph and each composite nodewill have a number of constituent nodes equal to the

Fig. 6. A combination of the Item Description and Directed Acyclic Graph patterns.


Fig. 7. An Enriched Directed Acyclic Graph pattern.

number of Composite Member meta-objects in theItem Description corresponding to that node.

The complexity of the overall model of Items istherefore handled through the reuse of Item Descrip-tions. The reuse can take place at any point in the tra-versal of the directed graph as long as the graph isacyclic. For the car example, the number of Items andthe number of levels of compositeness is not great andcomplexity handling is not a major issue. As eitherthe complexity of the Item and the number of levelsof composition increases the role of Composite Mem-ber meta-objects becomes essential. The Enriched Di-rected Acyclic Graph and Item Description patternshave been used to manage the complexity inherent inthe construction of a large scientific apparatus.

3.2. Integrating product and process models

Having discussed the role of a directed acyclicgraph to describe Items and their constituents in theprevious section, it is now proposed that any productor any process can be modeled in terms of an EnrichedDirected Acyclic Graph pattern combined with anItem Description pattern.

In manufacturing, models are used to support thedesign life cycle of a particular product [8]. Productscan evolve over time, their designs may change or theproduction process may be improved. Earlier it wasstated that PDM systems have been employed to man-age product data in the design life cycle. PDM sys-tems traditionally employ hierarchies to capture prod-uct composition (so-called ‘Bill Of Materials’, BOM)and therefore, as the complexity of the product grows

PDM systems suffer from a dramatic increase in thenumber of products (the so-called ‘products explo-sion’). Basing a PDM model on an Enriched DirectedAcyclic Graph pattern combined with an Item De-scription pattern, handles the products explosion. Theconsequence is that the BOM is only available oncethe product composition tree has been generated bytraversal of the complete graph structure.

Products are subject to many processes in the man-ufacturing life cycle such as design processes, assem-bly processes, test processes, maintenance processesetc. Each of these processes can be complex andcomposite in nature. Ideally the description of theseprocesses should be captured in a model and in-stances of these processes managed in some repos-itory. One example of a process management sys-tem is a WfM, which, as stated earlier, can be de-scribed as description-driven systems. Process mod-els to support systems such as WfMs must cope withprocess composition, process sequence, parallelism ofprocesses and synchronization of processes. Basing aWfM model on an Enriched Directed Acyclic Graphpatterns combined with an Item Description patternsupports processes of arbitrary complexity includingcomposition and sub-process reuse. Furthermore, us-ing the CompositeMember meta-objects of the En-riched Directed Acyclic Graph pattern allows the cap-ture of process sequence, parallelism and synchroniza-tion.

There is an increasing movement in manufacturingto integrate product and process models for the pur-poses of life cycle data management. Therefore anysystem which can manage both product and process


information in a common model is very desirable tothe manufacturing community. Basing both a productand a process model on the above patterns and asso-ciating product descriptions with process descriptions,provides a uniform model for manufacturing. The as-sociation between the two descriptions carries seman-tics in that it describes how a particular process de-scription is applied to a particular product descriptionand any conditions or constraints on how the processacts on the product. This association of process de-scription to product description is very powerful —it allows different associations to be defined betweena product and different processes that can take placethroughout its life cycle, e.g., design, assembly, test-ing, maintenance, etc. For example, the associationof a maintenance process to a product will requirequite different conditions to be captured from thosethat are captured when a design process is carried outon that same product. The integration of PDM withWfM demonstrates the power of a unified product andprocess life cycle model.

3.3. Handling evolution

Production systems should cater for the evolutionof product or process descriptions regardless of thecurrent state of the production and this while theproduction process continues. Since, as discussedearlier, layers in a description-driven system are onlyloosely coupled, modifications in the meta-modellayer can be carried out asynchronously from theapplication of those modifications in the model layer(which is itself defined in and generated from themeta-model layer). Similarly, modifications in themodel layer can be asynchronously applied from theirinstantiations in the instance layer.

Even though the modifications are asynchronouslyapplied in each layer, notification of the modificationis required to provide traceability in the productionsystems. This mechanism can be handled through acombination of patterns, the Publish/Subscribe patterndescribed in Section 2.5, the Item Description patternof Section 2.2 and the Version pattern of Section 2.4.In the combination of these patterns, an Item Descrip-tion is a concrete Publisher and any Item associatedwith this Item Description is a concrete Subscriber.A modification in the Item Description (at the modellayer) is then notified to its Subscribers (at the instance

layer) which can apply their modifications when ap-propriate. The application of the Subscribers’ modifi-cations follows the Homomorphism pattern, describedin Section 2.3. The Homomorphism pattern provideslinkage between versions of Items and Item Descrip-tions. Consequently an Item can determine the con-sequences to itself of moving to a new version of aninstantiation of its Item Description.

3.4. Meta-objects and standardization

In distributed object-based systems, object requestbrokers provide for the exchange of simple data typesand, in addition, provide location and access ser-vices. The CORBA standard is meant to standardizehow systems interoperate. The OMG’s CORBA Ser-vices [9] specify how distributed objects should par-ticipate and provide services such as naming, persis-tent storage, life cycle, transaction, relationship andquery. The CORBA Services standard is an exampleof how self describing software components can inter-act to provide interoperable systems.

Recently a considerable amount of interest has beengenerated in meta-models and meta-object descrip-tion languages. Work has been completed within theOMG on the Meta Object Facility [10] which is ex-pected to manage all kinds of meta-models relevantto the OMG Architecture. The purpose of the OMGMOF is to provide a set of CORBA interfaces thatcan be used to define and manipulate a set of inter-operable meta models. The MOF uses CORBA in-terfaces for creating, deleting, manipulating meta ob-jects and for exchanging meta models. This meta-modeling approach will facilitate further integrationbetween product data management and workflow man-agement thereby providing consistency between de-sign and production and speeding up the process ofimplementing design changes in a production system.The MOF provides the mechanisms required to bringtogether OMG work on Product Data Enablers [11]and the Workflow Management Facility [12,13]. Theusage of the MOF will depend very much on view-point. From a systems designers viewpoint, who willbe looking down the layers of a multi-layer architec-ture, the MOF is used to define an information modelfor a particular domain of interest. Another viewpointis that of a systems programmer who is looking up themulti-layer architecture. CORBA clients use the MOF


to obtain information model descriptions which sup-port reflection and interoperability.

4. The CRISTAL project

A prototype has been developed which has facili-tated a study of description-driven systems. The objec-tive of this prototype was to integrate a Product DataManagement (PDM) model with a Workflow Manage-ment (WfM) model in the context of the CRISTAL(Cooperating Repositories and Information System forTracking Assembly Lifecycles) project currently be-ing undertaken at CERN, the European Organizationfor Nuclear Research in Switzerland.

The Compact Muon Solenoid (CMS) experiment[14] currently being constructed at CERN, Genevawill comprise several complex detectors for funda-mental particle physics research. Each detector is be-ing constructed out of, potentially, over a million partsthat will be produced and assembled during the nextdecade by specialized centres distributed world-wide.Each constituent part of each detector must be ac-curately measured and tested locally prior to its ul-timate assembly at CERN. The CRISTAL system isbeing developed to control the production and assem-bly process of the CMS Electromagnetic Calorime-ter (ECAL) detector (see [15,16] for further projectdetail such scale, context and applicability). It em-ploys workflow (WfM) and product data manage-ment (PDM) techniques to provide an infrastructurein which the engineering data can be stored.

A distributed object-oriented database (Objectivity)is used to hold the detector data and the definitions ofboth the detector components and of the tasks whichare performed on the components. The ECAL con-struction database follows an object-oriented designto maximize flexibility and reusability. An approachhas been taken, which promotes self-description anda degree of data independence. In adopting such adescription-driven design approach, a separation ofobject instances from object descriptions instanceswas needed.

A CRISTAL system comprises one or more dis-tributed data gathering centres. These centres beinga single Central System and multiple Local Centresin which the CRISTAL software will run. Each LocalCentre will have a set of measurement Instruments de-

fined in the database in terms of the commands thateach instrument uses and the data formats expected asoutcomes from the execution of workflow activities byinstruments [16].

Fig. 8 shows the software architecture of a CRISTALLocal Centre. The software comprises a set of Instru-ment Agents, a set of Product Managers for handlingall part data to/from the database, a Local Centre Man-ager which supervises the data gathering in a centre, aset of Digital Control Panels (DCPs or Graphical UserInterfaces, GUIs) which handle user interaction withCRISTAL and a Data Duplication Manager (DDM)which handles all duplication of data between the Lo-cal Centre and the Central System.

Product Managers (PM) provide the mechanism bywhich products (or detector parts) are tracked throughworkflows. They manage concurrency of workflowactivity executions, they manage data storage andcarry out all book-keeping of events. Any significantoccurrence that happens to a product in a workflowis recorded by its PM which effectively keeps trackof the ‘state’ of the product in production. As thePM handles all database activity for specific products,the DCPs are protected from any changes occurringin the database schema. The PM uses the presentstate of products and workflow activities with theprevailing production conditions to determine the nextstep that a product takes in its workflow. In effect theProduct Manager acts like amediator liaizing withboth workflow activity and product objects, which,themselves, have no knowledge about each other’sstate.

By using the Mediator pattern (as described in [16]),workflow activity objects are decoupled from productobjects thereby allowing interaction with these objectsto be handled separately through a single object. Byso doing the protocol for interaction with both work-flow activity and product objects is simplified and onlyimplemented through the mediator object. In prac-tice, this means that the product (PDM) and process(WfM) information can be managed separately but canbe combined by the Mediator process. Product andprocess data are stored as database objects, managedby the PM.

All events associated with these product and processobjects are also stored in chronological order as data-base objects. The PM interrogates the database forproduct and process ‘state’ information and combines


Fig. 8. The CRISTAL Local Centre software architecture.

Fig. 9. An Enriched Homomorphism pattern.

this with the production conditions to determine thenext viable workflow activities that can be performedon the product under consideration. Not only does thePM manage static product and process information,it also handles evolving product and process informa-tion. When a new release of the product specificationbecomes available at a centre, the PM will computewhen and how the change can be applied. As a conse-

quence of its role in determining when a change canbe applied, it is possible for products of the same de-finition to be following quite different versions of theproduction scheme at any one time in a centre.

It is the responsibility of each products’s PM tokeep track of the product in its workflow. Products canmove between centres, so PMs in both the source anddestination centres must be able to follow the same


workflow, i.e. to suspend and resume workflow activ-ities when products are shipped between centres. TheProduct Manager has been implemented as a CORBAobject using the CORBA lifecycle service. In its roleas manager of the Local Centre the LCM manages thelife cycle of each PM instance, including when a prod-uct is physically transported from one centre to an-other (‘shipped’). Fig. 9 shows an enriched Homomor-phism pattern replacing the condition element of Fig. 2by a mediator class. The PM carries out the physi-cal role of mediation in the CRISTAL prototype. Thisenriched pattern describes both the relationship be-tween the meta-model and model layers of CRISTAL,through the familiar Item Description pattern and therole of the PM as the mediator between Items of themodel layer (in this case between products and work-flow activities).

5. Conclusions

The following existing patterns emerged from theCRISTAL data model: Item Description, Publish/Sub-scribe, Homomorphism, Graph, Tree and Mediator(see [16]). These patterns were shown to be insuffi-

cient to provide the flexibility required in the CRISTALdata model. However, with enrichment of the Graph,Tree and Homomorphism patterns and the additionof a new Version pattern it has been possible to pro-vide the functionality required to integrate PDM withWfM, using a description-driven approach. Fig. 10summarizes the inter-relationship between the set ofpatterns identified for the integration of PDM sys-tems and WfM systems in the CRISTAL data model.It shows a Versioned Graph Pattern which has beenderived from the Version, Complex Graph and Pub-lish/Subscribe patterns. It also shows an Enriched Ho-momorphism pattern which has been derived from theItem Description and Mediator patterns. Furthermorethe diagram brings together the Complex Tree patternwith the Versioned Graph pattern from which it is de-rived.

Blaha and Premerlani [4] state that “patterns pro-vide a higher level of building blocks for models thanthe base primitives of class, association and general-ization”. This work has shown that this assertion isnot only true for models but can be extended to in-clude meta-models. In the CRISTAL projectmeta-data are used to reduce system complexity, aid datanavigability and reduce the effect of schema evolution

Fig. 10. The CRISTAL pattern summary.


and, in addition,meta-models are used to provide self-description for data and to provide the mechanismsnecessary for developing a query facility to navigatemultiple data models.

The meta-model approach to design reduces sys-tem complexity, provides model flexibility and can in-tegrate multiple, potentially heterogeneous, databasesinto the enterprise-wide database. A first prototypefor CRISTAL based on CORBA, Java and Objectiv-ity technologies has been deployed in the autumn of1998 [17].

References

[1] D. Georgakopoulos, M. Hornick, A. Sheth, An overview ofworkflow management: from process modelling to infrastruc-ture for automation, J. Distributed Parallel Database Sys-tems 3 (2) (1995) 119–153.

[2] M. Philpotts, An introduction to the concepts, benefits andterminology of product data management, Industrial Manage-ment Data Systems 4 (1996) 11–17.

[3] E. Gamma, R. Helm, R. Johnson, J. Vlissides, Design Patterns— Elements of Reusable Object-Oriented Software, Addison-Wesley Publishers, Reading, MA, 1995.

[4] M. Blaha, W. Premerlani, Object-Oriented Modelling andDesign for Database Applications, Prentice-Hall, EnglewoodCliffs, NJ, 1998.

[5] P. Coad, Object-oriented Patterns, Comm. ACM 35 (9) (1992)152–159.

[6] J. Rumbaugh et al., Object Oriented Modelling and Design,Prentice-Hall, Englewood Cliffs, NJ, 1991.

[7] M. Fowler, K. Scott, UML Distilled — Applying the StandardObject Modeling Language, Addison-Wesley Longman Inc.,Reading, MA, 1997.

[8] R. Haugen, Inventory by process stage: A useful patternfor integrating process and product, in: Proc. OOPSLA’98,Mid-Year Workshop on Implementing Lifecycle Process andProduct Models, 1998.

[9] OMG, CORBAservices: Common Object Services Specifica-tion, OMG Publications, 1994.

[10] Object Management Group Publications, Common FacilitiesRFP-5 Meta-Object Facility TC Doc cf/96-02-01 R2, Evalua-tion Report TC Doc cf/97-04-02 & TC Doc ad/97-08-14.

[11] Object Management Group Publications, Product Data Man-agement Enablers RFP, Manufacturing Domain Task ForceDocs mfg/96-08-01, mfg/98-01-01 & mfg/98-02-02.

[12] OMG, Workflow Management Facility — RFP OMG TC Docbom/97-05-06 & Joint Submission, OMG TC Doc bom/98-06-07, 1998.

[13] W. Schulze, C. Bussler, K. Meyer-Wegener, Standardising onworkflow management — the OMG workflow managementfacility, ACM SIGGROUP Bull. 19 (3) (1998).

[14] CMS Technical Proposal, The CMS Collaboration, January1995. Available from ftp://cmsdoc.cern.ch/TPref/TP.html.

[15] F. Estrella et al., The design of an engineering data warehousebased on meta-object structures, in: Lecture Notes in Com-puter Science, Vol. 1552, Springer, Berlin, 1999, pp. 145–156.

[16] Z. Kovacs, The integration of product data with workflowmanagement through a common data model, PhD Thesis,University of the West of England, April 1999, submitted.

[17] A Bazan et al., The use of production management techniquesin the construction of large scale physics detectors, IEEETrans. Nuclear Sci., to appear.

ftp://cmsdoc.cern.ch/TPref/TP. html

Documents

Design patterns for description-driven systems in High Energy Physics