UBC Theses and Dissertations

UBC Theses Logo

UBC Theses and Dissertations

Formalization of transactions in AEC/FM industries Pouria, Arezou 2007

Your browser doesn't seem to have a PDF viewer, please download the PDF to view this item.

Notice for Google Chrome users:
If you are having trouble viewing or searching the PDF with Google Chrome, please download it here instead.

Item Metadata

Download

Media
831-ubc_2007-0213a.pdf [ 9.53MB ]
Metadata
JSON: 831-1.0063244.json
JSON-LD: 831-1.0063244-ld.json
RDF/XML (Pretty): 831-1.0063244-rdf.xml
RDF/JSON: 831-1.0063244-rdf.json
Turtle: 831-1.0063244-turtle.txt
N-Triples: 831-1.0063244-rdf-ntriples.txt
Original Record: 831-1.0063244-source.json
Full Text
831-1.0063244-fulltext.txt
Citation
831-1.0063244.ris

Full Text

FORMALIZATION OF TRANSACTIONS IN A E C / F M INDUSTRIES by A R E Z O U POURIA M.Eng., Tehran University, 1985 A THESIS SUBMITTED IN PARTIAL F U L F I L L M E N T OF THE REQUIREMENTS FOR THE DEGREE OF M A S T E R OF APPLIED SCIENCE in THE F A C U L T Y OF G R A D U A T E STUDIES (Civil Engineering) THE UNIVERSITY OF BRITISH C O L U M B I A February 2007 ©Arezou Pouria, 2007 Abstract The main objective of this dissertation is to contribute to the field of Computer Integrated Construction (CIC). Total Project Systems (TOPS) is an ongoing research project at the University of British Columbia which streamlines the CIC strategies. This research is a component of the TOPS project which focuses on the formalization of transactions or information exchanges in A E C / F M . The main objective of this research is achieved by pursuing sub-objectives set as follows: • Trace the trend of CIC in the A E C / F M industry and study the related efforts within other industries. • Develop an approach for formalizing transactions. • Analyze a process as an example and define formalized transactions needed for the process. • Create a prototype system that uses the formalized transactions to demonstrate and evaluate the proposed approach. The research consists of two parts. It uses techniques such as a survey, literature review, and a case study, to answer the questions of the first part of the research: • What is the state of the art in the field of formalization of transactions in AEC/FM? • How should A E C / F M transactions be formalized? Answering these questions led us to propose a multidimensional formalization approach that uses extensible Mark up Language (XML) . The second part of the research demonstrates that the proposed approach formalizes transactions in the way that research suggested in the first part.. For this part, the research develops a prototype application for the example process, which uses the proposed multidimensional formalization system. The example process was taken from a case study done at U B C T R E K program centre. The research implements a rapid prototype ii testing technique to evaluate the functionality of the proposed system for the prototype application. The main contributions of the research are answering the questions in the first part, and the proposed system and its implementation in the second part. Future directions of the research could be to improve the proposed approach, and developing other applications that use the formalized transactions. i i i Table of Contents Abstract ii Table of Contents iv List of Figures vii List of Abbreviations ix Acknowledgement xi Chapter 1 : Introduction 1 1.1. Introduction to this Research 1 1.2. Standards at both Product and Process Levels 5 1.3. Impact of Improved Transactions 6 1.4. Motivation for the Research 7 1.5. Research Foundations 8 1.6. Research Questions and Hypothesis 9 1.7. The Need for the Research 10 1.8. Research Challenges 12 1.9. Research Scope 14 1.10. Research Objectives 15 1.11. Research Methodology 15 1.12. Case Study 17 1.13. Reader's Guide 21 Chapter 2: Points of Departure 23 2.1. General computer standards 23 2.1.1. EXPRESS 24 2.1.2. X M L 26 2.1.3. Unified Modeling Language U M L 28 2.2. A E C / F M standards 30 2.2.1. STEP 32 2.2.2. The International Alliance for Interoperability and Industry Foundation Classes 33 2.2.3. i f cXML (ifcXML 2005) 34 2.2.4. aecXML 35 2.2.5. Building Construction extensible Markup Language b c X M L 35 2.2.6. Example of a Set of Transactions in the A E C / F M Bidding Process 36 2.3. Standards in other industries 38 2.3.1. Electronic Data Interchange (EDI) 38 2.3.2. RosettaNet 40 2.3.3. Electronic Business using the extensible Markup Language 42 2.3.4. eCo (eCo 2005) 43 Chapter 3: Formalizing Transactions in the AEC/FM Industry 44 iv 3.1. Previous Work 47 3.1.1. Information flows in A E C / F M 47 3.1.1.1. Shahid and Froese 48 3.1.1.2. Wix and Liebich 50 3.1.1.3. Process Protocol, Salford University 52 3.1.1.4. Other studies 53 3.1.2. Classification systems in the A E C / F M industry 56 3.2. Survey 59 3.3. RosettaNet Partner Interface Processes (PIPs) 61 3.4. Elements of Transactions Based on Communication Theory 62 3.4.1. Document Common Name 63 3.4.2. Roles 64 3.4.3. Stage of the project 65 3.4.4. Field of Transaction 67 3.4.5. Type of Transaction 67 3.4.6. Security 67 3.4.7. Data Content of the Message 68 3.4.8. Other Elements 68 3.5. aecXML Use Case Template 69 3.6. Discussion of the Research Questions 69 Chapter 4 : Multidimensional Formalization System 75 4.1. Multidimensional Formalization System 78 4.2. A Discussion about the Research Hypothesis 91 4.2.1. Combination of Different Layers of Information 94 4.2.2. Both Human and Computer Interpretability 95 4.2.3. Ability to Transform the Document using X S L T 95 4.2.4. Ability to Categorize Transactions Based on the User's Interests 95 4.3. The Role of Formalized Transactions 96 4.3.1. Product Model Standards 96 4.3.2. Classification Systems 97 4.3.3. Applications 97 4.3.4. Organizations and Work Process 98 4.3.5. Knowledge management 99 Chapter 5: Review Process for Sustainable Planning—Case Study 100 5.1. Review Process As-Is 101 5.1.1. Introduction 101 5.1.2. Generality of the Review Process 102 5.1.3. Land and Building Services 102 5.1.4. L & B S Review Process 103 5.1.5. Analysis of the L & B S Review Process 104 5.2. Review Process "To-Be" 107 5.2.1. "Request for Comment" Transaction 108 5.2.2. "Notification of Project" Transaction 109 5.2.3. Analysis of the To-Be process 111 5.2.4. Advantages of using formalized transactions for the review process 117 v Chapter 6: Implementation of the formalized transactions through a prototype application 119 6.1. Introduction 119 6.1.1. System Architecture 120 6.1.2. .NET Environment 122 6.1.3. System Functionality 124 6.2. Description of the Prototype Application 125 6.2.1. The project manager is able to view all previous transactions sent and their responses, i f applicable 125 6.2.2. The project manager searches for a formalized transaction 128 6.2.3. The project manager creates an instance of the formalized transaction 130 6.2.4. The project manager sends the transaction to the other department 131 6.2.5. The other department receives the transaction 132 6.2.6. The other department processes the transaction if needed 132 6.2.7. The other department acknowledges or responds, if needed 133 6.3. Discussion of the Prototype 133 Chapter 7: Conclusions 140 7.1. Summary 140 7.2. Contributions 141 7.2.1. A review of efforts in the field of formalization of data exchange in the A E C / F M industry and other industries 143 7.2.2. The establishment of the notion of process standards in the A E C / F M industry which is needed for the realization of the CIC strategies 143 7.2.3. A Multidimensional Formalization System to define transactions in A E C / F M using the X M L technologies 143 7.2.4. Analysis of a review process from our case study 144 7.2.5. Application of the multidimensional formalization system for the approval process and defining the transactions used in the process 144 7.2.6. A prototype application to demonstrate the functionality of the formalized transactions 144 7.3. Future Work 144 7.3.1. Multidimensional Formalization System 145 7.3.2. Transaction representation tools 145 7.3.3. Analysis of other processes in A E C / F M 145 7.3.4. Implementation prototype 146 7.3.5. Other applications 146 References 147 Appendix 153 A . l Express 153 A.2 STEP 155 A.3 Transaction dimension table 157 v i List of Figures Figure 1.1 Two parts of the research (Fellows and Liu 2003) 10 Figure 1.2 The Depth vs Breadth from (Fellows and Liu 2003) 17 Figure 2.1 EXPRESS Listing of a schema for a simple model containing two entities 25 Figure 2.2 EXPRESS G diagram of a schema for a simple model containing two entities 26 Figure 2.3 ISO STEP Part 21 listing of a sample data set for the schema shown in Figure 2.1 26 Figure 2.4 DTD Schema definition for a simple model containing two entities 28 Figure 2.5 X M L data set for the schema shown in Figure 2.4 28 Figure 2.6 U M L Class Diagram of a schema for a simple model with two elements 29 Figure 2.7 U M L Instance Diagram of a data set for the schema shown in Figure 2.4 30 Figure 2.8 The Sub-schema that make up the IFC data model 33 Figure 2.9 A set of transactions in the field of bidding 37 Figure 2.10 RosettaNet's comparison 40 Figure 3.1 Personnel vs. Function Matrix (Shahid and Froese, 1998) 48 Figure 3.2 Personnel vs. Information Needs Matrix (Shahid and Froese, 1998) 49 Figure 3.3 Document Type vs. Information Contents Matrix (Shahid and Froese, 1998) 49 Figure 3.4 Matrices of information flow (Wix and Liebich, 2001) 51 Figure 3.5 Elements of communication theory 63 Figure 3.6 Different documents in A E C / F M 64 Figure 3.7 Different roles in A E C / F M . . 65 Figure 4.1 Document Type Definition (DTD) 82 Figure 4.2 X M L document of "notification of the project" transaction 83 Figure 4.3 X M L document of "request for comment" transaction 84 Figure 4.4 A simple version of an X S L file 85 Figure 4.5 Script within an ASP file 86 Figure 4.6 A screen capture of the sample transaction converted via the sample X S L file 87 87 Figure 4.7 A screen capture of the sample transaction converted via the sample X S L file (continued) 87 Figure 4.8 Modified X L S file 89 Figure 4.9 Modified script within an ASP file 89 Figure 4.10 A screen capture of the sample transaction converted via the sample X S L file transaction 1.asp 90 Figure 4.11 A screen capture of the sample transaction converted via the sample X S L file transaction 1.asp (continued) 90 Figure 5.1 Review process activity model for checking the code from the perspective of the reviewer 105 Figure 5.2 Review process activity model from the project manager's perspective 105 Figure 5.3 Review process activity model from the department's perspective 106 vii Figure 5.4 Review process activity model for code checking from the department's perspective 106 Figure 5.5 Request for Comment.... 109 Figure 5.6 Notification of Project 110 Figure 5.7 Use case model of the prototype system 112 Figure 5.8 Two transaction instances that are sent through the prototype system 113 Figure 5.9 Use case models for different responses of the TREK department 114 Figure 5.10 Swim lane model for the "Request For Comment" transaction 115 Figure 5.11 Sequence model for the "Request For Comment" transaction 115 Figure 5.12 Swim lane model for the "Notification of Project" transaction 116 Figure 5.13 Sequence model for the "Notification of Project" transaction 117 Figure 6.1 Architecture of the prototype system 120 Figure 6.2 Architecture of the .NET Framework 123 Figure 6.3 .NET Class Library 124 Figure 6.4 Main form 126 Figure 6.5 The Transaction View form 127 Figure 6.6 Response Form 128 Figure 6.7 Selecting a formalized transaction 129 Figure 6.8 Result of search among the existing formalized transactions 130 Figure 6.9 A to be completed transaction shown in the Transaction View form 131 Figure 6.10 Login form 132 Figure 6.11 A message box indicating that the message has been received 132 Figure A . l EXPRESS Example 154 Figure A.2 EXPRESS-G Example 155 viii List of Abbreviations A D M Accumulated Deferred Maintenance A E C / F M Architectural, Engineering, Construction, and Facility Management A E X Automating Equipment Information Exchange AIA American Institute of Architecture ANSI American National Standards Institute ASCII American National Standard Code for Information Interchange A U C C Association of Universities and Colleges in Canada BC Building and Construction BCIT British Columbia Institute of Technology b c X M L Building and Construction extensible Markup Language BPPMTF Building Projects Practice Manual Task Force C A D Computer-Aided Design C A U B O Canadian Association of University Business Officers CIC Computer Integrated Construction CICS Construction Information Classification System CI/SFB Construction Index / Samarbetskommitten for Byggnadsfragor CP&D Campus Planning and Development CSC Construction Specifications Canada CSI Construction Specification Institute CSS Cascading Style Sheet DTD Document Type Definition eBTWG eBusiness Transition Working Group EDI Electronic Data Interchange GDCPP Generic Design and Construction Process Protocol GenCOM General Construction Object Model GSA General Services Administration GUI Graphical User Interface G V R D Greater Vancouver Regional District H O V High Occupancy Vehicle H T M L Hyper Text Markup Language HTTP Hyper Text Transfer Protocol H V A C Heating, Ventilating, and Air-Conditioning IAI International Alliance for Interoperability ICON Information/Integration for Construction ICT information and Communication technology ix IFC Industry Foundation Class ISO International Standards Organization ISTforCE Intelligent Service Tools for Concurrent Engineering IT Information Technology IT A C Information Technology for A E C in Canada JIT Just-In-Time L & B S Land and Building Services (UBC) LSE Large Scale Engineering NPD New Project Development NIST National Institute of Standards and Technology OASIS Organization for the Advancement of Structured Information Standards OCCS Overall Construction Classification System OCP Official Community Plan O M G Object Management Group OO Object-Oriented PIP Partner Interface Process PMICS Project Management Information Control System R A F Reference Architectural Framework RFI Request for Information RFQ Request for Quotes S G M L Standard Generalized Markup Language STEP Standard for the Exchange of Product data STP Strategic Transportation Plan TCP/IP Transmission Control Protocol/Internet Protocol T D M Transportation Demand Management TOPS Total Project Systems T R E K Transportation Reduction Education and Knowledge U B C University of British Columbia U M L Unified Modeling Language U M M UN/CEFACT Modeling Methodology UN/CEFACT United National Center for Trade Facilitation and Electronic Business UN/EDIFACT United National Electronic Data Interchange for Administration, Commerce, and Transport W3C World Wide Web Consortium X M L extensible Markup Language X S L extensible Style Language x Acknowledgement I would like to thank my parents Iran and Khosro who taught me to play the strings of my soul with love, care, and faithfulness; some unexplored dimensions of our universe. x i Chapter 1: Introduction Chapter Abstract: This chapter introduces the work, including the research questions and hypothesis, research foundations, challenges, scope, objectives, methodology, and reader's guide. 1.1. Introduction to this Research This dissertation contributes to the field of Computer Integrated Construction (CIC). CIC aims to provide an integrated environment for Architectural, Engineering, Construction, and Facility Management (AEC/FM) industries, so that all computer applications can generate, share, and exchange data among themselves in an interoperable manner. Many researchers have conducted studies in the field of CIC in recent years. Among these studies, the work done by Russell and Froese in 1996 is of particular interest. They addressed the challenges facing the A E C / F M industry in implementing CIC strategies and deploying interoperable software throughout the whole life cycle of building projects. By interoperable software we mean multiple applications that do not need human interference for converting the output of one application to make it the input for the other application. In continuation of the effort to face those challenges, Froese, Rankin, and Y u (1997) proposed TOtal Project Systems (TOPS) and Y u (2001) defined the TOPS Reference Architectural Framework (RAF). TOPS RAF provides a comprehensive, integrated, and flexible environment for distributed heterogeneous applications to interoperate with each other. Shahid and Froese (1998) addressed project management information control systems. This thesis is considered to contribute to the TOPS efforts by focusing on the formalization of A E C / F M processes, with a long-term objective of contributing to the standardization of these processes. It also extends other significant research efforts such as International Alliance for Interoperability (IAI) (IAI 2005) projects and their partners, 1 Intelligent Service Tools for Concurrent Engineering (ISTforCE), eConstruct, and other research in the field of CIC. There were many reasons to pursue this research and these will be discussed in more detail in the following sections. Generally, since A E C / F M is a fragmented industry, many participants need to collaborate with each other during a short period of time. The need for interoperability is especially critical in this industry since the work involves large, highly interdependent and information-rich activities carried out by a wide spectrum of participants from many different organizations. Low margins and short project durations, as well as diverse actors participating in each project, leave little opportunity for timely adaptation of customized solutions. Thus, the best way to achieve interoperability is to communicate using common, industry-standard data languages. The formalization of data exchanges and standardization of these formalized transactions would play a vital role in enabling all the participants to understand and respond to each other in an expected manner. Furthermore, from a management perspective, A E C / F M processes are associated with the timely and accurate flow of information between project participants throughout the lifecycle of the project. These information flows are a crucial factor for the success of A E C / F M projects. In this research, the term "transaction" is used to describe any exchange of information, communication or interaction between different parties that make up the project's information flows. Transactions can generally be described in relation to various activities performed by project participants to achieve specific business objectives. Transaction examples in A E C / F M include on-line purchasing of materials, requests for information on a job site, and reporting inspection results. Transactions involve information content as well as a number of characteristics and context that describe how the transaction is carried out, for what purpose, with what obligation of participants, etc. Given this notion of transactions, how does the formalization of transactions contribute to CIC? On A E C / F M projects today, transactions are a commonplace occurrence. Yet these transactions are almost exclusively human-to-human information exchanges (even where the information is produced and communicated electronically, 2 such as email, the information is ultimately interpreted by a person rather than used directly by another computer application). In many cases these human-to-human transactions are ad hoc, with little i f any pre-established structure to the content, characteristics, and context of the transactions. Although many standard documents are used by different companies, however, there is no common standard that defines the vocabulary (what) or grammar (how) of the language by which data exchanges take place in the industry. In contrast, CIC involves the direct exchange of information from one computer application to another. This process requires that the transactions be much more structured than for human-to-human transactions, and that the structure be known to all participants. Therefore, efficient electronic information flow and exchange among project processes requires that transactions be formalized and, where possible, standardized among participants. The information flows made possible by this formalization and standardization will improve the functionality and efficiency of information exchange on projects, leading to cost savings, better quality, and shorter duration of building projects. Many studies have found that interoperability saves costs and increases the productivity of building projects. In section 1.3 a study conducted by NIST will be discussed. It is assumed that seamless information exchanges in quality control processes such as in time inspection reports, deficiency reports, warning notices, etc. will help increase the quality of a building project. Although the main focus of the research is to provide means for seamless computer-generated transactions in the industry, it is also useful for human-generated transactions. One might think that formalized transactions are not required for human-to-human communication, where the participants have a high capacity to "interpret" the transaction semantics, but even in human-to-human communication, they will help to express the implicit rules that lie behind the culture and business language of the A E C / F M industries. Expanding the body of knowledge in the field of the processes in A E C / F M will help provide a better understanding of those processes for the whole industry. It provides a transparent environment for experts and industry practitioners to be able to identify a 3 process and know about its characteristics. The necessity of such transparency is more evident as we move to a computerized working environment. It contributes to the implementation of CIC, which in turn increases the need for greater formalization. Since the formalization of transactions can lead to both increased efficiency in projects' information handling and to a better awareness and understanding of the information exchange processes, it can contribute to numerous secondary benefits. These include improvements to a range of information systems such as document management and workflow management systems, improved efficiency of the project design and construction process overall (and therefore improved sustainability in the construction industry), and improvements to the education of A E C / F M work processes. It is notable that in the computing environment of today, using extensible Markup Language (XML) format is a choice that provides more opportunities for interoperability with other applications. As well as its wide acceptance, it allows for defining a process using a human-interpretable language. The decision to use X M L was arrived at after trying to define a process along with all possible aspects of the information exchange. The following sections discuss the research in more detail by first discussing standards at the product and the process level. Computer interoperability for A E C / F M is achievable only i f one can model both the products and the processes of the industry. Where consensus regarding these modeling efforts can be reached, standards can be introduced to enable the interoperability of different applications. It does not mean that until then, no interoperability will be possible. Every step should be taken to put the whole puzzle together. For true and complete realization of CIC strategies to happen in the industry, which can exclude the knowledge expert interference from the whole processes of A E C / F M , an expert should be able to model his/her knowledge into a computer interpretable model and add intelligence to the machine. There is a long way till then, but each research plays its role in achieving that ultimate goal. 4 1.2. Standards at both Product and Process Levels The preceding introduction discussed the necessity of formalization and standardization of the processes in A E C / F M . The author's literature search showed that compared to the studies in the field of product modeling, less attention has been paid to processes. Much of the research throughout the last decade was driven by the need to develop standard industry-wide data models for A E C / F M projects. Although it is clear that standards should be developed at the product level, there is also the need to establish standards at the process level, or at the transaction level. Data models are needed to provide a common language for various actors or their corresponding software agents in A E C / F M . These data models will facilitate interoperability and better communication and exchange of information. Comparing a natural human language like English with a hypothetical common business electronic language in A E C / F M , one can imagine the product model standards as the meaning of the words or the dictionaries, and transaction standards as the way that those words should be used in a meaningful conversation. Standard data models standardize the product representation, while transaction standards define standards at the process level. As an example (drawn from the domain of transportation planning, which is the focus of the more detailed examples developed later in this thesis), a parking stall with all of its physical/technical properties would be treated as a product of a certain A E C / F M project, while the act of communicating the number of parking stalls from the architect to a transportation engineer for the purpose of checking Transportation Demand Management (TDM) codes could be considered as a process. Throughout the world, many efforts have been underway to standardize the data models used in the industry. One of the most important organizations working on the standardization of product data in A E C / F M is ISO Standard 10303, STandard for the Exchange of Product data (STEP). Another effort is the IAI. These efforts will be discussed in more detail in Chapter two. Interoperability can be described in terms of seamless data exchanges (transactions) that occur among users and applications. Efforts such as ISO STEP and the IAI standardize the data content of these transactions— 5 however, interoperability also requires that the context of these transactions be formalized and standardized. Issues relating to A E C / F M processes have been the subject of a few studies that will be discussed in Chapter three. Most of the studies have been focusing on the products rather than the processes. As far as our literature search has shown, those few studies about the processes have focused on mapping out the range of typical document exchanges that exist on projects; they have not addressed mechanisms for capturing the details of the A E C / F M processes and their overall placement within the whole life cycle of the project. Although this research will contribute to the field of CIC and add to the body of knowledge in the field of formalization and standardization of the products and processes in A E C / F M , it does so independent of any specific data model standards, as there are still no widely agreed-upon data models implemented in different applications in A E C / F M industries. This will not prevent the research though, to use an example data model to show the possible linkage of the system to a data model. In other words, it is believed that this research streamlines interoperability of different applications in the industry by providing a formalization system that uses X M L technology. 1.3. Impact of Improved Transactions One of the first questions that we usually receive from the industry is the effect of interoperability in monetary format. To illustrate the effect of interoperability, it would be beneficial to think about the nature of any A E C / F M project. Many participants collaborate for the realization of an A E C / F M project. Each participant draws upon the previously developed information, adds their contribution (working with their own computer tools), and passes their work on to others through drawings and various documents or by other means. In the stage of transferring the work between experts, there is a great possibility of loss of information. Standard data models, by enabling interoperability between the 6 computer applications used throughout the project, reduce the information loss and increases productivity and quality of A E C / F M projects. A study was conducted by the National Institute of Standards and Technology (NIST) about the cost analysis of inadequate interoperability in the U.S. capital facilities industry. The study estimated building owners and operators could have saved at least 15.8 billion dollars in 2002 through better coordination of electronic data. Over 374 billion dollars were invested in new facilities or renovations and additions in 2002 (NIST 2004), giving a potential savings of 4.2%. We might expect a similar rate for the industry in Canada. It has been reported that the National Gross Output forecast of construction was 123 billion dollars in 2003 (Canadian Construction Association 2003) and over 160 billion dollars in 2004 (Canadian Construction Association 2004). In Canada alone, therefore, the amount of savings would be billions of dollars. Although many issues should be dealt with for the complete realization of CIC in A E C / F M , it is believed that this research provides a useful contribution towards interoperability in the industry, which would be beneficial for the economy of the whole country. 1.4. Motivation for the Research Motivation for the research came from the author's personal work experience overseas. As an engineer, she experienced many instances of inefficient communication due to the lack of a formalized process. As a structural engineer she knew what kind of information she needed to be able to design a reservoir .After many problems that she faced in accessing the right information through different projects, she created a document that asked explicit questions about the information that she needed. This formal document did not exist before. Formalizing the transfer of information served its purposes well and increased productivity of the design phase in her department. As a case study, to observe a real process in the industry, she worked as a student for the T R E K program centre and contributed to an audit checklist for new developments on campus. Although the motivation for the research was created through an anecdotal 7 observation in a working environment far from perfect operations, similar problems were observed through the case study of this research 1.5. Research Foundations This work builds on previous research in the field of CIC. We believe that CIC will continue to grow in the future—a view supported by a survey and literature reviews conducted during this research. The research also builds upon the field of communications theory, and upon existing standards and computational technologies such as HTTP, X M L , and .NET. • CIC provides an integrated environment for A E C / F M industries, so that all computer applications can generate, share, and exchange data among themselves in an interoperable manner. Although construction involves high risks that resist the implementation of new technologies, for different companies to be competitive there is the need to incorporate new techniques and processes. Despite the costs and risks involved, the industry is in need of computer applications that can link and talk to each other and can eliminate the re-entry of data and manual documentation of communications that happen among the various participants and applications at present. Different firms that provide applications for the A E C / F M industries tend to link their applications to other applications. For example, Timberline estimation software can integrate with Computer-Aided Design (CAD), scheduling applications, etc. (Timberline 2004). ICE2000 by MC2 allows the user to link with systems such as Primavera P3, Expedition, and MPS Prolog Manager (MC2 2004) and WinEST by WinEstimator Inc. can integrate with accounting, scheduling, project management, and C A D (design drawing) software solutions (WinEst 2004). These links should be based on an industry-wide standard language for products and processes of A E C / F M to achieve the ultimate goals of CIC. Many studies in the field of CIC have focused on defining the objects and the processes of A E C / F M . Eastman made a thorough review of the efforts in the field of product modeling in his book "Building Product Models" 8 (Eastman 1999). This research discusses some of these efforts in the second chapter. Some of the previous work in the field of information flows in A E C / F M will be discussed in the third chapter. • Communication Theory. This research examines and structures formalized transactions with respect to communications theory, which considers characteristics of senders and receivers, communication channels, barriers and filters, the message and the feed back. We will discuss communication theory in Chapter three. • Computer Standards. Various Internet protocols such as Hyper Text Transfer Protocol (HTTP), Transmission Control Protocol/ Internet protocol (TCP/IP), and X M L have been adopted for this dissertation. This research assumes that the trend in processes and data communication in the A E C / F M industry will be towards increasing use of the Internet and electronic devices, including desktop computers, laptops, and wireless technologies. For the implementation part of the research, the mentioned Internet protocols have been used through the Microsoft Visual.NET environment. X M L has also been used for the multidimensional formalization system which will be discussed in the forth chapter. 1.6. Research Questions and Hypothesis This research consists of two parts. The first part addresses the following questions. • What is the state of the art in the field of formalization of transactions in AEC/FM? • How should A E C / F M transactions be formalized? Chapters two and three will discuss the findings of the research about these questions. Answering these questions led the author to propose a system which is the subject of the fourth chapter and created the hypothesis of the research for the second part of our research. The hypothesis of this research is that the proposed system formalizes transactions in the way that the first part suggested. Figure 1.1 is the model of our research. 9 Figure 1.1 Two parts of the research (Fellows and Liu 2003) 1.7. The Need for the Research CIC involves the computer-based exchange of information between parties. Gould and Joyce, (Gould and Joyce 2003) stated that traditionally, project information was passed on linearly throughout the life cycle of the building. CIC, creates a central electronic repository that could be accessed by different parties. In order for computers to exchange information, there must be formal rules governing information exchange. These formal rules are relevant to many cases that should each be defined according to an agreed upon format. There is a need to formalize different scenarios of data exchanges in the A E C / F M industry so that all of the processes can lend themselves to the strategies of CIC. Formalization of the processes not only actualizes CIC objectives but also enables a better understanding of the pitfalls of existing processes and will help to identify strategies to compensate for problem areas. By formalization, we mean defining the processes and analyzing complex scenarios to atomic units of data exchanges in a systematic manner. In order to allow interoperability through the industry, these information exchange rules must be standardized. The formalization of transactions streamlines their 10 standardization. The electronic devices that will be used for the actual exchanges of information lack the human capacity for observation and comprehension. This implies the need for formalization of the data exchanges between various roles and their applications using a format that could be interpreted by computers and, for ease of use and ensuring the continuation of its usage, by humans as well. These information exchanges constitute a series of transactions that do not necessarily involve any kind of monetary exchange. In the business world, the word "transaction" is usually used for the exchange of goods and money. Since each transaction is about exchanging data related to the project, the elements of communication theory could be applied in each case. This research will study the elements of communication theory and apply them in defining the transactions which results in a Multidimensional Formalization System. Considering the fact that transactions in this research are not limited to commercial transactions that usually happen between a buyer and a seller, the system should be able to accommodate numerous roles, stages of the project, and many other elements that will be discussed in more detail in the following chapters. The broad range of these variations necessitates usage of an approach that will differ from those used in the supply chain. Categorization of those formalized transactions will be one of the challenges of this research. In addition to the realization of CIC objectives, the ability to develop automated information processing tools also requires formalized descriptions of information exchange. Much work in the field of product modeling and process modeling in construction computing studies has gone into the formalization and standardization of the data used to describe A E C / F M projects (the content of transactions), but not the process or the context of the transactions. Therefore, the development of an approach for formally specifying transactions within the A E C / F M industry is a necessary input to the future development of transaction standards, interoperability solutions, and automated information processing systems for the industry. In the next section, the challenges that the research faced will be discussed. 11 1 . 8 . Research Challenges It has been shown that CIC requires the formalization and standardization of the information in data exchange transactions. Standardization could happen after the formalization is accepted by the majority of the industry and by standardization bodies and organizations in the industry while "Formalization" is to clearly define and categorize transactions. While much work has gone into the standardization of the content of data exchange (i.e., product model standards), little work in the field of process modeling in construction computing studies has examined the process perspective to formalize and standardize the types of transactions that take place during A E C / F M projects. The issue is complex since there is such a broad spectrum of types of information transactions that occur continuously throughout the life of a project, and the range of potential technical solutions and issues is very broad. The central challenge addressed by this research is to develop a feasible technical approach to the formalization of construction transactions, as a necessary ingredient to future standardization efforts, CIC interoperability solutions, and task automation. This solution considers issues such as what techniques to adapt from other industries, and how to handle both transactions that are common throughout the industry as well as transactions that are unique to certain situations. In adapting from other industries, the challenge is the environment and culture of A E C / F M industries and specifically Construction Management. As mentioned earlier, the nature of construction projects is different than other manufacturing projects. The number of participants is far more than other industries and the duration of the projects are shorter. Since it does not need much capital to enter the construction industry, during boom periods, many people enter the industry without sufficient academic qualifications or related background. Margins are low and risks are high These could be among the reasons that automation, computerization, standardization and formalization of the processes in A E C / F M are lagging behind other industries. Research efforts should have an eye on these challenges that are unique to construction projects. 12 The challenges of this research are of two types. The first type of challenges are related to the topic of the research and are the fuzzy problems or subjective challenges that the research faced. Since our methodology for the first part of the research was based on induction, these subjective challenges were mostly dealt with in the first part of the research. The second type of challenges are the well defined problems or objective challenges of the research. The objective challenges include but are not limited to the following: Fragmentation in the industry The environment and level of knowledge about CIC in the industry The environment of the computing world Developing a generic approach At the end of Chapter Three, we will mention how we overcame these subjective challenges. The objective challenges include but are not limited to the following: In the first part of the research: Finding an important missing link for the realization of CIC • The scarcity of previous work in the field • Finding out the current overall opinion and environment of the industry about the usage of information technology through a survey Determining how transactions should be formalized In the second Part of the research: • Developing a solution Testing the solution 1. Validation with respect to the requirements and issues suggested in the first part of the research. 2. Demonstrating the usage of the solution The As-Is process and improved To-Be process 13 • The problems in the As-Is process The problems solved by the To-Be process using the solution The objective challenges for the first part of the research are an inherent part of Chapters Two and Three. We will explain how the research overcame the objective challenges for the second part of the research at the end of Chapter Six. 1.9. Research Scope The scope of this research is the formalization and standardization of information exchange transactions for the A E C / F M industry. The intention is that the research should cover different types of transactions: Transactions that are for distribution of information only, as well as transactions that need a response. The research should not be limited to only the first type of transactions, it should be able to provide solutions for both types of transactions. For the implementation part, however, a process involving the distribution of project information for review purposes is used for illustrative and prototyping purposes. It contains both types of transactions, so it is not only for a specific type of transaction. The work focuses primarily on the information flow context of the transactions, but also, considers the data content of the exchanges. The data content is not restricted to any particular data models or standards. The role of the research is to act as a placeholder for different probable data content standards. The work addresses the general role of transactions and approaches for formalizing and standardizing these transactions. It could be used with different types of data standards. However there will be the need for a mapping tool to be able to extract the content through different data standards which may be used. These transactions, when put together in a proper sequence, will be the subject of workflow management studies which are outside the scope of our research. This research is considered to be a necessary input upon which future workflow management research could build. 14 1.10. Research Objectives The main objective of this research is to contribute to CIC by developing an approach for the formalized specification of transactions in the A E C / F M industry, as an input to future transaction standardization, interoperability, and automated information processing activities. The main objective of contributing to CIC is achieved by pursuing the following sub-objectives: • Trace the trend of CIC in the A E C / F M industry and study the related efforts within other industries. • Develop a solution for formalizing transactions. • Analyze a process as an example and define formalized transactions needed for the process. • Create a prototype system that uses the formalized transactions to demonstrate and evaluate the proposed approach. 1.11. Research Methodology A combination of qualitative and quantitative methods has been used for this research. The research uses a case study approaches from qualitative methods and a survey from quantitative methods. Evaluation of the prototype system uses rapid prototype testing method. Love et al. discussed triangulation in construction management research (Love et al. 2002). They suggested an approach that uses both ontological (referring to the metaphysical nature of being) and epistemological (referring to the theory of method or grounds of knowledge) viewpoints. They believe that since construction management is at the intersection of natural sciences and social sciences, the methodology used to conduct research could reasonably be a combination of methods used for the two distinctive sciences. Triangulation is described as the usage of qualitative and quantitative techniques together to study the topic (Fellows and Liu 2003). This dissertation begins with the inductive research and, by using techniques such as an international survey, literature review, and a case study, answers the research 15 questions i n sect ion 1.5. The research also uses a deductive approach, proposes a system, develops a prototype appl icat ion for the case study that uses the proposed mul t id imens iona l formal iza t ion system, and implements a rapid prototype testing technique to evaluate the funct ional i ty o f the proposed system for the prototype appl icat ion. A s ment ioned above, amongst the techniques used to conduct this research were an international survey that p rov ided speculat ion f rom other experts i n the academy and the industry about the questions o f the research wh i ch w i l l be discussed in Chapter three, a case study that w i l l be br ie f ly expla ined in the next sect ion, and also many in formal interviews that the author conducted w i th construct ion company owners, software company representatives, and other people f rom the construct ion industry dur ing her research. F igure 1.2 shows the depth versus the breadth o f the methods used for the research. The areas o f these methods are the same, however , they di f fer in their breadth and depth. Breadth of Study o a, ft •4 • (Interviews) (Questionnaire) (Case Study) 16 Figure 1.2 The Depth vs Breadth from (Fel lows and Liu 2003) The research also benefited from the author's past working experience in civil engineering design and construction in Iran, her teaching experience in the field of construction management in Canada and the United States, her role as the head of a graduate degree program in construction management at the British Columbia Institute of Technology (BCIT) based at the University of Bath in United Kingdom, her work experience at T R E K at U B C and attending many international and national conferences which exposed her to a wide range of experts in the field from all over the world. Informal discussions with people from the industry and academy helped her conduct the inductive part of the research and reassure about the need for the research. For the purpose of the implementation part, courses were taken from different institutions such as the British Columbia Institute of Technology (BCIT), which helped in the development of the multidimensional formalization system and the prototype for the case study. The author worked as a member of the BC Environmental Group at the UBC where she found a process to illustrate the case for formalized transactions. The next section will explain about this case study. 1.12. Case Study As part of our research techniques, the author did a case study in which a review process used for renovations and new projects at the U B C campus was analyzed. The following provides some background about this case study. The U B C policy for developments on campus had been to assign the design and construction functions to outside companies and to control and monitor these functions through the Campus Planning and Development (CP&D) department. Documentation of the developments was provided by the CP&D project manager for review to numerous different departments at UBC. Notification of the project was sent by email to the relevant departments asking them to review the physical documents in a specified public place. A deadline was announced for comments, and no response implied acceptance of the plans. 17 The department considered in this motivating example was the Transportation Reduction Education and Knowledge (TREK) program centre at UBC. TREK checked the plans to verify i f the strategies that lead to Transportation Demand Management (TDM) objectives had been implemented in the design and construction of the campus developments. The author worked for T R E K as the technical team leader of the BC Environmental Group. Her duties included investigating the plans for compliance with T D M strategies that were recommended in the Strategic Transportation Plan (STP) (STP 2005). During this review process for renovation or new projects, the task of accessing the data (which was needed for the review process) was the main problem. Generally, in A E C / F M projects today, information is represented in the form of unstructured documents that are exchanged in an informal and manual manner, or it resides in human minds and is exchanged through informal communications. Given the complexity and quantity of information and the number of participants in a typical project, the difficulties arising from managing project information flows are evident. Experience shows that a significant amount of project time and resources are spent accessing, searching for, and exchanging information. Inefficient communication of information contributes to project cost and time overruns. It may also cause rework, loss of design intent, the inability to appropriately access and communicate project information in a timely fashion, and reduced quality and productivity. The information flow regarding the process under consideration as the motivating example was not an exception. The process of reviewing was largely unformalized. Although the author had participated in developing an audit checklist for T D M purposes, and it was explicit about what kind of data was needed, the data was not always obtainable from the plans or people involved in the project. Communication of the required data was through face-to-face meetings, phone calls, and time consuming reviews of paper documents. The data could be the number of parking spots in a building which, according to T R E K recommendations, should not exceed certain numbers for different types of buildings. Although AutoCAD was used to draw the plans, paper printouts were used for 18 the review process. Communication of the data from the designer through the plans to the reviewer was interrupted by many barriers. Different locations of the plans, different versions of the plans, outdated and misleading information communicated by different parties, etc. prevented a seamless flow of information from the designer to the reviewer. These communication problems motivated the author to use the review process as a simple but significant example for the implementation of the formalization of a set of related transactions. In an interoperable integrated environment, the data should have been modeled using a common language and also communicated through standard processes. This research focuses on formalizing the processes related to the review process which includes both types of transactions: for information distribution only and request-response type of transactions. It is representative of both types of transactions, so it is representative of general transactions in the industry regardless of the content of the transaction. The research analyzes the review process as it was done by CP&D and proposes a systematic way to formalize the exchange of data using a prototype to implement the formalized transactions. The system of multidimensional formalization will be introduced in the fourth chapter and the business process will be discussed in the fifth chapter. The implementation part of the motivating example will be discussed in the sixth chapter. It is assumed that formalization at the project and company level may lead to the industry-wide standards, because many other computer informal standards were primarily used by a small user group and then were accepted as industry standards. For this reason and also considering the results of the survey and the broad usage of X M L in the computing world, the decision was made to use the X M L . Microsoft .NET was the environment of application development. The prototype system is based on the review process. This process was selected because it had many applications throughout the A E C / F M industry. It is a sample of an information review system that could be implemented in all other fields whenever information must be distributed and reviewed. 19 Implementing the formalization system will accelerate the review process and make sure that technical checks happen in a timely manner. Although there are some common documents in the industry which are more prevalent, such as Requests for Quotes (RFQs) or Requests for Information (RFIs), the decision was made to analyze the review process for T D M purposes to demonstrate the applicability of the proposed system for any use cases that might be less common in the industry. Since the author used this process in the case study it was reasonable to use the same process for developing the prototype system. It is important to remind the reader that the T D M review process does not differ from any other review process. Only the content, sender or receiver, and the other values of the transaction elements are different, it contains all of the elements that any other transaction of the same type (request-response etc.) can have, so it is representative of general transactions of the same type. For this use case, the research analyses both a simple "for information" type of transaction, as well as a more complex "for review" type of transaction that requires a response. The prototype system allows users to initiate the various types of transactions, respond to transactions and track the transactions and responses. In the prototype system, the transactions are initiated and responded to manually by users. In addition to the functionality that the formalization adds to this manual process, it lays the groundwork for future efforts to automate the process using computerized code checking. Interpretation of the content of the message is outside the scope of this research. The potential of automating processes and transactions provides some of the primary motivation to formalize and standardize A E C / F M transactions. The prototype system reads the characteristics of the transaction from an X M L file and creates an appropriate user interface for the transaction so that the user can interact with the application and enter the values that are needed for that specific transaction. This illustrates . the way that applications can use formalized transactions to exchange structured information. Furthermore, the prototype shows that characteristics of the transaction can be altered in real time in response to the information contained in the formalized transaction. 20 Furthermore, the prototype assists with information handling by keeping track of the sent transactions and responses. The way that the prototype configures the structured data content and process characteristics of transactions in real time distinguishes it from ad hoc, unstructured communications such as email. No other application in the industry at present accesses the internet to achieve the characteristics of the transaction for data exchanges. Although the prototype is developed as a proof of concept only (not for practical application), the architecture of the system is worth noting. It serves both as a user of the formalized transactions and also as a document management system. The X M L file itself works both as a data source for the prototype system and also as a document that is comprehensible by humans, with all the capabilities of X M L technologies such as the ability to search for specific information from among the broad range of A E C / F M transactions. 1.13. Reader's Guide This section briefly summarizes each of the chapters of this dissertation. Chapter Two presents the points of departure and summarizes the literature review about standards in the industry or other industries. It discusses three themes: • General computer standards upon which the research builds • Existing standards in A E C / F M • Existing standards in other industries Chapter Three explains previous efforts related to formalization of the data exchanges in the A E C / F M industries as well as electronics industries. It also discusses the elements of communication theory that could be used to define the transactions. Although aspects of this discussion also provide points of departure, they were included in a separate chapter as they are integral to the proposed formalization system for information exchanges. Chapter Four introduces the multidimensional formalization system that could be used to formalize A E C / F M transactions in both human and machine-readable formats. 21 The proposed system can accommodate the numerous complex data exchange scenarios within the scope of this research. Chapter Five applies the proposed approach in relation to a review process of the case study. The process is analyzed "As-Is", and a process is suggested as the "To-Be" process. Chapter Six explains the architecture of the prototype application that implements the transactions discussed in Chapter Five for the motivating example. Chapter Seven presents a summary of the thesis, the contributions of the research, and future research. Additional material related to the research topic is included in the Appendix. Chapter Summary: This chapter described the research questions and hypothesis, research foundations, scope, objectives, challenges, methodology, and reader's guide. 22 Chapter 2: Points of Departure Chapter Abstract: This chapter provides a summary offindings from a review of relevant literature. It discusses three themes: general computer standards, existing standards in the AEC/FM industry, and existing standards in other industries. Computer applications are used widely in different fields and software development has become an important part of many industries. Professional involvement in information systems has become a necessity in the A E C / F M industry. Standards play an important role in the heterogeneous, dynamic and distributed computational environment of today, and many standards have evolved during the past decades. In this chapter, these standards are divided into three categories. The first category is general computer standards that are used widely for the purpose of design and implementation of systems including transaction processing systems and for allowing these systems to collaborate with each other through the Internet. The remaining two categories are the standards in the A E C / F M and standards in other industries. In the A E C / F M industry, there have been many efforts underway to standardize data models, but a broad acceptance of these standards by the industry has not yet happened. In other industries, standards have been developed, such as standards to support supply chain transactions in the electronics industry. Chapter three will discuss the transactions, the elements of communication theory, and how we can use those elements to define the universe of discourse of all A E C / F M transactions. Although some parts of Chapter three could be considered as points of departure, they have been separated into another chapter because of their direct relevance to the proposed system in this dissertation. 2.1. General computer standards Currently, most software development is based on Object-Oriented (OO) techniques. Typical OO software development techniques involve designing the system requirements, 23 processes, objects, and their relationships, in a way that models the real-world area of application for the software. These approaches necessitate acquiring the knowledge about the processes and products of the target industry, which should be determined through collaboration between the computer experts with experts working in that specific industry. This can be achieved through interviews, questionnaires, and software tools, with the result presented in a standard and understandable format. This section reviews several general computer standards that play a role in this process. This includes EXPRESS, which is used to define object models or schemas, and which has been used in some important data standardization efforts in A E C / F M and other industries. The Unified Modeling Language (UML) has been used widely to graphically show different classes of a business domain, and their relationships, roles, activities, sequence of data exchanges, as well as many other important issues that affect the design of a system. It will be discussed in the following sections. X M L which is a standard format for exchanging structured data between applications is being applied extensively to a wide range of software development issues. We will explain X M L and we will also provide an example of a schema in the above mentioned formats. 2.1.1. EXPRESS The EXPRESS language, which is a textual, conceptual, schema language, was developed as part of ISO Standard 10303, STEP, to define standard data models. Parts 11-19 of STEP describe EXPRESS. EXPRESS has also been used by the IAI to define IFCs. Schenck and Wilson (1994) defined "information", "data", and "information models" as follows. Information is "the knowledge of ideas, facts and or processes". Data are "symbols which represent information for processing purposes, based on implicit or explicit interpretation rules". An information model is defined as "a formal description of types of ideas, facts, and processes which together form a model of a portion of interest of the real world and which provides an explicit set of interpretation rules. (If an information model is written in EXPRESS or any other computer sensible representation, it has the additional quality of being computer processible.)" They also state: "Since a model is a representation of something, there are two ways of representing it, by a written language or by a picture. In either case, the representation 24 uses a finite structured collection of predefined symbols which hopefully provide a rich enough vocabulary for stating everything that needs to be said", (Schenck and Wilson 1994). EXPRESS defines schemas that are the structure of the data models. The major elements of EXPRESS are the schema, the type, the entity, and the rule. Some of the characteristics of EXPRESS are as follows: • Expressive language for object-oriented data models • Constructs for schemas, types, entities, attributes, constraints, and rules • Very limited use outside of STEP/IFC communities EXPRESS-G was created in 1990 to graphically display the models written in EXPRESS and is used for human communication. Figures 2.1, 2.2 and 2.3 illustrate, respectively, an EXPRESS schema, an EXPRESS-G representation, and a sample data set written as an STEP Part 21 (Express Physical File Format) file—a project and a related project manager. ENTITY Project; Project Name: STRING; Budget: REAL; Manager: Project Manager; END_ENTITY; ENTITY Project Manager; Last Name: STRING; END_ENTITY Figure 2.1 EXPRESS Listing of a schema for a simple model containing two entities. 25 Project Name Budget Project Manager Project Manager Last Name STRING <X REAL q STRING Figure 2.2 EXPRESS G diagram of a schema for a simple model containing two entities FILE-SCHEMA # 1 = Project (New Forestry Building # 2 = Project Manager ('Jones') ', 20,000,000 , #2) Figure 2.3 ISO STEP Part 21 listing of a sample data set for the schema shown in Figure 2.1 2.1.2. X M L In 1996, the World Wide Web Consortium (W3C 2000) began to design an extensible markup language (Martin et al., 2000). The result, X M L , is a standard that specifies a syntax that allows users to define their own markup language. X M L builds upon ISO's Standard Generalized Markup Language (SGML). The high cost of implementing S G M L and its complexities were some of the reasons that the World Wide Web Consortium (W3C) began to design the X M L . Whereas the Hyper Text Markup Language (HTML) is concerned with how data will look in a web browser (e.g., the information content of a web page marked up with embedded formatting instructions), X M L conveys the structure of the information (e.g., 26 the information content marked up with embedded data structure instructions). This makes X M L well suited to information transfer, particularly between different applications. Typically, the majority of the content of an X M L document is made up of elements. Elements can have attributes and can contain other elements (children). An X M L document should be well-formed and valid: a well-formed document must contain an X M L declaration line and a single root element, be properly nested, and have beginning and closing tags for every element. A well-formed X M L document also has quotation marks around all attributes and is case-sensitive. A valid X M L document is consistent with a set of rules that have been defined for structuring the document. These rules are described by a Document Type Definition (DTD), which is a set of rules that define the structure of the document. A DTD declares the elements, the attributes, how they should be nested, and whether they are optional or required. As an alternative to a DTD, an X M L Schema document can be used to define the structure of the X M L document. An X M L data file can be formatted and viewed through a web browser. This can be done in one of two ways. One method uses a Cascading Style Sheet (CSS), while the other method uses extensible Style Language (XSL). In Chapter four, the use of X M L files will be presented for the purpose of defining and formalizing A E C / F M transactions. As part of this research, a small Java script program has been written that reads both the X M L file and an accompanying X S L file for the purpose of formatting the transaction standard to be displayed in a web browser. XPath is a specification for pinpointing a certain element or defining a pattern into which a number of X M L elements fit. XPath is used with X S L to define the parts of an X M L document that should be matched into parts of the X S L template. Chapter four describes how XPath was used to look into the XML-based transaction standard documents and select specific transaction elements to be displayed in a web browser. Figures 2.4 and 2.5 illustrate an X M L DTD schema definition and a corresponding X M L Dataset, respectively. 27 <!DOCTYPE Project[ <!ELEMENT Project(ProjectName,Budget,ProjectManager)> <!ATTLIST Project id CDATA #IMPLIED> <!ELEMENT ProjectName (#PCDATA)> <!ELEMENT Budget (#PCDATA)> <!ELEMENT ProjectManager (#PCDATA)> <!ELEMENT ProjectManager(LastName)> <!ATTLIST ProjectManager id CDATA#IMPLIED> <!ELEMENT LastName (#PCDATA)> ]> Figure 2.4 DTD Schema definition for a simple model containing two entities <Project id='object 1'> <ProjectName>New Forestry Building</ProjectName> <Budget>20000000</Budget> <ProjectManager>object 2</ProjectManager> </Project> <ProjectManager id='object 2'> <LastName>Jones</LastName> </ProjectManager> Figure 2.5 XML data set for the schema shown in Figure 2.4 2.1.3. Unified Modeling Language U M L The Unified Modeling Language (UML) is a graphical notation and a meta-model that has been accepted by the Object Management Group (OMG) as a standard for documenting the design of computing applications. It is a unified version of the modeling notations that had been developed by Booch, Rumbaugh, and Jacobson (History 2006). The main reason to use a standard modeling language is to enhance communication among the development team. Important concepts can be more clearly shown using graphical notation. Standing at a stage between natural language and software, U M L can represent an acceptable precision in demonstrating design concepts without the need to get into complex details. U M L is not a process. It does not tell the user which notations to use and in what sequence. However, the authors of U M L have also developed the Rational Unified Process, an iterative and incremental development process for software development using U M L . The process has inception, elaboration, construction and transition phases. In the inception phase, the business case, the scope, size, and cost of the software 28 development project should be roughly worked out. In the elaboration phase, different risks, such as requirement risks, technological risks, skills risk and political risks are considered. Different use case models, domain model, class diagrams, activity diagrams, component diagrams, etc. could be used to accomplish this phase. In the construction phase, the system is built through a series of iterations. Each iteration is comprised of design, coding, testing and integration of the use cases related to it. During the transition phase, any bugs should be fixed, adding to the performance of the system (Fowler and Scott 2000). Another development process that can be used in conjunction with U M L is ICONIX, a practical, use-case-driven approach. It has been developed by Rosenberg and Scott (2001). Starting from user requirements, it draws the class diagrams and static model of the system. At this stage, in order to identify the classes, the modeler should lay out as many statements as possible that were identified in the relevant literature, expert's knowledge, and the requirements of the users. Nouns in those statements are good candidates for classes in the system. Next, associations and generalizations of the classes should be determined, and use cases defined. Design-level use cases are sometimes called scenarios. The modeler should write a paragraph or two about each design-level use case. These paragraphs correspond to the content of the user manual of the system. Drawing the Graphical User Interfaces (GUI) can help to explain and write the use cases and check them with the users. Rapid prototyping can be done at this stage to show the proof of concept. In this research, rapid prototyping was used for the implementation of the prototype system. Many diagrams are used in U M L such as class diagrams, object diagrams, sequence diagrams, use case diagrams, etc. Figures 2.6 and 2.7 illustrate the simple model that was previously shown in EXPRESS, EXPRESS-G, and part 21 file format. Project manager Project Manager project Name (String) Budget (Real) Last Name (String) Figure 2.6 UML Class Diagram of a schema for a simple model with two elements. 29 object 1: Project manager object 2 : Project Manager project Name (String) = New Forestry Building Budget (Real) = 20.000,000 Last Name (String) = Jones Figure 2.7 UML Instance Diagram of a data set for the schema shown in Figure 2.4 2.2. A E C / F M standards As mentioned in the first chapter, this dissertation contributes to the field of CIC. Many researchers have conducted studies in the field of CIC in recent years. Standardization efforts in the A E C / F M industry have been focused primarily on defining the objects or the products: the standardization of the processes and transactions has received little attention. The following work illustrates the nature and range of this type of research, followed by the details of the two most significant international efforts. "Credit for developing the world's first interactive computer-aided design (CAD) system belongs to Ivan Sutherland, who in 1963 developed special graphic hardware and a program called 'Sketchpad' as for his Ph.D. dissertation" (Eastman 1999). In the mid-1970s, there were some efforts to develop integrated systems. They were based on a single building model supporting a suite of applications. Most of these efforts were British such as OXSYS C A D , CEDAR, and HARNESS hospital design systems. Another effort was at the University of Michigan in the United States. Their model was called A R C H - M O D E L and also at the Carnegie-Mellon University where three different building modeling systems were developed and tested: BDS, GLIDE, and GLIDE-11. Froese (1995) discussed the models of construction process information and efforts such as the Information/Integration for Construction (ICON) project (Aouad et al. 1994), the General Construction Object Model (GenCOM) (Froese 1992), A T L A S LSE (Tolman, Bakkeren, and Bohms 1994), and Computer Models for the Building Industry in Europe 1 and 2 (COMBINE 1995). Froese et al (1996) explained project modeling in construction applications. The StartPlan system (Yu 1995, Froese and Yu 1994), the project management information 30 control system (Shahid 1996), a construction methods database project (Abouhagar 1995), and a parametric cost estimating system were discussed and the underlying product models were introduced. Russell and Froese (1997) investigated the challenges and developed a vision for Computer Integrated Management Systems specifically for medium-sized contractors. In continuation of the effort to face those challenges, Froese, Rankin, and Y u (1997) proposed TOPS and Y u (2001) defined the TOPS RAF. The TOPS RAF provides a comprehensive, integrated, and flexible environment within which the distributed heterogeneous applications may interoperate. In facility management, Hassanain et al (2000) and Hassanain (2002) describe a data model for integrated maintenance management. Halfawy and Froese (2001) describe the Information Technology for A E C in Canada (ITAC) project, which aims at the implementation of model-based tools in the A E C / F M industry. These research efforts contributed to the implementation of standard data models, which was needed for the realization of CIC strategies. However, their focus was not on the process standards. There remains a need for research to address the gap between formalization of the products and processes. Khanzode and Fischer (2000) analyzed the inefficiencies of a typical steel project due to design change, and showed how the adoption of the CIMSteel integration standard could eliminate those inefficiencies. Kiviniemi (2005) formalized a requirement model specification which can be linked to a building product model based design model of the project. The Confederation of Finnish Construction Industries RT initiated the PRO IT project to define a national data management approach and guidelines for the construction industry. Karstila and Seren (2005) discuss the data exchange use case from the architectural design to structural design through C A D 3D models based on IFCs. They used IDEF0 to demonstrate the process; however, their models are very generic and do not identify different transactions that occur in real-life situations. The data exchange scenario at that generic level could be useful i f the whole model of the building is exchanged in every transaction and it is based on IFC implementation. 31 Cooper et al (1998) discuss research conducted at the University of Salford, in the development of a generic design and construction process protocol. The research compares the construction industry with the new product development process in manufacturing, and believes that the problems the construction industry encounters are due to the lack of consistent processes, and usage of ad hoc methods in the industry. Cooper et al suggest that the industry needs a new way of thinking which results in changing the culture and working practices. The process protocol project developed process maps; however, these process protocols are generic and do not provide a detailed view of the processes. Tommelein (1999) explains about the challenges of today's construction industry and states: " A vocabulary to describe the industry's complexities with its numerous interdependencies and uncertainties is sorely lacking. Fundamental laws have not been articulated." She suggests that lean construction should appear at the top of the list of subjects in the C E & M agenda for research and development. Although the topic of our research is not lean construction, her paper reassures us about the need for an approach to define and formalize A E C transactions. Among the efforts related to standard product models for the A E C / F M industry, two significant efforts have emerged as the most important initiatives, ISO standard 10303 STEP for product data representation and exchange, and IAI. These, along with other efforts such as i fcXML, aecXML and eConstruct, will be described in the following sections. 2.2.1. STEP For several decades, communication of product data in a computer-readable format has been necessary for many engineering enterprises. Both internal and external communications, as well as application-to-application data exchanges, require a computer-readable format for the product data. Product data should be usable throughout the life cycle of the product, which, in the A E C / F M industry, can exceed 30 years or more. The computer applications used at different stages of the life cycle of the product may employ different languages and 32 formats to manipulate the product data. This necessitates that the product data must be represented in a neutral format (Owen 1997). An international effort within ISO has developed standards for representing information about products in various industries. This standard is known as STEP, ISO Standard 10303 for product data representation and exchange. The objective is to provide a neutral mechanism for describing product data independent from any specific system throughout the life cycle of the product. The STEP standard is being developed for domains in many different industries, including building construction. STEP developed EXPRESS as a language to formally represent the models that were to be developed for the exchange of product data. 2.2.2. The International Alliance for Interoperability and Industry Foundation Classes The IAI is a global consortium for architecture, engineering, construction, and facility management that develops data standards for A E C / F M projects called the Industry Foundation Classes (IFCs) (Froese, Yu , 1999). The IFCs form an object-oriented data model made up of many sub-schema and organized into different layers, as shown in Figure 2.8. Domain Inter- ' operability Core Geometry '„ > Geometric . P r M e resource model Topology 1 (Represent."! tCost resource resource § Iresource ' resource Resource Figure 2.8 The Sub-schema that make up the IFC data model 33 The IFCs define how real objects, such as doors, walls, etc. and abstract things such as spaces, processes, etc. should be represented electronically. The IFCs build on results from STEP, and use EXPRESS to define the data model. Since 1995, the IAI has developed five major releases of IFCs (up to release 2X3 in February 2006). Work on new releases continues and the potential for use in the industry is increasing. The current status of the IFCs is that of an emerging standard. "From the point of view of the basic technical ability to exchange A E C / F M information, it can be said that the IFCs have now been established as a viable interoperability technology. Significant portions of the IFCs are now mature, stable standards and numerous prototype and early commercial systems have demonstrated their extensive information exchange capabilities. From other points of view, however, the IFCs are still in a very early stage of development. Only recently have IFC-compatible software applications started to become commercially available." (Froese 2003) These systems mainly support the exchange of object-based C A D models between various C A D software, or the use of these C A D models as inputs to downstream applications such as energy analysis or cost estimating. These applications represent only a small portion of the potential scope of IFC data exchange. As part of the process of developing the product data standards, the developers define common business transactions or scenarios that could use the data standards. Listing these scenarios is out of the scope of this research and the case study will be used to define the scenario for this research. However, these transactions are usually defined in an ad hoc way to support the development processes. In other industries, it has been recognized that it is useful to define the transactions themselves as a standard. The product data standards define the "content" of a transaction; the transaction standards define the "context" of the transaction. To our knowledge, few efforts have previously been made to pave the road for establishing similar standard business transactions within the A E C / F M industry. These few efforts will be discussed in section 3.1. 2.2.3. i fcXML (ifcXML 2005) The IFCs have been developed based on ISO STEP technologies for representing the data model and for exchanging IFC data sets. Meanwhile, interest in using X M L for data 34 exchange has been increasing. aecXML in North America and b c X M L in Europe are two initiatives that try to use X M L for A E C data exchanges. A project within IAI, called the i fcXML extraction and evaluation project, has been underway using the previously achieved consensus on data content within the A E C / F M industry and applying it to XML-based data exchange. Two important use cases of this effort are to enable the exchange of IFC data files as X M L document instances, and to enable the reuse of IFC content and structure within XML-based initiatives for data exchange in Construction and F M industries (Liebich 2001). 2.2.4. aecXML aecXML is an industry-based effort to define XML-based data standards for A E C / F M applications. This effort, which was initiated by Bently systems, is now a part of the IAI organization. aecXML is an XML-based language that is used to represent information about resources or activities in the A E C industry. It is intended to work as a namespace to facilitate the exchange of information over the web. At the moment, their core documents are Use Case Templates that the author assisted in its development and contributed to the aecXML effort, as well as other documents that describe appropriate methodologies. 2.2.5. Building Construction extensible Markup Language bcXML eConstruct is a project that aims at providing Building Construction extensible Markup Language for the European building construction industry. Their primary mission is to improve eCommerce/eBusiness communication in the Building and Construction (BC) Industry. Their strategy is to develop a specification called bcXML that addresses the issue of European multi-language and multi-dictionary aspects. The eConstruct researchers were interested in using X M L because it divides electronic documents into content and markup. eConstruct uses standards that were developed by other initiatives in order to be compatible with those other applications. For example ebXML is one of those standards (which will be discussed in the next section). eConstruct will use the results of ebXML as far as they are applicable to eBusiness in A E C / F M . 35 Many research projects have studied the communication of information in the A E C / F M industry. For example, (Khedro 1995) studied the use of distributed artificial intelligent techniques to facilitate design and construction integration through cooperative network communications; and (Halfawy 1998) studied the agent-based integration of structural design/analysis and construction scheduling of bridge projects. But few studies have addressed the formalization and standardization of the transactions. In the A E C / F M industry, the data dictionaries have been defined by a number of data models, but the other levels of business exchange—specifically transactions and implementations—have not yet been formalized and standardized. The next section is an example of a set of transactions in the field of bidding that uses U M L to illustrate the sequence of those transactions. 2.2.6. Example of a Set of Transactions in the A E C / F M Bidding Process Prior to presenting an approach to the formalization of transactions for A E C / F M , this section outlines an example of a set of A E C / F M transactions in the bidding process. It illustrates how a sequence of common transactions in the industry underlies the entire process of bidding. Bidding is an important stage in the construction industry. In the bidding process, a large amount of information is exchanged and processed between different parties. Owners, architects, contractors, and other participants exchange specifications, drawings, request for bids, award of bids, pre-qualification forms, and other documents. Redundant data and missing documents can result, as the process is based on the exchange of paper-based documents. Such processes can be analyzed and the sequence of activities and data exchanges can be defined as formalized transactions. A U M L sequence model is shown in Figure 2.9. This model may not include all of the transactions involved in the bidding process since there are no on agreed upon process that is used in every case. This model is used only as an example; users may find many more transactions in this field as they probe the processes in greater detail. The roles participating in this model of the bidding process are the owner (or his/her agent), the contractor, the subcontractor, the supplier, and the manufacturer. The process 36 starts when the owner sends an invitation to bid to the contractor and, in response, the contractor sends the owner an acceptance to bid. The owner then sends the notification of the pre-bid conference, as well as the notification of the site visit and the addenda, to the contractor. The contractor sends request for quotes to subcontractors, suppliers, and manufacturers. The subcontractor, supplier, and the manufacturer send their quotes to the contractor. The contractor puts the bid together and sends in the bid. The owner selects the winning bid and sends the notification of the award of the contract to the contractor. Owner Contractor Notification of pre-bid conference Invitation to bid Acceptance to bid Instructions to bidders Notification of site visit Addenda Bid Notification of award of the contract sub RFQ Quote supplier RFQ Quote manufacturer RFQ Quote Figure 2.9 A set of transactions in the field of bidding This example demonstrates a number of possible data exchanges in the bidding process which may differ in detail and in sequence in different situations. The bidding process used in this example is a simplified model of the transactions that happen in the real industry; all of the data exchanges shown in the figure involve the transfer of a well-recognized document such as an RFQ. However, there are many informal data exchanges that happen through meetings and phone calls that have no corresponding documents. To 37 achieve the ultimate goal of computerization of the A E C / F M data exchanges, the industry should be able to define all of these informal communications as well. To computerize the whole process of decision making at the management level, the means should exist that allow for the definition of even informal communications. Although this research contains a case study for a more detailed investigation of a sample transaction which is not related to the bidding process, this example provides a background for the reader to think about the broader picture of the process and the transactions involved. The studies in the past have attempted to demonstrate the whole process and address the sequence of the transactions—we discuss these efforts in this chapter and also in chapter three. In other industries, some initiatives have begun to formalize and standardize their processes. The following sections provide a summary of a few such efforts. 2.3. Standards in other industries In this section we will discuss some of the standards in other industries. 2.3.1. Electronic Data Interchange (EDI) EDI is the inter-company computer-to-computer communication of business transactions in a standard format that allows the receiver to perform a specific transaction (Sokol 1989). Implementation of EDI in a company is costly, due to its specifications for message formats, communication protocols and even some hardware requirements. The cost of the systems needed, the difficult format of the language, and the need for training personnel are some of the barriers to using EDI. Companies usually try to combine it with their proprietary systems and, in general, only big businesses or government agencies have been able to completely implement it. However, in industries such as automobile manufacturing, the number of companies using EDI to support Just-In-Time (JIT) manufacturing has been growing rapidly. Competition in a saturated market could be based, not only on the basis of quality versus price, but also on the ability of the manufacturer to respond to the fluctuations of the market quickly and flexibly. Manufacturing concepts such as JIT or "zero inventory", 38 "lean manufacturing" and "concurrent engineering" are assumed to be useful in time-based competition (Pfeiffer 1992). Existing EDI standards are essentially formatted messages that are transmitted using predefined protocols. The message formats should be shared between different organizations. Each standard message type has a code that identifies the purpose and specifications of the transaction. Different scenarios could occur in business processes that use the messages. It is assumed that any system used for exchanging information should be able to send certain messages, however the format could be different than EDI. Two major public standards provide controls for EDI. One is the American National Standards Institute (ANSI) X12 EDI transmission and control structure which defines three levels of electronic envelopes known as Interchange, functional group, and transaction sets. The other is the United Nations Electronic Data Interchange for Administration, Commerce, and Transport (UN/EDIFACT) which uses headers and trailers controls at the interchange, functional group, and message envelopes. Using EDI messages can entail risks such as access control, data integrity, and transmission security. The use of identification numbers and passwords provide a mechanism for controlling access to a specific mailbox and ensuring that the data will not be disclosed to unauthorized parties. For data integrity, X12 has provided standards for encryption and authentication of the messages (Marcella and Chan 1993). Although many precautions are taken to provide secure communication of data, in reality, public networks can never be completely secure. Therefore, the decision to use such systems depends on how critical the data is, and the anticipated consequences of unintended disclosure. The advantages of using EDI were clearest when a large number of transactions had to be processed through the system. In such a case, the benefits of the system would outweigh its initial implementation costs. In our literature review we found few studies that discuss the usage of EDI in construction-related transactions (EDI 1997) and (EDI 2006). Since the format of EDI has proven to be difficult to implement, we assume that X M L would be a better format for the future standards in A E C / F M . 39 2.3.2. RosettaNet RosettaNet (RosettaNet 2000) is an initiative aimed at developing electronic business interfaces for the electronics industry. RosettaNet builds upon the Internet and X M L to define three layers of standards: Partner Interface Processes (PIPs) formalize the characteristics and requirements for specific transactions between parties; dictionaries define the properties of the products, partners and business transactions; and implementation frameworks specify data exchange implementation details. RosettaNet compares a human-to-human business exchange to a server-to-server business exchange. To build a transaction, humans use their sound and agree on an alphabet to create words. Then they apply grammatical rules to make a dialogue that is conducted through a telephone line to form a business process. In an e-Business transaction, X M L works as the alphabet. The four components of the words, grammar, dialog, and the business process are the gap that RosettaNet is filling to conduct a standardized eBusiness application. Figure 2.10 shows their comparison and where PIPs stand in this comparison, which is equivalent to the dialog. (RosettaNet 2000) Figure 2.10 RosettaNet's comparison The process of developing the PIPs begins with the modeling of the business; the result of the modeling yields the "as is" process. Then, through the business process 40 analysis, re-engineering of the process takes place and the "to be" process is identified. This part should be approved by business people. RosettaNet classifies transactions into segments and clusters. Processes in the supply chain are divided into clusters that are more generic. In each cluster, different segments are identified that relate to more specific processes within the whole cluster. PIPs are defined within the segments. The clusters are as follows: • Cluster 0: RosettaNet Support, • Cluster 1: Partner Product and Service Review, • Cluster 2: Product Information, • Cluster 3: Order Management, • Cluster :4 Inventory Management, • Cluster 5: Marketing Information Management, • Cluster 6: Service and Support, • Cluster 7: Manufacturing. As an example, the segments within one of the clusters, Order Management, are as follows: • Segment 3A: Quote and Order Entry, • Segment 3B: Transportation and Distribution, • Segment 3C: Returns and Finance, • Segment 3D Product Configuration. Within Segment 3C, the PIPs are PIP 3C1: Return Product, and PIP 3C2, Request Financing Approval. Many companies in the field of electronics support the RosettaNet initiative. Global business and the Internet necessitated that those companies define standards that will be used by developers to provide software that works in an interoperable manner with their partner's applications. As stated in section 2.2.6, this initial investment will be offset by the huge number of transactions that will be processed through their applications seamlessly with lower costs. Additional details of the contents of RosettaNet PIP's are given in section 3.2. 41 This research has found that due to the broad range of processes in A E C / F M industries, the clustering format of Rosettanet could not be used as a model for A E C / F M . A E C / F M needs a system which enables clustering of any communication in different stages of the project life cycle. 2.3.3. Electronic Business using the extensible Markup Language Electronic Business using the extensible Markup Language (ebXML 2005) is sponsored by the Organization for the Advancement of Structured Information Standards (OASIS) and the United Nations Center for Trade Facilitation and Electronic Business (UN/CEFACT). ebXML is a set of specifications that enables enterprises to conduct business over the Internet. Companies can use ebXML as a standard method of exchanging business messages, defining and registering business processes and communicating in common terms. OASIS (OASIS 2005) is a non-profit consortium that provides interoperable industry specifications based on X M L or S G M L as well as other standards that are related to structured information processing. OASIS builds upon other standard bodies such as W3C for X M L and ISO for SGML. UN/CEFACT is intended "to improve the ability of business, trade and administrative organizations, from developed, developing and transitional economies, to exchange products and relevant services effectively—and so contribute to the growth of global commerce" (UN/CEFACT 2003). ebXML messaging services, registries and repositories, collaborative protocol profile and implementation, interoperability, and conformance work are conducted within OASIS because of their expertise in X M L , while core components and business process models are conducted within UN/CEFACT because of their expertise in EDI. In May 2001, ebXML delivered their first set of specifications that provide a framework in which EDI's substantial investments in business processes could be preserved in an architecture that uses X M L ' s capabilities. In July 2001, UN/CEFACT created the eBusiness Transition Working Group (eBTWG) to continue the development of X M L standards for electronic businesses based on the first set of deliveries of ebXML. 42 ebXML technical architecture specification v 1.0.4 is a final draft for the eBusiness community (ebXML 2005). This document explains the ebXML system overview. The example scenarios are all commercial scenarios for trading partners in eBusiness transactions. Initiatives in A E C / F M such as eConstruct which focus on ecommerce, can use the result of the work of ebXML as it applies to the eCommerce in A E C / F M . For business practices, ebXML uses the UN/CEFACT Modeling Methodology (UMM) that utilizes U M L . Like RosettaNet, it consists of a business operational view and a functional service view. The ebXML business operational view uses a core library and business library. It addresses the semantics of business data and also the architecture for business transactions. According to the final specification, the core library may be tied to an accepted industry classification scheme or taxonomy. Thus, other efforts can be tied into ebXML in order to produce ebXML-compliant applications. One can assume that the result of ebXML could be applicable to A E C / F M transactions for general eBusiness processes. However, for other transactions such as the information exchanges in other aspects of the industry (design, bidding, etc.), more studies are needed to investigate the practicality of using these specifications. No companies in the field of construction were found among the implementers of ebXML as indicated in their web site. The author did not find any commercial software provider who uses ebXML for transactions in A E C / F M . 2.3.4. eCo(eCo2005) The eCo Framework project focuses on demonstrating the value of the integration of three eCommerce services. These services are semantic integration of multiple database types with multiple data constructs and data libraries, trusted open registries, and agent-mediated buying. The eCo specification is a framework for businesses to discover each other on the Internet and determine how to conduct business with each other (eCo 2005). Chapter Summary: This chapter discussed three themes: general computer standards andformats that may be used to define and implement transaction standards; existing standards in the AEC/FM industry and standards in other industries. 43 Chapter 3: Formalizing Transactions in the AEC/FM Industry Chapter Abstract: This chapter discusses recent research studies relating to formalization of information flows and existing classification systems in the AEC/FM industry, as well as standards usedfor data exchange in the supply chain. Communication and information are important in A E C / F M projects. Many A E C / F M processes, from design, planning and control, to commissioning and operation, are largely information-processing tasks. In the same way that physical construction works with "hard" bricks, management and engineering use information as the "soft" bricks for a building project. Yet communication of information has been a significant problem area in the construction industry for decades. This is due to the fragmented nature of the industry, the significant number of participants in a building project, the open environment in which the building product is produced, and the diversity of the product design. In current practice, communication and information exchange on A E C / F M projects take place through a variety of mechanisms, such as the exchange of design documents or other types of project documents such as field orders or requests for payment; telephone conversations; email messages; faxed forms; etc. Previous efforts to examine information flows in A E C / F M have primarily scrutinized the project documents, their contents, and the roles that project participants enact in exchanging the documents. However, documents are not the only medium for information exchange and an examination of project communication and information flow should not be limited to existing documents. Some common transactions, such as purchase orders, follow a very typical procedure, the format of the information (a typical form-based document) and the information flow are largely standard throughout the industry. Some parts of information exchange, however, is carried out in a fairly ad hoc manner. This ad hoc nature does not cause 44 significant problems when the communication is carried out between two humans (as in a telephone conversation), since humans are easily able to adapt to the circumstances of each transaction and interpret the information being communicated. However, the ad hoc nature of communications does pose problems for Information Technology (IT) solutions, where computing systems are expected to play a role in creating, storing, communicating, receiving, and acting on information. As we explained before, IT solutions (such as CIC) require that project communications and information exchange be formalized, classified, and standardized. As an illustration of the ways in which project communications should be more formalized and less ad hoc, A l Morgan (Morgan 2005) has described in the "The Revay Report" the problems that email communications have created in the industry. He discusses that employees in construction have diverse background, and projects last for short periods of time. Employees often use email as an informal mode of communication. In some cases, employees use their own laptops and the email never gets transferred to the company's computer. Managers may lose control over the messages that are transmitted to the third party. Morgan has suggested that construction companies should have email policies both for the company as a whole and for individual project-related communications. Some of the basic components of such policies are as follows (Morgan 2005): • Standards or criteria for what information may be received electronically • Procedures and standards for verification and authentication of information • Express recognition that email becomes a part of the project records • Standards establishing who is authorized to communicate with outside parties • Procedures to ensure all project-related emails are communicated to all participants • Procedures to preserve project-related emails as a part of the project records • Procedures to ensure that responses or follow-ups are documented These recommendations suggest a more formalized (less ad hoc) approach to project communications—that is, a formalization of transactions. It follows that project communications would be improved by increased formalization, and that these 45 formalized transactions be implemented by both corporate policies and by the software tools used to carry out the communications. However, he does not propose a technical solution other than the email system which needs human interpretation. Although standardization of the content is outside the scope of this research, this research does facilitate the usage of such standards which will result in automation of the whole processes. Other efforts to achieve integration of different applications within A E C / F M have focused on defining data specifications for eCommerce in A E C / F M (such as eConstruct), or on integration at the level of product models (such as aecXML). These efforts address aspects of structuring the content of information exchanges, but they do not provide a systematic approach for A E C / F M data exchange in general. As a minimum requirement to support the computerization of information management, communication transactions should be formalized so that the requirements, type of information content, representation formats, etc. of the transaction are explicitly known. In order to achieve this formalization, a technique for modeling, representing, and working with these transaction formalizations is required. Furthermore, transactions that are frequently repeated should be standardized in some way, so that they are consistent and re-usable from one application to another. In considering the formalization approach for transactions, it is appropriate to recognize that different types of transactions have different scopes of applicability. Some transactions—such as requests for information, invoices, etc.—are very common throughout the A E C / F M industry, and it is appropriate to consider some degree of industry-wide standardization. Other transactions are carried out in a consistent manner throughout all of the companies participating on a specific project, or across all of the projects carried out by a specific company. For example, the project manager of a construction project may establish a specific process for initiating change orders. Finally, an individual worker may formalize transactions relating to their own work to standardize the way that transaction is carried out, possibly with no relation to the way that other people might carry out similar tasks. For example, in order to streamline their own work practices and 46 apply a workflow management system, an individual designer may formalize the way that he or she sends design drawings out for review. Thus, the formalization approach for transactions can be targeted at the industry level, an organization level, a project level, or an individual level, depending upon the context of the transaction involved. The technology for formalizing transactions, as developed in this thesis, is essentially the same across all of these levels, and as such, this thesis contributes to all levels. This is similar to different ways that an organization can establish and implement policies. It could be done from top to bottom or in a participative manner from bottom to top. When formalization has been done, the process of establishing standards within companies involves organizational and corporate strategy issues, while establishing standards across an entire industry involves socio-political or other power related issues. These standardization issues are beyond the scope of this thesis. In the following sections we will explain the previous work in the field of information exchanges in the A E C / F M industry, and we will discuss the international survey that we conducted; the RosettaNet initiative and their Partner Interface Processes (PIP)s; use case modeling; and communication theory. In fact, descriptions of different efforts are the state of the art in the field of formalization of information exchanges, which was the first question of the research. This question is being answered gradually. By studying all those approaches and through inductive approaches, we answer the second question of the research as well. 3.1. Previous Work This section discusses the main key previous studies relating to the formalization of data exchange in A E C / F M that this research was based upon, some of the classification systems that are used in A E C / F M , and a relevant industry-wide standardization effort in the electronics industry. 3.1.1. Information flows in A E C / F M This section describes two previous studies into the information flows that typically exist on A E C / F M projects. 47 3.1.1.1. Shahid and Froese Shahid and Froese (1998) addressed project management information control systems. The authors mapped different types of project information against the documents that deliver that information and the construction management functions that create or use the information (Shahid and Froese 1998). A Project Management Information Control System (PMICS) was developed to allow construction managers to enter and cross-reference various information and use it to monitor and control different views of a construction project. The objective was not to compete with commercially available solutions but to add to the body of knowledge about project information. Using a matrix model, the authors were able to show two or more entities related to project information. The matrices were: personnel versus functions, personnel versus information needs, and document type versus information contents. Although these matrices do not show many aspects of the data exchanges, they are nevertheless very useful for providing insight into who controls a document and which roles are involved in the exchange of the document, etc. Figures 3.1 to 3.3 show parts of the matrices that are used by Shahid and Froese to formalize the information flows. P E R S O N N E L vs. FUNCTIONS MATRIX (M-1) in c o Q. in CD a. Management level: Legends: A= advisory/assist E= Execution C= control responsibility H= hands D= data provisions R=review & analysis Function/Activity 4. E N G I N E E R I N G Quantity Surveying Measure work & payment estimate Prepare/agree valuations Prepare cost/value reconciliation Agree final accounts Safety Implement safety programs on the project Make accident reports Take charge of explosive/blasting safety Administer safety enforcement Top Construction Project Functional H O C O ) O) flj L. CO CO CD c c c CO cu c o o C LU CO •£ 5) -fj & ~ CD cn i_ CD CD c o> CO CO 1 So o> CD c (i> -a CD CD c CD CO : CD <D c 'cn c 2  CO < = ^ <3>C. CD .E C IM '5) ^ c CO .— " CO CD • g E 8 < u J 5 o u j S c t 5 t 3 . c | S « > , § f f l 2 ^ £ c o , 5 ' S ? * l s 3 S . § , . 9 > c r ; . i . t o - 5 £ m C CO . _ . _ p- cf 5 g « « 9 o LU • £ fc! c 2 2 g. P 0) .03 CD 3 o CO c o o 3 Q . O b . o O O < O i Q . D . r i D . o i i J ( 0 < r i O L u . w u . w C H C H c C H E E E E c E E H H Figure 3.1 Personnel vs. Function Matrix (Shahid and Froese, 1998) 48 P E R S O N N E L v s . I N F O R M A T I O N N E E D S M A T R I X ( M - 3 ) CQ T3 d) <D Z £ c C O c o Information Needs Planning A p p r o v a l t i m e f o r s u b m i t t a l s D e l i v e r y t i m e o f a n i t e m T i m e i m p a c t b y c h a n g e o r d e r R e v i s e d c o m p l e t i o n d a t e o f p r o j e c t Site Management L i s t s o f d e f e c t i v e w o r k n o t i c e ( D W N ) D e t a i l s o f d e f e c t i v e w o r k n o t i c e S u b c o n t r a c t o r r e s p o n s i b l e f o r D W N T y p e o f d e f e c t / r e j e c t i o n o f D W N V a l u e o f D W N P u n c h l i s t s a n d d e t a i l e d i t e m l i s t s S u b c o n t r a c t o r r e s p o n s i b l e f o r p u n c h l i s t S t a t u s o f p u n c h l i s t UJ c o O QJ S QJ M— 3 QJ o z e o o. ' o ; 'o , C L QJ C "ra c LU TJ 'o CL QJ 0) c C O c LU CO O o "CD UJ _ O 0 . LO c QJ DJ < DJ C UJ nj o i z; CL 0J 0J c "DJ c LU QJ O i t o dJ QJ c "DJ c LU T3 0J c <D "D c QJ OJ Q . CO Figure 3.2 Personnel vs. Information Needs Matrix (Shahid and Froese, 1998) D O C U M E N T T Y P E v s . I N F O R M A T I O N C O N T E N T S M A T R I X ( M-4) CD a c a> E 3 o o D Information Contents Planning A p p r o v a l t i m e f o r s u b m i t t a l s D e l i v e r y t i m e o f a n i t e m T i m e i m p a c t b y c h a n g e o r d e r s R e v i s e d c o m p l e t i o n d a t e o f p r o j e c t Site Management L i s t o f d e f e c t i v e w o r k n o t i c e ( D W N ) D e t a i l s o f d e f e c t i v e w o r k n o t i c e S u b c o n t r a c t o r r e s p o n s i b l e f o r D W N T y p e o f d e f e c t s / r e j e c t i o n o f D W N V a l u e o f D W N P u n c h l i s t s a n d d e t a i l s i t e m l i s t s S u b r e s p o n s i b l e f o r p u n c h l i s t S t a t u s o f p u n c h l i s t s UJ flj c CO O CQ QJ QJ - C UJ £• CD 13 <z> •g in 01 "O QJ DJ C CD . C O QJ O C QJ "O C o Q. O o o Q. QJ or QJ c73 >. '5 Q o & QJ Q "D QJ 6 CO ~ co ^ 2 OJ "CD •c o CL QJ or DJ O 0 . C O Q . CD DJ O C L O — DJ C UJ UJ UJ CD "_l J Z UJ QJ Dr o Q . c D - O =J QJ JZ C L CC CO t-CD CL CD CL CO o o >. c CD C L E o O Figure 3.3 Document Type vs. Information Contents Matrix (Shahid and Froese, 1998) These matrices show the categorization of a few variables and the relationship of some variables with others in the broad context of processes. Variables such as 49 information content, document type, roles of the people who need information, etc. The summary matrices show how daunting it would be to think of using matrices in case we need to define and categorize even more variables of the process. In fact their research created the question of what method should be used to categorize A E C / F M transactions. 3.1.1.2. Wix and Liebich The second study was done by Wix and Liebich (2001). They developed a set of matrices that have the roles on one axis versus the stage and document type on the other. The role could be the sender or the receiver of information and is shown in the matrix by an "o" or an "x". These matrices are very useful and provide a high-level view of the information flow. Figure 3.4 shows part of their matrices. As shown in this matrix again (as in the previous section) a few variables are categorized to show at what stage information is sent or received. 50 Stage Role Activity c CD E CD CO CD c CO o CD o Notes c CO 'cn cu Q co c X) c cu E cu CO CD c CD c OJ CO CD Q CO oS O 0. 02 O O c go cn CD Q cn CD O ' £ CD CO o T5 CO t_ c o o o CD » c o O • ZJ CO o CD c o O • CO I Z! CO >> "D O CO £> o C L C L ZJ CO CD CO O Conception of Need Background Information Client Data Maps •.„ Site Plans o x 0 X X X X Background information from the client relating to the project o Cartographic authority o Client and site records Lists ) Stakeholder List O X X X X X X X List of people having an interest/involvement in the project Strategy Statement of Need o x x x x x Business Case o x x x x x x x Project type, occupants, occupancy, occupancy standards, processes, actors, conditions, environmental limitations, other factors. The statement of need is periodically updated throughout the project. Standards, Codes and Regulations Applicable Standards and procedures ox ox ox ox ox ox ox Sets down the standards and procedures that are to be adopted throughout the project. Various statements in this regard may be required and these may be updated periodically throughout the project Plans Project Execution Plan Process Execution Plan x o x x x x x o x x x x Briefs Project Brief H Design Brief 0 X X X X X O X X X X X Overall outline of objectives for the project including construction Outline of design requirements for the project including architectural, structural, environmental Approvals Request Approve o o o o o o ox ox ox x x Work submitted and approval requested Approval given to work submitted. If approval is not given, further work needs to be done and resubmitted Figure 3.4 Matrices of information flow (Wix and Liebich, 2001) 51 Both of the above studies provide simple approaches for describing A E C / F M information and information flows and then use these approaches to identify or enumerate key project information. In neither case was this done for the specific purpose of formalizing and standardizing A E C / F M transactions to support IT systems. In comparison, this dissertation proposes a more extensive description and representation for A E C / F M information flows and develops an approach for applying this formalization to support IT systems, but it does not attempt to enumerate all typical project transactions. The next sections describe other studies which are related to the topic of this dissertation. 3.1.1.3. Process Protocol Salford University Latham (1994) and Egan (1998) stated the need for improvement in the construction industry in United Kingdom. They identified fragmentation, poor co-ordination and communication, informal and unstructured learning processes, minimal research and development, adversarial contractual relationships, and lack of customer focus as key inhibitors to the performance of the construction industry. Therefore, the British Airport Authority, British Aerospace and London Underground came up with a common process structure which contributed to the development of Generic Design and Construction Process Protocol (GDCPP). The Process Protocol was undertaken by the University of Salford with seven industrial partners during 1995-1998. Process maps show the sequence of the processes and the Process Protocol Guide explains about the process management, key principles, activity zones, phases, and deliverables. The following are the key principles of the process protocol (Salford University, 1995-1998): • Whole Project View, all of the life of the project should be covered, from recognition of need to operation and maintenance. • Progressive Design Fixity, using the stage-gate approach from manufacturing New Product Development (NPD) processes, a Phase Review Process is adopted to apply a consistent planning and review procedure throughout the project. 52 • A Consistent Process, the consistent application of the Phase Review Process, together with a standard approach to performance measurement, evaluation and control, facilitates a continual improvement in design and construction. • Stakeholder Involvement/Teamwork, a stakeholder view ensures that appropriate participants are consulted earlier in the Process than in a traditional approach. • Co-ordination, Process management is appointed by the client to co-ordinate the participants and activities of each phase. • Feedback, a Legacy Archive aids a process of continual improvement in design and construction. The process protocol provides an insight into the processes of design and construction. It could be used very efficiently to find the sequence of transactions to create a process. Although it does not identify the exact exchanges of information that happen through the transactions in the A E C / F M industry, but it is a roadmap for better usage of transactions by considering the broad picture of the whole processes in the industry. Illustrations of processes help the user understand sequence of the processes. The reader should refer to their web page for more information about their project. The studies mentioned so far have not categorized both the content and context of transactions and their formats could not be used to categorize the broad range of all of the transactions in A E C / F M . 3.1.1.4. Other studies Other studies have been conducted that are related to the processes in A E C / F M industry. At the Georgia Institute of Technology College of Architecture, Jain and Augenbroe (2000) analyzed processes related to electronic product catalogues in the building industry from both sides of supply and demand. eConstruct (2003) is a European project that aims at defining a language called the Building and Construction extensible Markup Language (bcXML) that was discussed in chapter two. 53 Sun and Howard (Sun and Howard 2004) explain a vision for the construction industry's future use of IT which has been developed by the IT Construction Best Practice group and Construct IT with these major themes: • Model driven, as opposed to document driven, information management on projects • Life cycle thinking and seamless transition of information and processes between phases • Use of past knowledge in new developments • Dramatic changes in procurement philosophies as a result of the Internet • Improved communications during all life cycle phases via visualization • Increased opportunities for simulation and "what i f analysis • Increased capabilities for change management and process improvement We believe that our research can contribute to the first three of the above themes directly and indirectly to the others: • By formalization of the transactions, we promote a model driven approach compared to document driven processes which dominates the industry at present. The transition of information between different phases will be streamlined. • Through the formalization of transactions, we create a knowledge base which allows past knowledge to be used in new developments. It promotes reuse of structured information and reduces the need for ad hoc unstructured exchange of information. Another study was done by the Building Centre Trust in U K between 1997 and 1999 about the usage of IT in construction. They found that the prevailing attitude for the development of IT in the organizations was "Let's wait until others have tried it and we'll follow" (Sun and Howard 2004). This is the kind of environment which the author generally found through informal discussions with people from construction industry coming from North America, Africa, Europe, Asia, and Middle East as her coworkers, 54 students, and industry partners through her academic and industry work experience. However, the trend of usage of IT is improving increasingly everywhere. Underwood and Watson (2003) from the Universities of Salford and Leeds in the U K discussed an X M L metadata approach to seamless document exchange. They explain about a three year ESPIRIT project - ProCure - which aimed at taking a significant but achievable step toward the application of Information and Communication Technology (1CT) to the Large Scale Engineering (LSE) construction industry. The project implemented two demonstrators for X M L based automated document exchange between a simulation of a corporate document management system and a simulation of a collaborative construction project web site. Watson and Davoodi (Watson and Davoodi 2002) explain about DocLink (DocLink 2002) generic metadata model and list the DocLink transactions. Leeds University has published DocLink specifications for transactions. DocLink transaction specifications streamlines the transfer of document information from a document management system to an extranet website, however the information that is contained in the document is dealt with as an X M L model. Their project has some similarities to our work in the part of implementations. As we will describe in chapter six, we have also developed a prototype that sends the information from the sender to the receiver through the web. However, our prototype uses the multidimensional formalization system that identifies the type of information which is sent through a specific transaction in A E C / F M industry. These efforts try to send a document which contains model based information. The model based information is an X M L model and the study does not specify what is the content of that model, or in what context that information model is exchanged. The specification explains about sending a document and uploading a document. Although it is used for construction documents, the only difference between such system used for any other industry would be the content of the document which would be in X M L format. The metadata about the document does not identify how the transaction is taking place, at what stage of the project, what are the roles of the sender and receiver in A E C / F M context and it does not illustrate the data exchange as part of the whole 55 processes in the A E C / F M . These specifications are very useful for sending a model based document from the IT department of a corporate to a web extranet system. DocLink metadata is a generic metadata model which consists of group, user, organization, project, set, structure, document, revision, and file, where set and structure relate to documents and group relates to users. Their study has no metadata about the content of each and every document which is uploaded. They consider the content as an X M L model and they send that information by methods such as Post that we have also used in the implementation part of our research. However i f we consider the whole model of a building which is sent through the plans in today's processes, in fact there is no need for each recipient to receive the whole model. Each recipient only needs those parts of the model that are related to his/her expertise for the purpose of approvals, or distribution of information. In this research "What information is needed" has been dealt with in addition to "how it should be exchanged". Since at present there are no formalized processes that could demonstrate who needs what and when, usually the plans are sent to all of the recipients. Even i f those plans are expressed by data models, there is still the need for a systematic identification of what part of the model is needed by whom and this part is missing from all of the studies that we have found in our literature review. In Chapter four message elements will be discussed, which contain the information content of the transaction. The formalization system provides the means to define the content of transactions by using message elements. A l l of these studies contribute to an overall knowledge base in the area of formalized information content and flow within the A E C / F M industry, but none include a comprehensive focus on the specific scope of this dissertation which is to formalize the whole universe of discourse of the information exchanges in the industry. 3.1.2. Classification systems in the A E C / F M industry Different classification systems exist in the construction industry. " A construction information classification system (CICS) provides a common method of improving coordination of information for design, construction, and management" (Kang and 56 Paulson 1997); the Construction Index/Samarbetskommitten for Byggnadsfragor (CI/SfB) has been used in many countries; and, in North America, the M A S T E R F O R M A T (MASTERFORMAT 2005) has been the predominant A E C / F M project information classification system for many years. M A S T E R F O R M A T , developed by the Construction Specification Institute (CSI) and Construction Specifications Canada (CSC), contains 16 divisions that are commonly used in estimating, bids, specification documents, etc. These divisions (as follows) identify and classify common building elements: • Division 0: bidding and contraction requirements • Division 1: general requirements • Division 2: site work • Division 3: concrete • Division 4: masonry • Division 5: metals • Division 6: wood and plastics • Division 7: thermal and moisture protection • Division 8: doors and windows • Division 9: finishes • Division 10: specialties • Division 11: equipment • Division 12: furnishings • Division 13: special construction • Division 14: conveying • Division 15: mechanical • Division 16: electrical UNIFORMAT (UNIFORMAT 2005) is another classification system, which was originally developed by the General Services Administration (GSA) and American Institute of Architects (ALA) in 1972 for estimating and design cost analysis. UNIFORMAT II was first issued in 1973 by A S T M . It was developed by a task group that included GSA, A A C E , the Tri-Services, R. S. Means, CIQS and the others. 57 (UNIFORNAT 2005). It classifies the information into eight first-level items. M A S T E R F O R M A T indicates what the construction item is while UNIFORMAT shows where it is located (MC2 2004): • Section A: substructures, including foundations and basements • Section B: building shell, including superstructure, exterior enclosure, and roofing • Section C: interior, including interior construction, stairs, and interior finishes • Section D: services such as conveying, plumbing, H V A C , fire protection, and electrical • Section E: equipment and furnishing • Section F: special construction and demolition • Section G: site work, including site preparation, site improvements, civil and mechanical utilities, and electrical utilities • Section Z: general, including general requirements and contingencies, and project description. The Overall Construction Classification System "OCCS" (2003), which has been renamed to "OmniClass", is a new classification system that is being developed by a group of volunteer organizations to organize the enormous amount of data created during the life cycle of a building project. A l l of the above classification systems are useful for classifying various aspects of A E C / F M information. M A S T E R F O R M A T is the most common classification system in North America. Estimation software uses M A S T E R F O R M A T to itemize different elements of a building for the purpose of quantity take off and pricing. This classification system is a one-dimensional classification system. For instance, pavement concrete could be placed in either Division 3 (concrete) or Division 2 (site work). A fire pump could be placed in either Division 15 (mechanical) or Division 13 (specialties). For masonry work, the scaffolding could be listed in Division 0 (general conditions) or included in Division 4 (masonry). The reason for the above problem is that, in reality, there are many different aspects of elements that differentiate them from each other and the effort to simplify the 58 classification systems may result in some ambiguities. These classification systems are mostly used to identify different building elements; when we try to formalize transactions we have to consider that they take place between two participants, applications or roles in A E C / F M . So there are many more dimensions that should be considered for the purpose of formalization of transactions. 3.2. Survey In addition to the literature-based studies presented previously, a survey was conducted to collect opinions from international experts in the field of A E C / F M on a range of topics related to the research questions (reported in Froese et al 2001). The survey was conducted in continuation of two other surveys that were conducted five and ten years previously. We received 48 responses from 18 countries. The majority of responses came from Canada, USA, U K and Australia. The survey consisted of different sets of questions in the following categories: "Project Management Environment", "Computing Systems", "Application Areas", "Information and Integration", and "Overall". The first section of the survey asked about the Project Management Environment in the year 2020. Seventy-one percent of the respondents believed that the number, size, and type of companies will not be the same as at present in 2020. Among their reasons for the shift toward larger companies were globalization, increasing complexity and regulation, consolidation, and ninety-four percent believed that new computer technologies will have a positive impact on the market potential/competitive advantage. In the Computing Systems section of the survey, when asked about the type of computers used in 2020, one of the respondents answered: "I think that there will be a definite shift away from computers that try and do too many things. The move is more likely to go toward specialist micros (palm and less) to perform transactional work and very large ones to undertake complex modeling (3d and 4d). Data is also likely to be far more distributed." 59 The third section addressed application areas. The following lists the percentage of respondents who expected each case to be typical in 2020 (respondents could choose more than one case): • applications that are essentially the same-6% • applications that are similar, but with more standardized and widely accepted ways of exchanging information-35% • applications with the ability to exchange all forms of data with other applications on demand-48% • applications that operate on bodies of information that they don't "own" such as project database-48% • "web/server" based systems that users access through generic "browser" type interfaces-69% • programs that are not stand-alone applications, but perform a specific function within an overall integrated system-42% • systems that automatically search the "net" for the needed applications and data-40% • other-4% In the Information and Integration section, when asked how common different data standards would be used in 2020, respondents answered (with the scale of l ivery common, 3= often used, and 5= rarely used) as follows: • Defacto or proprietary industry standards allowing certain programs to exchange data (e.g., .DXF, .WKS)-2.48 • Company-wide standards allowing all applications used by a company to share data-2.72 • Project-wide standards allowing all participants to share data-2.51 • Construction industry-wide standards for related information allowing data sharing between any systems used by any project participant (e.g., ISO-STEP, IAI-IFCs, aecXML, etc.)-1.91 • General purpose inter-industry standards for data sharing (e.g., H T M L , SGML, XML)-1.68 60 • Intelligent software agents that automatically perform the necessary translation when exchanging information-2.26 As we can see from these answers, X M L received the highest value of 1.68. This result is relevant to the solution that is presented in this research. Under the section "Overall", we asked general questions such as: "What is the most important way that information technology will change the way project managers work by 2020?" Sixty-five percent of the 46 responses were related to collaboration, communication, access to information, information sharing, interoperability, and data standards. Considering the open-ended question that we asked, there seemed to be a consensus among the respondents around one broad topic area. We also asked: "What are the most critical areas requiring the industry's attention, research, and development today in order to beneficially shape the future of computing in project management?" From 44 answers, by far the largest number, 48%, were related to information standards and information exchange mechanisms. We believe that this survey contributed to our understanding of the issues addressed by the research questions. It also supported the need for solutions such as those proposed in this research. Although the survey was not specifically designed for the purpose of this research and was conducted in continuation of two previous surveys, it was conducted to achieve the sub objective of: "Trace the trend of CIC in the A E C / F M industry" as stated in section 1.10 of this dissertation. 3.3. R o s e t t a N e t P a r t n e r In te r face Processes ( P I P s ) As mentioned in the second chapter, RosettaNet has developed a set of standards for the processes in the supply chain for the electronic industry. The objectives of the RosettaNet project were found to be very similar to those described in this dissertation, although the approach followed was somewhat different. Some of the features used to define PIPs (several of which have been included in the proposed A E C / F M approach described below) include a business process definition, PIP purpose, a U M L swim lane diagram of the process, start state, end state, partner role 61 description, and activity controls (such as authorization, number of retry count, time to perform, acknowledgement of receipt, and time to acknowledge). RosettaNet has done a thorough job in defining the processes involved in eCommerce and the terms and definitions used in the electronics industry. Similar to ebXML, eConstruct, and other initiatives in eCommerce, then, it provides some of the elements that are useful in addressing the needs of formalizing the transactions in A E C / F M , but does not provide a complete solution. RosettaNet's use of U M L models and XML—as proposed for an A E C / F M solution in this thesis—provides evidence that these are appropriate technologies for formalizing industry transactions. 3.4. Elements of Transactions Based on Communication Theory Our objective is to formalize A E C / F M transactions. To achieve this, the characteristics or elements that make up transactions must be identified and formalized. These elements, then, provide a structured, formalized way of specifying and classifying transactions. There are many characteristics of transactions that could be used as possible candidates as the elements of the formalization approach. This section describes the elements that we have identified. Information exchange is a form of communication. By definition, communication is the sending and receiving of information between team members (Thomas et al. 1998). Communication is a key issue for the success of a project. Thamhain and Wilemon (1986) listed "communicating effectively among task groups" as the third most important factor for the success of a project. In this dissertation, communication theory was examined to better understand the foundations for transactions and to identify the relevant elements that make up a transaction specification. Communication theory identifies a set of elements that make up any communication (as shown in Figure 3.5): the sender, the receiver, the message, the channel, the media, communication barriers and filters, and feed back. Each of these elements is relevant for our specification of A E C / F M transactions and provides a potential basis for classification. Furthermore, for the most part, these elements have not been considered in the previous studies of A E C / F M information exchanges not explicitly nor implicitly (as described previously in this chapter). 62 The exchange of information in the A E C / F M industry occurs at different stages of a project between different participants (sender, receiver), and the data content (the message) of these exchanges could be related to various physical parts of the building as well as to other documents. Formalization of Transactions should be applicable to communications from any channel and using any media. Since the Internet will increasingly be used for carrying out transactions, security issues may provide typical examples of communication barriers and filters. Acknowledgements and responses are examples of feedback elements of the communication. Communication Is based on 1 • r 1 1 1 The sender receiver The message Channels Media Barriers and Filters Feed back Figure 3.5 Elements of communication theory 3.4.1. Document Common Name The documents used in A E C / F M include, but are not limited to, change orders, work orders, budget reports, cost records, productivity records, correspondence, quality control documents, material delivery reports, and bonds, as shown in Figure 3.6. Regardless of their content, the element that we are concerned about in this section is their "name". 63 Change Work Budget Cost orders orders ; reports records Project plan Material Delivery Bonds reports Prequalificatior Reports lawsuits Request for quotes Financial Documents Productivity records Phone calls, talks, emails Minutes of meetings Quality control Documents correspondence Estimates Schedule Lab Results, inspection results Specifications Request for information Change notices Oesign, standards, .manuals. Contracts Bids Site reports, photos Progress Reports Invoices Transmittals and the Drawings Operation or maintenance records Surveys Design sketches' Approvals Figure 3.6 Different documents in AEC/FM. These documents are known to the people working in the industry and they imply the data which makes up the transaction, so it is useful to include the name of the document as a transaction formalization element. It relates to the "message" among the communication elements discussed earlier and it creates better searching capabilities when implementing formalized transactions as discussed in Chapter six. If there is no common name for the transaction, the user may define a name. Since this research uses a repository of formalized transactions that are accessible through the Internet, the naming of the transactions could go through a peer review process as part of the administration of the repository. Implementation of the repository and its administration are outside the scope of this research 3.4.2. Roles Among the roles that send and receive information in A E C / F M are the tradesman, contract administrator, manufacturer, design engineer, facility manager, accountant, 64 owner, building officials, lawyer, bidder, lab engineer, scheduler, supplier, etc., as shown in Figure 3.7. Material Delivery person Bonding1 Agent Tradesman • Contract Administrator Design Engineers Estimating and cost engineer Scheduler Owner Lawyer Financial people Comrrissioning| agent lab engineer or technicians Bidder Building Official Manufacturer Product Representative Supplier Sub Contractor Contractor Safety and quality assurance or control staff Procurement and material, control staff Accounting Construction supervisor Project managei Facility manager Worker Figure 3.7 Different roles in AEC/FM. A sender or receiver is an important element of the data exchange, because it relates to the expertise, authorities and duties of that role for the process in which the transaction is taking place. 3.4.3. Stage of the project The stage of the project in which the transaction occurs is also a relevant characteristic of the transaction. At different stages of a project sensitivity to certain issues changes. In-time responses and security of the information are always appreciated, however during the bidding stage because of the deadlines, and the financial impacts of a more accurate pricing, they take on a more critical role in the success of the bid. Since A E C / F M consists of many different stages, in formalizing a transaction, it is important to identify the stage of the project that the transaction occurs. The data content of a transaction at different stages could be different. In requesting a quote for a construction project, the quote could be asked at different conceptual levels. The owner may submit the number of beds for a hospital and ask for a quote, or submit the square footage of the hospital and the type of framing and ask for a quote. Although this is a hypothetical example (since owners usually do not send a request for quote to a designer for such figures but rather meets with them to discuss this kind of information), 65 still, in our attempt to shift the information exchanges from human-human to computer-computer messaging, we need to define these as transactions. Those "request for quotes" should contain different types of messages contained in them. There are different responsibilities implied in different stages of the project held by different roles. For example, the submission of a change during the design stage may have different liability issues than during the construction stage. The type of security might be different if it is happening during the construction tender and award versus during the project development of a commercial building. The Construction Integration Summit (Construction Integration Summit 2003) identifies the different stages of the life cycle of the project as follows: • Identification • Pre-Design • Design • Bid-Negotiation • Construction • Management • Analysis The Building Projects Practice Manual Task Force (BPPMTF 2001) divides the whole life cycle of a project into the following six different stages: Business Planning • Project Development • Documents for Construction or for Design-Build • Contract Tender and Award • Construction and Contract Administration • Acceptance and Commissioning 66 In our formalization system, we have considered feasibility analysis, programming, schematic design, design development, construction documents, procurement, construction, turnover and startup, operation, and disposal as the stages of the project (Gould and Joyce 2003). 3.4.4. Field of Transaction Transactions can also be grouped according to field, or the nature of the work being carried out. This can serve various purposes, such as allowing a user to identify all of the transactions that pertain to a particular field. Examples of different fields include client requirements, feasibility studies, architectural design, structural design, mechanical and electrical design, estimation, quantity take off, bidding, procurement, safety, quality assurance, accounting, scheduling, equipment maintenance, material delivery, transportation demand management, etc. 3.4.5. Type of Transaction The type of the transaction can be included as a transaction formalization element. Different types of transactions in A E C / F M could be a request response, such as request-for-quote, or a one-way transaction that does not need a response, such as a notification. The transaction type helps determine the way in which a transaction should be handled (e.g., identifying whether a response is required). Among different elements of the communication theory, the feedback is the element that addresses the response from the receiver to the sender of the message. If a transaction needs a response from the receiver then it will be of a request-response type. If it does not need a response from the receiver then it is only for the distribution of information or notification. So type of the transaction indicates if there is the need for a feed back or response from the receiver. 3.4.6. Security The requirements for security of transactions could range from low to high; and this is also a relevant characteristic of transactions. Since the descriptions of transactions should be generally applicable, and security systems may vary throughout time, we do not have to restrict ourselves to specific types of security measures. We believe that at any time, 67 low, medium and high will be understood for the implementation of appropriate security systems. 3.4.7. Data Content of the Message For the most part, the transaction formalization elements listed above describe the transaction itself, rather than the information content of the transaction. By analogy, they are characteristics of a message envelope rather than characteristics of the information contained inside the envelope. In this sense, they can be considered to be metadata of the transaction. While the metadata is important, it is the information content of the message that is the most important element of the transaction. With the data content of transactions, however, we move into the domain of the many other existing A E C / F M data standardization efforts, so we will make no attempt to define new ways of formalizing and standardizing the data content as part of this dissertation. For the transaction data content, then, we would expect a transaction element to refer to appropriate parts of one or more relevant data content standards, such as the IFCs or aecXML. Since the transaction formalization system is decoupled from the data content specification in this way, we have adopted a very simple data content representation for the purpose of illustrating and testing this approach. Here, we treat the data content as a simple list of data values which are assigned specific meaning for each formalized transaction. Although this research is not restricted to use a special data standard and does not intend to define any, the implementation is capable of linking to an X M L file and reading appropriate data values from that file to be used in the transaction. This capability is considered to be part of the overall effort of integrating the product with the process. 3.4.8. Other Elements Other elements could be defined that relate to the methods in which information exchange can happen. These may, for example, relate to the media of the communication. Since we assume that the formalized transactions are independent from the implementation tools, we will not include these characteristics as part of the formalization system for transactions. For instance, we know that we will use the Internet 68 for data exchange in our implementations, but we will not include a "time out" element as part of the formalization system. 3.5. aecXML Use Case Template During the period of work described in this dissertation, the author assisted in the development of a template to be used to structuring use cases in the aecXML project. Later, this use case template was combined with work from an X M L schema development project being carried out by FIATECH, and the result was adopted and used by A S H R A E GPC20 and FIATECH A E X (Automating Equipment Information Exchange (AEX))(FIATECH 2005) and aecXML . " A use case provides an overview of the functional requirements for the application of technology" (aecXML 2005). The components of aecXML use cases are : Use case name, purpose, description, actors, data content, transactions, applications, performance goals, preconditions, begins when, ends when, exceptions, post conditions, references, and open issues. aecXML Use case diagrams include: Use case diagram (UML use case diagram), business process diagram (UML activity diagram), and application example (UML sequence diagram). 3.6. Discussion of the Research Questions Section 3.1 discussed some of the efforts in A E C / F M regarding the formalization of processes. Section 3.2 explained the international survey, section 3.3 looked at RosettaNet PIPs, and section 3.3 reviewed the primary elements of transactions based on communication theory. Section 3.4 explained how the author contributed to a set of requirements for use case modeling in the aecXML project. The previous studies of A E C / F M processes, which used matrices or other approaches to define the information flows, did not address all the elements of communication theory. Thus, to the first question of this research—"What is the state of the art in the field of formalization of transactions in AEC/FM?"—the answer, which was presented in chapters two and three, showed that, although there are some valuable studies in the field of information flows in A E C / F M , most previous work has focused on the information content of transactions and not on the information about the communication process itself. Those few studies in the field of information exchanges have not presented a 69 systematic and inclusive method to formalize all transactions with the necessary communication process details of each transaction. Those approaches cannot cover all of the elements of communication theory to formalize transactions. Efforts to standardize processes in the supply chain were also presented. These standards provide a good model for formalized transactions in A E C / F M , but they are tailored to e-commerce of electronic components and are not applicable to every transaction in A E C / F M . The reason is that typical firms in the A E C / F M industry would generally have fewer IT skills and resources, and thus standards for A E C / F M have a higher requirement for simplicity and ease of use. The other major difference is the numerous categories of transactions in A E C / F M which exist due to the fragmentation of the industry. Furthermore, due to the broad range of transactions in this industry and the uniqueness of each project, it is not possible for all possible transactions to be defined in advance; rather, it should be possible for each participant to be able to define their own transactions. Since the A E C / F M industry is so highly distributed among many small companies, remote construction sites, etc., it is important that solutions for formalized transactions be based on widely available technologies available across all computing platforms (i.e., based on widely adopted Internet standards rather than proprietary solutions). Unlike generic eCommerce, where a few types of transactions are widely used millions of times, A E C / F M involves numerous transactions that may occur only a few times during the project. An approach to categorize these transactions cannot be adapted from other industries. This research aims at contributing to CIC and TOPS which is an ongoing research at UBC. As a requirement of TOPS RAF, the proposed solution for the formalization of transactions should be open, flexible, and modular. Openness, flexibility, and modularity help interoperability among different applications in A E C / F M . 70 The followings are the general challenges of the research and how those challenges were tackled in an inductive way to answer the research questions in the first part of the research: • Fragmentation in the industry To overcome the numerous roles and their information exchanges in the A E C / F M processes, the author discussed communication theory and mapped the elements of communication theory to A E C / F M transactions, she also explained about use case modeling since a transaction is also a process that could be modeled through use case modeling considering the environment of the industry and the knowledge of the people in the field of IT in A E C / F M industry. The literature review gave an insight to what other researchers in this field had done and tried to add to the body of knowledge that they had provided. The case study as mentioned in section 1.12 also contributed to finding out about the problems facing existing information exchanges in the industry and providing guidance as to what to avoid and what to require for a formalization approach. • Environment and level of knowledge about CIC in the industry To get a better understanding of the environment and level of knowledge about CIC in the industry, the author conducted the case study, the international survey, and many informal discussions and observations in Canada, US, Iran and the U K with people from academy and industry. The survey was mentioned in this chapter and the case study will be discussed in detail in Chapter five. The literature also indicated that there is a lag in the usage of IT in construction compared to other fields such as manufacturing. Since the industry is very fragmented and industry practitioners should be able to define and formalize their transactions, inclusion of highly technical 71 elements could result in rejection of the approach by the experts in A E C / F M . Environment of the computing world For the purpose of this research, the author took courses at the British Columbia institute of Technology BCIT and learnt about new technologies available in the computing world. The literature review also played a role in clarifying the history and evolution of the other efforts related to A E C / F M models and standards. Their successes, failures, and evolution show the way that A E C / F M transactions should be formalized Generic approach Since the research considers A E C / F M as a whole, one cannot think about the a formalization approach that is tailored to the needs of separate units in these industries. There is the need to have an integrated view of all of the information exchanges that happen in A E C / F M and take a holistic approach. The following is a summary of the research findings through the literature review, the questionnaire based international survey, case study, and many informal discussions with the experts of A E C / F M from academy and industry in Canada, United States and United Kingdom. The main points of the way that A E C / F M transactions should be formalized are: • Have an easy to learn format. The environment of the industry necessitates such a requirement. Past experiences in other industries with using difficult formats such as EDI teaches the need to use an easy format for such an approach. • Be computer-interpretable Since we aim to contributing to CIC, which promotes the usage of a model based approach throughout the whole life cycle of the building, it would 72 not be enough to define and formalize transactions in a textual format. It must be interpretable by the computer to be used by different computer applications. Allow end users within the industry to define their own transactions As mentioned, due to the fragmentation in the industry, the end users are the people who know exactly what information items are needed to be exchanged and how they should be exchanged. So transactions are best defined by their end users. Have low initial and maintenance costs The experience with EDI showed that the approach should have a low initial and maintenance cost. The Building Centre Trust study within the construction industry showed that the cost of IT systems affects the decision of the organizations about the usage of those systems in their organization (Sun and Howard 2004). Be based on open and widely supported technologies The formalization approach should not be based on scarce technologies. They should be based on open and widely supported technologies for the ease of expanding those approaches in future research and for the purpose of simplicity and lower costs. Accommodate different elements of the communication theory We stated that information exchanges in A E C / F M are not different than any other communication instances. So, they should include the elements of communication theory. We mapped those elements into the A E C / F M context and found the transaction elements for the A E C / F M industries based on communication theory. Allow for openness, flexibility, and modularity For integration purposes it is required that the formalization approach be open, flexible, and modular. In this way, more applications will be able to 73 integrate and work with the formalized transactions with less need for the conversions, wrappers, or mappers in between. • Accommodate the ownership of information Usage of construction hubs on the Internet has created the issue of the ownership of information. In collaboration environments, firms prefer to own their information. It is a preference for companies to own their information and the author anecdotally found that they even prefer to not use a third party. • Allow for different levels of security Security is always desirable, however it is costly too. The approach must be able to accommodate different levels of security. Chapter two and three contained different parts of the answers to the research questions. An inductive approach was used to be able to summarize the author's findings from all the studies, experiences, and feedback that she received in her discussions with other people form the industry and academy. Based on the summary of the ways that transactions should be formalized, and considering the transaction elements, requirements of use-case modeling proposed to aecXML, and RosettaNet PIPs, the next chapter will present a proposed system that is capable of formalizing the broad range of transactions in A E C / F M . The hypothesis of the research is that the proposed system Formalizes A E C / F M transactions in the way that first part of this research suggested. Chapter summary: This chapter discussed recent research relating to formalization of information flows and existing classification systems in the AEC/FM industry, as well as standards usedfor data exchange in the electronics industry. It explained about the transaction elements based on communication theory and a survey. At the end of the chapter the research questions were answered. 74 Chapter 4: Multidimensional Formalization System Chapter Abstract: This chapter introduces the concept of a multidimensional formalization system for transactions in the AEC/FM industry using XML technology. It also identifies the advantages of the system and discusses the research hypothesis. Finally, it addresses the role of formalized transactions relative to the other elements of computer-based project activities. Chapters two and three addressed the first part of the research and answered the research questions. Section 3.6 summarized the ways that A E C / F M transactions should be formalized. It was based on communication theory, on the approaches used by standardization initiatives in the A E C / F M and supply chain, and on the environment and culture of the building and infrastructure projects. This chapter presents an approach for formalizing transactions and representing the formalized transactions. This approach is called a "multidimensional formalization system". This name was selected because, as will be shown in this chapter, it uses several different elements of information exchange (i.e. multiple dimensions) to formalize the structure of transactions. The word 'system' was used because it consists of pieces of code—XML and X S L files—that can accept an input and produce an output by making some conversions in between. There are different levels of formalization of the data exchanges that could be considered by different studies. A study can consider a transaction at the level of sending some information from an application to a server, which is the way that financial transactions or ecommerce transactions are dealt with. These transactions are specific to electronic exchanges of information. The scope of our study is much broader than these transactions. We believe that a system is needed to formalize all of the information exchanges in the A E C / F M process to streamline their computerization. Although it might seem 75 ambitious, the difference between using matrices and the X M L format is due to considering "all" of transactions. Since at present such a system does not exist, big chunks of information have been sent over to different participants because usually the sender of the information does not know what information is needed at what stage by whom. Even when using model based approaches, no studies have addressed which partial data sets are needed for different data exchanges. The intention is to send the whole model, or parts of the model which exists in a document, over to a receiver. Few studies have been conducted to ask the question of when what should be sent by whom to whom. Those studies use tables, graphs or matrices to structure the whole range of information flows in the industry. A formalization system that takes the form of a simple listing of transactions would classify the transactions on the basis of a single dimension only, while a simple matrix approach would probably use two different dimensions. We have found such approaches to be limiting, since there are not one or two dimensions that are of primary importance, but rather several dimensions that may be combined in different ways for different situations. A diagram or matrix cannot simultaneously show many different dimensions of transactions. Formalization of the transactions based on different dimensions requires a mechanism that can incorporate as many dimensions for each transaction as is needed. Our goal is to create a formalization system that is multidimensional in order to enable it to include all the necessary combinations of dimensions. This would be difficult or impossible to achieve using a limited two-dimensional "paper-space" representation. This chapter will present a structure for representing the formalized transactions. Specifically, it presents a data representation scheme for specifications of different kinds of transactions. Current information representation technologies readily enable a multidimensional approach. The proposed formalization system uses X M L technology for this purpose as described in the following sections. In this way, the dimensions used to describe transactions can be manipulated to create a variety of views that serve the needs of a formalization system for transactions. Using databases could be another option, however there are some advantages that make this system a better choice for 76 A E C / F M processes, as will be discussed later. This chapter aims to show that X M L provides an effective representation scheme. An important feature of this representation scheme is that it allows collections of transaction specifications to be organized according to a variety of different dimensions. The multidimensional formalization system serves the need for formalizing the transactions based on many dimensions and also the need for representation of those transactions. If we define a transaction in a review process for the purpose of sustainable planning as in our case study, and we call it "Request for Comment", in fact we have not created an instance of that transaction. We have only described the necessary dimensions of that kind of transaction in general. Now if we actually create an instance of the "Request for Comment" type of transaction, in accordance with the defined dimensions, and transfer the data content of that individual transaction between two real people who are working on a real project, we can claim that we have created a real transaction based on our multidimensional formalization system. If we define many kinds of transactions, we should be able to find a certain kind of transaction, such as the request for comment, to create an instance of it in a real situation. We need to be able to represent those defined multidimensional transactions for a human or computer transaction creator. Our proposed multidimensional formalization system uses X M L technology that enables the system to formalize transactions in the ways suggested in Chapter three. The broad range of transactions in A E C / F M necessitates a representation system that is easy to use and can handle the combination of dimensions that the user might be interested in finding as a suitable transaction for his or her purpose. The dimensions themselves satisfy the elements of communication theory and the system is capable of defining the kinds of transactions considering those elements that were not covered in previous research studies. We did not follow on exactly from other initiatives because the environment of A E C / F M is not the same as the eCommerce or the computer and electronics industry; however, we tried to consider some dimensions that we did not include in the previous chapter. 77 In Chapter three we made a parallel between the A E C / F M industry and the communication theory regarding the elements of transactions. In this chapter we add some dimensions to those elements to be more adaptable with use case modeling and computer modeling techniques, since we are gradually going to shift from the real A E C / F M world to the computer model of the industry. 4.1. Multidimensional Formalization System In this section a multidimensional formalization system is proposed and the hypothesis of the research is to demonstrate that it formalizes transactions in the way that the first part of research suggested. Using a prototype application, the research will demonstrate the functionality of the formalized transactions in data exchanges between different roles of the process explained in the case study. The dimensions that we believe should be incorporated into our formalization system are not only important in defining each individual transaction, but also in searching for transactions when many of these transactions have been defined and formalized through the formalization system. These dimensions include: name, definition, project state, transaction type, transaction field, purpose, start state, end state, sender role, receiver role, graphic U M L models (to better demonstrate the flow of information and the process), response time, security, acknowledgement, and message elements. A table of dimensions and their definitions is in appendix A.3. Some of these dimensions were mentioned in Chapter three as the transaction elements such as the sender or receiver; some of them are related to the A E C / F M such as the project stage and project field and do not exist in the general supply chain domain. PIPs of the RosettaNet include the U M L models of the process which is helpful in understanding the transaction. The first dimension is the name of the transaction. It is important to have a name for the transaction as it will help both parties. It also specifies the kind of transaction, such as a request for comment or notification of the project. The second dimension is the definition of the transaction which has a documentation role. It explains about the transaction and helps the user get a better idea about the transaction. 78 The third dimension is the project stage. For A E C / F M transactions this is an important dimension, because in different stages of the project, such as design or construction, characteristics of transactions could be different. For example, a quote may need high security for the pre-contract stage of the project, while during construction the security could be defined as medium. Transaction type relates to the need for feedback. A transaction may only have the role of disseminating information such as the notification of the project in our case study. It may need a response such as the request for comment. It is important to know about this dimension to follow up with the responses. Transaction field describes the work process to which the transaction contributes (thus providing a subject area for the transaction within construction management). Fields such as "bidding" may have certain requirements. Due to the broad range of transactions, the transaction field should be included in these dimensions as it will help to get a better understanding of the transaction. Different working environments depend on the field of transaction and the "How To's" regarding sending and receiving the transaction will be affected by this dimension. The purpose of the transaction is important in order to define and formalize the transaction, and the start and end state of the transaction helps to define consecutive transactions which could be used for work flow applications in future researches. We talked about the sender and receiver roles in Chapter three based on communication theory. We also looked at different roles that exist in A E C / F M , that make a difference between this industry and the supply chain where the roles are very limited, usually to buyer and seller. As mentioned before, to illustrate the process it is useful to have a graphic U M L model of the process. Although it might look difficult to include this in the dimensions of the formalization system, we will use a Universal Resource Locator (URL) to enable us to find the address on the web where we stored the models of each particular transaction. Response time is only needed for those transactions that need a response. Depending on the type and stage of the transaction the response time could be different. 79 Security could be high, medium, or low. We will not specify the technology required for each of those levels. As computer technology improvements regarding security has a fast pace, at any time, depending on the available technologies, a suitable security system should be selected for low, medium, and high security requirements. For documentation purposes, especially in A E C / F M with a high level of legal claims during and after the projects, it is important to identify whether or not the transaction needs an acknowledgement. An acknowledgement is different than a response. A transaction that is "for information only" may need acknowledgement to confirm the date and time of receipt. We have also included the 'message' field so as to include the information content of the transaction as stated in communication theory. The message is the core part of each transaction. For a transaction we can identify the message elements of the transaction but not the values for those elements. When we create an instance of a transaction we enter a value for each of the message elements that we had identified in our formalization system for the message of that transaction. The author considered the number of message elements to be up to 20. This number was used due to usual forms that are already used in the industry, however, changing this number is possible and it could definitely change. These correspond to the data items that, at the moment, may be written on a common document such as an invitation to bid. For the case study process not all of those 20 elements were used. The collection of transaction dimensions provides a structured description of each kind of transaction and captures the main characteristics identified as being important for formalizing a transaction in order to computerize the processing of transactions. Based on the dimensions discussed above, an X M L document will be used to formalize transactions. This section describes the X M L document that formalizes a transaction along with the document schema specified as a Document Type Definition (DTD) document. Later sections will describe components for creating human-readable presentations of the formalized transactions via an X S L file, and a script for translating the X M L document into H T M L for display on a web server. 80 As mentioned in Chapter two, a DTD is used to show the structure (schema) of a document. An X M L document is then structured according to, and can be validated against, the DTD. A DTD can be created and modified using a specialty X M L authoring tool, or a simple text editor or word processing program. A proposed DTD listing for a formalized transaction is shown in Figure 4.1: 81 <!DOCTYPE transactions [ <!ELEMENT transactions (transaction*)> <!ELEMENT transaction ( name, definition, project_stage, transaction_type, transaction_field, purpose, start_state, end_state, sender_role, receiver_role, transaction_UMLmodels_URL, response_time, security, acknowledgement, message_element1, message_element2, message_element3, message_element4, message_element5, message_element6, message_element7, message_element8, message_element9, message_element10, message_element11, message_element12, message_element13, message_element14, message_element15, message_element16, message_element17, message_element18, message_element19, message_element20)> <!ELEMENT name (#PCDATA)> <!ELEMENT definition (#PCDATA)> <!ELEMENT project_stage (#PCDATA)> <!ELEMENT transactionjype (#PCDATA)> <!ELEMENT transactionjield (#PCDATA)> <!ELEMENT purpose (#PCDATA)> <!ELEMENT start_state (#PCDATA)> <!ELEMENT end_state (#PCDATA)> <!ELEMENT sender_role (#PCDATA)> <!ELEMENT receiver_role (#PCDATA)> <!ELEMENT transaction_UMLmodels_URL (#PCDATA)> <!ELEMENT responsejime (#PCDATA)> <!ELEMENT security (#PCDATA)> <!ELEMENT acknowledgement (#PCDATA)> <!ELEMENT message_element1 (#PCDATA)> <!ELEMENT message_element2 (#PCDATA)> <!ELEMENT message_element3 (#PCDATA)> <!ELEMENT message_element4 (#PCDATA)> <!ELEMENT message_element5 (#PCDATA)> <!ELEMENT message_element6 (#PCDATA)> <!ELEMENT message_element7 (#PCDATA)> <!ELEMENT message_element8 (#PCDATA)> <!ELEMENT message_element9 (#PCDATA)> <!ELEMENT message_element10 (#PCDATA)> <!ELEMENT message_element11 (#PCDATA)> <!ELEMENT message_element12 (#PCDATA)> <!ELEMENT message_element13 (#PCDATA)> <!ELEMENT message_element14 (#PCDATA)> <!ELEMENT message_element15 (#PCDATA)> <!ELEMENT message_element16 (#PCDATA)> <!ELEMENT message_element17 (#PCDATA)> <!ELEMENT message_element18 (#PCDATA)> <!ELEMENT message_element19 (#PCDATA)> <!ELEMENT message_element20 (#PCDATA)> ]> Figure 4.1 Document Type Definition (DTD) Based on the above DTD, we can create an X M L document that contains all the formalized transactions. An example of a formalized transaction from our case study is shown in Figure 4.2: 82 transaction > <name>notification of the project</name> <definition>This transaction is used whenever the project manager wants to notify the transportation department about a project( new or renovation)</definition> <project_stage>design</project_stage> <transaction_type>notification</transaction_type> <transaction_field>transportation_Demand_Management </transaction_field> <purpose>to notify transportation department about a project</purpose> <start_state>When the architect has sent the plans to the project manager</start_state> <end_state>When an acknowledgement is received </end_state> <sender_role>project manager</sender_role> <receiver_role>transportation department</receiver_role> <transaction_UMLmodels_URL>http://www.construction.ubc.ca/ transactions/notification</transaction_UMLmodels_URL> <response_time></response_time> <security>low</security> <acknowledgement>yes</acknowledgement> <message_element1 >project name</message_element1 > <message_element2>project address</message_element2> <message_element3>architect</message_element3> <message_element4>architect contact</message_element4> <message_element5>future user department</message_element5> <message_element6>future user department contact</message_element6> <message_element7></message_element7> <message_element8></message_element8> <message_element9></message_element9> <message_element10></message_element10> <message_element11 ></message_element11 > <message_element12></message_element12> <message_element13></message_element13> <message_element14></message_element14> <message_element15></message_element15> <message_element16></message_element16> <message_element17></message_element17> <message_element18></message_element18> <message_element19></message_element19> <message_element20></message_element20> </transaction> Figure 4.2 XML document of "notification of the project" transaction Another example is shown in Figure 4.3: 83 transaction > <name>request for comment</name> <definition>This transaction is used whenever the project manager asks Transportation department for their comment about a project </definition> <project_stage>design</project_stage> <transaction_type>requestResponse</transaction_type> <transaction_field>transportation_Demand_Management</transaction_field> <purpose>to get back the comment of the transportation department about the project in regard to Transportation Demand Management requirements </purpose> <start_state>when the notification of project has been sent</start_state> <end_state>when the comment is received by the project manager</end_state> <sender_role>project manager</sender_role> <receiver_role>transportation department</receiver_role> <transaction_UMLmodels_URL>http://www.construction.ubc.ca/ transactions_UML_models/request for comment </transaction_UMLmodels_URI_> <response_time>2</response_time> <security>low</security> <acknowledgement>yes</acknowledgement> <message_element1 >project name</message_element1 > <message_element2>project address</message_element2> <message_element3>number of residency units</message_element3> <message_element4>building type</message_element4> <message_element5>number of visitor parking units</message_element5> <message_element6></message_element6> <message_element7></message_element7> <message_element8></message_element8> <message_element9></message_element9> <message_element10></message_element10> <message_element11 ></message_element11 > <message_element12></message_element12> <message_element13></message_element13> <message_element14></message_element14> <message_element15></message_element15> <message_element16></message_element16> <message_element17></message_element17> <message_element18></message_element18> <message_element19></message_element19> <message_element20></message_element20> </transaction> Figure 4.3 XML document of "request for comment" transaction Due to the broad range of transactions in A E C / F M , as discussed before, there will be many transactions contained in the final X M L document that will be posted on the web and administered by a committee for peer reviews. There needs to be a system to find each formalized transaction for the user. The transactions shown above are represented in the machine-interpretable X M L language. Although it is possible for humans to read and understand these X M L 84 documents, it is not a convenient fo rm for people to w o r k w i th . F o r a more human-appropriate representation, the X M L documents can be readi ly converted us ing X S L . F o r example , an X S L file can be def ined to map the in format ion contained i n the X M L file into a suitable H T M L representation that can be rendered in any web browser. A s imple vers ion o f such an X S L file is shown in F igure 4.4: <?xml version="1.0" encoding="ISO-8859-1"?> <xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform"> <xsl:template match="/"> <html> <body> <table border="4" > <tr bgcolor="yellow"> <th>name</th> <th>sender_role</th> <th>receiver_role</th> <th>project_stage</th> <th>start_state</th> <th>end_state</th> <th>response_time</th> <th>security</th> <th>message_element1 </th> <th>message_element2</th> <th>message_element3</th> <th>message_element4</th> </tr> <xsl:for-each select="transactions/transaction"> <xsl:if test= , ,transaction_field='transportation_Demand_Management'"> <tr bgcolor="yellow"> <td><xsl:value-of select="name7></td> <td><xsl:value-of select="sender_role"/></td> <td><xsl:value-of select="receiver_role"/></td> <td><xsl:value-of select="project_stage'7></td> <td><xsl:value-of select="start_state"/></td> <td><xsl:value-of select-'end_state7></td> <td><xsl:value-of select="response_time7></td> <td><xsl:value-of select="security7></td> <td><xsl:value-of select="message_element17></td> <td><xsl:value-of select="message_element27></td> <td><xsl:value-of select="message_element37></td> <td><xsl:value-of select="message_element47></td> </tr> </xsl:if> </xsl:for-each> </table> </body> </html> </xsl:template> </xsl:stylesheet> Figure 4.4 A simple version of an XSL file 85 Various techniques can be used to apply the X S L file to the X M L document. Figure 4.5 shows a brief script that can be included within an ASP file on a web server (Microsoft Internet Information Server) to read an X M L file named transaction.xml, apply an X S L transformation from a file called transaction.xsl, and return the resulting H T M L to the client's web browser. The resulting web page is shown in Figures 4.6 and 4.7. <% set xml=Server.Createobject("Microsoft.XMLDOM") xml.async=false xml.load(Server.MapPath("transaction.xml")) set xsl=Server.Createobject("Microsoft.XMLDOM") xsl.async=false xsl.load(Server.MapPath("transaction.xsl")) Response. Write(xml.transformNode(xsl)) %> Figure 4.5 Script within an ASP file 86 '31 http://localhost/lransdctton.asp - Microsnfl Internet Implore 'illy-', j i i J M E ' ^ g J g P He Edit View Favorites Tools • Help. •: - ^ 5^ ; _ ^  • I ' " ' " j s ' f ^ }~11 [ SJqn l^n j <3> My Yahoo! Vohooj Ma< -ii " £2 i request for project-: i (comment manager: :; [department:-: idesign::: • :.icomment is • . of project: | •:• : ,•, • • • . i2 . :, -: • • ireceived by the • has been : > •- -[project manager ; nonScahon of the project project manager transportation department 'design::: When the architect has sent the: plans to the project manager.:. When an • • acknowledgement. is received . .: . low .. project name tow project n project address nui ^project address ?are •gjDone " . * „ J [ 11 jji L k *JI Local rtranet Figure 4.6 A screen capture of the sample transaction converted via the sample XSL :'Rle. .Ed* View Favorites Tods Help 1 " .j-dcirfis.?^ ) http://toe a host/transaction, asp ^^ :i^ ;,^ llll„IIIIZIIIIIIln I SearchijT] |.| Son Ini) My YahooI E 3 Vohool ftoi .- |Vj Ganwsj; i '^^""^'; ' ' ; ' '"' '^ v j Q Go ir>-:: ,when the . , — ...... :•:•[:•:•:•' iwhen the .: notification J I '• • . .•.'[•'•••.:•:•:•'.:• . comment IS:::,-:' • d " « " l»f project ! r e „ i v e d b ^ has been t i . i::-. ....sproject manager. ; iscnt j I .When the j 'architect L , „ i 1 , , [When.an .:>•:::::: - has sent the , . . d^esign , , (acknowledgement:. plans to the * . :is received :•: project • manager | '.slow.'.'.. . .project name . 'low 'project n .iiproject address • number of units . : bud ding type xiproject address •• .[architect -^ architect contact jg^Dcyie In i,l 11 | i 1 11 | 1 |" "| 1 1 1 *J Local intranet 1 ure 4.7 A screen capture of the sample transaction converted via the sample XSL file (continued) Figures 4.6 and 4.7 show only transactions relating to the transportation demand management field. This is caused by the conditional " X S L : i f ' statement with the test 87 "transaction_field='transportation_Demand_Managernent' " in the X S L file, which restricts this particular output to show only transportation demand management specifications. The X S L file shown previously in Figure 4.4 is modified below (Figure 4.8) to present different H T M L representations of the transactions shown in Figures 4.6 and 4.7. In this X S L file (transactionl.xsl), the user has chosen to list only those transactions that are a type of request response (unlike the previous case in which the user was interested in all the transactions that relate to the field of transportation demand management). <?xml version="1.0" encoding="ISO-8859-1"?> <xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform"> <xsl:template match=7"> <html> <body> <table border="4" > <tr bgcolor="yellow"> <th>name</th> <th>sender_role</th> <th>receiver_role</th> <th>project_stage</th> <th>start_state</th> <th>end_state</th> <th>response_time</th> <th>security</th> <th>message_element1 </th> <th>message_element2</th> <th>message_element3</th> <th>message_element4</th> </tr> <xsl:for-each select="transactions/transaction"> <xsl:if test="transaction_type='requestResponse'"> <tr bgcolor="yellow"> <td><xsl:value-of select="name'7></td> <td><xsl:value-of select="sender_role"/></td> <td><xsl:value-of select="receiver_role'7></td> <td><xsl:value-of select="project_stage'7></td> <td><xsl:value-of select="start_state7></td> <td><xsl:value-of select="end_state'7></td> <td><xsl:value-of select="response_time7></td> <td><xsl:value-of select="security'7></td> <td><xsl:value-of select="message_element17></td> <td><xsl:value-of select="message_element27></td> <td><xsl:value-of select="message_element37></td> <td><xsl:value-of select="message_element47></td> </tr> </xsl:if> </xsl:for-each> 88 </table> </body> </html> </xsl:template> </xsl:stylesheet> Figure 4.8 Modified XLS file The formalized transaction X M L file is the same as for the previous case (Figure 4.3) but the X S L file has changed based on the user's preferences. The corresponding server-side script would appear as follows. <% set xml=Server.Createobject("Microsoft.XMLDOM") xml.async=false xml.load(Server.MapPath("transaction.xrnr')) set xsl=Server.Createobject("Microsoft.XMLDOM") xsl.async=false xsl.load(Server.MapPath("transaction1.xsl")) Response.Write(xrnl.transformNode(xsl)) %> Figure 4.9 Modified script within an ASP file As shown in Figures 4.10 and 4.11, only the transaction of the type "request response" is given. 89 ' 3 ; h M | i / / l o r i l l u t f / l r ^ m n l i o n l n\i I r i i i n I I x p l o n i I n v i t l i i l l i y SI I A W I r i f i ' n u ' l :XFlta-i:.:.Ecfe:;!Vlew:-:- Favorita* : : Tools Neb ;:Adi)r««.-. http:/localhostArensact.ion: ^ SearchWeb | - | New Toolbar Updatoi^ | 'Q **»^^0 My^Yahooi & Garnws- Pursonals - t)> » E l FMwice^  fCj> Sign In j - [|| project transportation m^anager {department design::: st . -nt^.ttMp i>ii(l^sTari> i i o - t j i o i i - i e ^ n i n e s e t i u m 1 m e s s a j e c - l t :;!:•:-:•:•:•:•--:•:•::.:: : [when the:>! when the j ^notification:: . • j • lis received; 'ofproject ' h . . b « n l.ent i"™-"" •| •::.:•:•• • •• manager • n<»iktl i i r > ( * . « s . i g e _ p l « " i n p i i t 2 u n p s s n j c jproject address {number of u ?KJS&r-$;ii>J Local Intranet(Kfess&iHSS Figure 4.10 A screen capture of the sample transaction converted via the sample XSL file transaction!.asp IE] Finance - jjTj- Sign In | » m»ff*_* l* i in*i i« , l m e . 5 S f t g * _ * l e i n e t i T 2 i u « K . « n ; e _ v l e i n v u f ^ n \ * s s mj*_*l*m»iit-4 i^of project :isent •  iby the [project' jmana^ er. • low • ... -project name project address number of u ; building type Jgt} Dcna < - - 1 i , \^ Local mtronot Figure 4.11 A screen capture of the sample transaction converted via the sample XSL file transaction!.asp (continued) In the next section we will discuss the research hypothesis. 90 4.2. A Discussion about the Research Hypothesis In the previous section the multidimensional formalization system was introduced. As stated in chapter one, the hypothesis of the research was that the proposed system formalizes transactions in the way that research suggested in the first part. The dimensions used for the proposed system were based on communication theory, PIP's of the RosettaNet and, the use case modeling approaches (such as the graphical U M L models, or the purpose of the transaction, start state and end state). Since there is a trade-off between the sophistication of the dimensions of the system and its ease of use regarding the level of computing knowledge of the people in the A E C / F M industry, including some issues such as exception handling, etc., does not fit the requirement of the approach as specified in chapter three. Environment of the industry does not allow for such technical descriptions at present. The author believes that the level of sophistication of the proposed system is suitable for the A E C / F M and if there is a need for more dimensions to be included in the system, the system could be modified later while in use by the people in the industry. At present, adding formalized transactions needs the manual addition of an X M L document. However, it is possible for the future studies to develop a user interface which could be posted on the web that allows for new entries or changes in the representations of the formalized transactions. This research suggests that a repository of transactions should be created on the web. Anyone from the industry should be able to define transactions, however those transactions should go through a peer review process and then posted on the web. Since our approach could be dominating the industry in a bottom-up direction, meaning that people will write their transactions themselves rather than an initiative to write transactions for them, we believe that another requirement of the research has been met by the system. Our approach makes it possible for different users to define their transactions and to find transactions that are somehow similar or close to their transactions. This will benefit 91 the industry since best practices will be disseminated through the formalized transactions and it could be used as a resource to learn about the industry processes. Since the system uses X M L , which is an open standard, it allows many applications to use it as a source of information. It will help develop flexible and modular applications in different fields of A E C / F M that can access the transactions and use them for their data exchanges. So it satisfies the TOPS RAF requirements of openness, flexibility, and modularity. We have found X M L to be a useful format for formalizing transactions. It provides a way of formalizing transactions in A E C / F M that corresponds to the way that natural language would be used to define a data exchange process. The X M L format has the advantage of being a computer-readable format already broadly accepted as the common language for data exchange through the Internet. In Chapter three we discussed the research questions and, after studying other standardization initiatives' history and preferences, decided on X M L as the format of choice for our approach. In order to formalize a transaction using X M L , each transaction dimension becomes an element within the X M L document that describes the transaction. These formalized transactions become the basis for the computerization of the processes within A E C / F M according to the CIC strategies. If transactions are formalized using this system, they can be implemented and used by various users, and could evolve into industry standards. We have defined some example formalized transactions using the proposed system and will demonstrate the implementation of these transactions through a prototype system described in Chapter six. The formalization of A E C / F M transactions is not limited to the exchange of the information contained in documents already used in the industry; the proposed system can accommodate all forms of data exchange that take place within A E C / F M processes. To make sure that our proposed system formalizes transactions in the way that the first part of the research suggested, the main points of section 3.6 are revisited: • Have an easy to learn format 92 The system uses X M L which is proven to be an easy format since it uses human-interpretable language Be processable by computers X M L is both human readable and computer processible Written from the bottom up from within the industry At the moment the proposed system is written manually which may need a bit of expertise for a regular person in the A E C / F M industry, however, future research can develop user-friendly interfaces that allows for easier entries to formalized transactions. Have low initiative and maintenance cost Regular computers and browsers can accommodate X M L documents Be accessible from any place The formalized transactions could be placed on a server and be accessed from anywhere through the Internet and also by wireless technology Accommodate different elements of the communication theory The multidimensional formalization system is not restricted to a table or a matrix; it can have as many elements that are needed to be included. Accommodate the ownership of information The applications that use the formalized transactions can create instances of transactions on their own computers, so the information will remain under their sole ownership. No fragmentation of information will happen due to this ownership. It works like an email application on a computer that keeps all of the sent emails on a personal computer. In fact the main part that should be cohesive is the formalized transactions, that each computer will download in real time from the repository so no fragmentation will happen. Allow for openness, flexibility, and modularity 93 The system allows for flexibility, since unlike third party formalized transactions which have a limited rigid set of transactions, it contains many formalized transactions which the user can view, search for, choose from, and add to. The system allows for modularity since it could be interoperable with many other applications that already use X M L for other reasons. • Allow for different levels of security The multidimensional formalization system is for public use. It contains an element of security which identifies the level of security which is needed for the transfer of instances of formalized transaction. It would be the responsibility of the applications which send the instances, to send the instances at the same security level that the formalized transaction dictates. To better demonstrate the usage of our proposed system we developed a prototype application, using a process from our case study which is discussed in chapter five. Although the prototype application does not implement all of the aspects of the formalization system, it reinsures us about the usability of the system. Future research will enhance other aspects of the formalization system. The following sections identify some of the advantages that X M L offers for representing formalized transactions. 4.2.1. Combination of Different Layers of Information The XML-based approach described above combines high-level formalization meta-data, such as the field of transaction or the stage of the project, with the more detailed transaction control meta-data, such as receipt acknowledgement, time to respond, and security requirements; along with the actual transaction data content. It is convenient to be able to represent all of these layers of information in a single, consistent method, and it allows the resulting formalized transaction to be used for a wide range of purposes, such as categorization of a large collection of transactions, controlling transactions through a 94 transaction server application, and manipulating the information content of individual transactions. 4.2.2. Both Human and Computer Interpretability X M L can be understood by both computers and humans since it is fully structured but uses a plain ASCII language. It is both human-readable and computer-parsable. There are many technologies available for working with the X M L information, such as the X S L approach shown previously. Many other such technologies are still in the developmental stage but have potential for future advantages from which this approach would benefit. In the same way that people use a natural language to communicate with each other, X M L is used to create such a communication using the computers. Compared to formats that were used in the past, such as EDI, it has the advantage of being human-readable. 4.2.3. Ability to Transform the Document using X S L T The X M L approach makes the formalized transaction easy to manipulate for various purposes using X S L and other technologies. For example, formalized transaction files could be kept on a centralized server where they would be available for viewing via the X S L translations and the server-side ASP script shown earlier, and could also be accessed directly by distributed computer applications to control computerized transactions. 4.2.4. Ability to Categorize Transactions Based on the User's Interests Participants in different roles have different views for the categorization of transactions. The X M L technology allows a collection of transactions to be sorted, filtered, and grouped in any number of ways, thus providing a dynamic and flexible approach to categorization. In order to illustrate these differences in the transaction view based on the user's interests, two different X S L files are used for two sample transactions that will be explained in more detail in Chapter five. Now that we have discussed the origins of the dimensions of the proposed system, how it formalizes transactions according to the ways that research suggested in the first part, and the advantages of the system, we should demonstrate the functionality of the system. What was demonstrated is a very preliminary system which shows parts of the 95 whole functionality of an advanced system. This system should be used by an application as a source of formalized transactions to send and receive information between two parties. For this reason we have worked on a case study that will be discussed in the next chapter and, based on the case study, a computer application was developed that uses the formalized transactions document to send and receive information. As per any prototype application development, a rapid prototype testing methodology was accepted for the proof of concept. The application will be discussed in Chapter six. What distinguishes this system from other approaches is its capability of describing the characteristics of each transaction at the level of overall processes in A E C / F M , as well as providing detailed information of the transaction itself. Since it uses X M L , it is compatible with specifications from other initiatives such as ebXML or bcXML. Again, note that, while these initiatives have defined the components regarding the supply chain, they have not proposed a system that can accommodate the broad range of transactions that take place in A E C / F M . It is possible to use multidimensional formalization system for other industries, but the stages of the transactions, the roles of sender and receiver, the field of transaction, and other elements could be different; even the elements themselves might differ due to the nature of the industry and the importance of including the elements that differ from A E C / F M elements. The onus would be on the experts in those fields to identify the elements to be included in their systems and the values of those elements for each transaction. 4.3. The Role of Formalized Transactions This section addresses the role of formalized transactions relative to the following standards and systems. Although some parts have been mentioned before, the subject will be reiterated due to their relevance under this topic. 4.3.1. Product Model Standards Previous sections have introduced product model standards such as the IFCs, and have shown how these standards structure the data content of data exchanges, without 96 structuring the contextual aspects of the transactions themselves. In this way, the product model standards and the formalized transactions can both be developed as two separate but highly complementary efforts. In particular, the product model standards, as described above, can be directly adopted within the formalized transactions to structure the data content parts of the transaction 'message. Conversely, a well-developed set of formalized transactions would be beneficial in identifying the data content areas that need to be developed for new product model standards. 4.3.2. Classification Systems As described in Chapter three, several classification systems exist or are under development within the A E C / F M domain (such as MasterFormat or OCCS), but none of these classification systems were found to be relevant for classifying the range of existing business processes, communications, or information transactions. Thus, we have not used them as a basis for classifying formalized transactions in this work. Although we do not find these classification systems to be sufficient for classifying formalized transactions, there may still be some value in associating a collection of formalized transactions with categories in a system such as the OCCS. If this were desired, then one or more classification scheme codes could be added into the formalized transaction's DTD. 4.3.3. Applications This work assumes an environment where users throughout an A E C / F M project work with computer applications capable of communicating with each other. In this environment, information transactions could involve two people communicating with each other via their computer applications (e.g., one C A D operator sending design updates to another C A D operator); one person communicating through their application with a fully automated application (e.g., a project manager submitting documents to a centralized document management system); or two fully automated applications exchanging information (e.g., an automated data collection system that tracks truck 97 movement on site autonomously sending update information to a centralized project scheduling system). In most cases, the formalized transactions would have little or no impact on the core functionality of the application itself, but would come into play during the information exchange operations. At this point, the formalized transactions would provide the information necessary for the applications to complete the information exchange with minimal user intervention. This would make the information exchange process much simpler and less error-prone. In the case of the fully automated information exchanges, the transaction may not be possible without the formalized transactions. 4.3.4. Organizations and Work Process As shown, formalized transactions will make the information exchange process more efficient wherever repetitive, computer-based communications occur. To minimize the effort required to produce the formalized transactions and to ensure consistency, it would be beneficial to standardize the transactions across the broadest domain possible. As described before, different information exchanges have different ranges of applicability, from those that are common industry-wide to those that are unique to one individual worker. Correspondingly, some formalized transactions should be standardized throughout the industry, others throughout a company, others within a single project, and still others at the level of an individual worker. Once formalized transactions are developed and standardized, it will require very little skill and training on the part of the end user to use the transactions (in fact, the standard could be incorporated into a software tool in a way that is transparent to the user). However, the process of creating the transaction standards in the first place would require a moderate level of technical knowledge, training, and time commitment to develop formalized transactions that appropriately model the communication processes. Furthermore, while many of these transaction standards will remain stable over time, some ongoing maintenance and development of the standards will be necessary. 98 Therefore, transaction specification and standardization efforts would need to be adequately resourced at the appropriate levels. 4.3.5. Knowledge management Knowledge management is a relatively new term to the construction industry. It recognizes the ownership of intellectual property rights of an organization. Knowledge is a form of capital and should be capable of being exchanged and added to. This knowledge has two forms: tacit and explicit. The tacit knowledge resides in people's mind and the explicit knowledge can be captured and used by others. (Sun and Howard 2004). Formalized transactions will convert part of the existing tacit knowledge in the industry to explicit knowledge. The knowledge which exist in experts minds should be explicitly defined and it is a necessity for the computerization of the processes. It also adds to the transparency of the information exchanges and would be useful for the people who lack those expertise. In the next Chapter the case study of the research will be discussed. The process of reviewing the plans of developments on U B C campus, ( with the objective of sustainable planning, specifically checking transportation demand management requirement) is analyzed "As-Is" which is the way that it was conducted during our study. We will define formalized transactions for the process and use the formalized transactions for the implementation of the research through the prototype system that will be discussed in Chapter Six. Chapter Summary: This chapter described the multidimensional formalization system which is based on XML technology. A discussion about the hypothesis of the research and advantages of the system was followed by the role of formalized transactions within the overall context of information systems and environments. 99 Chapter 5: Review Process for Sustainable Planning— Case Study Chapter Abstract: This chapter analyzes a review process for sustainable planning from the research case study as an example of a business process in the AEC/FM industry. The As-Is process and the To-Be process are defined. For the To-Be process, two different types of transactions are identified and analyzed. In Chapter Four we proposed the multidimensional formalization system and discussed the role of formalized transactions in regard to different subject areas. To demonstrate the usage of this system we decided to implement it in a real world situation. We should analyze a process "As-Is" and also define the improved process: "To-Be" which uses the formalized transactions and discuss the advantages of the improved process. The author conducted a case study that will be discussed in the following sections. This chapter provides a detailed discussion of the business process in which project information is distributed to a number of parties for review and comment (i.e., a "review process") that the author practiced during the case study. The process is analyzed and some of the associated transactions are identified. The author was involved as a participant in this review process during her work at the TREK program centre of Land and Building Services (L&BS) Department of the University of British Columbia. The field of this process is Transportation Demand Management (TDM) as part of the sustainable planning for the U B C campus. During her work she assisted in developing a T D M Questionnaire (TDM Questionnaire 2005) and an Audit Checklist (TDM audit checklist 2005). She reviewed plans of a renovation project as well as new projects. She used her experience and the problems that she encountered in accessing the information that she needed for the review process, as a case study of an As-Is process (a process which happened at that time in the industry in practice). 100 5.1. Review Process As-Is As mentioned, a business process was selected as the case study for the research. The author worked at TREK department and part of her work was to assist in developing a T D M audit checklist which was used for the reviewing of plans of new developments or renovation projects at U B C campus. At the time of her work plans for any new or renovation project at the campus of the University of British Columbia were prepared by outside consultants and had to be reviewed by different affected departments of the University. The project manager informed those departments about the plans and asked for their comments. He collected those comments which he sent to the designers for modifying the plans if needed. This process will be analyzed in the following sections. 5.1.1. Introduction The University of British Columbia's L & B S is responsible for all services and activities necessary to plan, develop, operate, and maintain the land and buildings on the U B C campus. New projects, as well as renovation projects for the existing facilities, are part of the responsibility of L & B S . "In general, facility maintenance is the set of ordered activities which, when properly managed, allow for the continual operation of a facility" (Magee 1988). Sometimes during the operation of different facilities there is a need to do some alterations or renovations for better performance or functionality of a facility. Due to the limitations in the budget assigned for facility maintenance operations, some of those activities are postponed. In some cases, postponing maintenance activities causes more problems and necessitates the need for further repairs. In April 2000, the Canadian Association of University Business Officers (CAUBO) and the Association of Universities and Colleges in Canada (AUCC) jointly reported the urgent need for renewal of infrastructures in Canadian universities. "At the time of the report, C A U B O estimated the cost of addressing the Accumulated Deferred Maintenance (ADM) at an extrapolated 3.58 Billion Dollars across Canada" (AUCC 2001). This research formalizes part of the maintenance management transactions (for renovation projects ) as a step towards the computerization of the maintenance process. 101 This formalization will be implemented through a prototype application. The transaction could be stored under both fields of T D M and maintenance management. It will be more probable for a user to find it if it is under both fields. 5.1.2. Generality of the Review Process The Review Process takes place in many different stages and between many different roles in the A E C / F M industry. The author has observed and heard from her colleagues that the manual exchange of documents during this process falls short in supporting the needs for timely checks and approvals. During the review process, some piece or collection of information, which usually exists in the form of a document, is reviewed, checked, and commented upon. For example, the information could be a plan of the facility, a drawing of a piece of equipment, or a design change proposed during the construction phase. After the review of the information, comments or approvals might be sent to the owners from governmental bodies, to designers from regulatory authorities, to vendors from project managers, to service designers from the architects, and so on. The sender of the information or the document has received or developed the information or the document that needs to be checked. The review process has been chosen as an example because it is a common process with multiple use cases within the industry. For the purpose of developing a formalized transaction, however, a specific application of the general review process should be considered. 5.1.3. Land and Building Services As mentioned in the previous section, L & B S is responsible for all activities necessary to plan, develop, operate, and maintain the land and buildings on the U B C campus. A l l of the renovation projects, as well as the new developments on campus, should be controlled by L & B S . Two of the departments within L & B S were CP&D and T R E K program centre. Typically, consultants from outside campus did the design and administered the bidding for developments on campus. This process was controlled by CP&D. For each project, different parties from U B C should review the plans and 102 comment on them. The TREK program centre was concerned with transportation issues related to the renovation projects or the development of new campus buildings. The STP was a set of recommendations developed by T R E K that aimed at T D M with the general goal of contributing to sustainability. As mentioned in the introduction, the author worked for T R E K during the spring and summer of 2001. Based on the STP and under the supervision of the director of TREK, the author and other technical members of the BC environmental group developed a T D M audit checklist (TDM Checklist 2005) and questionnaire to ensure that the recommendations in the STP were met by all renovation projects and new developments on campus. The T D M audit checklist was used for checking the existence and the number of some of the building components such as the number of visitor parking lots, High Occupancy Vehicle (HOV) parking lots, bike racks, showers, and change rooms, etc., all of which were related to the architectural plans provided by consultants. It was also used for checking truck routes, traffic detours, the number of worker parking spots, etc., which were related to the contractors' plans during the construction stage. For each project, the project manager at the CP&D sent a "notification of project" inviting different people from different departments to go to the CP&D library and review the plans. It announced a deadline for submission of the comments and assumed that i f a department did not send any comments by the deadline, the requirements of that particular department had been met by the plans. 5.1.4. L & B S Review Process For the purpose of defining sample transactions, the L & B S review process was used. The author found that accessing the plans was not as straightforward as it might seem. Using paper drawings for all of the department reviews caused delays and the need for meetings with the project manager. In addition to accessing the plans, the other problem was that, from the initial stages of initiation of a project, detailed information about the requirements of the users and other demographic characteristics of the project were not shown on the drawings. 103 Information such as what percentage of the residents used bicycles, how young they were, etc. Each department knew what kind of information they needed to check for each project. The needed information could be financial (total amount of the contract and the length of its construction for an existing project), statistical, or demographic information which was not shown on the drawings. Even i f the information needed involved the physical elements of the buildings, there was the risk of misinterpretations from the plans. Incomplete, missing, or incorrect information caused the review process to be very tedious and time consuming. The author concluded that this process was not as effective as it could be, because, in practice, required information could not always be obtained on time, deadlines could be missed, and this could incorrectly be interpreted as the acceptance of the plans. One might think that just by changing manual regulations the problems could be completely solved. However, although manual processes are also subject to change, the author worked during a period that those changes did not happen. And even if those changes had happened, still the main problem existed, which was the lack of integration in processing the information. 5.1.5. Analysis of the L & B S Review Process The reviewer—according to his/her knowledge, relevant codes, or policies—might produce some type of checklist or questionnaire as an aid for checking any documents received for review. After comparing the information with the requirements, the reviewer would make comments and send them to the original sender of the information. Figure 5.1 shows the steps taken by the reviewer for the code-checking activity based on the use of a checklist or questionnaire, which is common for quality assurance purposes. In practice, these steps are time consuming and prone to human error. An example of the problems with the code-checking process relate to the fact that codes change over time. New construction methods, equipment, safety and environmental precautions, etc., change the way that buildings should be built in different eras. Every few years, codes are revised and new codes are published and distributed among the experts in related fields. 104 Figure 5.1 Review process activity model for checking the code from the perspective of the reviewer In the review process, the project manager must ensure that people in different roles have checked their related areas of specialization. The project manager receives project information from various sources, passes the relevant information on to the reviewers, and receives the results of their reviews. Figure 5.2 shows the activity model for the review process from the point of view of the project manager. Start yfS^ f Send C ^ V Info End Figure 5.2 Review process activity model from the project manager's perspective Figure 5.3 shows the activity model from the point of view of the department. The activity of applying the checklists is demonstrated in more detail in Figure 5.4. 105 'Receive NotificationN Start < | | of the Project Receive Request for Comments > End Send Comments Make Comments^)'*" Check the Checklist > Figure 5 . 3 Review process activity model from the department's perspective As shown in Figure 5.4, each department should formalize its own codes. TREK developed a questionnaire and an audit checklist based on the STP recommendations. By receiving a notification of the project which included a request for comments, T R E K had to find out whether or not the plans satisfied the requirements of the T D M audit checklist. \ ^ Send Comments^^)'^ ^ M a k e Comments^^)* End Figure 5 . 4 Review process activity model for code checking from the department's perspective 106 Figure 5.4 is the department view of the activity model for code checking. The reviewer can send responses such as "no exception", "revise", "reject", or "reviewed", respectively indicating that the information sent is acceptable, should be revised partially, is not acceptable, or is reviewed but no comments were requested. 5.2. Review Process "To-Be" To improve on the As-Is process, the To-Be process should provide, in a timely manner, all the specific information needed for each department to complete its review. Each department knows which information it needs to check, and could compile a list of this information for the project manager. As a starting point, it would be nice if all the specifically needed information could be sent to each department by the project manager along with the "request for comment,". Then, i f the checking process could be computerized and comments could be automatically returned to the project manager, this could be a desirable To-Be process. However, when there are numerous departments and each department needs a list of data items for different transactions, the project manager will not be able to memorize all of those transactions. So, it would be useful to have a system which is capable of keeping and categorizing those transactions. The system should define the transactions in such a way that all of the questions regarding those transactions could be answered, questions such as: "what is the name of transaction?", "what is the objective of transaction?", "who sends the information and who should receive it?", "what kind of security is needed for the transaction?", "is there a need for a response?", and i f yes, "how long can it take for the receiver to respond?", or "what kind of information should be sent?", etc. For building projects, the information about the project exists in the drawings. If model-based applications are used in the project, the information content of the transactions could be automatically extracted from the model. Otherwise, the project manager should interpret the drawings for the needed information ( as per the checklist provided by each department) and send it to the receiving department. For the purpose of our example review process, the To-Be process should utilize a system in which the project manager can define the transactions for the information that is required by each 107 department. These transactions can be represented and formalized according to the DTD discussed before. Although at present time it is not possible to reduce everything to checklists and often people need to explain things in a natural language, in order to automate the processes one should start with simple cases. Until the time that all the means for a complete translation of reality to a virtual world come to existence, automated processes may not satisfy all the needs of the industry. However, this should not be a stopping point for further developments and research studies. 5.2.1. "Request for Comment" Transaction The following listing formalizes the "request for comment" transaction that follows the transaction DTD discussed in Chapter four. The information about the project is sent electronically to the Transportation Department to be compared with the regulations of the department. 108 transaction > <name>request for comment</name> <definition>This transaction is used whenever the project manager asks transportation department for their comment about a project </definition> <project_stage>design</project_stage> <transaction_type>request response</transaction_type> <transaction_field>transportation demand management</transaction_field> <purpose>to get back the comment of the transportation department about the project in regard to Transportation Demand Management requirements </purpose> <start_state>When the notification of project has been sent</start_state> <end_state>When the comment is received by the project manager</end_state> <sender_role>project manager</sender_role> <receiver_role>transportation department</receiver_role> <transaction_UMLmodels_URL>http://www.construction.ubc.ca/ transactions_UML_models/request for comment </transaction_UMLmodels_URL> <response_time>2</response_time> <security>low</security> <acknowledgement>yes</acknowledgement> <message_element1 >project name</message_element1 > <message_element2>project address</message_element2> <message_element3>number of residency units</message_element3> <message_element4>building type</message_element4> <message_element5>number of visitor parking units</message_element5> <message_element6></message_element6> <message_element7></message_element7> <message_element8></message_element8> <message_element9></message_element9> <message_element10></message_element10> <message_element11 ></message_element11 > <message_element12></message_element12> <rnessage_element13></message_element13> <message_element14></message_element14> <message_element15></message_element15> <message_element16></message_element16> <message_element17></message_element17> <message_element18></message_element18> <message_element19></message_element19> <message_element20></message_element20> </transaction> Figure 5.5 Request for Comment 5.2.2. "Notification of Project" Transaction The listing in figure 5.6 provides an X M L document that defines a formalized transaction for the "notification of project" transaction identified in the example scenario earlier in this chapter. 109 transaction > <name>notification of the project</name> <definition>This transaction is used whenever the project manager wants to notify transportation department about a project</definition> <project_stage>design</project_stage> <transaction_type>notification</transaction_type> transaction Jield>transportation_Demand_Management </transaction_field> <purpose>to notify transportation department about a project</purpose> <start_state>When the architect has sent the plans to the project manager</start_state> <end_state>When an acknowledgement is received </end_state> <sender_role>project manager</sender_role> <receiver_role>transportation department</receiver_role> <transaction_UMLmodels_URL>http://www.construction.ubc.ca/ transactions/notification</transaction_UMLmodels_URL> <response_time></response_time> <security>low</security> <acknowledgement>yes</acknowledgement> <message_element1 >project name</message_element1 > <message_element2>project address</message_element2> <message_element3>architect</message_element3> <message_element4>architect contact</message_element4> <message_element5>future user department</message_element5> <message_element6>future user department contact</message_element6> <message_element7></message_element7> <message_element8></message_element8> <message_element9></message_element9> <message_element10></message_element10> <message_element11 ></message_element11 > <message_element12></message_element12> <message_element13></message_element13> <message_element14></message_element14> <message_element15></message_element15> <message_element16></message_element16> <message_element17></message_element17> <message_element18></message_element18> <message_element19></message_element19> <message_element20></message_element20> </transaction> Figure 5.6 Notification of Project In some cases, appropriate transactions may already exist. If there are no existing transactions for a particular data communication, then the project manager should create an appropriate transaction and add it to the collection of transactions so that it w i l l be available for use by others. 110 5.2.3. Analysis of the To-Be process This analysis will be used for the development of the prototype system discussed in Chapter six. The requirements of the user for the implementation part are as follows: • The project manager views the transaction sent and the response, i f applicable. • The project manager searches for a formalized transaction. • The project manager creates an instance of the formalized transaction. • The project manager sends the transaction to the other department. • The other department receives the transaction. • The other department processes the transaction, i f needed. • The other department acknowledges or responds, i f needed. For our implementation purposes, we use TREK as the "other department." We will consider two transactions: "notification of project" and "request for comment". After receiving the request for comment, TREK should compare the information regarding its requirements for T D M . Figure 5.7 shows the overall functional expectations of the system. I l l Figure 5.7 Use case model of the prototype system In the process of creating instances and sending the transactions, the system uses two transactions as shown in Figure 5.8. These transactions have been defined in the transaction standard X M L file which is located on the server. More description about the infrastructure needed for this service will be provided in chapter 6. 112 o o Project Manager Figure 5.8 Two transaction instances that are sent through the prototype system The two transactions—"notification of project" and "request for comment"—are the examples discussed in this section. As shown in figures 5.5 and 5.6 and also in Figures 5.1 and 5.2, these two transactions are defined according to the elements that were described in Chapter three. The contents of these two transactions are described as message elements and comprise the information needed by the TREK Department for the implementation prototype. In the request for comment transaction, the name of the project, the number of units, the type of the building, and the number of visitor parking lots are passed to TREK. According to the STP, and consequently the audit checklist, the number of the visitor parking lots for developments on campus should be limited to decrease the tendency of visitors to drive to campus instead of choosing other modes of transportation such as biking and transit. This limitation depends on the type of building, such as commercial, institutional, residential market or residential non-market. If, for example, the building is a residential non-market building, then according to the STP, the number of visitor parking spaces should be less than a specified percentage of the number of units. After receiving this information, T R E K compares the number with their requirements. This comparison could be done by a human or by an automated system. If 113 their requirement has been met, a "No Exception" response will be sent. If it is not met and changes are required, they can submit a "Revise" reply. In the revise message, there could be more details about what to change. Finally, if—as could happen in some cases— it is not acceptable at all, the response would be "Reject," as shown in Figure 5.9. Transportation Department Project Manager Figure 5.9 Use case models for different responses of the TREK department The swim lane model for the transaction "request for comment" is shown in Figure 5.10. The type of this transaction is a request response and it will end upon receipt of the response. Thus, the system expects the response to be received by the sender within the time specified in the "Time to Respond" field of the transaction standard X M L file. The prototype system should make the response visible to the sender of the request. The sender could send additional reminder notices to ensure a response within the allowable response time. 114 Project Manager Transportation Department Start ( Create Request For V Comment transaction Response End Request For Comment ^Process Request For Comment Figure 5.10 Swim lane model for the "Request For Comment" transaction Figure 5.11 demonstrates the sequence model for the transaction. The project manager sends the request and the Transportation Department sends back the response containing the review comment. Project Manager Transportation Department 1. Request (Request For Comment) > 2. Response Figure 5.11 Sequence model for the "Request For Comment" transaction 115 Figures 5.12 and 5.13 show the swim lane model and sequence model for the "Notification of Project" transaction. This transaction does not need a response but it does need acknowledgement as stated in the transaction standards. The transaction end state is when the acknowledgement has been received by the sender. The prototype system should demonstrate the acknowledgement of receipt. Project Manager Transportation Department Start r Create Notification Of Project l[Fail] [Success' (C~^) ) End Acknowledge Receipt r Issue Notification Of Project Process Notification Of Project Figure 5.12 Swim lane model for the "Notification of Project" transaction 116 Project Manage r Transportat ion Department 1. Notif ication Of Project 2. Acknow ledge Rece ip t Figure 5.13 Sequence model for the "Notification of Project" transaction. 5.2.4. Advantages of using formalized transactions for the review process As we explained in the previous sections, the informal exchange of information causes many problems. These problems could be categorized as follows: 1. Time overruns 2. Cost overruns 3. Quality deficiencies Time overruns Time overruns take place when the information is inadequate, or inaccurate. In our example, using paper-based information, the versions of the drawings and the location of the drawings were not right and there was the need to arrange for meetings with knowledgeable people in the project and ask for accurate information about the project. Considering the nature of construction projects which are very sensitive to deadlines, and low margins in the industry, the productive time of the experts should not be taken by providing missing or misinterpreted information from the paper-based information exchanges. The time restrictions regarding the review process and busy schedules of the knowledgeable individuals in the project does not allow for a tedious review of the paper-based drawings. 117 Cost overruns Cost overruns happen when the review process has not been completed due to time restrictions. Sometimes, despite the fact that the project should not be accepted through the review process, but because the response was not ready due to the lack of adequate information, it has been considered as an acceptance of the plans. If a plan is not acceptable according to the STP, approving it will create substantial problems in the future that will be costly to fix. Quality deficiencies Quality deficiencies are another aspect of the problems that could be prevented by finding a way to exchange adequate and accurate information about the project. A plan that does not meet the requirements of the Transportation department will have an adverse effect on the quality of life of the people who live in the same neighborhood. Although it may seem at first glance that building more parking lots than the Transportation department recommends will not harm the quality of the building, it will , however, affect sustainability of the environment where the building is situated. As we mentioned earlier, in the As-Is situation, the notice of the project was sent through email. One may think of email as an electronic exchange of information; however, the same email was sent to all of the different departments and the information was provided in a physical location in the form of paper-based drawings. Although it was an electronic exchange of information, but as any other email, it needed human interpretations. Chapter Summary: This chapter analyzed the review process of the case study as an example of a business process in the AEC/FM industry. The As-Is and To-Be processes were defined. For the To-Be process, two types of transactions—a notification type and a request type—were identified and analyzed. 118 Chapter 6: Implementation of the formalized transactions through a prototype application Chapter Abstract: This chapter explains the prototype system that was developed to exchange information based on formalized transactions for the To-Be review process which was analyzed in chapter five. It explains the system architecture, functionality, and user interfaces of the prototype application. 6.1. Introduction Chapters one, two, and three of this thesis discussed the first part of the research—the research questions relating to the ways that A E C / F M transactions should be formalized. In Chapters four a new approach was introduced for the formalization of transactions in A E C / F M . In chapter five we explained a review process that was related to checking the plans of new developments or renovation projects on UBC campus based on a T D M audit checklist. This review process was analyzed as the As-Is process and the problems with the As-Is process were mentioned. A To-Be process was designed with the same functionality of the As-Is process which should be able to send the needed information by each party based on the formalized transactions. This chapter explains a prototype application that was developed for the exchange of information for the To-Be review process from our case study is chapter 5. A prototype system has been implemented and, as shown in the following sections, it meets the requirements of the users for the business process described in Chapter five. It provides a proof of concept for the use of XML-based formalized transactions to support the development of information systems in the A E C / F M industry. The prototype system is written in the Visual Basic language and the Microsoft.NET environment. It uses the Internet to exchange data between project managers and the TREK department. X M L and Active Server Pages (ASP) technologies have been used to send and receive transactions between the applications. 119 6.1.1. System Architecture The prototype system is used to demonstrate the use of formalized transactions. It consists of two client components: the "Transaction Automation X M L , Manager" component (TAXMLManager) and the "Transaction Automation X M L , Department" component (TAXMLDepartment). The system also uses components located on a server, which include ASP and X M L files The prototype can send and receive messages between the project manager and the T R E K Department. HTTP Get and Post methods and file streams are used to transfer the data from the web server to local files. Figure 6.1 shows the overall architecture of the system. Server data files include the formalized transactions that are stored in X M L files as repositories on the web and the instances of the transactions. Local data files consist of formalized transaction X M L files and transaction instances X M L files. The Project manager machine also has Data Model X M L files of the project. The transfer of data between the local machine and the web server happens under HTTP GET and POST methods and the ASP technology. Project Manager Local Machine Local Data Files TAXML-Manager HTTP Web Server Server Data Files ASP Web Application HTTP Department Local Machine Local data Files TAXML-Department Figure 6.1 Architecture of the prototype system As shown in Figure 6.1, this prototype system will access the repository of transactions. Although it is a simple application, it shows that the user will be able to access formalized transactions through the web, read the content and context of the data that is being exchanged, and create an instance of that transaction. The system will read the formalized transaction and create spaces that allow the user to enter relevant values for the parameters that are needed for a specific transaction. This prototype system shows 120 the functionality of formalized transactions that could be standardized throughout the industry. Although the repository is not an accepted standard yet, it could be used among the parties who have agreed to use it for their data communications. The prototype system acts as a real-time application. Formalized transactions are written in X M L using the multidimensional formalization system proposed in this dissertation. The prototype system also creates an interface which the user can read or enter information relevant to each transaction. The values that the users enter into the interface are, in fact, the actual data that will be exchanged among the parties and the values that the user reads from the interface are the elements or dimensions of the formalized transactions. To demonstrate the capability of automation of the information exchange and code checking process that happens in many approval procedures, by using formalized transactions, we have linked our application to a data model file in X M L . This demonstrates that such capability exists, yet more research is needed for improving the application and the realization of seamless data exchanges using formalized transactions and data models in A E C / F M . The prototype system reads the X M L file containing formalized transactions from the web. The file is considered to be written and approved through a community of practice web site. It gets the file from the web and uses the content of the formalized transactions to send an instance of formalized transaction in the context that the formalized transaction states. It also creates a user interface based on the information content or message elements of the formalized transaction. The user has the option to enter information manually or link to a data model file on the local machine and get the information from that data model. The other department can receive the transaction and if there is a need to do any checks, it can perform these manually or automatically. We have used a simple T D M audit check to demonstrate the capability of computerization of the process. If the check is done and it is approved, the department can send the approval response back to the project manager or it could be done automatically by the application. 121 The method of implementation is the same for any transaction. It would be only a matter of resources to expand the prototype system for reliable commercial usage. As is, the prototype is simplistic but it fully implements the general solution for formalized transactions. 6.1.2. .NET Environment The system has been written with Microsoft Visual Studio.NET professional and uses Active Server Pages (ASP) technology. It can be implemented on any MS Windows platform that can run ASP. In this section we will briefly explain about Microsoft NET, its framework and DOTNETNUKE. Microsoft's .NET has greatly simplified application development. It provides support for traditional desktop windows applications as well as web-based services. VB.NET is now a fully object oriented language which supports classes, interfaces, interface and implementation inheritance, and polymorphism. VB.NET is also highly integrated with .NET Framework (Wyatt and Oberg 2002). Microsoft development tools now all use a single Interactive Development Environment (IDE); .NET provided the means for design, development, and debugging, in one cohesive environment. Since Internet Information Services was introduced in 1997, ASP has been the main technology to deliver web content. ASP.NET is the .NET version of ASP which could be used by programmers to quickly infuse websites with dynamic content and functionality (Powers and Snell 2002). DOTNETNUKE is an open Source Framework tool which is ideal for creating and maintaining professional web applications. D O T N E T N U K E is under a BSD-style agreement which allows the general public to obtain the software for free. It builds upon ASP.NET (VB.NET) platform and is easily installed and maintained (DOTNETNUKE 2005). D O T N E T N U K E could be used to create the website which is needed for the creation of the formalized transactions by people from the A E C / F M industry as a community of practice. .NET offers a compact framework that works on mobile devices. This framework is coupled with SQLCE (which is a compact SQL data base). Applications could be written 122 which run on a mobile device to collect data on construction sites and then transferred to the PC in the office. The overall architecture of the .NET Framework is shown in figure 6.2 below (From Wyatt and Oberg 2002). C# VB.NET C++ Other Common Language Specification .NET Framework Class Library Visual Studio.NET Common Language Runtime Figure 6.2 Architecture of the .NET Framework .NET Framework supports different languages such as C# and Visual basic. Common Language Specification (CLS) is an agreement among language designers about a common subset of features that all languages will support. For example, the CLS requires that public names do not rely on case for uniqueness, since some languages are not case sensitive. The .NET framework class library is comprised of many classes. The library of classes consists of four major parts: 1. Base class library 2. Data and X M L classes 3. Windows User Interfaces (UI) 4. Web services and Web UI The .NET Framework block diagram is shown in figure 6.3: 123 Web Services and Web UI Windows UI Data and X M L Base Class Library Figure 6.3 .NET Class Library Common Language Runtime (CLR) performs memory management. It is needed for compile time checking and runtime checking and provides better performance and security (Wyatt and Oberg 2002). 6.1.3. System Functionality As discussed in section 5.2.3, Analysis of the To-Be Process, the following are the requirements of a user of the prototype system: 1. The project manager is able to view all previous transactions sent and their responses, if applicable. 2. The project manager searches for a formalized transaction. 3. The project manager creates an instance of the formalized transaction. 4. The project manager sends the transaction to the other department. 5. The other department receives the transaction. 6. The other department processes the transaction, i f needed. 124 7. The other department acknowledges or responds, i f needed. For the prototype application it is assumed that the formalized transactions already exist in an X M L file on the web. The addition of any formalized transactions to the collection of formalized transactions in a repository should be done through some peer review approval processes. The addition could be done manually or future implementation efforts could develop an interface for the entry of new formalized transactions to the X M L file containing all of them. As shown in the following sections, the prototype application was able to fulfill all of the above mentioned requirements. 6.2. D e s c r i p t i o n o f the P r o t o t y p e A p p l i c a t i o n Sample scenarios have been described to demonstrate the proof-of-concept prototype system. The system functionality and user interfaces for these scenarios are described in the following sections. 6.2.1. The project manager is able to view all previous transactions sent and their responses, if applicable As an initial basic functional requirement of the system, the project manager is able to view all previously sent transactions, along with their responses, and gain access to all other system functionality. This is achieved in the prototype through the Main form of the TAXMLManager component. This form, shown in Figure 6.4, has two menus: File and Tools. The File menu has three commands: • O p e n T r a n s a c t i o n s : the user can open a transaction. • Save T r a n s a c t i o n s : the user can save a transaction. • E x i t : closes the screen and exits the program. The commands available through the Tools menu are as follows: • R e c e i v e T r a n s a c t i o n s : the user can receive a transaction • S e n d T r a n s a c t i o n s : the user can send a transaction. 125 • View Response: allows the user to view the response to a selected transaction. The Main form also contains a list of existing transactions. The columns of the transaction list view are as follows: • Name: Every transaction has a unique name as indicated in the Name column. • Template: The name of the formalized transaction used as the template for the transaction instance. • Acknowledged: The Acknowledged column contains a Yes i f the system has received a response or an acknowledgement for that transaction. • To: The name of the receiver. • Date Sent: The date the transaction was sent. File Tools Transactions. . '.'] -Template | Acknowledged | To South CampusNOP Health Centre NOP South Campus RFC Health Centre RFC, request for comment Yes notification of the pro... : Yes notification of the pro... -Yes request for comment Yes TREK TREK TREK TREK 06/'2t/03: 06/23/03 06/28/03 06/29/03 Figure 6.4 Main form 126 By selecting one of the transactions, the user can open it by selecting "Open Transaction" from the File menu and viewing the selected transaction in the Transaction View form, as shown in Figure 6.5. Transaction Name ' "!|Health Centre RFC To Whom: TREK: Template Name: Sender Role: Receiver Role: :•:, Transaction Type: Pro|ect Stage 'iStart State: End State: Message Elements: request for comment project manager N! transportation department | requestR esponse Security: Date Sent:" Response Time: Acknowledgement: UML'ModelsURL Definition; low yes http: //www: construction, ubc: ca/trai design- , This transaction is used whenever the proiect manager asks Transportation department for their i when' the notification of pro|e Purpose -i when the""c'omment is receive to get back the comment of the; , |/»,| transportation department about the, ,rIr> project in regard: to iTransportatioh . .\y'j Value Entered For Message Element: project name proiect address number of units building type number of visitor parking lots Health Centre 5580 University Boulevard 75.. residential 7 Submit OK Figure 6.5 The Transaction View form The Transaction View form contains fields such as "Transaction Name" and "To Whom". Depending on the Template Name (i.e., the formalized transaction), other properties of the formalized transaction will also be displayed in this form. Different message elements (message content), along with their assigned data values, will also be displayed on the Transaction View form. 127 To view the response to a transaction, the user can select that transaction from the list in the Main form and select the "View Response" command from the Tools menu, or select the "Response" button from the Transaction View form. The Response form will appear as shown in Figure 6.6. -"l — • • •• • J'-Tjansaction Name: ;!|SpTjth",Gampus RFC. " Response: BSSBSKSHr!" ^:EE:iEijEii!ii:!!!!!!!!:'!!!!.i:!'!!!! i. , .^ V,', Close • j Figure 6.6 Response Form The Response form contains the Name of the selected transaction and the comments of the receiver. The "Close" button will close the Response form. This is just an example and more comments could be included if necessary. 6.2.2. The project manager searches for a formalized transaction To create a new transaction, the user selects the "New Transaction" command from the File menu of the Main form. The Template Selection form will be displayed as shown in Figure 6.7. 128 Templale Name: j|| Sender Role: 1 V~ Receiver Role: |~ Transaction Type P , note: leave blank to indicate any value Template Selection Search I linT lansaction T emplates M alching Criteria: Proiect Stage" | Start State - f End State 1 ; Security ' 1 [ Response Time ,, . .[ J Acknowledgement!:! UML Models URL, N/A Definition . Purpose: Figure 6.7 Selecting a formalized transaction With this page, the user can search for an existing formalized transaction. The search criteria that have been implemented for the prototype are the name of the formalized transaction, the sender and receiver roles, and the transaction type. Subject to the search criteria, the matching formalized transactions will be shown and the user can select the desired formalized transaction. For example, Figure 6.8 shows the results of a search for the formalized transaction named "notification of the project". A formalized transaction of this name is shown in the list of available formalized transactions, since this template was available in the formalized transaction X M L file. The user can select this formalized transaction in the list to display some of its properties, and can click on the "Select" button to create a new instance of the transaction based on this formalized transaction, which is then shown in the Transaction View form. This instance contains the values 129 relevant to the information that should be provided in each case according to the formalized transaction, such as the values for the data content of the formalized transaction. Template Name: - '^ (notification of the prefect Sender Role: 'j Receiver Role' | jJ'ransactiomTypeTi"'; j note leave blank to-mdicate any value Search:! Template Selection T ransaction T emplates M atching Criteria; Proiect Stage Start State End State Security ..Response Time:: i design |When:the.architectihasisent t |,Whentan .^ acknowledgement i, I low Acknowledgement lyes UML Models LRL http://www:Constfuction.ubc.ca/transactions/notification: Definition: ; Purpose: .1 This transaction is used whenever 1 the proiect: manager wants to notify tnsportation department about a proiect to notify transportation department about a proiect Cancel Select Figure 6.8 Result of search among the existing formalized transactions 6.2.3. The proiect manager creates an instance of the formalized transaction Once the user has selected a formalized transaction and created a new instance of a transaction, they can define a name for the instance (which for simplicity will be simply called a "transaction" hereafter), the name of the receiver, and select each message element to enter the value for that element as shown in figure 6.9. After all the required fields have been entered, the Submit button becomes activated. The user checks all the values and presses the Submit button. A completed transaction was shown in figure 6.5 130 Transaction Name:: To Whom: ' Template Name: Sender Role: Receiver Role: Transaction Type: Project Stage: Start State: End State: TREK request for comment Security: Date Sent: Response Time: Mow proiect manager i transportation: department!! requestResponse ' design Acknowledgement: :yes UML Models URL: http' //www.construction.ubc.ca/traj Definition: This transaction is used whenever the proiect manager asks >lrl> Transportation department for their .v^ i when the notification of proie ; when the comment is receive : Purpose: to get back the comment of the t l Ji^jl transportation department about theiiiisIS' project in regard to Transportation iv'| Message E lements: Value Entered For Message Element: proiect name project address number of units building type number of visitor parking lots Response..1 OK Figure 6.9 A to-be-completed transaction shown in the Transaction View form In effect, the system uses the formalized transactions stored in the repository to re-create different documents used in the industry, allows users to enter various data values for these documents, and sends the documents to the other parties. 6.2.4. The proiect manager sends the transaction to the other department After saving the transaction, the project manager can select "Send Transaction" under the Tools menu of the Main form, as shown in Figure 6.5, to send the transaction to the indicated receiver. 131 6.2.5. The other department receives the transaction At the TREK department, a user logs into the TAXMLDepartment component through the Login form shown in Figure 6.10. Figure 6.10 Login form Through the Main form, the user selects the "Receive Transactions" command from the Tools menu. A message box is displayed upon successful receipt of the transaction, as shown in Figure 6.11. Receive < 3f data file com i OK I pleted successfully!^ Figure 6.11 A message box indicating that the message has been received 6.2.6. The other department processes the transaction if needed Once transactions have been received by the TREK department, the user can select the transaction in the Main form for viewing. The message will appear in a Transaction View form, identical to Figure 6.11, except that the "Response..." button is now available. The Response button is not enabled if the type of transaction has been "notification". Only for the "request response" type of transactions it will be enabled. The user would then carry out any required data review and checking procedures. A simple check of T D M audit checklist was implemented which demonstrates that the approval 132 process could be automated through the usage of formalized transactions, data models and functions that perform the checking of a checklist which has been created based on the knowledge and existing codes of the department. 6.2.7. The other department acknowledges or responds, if needed In case of a "request response" type of transaction, when the user is ready to submit the response, he or she can select the "Response..." button in the Transaction View form. The Response form, shown in Figure 6.6, will be displayed, allowing the user to enter their response in the form. This could be automated in a manner similar to the partial checking of the T D M audit checklist—if the department requirements are met, an "approval" response could be sent automatically to the project manager. 6.3. Discussion of the Prototype The implementation scenarios show that the required system functionality was achieved by the system. It showed that the formalized transactions could be used by different users, and the system was able to search the formalized transactions and create an instance of the transaction, and send and receive transactions using the web. This prototype implements structured information flow functionality. This formalized and standardized exchange of structured information associated with specific tasks could be expanded into systems that manage who is responsible for what and when (workflow management systems), and into systems that could partially or fully automate the required checking (automated work tasks). Other systems that could have been used to send information to another party are, for example: regular email, custom templates in applications such as Microsoft BizTalk server etc. The difference would be in the fact that by using those applications there would be no common language that the industry could use to communicate on A E C / F M projects. Even if templates are created in those applications, those templates will not be accessible by everyone in the industry. Emails are unstructured while the prototype system creates the same interface for any participant who is using the formalized transactions. The central structure is located on the web and it is written in X M L which could be read and implemented by other 133 applications. There is the possibility of linking to the data model of the building and automatically extract the information which is needed for the transaction. At the department, the checking could also be formulated and automatically performed. Other approaches generally fail to achieve one or more of the requirements—for example, Microsoft's Biztalk or Exchange servers, could provide much of the prototype's functionality, but they are not using an open online source that experts in the industry have defined as a knowledge base of the information exchanges in the industry. Those systems are comparable to the prototype application; however, they lack the usage of the main part of the research which is the formalized transactions. Those applications do not propose an approach that looks at the nature of the process in A E C / F M and do not fulfill the need of the industry to a set of explicitly defined transactions that could be used by different parties. Chapter five described the problems with the As-Is process which were related to the access to the information needed for the checking of the T D M Audit Checklist (TDM Checklist 2005). By using the formalized transactions, the information that each department needs could be identified using the formalized transactions and that information could be extracted from data models. In this manner the problems that the As-Is process was facing will be solved. It is important to consider that, this prototype application is used only for the proof of concept, and not for commercial use. To illustrate the usage of the prototype, it would be beneficial to recall the transaction in chapter five. We defined two transaction examples for the review process. We wrote those transactions in an X M L file and located them on the Web. In the implementation prototype, the TAXMLManager user can access the web and search for the transactions that are sent to TREK. The user can choose the request for comment and the prototype will show the message elements of that transaction. The formalized transaction was shown in figure 5.5: The message body elements for this transaction are as follows: Project name Project Address Number of Units 134 Building Type Number of parking lots The values corresponding to these items could be entered manually or extracted from a data model in X M L which contains the information. Those values will be written in an X M L file on the local machine and will be posted on the web. The Transportation department then receives the values from the web, stores them on the local machine and performs the check for the T D M audit checklist. Figure 6.9 shows the values entered for these items. These values could be entered manually or by linking to a data set that contains the information about the building in an X M L file. At the Transportation department, these values should be compared with the requirements of the T D M audit checklist. For instance the check could be that i f the type of the building is residential, then the number of visitor parking lots should be less than 0.1 * Number of Units. It is possible to formulate this check and extract the values from the X M L file of the instances of transactions, perform the check and automatically send the response to the project manager. In this case the response should be approval of the check. This implementation was used as a proof of concept to illustrate how the formalization system could be used in a prototype application. The advantage of this application was that it used formalized transactions from the web, created user interfaces that were based on the content of the transaction for data entry by the user. It is possible to link to the data sets from the building model at a simple level and send the information through the web to another application which could be capable of automatic checking for different cases. Previous efforts to define supply chain specifications for marketing and e-commerce through the Internet are not sufficient for a thorough implementation of CIC in actual A E C / F M processes. A multidimensional formalization system is needed and is capable of defining the processes that are used for the data communications in A E C / F M using the computers. 135 We would like to revisit our answer to the second question of the research about the ways that a formalization system in A E C / F M industry should formalize transactions to evaluate the compliance of our prototype application in that regard. It should : • Have an easy to learn format This requirement was met by usage of X M L • Be computer-interpretable The prototype system showed that the X M L file was read by the computer. • Allow end-users within the industry to define their own transactions The prototype application did not have an option to write to the formalized transactions, it only read the formalized transactions and wrote to the instances of formalized transactions. The future research can add that functionality to the application. • Have low initial and maintenance cost The application was a windows based application developed in Microsoft Visual. Net environment and did not need a high level of sophistication • Be based on open and widely supported technologies We used a personal web server for the formalized transactions and the application used that through the Internet. The same happens i f we store the formalized transactions on any server and access it through our browser from any place. • Accommodate different elements of the communication theory Although our formalization system contained all of the necessary elements of the communication theory, we did not use all of those elements in the prototype search options. We believe that with the same logic we can expand the system to contain all of those elements as search options. • Allow for openness, flexibility, and modularity 136 The application was developed in Microsoft visual.net which uses openness, flexibility and modularity in the Application Development Environment A D E . We showed before that X M L format also has the features. • Accommodate the ownership of information The prototype application keeps the instances of transactions on the local computer, so this requirement could be met by using the formalization system. The data values will be kept on the server only for a short time. The formalized transactions however, will stay there for everyone's use and reference. • Allow for different levels of security The application did not have an option to use different levels of security; however, it is possible to do it manually by changing the settings of the browser to different levels of security based on the formalized transactions. Future research can work on adding the option to change the security levels from within the prototype application. In Chapter One we explained about the objective challenges that the research faced. In the following we explain how we overcame those challenges. • Finding a solution After reviewing the literature, conducting the international survey, and the case study, informal interviews, our past work and teaching experience, and finding more about the capabilities of X M L technology at BCIT, we proposed the multidimensional formalization system. • Testing the solution Rapid prototype testing was used for the prototype application. The hypothesis of the research was to demonstrate that the solution formalizes transactions in the way suggested by research in the first part. 1. Satisfying the suggestions of the first part of research 137 It was shown in this section that the solution formalizes transactions according to the ways that research suggested in the first part. Although the prototype application did not implement all of the aspects that were suggested before, they could be implemented if the research could use a programmer. Future research could implement all of the aspects of the first part of the research. 2. Demonstrate the usage of the solution For the purpose of proof of concept, the usage of the solution was demonstrated in Chapters Five and Six. • The As-Is process and improved To-Be process In Chapter five, the case study was discussed and the As-Is process was analyzed. The U M L models for the To-Be process were developed which had the functionalities of the As-Is process using the multidimensional formalization system proposed by the research. The problems in the As-Is process In Chapter Five, the problems that the author faced, while trying to access the information needed to review the plans of developments on campus, were explained. The problems solved by the To-Be process using the solution In Chapter Six the author explained how by using formalized transactions one could eliminate the need for human interpretation and tacit knowledge of the experts in the field, and prevent the problems faced in the As-Is process. Although this approach does not solve all of the problems that CIC faces, it contributes to achieving the goals and objectives of CIC. More research and resources are needed to full implementation of CIC strategies in A E C / F M industries. In the next 138 Chapter the author concludes the dissertation and briefly discusses some of the possible future research based on our proposed approach. Chapter Summary: This chapter illustrated the functionalities and user interfaces of the prototype application and showed that the requirements of the users were met by the application. It also discussed a demonstration of a partial implementation of the aspects of the formalization system as found in the first part of the research and the potential for a complete implementation of aspects which could be part of our future research. It provided a proof of concept for the use offormalized transactions in the computerization of data communications in the AEC/FM industry 139 Chapter 7: Conclusions Chapter Abstract: This chapter presents a summary of the thesis and defines the contributions of the research as well as possible future work. 7.1. Summary In a typical project today, information is represented in the form of unstructured documents (including all formatted and tabulated word, pdf, and excel computer files) that are exchanged in an informal and manual manner (including through email and fax), or it resides in human minds and is exchanged through informal communications. Given the complexity and quantity of information and the number of participants in a typical project, the difficulties arising from managing project information flows are evident. Experience shows that a significant amount of project time and resources are spent accessing, searching for, and exchanging information. Inefficient communication of information results in project cost and time overruns, reduced quality and productivity, rework, loss of design intent, and the inability to appropriately access and communicate project information in a timely fashion. TOPS is an ongoing research program within the Construction Management Group of the University of British Columbia that streamlines the integration of building project information to achieve interoperability in the A E C / F M industry and contribute to the strategies of CIC. This dissertation focused on the formalization of data exchange transactions as a step towards the overall goal of interoperability according to the TOPS directives. In Chapter one, we discussed about the structure of the thesis which consisted of two parts. The first part aimed at answering research questions. Chapters two and three reviewed some of the efforts in the field of general computer standard formats, such as X M L , product data standards within A E C / F M , some process standardization efforts from other industries, and previous efforts to formalize data exchanges in A E C / F M . Through a 140 discussion at the end of Chapter three, the research suggested the ways that A E C / F M transactions should be formalized. Based on the literature review, an international survey that was conducted, and a case study in the industry, an approach to define formalized transactions in the A E C / F M industry was presented in Chapter four. This approach will allow A E C / F M systems to exchange information in a consistent way and provide opportunities to improve information access and management across the industry. In Chapter five a sample process from our case study was analyzed and As-Is and To-Be states were discussed. A prototype system was developed that used the web to access the proposed formalized transactions and create instances of data exchange accordingly. The prototype system discussed in Chapter six showed how a collection of formalized transactions can be searched and used to create various transactions from the formalized transactions that were stored on the web. The hypothesis of the research, which was the second part of our research, was discussed at the end of Chapter four and the functionality of our proposed system was demonstrated through Chapters five and six. Although the prototype system was intended only to demonstrate the functionality of formalized transactions, it could be further developed to automate some of the work processes, based on the information received using a formalized transaction. This approach could form the basis of many working applications that use the formalized transactions and perform various calculations and code checking on the data. The data is not limited to a specific data standard such as the IFCs or aecXML, etc., yet any of these data standards could be used to define the data content of the messages or message elements as mentioned in Chapter four. 7.2. Contributions The main contributions of the research are as follows: • A review of efforts in the field of formalization of data exchange in the A E C / F M and supply chain • The way that A E C / F M transactions should be formalized 141 • A Multidimensional Formalization System to define transactions in A E C / F M using the X M L technologies The first two contributions are the answers to the research questions as stated in the first part of the research. A collection of descriptions of different efforts in the field of formalization of transactions in A E C / F M industry as well as supply chain was gathered. Such a collection will help future researchers access the sources of information that they need. The research also reviewed computer formats and standards that these efforts or initiatives have used. These formats and standards act as a back bone for future paths of research toward the fully formalization and standardization of the processes. The research discussed about communication theory and the need for a system which can accommodate formalization of different elements of it, in regard to the processes in A E C / F M was stated. Use case modeling by aecXML and PIPs from RosettaNet were discussed and the broad range of transactions in A E C / F M which differentiates it from other industries was mentioned. The author also explained about the lack of enough knowledge about IT in construction and the environment of the industry which requires an easy format to be used to formalize the transactions. The need for a bottom up approach for defining many of the transactions that at present do not exist as part of the industry's common documents was discussed. An international survey was conducted which demonstrated the opinion of some of the people from the academy and the industry about the future computing trends in A E C / F M industries. The way that A E C / F M transactions should be formalized is the first step toward developing formalization systems and therefore, it is assumed that answering the questions in the first part of the research constitutes a major contribution of the research. Based on the previous research, their shortcomings for the A E C / F M environment, the author's findings from the survey, and the case study conducted at the TREK department of UBC, the first part of the research was answered. A multidimensional formalization system was proposed that used X M L technology. In chapter five the As-Is process and some of the problems encountered during the case study were analyzed. The research proposed a To-Be process for a formalized exchange of information using U M L modeling techniques. 142 It is assumed that that the multidimensional formalization system is another major contribution of the research, however, implementing that system necessitated the case study and modeling of the As-Is and To-Be process, as well as, developing the prototype system that uses the formalized transactions to exchange information between a sender and a receiver. So chapters five and six could also be considered as contributions of the research since they provide proof Of concept for the multidimensional formalization system. These contributions could be further expanded as follows. 7.2.1. A review of efforts in the field of formalization of data exchange in the A E C / F M industry and other industries Various efforts from the field of formalization of data exchange were reviewed and some of these methods were described in more detail in Chapters two and three. 7.2.2. The establishment of the notion of process standards in the A E C / F M industry which is needed for the realization of the CIC strategies Data standards have been the main subject for different organizations in A E C / F M in recent years. Standardization at the process level has received less attention. Although, in the supply chain, some efforts have been underway, there have been no efforts in the field of process standards for the whole range of A E C / F M processes. Our multidimensional formalization system for transactions has established the notion of the process standards in the A E C / F M industries, and future research should be conducted to achieve the ultimate goal of computerization of all of the processes in A E C / F M . 7.2.3. A Multidimensional Formalization System to define transactions in A E C / F M using the X M L technologies The research suggested a method for the formalization of data exchange, which could accommodate a multidimensional universe of discourse for all of the necessary elements of data exchange, was introduced. This approach addresses dimensions such as the stage of the project, field of transaction, sender, receiver, and the data content of the transaction. This method uses X M L to represent a series of transaction properties. This method uses powerful technologies that accompany X M L technology, such as XPath and X S L for the representation and search of the formalized transactions. 143 7.2.4. Analysis of a review process from our case study A review process was analyzed and related U M L models illustrated the sequence of tasks throughout the process. 7.2.5. Application of the multidimensional formalization system for the approval process and defining the transactions used in the process The application of the multidimensional formalization system for the transactions used in the approval process was demonstrated and the transactions were written in X M L according to the DTD of the system. These transactions were represented using X S L technology in Chapter five. 7.2.6. A prototype application to demonstrate the functionality of the formalized transactions The architecture of the prototype system that was implemented as part of this research uses the web to send and receive messages based on formalized transactions that are distributed on the web. The review process, which was analyzed in Chapter five, has been implemented and two transactions related to this process were exchanged between the applications. The prototype demonstrated the usage of the formalized transactions and meets the requirements of the user as defined in Chapter five. This prototype system is currently used by humans, but it could form the basis of components that could be added to other applications and give them the ability to act as the sender and receiver of information in various transactions, increasing the functionality of those applications while reducing the data entry and other user requirements. 7.3. Future Work This research could be a basis for the implementation of CIC which requires that the products and processes of the industry be formalized. Based on a formalization system that is computer-readable, many applications could be developed to send and receive data according to the specifications of a transaction. There are many venues for the future research, such as: find out more about the way that A E C / F M transactions should be formalized, populating the system with more transactions; developing an application to 144 acquire the user's preferences for the representation of transaction specifications; and developing systems that use those specifications for actual data exchanges. We divide the potential future work to the following categories: • Multidimensional Formalization System • Transaction representation tools • Analysis of other processes in A E C / F M • Implementation prototypes • Other applications 7.3.1. Multidimensional Formalization System The multidimensional formalization system could be improved in the future by adding more dimensions. The provision of security and other technical characteristics of the web-based data transmission may be added. This will hopefully happen in the future when the environment of A E C / F M has changed and computerization of processes has been accepted in the industry. 7.3.2. Transaction representation tools The representation of transactions could be improved. The use of XPath and X S L offers enormous potential for developing better representations of the formalized transactions and searching capabilities to categorize the transactions based on the users' interests. 7.3.3. Analysis of other processes in A E C / F M Other processes could be analyzed and formalized in different fields of the industry. Related transactions should be identified and defined. The range of fields and the number of transactions within each field is vast, and future work in this field will be very broad and extensive. Transactions resulting from the formalization of processes should be added to the formalized transactions and be used by the implementation prototype or by other applications. 145 7.3.4. Implementation prototype The implementation prototype could be improved by adding numerous features. A possible part is the code checking, which the author intends to implement as part of her future work. Other modules could be added to the prototype system to increase its efficiency. 7.3.5. Other applications Other applications could incorporate functionality for working with the formalized transactions to interact with other users and applications, as demonstrated in the prototype or in additional novel ways. Chapter Summary: In this chapter, a summary of the thesis was presented and the contributions of the research as well as possible future work were discussed. 146 References Abuohagar, T. (1995), "Construction Information System in Paradox", unpublished report, Department of Civi l Engineering, University of British Columbia aecXML (2005), http://www.iai-na.org/aecxml Aouad, G., et al. (1994), "Integration of Construction Information, Final Report", University of Salford. A U C C (2001), "Addressing Accumulated Deferred Maintenance on Canadian University Campuses" http://www.aucc.ca/_pdf/englislVreports/2001/defpro_09_25_e.pdf BPPMTF (2001), "The Building Projects Practice Manual Task Force", http ://ww w .bcproi ectsmanual. com/ Canadian Construction Association (2003), (2004), www.cca-acc.com COMBINE (1995), "Welcome to COMBINE 2", a World Wide Web document at U R L : http://erg.ucd.ie/combine.html Construction Integration Summit (2003), http://www.csinet.org/technic/iii/cisl .pdf, (accessed July 29, 2003) Cooper, R. et al. (1998) "The Development of a Generic Design and Construction Process" European Conference, Product Data Technology (PDT) Days 1998, Building Research Establishment, March 1998, Watford, U K DocLink (2002), http://www.engineering.leeds.ac.uk/civil/research/doclink/ ebXML (2005), http://www.ebxml.org. eCo (2005), http://xml.coverpages.org/ecoFramework.html eConstruct (2003), http://w^ww.econstruct.org/6Public/Summarv/eConstruct_summai'y.htm EDI (1997) IT Construction and Real estate 2002, Implementation in construction and facilities management programme document 1997-12-18 http://www.itbof.com/documents/engelska/Programme97.pdf EDI (2006) Construction industry scheme online - Electronic Data Interchange http://www.hmrc.gov.uk/ebu/edi/cis intro.htm#edi3 147 Egan, J.(1998) "Rethinking Construction: the Report of the Construction Task Force (Egan report)" Office of the Deputy Prime Minister (OPDM) Eastman, Ch. (1999), "Building Product Models" CRC Press L i e , ISBN 0849302595 Fellows, R., and Liu, A . (2003), "Research Methods for Construction", Blackwell Publishing, ISBN 0-632-06435-8 FIATEC (2005) http://www.fiatech.org/ Fowler, M . , Scott, K. (2000), " U M L distilled, second edition, a brief guide to the standard object modeling language", Addison-Wesley Froese, T., Rankin, J., and Y u , K. (1997), "An Approach to Total Project Systems", Computing in Civil Engineering: Proc. of the Fourth Congress, ASCE, Philadelphia, PA, June 16-18, pp. 1-8. Teresa Adams, Ed Froese, T. and Yu, K.Q. (1994), "StartPlan: Producing Schedule Templates Using IRMA", Computing in Civil Engineering: Proc. of the First Congress, ASCE, Vol . 1, pp. 63-70. Froese, T. (1992), "Integrated Computer- Aided Project Management Through Standard Object- Oriented Models", Ph.D. Thesis, Stanford University. Froese., T., (1995), "Models of Construction process Information", Computing in Civil Engineering: Proc. Of the Second Congress, ASCE, Atlanta, GA, June 1995, Vol . 1, pp. 5-12 Froese, T., Yu , K., and Shahid, S.(1996), "Project Modeling in Construction Applications" Computing in Civil Engineering: Proc. Of the Third Congress, ASCE, Anaheim, June 1996. pp. 572-578 Froese, T., and Yu, K. , (1999), " Industry Foundation Class Modeling for Estimating and scheduling", Durability of Building materials and Components 8., Vancouver, May 1999, Vol .4 , pp. 2825-2835 Froese, T., Waugh, L. , and Pouria, A. , (2001), " Project management, 2020 A D " 2001 Conference of the Canadian Society for Civil Engineers, Victoria, B.C. May 30-June 2, 2001. Paper C15. Froese, T., (2003), "Future Directions for IFC-Based Interoperability," Electronic Journal of Information Technology in Construction, Special Issue on IFC-product models for the A E C arena, Vol . 8 (Jul.) 2003, pp. 231-246. http://www.itcon.org/2003/17 . submitted Dec. 3, 2002. 148 Gould, F. E., and Joyce, N . E. (2003), "Construction Project Management" second edition, Pearson Education, ISBN 0-13-048054-1 Halfawy, M . (1998), " A Multi-Agent Collaborative Framework for Concurrent Design of Constructed Facilities", Ph.D. Dissertation, Department of Civil Engineering, The Ohio State University. Halfawy, M . , and Froese, T. (2001), "Leveraging Information Technology Applications in the Canadian A E C / F M Industry", Conference of the Canadian Society for Civil Engineers, Victoria, BC, May 30-Jun 2, Paper A22 Hassanain, M . , Froese, T., and Vanier, D. (2000), "IFC-based Data Model for Integrated Maintenance Management", 8th International Conference on Computing in Civil and Building Engineering (ICCCBE-VIII), Stanford University, California, USA, August 14 - 17, 2000 Hassanain, M . (2002), "Integrated Systems for Maintenance Management", Ph.D. Thesis, Dept. of Civil Engineering University of British Columbia History (2006) http://en.wikipedia.0rg/wiki/Unif1ed_Modeling_Language#History i f cXML (2005), http://ww\v.iai-intemational.org/Model/IFC(ifcXML)Specs.html IAI (2005), http://www.iai-iuternational.org/, and http://cig.bre.co.uk/iai uk/ ISO STEP, International Organization for Standards standard 10303 Jain, Sh., Augenbroe G. (2000), "The role of electronic product data catalogues in design management" CIB W96, Atlanta, 19-20 May 2000 Kang, L . S., and Paulson, B. C.,(1998) "Information Management to Integrate Cost and Schedule for Civil Engineering Projects" Journal of Construction Engineering and Management, September/October 1998, pp 381-389 Karstila, K . and Seren, K. (2005), "Data Exchange Use Case, Architectural Design— Structural Design" PRO IT publications http://www.vtt.fi/rte/cmp/proiects/proit_eng/indexe.htm Khanzode, A. and Fischer, M.(2000), "Potential Savings from Standardized Electronic Information Exchange: A case Study for the Steel Structure of a Medical Office Building" CIFE Technical report#121 http://www.stanford.edu/group/CIFE/online.publications/TR I21.pdf Khedro, T. (1995), "Facility Design and Construction Integration through Cooperative Network Communications", (last accessed March 2002) http://www.stanford.edu/group/CIFE/FCDA/ICCCBE95.html 149 Kiviniemi, A . (2005), "Requirements Management interface to Building Product Models" CIFE technical Report #161, March 2005 http://www.stanford.edu/group/CIFE/online.publications/TR.16i.pdf Latham, M.(1994), "Constructing the Team" Final Report of the Government/ Industry Review of Procurement and contractual Arrangements in the U K Construction Industry HSMO, London Livingstone, D. (2001), "essential X M L for web professionals", Prentice Hall PTR Liebich, T. (2001), " X M L Schema language binding of EXPRESS for i fcXML", IAI Love, P., D. E., Holt, G.D., and L i , H. , (2002), "Triangulation in construction management research" Engineering Construction and Architectural Management, Volume 9, No. 4, pp 294-303 Marcella, A . J., Chan, S. (1993), "EDI Security, Control, and Audit", Artech House Inc. Martin, D., Birbeck, M . , Kay, M . L., Pinnock, J., Livingstone, S., Stark, P., Williams, K. , Anderson, R., Mohr, S., Baliles, D., Peat, B. , Ozu, N . (2000), "Professional X M L " , Wrox Press Ltd MasterFormat (2005), CSI, Construction Specification Institute, Alexandria, Virginia, USA, hUp://www.csinet.org/ MC2 (2004), http://www.mc2-icc.com/ice prod frame.htm (last accessed June 2004) And http://www.mc2-ice.com/popular conversion/popular conversion files/construction_ coding.html Morgan, A . (2005), The Revay Report, Volume 24, Number 1, http://www. revay. com April 2005 NIST (2004), http://flre.nist.gov^frlpubs/build04/art022.html OASIS (2005), http://www.oasis-open.org OCCS (2003), http://www.occsnet.org/ Owen, J. (1997), "STEP: An introduction", Information Geometers Pfeiffer, H. K. C. (1992), "The Diffusion of Electronic Data Interchange", Physica-Verlag Heidelberg Pouria, A . and Froese, T. M . (2001), "Transaction and Implementation Standards in the A E C / F M Industry", proceedings of the 2001 Conference of the Canadian Society for Civi l Engineers, Victoria, Canada, May 2001, paper C43 150 Rosenberg, D., Scott, K. (2001), "Use case driven object modeling with U M L , a practical approach", Addison-Wesley, ISBN 0-201-43289-7 RosettaNet (2000), http://www.rosettanel.org RRR (2002), " Reputation, Risk and Reward: The Business Case for Sustainability in the U K Property sector", a report by the Sustainable Construction Task Force, http://www.dti.gov.uk/construction/sustain/rrnr.pdf Russell, A . D. and Froese, T. M . (1997), "Challenges and a Vision for Computer Integrated Management Systems for Medium Sized Contractors", Canadian Journal of Civil Engineering, Vol.24, No. 2, pp. 180-190 Salford University (1995-1998), "Process Protocol Guide" http://www.sc.ri.salford.ac.uk/pp2/ppguide/keyp.rinciples.htm Shahid, S. (1996), "Use of Information for Problem Resolution on Construction Projects," M.A.Sc. Thesis, Dept. of Civil Engineering, University of British Columbia, April 1996 Shahid, S. and Froese, T .M. (1998), "Project Management Information Control Systems," Canadian Journal for Civil Engineering, Vol . 25, No. 4, 1998, pp.735-754. 1998 Schaufelberger, J. E. and Holm, L. (2002), "Management of Construction Projects, A Constructor's Perspective", Prentice Hall Sokol, P. K. (1989), "EDI The competitive edge", Intertext publications, Inc. McGraw-Hill Book Company Schenck, D., Wilson, P. (1994), "Information modeling: the EXPRESS way", Oxford University press STP (2005), http://www.trek.iibc.ca/research/stp/index.html Sun, M . , and Howard, R. (2004), "Understanding I.T. in Construction" Spon Press, Taylor and Francis Group, ISBN: 0-415-23190-6 Synapticslearning (2002), www.svnapticsl earning, com T D M Checklist (2005), http://www.trek.ubc.ca/research/pdf/TDM checklist02.pdf T D M Questionnaire (2005), http://www.trek.ubc.ca/research/pdf/TDM_questionnaire02.pdf (On line T D M encyclopedia http://www.vtpi. org/tdm/ ) 151 Thamhain, H . J., and Wilemon, D. L. , (1986), "Criteria for controlling projects according to plan" Project Management Journal, XVII (2), pp. 75-81 Thomas, S.R., Tucker, R.L., Kelly, W. R. (1998), "Critical Communications Variables", Journal of Construction Engineering and Management A S C E Vol . 124, N o . l , pp. 58-66 Timberline (2004)Jittp://www.timberline.conVsoftware/estimating/applications/scheduling integrator.as Ex Tolman, F., Bakkeren, W. and Bohms, M . (1994), "Atlas LSE Project type Model", ESPRIT Project 7280-ATLASAVPl/Task 1500 Document D106-Ic, April 1994 Tommelein, I. (1999), "Toward Integrated Product-Process Development: Research Agenda for Life-Cycle Design and Systems Engineering for the A E C Industry" white paper contributed to Berkeley-Stanford C E & M workshop: Defining a research agenda for A E C process/product development in 2000 and beyond, Stanford University and Co organized by University of California Berkeley, August 1999, 7 pp UN/CEFACT (2003), http://www.unece.org/cefact/index.htm. Uniformat (2005), http://www.uniformat.com/background.htiTil , Underwood J., Watson A. , (2002) "An X M L metadata approach to seamless document exchange", http://www.doclink.info/XML%20Metadata%20Document%20Exchange.pdf W3C (2000), http://www.w3.org Watson, A . and Davoodi, M . , (2002), "Transferring Project Documents and Associated Metadata Between Company Document Management Systems and Project Extranets", http://www.engineermg.leeds.ac.uk/civiVresearcli/doclink/More%20Documeuts/Transferr ing%20project%20documents%20and%20associated%20metadata.pdf WinEst (2004), (http://www.winest.com Wix, J. and Liebich, T. (2001), "Information Flow Scenario," Intelligent Service Tools for Concurrent Engineering (ISTforCE), http://www.istforce.coin Yu, K. (2001), "Computer Integrated Construction based on Total Project System framework", Ph.D. Thesis Yu , K.Q. (1995), "Application of Project Information Models to Computer-Integrated Construction", M.A.Sc. Thesis, Department of Civil Engineering, University of British Columbia. 152 Appendix A . l Express EXPRESS defines schemas that are the structure of the data models. Some of the main elements of the Express language are as follows: Types - Every object has a type. Some of the types are predefined such as INTEGER. Entities - The information about an object is described in the ENTITY declaration, which contains the attributes of the entity. The optional DERIVE section describes the attributes that are derived from other attributes while the optional UNIQUE section describes the attributes of the object that should be unique in the model. The optional WHERE section explains about the constraints of the values of each attribute of the entity. Constraints - Constraints could be defined in " R U L E " sections, Entity "Where" sections, or data type definitions. Entities can have instances or can be abstract, which means that no instance of that entity exists. Constraints could be defined by using "Where" or other constraint syntax. EXPRESS-G was created in 1990 to graphically display the models written in EXPRESS and is used for human communication. It is not as complete as EXPRESS: for example, constraints can not be shown in EXPRESS-G. While EXPRESS and EXPRESS-G are used to define the schema, EXPRESS-I is used to define the instances of the model based on the schema (other names for the format for instances of EXPRESS models include "STEP Physical Format", SPF, or "Part 21", referring to the section of the STEP standard that specifies this format). Several software tools exist that are used as EXPRESS parsers, editors, syntax or semantic checkers. (Schenck and Wilson 1994) 153 An Example: In this example a schema is shown in the EXPRESS language and an EXPRESS-G diagram. The schema includes data regarding the load of a riser in a private building. The diagram in figure A . l is the same entity in EXPRESS-G. S C H E M A RiserPrivate ENTITY RiserFixtures NumSimilarFloors: INTEGER; NumUnits: INTEGER; NumKitchenSinks: INTEGER; NumLavatories: INTEGER; NumFlushValveWaterClosets: INTEGER; NumFlushometerTankWaterClosets: INTEGER; NumFlushTankWaterClosets: INTEGER; NumBathTubs: INTEGER; NumShowers: INTEGER; NumDishwashing: INTEGER; NumLaundry: INTEGER; WHERE NumUnits=NumKitchenSinks; END ENTITY Figure A.1 EXPRESS Example 154 RiserFixtures NumSimilarFloors q INTEGER NumUnits q INTEGER NumKitchenSinks q INTEGER NumLavatories q INTEGER NumFlushValvewaterClosets q INTEGER NumFlushometerTankwaterClosets q INTEGER NumFlushValvewaterClosets q INTEGER NumBathTubs q INTEGER NumShowers q INTEGER NumDishWashinq q INTEGER NumLaundry q INTEGER Figure A.2 EXPRESS-G Example A.2 STEP The STEP standard is comprised of many different parts. Parts 1 -9 are introductory. Parts 11-19 are the Description methods parts that describe EXPRESS, a textual conceptual schema language. Parts 21-39 are the implementation methods and conformance testing methodology and framework, which describe the Physical file, Standard Data Access Interface (SDAI), C++, C language bindings, Interface Definition Language (IDL) Binding, and abstract test methods for SDAI. The standard models could be exchanged using the STEP physical file format for simple file exchange or the SDAI for online file exchange. For physical files, the Wirth Syntax Notation WSN is used. Parts 41-99 and 101-199 are considered the integrated resources. Parts 41-99 are the generic integrated resources such as fundamentals of product description and support, geometric and topological representation, and materials. Parts 101-199 are the 155 application-integrated resources such as part 101, which is a general draughting resource that could be used in applications of draughting. Integrated resources are context-independent information models that will be implemented indirectly using an application protocol. The Building Construction Core Model (BCCM), Part 106, is intended to be used as a unifying reference for building construction Application Protocols. Parts 201-299 are the Application Protocols. For each application context, there is an application protocol that uses the integrated resources and is combined with an implementation method. The implementation should be tested for conformance using the abstract test suit and the conformance testing methodology and framework. Parts 225, 228, and 230 are respectively for building elements using explicit shape representations; Building services: heating, ventilation, air conditioning; and Building structural frame: steelwork. In developing an application protocol, the different phases are: defining the scope of the application, the information requirements, Application Interpreted Models development, conformance requirement, and an overview. The information requirements are expressed in the language of the application rather than STEP. There could be an information model that describes the information structure of the application. These requirements are satisfied by interpreting the applicable integrated resources. The application interpreted model includes an EXPRESS schema that should comply with the application information model. Parts 501-599 are the application-interpreted constructs. Some of the integrated resources were used in different application protocols (Owen 1997). STEP standards represent information about products in different industries. The objective is to provide a neutral mechanism to describe product data independent from any specific system throughout the life cycle of the product. 156 A.3 Transaction dimension table The table below shows the dimensions, definitions, examples of dimensions, and to which type of transactions it is applicable. Examples are from request for comment as described in the thesis in which, not all of the message elements were used. Dimension Definition Example Applicable to which types Name Name of the transaction Request for comment Both Definition Definition of transaction This transaction is used whenever the project manager asks the Transportation department for their comment about a project Both Project stage Stage of the project Design Both Transaction type Request response Request response Both Transaction field Field of Transaction Transportation Demand Management Both Purpose Purpose of Transaction To get back the comment of the transportation department about the project in regard to Transportation Demand Management requirements Both Start state The state at which the transaction When the notification of project Has been sent Both 157 starts End state The state at which the transaction ends When the comment is received by the project manager Both Sender role The position of the sender Project manager Both Receiver role The position of the receiver Transportation department Both Transaction U M L model U R L Web address of the U M L models related to the transactions http://www.construction.ubc.ca /transaction_UML_models /request for comment Both Response time Time to respond 2 days Request response Security Required security Medium Both Acknowledge ment If there is a need for acknowledg ement Yes Both Message element 1 The first content item Project name Both Message The second Project address Both 158 element 2 content item Message element 3 The third content item Number of residency units Both Message element 4 The fourth content item Building type Both Message element 5 The fifth content item Number of visitor parking units Both Message element 6 The sixth content item N/A Both Message element 7 The seventh content item N/A Both Message element 8 The eighth content item N/A Both Message element 9 The nineth content item N/A Both Message element 10 The tenth content item N/A Both Message element 11 The eleventh N / A Both 159 content item Message element 12 The twelveth content item N / A Both Message element 13 The thirteenth content item N / A Both Message element 14 The fourteenth content item N/A Both Message element 15 The fifteenth content item N / A Both Message element 16 The sixteenth content item N / A Both Message element 17 The seventeent h content item N / A Both Message element 18 The eighteenth content N / A Both 160 item Message element 19 The nineteenth content item N / A Both Message element 20 The twentieth content item N/A Both 161 

Cite

Citation Scheme:

        

Citations by CSL (citeproc-js)

Usage Statistics

Share

Embed

Customize your widget with the following options, then copy and paste the code below into the HTML of your page to embed this item in your website.
                        
                            <div id="ubcOpenCollectionsWidgetDisplay">
                            <script id="ubcOpenCollectionsWidget"
                            src="{[{embed.src}]}"
                            data-item="{[{embed.item}]}"
                            data-collection="{[{embed.collection}]}"
                            data-metadata="{[{embed.showMetadata}]}"
                            data-width="{[{embed.width}]}"
                            data-media="{[{embed.selectedMedia}]}"
                            async >
                            </script>
                            </div>
                        
                    
IIIF logo Our image viewer uses the IIIF 2.0 standard. To load this item in other compatible viewers, use this url:
https://iiif.library.ubc.ca/presentation/dsp.831.1-0063244/manifest

Comment

Related Items