Computer-Aided Civil and Infrastructure Engineering 17 (2002) 464–472

SHORT CONTRIBUTION

Integrated AEC Information Services Using ObjectMethods and a Central Project Model

Rafael Sacks∗

Department of Construction Engineering and Management, Faculty of Civil Engineering,Technion–Israel Institute of Technology, Haifa 32000, Israel

Abstract: A new paradigm is presented in which design-ers, contractors, and suppliers process project informa-tion, which is stored in a central project model, by usingapplication routines provided on-line as object-orientedmethods instead of stand-alone applications. Commer-cial project management Web site companies can providethe service through application methods tightly coupledwith a project model. The development and use of such“intelligent” object sets is exemplified by the use of intel-ligent parametric templates (IPT) in three sample appli-cations: for RC slab design, formwork design, and labormonitoring. The research requirements relating to the pro-posed paradigm are discussed, in light of the experiencegained in development of the IPTs. The paradigm offersa technical and economic alternative to the developmentof industry-wide building project models.

1 INTRODUCTION

The process of building construction has been aptlydescribed as consisting of two highly integratedsubprocesses—an Information process and a materialprocess (Bjork, 1999). A significant proportion of theproblems that occur in physical construction activitiescan be traced back to failings in the information process.For example, information-related problems have beenfound to cause significant construction delays in 75% ofprojects (surveyed in a number of countries) (Ogunlanaet al., 1995).

One of the reasons most commonly cited for thisstate of affairs is the fragmentation of the building de-sign and construction industry (Tolman, 1999; Alshawi,2000). This problem is especially acute because almost

∗ E-mail: cvsacks@tx.technion.ac.il.

every project is prototypical—it must be designed fromscratch, with the attendant production of a mass of newinformation (Mokhtar et al., 1997). Information technol-ogy (IT) is seen as holding the potential to radically im-prove the information process, by enabling collaborationand integration in both design and construction. Concep-tually, what is desired are information repositories andnetworks that could simulate in-house colocation of allproject participants. Much has been researched and writ-ten to show that colocation and concentrated large-scaleinvestments in information technology are not possiblein construction, and a plethora of ways have been devel-oped in order to cope with the “distribution” problem(Bjork, 1999).

The key thrust of research in pursuit of this goalhas been the development of building project model-ing (BPM) concepts. Galle (1995) defined ten desir-able properties of computer-building modeling systems,grouped as issues of integration, “intelligence,” and com-pliance. While a wide range of technological approacheshas been researched, no clear consensus has yet emergedon many basic issues. Among these are the following:

� How to resolve the need to provide versatility (theability to add new building technologies, sometimesad hoc) with the need for industry-wide standardiza-tion of building project models (Galle, 1995; Tolman,1999).

� The architecture of the databases. Centralized datamodels, distributed data models, hybrids of these, datatransfer models (neutral file formats), and others havebeen investigated (Gielingh, 1988; Eastman, 1992;Teicholz and Fischer, 1994).

� Providing for concurrent design collaboration while atthe same time ensuring semantic integrity of the data(Eastman and Kutay, 1991; Galle, 1995). Q2

C© 2002 Computer-Aided Civil and Infrastructure Engineering. Published by Blackwell Publishing, 350 Main Street, Malden, MA 02148, USA,and 108 Cowley Road, Oxford OX4 1JF, UK.

Integrated AEC Information Services Using Object Methods and a Central Project Model 465

� The degree of coupling between software packagesand the project model database (Fenves et al., 1990).

� The possibility (and desirability) of incorporationof “intelligent” or “creative” systems with “learn-ing” capabilities, both within application modules(Flemming, 1994; Sacks and Warszawski, 1997) andwithin the data model itself (for preserving integrity).

Two major efforts at standardization have been pur-sued: STEP (ISO 10303), starting with the AEC buildingsystems model (Turner, 1988) and continuing with build-ing construction core model (BCCM; Tolman and Wix,1996); and more recently the industry foundation classes(IFC) development within the industry alliance for inter-operability (IAI; Liebich and Wix, 1999). These assumeno coupling with software applications and no “intelli-gence,” they provide limited integrity constraints, andthey are likely to suffer from lack of versatility due tothe need to update versions in incremental steps. Doubthas also been expressed as to the chances of success ofstandardization efforts such as STEP or IAI, or of anycommon model (Tolman, 1999), due to the innate com-plexity of a unified model, the multinational nature ofthe construction industry, and the required level of con-centrated financing.

