Budding and Enmronment, Vol 27, No 2, pp 163-171, 1992 0360-1323/92 $5 00+0 00 Pnnted m Great Britain © 1992 Pergamon Press Ltd

Sharing Data Between Application Programs in Building Design : Product Models and Object-Oriented Programming

A. J WRIGHT* S R- LOCKLEY* T J WILTSHIRE*

This paper reviews current developments m Ob.lect-Ortented Programming and data exchange standards m relatwn to the use of computer software in budding design The problems of creat,ng complete product models for budding are consldered and an alternative strategy based on the concept of sharing Local Product Models between related apphcat:ons ,s proposed Some criteria for selectwn of Local Product Models and determining thetr contents are gwen and conclusions are drawn about future developments

1. INTRODUCTION

THE CURRENT generation of software for building performance evaluation ranges from simple calculations which could be done manually, such as the calculation of average daylight factor or steady-state heat loss, to thermal simulation of complete buildings involving milli- ons of calculations. Most of the current programs are written m FORTRAN, C, BASIC, or similar procedural languages with arbitrary internal data structures

In most cases, the data sets are entirely incompatible and there is almost no sharing of code, even when the programs share a similar overall functionality. These problems have been discussed elsewhere [1-4], to sum- manze, the incompatibility results from the use of different conceptual frames, leading to the following problems

- - lack of agreed definmons and data models for building descriptions

-- incompatible data sets, arbitrarily defined for each program

--independent development of most programs --diversity of hardware and software environments

Three parallel developments, which have emerged from work on conceptual data models and database design combined with development in Artificial and Intel- ligence and programming languages, offer new tools and approaches which may solve some of these problems_ These are Object-Oriented Programming, Data Exchange Standards and Product Modelling. All of these are closely linked and concerned with the logical design of the data structure.

* The School of ArchltOeture, Umverslty of Newcastle upon Tyne, U.K

163

2. OBJECT ORIENTED TECHNIQUES IN BUILDING SIMULATION

Object-Onented Programming (OOP) has a relatively long history in computing ; the two most important 'clas- sical' OOP languages are SIMULA [5] and Smalltalk-80 [6] ; but only in recent years has it gained in popularity in many areas of software development, as the hardware powerful enough to support it has become cheap and widely available, and the technique has proved Its worth in improved productlwty and quality of software [7]

Simulation is particularly suited to an OOP approach because it is based on structured data types, or classes, which provide a logical mapping from the types of real- world objects being simulated A class represents the data structure and behawour of the type, here, behavtour means encapsulated data and functions. Functions are often called methods in the OOP world Instantlations of classes are called objects, they represent real-world objects, with the data structure of the corresponding class filled out with values.

It should be clear that OOP shifts the emphasis m software structures away from procedures and functions and on to the data. This often brings greater re-use of code According to Meyer [7],

Programming is a highly repetitive activity, involving frequent use of common patterns .. commonly accepted notions of module are simply not adequate to support senous reusabil i ty. . ,In object-oriented design, the primary design issue is not what the system does, but what objects it does it to . Classes should be designed to be as general and reusable as possible, the process of combining them into systems is often bottom-up.

This means that OOP is suitable for supporting a num-

164 .4 J ll')'tqht et al

ber of apphcatlons which refer to the same real-world objects, which can hence share the same OOP classes and objects

It has long been recognized that an integrated enwron- ment is highly desirable for building design tools and simulation In such an environment, programs share common sets of data and functions For the first time, OOP techniques appear to offer the possibility of achiev- ing such integration and resolving the problems with current apphcanons described above A number of pro- jects are already under way around the world to exploit this technique for thermal slmulanon of buildings, plant and control [3, 8 10]. However, work to date on these projects also indicates that re-use has hmitatlons, as they presently stand, few if any classes defined in any one of these systems could be used in another, because of arbitrary decisions made during class design and because they are based on fundamentally different approaches to solving equations

3. A STANDARD FOR THE EXCHANGE OF PRODUCT DATA

Parallel to the developments in OOP, an international standard is emerging for the exchange of product data There has always been a need for a common format for the exchange of data in the engineering and construction industries, but this has become more acute with Increas- Ing volume and complexity of information being trans- ferred, coupled with greater integration of markets The inability to share information is seen as a major technical barrier to the effective deployment of Information Tech- nology m the construction and transport industries

