abstract - wit press · the implementation of the concurrency model together with the mechanisms...

Object-oriented modelling, analysis and

concurrency in the boundary element

method

K.H. Lee, K.W. Tan

Department of Mechanical and Production

Engineering, National University of Singapore,

10 Kent Ridge Crescent, 0511 Singapore

ABSTRACT

The object-oriented modelling environment described in an earlier paper isadopted for the implementation of the boundary element method in two-dimensional linear elastostatics analysis. In this environment, objectrepresentation is facilitated with the use of three different application classes,namely, the geometry, the mesh and the system of equations. Objectcommunication is made through communication channels and messages. Adatabase management system is employed for the matrices in the system ofequations in order to provide a good referencing system for equationcoefficients belonging to entities in the geometry and mesh classes. The objectrepresentation thus allows the integration of the modelling with the analysis byenabling the incremental creation of the matrices to proceed in parallel withthe construction of the geometry and the mesh. It also enables the analysisprogram to calculate only those matrices which are associated withmodifications made to the geometry and the mesh. Furthermore, the nature ofthe object-oriented modelling and analysis makes it an ideal candidate forobject-based concurrency. The implementation of the concurrency modeltogether with the mechanisms for communication and resource managementare described in this paper.

INTRODUCTION

Present research in computer-aided design (CAD) systems involvingcomputational mechanics has progressed beyond the integration of solidmodelling technology with fully automatic mesh generation. It has led touseful pre-processing features such as associativity between geometry andmesh as well as important post-processing features like sensitivity analysis and

Transactions on Modelling and Simulation vol 1, © 1993 WIT Press, www.witpress.com, ISSN 1743-355X

596 Boundary Elements

optimization. Automatic error analysis and adaptive mesh refinement, too, arealready found in many CAD systems.

There has also been an increasing interest in developing systems whichdepart from the traditional end-to-end connection of the three well-definedphases presently found in practically all CAD software. The software useralways begins with the pre-processing phase where he constructs the solidmodel or geometry and enters the relevant material properties and boundaryconditions. On completion of this task, he leaves the analysis or computationphase entirely in the hands of the computer. Once the analysis is over, hereturns to perform the post-processing phase where he obtains the desiredresults in numerical or graphical form. If he is not satisfied with the results, hemakes changes to the geometry, material properties or boundary conditionsand repeats the sequence. Product design is well recognized as anevolutionary process during which localized changes in geometry are madefairly often for functional, structural integrity and manufacturing reasons. Thismeans that the software user carrying out a design task may have to gothrough the three phases in an end-to-end manner many times fully knowingthat many of the matrices in the system of equations are unchanged but arenonetheless recalculated. Used in this way, the software package whether it bebased on the finite element method (FEM) or the boundary element method(BEM) functions more like a diagnostic tool than a design tool. It is for thisreason that researchers have looked at ways to release this end-to-endconnection especially within the context of linear analysis.

The advantage of releasing such an end-to-end requirement is that itallows parallel activities among the three phases. In the absence of thisrequirement, independent parts of the computation phase can be carried out byother processes in the background in a transparent manner while the userproceeds with the definition of the solid model or geometry. Allowingnumerical computation to start when the geometry is only partially definedwill shorten the overall turnaround time. This level of concurrency isparticularly useful when the geometry is very complicated and time consumingto construct.

As early as 1988, Miller [1] made the above observation in the area ofstructural analysis. He introduced a LISP-based approach which made use ofobject-oriented data structures. The flexibility inherent in this type of datastructure makes it possible to analyze structural models incrementally as theyare defined. At the same time, it allows the development of a matrix-freesolution algorithm for computing the equivalent of the inverse matrix for anarbitrary assemblage of linearly connected objects. In a subsequent paper onobject-oriented concurrent structural analysis, Miller [2] explored thepossibility of concurrency and the parallel processing of tasks arising fromdifferent parts of the structural model. He emphasized the need to provide a


Boundary Elements 597

basic framework for parallel computations to occur and to address theprincipal problems in concurrent processing such as synchronization, deadlockand divergence. Although Miller considered the actor model of Hewitt el al.[3] to be the most promising approach, he did not address the issues ofconsistency and correctness. These important issues surface when the object-oriented modelling environment allows modifications to be made on parts ofthe geometry for which computations have already been performed or areongoing. This is a special problem that occurs only when the pre-processingphase proceeds in parallel with the analysis or computation phase.