This paper suggests that many of the problems listedcould be overcome if a new approach is taken to theprovision of information services in construction, in linewith the suggestion that “the first practical solution tothe integration problem will be realized (through pro-viding a service) rather than the unified development ofstandards” (Tolman, 1999). This implies decentralizationand commercialization—here, entrepreneurs provide aservice, rather than any industry committee effort.

Two trends in IT and construction project manage-ment are of relevance to the following discussion: the firstis the advent of commercial project management Websites, and the second is the application service provider(ASP) model for providing software (ASP Island, 2000).The use of commercial project management Web sites(PMWS) has become common practice in AEC projects.Such sites provide a common data repository for theCAD drawings, text documents, and other data of theproject (Hartung et al., 2000). The site is paid for bythe project owner and managed directly by the projectmanager. While such sites create a “virtual company”for a construction project, and thus improve communi-cation, they do not support any project data modelingcapabilities at this time. In the ASP model, software isinstalled only on the provider’s server and used on-lineby the client through a network (usually the Internet).Remuneration is for a service rather than for purchaseof a package. This has the significant benefit of relievingthe user from the need to maintain or upgrade software,

or finance its purchase; the user is assured access to themost recent version of the software.

In light of these developments and the shortcomingsof BPM standards, it is proposed that the concept ofa central model be revised, particularly with regard tothe ways in which it can be delivered and financed. Thefollowing discussion starts by outlining a likely scenarioof implementation of IFCs in the short term. Next, anew paradigm is proposed and described, in which ap-plication software methods are delivered together withbuilding project model object instances, rather than aspre-sold packages. Three examples of the use of intelli-gent parametric templates are presented to demonstratethe concept. Finally, the obstacles and future researchrequirements are discussed in light of the experiencegained through implementing the examples.

2 THE BASIC IFC APPROACH

A likely scenario of the use of the IFC classes for in-tegrating information processing in construction, usingproject management web sites (PMWS) as facilitators,is shown in Figure 1. In this view, software vendors in-corporate IFCs in their products, that is, they are used asan application programming interface (API) rather thanas a model exchange standard (Tolman, 1999). The userseach build and use their own local project model subsets;data objects are downloaded to and uploaded from thecentral repository as and when needed.

The straightforward drawbacks of this scenario are� Ensuring the integrity of the project data is difficult

(multiple copies of each instance are stored) and datamust be “mapped” or translated between each localbuilding project model and the global BPM

� Adding new building products to the system, with at-tendant data objects, requires software upgrades, evenif the new object classes inherit from the IFC classes

� Updates of vendor software require upgrading at eachdifferent location

� The cost of financing the integration is borne largelyby the AEC consultants

However, this scenario suffers from two more funda-mental problems. First, adding any new building tech-nology or product requires that new objects be definedand agreed upon. This is complex and laborious, since itrequires that the model schema be “evolved” and thenthat each individual software vendor update their ownpackages and translators wherever necessary. Second,the vendor software packages, as “intelligent” as eachmay be, have limited scope (Tolman et al., 2000). Con-sider a simple question an owner may pose to a designer:What will be the cost and schedule implications of a

466 Sacks

Fig. 1. AEC integration using industry foundation classes and a project Web site.

design change (changing exterior finishing technology,for example)? To make this assessment, the designerwould either have to run two additional software ap-plications (estimating and scheduling) or request an-other consultant or the project manager to perform thecheck. Such multidisciplinary issues are common, andthe limited scope of each application in the above sce-nario does nothing to aid the project participants resolvethem.

Two system architectures, which represent improve-ments to that described here, have been tested: theWISPER project (Alshawi, 2000) and an Internet-basedCAD system (Han et al., 1999). In both of these, IFCsprovide the basis for a common project model, and theInternet is used as the communication medium betweenusers (through CORBA technology). However, only theintegrity problem is ameliorated. The others remain,and in addition, the client software packages still re-quire mapping or translation of the project data to theirnative data formats.

3 THE PROPOSED PARADIGM

It is proposed that information generation in construc-tion can be re-engineered: the new paradigm is presentedin Figure 2. The key difference here is that applicationsoftware is no longer delivered as user-based packages,

but as object-oriented methods, tightly coupled to thedata objects, and delivered over the network at run time.