The principal medium of data exchange is still text and drawings on paper, with laborious and error-prone translation required into the unique representations for each different piece of software Some de facto standards have emerged for drawings in CAD, the main ones being the Drawing eXchange Format (DXF) file format and the International Graphics Exchange Standard (IGES), which allow transfer between different CAD languages Although useful, these formats are limited to the notions of geometric entities (16 in total for DXF), blocks of entlnes and text strings which are 'attached' to entities and blocks_ They are the electronic equivalent of an anno- tated drawing, lacking semantic depth

In a similar way, some other types of software have a specialized neutral format, such as ISO 8879 Standard General Mark-up Language (SGML) for desk top pub- hshing Another, less flexible but simpler approach, widely used in commercial office software, as to allow direct transfer of files in several different formats, for example spreadsheet programs which can translate files from other spreadsheet programs into their own format

In an attempt to overcome the problems of exchanging engineering data, the Standard for Exchange of Product data (STEP) is a major international effort with the aim of creating a standard for this STEP is about to become an ISO draft proposal [11]_ Its overall structure is shown m Fig 1, which shows the breakdown, by application, moving down a level implies an increased specialization It is divided into three main areas of application, Build- mg descriptions come within the area of Architecture,

STEP General STEP layer

F~g l

AEC I [Oechon,co, 1 Electncal/ Electronic

Indust~-Iype layer

Producl-~pe layer

Non-STEP layer

Structure of the STandard for Exchange of Product data (STEP) showing dTfferent layers

Engineering and Construction (AEC) The fourth (bot- tom) layer of Fig 1 is the non-step layer which holds entitles defined outside STEP This includes national standards, industry standards, etc which are considered too speclahzed to be part of STEP Figure 2 shows a more detailed breakdown for buddmgs

The whole STEP system is also divided into three main layers

The logical layer is a logical or semantic description of the data items and how they relate to each other It includes the data modelhng language EXPRESS used to describe the structure of data and definitions of entities which are common to all application areas, such as geometry_

The application layer contains data definitions for par- tlcular application areas and definitions shared by several application areas The following application models which relate to buildings have been proposed

Building Systems Model --Plant Design Model --Distributions Systems Model --General

The physical layer describes the structure of the product data In files, used in actual exchange between programs. Files are in a human-readable ASCII format, although they would not be read in normal use.

In STEP, the EXPRESS files defining data structure are analogous to class definitions in OOP, while the physi- cal files describing actual entitles according to a cor- responding EXPRESS structure are analogous to objects in OOP This is illustrated in Fig 3 A format called STEP-2DBS has been developed by the German budding mdustry for the exchange of 2D lnformanon between CAD systems specific to the needs of the industry [I 3]. This is not strictly part of STEP, and IS not written m EXPRESS, but it is based on the STEP standard It Is intended as a replacement for IGES, DXF and other formats, which are regarded as unsatisfatory, and is still essentially a geometric model with 11 basic geometric enntles (line, polygon, etc ) defined Although the system has a concept of general "entity', allowing the possibility of richer semantics, this is provisional because, according to the authors of STEP-2DBS.

Product Models and Object-Oriented Proyramming 165

lndultry - revel AEC Product Deflr.bon Unit

GtmlrQttxQt..an / Spec~atlz~aon

i I I I I Sh=p PDU Ptant PDU Bu=Ldtng PDU Road POU Bridge PDU

P r o ~ c t - t ~ e t - B u l ~

CIneratlzotmn/SI)ecm(izotlon

I i 1 I BSA B I}IC Sfb tabto I Ptow~n Cl~

Non-STEP LeveL Sfb C-e ner at UmtdOn/Specmld za t ~n

I 1 I I 1 1 Ground

S~te substrucbJre Structure Comptlbtmnt Fmlshl~ Servtcm

- - l l II 11 II II

I

I Fltbngt

l[ ] Fig 2 An example of speclahzatlon within AEC Several classification systems are used for building products One is SfB which has been adopted for international use by CIB, it identifies seven classes of building elements Each of these can be decomposed further (not shown) Because it does not belong to

the STEP standard, the SfB code is put in the non-STEP layer From [12]

generally accepted entitles are not yet available System vendors seem to be going in different directions with technical attnbutes_ It would therefore be useful to have data dictionary entities. However, since few CAD systems have access to databases which can use this facdlty, this route is not foreseen m the first stage of extending the STEP-2DBS interface