Although practically all of the observations of Miller for object-oriented concurrent structural analysis also apply to the FEM, they cannot becarried over to the BEM because the numerical formulations and algorithmsfor these two methods are essentially different. In the FEM, only informationpertaining to the element in question is required in computing elementcharacteristics such as the stiffness matrix and the load vector. This naturallymakes the implementation of concurrency at both the geometry and mesh levelfairly straightforward. However, this is not true of the boundary elementmethod because it requires information on both the boundary element (thefield) and the boundary node (the source). This requirement complicates notonly the implementation of concurrency due to interactions between theboundary element and the boundary node. It also makes the issues ofconsistency and correctness more difficult to tackle.

The aim of this paper is to describe the implementation of anintegrated design environment for object-oriented modelling, analysis andconcurrency which allows parallel activities among the three phases of pre-processing, analysis and post-processing. The main features of theenvironment for object-oriented modelling and analysis have already beenintroduced in an earlier paper by Lee and Tan [4] and are thus not reproducedhere. Instead, the paper will focus on the scheme for achieving object-basedconcurrency as well as the mechanisms for communication and resourcemanagement

Although object-oriented concurrency of the form indicated above isseldom discussed in the open literature, the use of object-orientedprogramming for the development of engineering and FEM software has beenproposed and implemented by a substantial number of researchers who wishto take advantage of code reusability and extendibility via the mechanisms ofinheritance and polymorphism. Notable among them are the works of Forde elal [5], Fenves [6], Forde et al. [7], Ross et al. [8, 9] and Mackie [10]. Thesepapers describe the problems with conventional engineering and FEMsoftware and the potential solutions and advantages offered by object-orientedprograms.



PARALLELISM IN THE BEM

In order to appreciate the avenue for parallelism in the BEM, it is useful toconsider the form of the system of equations obtained after discretization. Forlinear elastostatics, the equations can be represented in matrix form as

Hu = Gt (1)

where it is understood that each row of the matrix equation is derived from aboundary integral equation wriiten for a source node. A coeficient in the rowcan be interpreted as the influence which the particular displacement ortraction variable at the field node has on the displacement at the source node.The whole row can thus be seen as the total influence of the variables at all thefield nodes (including the source node) on the displacement at the sourcenode.

This interpretation at the inter-variable level can be extended to theinter-node, inter-element and inter-boundary levels. At any level, the influenceexperienced by a party comes from all parties, including itself, at the samelevel. The mutual influence occuring between two parties can be representedseparately and computed independently as soon as information on them isavailable.

Suppose the inter-boundary level is being considered. For the sake ofdiscussion, let there be two boundaries in the problem, such as a plate with ahole labeled E and /, respectively. The matrix equation (1) can be partitionedinto two halves, with each half describing the influence experienced by oneboundary. In this example, the total influence on each boundary comes fromtwo boundaries, with one from itself and the other from the other boundary. Inmatrix form, the influence experienced by boundary E is

t},+[GUt}, (2)

and that experienced by boundary / is

