Towards a lazy, evolutionary common building model

Building and Environmenr, Vol. 30, No. I, pp. 99-114, 1995 Copynght 0 1994 Ekvier Science Ltd Printed in Great Britain. All rights reserved 036&1323/95 S9.50+0.00

Pergamon 0360-1323(93)EOOlO-B

Towards a Lazy, Evolutionary Building Model

Common

W. B. MUGRIDGE* J. G. HOSKING* A lack of suitable standards for the transfer of building data from application to application has led to the needfor a common building model. Such a model would enable a variety of design tools to access a common repository of building design information and thus avoid redundant data entry and resultant inconsistency. Much research work assumes that the data modelling for a common building model should be completed before systems are built. We instead take an evolutionary approach to developing a common building model, accepting that any such model will need to continue to evolve. It also means that we can begin to address some of the practical issues in providing a common building repository. In addition, it is usually assumed that the repository is (mostly) filled with data before it is used. We instead assume that data in the repository will be accumulated in a lazy fashion; i.e. it is entered by the user (as necessary) in the process of using &sign tools. As a case study, we describe the development of a model of a building that integrates the data needs of two design tools, ThermalDesigner and WallBrace. In integrating the (object-oriented) schemas, various transformations are required to create a common schema. The inverse of each transformation is then defined as a mapping from the common schema to the application schemas. This is in order to minimise the impact on applications due to both the initial integration and the continuing evolution of the common schema. We also consider the dynamic aspects of the integration of applications, beginning with the user interface requirements.

INTRODUCTION