Even so, the only valid types for the 'attributes' of entry in STEP-2DB are stnngs and numbers, not other entrees It IS reasonable to conclude that, although the concepts of STEP and the EXPRESS language are quite well developed, actual implementation and definmon of standard entities in the building industry has hardly begun.

4. PRODUCT MODELS

The STEP standard is closely linked to the concept of Product Models A Product Model can be thought of as a set of entities which together form a system, or single product, of interest Giehngh [14] defines a Product Model thus

A product model contains 'complete' and non-ambigu- ous information about a product. Complete in the sense that all information required for a specific appli- cation, if avadable, will be specified as an integral part of the product-model or can be derived from it

Product Models lie on a spectrum from very general to highly specialized We are used to deahng with specialized product models and doing mental mappings to other product models. A Quantity Surveyor may think of a brick wall in terms of cost per unit area, a Contractor may think of it in terms of work schedule and materials, while a Thermal Modeller may only consider at as a layer with thermal properties; each viewpoint leads to quite different representations.

Many m the STEP community believe that it is possible to define comprehensive product models for a given application area (eg Building) [15] A number of approaches are being tested in Finland for describing a braiding [16]_ In this context, Smith [17] defines a product model thus

The term product data denotes the totahty of data elements which completely define the product for all applications over its expected hfe cycle Product data includes the geometry, topology, relationships, tol- erances and features necessary to completely define a component part or an assembly of parts for the pur- poses of design, analysis, manufacture, test and inspec- tion

Note that this is an absolute definition, compared to Glehngh's which is relative The authors of this paper beheve that Smith's definition is simply not realistic for bulldmgs, there lS no absolute level of completeness The

166 A J_ Wrtght et al.

~ l / l ' t . =~l==t ,¢,.~,s~

Ira,

==Lm=l~=_,t'~d=~ - 1t.~M4,2); m,,m_,l~

EX]=RE,~.q DBqNmON FILE

l•lm. N('.~,.Q~D ucr.sl"l,. ) ]1

@ n~,,tnmucr~m=t1,".o,66o.o3s 3, 1 I @ f~= ,~ /~ucr~ ,o.o.o,#~,,); •

l,

EXPRESS DATA FILE

C-H. HEADER FILE

0 O 0 0 0 0 e 0 0 O

OBJECT IN O00B (not human readable)

Fig 3 The EXPRESS file defining an entlty's data structure, the corresponding STEP physical file for an entity, a C+ + file defining the structure of an equivalent class in C+ + and an

actual object m an Object-Oriented Database

'completeness' described by Smith and Glehngh is only true for a closed system and it is always possible to find apphcatlons which require data which are not contained within such a comprehenswe or 'global ' Product Model

For example, a thermal slmulaUon may require the room natural ventilation rates and casual heat gain pro- files, but these will certain be absent from even the most detailed product model of a building, because they are only the concern of this appllcaUon and cannot be derived from the other information. In pracUce, they will come from the expert knowledge of the person carrying out the simulation

The reality is that building designers already use a large number of informal product models, each speclahzed to a particular task or group of tasks m a parUcular domain The process of specmhzatlon starts with a more general product model or, more hkely, data m the real world in various forms; some of this will be available to other members of the design team, but a s~gnlficant amount, which is domain-specific and depends on expert knowl- edge, will be added to it Sometimes, these speclahzed product models are formahzed for use in computer pro- grams.

5. S P E C I A L I Z A T I O N IN P R O D U C T M O D E L S

The process of speclahzatxon may involve several stages, the resulting model at each stage may be of use to different people An example serves to illustrate the changes which occur m this process

For a given domain, increasing speclahzation results

m a product model which, compared to the original data set

is suited to a particular set of applications has a compressed data set

--incorporates implicit domain knowledge - -conta ins more assumptions

To put it briefly, data (facts) are traded for information (knowledge) There are two basic ways of achieving specialization in an obJect-oriented data environment The first is through inheritance a descendant class inherits all the data definition and methods of its parent, but may have addmonal data defimtlons, and redefine and add Its own methods For example, a general NumberSet class could be defined for a set of numbers, with methods for intersection, union, adding members, etc A descendant class, StatNumberSet could then be defined with ad&- tlonal methods for calculating the mean, median and variance This would be statable for a situation In which the individual data may still be of interest, e_g m a climate database used in simulation where the numbers represent a chmauc variable measured at hourly lnterval~

The other form of specmllzanon in OOP, which does not use Inheritance, is to define a separate class which replaces methods with data members Using the Stat- NumberSet example above, one could define a separate class StatSummary which no longer contained the orig- inal numbers, but had the mean, medmn and variance as data members This usually achieves greater data com- pression, but is highly speclahzed and so is of less general use_ In the case of climatic data class above, such a StatSummary class might be of interest to characterize dzfferent chmate data sets where measurements were of no interest

Consider an example (at a conceptual level) of specml- lzahon of a wall description for thermal analysis at various levels of physical detail Figure 4 shows the pro- cess of specmhzation apphed to a cavity wall At some detailed level of description, there is a full 3D geometric descriphon including wall ties, floor joints, etc and each leaf is represented by an arrangement of blocks and mortar At this level, the overall resistance of the wall could, in principle, be calculated taking into account edge and corner effects, wall tie conduction, etc This representation could also be used for a dynamic heat conduction analysis of, say, a corner using finite elements

At the next level of speclahzatlon, the wall is approxi- mated by a set of layers between two surfaces bounded by sets of vertices, ignoring features which do not fit the layer model such as wall ties, and edge and corner details Each leaf is represented by a homogeneous layer of a fictional material which averages the properhes of the block materml (e g brick) and mortar in the correct proport ion, and a layer thickness At this level, the total resistance can be calculated using a simple one-dimen- sional heat flow model and making several assumptions about heat flow through the cawty This representation can also be used in detailed building therrnal analysis programs using a finite difference or response factor model of conduction, which model thermal storage effects as well as resistance effects

A further, highly specialized representation is obtained for simple heat loss calculations by representing the wall

Product Models and ObJect-Oriented Programmin9 167

More Sulled to ap~lcailorls

Compressed data set

More Imptc~ doma)n knowledge