The project participants all work through a commoninterface. The interface is both project and user specific,as is common today (Hartung et al., 2000). In additionto regular project communication functions, each user isgiven appropriate access to the building project modelinstances through a specific professional “view” inter-face (these are programmed by software houses and pro-vided directly by the PMWS). All of the actions a userneed perform (e.g., add and edit assemblies, producedrawings, bills of quantity, and other outputs, etc.) aredone by launching object methods. Producing a projectschedule, for example, could be initiated by a methodof the “IfcProject” class, which would instantiate an“IfcWorkSchedule” and its “IfcTasks” (IAI, 2000). Pro-ducing a bill of quantities for a particular building sys-tem could be launched by an “estimate” method of the“IfcSystem” class, producing an “IfcCostSchedule.”

Two sets of object class definitions and their methodsare used, as distinguished by their source: basic classesand methods, and extension classes and methods. Thebasic methods provide simple functionality for the rootclasses, such as instance, read, write, etc. In many casesthese will be “place-holder” methods, whose main pur-pose is to define the object level interface (method dec-laration) for the base classes. All of the extension classesmust inherit from root classes, and most significantly,

Integrated AEC Information Services Using Object Methods and a Central Project Model 467

Fig. 2. Proposed paradigm for AEC integration.

they must also be subtypes of the base classes—this en-sures that their instances will function with any methodsthat adhere to their base class method declarations. Theextension methods are the majority of the methods re-quired. They can be classified as belonging to one of twokinds:

1. Methods provided by AEC software companies,such as method groups for preliminary design,structural analysis, output of drawings, bills ofquantities, etc. The vendors’ revenues will be ac-crued by selling the methods “per use” or by li-censing the project management Web sites to sellthem.

2. Classes and methods provided by building compo-nent suppliers. These will take the form of intel-ligent parametric templates (IPTs) (Sacks, 1998),which will enable a user to design, analyze, and de-tail complete work assemblies directly in the model.It is envisaged that product supply companies willprovide these free of charge, with the aim of pro-moting sales (at present, CAD file libraries are sup-plied free of charge by a wide range of buildingcomponent suppliers).

In Figure 2 both the base classes and the extensionclasses are shown as residing on the project manage-ment server. It should be noted, however, that this isnot the only (and not necessarily the optimal) possibil-ity: distributed object technology on the Internet makesthe physical location of software resources transparent

to the user (Faraj et al., 1999) These may therefore justas well reside on the vendors’ servers.

4 TWO-TIER “INTELLIGENT” BUILDINGPROJECT MODEL IMPLEMENTATION

The three examples outlined in this section demonstratehow intelligent object sets, rooted (but not necessar-ily contained a priori) in a building project data model(BPdM), may be provided to construction professionals,as envisaged in Figure 2. (Note that the term “build-ing project data model—BPdM” is used to distinguishthe object-oriented data model definition (of classes, in-heritances, and links) from particular instances of build-ing project data, which are termed “building projectmodels—BPM.”) All four make use of intelligent para-metric templates (IPTs) based on the BPdM, and wereimplemented in AutoLISP++.

IPTs are a technique for populating building projectmodels with semantically rich sets of object instances(Sacks, 1998). They are defined as “intelligent mecha-nisms for instantiation of sets of objects and the relationsbetween them.” They comprise a set of parametric ob-jects, which are instantiated dynamically, and can adaptto represent complex real-world assemblies. The term“intelligent” refers to the collections of object methodsand knowledge sets that are processed in order to instan-tiate the object instances and determine values for theirparameters. As distinct from traditional expert systems,

468 Sacks

there is no central “knowledge base”; instead, packets of“knowledge” are coupled to the objects representing thebuilding elements and assemblies to which they pertain.Rule sets are inherited in a similar fashion to methods.This top-down approach allows new technical solutionsto be added incrementally to the library of IPTs withoutany change to the system itself or to previously definedsolutions. The new classes defined to implement an IPT,which extend the base project model in which they arerooted, must inherit from base model classes, and mustremain subtypes of base model classes.

The base BPdM was developed for the automatedbuilding system (ABS; Sacks and Warszawski, 1997).It defines three levels of detail for each of three mainaspects of building information: the building spaces(building, primary space, and secondary space), the as-semblies (building assembly, work assembly, element),and the construction process (task, activity, and basicactivity).

AutoLISP++ is an object-oriented data base manage-ment system, based on the principles of the commonlisp object system (CLOS) (Keene, 1989), and written inAutoLISP (AutoCAD R©) for the purpose of this seriesof building project model research. It includes an inter-preter, a graphic schema editor (which automates writingof class definition files), a rule processor, and an instancebrowser.