many of the difficult issues are tackled on a smaller scale) [ 141. Second, we assume a model in which the user enters data as an application is executing, with the ability to make changes to consider various design options. This latter model is more complex in that several applications may be executing at once, with the resulting need for consistency of input data and results between them. Augenbroe [7] has characterized the integration of applications according to the “locality” of the applications. The types of system we focus on here are those of Augenbroe’s category 1 : tightly coupled systems which share a common workspace, with an added requirement for consistency to be maintained between applications at all times. In previous work, we have developed a number of software packages to assist building designers to check conformance of their designs against codes of practice [15-l 71. In the process, we have developed a framework for implementing code of practice conformance systems. This uses an object-oriented functional representation (based on the language Kea), coupled with a flexible i/o system based on a forms interface and a generic plan drawing package (PlanEntry) [ 18, 19]. The advantages of our approach are :

CONSIDERABLE

effort has been expended in recent years in the development of software tools to assist in the design and construction of buildings. However, beyond simple drafting, the penetration of such tools into professional practice has been poor [l, 21. One of the principal reasons for this lack of penetration is a lack of suitable standards for transfer of building data from application to application. Thus the cost of entering data multiple times together with the resulting inconsistencies mitigate against designers using multiple tools. Accordingly, one of the most active areas of research in the use of computers in the building industry is the development of a common building model which a variety of design tools can interact with, and which can act as a common repository of building design information. Example projects include ICAtect [3, 41, the BBANZ residential building model [5], the EC COMBINE initiative [6,7], DOE-2 extensions [8], the Intelligent Front End [9], ISOLDE [lo], the work ofVTT [ll, 121 and the ISOSTEP standard for product data interchange [ 131. Much of this work has been based on two assumptions : that data modelling can be completed before systems are built ; and that a repository is completely filled with data before application systems access the data contained within it (a batch approach). We are interested in removing these assumptions. First, we have chosen to take an evolutionary approach to this task (in which

l

l

*Department of Computer Science, University of Auckland, Private Bag 92019, Auckland, New Zealand. 99

An object-oriented structure is well suited to the representation of buildings. A functional style is appropriate for representing code of practice provisions. Although provisions are effectively constraints, their application tends to be as mathematical functions and hence the computational cost

W. B. Mugridge and J. G. Hosking

100

l

of a multi-directional avoided. Automatic consistency interface means that the explicitly handle design though input data never

constraint

approach

can

be

management within the user programmer does not need to changes, and can program as changes.

The aim of this work is to see how our framework influences the task of integration by creating and evolving a common Kea-based building model. In particular, we are interested in the dynamic aspects of a system providing a common model. We present a case study integrating parts of two existing code of practice conformance tools, WallBrace (WB) [16] and ThermalDesigner (TD) [ 191. The integration is based on the object-oriented schema of the two applications. In integrating the two schemas, various transformations are required to create a common schema. The inverse of each transformation that has been applied to an application schema is then defined as a mapping from the common schema to the application schemas. Such mappings are defined to minimise the impact on applications due to both the initial integration and the continuing evolution of the common schema. We also consider the dynamic aspects of the integration of applications that use a common building model, beginning with the user interface requirements. In subsequent work we intend to evolve the resulting model by integrating other applications, using the lessons learnt from this initial integration. Pursuing this research has provided some perspectives that are particular to the architecture of our model while others are more generally applicable. We commence with a description of the conceptual modelling approach we have chosen to use. This is followed by a brief description of the two applications and their associated structures. A discussion of (input) schema integration and its problems is followed by a description of the integrated data model and the associated transformational mappings. This leads to a discussion of the implementation of such mappings in our model. After considering the dynamic aspects of a practical common building model, with emphasis on the user interface requirements, the paper concludes with a discussion of future work.

CONCEPTUAL

MODELLING

based on an object-oriented model have been slow in development [21]. A common approach in database schema integration work, also adopted in the STEP development, is to abstract from particular implementations (e.g. relations) to a more conceptual model prior to integration. Abstraction to an ER model is the most common approach in database schema integration, while NIAM or IDEFlX models augmented by Express behavioural specifications, are used in the STEP work [7, 221. We have adopted a similar approach, although we instead abstract to an object-oriented analysis model of the two systems [23, 241. Typical abstractions in this approach include : l

l

Abstraction from particular implementational mechanisms. For example : from feature references, to conceptual relationships and from container classes to whole-part or associational relationships. Abstraction away from user interface details. For example : ignoring how input is obtained, whether by a menu or by a dialogue box ; ignoring forms of reference, such as referring to a part of a building either by name or by highlighting the part on a diagram; and ignoring navigation between structures (such as between forms).

The representational power of our approach is comparable to that of using NIAM and Express, although the notation is a little different. The adoption of this particular analysis approach was aided by the availability of SPE, a tool to support this form of conceptual modelling. SPE is a visual programming tool and program development environment for object-oriented programming [25]. It permits multiple overlapping views of an application to be developed at varying degrees of abstraction in both textual and graphical forms. Most of the class relationship diagrams incorporated into this paper, such as the one in Fig. 1, were produced using SPE.* Unlike the ER-based approaches, we initially consider integration of only the input data schema. In the Keabased functional representation, any intermediate results and output can be rederived from input data. Hence the structure of the input data determines what needs to be persistent. Identification of shared calculations/derived data was ignored in the initial phase of integration and left as a later refinement.

APPROACH

A number of methodological approaches have been adapted to the development of common building models. For example, Amor’s work on ICAtect and some of the ISO-STEP development have used methods borrowed from the field of database schema integration. In this latter field, a variety of methodologies based on the Entity-Relationship (ER) and Relational models [20] have been developed. Corresponding methodologies

* SPE is implemented using MViews [26], a framework for constructing multiple-view program development environments. An MViews-based tool similar to SPE but supporting NIAM/Express modelling has been developed subsequent to the work described here [27]. t Further detail is provided in [31].

THERMALDESIGNER ThermalDesigner (TD) assists the process of checking that a building design meets the requirements of the New Zealand thermal insulation standard for residential buildings, NZS4218P [28]. It embodies an empirical approach to this process developed by the Building Research Association of New Zealand (BRANZ) and published as a design guide [29]. More complete descriptions Oi‘ThermalDesigner may be found in [19, 301. Two views of the TD conceptual model are given here.? Figure 1 is an overview of the TD object-oriented building model ; it includes the principal classes (rounded rectangular icons) and the major relationships between them (whole-part relationships are shown with solid lines; property relationships are shown with dotted lines). A

101

Evolutionary Common Building Model

Storeys

Spaces

Walls

Floor

I : Ma&ial

fWindow material I Fig.

1,Overview of the ThermalDesigner

building is composed of a number of storeys. A storey, in turn, is composed of a number of spaces, each of which includes a number of floors, roofs and walls, etc. Various materials are shown as properties of the components of a space. Superclass relationships are not shown in this overview; for example, most of the classes inherit positional information from a rectangle class. The various materials (roof, floor, etc.) are all generic, in the sense that they may be shared amongst a number of building components (several walls of the same material for example). Floors, roofs, and walls all have an associated collection of holes. These describe areas of the building component that are absent (e.g. where a window is) or irrelevant to the thermal insulation calculations (e.g. where a wall is shared with another space, and hence is not part of the external envelope). Not shown are a large number of, mostly geometric, constraints between input data values. In TD, these are maintained by the PlanEntry system and include such constraints as : spaces do not overlap other spaces; walls are on the boundary of spaces ; abutting walls in a storey are of the same height where they abut; windows are within walls ; and a window has a corresponding hole in the wall it is within. Figure 2 shows another view of the object-oriented analysis model for TD. This view focuses on the detailed relationships between the building class and its major parts, together with their input attributes (i.e. attribute values that are supplied by the user); it excludes positional and internal part identification attributes. PlanEntry provides a building-storey-space part hierarchy. However, for the thermal calculations, storeys are irrelevant, and a derived building-space part hierarchy

input schema

is constructed. Figure 2 indicates this transformation between the space and storey parts of a building as a conceptual relationship (directed arc) between the space and storey classes.

WALLBRACE The WallBrace (WB) system assists building designers to check that the wall bracing elements of a building satisfy the requirements of Clause 6.3 of NZS 3604 : 1984 Code ofpracticefor light timberframe buildings not requiring specific design. These requirements provide a simplified version of the loadings code, NZS 4203 : 1984 Code of practice for general structural design and design loadings for buildings. The code specifies how to calculate loadings on a building in two orthogonal directions, based on attributes of the building such as the height and type of roof. Earthquake loadings are based roughly on the storey height, the surface area and weight of the roof (categorized as light or heavy), and the earthquake zone of the building. Wind loads are based on the wind exposure zone, the exposed roof and wall surfaces, and take account of the number of storeys, the storey height, and the slope and height of the roof. Once the loadings for the building are known, appropriate bracing elements are allocated to external walls and internal bracing lines. As WallBrace was written prior to the development of the forms and PlanEntry interfaces to Kea, it uses a textbased user interface. Many of the geometric constraints handled by PlanEntry in TD, had to be handled explicitly

102

W. B. Mugridge

and J. G. Hosking

Spaces

name ’

Floor

Roof

Fig. 2. Building

Walls

class, its relationships,

in WallBrace by appropriate questioning. A description of the WallBrace application may be found in [ 16, 321. Figure 3 shows the major class structures of WallBrace relevant to data input.* As with the TD overview of Fig. 1, a large number of subclasses and components have been omitted for simplicity. The WB dialogue is structured around entering data about uniform vertical slices through the building, called sections, rather than around storeys/levels. It is easier for the user to provide information about sections in a textual dialogue, with the system constructing a level view from the sections, than the reverse (both types of view are needed in the wall bracing calculations). Conversely, with a PlanEntry-type graphical drawing approach to data entry it is simpler to enter information on a level by level basis and use these to construct the sectional views. Thus WallBrace will require modification to be consistent with a PlanEntry approach to data entry. SCHEMA

INTEGRATION

The aim of schema integration is to pare back the union of the models to elementary data (and structure) that cannot be derived from other data (and structure). This is akin to the process of relational database normalization. In the process of integrating the input schemas of the two applications, it was necessary to abstract from them further and to clarify their different. perspectives with regard to the structure and components of buildings. For example, the notion of space in TD does not relate easily to the structures used within WB. Partial constraints between the input requirements of the applications were * Further detail is provided in [3l]

and inputs.

the most difficult aspects to handle. For example, the two applications have very different views of walls and where they are placed within the structure.

Method of integration Batini et al. [20], in the context

of database schema integration, provide a categorization of structural and semantic differences between schemas which we found useful during integration (as Amor et al. [l] also found). They argue that, in order to perform integration, it is “crucial to single out not only the set of common concepts but also the set of different concepts in different schemas related by some semantic properties”. The latter they call

interschema properties. The similarities and differences between the two application schemas were identified in a systematic manner based on the approach of Batini et al. These were then used in abstracting the design of an integrated schema and also the design of the conceptual mappings between the components of the integrated schema and the application schemas. Some of the categories of differences that Batini et al. describe, together with examples from our integration work, are as follows. l

l

Identical perspectives: Design tools or users have exactIy the same viewpoints in modelling the same concepts. This extends to the actual representation, the modelling constructs used and also to having the same perception of the concept. In our case, this only occurs in an elementary form at the simple data level, such as the owner name of a building. Different, but equivalent perspectives : Design tools or users have different viewpoints in modelling the same objects. However, the perceptions are still the same and are coherent. A simple example is where different

Evolutionary

rEnvironmsnt)

wb Bracing

103

Building Model

Brac~-YJyEG-~sectio*s

53 wb Bracing

Across

Common

level

wb Section

Along

direction

pxz&xzGy 77 storeys

F

wb Store

Walls wb Bracin

t;hi Walls

The roof

line

on bracing line

T

r

Braci;;?]

Fig. 3. Major class structures of WallBrace related to data input.

l

l

names are given to the same attribute. This category is broken into three distinct views of what equivalence means : l Behavioural : representations are equivalent if for one representation there is a corresponding alternative representation that has the same set of answers to any given query. This did not occur in our work. 0 One-to-one mapping : representations are equivalent if instances can be put in a 1-l correspondence. For example tools which require input in Imperial units as opposed to those which require input in SI units. For example, this occurs in the use of orientation in TD and direction in WB. l Transformational : representations are equivalent if they can be obtained by applying a set of atomic transformations. For example, WB organizes a building by slices (as discussed above) ; while this is very different from the storey-based organization of TD, there is a straightforward mapping between them. Compatible specifications : Several combinations of attributes can model the same object. Though they will be neither identical nor equivalent, the attributes, perceptions, and integrity constraints are not contradictory. For example, WB models the bracing qualities of a wall while TD models the thermal capacity of the materials of the wall. Incompatible specifications : Unresolvable conflicts regarding names, types and integrity constraints that give rise to incompatibilities in their present form. There is a hope that this case will rarely be observed as practitioners have developed views at least partially compatible with other practitioners as they have col-

laborated on building minor incompatibilities ignored for this work.

projects over the years. Some between WB and TD were

The handling of compatible specifications arose in the integration of the notions of spaces, holes and walls. Three different techniques were used to resolve the differences : l l

l

Use the more specific notion, as with spaces. Eliminate redundant data, as with holes, once more specific wall geometry is added to the model. Introduce partially-overlapping views of the same structure, as with walls.

The notion of space in WB is rather more specific than in TD and hence is the one that needs to be used in an integrated model. For WB, the space helps define a sectional slice (in which the weight and slope of the roof are important determinants). Given that TD may cut a storey up into fewer spaces than WB, allowance must be made for this for TD. The notion of hole in TD is not an elementary data item once the geometric information about all walls is included in the integrated model. Hence this notion is eliminated in the interests of normalisation, even though it must be reintroduced for TD. The notion of a wall is rather different in TD and WB, making it difficult to integrate them. Several wall segments, with different wall materials, may make up an external wall, as shown in Fig. 4. Only external walls and their materials (with respect to thermal properties) are

W. B. Mugridge and J. G. Hosking

104

-e--e-

I

Plan View of a storey

Fig. 4. Different views of a wall.

relevant to TD, while WB is concerned with all walls and their bracing elements. The approach used with spaces is inadequate for walls, because neither view is a subset of the other. There are two approaches possible : break the wall structure down so that the basic elements are compatible with both views ; or provide two views in the integrated model. A major problem with the first approach is that a bracing element may cross the boundary between interior and exterior walls. Hence it would need to be treated as two separate components, to be “welded” together again for WB. The second approach was taken ; it accepts that complete integration is not possible in a common model, but it requires a mechanism to ensure that the two views are kept consistent. For each of the above categories in Batini et al., there is a corresponding approach to producing the integrated schema component. In addition, there are corresponding mappings (transformations) of part of the common schema to (and from) part of each application schema. In the next section, we describe the common schema, after which these interschema mappings are examined in more detail. The common schema Figure 5 shows an overview of the integrated common input model.* The structure is rather closer to that of ThermalDesigner than that of WallBrace as the building model used in TD is a little more general than the application-specific one used in WB. The classes wall (with an emphasis on bracing for WB) and wallsegment (with an emphasis on external walls for TD) provide two views that contain related input attributes. Various constraints are maintained between the views (not shown in the figure). The wall class is provided for WallBrace, in which a contiguous wall consists of internal and external pieces, with windows, doors and bracing elements distributed along the wall. It will be up to WallBrace to ensure that bracing elements have not been placed incorrectly over windows in an integrated system. However, it is up to the PlanEntry component to * Further detail is provided

in [31].

ensure that the materials (from a TD view) are consistent with the bracing elements (from a WB view). A later section discusses the issues that arise from the generalisation of PlanEntry to handle such constraints. As well as having different internal structure, walls and wallsegments are placed in different parts of the schema structure. ThermalDesigner is interested in the external walls of spaces while WallBrace is interested in the walls of a storey as a whole, without regard to spaces. An important part of the mapping of the common schema to the two applications is the selection of the appropriate information. Similar conflicts of view occur with regard to ceilings and roofs, and require a similar solution. ThermalDesigner is interested in the thermal properties of the roof/ceiling combination, and hence only certain material properties are relevant. WallBrace is interested in two separate aspects, the weight and slope of the roof (in affecting the horizontal loads on the building) and the structural properties of a ceiling (when acting as a diaphragm) which arise from its materials and its slope. As with walls, two separate views are provided within the integrated schema, with the underlying PlanEntry being responsible for maintaining constraints between them. For example, if the weight of a roof is known (for WallBrace) then there are constraints placed on the materials that could be used in its construction and hence on the thermal properties of the roof and ceiling. The WB notion of space is used in the common model. This is simple to handle in TD, even though a storey may consist of more of the specialized spaces, because TD can work with these without change. The use of holes to represent shared (internal) segments of a wall in ThermalDesign is replaced by an appropriate collection of wallSegments. A similar mechanism is used for roofs and floors. The “hole” in a wallsegment for a window can be derived directly from the window itself.

MAPPING

TO THE

APPLICATION

SCHEMA

There are three important issues with respect to the mappings between the common building model and the applications : How much to change the operational structure of each application as opposed to providing mappings from the common model to the existing structure? . How best to represent the transformational mappings between the common data model and the data models for each of the applications? With our object-oriented framework, it is an open issue as to where the transformational mappings should be “attached”. . How best to permit the evolution of the common data model while minimizing the impact on applications that are using the old model.

l

Mapping to the ThermalDesigner model Each application requires a mapping of the common model to its own preferred representation. Some of the structural mappings needed for ThermalDesigner are shown graphically in Fig. 6. There we see those elements of the common model that (more or less) directly cor-

105

Evolutionary Common Building Model

Environment

c Storeys

Bracing

Walls

(Ceiling material)

Fig. 5. Overview

of the common

respond to elements required for ThermalDesigner (e.g. floor and roof), or require structural mapping (e.g. building, space) into a ThermalDesigner element (tdBuilding, tdSpace).* The structural mappings required in this case are not particularly complicated, involving the transformation of the building-storey-space hierarchy into a tdBuilding-tdSpace one. The bold arrows can be conceptually thought of as specialization relationships, although they may be implemented by the copying of attributes from the common model. This point will be addressed later. Another function of the structural mapping is the reintroduction of classes not included in the common schema, but which can be functionally derived from it. For example, holes, representing window gaps, are required for TD. In addition to the structural mapping illustrated in Fig. 6, there is much fine scale l-l mapping required, particularly for renaming of attributes. A number of possible mechanisms for implementing the structural and fine scale mapping are described in the next section, along with those for mapping the actual application “code” to the application “view”.

*Class attributes arc also shown these are not discussed further.

in Fig. 6 and later figures

;

building

model.

Mapping to the WallBrace model As previously indicated, WallBrace effectively required two different views of a building: a vertical slice (or section) view for calculating loadings and a level view for calculating bracing requirements. Each of these views requires a different structural transformation from the common building model. Figure 7 shows the resulting section-based model, and Fig. 8 the storey-based model. Once again, fine scale mappings have been omitted and the bold arrows correspond to a conceptual specialization. However, the mappings required in this case are somewhat more complex. In particular, constructing the sections of wbBuilding from the building class involves a complicated traversal of the building-storey-space hierarchy.

IMPLEMENTATION

OF

MAPPINGS

There are a number of ways to represent the mappings from the common schema to the schema of the two applications. These vary according to : where the various varieties of mapping code are placed (i.e. the classes they are attached to), where the application-specific code is placed, and the mechanisms used for copying information out of the common model.

106

W. B. Mugridge and J. G. Hosking

infiltration_zone

I f

Wall segment’ coloar orientation

wh

Wkt do Widow c3

Fig. 6. Overview

of ThermalDesigner

a Mappings and the views are defined in the common schema. That is, views are functionally derived from a common database, as in relational database views. l Mappings are defined in independent views ; they copy input data by a traversal of the common schema, creating a separate object structure for the view. An application may then have to copy further to place it into a suitable class structure with the code attached for calculations, output, etc. l Mappings are defined in the applications ; they copy input data from a traversal of the common schema, creating a separate object structure for their own purpose. That is, views are data copied directly into an application object structure. In looking at these options, it is worth noting that there are two sorts of mapping that require implementation. The first type is structural mapping, which creates the inter-object relationships for the application from the inter-object relationships for the common model. The second is the fine scale mapping of attributes to attributes. The latter includes direct correspondence, where the attribute in the common schema is the same as that in the application, and the “different but equivalent”

mapping.

mappings of [20] that require the application attribute to be derived in a simple way from common schema attributes. We explored two methods of solving the structural mapping problem, one based on object copying, and one based on object extension.

Object copying method The object copying method requires that the views are defined in the application schemas. Figure 9 shows graphically the object copying method, as applied to part of the ThermalDesigner mapping. The conceptual specializations of the conceptual structural mapping of Fig. 6 have been replaced by whole-part (aggregate) links. Thus, for example, a tdSpace object makes direct reference (via feature commonBuilding) to a space object of the common schema. It uses this reference to perform both structural and fine scale mapping. The fine scale mapping involves copying attribute information from the space object into the tdSpace object, and providing functions which derive additional tdSpace attributes from the space attributes. Structural mapping in this method is illustrated by

Evolutionary

Common Building Model

107

along slope average height across average height along average slope height position

Fig. 7. WallBrace

the construction of the spaces (collection) feature of tdBuilding. This involves selecting all of the spaces of all of the storeys of the building object (via the commonBuilding feature), constructing a corresponding collection of tdSpace objects, and passing one space object as a creation parameter to each of the new tdSpace objects. To use the structure-copying approach, the attributes of the common object must be visible (i.e. there is no encapsulation). The main advantage of this approach is that the common model does not need to include details of the mapping to the applications and hence does not include any application-specific information. The main disadvantage is that a copy must be made of everything that is needed, even unaltered attributes. A new structure is created that uses objects of classes belonging to the application (such as the mapping from objects of the common class space to the application-specific class tdspace). As different structural mappings are defined for each of the views, multiple copies are generated.

Object extension method The object extension method avoids copying by extending the class of objects of the common model at runtime to incorporate corresponding application classes, and thus permitting inheritance of common model attributes into the application classes. This

mapping

for loadings.

approach makes use of Kea’s unique dynamic classification mechanism [33]. Kea classes may include classifiers. These are parameterless functions which return the name of a subclass. When evaluated, the classifier causes the class membership of the object to be extended to include the class returned by the classifier. Classifiers thus provide a controlled way of dynamically changing the class membership of an object. Classification may introduce new features for the class and new bodies to override existing methods. Multiple classifiers permit multiple extensions of class membership, thus constructing “union classes” on the fly. Classifiers can thus provide a direct implementation of the conceptual specializations introduced when describing the conceptual mappings between the common schema and the application schema. For example, the mapping for TD of building-storeyspace information is shown in Fig. 10. The classes building and space are mapped into the corresponding application-specific classes tdBuilding and tdSpacc by classifiers that are defined in the common model classes. This means that minimal information about the applications is contained within the common model, yet the application classes inherit directly from the common model classes whenever there is a one-to-one correspondence. For example, the class tdSpace inherits the height and posi-

W, B. Mugridge and J. G. Hosking

108

Spaces

Roof Roof

height

@

length

Bracing linj

position

p

Ceiling

bracing type length i

/

Fig. 8. WallBrace mapping for bracing.

tion attributes of spaces and uses them in the calculation of derived values that are specific to TD and hence are defined within the class tdSpace. In addition to avoiding copying, the object extension method has another advantage over the object-copying method. It permits data that is derived in one application (A) to be written into the common data repository for another application (B) to access. In the object-copying model, it would be necessary for application B to know something of the structure of the data of application A, thus creating an unfortunate coupling between the applications. DYNAMIC

ASPECTS AND THE USER INTERFACE

The discussion so far has concentrated on the common building model and the mapping of that model to the applications. The remaining major issues are : how and when is data entered into the common model, how is

information displayed to the user, and how are constraints handled within a plan entry system? We take a lazy approach to data entry, by providing for consistency management between running applications while avoiding any explicit notion of interaction within the applications. ThermalDesigner was built with Kea, an objectoriented functional language with a flexible i/o system based on a forms interface and a generic plan drawing package. Figure 11 shows an example screen dump from the execution of ThermalDesigner. Shown there are an XWindow based plan drawing window, used for entering basic geometric information, and an example form. Forms are used for entering non-geometric data about the building as a whole and displaying results to the user. A form usually corresponds to an object within TD, with input fields on the form corresponding to attributes of the object. Buttons are used to control the display of forms, allowing the user to direct the entry of data and the provision of results. An important feature of the

Evolutionary Common Building Model

109

f td Building 1

Common building

Storeys

spa ces

Fig. 9. Object copying method.

framework is that the effects of changes to a building design are propagated automatically through the application, ensuring any results supplied to the user are kept consistent with the current state of the plan. Forms-based data entry for the common model We assume that a model editor (constructed from the plan entry and forms systems) will be used to build the objects of the common building model and provide values for the attributes of those objects. In addition, we assume that data entry is carried out at the time that applications are executing, so that the user may direct the data entry depending on the results that are required. This is a natural generalization of previous work on Kea applications built with the plan entry and forms systems. However, this aproach requires that the input requirements of the combined applications be integrated in some manner. A forms interface for the common model could be created by extending the forms of the current TD. Input fields would be added to each existing TD form where the underlying class of the common model has new attributes due to WB’s requirements. Then new forms would be designed for common model classes that are due only to WB. However, this approach has several disadvantages : l

A user who is only interested in one application would be hindered by the additional input fields on a form that is required for the other application. The user

l

l

l

could feel compelled to enter data for all applications even if the results from only one application are needed. The approach does not scale well beyond two applications, leading to large forms containing many fields. Each form would request a confusing amount of data. Much work would be required to integrate the forms and redesign the user interface for any additional applications that use the common model. Different types of user require different views [34], leading to the design of many different (integrated) forms.

Another approach is to keep the forms of each application separated, so that the user can concentrate on the needs of one application at a time. This allows input views to be tailored to each application. However, once the data for one application has been entered, reentry must be avoided. The most likely solution to the latter is to utilize an underlying mechanism that ensures consistency between shared inputs. Where data appears in the forms of both applications, a change to the field of one form will lead to a change in the corresponding form of the other application (if and when it is displayed). Thus shared inputs are bidirectionally constrained and are linked to a single Kea input in the common building model. Where there are partial constraints between the inputs, the underlying system must check these and inform the user of problems as they arise. The data for the different applications may thus be entered in either order, as required by the user, and

W. B. Mugridge

110

and J. G. Hosking

Environment

exposure_class

mass-type

infiltration_zone

name nam_of_occupants

building-name

height position

Walls

f3

Wall segment colour

1

orientation

1

Fig. 10. Object extension method.

changed at any time in a consistent manner. An obvious approach to the management of the multi-way consistency required is to use the multi-view ideas of the MViews framework* [25], as these ideas go beyond the purely functional dependency management of Kea (i.e. unidirectional constraints). The MViews framework provides a “blackboard” style communication/consistency system, with the integrated model being the “base view”. This is the approach being taken by [34]. The authors are also participating in a separate project to develop a constraint-based user interface system, which in the longer term is planned to replace the existing Kea forms system.

Output of results from applications The TD application currently combines input, output and control on forms. With an integrated model, there are several approaches. The first is to separate out the output into distinct forms that are created and displayed by the applications themselves. However, this leads to an awkward separation for the user. The second approach is *As mentioned earlier, the SPE visual programming tool used in constructing the graphical 00 models for this project is derived from MViews. t This idea of a “glue” language for combining forms was explored in earlier work ; this in turn led to the design of a lowlevel interactive graphics interface to Kea.

to incorporate

the application outputs into the common building model so that they may be displayed on forms as in the current TD. Thus outputs are treated in the same manner as intermediate values being passed between applications. A third, more complex approach is to define the common model forms for inputs separately from the output forms of the applications and then define in some “glue” language a means of combining the forms on display to the user.t

PlanEntry PlanEntry provides much of the input for TD and needs to be extended to incorporate the plan entry requirements of WB (such as internal walls, roof details, bracing elements and bracing lines), and other applications to be added later. These will, in turn, affect data entry for TD. For example, a bracing element may be placed in a wall after the materials of that wall have already been defined for TD (with an emphasis on their thermal properties). This will partially constrain the type of bracing elements that may be placed there. As data entry may occur in either order, PlanEntry must check for and handle the possible conflicts that may arise. As with forms data entry, PlanEntry must inform the user of unsatisfied partial constraints as they arise (or prevent them from being violated).

111

Evolutionary Common Building Model

gij Poinru 3 spa*

X:

Y:

3 Window

width: hci$s:

Building name My Hous Number of occupants III Effective Thermal Mass level 1 Timber - Plasterboard Iinterior brick wall1 - Plasterboard

1

Click appropriate button to proceed. _I(1

-1

Click on a button to generate a report. FIllI 0 Ezl Click on a button to see the summary figures.

-1 BPI:

fyixz-1 (

0.000

Fig. 11. Screen dump from ThermalDesigner execution.

Hence the integration of applications into a common building model will inevitably lead to extensions to the plan entry system. As this system is currently written in procedural code (C) and is very large, considerable expense is likely in making such extensions. As with the forms system, there are several major alternatives to a procedural approach : a functional approach (using Kea), a multi-view approach (using MViews), and a constraint-based approach. Most of the plan entry constraints can be described in a functional/one-way dependency manner. For example, the wall positions are dependent on positions of the spaces of the building, so that shifting a space shifts its walls. The authors have done some preliminary work towards extending the i/o model of Kea to provide lowlevel graphics capabilities with such functional dependencies being programmed in Kea code, and with the Kea consistency manager responsible for keeping the dependencies consistent. This work is similar in nature to the one-way dependencies of the Garnet user interface [35, 361. However, this approach is limited by the restriction that any data can only be defined by the user in one

place. For example, it is not possible with this approach to permit the user to place a window in a side view of a wall and then later move the window along the wall in a plan view of the building. MViews provides a software architecture for building multi-view graphical systems and for handling the propagation of a change in a view to those views that are affected by the change. This framework is well suited to the development of PlanEntry, in which geometric and other constraints are procedurally coded. Because of the benefits of the architecture, a plan entry system based on MViews would be much easier to extend than with the current C-based system. A third approach, that we are currently investigating, is to utilize a high-level language with explicit constraints. This will make the plan entry system easier to extend than the previous approaches. However, as general constraint-solving systems tend to be extremely slow, it will be interesting to determine whether the constraints that are needed for plan entry are sufficiently limited that a constraint-based approach is feasible.

112

W. B. Mugridge and J. G. Hosking

Model Editor- Generalised PlanEntry + Forms

WallBrace Specific Kea Model

WallBrace. Specific Data Display

ThermalDesi ner Specific Data B Isplay

Fig. 12. Model of the first integrated

CONCLUSIONS The first step in the evolutionary development of a common building model has been carried out, based on the integration of two code-of-practice applications (ThermalDesigner and WallBrace). A model of the integrated system is shown in Fig. 12. This work has focussed on the development of an object-oriented common model, and the issues involved in the mapping of that common model to the input models of the two applications. We have identified the object extension approach to mapping as being the most satisfactory, as it handles intermediate results between applications and avoids unnecessary copying. This work has prompted us to investigate further the types of mapping that occur in schema integration work for common building models. As a result, Amor [37] is undertaking a comprehensive study of the varieties of mapping that occur, together with techniques for implementing those mappings, and

system.

based on a wider sample of applications. While we expect that our approach will generalize beyond the context of Kea-based systems, further work is needed before this will become clear. As we are attempting to integrate highly interactive systems, a number of issues have been raised that have received little or no attention in the past. This work has shown that, no matter which approach to mapping is used, significant modifications are required to the existing applications. The code for input attributes and their definition is removed, as is the code for constructing the inter-object relationships (particularly the whole-part ones). As this code is likely to have been mixed in with the application code, considerable effort may be required to perform the decomposition. The functional approach to the generation of structure in Kea means that this decomposition is less likely to be a problem than for procedure-based 00 languages. The incorporation of new applications will, however,

Evolutionary Common Building Model be rather different from integrating existing applications. This is because the applications can be developed within the framework of the common model, ensuring consistency from the outset. When developing a new application, the first step will be to complete an object-oriented analysis of the input data requirements of the application. Then, the common building model must be extended to incorporate any additional requirements and to resolve conflicts between the new application and the ones that are already integrated into the old model. Of course, the new application will still need to be protected, as much as possible, from the affects of future changes to the common building model as it evolves. We have assumed that data in the repository will be accumulated in a lazy fashion ; i.e. it is entered by the user, as necessary, in the process of using design tools. This leads to a number of issues in the implicit interaction of applications and the management of consistency between their inputs. We have begun to explore the extension of forms and plan entry that permit such design

tools to be integrated while minimizing the impact on the implementation of the tools. In particular, we have focussed on the need for constraint management of data that is entered and changed both within the forms and plan entry systems. Two approaches are being explored for solving these multi-way constraint problems in plan entry, in an attempt to reduce the effort involved in extending the plan entry system as the common building model grows to incorporate a larger range of design tools. A future issue is the reuse of code between applications, possibly leading to a migration of shared data/behaviour into the common schema. For example, various geometric analyses may be used by several applications. This is a straightforward extension using a similar approach to the shared attributes. AcknowledgementsThis

work was funded by the Building Research Association of New Zealand, who in turn were funded by the Public Good Science Fund for the New Zealand Foundation for Research Science and Technology. The authors are grateful for the financial support of both bodies.

REFERENCES 1. 2. 3.

4.

9. 10. 11.

12.

13. 14. 15. 16.

17. 18.

19.

20. 21.

113

R. A. Amor, J. G. Hosking and M. R. Donn. Integrating design tools for toal bulding evaluation, Building and Environment 28,473482 (1993). C. Price, Building Research Association of New Zealand, Private Communication (1990). R. A. Amor, L. Groves and M. R. Donn, Integrating Design Tools : An Object-Oriented Approach, Proc. Building Systems Automation-Integration, First International Symposium, June 2-8, University of Wisconsin, Madison, Wisconsin, U.S.A. (1990). R. A. Amor, ICAtect : Integrating Design Tools for Preliminary Architectural Design, MSc thesis, Department of Computer Science, Victoria University of Wellington, Wellington, New Zealand (1990). C. Price, A building data model for integration, BRANZ study report, Building Research Association of New Zealand, Judgeford, New Zealand (1992). G. Augenbroe, COMBINE ; A joint European project towards integrated building design systems, Proc. Building Systems Automation-Integration ‘92, pp. 10-12, Dallas, Texas (1992). G. Augenbroe, Integrated building performance evaluation in the early design stages. Building and Environment 27, 1499161 (1992). W. L. Carroll, S. E. Selkowitz and F. C. Winkelmann, The Energy Design Advisor: A New Desktop Design Tool based on DOE-2, A white paper for discussion and comment, Lawrence Berkeley Laboratory, U.S.A. (1991). J. A. Clarke, J. H. Rutherford and D. MacRandal, An intelligent front-end for computer-aided building design, University of Strathclyde, Scotland (1989). S. R. Hastings, Passive solar energy use in commercial and institutional buildings, in Annual Report IEA Solar Heating and Cooling Programme (1991). B.-C. Bjork and H. Pentilla, A scenario for the development and implementation of a building product model standard, Current Research and Development of Integrated Design Construction and Facility Management, CIFE, Stanford CA, 28-29 March (1989). K. Kahkiinen, B.-C. Bjiirk and P. Huovila, The use of conceptual data modelling as a basis for regulations software development, VTT Symposium I2S, Computers and Building Regulations, VTT, Espoo, Finland, pp. 161-170 (1991). STEP, Standard for the exchange of product model data, proposed as IS0 10303, TC184/SC4 (1992). T. Gilb, Principles of Software Engineering Management, Addison-Wesley, Reading, MA (1988). J. G. Hosking, W. B. Mugridge and M. Buis, FireCode: a case study in the application of expert systems techniques to a design code. Environment Planning and Design B 14, 267-280 (1987). W. B. Mugridge and J. G. Hosking, The development of an expert system for wall bracing design. Proc. NZES’M The Third New Zealand Expert Systems Conference, pp. l&27, Wellington, New Zealand (1988). J. G. Hosking, S. Lomas, W. B. Mugridge and A. J. Cranston, The develoment of an expert system for seismic loading. Civil Engineering Systems 6(l-2), 27735 (1989). J. G. Hosking, W. B. Mugridge and J. Hamer, An architecture for code of practice conformance systems, in Kahkdnen ands Bjork (eds). Computers and Building Regulations, VTT Symposium 125, VTT Espoo, Finland, pp. 171-180 (1991). R. A. Amor, J. G. Hosking, W. B. Mugridge, J. Hamer and M. Williams, ThermalDesigner: an application of an object-oriented code conformance architecture. Proceedings CZB Joint International Workshops on Computer Integrated Construction and Computers and Building Standards, Montreal, Canada (1992). C. Batini, M. Lenzerini and S. B. Navathe, A comparative analysis of methodologies for database schema integration. ACM Computing Surveys 18, 323-364 (1986). W. Gotthard, P. C. Lockemann and A. Neufeld, System-guided view integration for object-oriented databases. IEEE Trans. Knowledge and Data Engineering 4, l-22 (1992).

114

W. B. Mugridge and J. G. Hosking 22. 23. 24. 25. 26.

27. 28. 29.

30. 31. 32.

33.

34.

35. 36.

37.

J. A. Turner, Conceptual modelling applied to computer-aided architectural design. Building and Environment 21, 125-133 (1992). P. Coad and E. Yourdon, Object-Oriented Analysis. Prentice-Hall, Englewood Cliffs, NJ (1991). J. Rumbaugh, M. Blaha, W. Premerlani, F. Eddy and W. Lorenson, Object-Oriented Modeling and Design. Prentice-Hall, Englewood Cliffs, NJ (1991). J. C. Grundy and J. G. Hosking, Integrated software development in SPE, Proc. 13th New Zealand Computer Society Conference, New Zealand Computer Society, Wellington, New Zealand (1993). J. C. Grundy and J. G. Hosking, Mviews, A framework for developing visual programming environments, Technology of Object-Oriented Languages and Systems TOOLS 9 Proc. of the 9th International Conference Sydney, pp. 1299137, Prentice-Hall, Englewood Cliffs, NJ (1992). R. A. Amor, J. G. Hosking, J. Grundy, G. Augenbroe and W. Rombouts, Directions in modelling environments, Working Paper TU Delft, Department of Civil Engineering (1993). SANZ, NZS4218P 1977 : Minimum Thermal Insulation Requirements for Residential Buildings, a New Zealand Standard, Standards Association of New Zealand, Wellington, New Zealand (1977). M. R. Bassett, R. C. Bishop and I. S. van der Werff, ALF MANUAL, Annual Loss Factor Design Manual, An aid to thermal design of buildings, Building Research Association of New Zealand, Judgeford, New Zealand (1990). R. A. Amor, ThermalDesigner, BRANZ contract No. 85-024, Technical Report No. 24, Department of Computer Science, Auckland University, Auckland, New Zealand (1991). W. B. Mugridge and J. G. Hosking, Object-oriented schema integration for a common building model, Auckland Uniservices Ltd, Auckland, New Zealand (1993). W. B. Mugridge and J. G. Hosking, An Expert Advistory System for Wall Bracing Design, Final Report for BRANZ Contract No. 8&85-009. Department of Computer Science, University of Auckland, Auckland, New Zealand (1989). J. Hamer, J. G. Hosking and W. B. Mugridge, Static subclass constraints and dynamic class membership using classifiers, Auckland Computer Science Report No. 62, Department of Computer Science, University of Auckland, Auckland, New Zealand (1992). R. A. Amor, R. A. and J. G. Hosking, Defining multi-disciplinary views of a computer model of buildings, Proc. 1st New Zealand Computer Science Research Students’ Conference, Waikato University, Hamilton, New Zealand (1992). B. A. Myers, A new model for handling input. ACM Transactions on Information Systems 8, no. 3 (1990). B. A. Myers, D. A. Giuse and B. Vander Zanden, Declarative programming in a prototype-instance systems : object-oriented programming without writing methods. Procs. OOPSLA’92, pp. 184200 (1992). R. A. Amor, priv. comm., University of Auckland, Auckland, New Zealand (1993).