Conla)ns more assump~ons

Fig 4 An example ofspeclahzatlon applied to a wall, for thermal calculations at different levels of detail

",,, c ~ t " "-._ . . . . J

I J " - ' - - " - .

"-, . . . . . - ' ' • ,:' thermal ": conducUvny

Fig 5 NIAM dmgram showing representation of wall as layers used in thermal simulation

--incorporates zmphctt domain knowledge It incorporates knowledge about the calculation of approximate total wall resistance

--contains more assumptions It assumes the wall has equal area on both faces, flow is one-dimensional and uniform across the wall, and resistance xs independent of Ume.

by total area, a total thermal resistance, and orientation and elevation angles, ignoring differences between inter- nal and external surface areas_

Often, this zs further abstracted by replacing the total resistance wzth a U-value (the reverse of total wall resis- tance plus surface remtances), making assumptions about the internal and external surface remtances, based on the angle of elevation and knowledge about the sste exposure, and only statable for a heat flux model which uses a combined radiation and convection model for internal and external temperatures and ignores solar radi- ation effects. This contains just two numbers, U-value and area,

The second stage of specialization (layers) is illustrated schematmally m the form of a NIAM diagram (the first stage is omitted because it is too complex to show easily) m FLg_ 5, and Fzg. 6 shows the third (total resistance) and fourth (U-value) stages m slmdar form Since this example is only at a conceptual level, ]t could equally have been gwen m the form of OOP classes, m this form, 'A has a B' is eqmvalent to B being a data member of A, while 'A ts a B' is equivalent to A being a descendant of B. Compared to the first level of representaUon, the third level :

- - i s stated to a particular set o f apphcations It Is suited to building heat loss programs, based on conduction loss and possibly including solar gains

--has a compressed data set It contains only four items of data, compared to hun- dreds m the first level ; vertex geometry is reduced to a value for area.

5 1 Sharm O product models The current sttuatlon is that for many apphcatxons, the

reqmred product model is completely specialized to that application, as described in Section 1 There is no possl- bd]ty of shanng data except through manual translation using text and drawings, maximizing suitabihty at the expense of compatlbdlty.

Adoption of a 'global' product model for all appli- cations represents the oppome extreme and would still fall to meet all needs It would introduce an enormous overhead of complexity to speclahst apphcatlons, since translators must be written to get the data into the correct form from the global model, maxlmzzmg compatlbdity at the expense of sultabdlty. Furthermore, at early design

onenlal]on ~ elevation

a r e a I O~ermaJ slanae

Inside out.de msl~lance mslslan~

Fig 6_ NIAM diagram showing representation of two simple types of wall for thermal calculations