4.1 Reinforced concrete column and slab designand analysis

In the first example, two complete IPTs were imple-mented for structural design of reinforced concretecolumns and slabs in rectangular shaped buildings (Sackset al., 2000)—for flat slabs spanning in two directions andfor one directional ribbed (joist) slabs. The requirementwas for technical solution templates that could adaptthemselves to all of the possible geometric and topo-logical configurations that might be required, such asdifferent slab dimensions, openings in the slab of arbi-trary size and location, variations in live load require-ments over the floor areas, etc. In each case, new WorkAssembly type classes were added to provide the anchorfor the new IPT. Certain building element classes werealso added: Figure 3 shows the base BPdM with the flatslab extensions (shown shadowed to the right) and theribbed slab extensions (shadowed to the left). Both in-herit from and are subtypes of the base Concrete slabclass. The new slab work assembly classes each include

� A rule set for proposing preliminary feasible spanlengths,

� A rule set for evaluating the cost of each feasible al-ternative,

� An instantiation method for the work assembly,� An algorithm and rule set for positioning and instan-

tiating Columns, with respect to Building Axes andStructural Walls (building core elements),

� Algorithms for laying out the IPT-specific buildingElements (e.g., One Way Slab Sections and Beams)with respect to arbitrary openings in the floor,

� Methods for performing preliminary sizing and struc-tural analysis of the slab system,

Wherever possible, classes available in the base BPdMare used. These IPTs instantiate objects such as Column,Beam, RC Design Section, Structural Support, Re-bar Use, Rebar, and basic activities such as Build Forms,Fix Steel, Pour Concrete. New classes, such as the One-Way Slab Section, and Column Strip and Middle Strip,all inherit from and are subtypes of the predefinedSlab Strip class.

Two features should be noted:� The two-tier nature of the object definitions—basic

objects and interfaces are part of the common BPdM,while others are added to provide the specific func-tioning of a particular technical solution,

� The tight coupling of the objects’ “form” (attributes),“function” (defined by links within the model), and“behavior” (methods and rule sets) within the modeldefinition. Specifically, the behavior is independent ofthe user interface, or of any one application.

4.2 Formwork design with high shoring towers

A prototype design aid for laying out and sizing tem-porary shoring towers for slab formwork has also beenimplemented using the IPT concept (Shapira, 1998). Theknowledge (rules and objects) for laying out the towers,joists, and stringers and checking their spacings for econ-omy, strength, stability, and safety requirements is imple-mented as an IPT for each proprietary formwork system.Five classes were defined for the IPT implemented inthe experiment: Temporary Support WA, which inher-its from the Work Assembly class of the BPdM, Tem-porary Support Element, which inherits from the Ele-ment class, and Tower, Joist, and Stringer Array classes(Figure 4, extensions shadowed). The formwork IPT ob-jects are fully integrated with the overall project modeland will exhibit all of the behaviors of their parentclasses.

It is common practice for suppliers of specializedformwork systems such as these to assist the contrac-tor in detailed formwork design. The prototype sys-tem provides a clear example of how an IPT couldbe funded by an equipment supplier, programmed andmaintained by a third party software house, providedas a service by a project management hosting Web site,

Integrated AEC Information Services Using Object Methods and a Central Project Model 469

Fig. 3. BPdM classes and ribbed slab extensions. Heavy lines denote inheritance relationships; light lines denote aggregationrelationships.

and used by any project team member, as outlined inFigure 2.

Fig. 4. Extension classes added for the shoring tower IPT.

4.3 Real-time monitoring of labor inputs

The last example concerns real-time monitoring of laborinputs during construction. A model has been developedin which the amount of time a worker spends on anyparticular scheduled activity can be deduced by trackingthe worker’s proximity to the building elements affectedin that activity (Navon and Goldschmidt, 1999). Globalpositioning system (GPS) or radio frequency (RF) tech-nologies have been proposed for use in tracking. Thedata model currently under development for this appli-cation is based on the BPdM, as is shown in Figure 5(classes shown shadowed were added specifically for thisapplication; the others are part of the base model). Workenvelopes represent the three-dimensional space occu-pied by a worker in order to perform a specific pieceof work on a particular building element—either aboveor below it (thickness), within a certain distance fromit (offset), or in a temporary workspace on the buildingsite.