[HUuh+[H],,{u}, =[GUt},+[G],,{t}, (3)

The influence which boundary E has on itself is given by the first termon either side of equation (2). The remaining terms in the same equationaccount for the influence of boundary / on boundary E. When the influencedand influencing boundaries are the same, the terms in the equation shall bereferred to as self terms. In contrast, when the influenced and influencingboundaries are different, the terms shall be known as cross terms. Similar self



and cross terms can be found in equation (3). Putting equations (2) and (3)together give

(4)

The coefficient matrices on both sides of the above equation are nowmade up of four sub-matrices, as shown. Each sub-matrix can be computedindependently from one another and requires information pertaining to theboundaries indicated by its subscripts.

Similarly, when there are three boundaries in the problem, such as aplate with two holes labeled £, / and ̂ respectively, the global matrix can bedecomposed into sub-matrices as shown below in equation (5). Again, eachsub-matrix can be computed independently from one another and requiresinformation pertaining only to the boundaries indicated by its subscripts.

[H],,

W, (5)

It is observed that there are two possible levels of parallelism in theBEM, namely, one between the pre-processing phase and the computationphase and the other within the computation phase itself. The former is madepossible by computer hardware and software that support multi-programmingor multi-processing as well as by releasing the end-to-end connection betweenthe pre-processing and computation phases. The latter arises from theparallelism inherent in the BEM formulation. Furthermore, parallelcomputations can be introduced at the various inter-node, inter-element andinter-boundary levels described earlier. Each of these levels offers anopportunity for concurrent processing.

When parallelism at the two broad levels mentioned above areimplemented together, the resulting scheme is able to perform boundaryelement modeling and analysis in a parallel and incremental manner. Thisscheme can be illustrated by a simple example with three boundaries, such as aplate with two holes. Suppose the user builds up the geometry by firstconstructing the external boundary £, followed by the first hole /, and endingwith the second hole /. After the construction and discretization of aparticular boundary, the system automatically sends the information relating tothe boundary to the background processors which then commences with thenecessary computation phase at the inter-boundary level as follows.



• When boundary E is sent to the background, only a pair of sub-matricesneeds to be computed.

(6)

Next, when boundary / is sent to the background, three additional sets ofsub-matrices matrices have to be computed. These are indicated in bold inthe matrix equation below.

(7)[H]{u}"[GL

Finally, when boundary J is sent to the background, five additional pairs ofsub-matrices need to be computed. Again, they are indicated in boldbelow.

[H],,

[GL

W,

(8)

In summary, the computation phase consisting of the creation of thesub-matrices can proceed in parallel with the pre-processing phase involvingthe generation of the solid model or geometry. The computation phase can inturn be decomposed into independent sub-tasks which can also be executed inparallel.

Grain SizeEach independent activity in the selected level is a unit of parallelism called agrain. It is defined as the average size of a sequential unit of computation inthe program, with no interprocessor synchronization or communication withinthe unit (see Sarkar [11]). From the discussion above, it is evident thatparallelism in the BEM can be implemented on one extreme at the inter-boundary level, or on the other extreme at the inter-variable level. The formeris known as coarse-grain concurrency as the number of grains involved isrelatively small, whereas the latter is known as fine-grain concurrency.

Level of ConcurrencyThe selection of the appropriate level of concurrency is a key concern in anyimplementation because it has a direct bearing on two competing factors,namely the degree of speedup and the overhead cost. Overhead costs areincurred as a consequence of interprocessor communication, memorycontention, synchronization, scheduling and other system activities. The



selection of the optimal grain size depends on the characteristics of thehardware and the nature of the problem. The level of concurrency adopted inthe present mplementation is at the inter-boundary level.

THE CONCURRENCY MODEL

This section describes the framework that performs the incremental parallelprocessing and the responsibilities of the respective components found in theframework. The following two sections will then focus on the mechanisms ofcommunication and resource management in the system.

System and ComponentsThe system consists of five main components, namely, the modelling system,processor manager, processing units, boundary database and matrix database.Except for the modelling system, the other four are implemented in thebackground and are transparent to the user. Of the five components, the firstthree are implemented on separate processors whereas the remaining twodatabases are implemented on shared memory. Each of the processors andshared memory has a unique name so as to facilitate communication andmemory access. Interprocessor communication is adopted among theprocessors. The semaphore mechanism is embedded to ensure the integrity ofthe databases. The structure of the system is shown schematically in Figure 1.

s

boundary database

rf 1

[ modelling system ] — [ processor manager • — [ processing unit

matrix database

Figure 1 Framework of the concurrency model.

Modelling System This is the front end interface of the system that allows theuser to construct the geometry and the mesh using the available applicationclasses. It communicates only with the processor manager in order to requestfor services, and it has access to the boundary database that stores the data foreach boundary required in the background computation.



Processor Manager It is responsible for channelling the requests of themodelling system and for monitoring and controlling other processing unitsthat actually carry out the requests. It must ensure that the requests made bythe modelling system are carried out in the fairest possible manner so that allprocessing units can be fully utilized. It carries out its tasks by communicatingwith both the modelling system and all other background processors usingmessage sending.

Processing Unit It performs requests from the modelling system and comesunder the control of the processor manager. It has access to both types ofdatabases; read access to the boundary database and both read and writeaccess to the matrix database. Throughout its life cycle, it can be in one ofthree stages, namely idle, active and pending. Generally, available processingunits are shared by several processes as the latter are usually more in numberthan the processors available. To provide the maximum possible number ofconcurrent activities, the task handled by each unit is independent of oneanother. Thus, synchronization among them is kept to a minimum.

Boundary Database As the name suggests, it contains information pertainingto the boundary. The information is arranged in an object-oriented manner sothat each boundary is stored as a separate unit and has a unique access key.The access key is the same as the object identification number of the graphicsentity created for the boundary in the object-oriented modelling system so thatthere is a direct link between the two.

Matrix Database It stores all the sub-matrices computed by the processingunits. Again, the object-oriented arrangement of information is adopted here.Each sub-matrix is thus stored as a single unit and has a unique access key.This time, the access key consists of the object identification number of theinfluenced boundary followed by that of the influencing boundary. Within eachsub-matrix, the information is further sub-divided into smaller pieces tofacilitate access for updating because modifications on the mesh can be madeat the element level.

COMMUNICATION

General Characteristics

One-to-Qne Communication Processors communicate in a one-to-one mannerinvolving a sender and a receiver. The requirement is that the sender mustknow the receiver's identification number, which is a unique number assignedto the processor during creation and will persist throughout the life cycle of theprocessor. This communication is usually one way. However, a dialogue can beeasily implemented using two one-way channels.



Minimized Communication Any communication must be done in the shortestpossible time and kept to the minimum among processors so that nounnecessary waiting time is wasted.

Asvnchrony On one hand, the sender can send a message to any processor atanytime, irrespective of the current state of its target. On the other hand, thereis no requirement on the receiver's part to pick up the incoming messagesimmediately unless it is in the idle stage. This type of communication requiresno synchronization between the two parties. Therefore, the sender need notwait unnecessarily for the target but can proceed to its next activity after thesend operation. Similarly, the receiver is not disrupted from its presentactivities by the incoming message. This mode of communication encouragesconcurrent processing in the system, as no unnecessary waiting time isincurred.

Buffered Communication On the basis of asynchrony discussed above, there isa need to have a message queue for each processor which acts as a buffer forthe incoming messages. The message queue is processed in a first-in-first-outmanner.

Communication SystemIn this system, the dialogue channel is adopted. One such channel is establishedbetween the modelling system and the processor manager and another onebetween the latter and each processing unit. No direct channel is requiredbetween the modelling system and the processing unit nor are there anybetween pairs of processing units. The network is shown below in Figure 2.

processing unit

(modelling system ) — [processor manager]

I processing unit

-communication channel

Figure 2 Communication system in concurrency model.

Message TypesThe two most fundamental interface functions are the send and receivefunctions. There also exist more specific messages relating to the computationof sub-matrices. The specific messages between the modelling system and the



processor manager, and those between the processor managerprocessing unit, are given below in Figures 3 and 4, respectively.

and the

modelling systemsend

create bdry matupdate bdry matdelete bdry matrequest progress

receiveacknowledgeprogress report

processor managersendacknowledgeprogress report

receivecreate bdry matupdate bdry matdelete bdry mat

^ request progress

Figure 3 Messages between modelling system and processor manager.

processor managersend

create bdry matupdate bdry matdelete bdry matquery statuspermission reply

receivestatus reportrequest permission

processing unitsend

status reportrequest permission

receivecreate bdry matupdate bdry matdelete bdry matquery statuspermission reply

Figure 4 Messages between the processor manager and processing unit.

RESOURCE MANAGEMENT

A resource in a concurrent environment may be defined as a facility for whichseveral processes compete. Two common types of such resources are theprocessing units and the databases.

The need to share the processing units arises from the fact that thereare usually more processes than processing units. Furthermore, the fluctuationin the computing requirements among these processes makes the sharing ofthe processing units necessary in order to avoid wastage of resources. In thecase of the databases, the sharing is mandatory as there are usually severalprocesses requiring the same set of information for their jobs. For instance, the

processes for computing the sub-matrices [H]̂ and [H]̂ both require

information pertaining to boundaries E and /.



The main challenge in managing resources is to ensure fairness in theallocation. This is usually achieved by satisfying resource requests in a first-come-first-served basis.

Processing Unit ManagementThis is put under the charge of the processor manager. The manager isresponsible for ensuring that the distribution of workload among theprocessing units is evenly done. This is commonly known as load balancing.To carry out this task, the manager must maintain an up-to-date report on thesize of the computations, which is measured in terms of the nodal variableswaiting in the queue of each processing unit. An up-to-date report is ensuredby requesting all processing units to give their current status through thesending of a status report to the manager.

Database ManagementThe consistency and correctness of a database are the two most importantissues in database management.

Consistency This is enforced at two levels, namely, the single transactionlevel and the parallel transaction level. The transaction is a unit of work thatbrings the database from one consistent state to another. Inconsistency mayarise if the transaction is completed only partially.

At the single transaction level, inconsistency may arise if only part ofthe operation is completed. For example, if the updating of data relating to aboundary is only half done by the modelling system, the resulting data will beinconsistent as parts of the data belong to the current stage while the restbelong to the previous one. Any further action based on the data will beincorrect. Therefore, in order to avoid this problem, the transaction must beperformed completely or not performed at all. This concept is known asatomic action.

At the parallel transaction level where several processes are trying toaccess the database at the same time, a consistency problem may also arise.For instance, when the modelling system is updating the data for a boundary ina particular sequence, a processing unit may be trying to read the same databut from the opposite sequence. This may result in inconsistent data beingread, as part of what has been read belongs to the previous version of theboundary. Generally, this problem may arise when among all the processessharing the database, there are one or more processes performing a writeoperation. The usual practice in solving this problem is to introduce a lockingmechanism which allows only one of the competing processes to haveexclusive access to the database. One important rule in using this mechanismis that the lock must be enforced for as long as the data is in use by theprocess in order to ensure that the same set of data is used throughout. The



section of the program that has exclusive use of the shared data is known as acritical region. However, this locking mechanism may give rise to two otherproblems, namely, deadlock and starvation.

Deadlock occurs when processes are mutually blocked in their attemptto obtain resources because each process holds on to one or more resourcesrequired by two or more competing processes. The deadlock problem isautomatically solved if all processes required a different set of data. However,this is unlikely in object-oriented concurrency because there always exist twoprocesses which need to have access to data from two boundaries in thecalculation of the sub-matrices involving the cross terms. In the presentimplementation of the concurrency model, a solution is found by emulating asituation whereby each process has access to data from one boundary at anyone time such that no deadlock situation arises. This requires the criticalregion to reduce to only over the instance of read or write instead of the usualdefinition of the critical region so that the process can move on to access thenext set of data. This short critical region actually promotes betterconcurrency. It may seem unconventional to reduce the critical region to onlyduring the read or write operation but it works perfectly well with theconcepts of optimistic strategy and versioning to be discussed in the nextsection.

Starvation, also known as indefinite postponement, occurs when aprocess is repeatedly denied resources because the allocation is not performedfairly. This problem can be solved by employing the semaphore mechanismwhich enables exclusive access to the shared data by one process whilesuspending the other competing processes. This mechanism also enables thereallocation of shared data to the following processes in the queue on a first-come-first-served basis after it has been released.

Correctness This is a big issue in concurrent processing due to the interleavedexecution of operations which can lead to incorrect results despite earlycompletion. The correctness criterion, known as serializability, ensures thatthe effect of executing several transactions in parallel is the same as that ofexecuting them serially in some order. This criterion is enforced by a systemcommonly known as the concurrency control system. Of the many schemesavailable for the concurrency control system, the optimistic strategy (withsome modification) is adopted in the present concurrency model.

In optimistic strategy, the transaction manipulates a shadow copy ofthe database in its own workspace and then submits a commitment request.The request will be accepted or rejected depending on whether or not itconflicts with other transactions (see Maier and Stein [12]). This schemeensures that the most up-to-date data is being used in the computations. It isparticularly useful in the present object-oriented concurrency model because it



is fairly common for the user to make errors in the definition of the geometrywhich are corrected only after some processes involving the computation ofsub-matrices have been completed in the background. Without a scheme forrenewing those processes which are executed using old data, the final resultwill be an incorrect one. Therefore, it is the responsibility of the concurrencycontrol system to avoid this problem. The optimistic strategy provides thesolution because those background processes that do not use the most up-to-date information are trapped at commitment time so that the necessarycorrection can be performed. For those processes which are alreadycompleted, new processes based on the latest version of the data are initiated.For this simple concept to work properly, the notion of versioning must beintroduced into the concurrency control system.

Versioning is widely recognized as one of the most importantfunctions in areas where users need to generate and experiment with multipleversions of a design before selecting one that satisfies most of their needs. It isbecoming a very important notion in the area of engineering design and hasbeen studied by Attwood [13], Chou and Kim [14] and Katz et al. [15].Basically, it attaches a version number to the data such that the process canaccess any version of the data. In the present implementation of the currencycontrol system, the version number doubles up as a means of comparing thelatest version with the version used by the background process. If there is anyviolation, corrective measures can be effected immediately.

CONCLUSION

The implementation of an integrated design environment for object-orientedmodelling, analysis and concurrency in two-dimensional elastostatics analysisusing the BEM has been described. Attention was focused on the concurrencymodel which was adopted for achieving parallelism in the BEM. Theframework of the model consists of the modelling system, processor manager,processing units, boundary database and matrix database. The mechanisms forcommunication and resource management were explained, and the importanceof selecting appropriate schemes for maintaining the consistency andcorrectness of the databases was emphasized. In particular, the optimisticstrategy concurrency control system was chosen to ensure the correctness ofthe databases.

REFERENCES

1. Miller, G.R. 'A LISP-Based Object-Oriented Approach to StructuralAnalysis' Engineering with Computers, Vol. 4, pp. 197-203, 1988.

2. Miller, G.R. 'Object-Oriented, Concurrent Structural Analysis' inComputing in Civil Engineering (Ed. Barnwell, T.O. Jr.), pp. 36-43,



Proceedings of the Sixth Conference on Computers in EngineeringPractice, Atlanta, Georgia, USA, 1989. ASCE, New York, 1989.

3. Hewitt, C.E., Bishop, P. and Steiger, R. 'A Universal Modular ACTORFormalism for Artificial Intelligence', Proceedings of the ThirdInternational Joint Conference on Artificial Intelligence, 1973.

4. Lee, K.H. and Tan, K.W. 'An Object-Oriented Modelling Environmentfor the Boundary Element Method' in Boundary Elements XII Vol. 2Applications in Fluid Mechanics and Field Problems (Ed. Tanaka, M.,Brebbia, C.A. and Honma, T.), pp. 449-461, Proceedings of the TwelfthInternational Conference on Boundary Elements in Engineering,Sapporo, Japan, 1990. CMP, Southampton, 1990.

5. Forde, B.W.R., Russell, A.D. and Stiemer, S.F. 'Object-OrientedKnowledge Frameworks' Engineering with Computers, Vol. 5, pp. 79-89, 1989.

6. Fenves, G.L. 'Object-Oriented Programming for Engineering SoftwareDevelopment' Engineering with Computers, Vol. 6, pp. 1-15, 1990.

7. Forder, B.W.R., Foschi, R.O. and Stiemer, S.F. 'Object-Oriented FiniteElement Analysis' Computers and Structures, Vol. 34, pp. 355-374,1990.

8. Ross, T.J., Wagner, L.R. and Luger, G.F. 'Object-OrientedProgramming for Scientific Codes. I: Thoghts and Concepts' Journal ofComputing in Civil Engineering, Vol. 6, pp. 480-496, 1992.

9. Ross, T.J., Wagner, L.R. and Luger, G.F. 'Object-OrientedProgramming for Scientific Codes. II: Examples in C++' Journal ofComputing in Civil Engineering, Vol. 6, pp. 497-514, 1992.

10. Mackie, R.I. 'Object Oriented Programming of the Finite ElementMethod' International Journal for Numerical Methods in Engineering,Vol. 35, pp. 425-436, 1992.

11. Sarkar, V. Partitioning and Scheduling Parallel Programs forMultiprocessors MIT Press, Cambridge, 1989.

12. Maier, D. and Stein, J. Development and Implementation of an Object-Oriented DBMS' in Research Directions in Object-OrientedProgramming (Ed. Shriver, B. and Wegner, P.) MIT Press, Cambridge,1987.



13. Attwood, T. 'An Object-Oriented DBMS for Design SupportApplications', Proceedings of the IEEE COMPINT Conference,Montreal, Canada, 1985.

14. Chou, H.-T. and Kim, W. 'A Unifying Framework for Version Control ina CAD Environment', Proceedings of the International Conference onVery Large Databases, Kyoto, Japan, 1986.

15. Katz, R., Chang, E. and Bhateja, R. 'Version Modeling Concepts forComputer-Aided Design Databases', Proceedings of the ACM

• Conference on the Management of Data, Washington, DC, USA, 1986.


abstract - wit press · the implementation of the concurrency model together with the mechanisms...

Documents