168 A J Wrt.qht et al

stages, a global product model will contain insufficient Information even for simple calculations, for example. an application using wall area cannot use a global model until the full geometry has been entered In the global model, but the budding geometry may itself depend on the results from the apphcatlon'

The complexity of systems for exchangmg 2D graphi- cal data using a hmlted range of shapes, which is a very well-defined, closed system, suggests that devlsmg a comprehenswe product model for buddlngs, which are loosely defined and open systems, could lead to insur- mountable problems

Therefore there is a clear need for mtermedlate levels of product model which will support a number of apph- cations, or famtly of applications, with overlapping data requirements These may be called Local Product Models

5 2 Localproduct models A local product model should strike a balance between

suitability for particular applications and compatibility between different applications_ The actual data set for a given application will be partly derived from the shared model and can be viewed as a further specmhzatlon Figure 7 shows some of the possible relatlonshtps between the data sets for three applications

(a) Mutually exclusive

(Ac~B) u ( B n C ) w ( C c ~ A ) = ~ b

(b) Small intersection

(A c~ B) ~ (B c~ C) ~ (C c~ A) = small set

(c) Large Intersection

(A n B) w (B c~ C) ~ (C c~ A) = large set

©c C

Fig 7 Posstble relationship between data sets for &fferent appli- cations, shown as a Venn Diagram

(d) One set contains rest

A u B u C = A

Examples in the field of building simulation are

(a) A = Simple daylight calculation. B = Structural analysis using Finite Elements. C = Simple boiler sizing algorithm Intersection none

(b) A = Simple daylight calculation. B = Annual energy consumption calculation C = Summer overheating calculation Intersection Window areas, skyline angle

(c) A = Internal and external shading analysis B = Detaded thermal simulation C = Plant and control simulation Intersection- Building 3-D geometry and surface properties

(d) A = complete building model for Integrated draught- lng, construction and maintenance software

The problem is to decide how to group applications to share a common product model The following criteria are suggested

1 Apphcatlons share similar conceptual 'views of the world' as a result of being in the same or related domams

2 Applications are related in some way by activity (e g by application area or by stage m design)

3 All applications have some data which can be derived from a common model

4 The posslbihty that other apphcatxons sharmg the local product model may be added at a later stage should be considered

A certam altruism is suggested by the last cr i ter ion-- the posslbdtty that the model may be useful for someone in the future. The boundary drawn around a local prod- uct model is arbitrary, because the system is open ;judge- ment must be exercised to dec~de what is included and there are no absolute rules

5_3 Hlerarchles oJ product models It IS quite hkely that local product models will be

defined in the absence of a global product model (such as a bulldmg product model) intended to serve all apph- cation areas. This may occur because this is easier, or because the global model is incomplete (particularly at early stages of design), or because it is never produced (for example m research work), and for small firms (80% of construction firms in EC countries have fewer than 10 employees [18], and for these it is unhkely to be economic to support a full computer bmldmg model on any job)

Where such a global model does exist, it is likely that some 'local ' product models will not be derived directly from ~t, but will be denved from one or more lnterme&ate product models, each of wluch may support apphcatlons, becoming lncreasmgly speclahzed to a particular appli- cation area Note that a more specmhzed product model may contain domam-speclfiC data, where these are additional to the data derived from the more general model at the next level up

Product Models and Object-Oriented Programmmg 169

0 Producl Model

cl Apphcatlon

Fig. 8 Possible mappings of Product Models to apphcatlons , (a) one product model per apphcatlon, (b) all apphcations share one product model, (c) hierarchy of product models serving

applications

Figure 8 shows the alternative structures.

(a) represents the present situation for most appli- cations, where each program has a unique data set or product model and no data are shared between applications (except through translation),

(b) represents the global product model approach, where

6)

54

a single, all-encompassing product model can serve all applications directly ; represents a hierarchical approach, where specialized product models can be derived from more general ones to serve one or more applications with sub- stantially common data requirements. In describing the hierarchy, some data are left out, while others may be modified to suit the applications (e.g surface areas may be derived from and replace vertex geometry in a speciahzed product model for a cluster of applications which only use surface areas)

Mamtammg consrstency VI local product models Consider a set of apphcations for the early design stage