As in the proposed paradigm for providing IT in con-struction (Figure 2), all of the functionality of the laborcontrol application can be provided entirely through the

470 Sacks

Fig. 5. Extension classes to support real-time labormonitoring.

project model classes. Most importantly, work envelopescan be instanced for any building element, without therequirement that its features be known to the labor moni-toring application developer at the time of programming(by definition, any building element must inherit fromthe root Element class in the BPdM). This implies thatany supplier can add new building elements to the over-all system at any time.

5 DISCUSSION AND CONCLUSIONS

The examples demonstrate the extension of the baseBPdM by adding new objects and methods (to serveas IPTs or analysis modules), while retaining the func-tionality of the viewing interface, including the abil-ity to produce outputs automatically. This is possiblebecause

� The data model is two-tiered—first, the basic model,and second, the supplier/application level. The sec-ond tier is entirely rooted in the first through object-oriented inheritance.

� The behavior (methods) is embedded with the dataobjects, and not part of any particular softwarepackage.

� All new instances generated by IPT classes remainsubtypes of existing base classes, and so the basic func-tionality of the user interface, editing, and drawingmethods, etc. is ensured.

These features are inherent in the paradigm proposedin Figure 2. They make it possible to incrementally addcapabilities and new building technologies to the sys-tem, without having to redefine and redistribute the basicproject model as an incorporated part of diverse soft-ware packages. The new paradigm allows a standard-ized basic project model to be combined with growingdomain models, thus providing versatility in terms ofthe range of building products it can support. It repre-sents a practical approach to the accumulation of capa-bilities, through “piecemeal development of modules”suggested by Galle (1995). Furthermore, the centralizeddatabase architecture reduces the problems of maintain-ing integrity, which are difficult where local databases areused.

In many cases design offices represent the weak linkin the economic chain of construction projects. Their re-sistance to integration is often associated with the addi-tional costs of purchasing and upgrading software for usein specific projects. In this paradigm, little or no capitaloutlay is required on their part: the investment requiredfor development and deployment are transferred fromdesign practices to project management “dotcoms” andconstruction component suppliers, who are far better po-sitioned to support capital investments. The operationalcosts are borne directly by the project owners, paid asfees to the PMWS.

A window manufacturer, for example, will provide aset of extension object classes and methods, rooted inthe base building project model, to enable an architectto insert/specify a specific window in a building design(i.e., in a growing project instance model). Using the IPTtechnique, the “window” will be able to insert itself in anywall object and detail its own parts. Through its methods,programmed using predefined base model interfaces, itwill also exhibit “behavior” compatible with the kindsof analyses, drawing production, or other informationprocessing that might be required.

A number of issues remain unresolved and requirefurther investigation. The upper (base) tier must includenot only classes and their attributes and links, but alsobasic methods (such as read(), write(), draw(), etc.) andtheir interfaces (i.e., method input and output defini-tions). These, and professional view interfaces, must beprovided by PMWS companies, who will compete formarket share (any attempt to provide these through

Integrated AEC Information Services Using Object Methods and a Central Project Model 471

industry-wide cooperative efforts seems unrealistic).The model presents no solution to the problem of main-taining integrity during concurrent editing of the BPM bymore than one project participant. The traditional viewof application software will no longer hold; it is not yetclear whether software vendors will impede or acceleratethe adoption of the ASP strategy.

To date, PMWS companies provide data repositoriesbut no applications. It is likely that market forces will in-creasingly pressure them to offer enhanced integrationservices. Providing application functionality using IPTsand ASP technology, as in the proposed paradigm, rep-resents a possible way forward.

REFERENCES

Alshawi, M. (2000), Integrated construction environments:technology and implementation, in INCITE 2000: Imple-menting IT to Obtain a Competitive Advantage in the 21stCentury, HK Poly University Press, Hong Kong, pp. 36–53.

ASP Island (2000), http://www.aspisland.com/services/model.asp.

Bjork, B. C. (1999), Information technology in construction:domain definition and research issues, International Journalof Computer Integrated Design and Construction, 1(1), 3–16.

Eastman, C. M. (1992), Modeling of buildings: evolution andconcepts, Automation in Construction, 1, 99–109.

Eastman, C. M. & Kutay, A. (1991), Transaction managementQ3in design databases, in Concurrency in Engineering DataManagement, D. Sriram, R. Logcher, and S. Fukada (eds.)Springer, New York.