of a buudmg, shanng a common model for properties of buildmg elements (walls, floors, roofs) Assume all applications need just area values and not vertex geometry, but one designer may want to enter the geometry m vertex form, perhaps from a CAD drawing, from which areas can be calculated ; others may want just to enter areas of elements If both modes are supported without safeguards, then it is likely that mconsistencies will arise between the two descriptions. However, it is essential that mconsistencies are avoided A number of solutions are possible, for example

1. Only allow one form of representation. 2 Only allow one form of representation at any one time. 3. Carry out consistency checks and when a new piece of

data threatens to introduce an Inconsistency, ‘unset’ a piece of related data and recalculate to maintain consistency with the new data

These approaches give rise to a vanety of scenarios, tak- mg as an example the entry of geometric mformation where ultimately only areas are required by the apph- cations

All data must conform to the required repre- sentation-if a vertex geometry IS used, then vertices must be entered (although the form of entry- keyboard, digitizer, mouse/screen, etc -IS irrelevant) A user can choose to work m ‘area mode’ or ‘vertex mode’. For the former he would enter areas directly, for the latter, vertices only. This could only work with simple shapes ; suppose only rectangles were allowed A user could then change any length, breadth or area of a given rectangle, but only by ‘unsettmg’ one of the remammg two variables (chosen by default or selection) For example, if a length L was changed to kL, then either breadth B would be unset and automatically recalculated as B/k, or area A would be unset and automatically recal- culated as kA

Different solutions may be appropnate to different situations Global product models adopt solution 1, this is conceptually simple but highly inflexible and it should be noted that a complete model does not guarantee a conszstent model. Solution 2 IS likely to be suitable m many cases. Solution 3 would be very difficult to implement in a large, complex product model, but is the most flexible and may be appropriate to small product models.

Maintauung consistency is a major problem for any product model The most important aspects for archi- tecture and engineenng are the geometnc and topological relationships This is most easily achieved using a geo- metnc/topolo~cal model which is mtrinsically consist- ent, rather than carrymg out endless consistency checks on a model which permrts inconsistency. No such model has yet emerged for bulldmgs at a useful level of detail

5 5 Composrtion of a local product model The cntena for selection of a local product model,

suggested in Section 5.2, and the need for mamtammg consistency raise the question of which data should be included m the local product model, and which should remam private to the apphcations In many cases, items of data required by different applications will be unique, but may be denved from a common model ; for example, one apphcation may require areas of polygons, while another requires penmeters, both of which can be pro- vided from a vertex or vector representation of polygons. This approach ensures consistency, while stonng areas and perimeters separately does not

Three possibihties are shown in Fig. 9 where the data sets for each apphcation are shown m Venn diagram form, with the data included in the local product model shaded :

170 A J Wrtght et al.

(a)

E

(b)

(c} (ell

Fig 9 Poss,ble options for the composition of a Local Product Model shared between three applications, (a) umon of sets, (b) umon of intersections, (c) intersection of all sets, (d) selection

based on judgement of current and future needs

(a) Union of all application data sets (b) Union of all Intersections of distinct data sets_ (c) Common intersection of all data sets

The problem with (a) is that it will Include many data which are always unique to a given application, such as special parameters which only have meaning for a single application and will result m an unnecessarily large local product model

The second option (b) is preferable to (a), but has the disadvantage of including some highly specialized data which may only have meaning for two very similar apph- cations (perhaps different versions of the same apph- cation), while excluding some very general items which only happen to be used by one application, but might well be used by more later

Finally, (c) is not useful because it will often tend to be small Experience in the COMBINE [3] project of finding the intersection of data sets for four applications relating to daylight and heat loss has shown that only window area and basic geometry (assummg the latter is held m a neutral format and not in the idiosyncratic formats adopted originally in the four applications) are common to all applications, but that many items are common to two or three applications

It may be concluded that a modified form of (b) is the favoured optmn, excluding highly speclahzed parameters and including general parameters, as shown in Fig 9

5 6 Localproduct models andobject orlentedproyrammln 9 Data modelling languages such as EXPRESS are not

designed and not suitable for application programming

As described in Section 2, OOP is conceptually similar to data modelling and therefore it provides a good environ- ment for integrating several applications using a common set of data structures, or classes Objects (representing real-world or other structured entities) must be stored in some form for a permanent record and to exchange objects between applications This is done using an Object-Oriented Data Base (OODB) which replaced the data files of conventional languages

The structure of a local product model m an OOP environment is, then, the corresponding set of class deft- nitlons and the product itself IS represented by a set of objects In an OODB If this were to be used with STEP, a translator would be written to convert classes into EXPRESS format and hence convert the objects into EXPRESS data files and vice-versa The equivalent elements are shown in Fig 3

6. CONCLUSIONS

There is an urgent need to integrate building per- formance evaluation programs, both to allow shared data and to reduce duplication of effort in writing code.

Developments in object-oriented programming and data modelling, notably the ISO STEP Standard, provide some of the tools for greater integration_ There is a close relationship between data modelling and object-onented programming

Product models for buildings exist at different levels of speclahzatlon Currently, most product models in use are highly specialized to particular apphcatlons, preventing Integration However, achieving a general and com- prehensive product model for buildings to satisfy the needs of all specialists seems an Impossible goal, because of the diversity of'world views' which different specialists have and the amount of domain-specific data which can- not practically be held in a shared model Furthermore, performance evaluations are (naturally) most useful dur- ing the early design stages, clearly no comprehensive model can exist at this point

The concept of Local Product Models, intermediate between complete speclahzatnon and complete gener- alization, has been proposed Criteria for deciding when such a model would be appropnate for a group of apph- cations have been given and the options for what data are contained in the Local Product Model are discussed The meaning of a Local Product Model in an object- oriented environment is explained Maintaining con- Slstency is a problem for all product models Different strategies are proposed appropriate to the different type of local product model, which give more flexibility to the user than traditional approaches

Object-Oriented Programming and Data Modelling are both at an early stage of development in terms of use outside research groups They offer promise for the future, but more work is needed This must be both at a commercial level, estabhshmg the practicalities of use on real problems, and at a research level, exploring a diver- slty of approaches to the many unresolved issues

Product Models and Object-Orwnted Programming 171

REFERENCES

1 T J Wdtshlre and A. J Wright, The documentation and evaluation of budding simulation models, BEPAC Technical Note 89/2 (November 1989)

2 J A. Clarke, D. MacRandal, J A Powell and T J Wdtshire, The Energy Kernel System an overview submitted to the Building Sub-Committee m support of five grant proposals, Science and Enganeenng Research Councd, U.K (March 1988)

3 G Augenbroe, Integration of simulation into Budding Design the need for a joint approach, 1990 ASME Int Solar Energy Conference, Miami, Florida (1~1 April 1990)

4 S E Mattsson, Concepts supporting re-use of models, Dept Automatic Control Internal Report, Lund Inst Tech, Sweden (1989)

5 G M Blrtwhlstle et al, SIMULA begin, Van Nostrand, New York (1979) 6 A Goldberg and D Robson, Smalltalk-80 the language and its implementation, Ad&son Wesley,

Reading, Mass 7 B Meyer, ObJect-Oriented Software Construction, Prentice-Hall, U K (1988) 8 A J Wright et al, The use of object-oriented programming techmques m the UK Energy Kernel

System for Bmldmg Simulation, 1990 European Simulation Multwonference, Nuremberg (10-13 June 1990)

9 E F Sowell and W F. Buhl, Dynarmc extension of the simulation problem analysis kernel (SPANK), SImulatwn Research Group, Apphed Science Division, Lawrence Berkeley Lab, University of Call- forma (1988)

10 G Soderhnd, L O Eriksson and A Bring, Numerical methods for the simulation of modular dynamical systems, Royal Inst Tech., Stockholm, Sweden (1988)

11 F Tolman and W Glehngh, Planning model for STEP, ISO TC/184/SC4/WG1 doc N328 (October 1988)

12 W F Glehngh, General AEC Reference Model (GARM), BI-88-150, TNO (October 1988). 13 National Economic Development Council, STEP-2DBS Building Subset An interface for the

exchange of drawing and CAD data m building, NEDC (November 1990) 14 W F Glehngh, Computer integrated construction a major STEP forward, Computer Integrated

Constructwn 1, Wlx McLelland Ltd_ (1990) 15 J A Turner, The conceptual modelhng of a budding Part 1, Computer Integrated Construction 1(1),

Wlx McLelland Ltd (1990) 16 B O_ Bjork, Computer-integrated construction process issues in the development of a budding

product model standard, Bldg Res Pract CIB, No 1 (1990) 17 B Smith, International efforts m product data exchange, Proceedings of the M1CAD86 Conference,

pp_ 745-751, Hermes, Paris (1986). 18 KD Consultants, Defining priorities for R&D m the construction industry, Consultation paper,

Voorburg (February 1991)