Faraj, I., Alshawi, M., Aouad, G., Child, T. & Underwood, J.(1999), Distributed object environment: using internationalstandards for data exchange in the construction industry,Computer-Aided Civil and Infrastructure Engineering, 14,395–405.

Fenves, S. J., Flemming, U., Hendrickson, C., Maher, M. L.& Schmitt, G. (1990), Integrated software environment forbuilding design and construction, Computer-Aided Design,22, 27–36.

Flemming, U. (1994), Case-based design in the SEED system,Automation in Construction, 3, 123–34.

Galle, P. (1995), Towards integrated, “intelligent”, and com-pliant computer modeling of buildings, Automation in Con-struction, 4, 189–211.

Gielingh, W. (1988), General AEC Reference ModelQ4(GARM), in Conceptual Modeling of Buildings, P.Christianson and H. Karlsson (eds.), CIB Proceedings, Pub-lication 126 W74+W78 Seminar, Lund, Sweden.

Han, C. S., Kunz, J. C. & Law, K. H. (1999), Building design

services in a distributed architecture, ASCE Journal of Com-puting in Civil Engineering, 13(1), 12–22.

Hartung, C. J., deLone, A. C., Kwas, R. M. & Austrian, B.(2000), e-commercial real estate industry overview, Bank ofAmerica Securities Equity Research Working Paper, March2000, San Francisco, CA.

IAI (2000), Industry Alliance for Interoperability, IFC 2x,http://cic.vtt.fi/niai/technical/IFC 2x/index.htm.

Keene, S. E. (1989), Object-Oriented Programming in CommonLisp: A Programmer’s Guide to CLOS, Addison-Wesley,Reading, MA.

Liebich, T. & Wix, J. (1999), Highlights of the development pro-cess of industry foundation classes, in Durability of BuildingMaterials and Components 8 (Vol. 4), M. A. Lacasse, and D.J. Vanier (eds.) NRC Research Press, Ottawa, Canada, pp.2758–75.

Mokhtar, A., Bedard, C. & Fazio, P. (1997), A methodology fordynamically assembling and modifying an active repository Q5building database, Proceedings CIB W78, Cairns, Australia,CIB Publication 208.

Navon, R. & Goldschmidt, E. (1999), Automated data ac-quisition for on-site control, Proceedings of the 16thIAARC/IFAC/IEEE International Symposium on Automa-tion and Robotics in Construction (ISARC’99), Madrid,Spain, 681–86.

Ogunlana, S. O., Promkuntong, K. & Jearkjirm, V. (1995), Con-struction delays in a fast-growing economy: comparing Thai-land with other economies, International Journal of ProjectManagement, 14(1), 37–45.

Sacks, R. (1998), Issues in the development and implementa-tion of a building project model for an automated buildingsystem, International Journal of Construction InformationTechnology, 5(2), 75–101.

Sacks, R. & Warszawski, A. (1997), A project model for an au-tomated building system; design and planning phases, Au-tomation in Construction, 7, 21–34.

Sacks, R., Warszawski, A. & Kirsch, U. (2000), Structural designin an automated building system, Automation in Construc-tion, 10(1), 181–97.

Shapira, A. (1998), Formwork design for high shoring towers,Concrete International, American Concrete Institute. Q6

Teicholz, P. & Fischer, M. (1994), “Strategy for Computer In- Q7tegrated Construction Technology,” ASCE Journal of Con-struction Engineering and Management, 120(1).

Tolman, F. P. (1999), Product modeling standards for the build-ing and construction industry: past, present and future, Au-tomation in Construction, 8, 227–35.

Tolman, F. P. & Wix, J. (1996), Building construction core model(BCCM) version 1.0, ISO/TC/184/SC4/WG1.

Tolman, F. P., Ozsariyildiz, S. & Schevers, H. (2000), Computeraided inception of large scale engineering projects: evaluat-ing value versus cost, in INCITE 2000: Implementing IT toObtain a Competitive Advantage in the 21st Century, HongKong, Poly University Press, Hong Kong, pp. 744–55.

Turner, J. (1988), AEC building systems model, working paperISO/TC/184/SC4/WG1.

472 Sacks

Q1 Au: O.K. to change match referenceQ2 Au: O.K. to change date to match reference?Q3 Au: Page # s?Q4 Au: Page # s?Q5 Au: Page # s?Q6 Au: city of publication?Q7 Au: Page # s?