Idea Transcript
INTEGRATED COMPUTER-AIDED PROJECT MANAGEMENT THROUGH STANDARD OBJECT-ORIENTED MODELS
A DISSERTATION SUBMITTED TO THE DEPARTMENT OF CIVIL ENGINEERING AND THE COMMITTEE ON GRADUATE STUDIES OF STANFORD UNIVERSITY IN PARTIAL FULFILLMENT OF THE REQUIREMENTS FOR THE DEGREE OF DOCTOR OF PHILOSOPHY
By Thomas Michael Froese June 1992
© Copyright by Thomas Michael Froese 1992 All Rights Reserved
ii
I certify that I have read this dissertation and that in my opinion it is fully adequate, in scope and quality, as a dissertation for the degree of Doctor of Philosophy.
Professor Boyd C. Paulson, Jr. (Principal Advisor) Department of Civil Engineering, Stanford University
I certify that I have read this dissertation and that in my opinion it is fully adequate, in scope and quality, as a dissertation for the degree of Doctor of Philosophy.
Professor Raymond E. Levitt Department of Civil Engineering, Stanford University
I certify that I have read this dissertation and that in my opinion it is fully adequate, in scope and quality, as a dissertation for the degree of Doctor of Philosophy.
Asst. Professor H. Craig Howard Department of Civil Engineering, Stanford University
Approved for the University Committee on Graduate Studies:
iii
To Deb
iv
Abstract Computer-Aided Project Management (CAPM) offers ever-increasing potential to improve project management practice, and yet the acceptance of computers within the construction industry remains slow. This dissertation explores new computer technologies that can significantly increase the power of CAPM for construction while simultaneously addressing the accessibility of the software for the typical user. The technological focus is on the complementary areas of project modeling—the rich, general-purpose representation of the project in the computer—and system integration—sharing the computer model among applications (from local to industry-wide). The premises of the dissertation are that CAPM programs create models of construction projects inside the computer, that standard forms of these models should be established, and that systems then can be integrated by requiring all applications to adopt these standard models. There are three specific elements to these standard models. For each one, the dissertation identifies and develops a supporting area of technology: 1.
A Data Model is a formal methodology for representing information in general. This dissertation proposes an object-oriented data model, reviews the emerging technologies of object-oriented programming and object-oriented databases, and develops the SOL object-oriented data model that could standardize data representation for integrated CAPM programs.
2.
A Domain Model or schema expresses relevant project management and construction concepts in the data model. This dissertation proposes standard domain models as a technology for enabling communication among software programs, and it develops the GenCOM domain model that combines both the requirements of typical CAPM applications and the fundamental concepts that make up construction. The domain model presents a series of object-oriented class definitions that can become the software components for building CAPM programs and serve as the universal language for communicating project data and knowledge among integrated applications.
v
GenCOM incorporates thirty-six classes that span most of construction at a high level, and describe cast-in-place concrete work at a more detailed level. 3.
A Project Model or database collects actual project data stored using the data and domain models. This dissertation uses a common project database as the mechanism for sharing data and controlling information flow in an integrated CAPM system. Tests of this approach involved developing a working prototype system, called OPIS, that combines CAD product data, a plan-generation expert system, an estimating program, and a scheduling application around a shared object-oriented project database.
While these technologies—object-oriented data models, data communication through standard domain models, and information sharing through common databases—may be useful individually, they are most promising when blended to form a cohesive approach for developing powerful, highly integrated CAPM software systems. Such systems both increase the capability of the system to support project management and improve the accessibility of the traditional and advanced applications. This research proves that a standard models approach to system integration is possible and that the resulting system offers extreme flexibility and significant integration. The prototype offers the combination of knowledge-based reasoning with traditional applications and demonstrates capabilities not available in traditional CAPM software such as data inheritance and immediate constraint checking. Future work indicated by this dissertation includes the acceptance of general object-oriented data modeling standards, an industry-wide effort to establish standards for construction information, and research into new applications made possible by the system’s integrated project model.
vi
Acknowledgments This dissertation is the culmination of four years of effort. It has been individual work, but it certainly has not been solitary work. I am deeply indebted to the many people that have supported me in my work and my life at Stanford, and whom I can never thank enough. My advisor, Prof. Boyd Paulson, Jr., has offered superb mentorship and a contagious zeal for scholarship. The other members of my committee, Prof. Ray Levitt and Prof. Craig Howard, have consistently provided thoughtful guidance. These faculty, along with Prof. Bob Tatum, Prof. Martin Fischer, and the faculty emeriti of the Construction Engineering and Management Program, have created an environment unique for the enthusiasm, scope, and quality of work it engenders in those of us who pass through it. Many friends and colleagues helped make my work productive and my time rich. They include Paul Chinowsky and Melissa Mullins, Lai-Heng Chua, Geoff Cohen, Don and Kathy Disney, Hossam El-Bibany, Glenn Katz, Lloyd Waugh, Mike Williams, and many others. I appreciate the effort and phone bills of my parents, family, and friends in British Columbia, who worked hard to stay close when we moved far away. I have received financial support for this work from the Stanford Center for Integrated Facility Engineering, the National Science Foundation (Grant #MSM-91-14095), the Canadian Natural Sciences and Engineering Research Foundation, and the Stanford Department of Civil Engineering. Finally, my daughter, Hailey, was born just in time to keep the final frenzy in perspective, and my wife, Deborah, shared it all with me—small apartments, late nights at the office, fishing and golfing trips, long drives home, and California sunshine—and always made it loving and fun. Thank you all!
vii
Brief Contents 1
1. Introduction Research Motivation / Solution Potential / Research Objectives / Reader’s Guide
2. Computer-Aided Project Management— Past, Present, and Future
8
Historical Background / Current Use of CAPM / Areas of CAPM Advancement
3. Integration Through Common Models
21
Computer Programs as Models / Integration Through Models / Industry-Wide Integration / Relationship to Other Research
4. An Object-Oriented Data Model
33
An Object-Oriented Data Model / Concepts in Object-Oriented Programming / Object-Oriented Databases / The SOL Data Model
5. A Domain Model for Project Management and Construction
65
A General Domain Model / Modeling Principles / Fundamental Construction Concepts / The GenCOM Domain Model / The Product Model / The Process Model / The Resource Model / The Organization Model / Example
6. A Project Model—the Core of an Integrated System
105
The Project Model and Integrated Systems / Overview of OPIS System / An Example of Integration in OPIS / System-Level Functionality / The Library Browser / The CADLink Application Interface Module / The AutoPlan Application Module / The InCost Application Module / The InTime Application Module / Reasoning Illustrations / Results from the Prototype
7. Conclusions
126
Benefits of the Proposed Approach / Contributions / Future Work
Appendix I - SOL Class Documentation
135
Appendix II - GenCOM Class Documentation
193
Appendix III - SOL Class Definition and Data Samples
236
Appendix IV - Scheduling and Estimating Object Models
245
List of References
260
viii
Contents Abstract
v
Acknowledgments
vii
Brief Contents
viii
Contents
ix
List of Tables
xiv
List of Figures
xv
1. 1.1. 1.2. 1.3. 1.4.
2. 2.1. 2.2.
2.3.
Introduction
1
Introduction to the Domain: Research Motivation ..............................................................1 Introduction to the Technology: Solution Potential.............................................................3 Introduction to the Research: Research Objectives ...........................................................4 Introduction to the Dissertation: Reader’s Guide................................................................5
Computer-Aided Project Management— Past, Present, and Future
8
Historical Background ........................................................................................................8 Current Use of CAPM ........................................................................................................9 2.2.1. Typical Levels of CAPM Use .................................................................................9 2.2.2. Advanced CAPM Systems in Use........................................................................10 Areas of CAPM Advancement..........................................................................................10 2.3.1. Advancement Trends ..........................................................................................11 2.3.1.1. Rationalization of the Project Management Process.............................11 2.3.1.2. Program Accessibility...........................................................................12 2.3.2. Computer Hardware ............................................................................................12 2.3.3. Graphics..............................................................................................................13 2.3.4. Flexibility .............................................................................................................13 2.3.5. Artificial Intelligence ............................................................................................14 2.3.6. Construction Automation and Robotics ................................................................14 2.3.7. Project Modeling..................................................................................................15
ix
2.4.
3. 3.1.
3.2.
3.3. 3.4.
3.5.
4. 4.1. 4.2.
4.3.
2.3.8. System Integration ..............................................................................................17 Conclusions and Research Goals.....................................................................................20
Integration Through Common Models
21
Computer Programs as Models ........................................................................................21 3.1.1. Conceptualizing Programs as Project Models ......................................................21 3.1.2. Levels of Computer Models .................................................................................22 Integration Through Models..............................................................................................24 3.2.1. Integration Equals Model Compatibility................................................................24 3.2.2. Integration Through Common Models..................................................................25 Industry-Wide Integration .................................................................................................27 Relationship to Other Research........................................................................................28 3.4.1. Integrated Engineering Research.........................................................................28 3.4.1.1. PENGUIN ............................................................................................28 3.4.1.2. KADBASE............................................................................................28 3.4.1.3. The DICE and IBDE Systems ..............................................................29 3.4.2. Model Standardization Research .........................................................................29 3.4.2.1. Object-Oriented Data Model Standardization. ......................................29 3.4.2.2. STEP/PDES ........................................................................................30 3.4.2.3. Project Management Data Standards...................................................30 3.4.3. CAPM Research..................................................................................................30 3.4.3.1. Relational-Database-Centered Systems...............................................30 3.4.3.2. Knowledge-Based Systems for CAPM .................................................30 3.4.3.3. Integrated Object-Oriented Project Management Systems ...................31 3.4.3.4. Object-Oriented Approaches for General CAPM integration.................31 Conclusions .....................................................................................................................32
An Object-Oriented Data Model
33
An Object-Oriented Data Model .......................................................................................33 Concepts in Object-Oriented Programming ......................................................................34 4.2.1. An Object View....................................................................................................35 4.2.1.1. The Software Engineering Point of View ..............................................35 4.2.1.2. The AI or Domain Modeling Point of View............................................36 4.2.1.3. The Database Point of View.................................................................36 4.2.1.4. Summary of the Use of Objects ...........................................................36 4.2.2. Encapsulation......................................................................................................37 4.2.3. Attributes, Methods, Messages, and Polymorphism .............................................37 4.2.4. Hierarchies and Inheritance .................................................................................38 4.2.5. Classes and Instances .........................................................................................39 Object-Oriented Databases ..............................................................................................40 4.3.1. Properties of Object-Oriented Databases.............................................................40 4.3.2. Advantages and Disadvantages of OODBMSs ....................................................41
x
4.4.
4.5.
5. 5.1. 5.2. 5.3. 5.4. 5.5.
The SOL Data Model .......................................................................................................45 4.4.1. Implementation Environment and Database Architecture.....................................45 4.4.2. Objects................................................................................................................47 4.4.3. Libraries ..............................................................................................................49 4.4.3.1. Alternative Approaches........................................................................49 4.4.4. Object Identifiers .................................................................................................49 4.4.4.1. Alternative Approaches........................................................................50 4.4.5. Attributes.............................................................................................................51 4.4.5.1. Alternative Approaches........................................................................52 4.4.6. Methods ..............................................................................................................52 4.4.7. The Broadcast/Subscribe Mechanism..................................................................53 4.4.7.1. Alternative approaches ........................................................................54 4.4.8. Indirect Relationships ..........................................................................................54 4.4.8.1. Independence ......................................................................................54 4.4.8.2. Relationships with Non-Persistent Objects ...........................................55 4.4.8.3. Dynamically-Defined Relationships ......................................................55 4.4.8.4. Separation of General and Specific Models .........................................56 4.4.9. Event Notification ................................................................................................56 4.4.9.1. Change Propagation ............................................................................56 4.4.9.2. Constraint Propagation ........................................................................57 4.4.9.3. Inverse Relationships and Propagation Circularity................................58 4.4.9.4. Event-Driven Reasoning ......................................................................58 4.4.9.5. Transaction Management.....................................................................59 4.4.10. Override Attribute Functions................................................................................59 4.4.11. Inheritance ..........................................................................................................60 4.4.12. SOL Object Persistence ......................................................................................60 4.4.12.1. Library Manager...................................................................................61 4.4.12.2. Hierarchical Data Format .....................................................................61 4.4.12.3. Alternative Approaches........................................................................62 4.4.13. Other SOL Classes..............................................................................................62 4.4.14. Weaknesses of the SOL System .........................................................................63 Conclusions .....................................................................................................................63
A Domain Model for Project Management and Construction
65
The Role of a General Domain Model ..............................................................................65 Developing a General Domain Model...............................................................................66 Modeling Principles..........................................................................................................67 Fundamental Construction Concepts................................................................................68 An Overview of the GenCOM Domain Model...................................................................70 5.5.1. Major Categories of Classes ................................................................................70 5.5.2. Scope of the Domain Model ................................................................................73 5.5.3. Diagrams and examples of GenCOM Classes .....................................................73 5.5.4. High-Level GenCOM Classes..............................................................................74
xi
5.6. 5.7. 5.8.
General Classes...............................................................................................................76 The Product Model...........................................................................................................77 The Process Model ..........................................................................................................81 5.8.1. Construction is a Process ....................................................................................81 5.8.2. Review of Existing Construction Process Representations...................................81 5.8.3. A General Representation of the Construction Process........................................84 5.8.4. Alternative Approaches .......................................................................................89 5.8.4.1. Work Breakdown Structures.................................................................89 5.8.4.2. Versioning............................................................................................90 5.8.4.3. Explicit Goal Representation................................................................90 5.8.4.4. Actions and Method .............................................................................91 5.8.4.5. Replicating the Construction Process ...................................................91 5.9. The Resource Model........................................................................................................92 5.10. The Organization Model...................................................................................................97 5.11. Example ..........................................................................................................................98 5.12. Conclusions .....................................................................................................................99
6. 6.1. 6.2. 6.3. 6.4. 6.5. 6.6. 6.7. 6.8. 6.9. 6.10. 6.11. 6.12.
7. 7.1. 7.2.
A Project Model—the Core of an Integrated System
105
The Project Model and Integrated Systems ....................................................................105 Overview of OPIS System .............................................................................................106 An Example of Integration in OPIS ................................................................................108 System-Level Functionality ............................................................................................109 The Library Browser.......................................................................................................111 The CADLink Application Interface Module ....................................................................113 The AutoPlan Application Module ..................................................................................114 The InCost Application Module.......................................................................................119 The InTime Application Module......................................................................................120 Reasoning Illustrations ...................................................................................................122 Results from the Prototype.............................................................................................125 Conclusions ...................................................................................................................125
Benefits, Contributions, and Recommendations
126
Summary .......................................................................................................................126 Benefits of the Proposed Approach ................................................................................127 7.2.1. Benefits Over Current Technologies ..................................................................127 7.2.1.1. Benefits for Application Developers ...................................................127 7.2.1.2. Benefits for Users ..............................................................................128 7.2.1.3. Benefits for Others.............................................................................130 7.2.2. Benefits Relative to Alternative Approaches ......................................................131 7.2.2.1. Standard Data Models .......................................................................131 7.2.2.2. Communication through Standard Domain Models.............................131 7.2.2.3. Information Sharing though Common Databases ...............................131
xii
7.3. 7.4.
Contributions..................................................................................................................132 Future Work...................................................................................................................133
Appendix I - SOL Class Documentation
135
Appendix II - GenCOM Class Documentation
193
Appendix III - SOL Class Definition and Data Samples
236
Appendix IV - Scheduling and Estimating Object Models
245
List of References
260
xiii
List of Tables Table 2.1:
Contractor utilization of in-house computers (from [Skibniewski 90, p.27])..........10
Table 3.1:
Alternative terminology for the concepts expressed by the data model, the domain model, and the project model.................................................................24
Table 3.2:
Advantages and disadvantages of alternatives for inter-application communication mechanisms ..............................................................................25
Table 3.3
Advantages and disadvantages of alternatives for inter-application architectures or control mechanisms ..................................................................26
xiv
List of Figures Figure 1.1:
Two important themes for future CAPM software development ............................6
Figure 2.1:
Examples of models in CAPM applications ........................................................15
Figure 2.2:
Three levels at which system integration applies within the AEC industry ...........18
Figure 3.1:
Three levels of models that can lead to system integration if standards are developed and applied across various applications in the system.......................22
Figure 4.1:
The NeXTstep Application Kit application-building and user-interfacebuilding classes, shown in inheritance hierarchy (from [NeXT 90, p. 6-5])...........46
Figure 4.2:
The primary SOL OODBMS classes, shown in inheritance hierarchy..................48
Figure 5.1:
The major concepts involved in construction (represented by ovals) and the dependencies between them (arrows show a dependency relationship between concepts) .............................................................................................69
Figure 5.2:
The classes that make up the GenCOM model, shown in inheritance hierarchy ............................................................................................................71
Figure 5.3:
The major categories in the GenCOM domain model for project management and construction, with example classes and instances ..................72
Figure 5.4:
A legend for the object diagrams used throughout this chapter...........................74
Figure 5.5:
Some of the high-level classes that make up the GenCOM domain model.........75
Figure 5.6:
Class diagram for general classes......................................................................76
Figure 5.7:
The GenCOM product model classes .................................................................79
Figure 5.8:
Example instances of the GenCOM product model classes................................80
Figure 5.9:
The GenCOM process model classes.................................................................85
Figure 5.10:
Example instances of the GenCOM process model classes ...............................86
Figure 5.11:
The GenCOM resource model classes ...............................................................93
Figure 5.12:
Example instances of the GenCOM resource model classes depicting resource use ......................................................................................................94
Figure 5.13:
Example instances of the GenCOM resource model classes depicting a resource category hierarchy ...............................................................................95
Figure 5.14:
The GenCOM organization model classes..........................................................98
Figure 5.15:
Sample instances of the GenCOM organization model classes ..........................99
xv
Figure 5.16:
Example libraries and GenCOM instances used to represent a construction activity for placing concrete for a column (part one of four) ..........101
Figure 5.17:
Example libraries and GenCOM instances used to represent a construction activity for placing concrete for a column (part two of four)...........102
Figure 5.18:
Example libraries and GenCOM instances used to represent a construction activity for placing concrete for a column (part three or four) ........103
Figure 5.19:
Example libraries and GenCOM instances used to represent a construction activity for placing concrete for a column (part four of four) ..........104
Figure 6.1:
Overview of major components of OPIS, a prototype integrated Objectmodel-based Project Information System .........................................................106
Figure 6.2:
An example of different application modules’ user interfaces and operations on the shared object-oriented database...........................................108
Figure 6.3:
The main system menu and the System Dock, a user-interface panel that allows users to switch between different applications........................................110
Figure 6.4:
The user interface of the Library Browser application module, including the application menu, the Library Inspector, and the Object inspector. .............112
Figure 6.5:
A sample CIFECAD screen ..............................................................................115
Figure 6.6:
The user interface for the CADLink application-interface module. ....................116
Figure 6.7:
The user interface of the AutoPlan plan-generation expert system. ..................118
Figure 6.8:
The user interface of the InCost application module. ........................................121
Figure 6.9:
The user interface of the InTime application module. .......................................123
Figure 7.1:
A model of the high-level management functions involved in providing and operating a facility, from Sanvido’s Integrated Building Process Model [Sanvido 90].....................................................................................................129
Figure 7.2:
Summary of dissertation objectives, point-of-departure technologies, and contributions.....................................................................................................133
Figure A3.1:
ODS, the Object Design System, is a utility for creating Objective-C and SOL classes, including documentation files......................................................237
Figure A4-1:
Classes for Project Scheduling Based on Primavera Project Planner ...............245
Figure A4-2:
Classes for Project Estimating Based on Timberline Precision Plus .................251
xvi
Chapter 1 Introduction Chapter Abstract: This chapter introduces Computer-Aided Project Management (CAPM), and shows the importance of the technologies of project modeling and system integration for future CAPM advancement. It then describes the basic approach of achieving CAPM system integration by establishing standard models, and introduces the object-oriented technologies used as a foundation for this work. The chapter then outlines the research objectives and gives a reading guide for the dissertation.
1.1.
Introduction to the Domain: Research Motivation
Computer-Aided Project Management (CAPM) for the construction industry brings together a field characterized by rapidly advancing technology, increasing miniaturization, and human-to-computer interaction with a field characterized by time-honored techniques, large-scale machines, and outdoor physical activity. This dissertation evolved from my interest in CAPM. The research addresses construction project management, though the results are broadly relevant to all of architecture, engineering, and construction (AEC), and to project management in other industries as well. Two discordant observations motivated my research within this domain: the potential for improving project management through computers is great and is ever increasing as computer technology continues to advance; yet the acceptance of computers within the construction industry remains, as always, slow. An example of this phenomenon is the application of artificial intelligence (AI) to construction. Although considerable research has focused on this area for over a decade, virtually no AI programs are currently in regular use on actual construction projects. In this research, I investigate how advanced computer technologies can aid project management tasks while maintaining the accessibility of both traditional and advanced computer tools.
1
Introduction
The advancing technologies contributing to the increasing CAPM potential include powerful computer hardware, graphics, AI, automation and robotics, project modeling, and system integration. The most pivotal of these technologies are the complementary areas of project modeling—the rich, general-purpose representation of the project in the computer— and system integration—the sharing of the computer model among applications (from local to industry-wide). This belief is based on the following reasons, which will be argued in more detail in section 2.3.7, section 2.3.8, and throughout this dissertation: •
Project Modeling: — Modeling uses the project itself as a basis for organizing project information in the computer. — The computer can operate on the project model to yield new information about the real project. — Creating a very rich and general representation of the project gives the computer better “comprehension” of the project (i.e., it can represent the data, relationships, and knowledge necessary for applications to reason about the project at a high level). Thus it provides a basis for intelligent processing. — The project model enables the computer to be used for communicating project information. — Project modeling provides a mechanism for system integration.
•
System integration: — Highly integrated CAPM applications are more powerful, more flexible, and better able to assist the project management process than non-integrated applications. — System integration is an enabling technology for other advanced technologies. For example, AI, 3-D graphics, and simulation are all information-hungry applications, and are generally impractical without integrated information sharing. — System integration contributes directly to application accessibility. For example, if a company combines current CAPM tools into a single integrated system (e.g., project estimating, scheduling, cost control, payroll, etc.), the tools will be easier to use because they will have a single computer interface style, and there will be less redundant data entry. However, the company can realize a significant payoff by adding advanced new applications at low incremental financial, lost-time, and human resources costs; much of the data are already in the system, applications
2
Introduction
can be assembled from existing software components, and users already know the system’s interfaces. — System integration is a prerequisite of industry-wide inter-personal computing, i.e., using computers to exchange all forms of information among all project participants. This is expected to be a primary growth area in computer integration. — System integration allows varied applications to use the project model. For these reasons, I have selected project modeling and system integration for CAPM as the subjects of this research, where the term “system integration” refers to a spectrum of application-linking and data-sharing capabilities. These range from joining a single user’s applications into an overall integrated system, to industry-wide electronic information sharing.
1.2.
Introduction to the Technology: Solution Potential
This dissertation proposes the following basic approach for using project modeling to achieve integrated systems: •
I argue that all CAPM applications create and operate on partial models of projects.
•
Each model consists of three elements: — a data model: a formal methodology for representing information in general. — a domain model or schema: the relevant project management and construction concepts expressed in terms of the data model. — a project model or database: the actual project data stored using the data and domain models.
•
System integration, then, can be achieved by making each CAPM application’s models compatible with all others.
•
Model compatibility can be achieved through direct translators and control mechanisms or through global translators and controls. However, I adopt the alternative approach of creating standard models that apply to all applications; thus no translation is required. While this is not the best approach for all situations, it does have many advantages, and aspects of a standards approach bear on all the compatibility mechanisms. This approach requires the following modeling standards:
3
Introduction
— a standard data model: I propose that all CAPM applications adopt a standard object-oriented data model for their basic data-representation scheme. — a standard domain model: I develop a standard set of specifications (class definitions) for representing project management and construction concepts in an object-oriented format. These can serve as a library for creating CAPM applications and as a common vocabulary for exchanging project information. — a common project model: I implement an experimental integrated system in which several traditional and knowledge-based project management applications share a common object-oriented database. The development of these standards in this dissertation draws heavily upon the underlying technologies of object-oriented programming and object-oriented databases (described in chapter 4). These object-oriented technologies offer diverse advantages for software design and implementation. Object-oriented programming reduces software complexity, models the real-world domain at a much higher level, and handles different data types in a uniform manner. Object-oriented databases handle large quantities of complex engineering data more effectively than traditional approaches such as relational databases. Overall, an object-oriented approach makes project modeling and system integration schemes more flexible and powerful, as well as much easier to create. In summary, the basic approach explored in this dissertation is to use standard objectoriented models (data, domain, and project) to integrate CAPM systems.
1.3.
Introduction to the Research: Research Objectives The specific objectives of this research are as follows:
•
To investigate the expected future of CAPM, and to evaluate the role of project modeling and system integration.
•
To develop a conceptual framework, or basic approach, for using project modeling to achieve system integration. This approach, as introduced in the preceding section, involves defining modeling standards that apply across all project management applications.
•
To investigate object-oriented data models and to develop a formal data model for integrated CAPM. I do not recommend that this be adopted as the actual data model
4
Introduction
for all CAPM systems. Rather, it is an experiment in using a basic object-oriented data model, in identifying the specific modeling properties needed to support integrated CAPM, and in learning how to build integrated CAPM systems from a standard objectoriented data model foundation. •
To design a general-purpose domain model or schema for project management and construction. Unlike the data model, the domain model acts as a possible core of an eventual industry-wide object-oriented data standard. The full development of such a standard, however, would require extensive collaboration from all segments of the industry.
•
To implement a prototype integrated system that combines several traditional and knowledge-based project management applications around a central shared objectoriented database. This prototype is intended to test the project modeling and integration ideas presented in this dissertation, to illustrate the approach, and to provide a platform for future CAPM research.
The fulfillment of these objectives will provide some guidance for defining CAPM development directions—particularly the themes of building models of the project in the computer (the models organize project information, allow applications to analyze the project, and support system integration), and of adopting an inter-application view of CAPM software (each application should be one cooperative part in an extensive overall whole). Figure 1.1 illustrates these themes. Pursuing these objectives will also help transfer objectoriented technologies to the arena of project management and construction computing.
1.4.
Introduction to the Dissertation: Reader’s Guide This dissertation is organized as follows:
•
Chapter 2 provides background on Computer-Aided Project Management by reviewing the history and current state of CAPM, and develops the research goals by examining expected and desired development directions for future project management computer systems. The primary research goal is to explore project modeling and system integration for CAPM.
5
Introduction
graphical model
process model
finite element model
Build models of the project in the computer
financial forecasting
scheduling
expert systems
CADD simulation estimating cost control
change-order tracking
document management
materials tracking
View applications as part of a larger system Figure 1.1: Two important themes for future CAPM software development
6
Introduction
•
Chapter 3 presents a conceptual framework for integrating CAPM systems using standard models. It first discusses the role of models in CAPM software and defines the three levels of models that exist in all programs: namely the data model, the domain model, and the project model. The chapter then shows that integration can be achieved by making applications’ models compatible with each other, and describes the alternative mechanisms for achieving this compatibility. The mechanism selected for this research is to establish standard models to be shared by all applications. Finally, the chapter introduces related areas of research.
•
Chapter 4 focuses on the data model, a standard paradigm for representing and communicating information in general. This dissertation proposes an object-oriented data model. This chapter reviews the underlying concepts of object-oriented data models, object-oriented programming, and object-oriented databases. It then presents a specific object-oriented data model—the Shared Object Libraries, or SOL, model— developed as part of this dissertation for use in integrated CAPM systems.
•
Chapter 5 presents the General Construction Object Model, or GenCOM, a project management and construction domain model or schema developed as part of this research. The model is arranged into major categories representing the construction product, the process, the resources, and the project organization. In each category, the model defines classes to represent the basic domain concepts.
•
Chapter 6 describes the Object-model-based Project Information System, or OPIS, a prototype integrated CAPM system that combines several project planning applications around a central project model, or object-oriented database.
•
Chapter 7 completes the dissertation by discussing the conclusions and the contributions of the research.
•
Appendix I contains the full class documentation for the SOL data model classes.
•
Appendix II contains the full class documentation for the GenCOM domain model classes.
•
Appendix III gives an example of a complete class definition using the SOL data model.
•
Appendix IV provides the domain models generated from analyzing traditional CAPM applications. 7
Chapter 2 Computer-Aided Project Management— Past, Present, and Future Chapter Abstract: The subject of this dissertation is computer-aided project management (CAPM). This chapter provides background by reviewing the history and current state of CAPM. It then develops the research goals by exploring expected and desired development directions for future project management computer systems in order to identify technological areas that might best improve the capabilities and accessibility of CAPM. The resulting primary research goals are to explore project modeling and system integration for CAPM.
2.1.
Historical Background
Computer-Aided Project Management (CAPM) employs computers to perform many project management functions. Common areas of CAPM include the following: • • • •
project accounting: payroll general ledger accounts payable accounts receivable job cost accounting estimating scheduling resource allocation
• • • • • •
equipment management inventory control purchasing financial planning engineering and surveying support computer-aided design and drafting (CADD) • general management and administration
The past decade has seen an explosion in commercial CAPM software. Currently, over 1000 vendors claim to offer construction software [Construction 86, p. 5]. The historical development of such applications areas is typified by that for planning and scheduling systems. Prior to the advent of network techniques and “modern project management” in the late 1950s [Fondahl 87], construction planning and scheduling was based mainly on the intuition and expertise of experienced site personnel. This first generation of project 8
Computer-Aided Project Management—Past, Present, and Future
planning [Lichtenberg 74] was superseded by a second generation of network-based, computer-assisted techniques. As these computer systems grew larger and more sophisticated, they also became more opaque and demanding, obscuring the scheduling data and rationale and inhibiting competent human planners. A general dissatisfaction with these inflexible computer systems led to the birth of a third generation of project planning, most notably characterized by the re-ascension of the human planner to the central role, using highly interactive methodologies. In the early 1970s, this third generation appeared in research institutions [Paulson 72, 73], [Lichtenberg 74]; it was later implemented in largescale systems [Paulson 75]; and in the 1980s it formed the foundation of a wealth of microcomputer-based project planning systems [Fersko-Weiss 89]. Although monumental advances have been made in personal computing hardware and graphical interface software, most current project management systems have evolved little in terms of basic approaches to planning, underlying algorithms, and levels of system integration over the past 15 years. The result is that there is often little to distinguish one CAPM system from another. With the exception of a limited number of features such as resource loading, hardware compatibility, enhanced graphics, and the vendors’ perception of “user friendliness,” the programs are functionally very much alike and have not changed dramatically since the introduction of PERT/Cost [Badger 87, p. 100].
2.2.
Current Use of CAPM 2.2.1.
Typical Levels of CAPM Use
For certain construction-related tasks, computer support has become indispensable. In other areas, only small portions of the industry have adopted computer-aided techniques. Table 2.1 summarizes the results of two surveys identifying the extent of computer use by construction companies, including software written by in-house personnel. Note that the date of the survey and the relative size of the contractor population studied must be considered in evaluating this information. It was also reported that: The more advanced uses of computers such as database management, computer communication with field office, computer-aided drafting and design, process simulation, risk analysis, and expert systems were [found to be] virtually unexplored by small contractors [Skibniewski 90, p. 26].
9
Computer-Aided Project Management—Past, Present, and Future
Table 2.1: Contractor utilization of in-house computers (from [Skibniewski 90, p.27]) Software Module
General ledger Accounts Payable/Rec. Payroll Job Cost Estimating Scheduling
1982 survey of general contractors
1988 survey of small contractors ($1 to $3 million annual revenue)
91 % 91 % 91 % 89 % 31 % 10 %
72 % 71 % 91 % 74 % 51 % 22 %
Particularly for small contractors, users’ computer experience is minimal and their management methods are often unsophisticated. It is clear that a high degree of sophisticated computer support is unlikely to be adopted and is probably inappropriate. However, it is also clear that where the advantages clearly outweigh the disadvantages, as with accounting software, computer-supported methods will be widely accepted. 2.2.2.
Advanced CAPM Systems in Use
While the CAPM capabilities of the typical software product and the typical small contractor remain rudimentary, there are both commercial products and sophisticated contractors that are making noteworthy advances. Timberline software, for example, offers software that can link their Precision Collection® array of integrated construction accounting and estimating software with Autodesk’s AutoCAD® drawings for generating estimate line items and quantity takeoffs, and with Primavera’s Project Planner® scheduling software for generating resource-loaded schedules [Timberline 89, 90, 91]. A few large engineering and construction companies, including Stone and Webster and Bechtel, have developed integrated computer systems to support the design and construction of large projects. These systems include 3-D CADD models of the project (with “walk-through” graphical simulation capabilities) that link to large mainframe project databases which, in turn, connect to estimating, procurement, scheduling, and other construction support systems [Killen 89], [Badger 87]. Furthermore, these companies are adding expert systems to their suite of integrated CAPM tools [Livingston 90].
2.3.
Areas of CAPM Advancement
In spite of the underlying uniformity of most commercially available project management systems, the continued advancement of computing technology and the level of 10
Computer-Aided Project Management—Past, Present, and Future
research activity in the CAPM field have led many people to believe that project management systems will be quite different in the near future. This section first identifies two major trends that are anticipated—rationalizing the project management process and increasing the accessibility of CAPM—and then outlines several technological areas in which advancement is expected and desired. These predications are based on a survey conducted by the author and Dr. Lloyd Waugh in which construction academic and industry experts were asked about their expectations for computer usage in construction in the year 2010 [Froese 91], and on many references that discuss the future of CAPM [Badger 87], [Hansen 87], [Ibbs 85], [Ibbs 87], [Levitt 87], [Logcher 87], [Logcher 91], [Mahoney 90], [Paulson 87], [Teicholz 87], and [Thisner 87]. 2.3.1.
Advancement Trends
2.3.1.1.
Rationalization of the Project Management Process
The management of projects is fraught with highly interrelated but contradictory objectives, adversarial participants, and partial, uncertain, incorrect, and frequently changing information. Thus the act of project management remains more of an art than a science, and computers have traditionally been applied to only a small portion of project management tasks. Those who are skillful at this art can often perform it very well. As an art, however, traditional project management is unpredictable, is difficult to optimize, is difficult to learn, and tends to break down with increasing project size and complexity. With the support of the technological advancements described in the following sections, CAPM systems are expected to make the project management practice more rational and engineered. Not only will future computer programs address many more project management responsibilities, but they will do a much better job of accommodating the “nondeterministic” nature of construction, e.g., equipment breakdowns, late material deliveries, components that don’t fit, “activities” that don’t have well-defined start points and predecessors, strikes, storms, design changes, and so on. This rationalization should, as a whole, improve project management performance, decreasing project costs, durations, and uncertainties while increasing quality. As reported in [Froese 91, p. 442], the following are typical responses from construction experts when asked what they think is the most important way that computers will change the way project managers work by 2010: Provide better information [and be] better able to control present and forecast future aspects of operations.
11
Computer-Aided Project Management—Past, Present, and Future
Provide real-time detailed status of construction projects with diagnostics and capabilities to project a future course of actions. Linkage between construction operations and computer models of design and construction will provide much greater analysis and understanding than today’s tools. Informed decision-making will be the norm. Improved decision support (not decision making!) Greatly more reliant on systems than gut feel or experience. Thus computers are expected to provide the information and the analytical tools to allow project managers to act from a much more informed and reasoned position. 2.3.1.2.
Program Accessibility
Computer programs must become more sophisticated to better accommodate the complex project management domain, yet become simpler to accommodate the rudimentary computer skills of the average project management user. These objectives only partially conflict. It is true that companies will not be able to install and support advanced CAPM systems without highly trained computer experts. However, advances in user interfaces, data-collection methods, natural language, uncertain reasoning, graphics, flexibility, configurability, and integration could make these complex systems fairly accessible for the average user. At the same time, the computer literacy of users will continue to increase. Therefore, program accessibility need not preclude complex CAPM systems, as long as it is actively pursued by researchers and developers. Similarly, the quantity and sophistication of CAPM software cannot increase significantly without major improvements in software engineering and management techniques. Fortunately, the level of effort required to develop complex, flexible, and robust applications is excepted to decrease as a result of new programming paradigms such as object-oriented programming (see chapter 4) and new program development tools such as computer-aided software engineering (CASE). 2.3.2.
Computer Hardware
The capabilities of computing hardware and system software will continue to improve rapidly. Significant improvements are expected in processing speed, memory capacity,
12
Computer-Aided Project Management—Past, Present, and Future
computer portability and relative economy, graphical capabilities, input devices, and hardware and basic software connectivity (networking). Computers with unprecedented input/output speed … will come to the user’s desktop sooner than we expect [Ibbs 85, p.62]. [In the year 2010,] computers will be orders of magnitude faster than today and in many cases they will leave the desktop. Their wealth of power will be used for managing information exchange, supporting very high-level programming languages, graphics, and artificial intelligence [Froese 91, p.442]. 2.3.3.
Graphics
Applications of graphics should increase significantly in future CAPM systems, including the following examples: •
Graphical user interfaces interact with users through pictures (including 3-D and animated pictures)—idioms that closely match the way people think about and communicate project information.
•
3-D graphical simulation of projects (possibly using solid modeling, shading, ray tracing, and “virtual reality”) will allow constructors to build prototype projects in the computer before building the actual projects in the field.
•
Graphical representation can be used as a basic data representation scheme (as opposed to numerical or textual representation). Already, some creators of integrated design-construction systems have chosen the 3-D CADD project model as the central structure around which all project data are stored. 2.3.4.
Flexibility
Whereas rigid systems execute predetermined sequences of tasks in an immutable fashion, flexible systems are highly configurable and can perform their duties in many different ways and in arbitrary order. Flexibility is particularly important for CAPM since project management, by definition, involves a dynamic rather than a static domain. The characteristics of most projects change constantly and rapidly. Project management is performed by individuals or small groups who inject a high degree of personal style into the process. These working styles differ dramatically from one team to another, and they change during the life of the project. As a result, the nature of the output required of a project management software tool, the level of detail desired, the amount of time and effort that can 13
Computer-Aided Project Management—Past, Present, and Future
be afforded to the system, and many other characteristics of the system’s environment, vary frequently. New programming technologies are expected to help provide the high system flexibility that is required in this dynamic setting. For example, [Thisner 87] propose a highlevel project management computer language that would allow users to formulate new queries and operations on a central project model at any time. The integrated, objectoriented system proposed in this dissertation is expected to provide significant flexibility. 2.3.5.
Artificial Intelligence
While traditional computer programs have been developed to support the “wellformulated” problems in project management, such as accounting and network scheduling, the majority of project management tasks are much more ill-formulated and are not well suited to traditional computer programs (i.e., they involve information and reasoning procedures that typically are not formally defined or specified). A great deal of research is being done to apply artificial intelligence (AI) and knowledge-based systems (KBS) to project management tasks. Example application areas include plan generation, schedule analysis, time-cost tradeoff analysis, project cost and time problem recognition, method selection, and site layout (see [Dym 91] for a thorough discussion of KBS in engineering). The main advantage of AI systems is that they apply to these ill-formulated problems, and thus allow computer support for a much larger portion of project management tasks. Another benefit of AI systems is that they can evaluate large quantities of computational output and reduce it to the essential results: they produce “more information and less data.” System intelligence also allows reduced input by allowing necessary information to be derived rather than entered. Finally, AI systems can offer the often-cited benefit of capturing and distributing construction “expertise.” 2.3.6.
Construction Automation and Robotics
Future construction projects will experience ever increasing levels of automation, possibly leading to intelligent autonomous robotics [Paulson 85], [Skibniewski 89], [Cusack 90]. The main impact on future CAPM systems will be that automation will require extensive and accurate project data from CAPM systems, and simultaneously will be able to return an unparalleled quantity and quality of information.
14
Computer-Aided Project Management—Past, Present, and Future
2.3.7.
Project Modeling
Existing CAPM systems may use a database to store data about projects. Such systems model some aspect of the project (see section 3.1.1). This project model is the cornerstone of any advanced CAPM system: A common theme observed among the companies in this paper was they all had excellent data bases. …meticulous maintenance of data appeared to be a key factor in the companies’ success with cost and schedule control. The database also permitted sophisticated planning methods in the early stages of a project [Riggs 87, p. 24]. The word “model” is used here very generally to mean “a representation or abstraction of something else.” The model need not be a database; for example, a CADD program creates graphical models of the project, a scheduling program works on temporal models, while an expert system that performs site layout uses logical and spatial project models (figure 2.1). Some models may statically describe project data (which fits the database notion of a model) while others procedurally simulate certain project elements (which might be called an engineering model). Analyzing the model (e.g., costs, strengths, and construction durations) provides estimates for the actual project, and numerous project alternatives can be studied in this way since the model can be created quicker and cheaper than the actual project. Moreover, the model is comprehensible by the computer, whereas the project itself is not. Thus the model is required in order to use computer for project analysis and design, or for communication
CADD
Scheduling
graphical model
temporal model
Site Layout Expert System
spatial model
Figure 2.1: Examples of models in CAPM applications 15
Computer-Aided Project Management—Past, Present, and Future
among project participants. Some specific roles that the model plays in the overall construction process are as follows: 1.
Prototype: Building a model in the computer prior to construction provides a prototype that designers can check for errors and omissions (e.g., pipe interference checking) and can familiarize the construction forces with the project before it is built (e.g., 3-D walk-through CADD).
2.
Planning: Planning also involves building the project in the computer before construction, possibly trying several alternative construction methods. This simulates the actual construction’s outcome (estimating cost, project duration, etc.) and yields a step-by-step plan to guide the actual construction.
3.
Monitoring and Control: Constructors can concurrently use data collected from the construction process to create a model of the project. Comparing this model with the planned model provides feedback on the accuracy of the planned model’s predictions and allows constructors to react to possible problem areas as they appear.
4.
Information Supply: Information gathered from the project design, plan, construction, etc., to create computer models can be made available to any users at any time. Information supplied in this way can be more complete, more consistent, and more convenient than other forms of information, such as written records stored in remote locations but not indexed. Through project modeling, programs can use the actual project as a framework for organizing information in the computer. For example, an object-oriented system may store all data relating to a particular project component in a software object that represents that component in the model.
5.
As-built Information and Post-Project Analysis: The computer models created priorto and during construction can subsequently be used as “as-built” information (e.g., for facility operations and maintenance) and for analyzing the project (e.g., to update a company’s estimating databases).
Future CAPM systems should greatly increase project modeling capabilities. They will store a much greater breadth of data (with an array of new data collection capabilities such as “smart tools” [Demsetz 90] or electronic daily site reporting [Russell 91]), will store data at a much higher and more complex level, and will provide the data to many more uses
16
Computer-Aided Project Management—Past, Present, and Future
(including extensive simulation and optimization). Such systems will maintain very thorough project models. Three-dimensional computer models of the entire built environment will be standard. …this model will be linked to a comprehensive project management software…. This will be the most fruitful research area in the construction industry [Hansen 87, p.47]. 2.3.8.
System Integration
There are many aspects to system integration, including the following: •
Hardware integration or connectivity involves networking all computers. This supports information sharing between systems as well as communication applications.
•
System software and application integration allows programs to interact with each other and allows them to call upon other “support” programs to perform much of the functionality required of a complete application. Advanced operating systems such as NeXT computer’s NeXTstep® and Apple’s Macintosh® System 7.0 contain many mechanisms for inter-application interaction and make a wide variety of services available to any program. This integration allows users to interact uniformly with many individual programs as if they were part of an overall integrated system, which they are. It also allows many different programming technologies (such as traditional programming, AI programs, databases, etc.) to interact and be used collaboratively.
•
Data language integration consists of languages or mechanisms to allow applications to exchange information. This requires compatibility between programs’ basic data representation schemes, domain-specific concept representation conventions, and datasharing control mechanisms (all of which will be discussed in section 3.1.2).
•
Information integration is the actual sharing of information among the various programs, users, and companies involved in a project. Information integration is the most central of the integration concepts.
System integration also applies to the following different levels within the AEC industry (see figure 2.2):
17
Computer-Aided Project Management—Past, Present, and Future
AEC Industry System Application
owners designers suppliers
Application
financiers regulators etc
Industry-Wide Integration
Inter-Application Integration Application
System Inter-System Integration System
Figure 2.2: Three levels at which system integration applies within the AEC industry •
Inter-application integration involves combining all of the CAPM applications employed by a single user or group of users into one integrated system. These applications can then share data and call each other’s procedures.
•
Inter-system integration exists when one group’s applications integrate with those used by other project participants.
•
Industry-wide integration is also required. This would allow any project participant to communicate electronically with any segment of the industry (e.g., owners, designers, suppliers, financiers, regulators, etc.). Industry-wide integration would also ensure consistent inter-application and inter-system integration efforts across different projects.
CAPM requires system integration since project management tasks are inherently integrated; that is, they address many different areas of concern, but these areas are highly interrelated and each deals with the same project and the same body of project-related information. Furthermore, system integration is necessary to make most of the previously described technological advances practical (or even to make them possible). Graphical applications, project modeling, simulation, optimization, AI, automation, and robotics all
18
Computer-Aided Project Management—Past, Present, and Future
tend to be “information hungry.” The only practical way to supply these applications with the input data they require and to manage large amounts of output is to allow the applications to communicate directly with each other and share their data. Enabling many subsystems to share the same pool of information also provides greater data consistency and simplifies programming by allowing all data to be treated in a uniform manner. Integration also bridges the two trends of increased rationalization and accessibility, since advanced applications that have direct access to each other’s functionality and information can become more autonomous from the user, while characteristics such as uniform user interfaces simplify the interaction that the system does have with the average user. Many researchers have stressed the importance of integration in future systems: Our future systems will be far more integrated and deal in a common manner with all types of project, environment, organizational and other types of data, using knowledge to integrate and utilize the data [Logcher 87, p. 86]. We believe that much of the future research and development of expert systems in construction will involve hybrid systems combining expert systems with database management systems and computational systems [Levitt 87, p. 110]. Project Management functions will be better supported by computers by allowing a project team to communicate from a common database and interface instantaneously [Thisner 87, p. 39]. The most significant development that will occur over the next 20 years will be the integration of design, construction, and management of the constructed facilities. [One of the most important developments will be] fully implemented vertical/lateral transparent connectivity between major systems and database depositories (responses from construction experts as reported in [Froese 91, p. 439]). Computers will be transparently interconnected to the extent that telephones are today. Most project information will be available to all project participants and its exchange will be facilitated by the use of intelligent data objects and industry-wide information standards…. Our overall conclusions from this study are that the computer will support future project management in the following three roles: First, the computer will be a supplier of, and medium for, information. Second, it will act as a device for multimedia communication and coordination. Third, the computer will be used for processing information. While information processing will be absolutely vital (an enormous amount of processing will be required just to access, filter, and refine information), it will no longer play the dominant and often sole role that it does today.
19
Computer-Aided Project Management—Past, Present, and Future
Another conclusion is that in twenty years, the hardware and basic software capabilities of computers will, without doubt, be awesome. However, progress that requires united industry-wide cooperation—such as standard data exchange models—is less certain [Froese 91, pp. 442-42].
2.4.
Conclusions and Research Goals
Section 2.2.1 showed that contractors will readily accept software tools if they are convinced that the advantages will clearly outweigh the disadvantages, but this currently encompasses only a small number of applications. The intent of this dissertation is to increase this number by exploring technologies that improve CAPM’s ability to support project management practice while also addressing the software’s accessibility. Section 2.3 described several candidate technologies, including advances in hardware, graphics, software flexibility, AI, and construction automation and robotics. However, I chose to focus on project modeling and system integration. As this dissertation will show, these two technologies are tightly interrelated since project modeling provides a mechanism for achieving system integration while system integration allows applications to exploit project models. Moreover, I believe these to be the most critical technologies for advancing CAPM to a new generation of computer tools. The research objectives, then, are to study project modeling and the various levels of system integration, to explore and develop technological alternatives for modeling and integration, and to identify important lessons for the industry as a whole. Chapter 3 describes the more specific objectives that arise from the methodology proposed in this dissertation.
20
Chapter 3 Integration Through Common Models Chapter Abstract: This dissertation explores project modeling and system integration for computer-aided project management. This chapter presents the conceptual framework for integrating CAPM systems. It suggests that, conceptually, all project management software programs create and operate on models of the actual construction project. More specifically, all software contains a data model or paradigm for representing data in general, a domain model or explicit terminology for representing domain concepts using the data model, and a project model or physical instance of the project-related information. Integration is achieved by making different applications’ models compatible with each other, and by enabling different applications to exchange their models. Taken together, the models used by a set of applications form a complete, robust, and generally useful computer model of the domain. This chapter compares alternatives for achieving this, and proposes standard models that all integrated applications can share. Finally, this chapter outlines the relationship of this approach to other CAPM and integration research.
3.1.
Computer Programs as Models 3.1.1.
Conceptualizing Programs as Project Models
Conceptually, all CAPM programs construct and operate on models of the physical project. This view is justified by the observation that all project management programs represent and manipulate data relating to the project, and any collection of project data describes or represents some aspect of the physical project—i.e., the data make up a model of the project. Furthermore, all computer programs used for a project (e.g., CADD, structural design and analysis, specification writing, estimating, scheduling, project accounting, etc.), if considered as a whole, make up a fairly complete computer model of the project. This approach uses the general definition of a “model” described in section 2.3.7.
21
Integration Through Common Models
The next section discusses more formal and specifically defined models and shows how this view of applications’ models leads to an approach for system integration. 3.1.2.
Levels of Computer Models
The previous section defined “model” to refer generally to any representation of the actual project. However, at least three more-specific types or levels of models exist in all CAPM computer programs. Figure 3.1 depicts these three levels of models: 1.
The Data Model establishes a paradigm for representing data in general. An example is the relational data model used in relational databases. A relational data model is a formally defined data representation scheme that uses relations or tables of data elements to store information. This research in integrated CAPM systems selects an object-oriented data model because of the programming efficiency and representational
1. Data Model
Class
Instance: Object Attribute Attribute Value
2. Domain Model (Schema)
C
Concrete Column width height
3. Project Model (Database)
B-1 C-1
C-2 width=0.900m height=3.100m
Figure 3.1: Three levels of models that can lead to system integration if standards are developed and applied across various applications in the system 22
Integration Through Common Models
richness that it offers. This model dictates that information be represented in the form of objects which are instances of classes, which have various data attributes, which can inherit properties from other objects, and so on. Currently, there is no common “standard” object-oriented data model. Chapter 4 discusses data models in greater detail and proposes and object-oriented data model for integrated CAPM. 2.
The Domain Model or schema is an explicit terminology or description of how to represent the elements of the domain in terms of the data model. For this research, the domain model is the definition of the classes that represent construction-related information. These class definitions make up a logical model of the domain. Chapter 5 proposes a domain model for project management and construction.
3.
The Project Model or database expresses the actual data (“instances” in an objectoriented system) relating to a specific construction project in terms of the domain and data models. These data describe aspects of specific projects, and thus form models of the projects themselves. Furthermore, the model is a computational project model because applied operations can yield useful information, such as evaluating each project component to determine the estimated project cost or analyzing actual activity completion dates to predict future project schedule performance.
These three levels of models refer to concepts common to many software specialty areas. Table 3.1 shows different terminology that might refer to the same concepts. The multiplicity of terms can be confusing. The terminology used here arises from the dissertation’s emphasis on models in CAPM and from an attempt to provide an accurate label for the three levels. While the term “data model” is well defined in database theory, other references to models in computer programs split between those that imply semantic representations of a body of knowledge (a domain model in this dissertation), and those that imply a specific data set (a project model here). This dissertation sometimes refers to these two modeling levels as the “schema” and the “database,” respectively, to reinforce their meanings.
23
Integration Through Common Models
Table 3.1: Alternative terminology for the concepts expressed by the data model, the domain model, and the project model Database Terminology
Traditional Software Engineering Terminology
Object-Oriented Programming Terminology
AI Terminology
data model
data representation
object-oriented language
knowledge representation scheme
Domain Model
schema
data structures
classes
ontology
Project Model
database
data
instances
knowledge base or assertions
Data Model
3.2.
Integration Through Models 3.2.1.
Integration Equals Model Compatibility; Alternative Methods
Given that the data contained in a program make up a model of the real-world domain (i.e., a construction project), system developers can achieve software integration by ensuring that the models used by various applications are compatible with each other, that different applications can exchange their models, and that—taken together—the models used by a set of applications form a complete, robust, and generally useful model of the domain. Normally, applications can use any suitable approach for data representation, domain modeling, and data storage. However, to enable information sharing, mechanisms must be in place for moving data between applications: both a protocol to allow the applications to communicate and an architecture or control strategy that informs applications where and when to locate information. Basic alternatives for communicating data between applications [Abdalla 89, pp. 5-10] are direct translators in which each application contains a translator for every other application with which it must communicate; neutral format translators in which each application contains a translator to some global communications standard format (often called a “neutral file format”); and common models in which each application adopts common modeling schemes so that no translation is required between applications. Table 3.2 outlines the relative advantages and disadvantages of each alternative. Similarly, basic alternatives for an integrated architecture or control mechanism are a distributed architecture in which each application maintains responsibility for communicating
24
Integration Through Common Models
Table 3.2: Advantages and disadvantages of alternatives for inter-application communication mechanisms Communication Alternative
Advantages
Direct translators 1. Modeling flexibility 2. Translation direct and fast
Disadvantages 1. Large number of translators required 2. Application interdependence 3. Model incompatibilities between applications 4. Difficult maintenance (if one application is changed, all others must be modified)
Neutral format translators
1. Modeling flexibility 2. Application models are independent of each other
Common models 1. Application models are independent of each other
1. Model incompatibilities between applications and neutral format 2. Difficult development of generalpurpose neutral file format 1. Difficult development of generalpurpose common model
2. Fast and direct (no translation required) 3. No model incompatibilities
directly with any other application when they deem it necessary; a central blackboard or controller mechanism in which all applications communicate with a central control component, requesting it to provide specific information from another location or informing it about some event that may be relevant to other applications; and a shared central database where applications physically share a single copy of all data in a shared project database. Table 3.3 compares the relative advantages and disadvantages of these alternatives. 3.2.2.
Integration Through Common Models
Tables 3.2 and 3.3 show that no communication and control mechanisms are clearly superior for all situations, but shared-model approaches offer enough advantages to be further investigated in this dissertation as the primary information-sharing mechanisms for integrated CAPM systems. Furthermore, future integrated systems will likely continue to use all three of these approaches, but the communication and translation mechanisms will form a software layer that will be largely transparent to users and application developers who will be able to operate as if there were only a single set of modeling standards. This, then, is the central approach proposed in this dissertation: that CAPM system integration can be
25
Integration Through Common Models
Table 3.3 Advantages and disadvantages of alternatives for inter-application architectures or control mechanisms Architecture/ Control Alternative Distributed system
Advantages
Disadvantages
1. No global administration required
1. Application interdependence
2. Simple for small systems
2. Difficult to maintain data consistency 3. Complex for medium to large systems
Central blackboard or controller
1. Applications are independent of each other
1. Difficult to maintain data consistency 2. Central controller required 3. Central controller may be dependent on each application
Shared database 1. Applications are independent of each other
1. General-purpose central database must be developed
2. Internal operation of each 2. Excellent data consistency since application must conform to there is a single representation of central database mechanisms and all data and traditional database are subject to database overhead consistency mechanisms are used (e.g., locking, backups) 3. Reliance of physical connection to central database 3. Timeliness of data sharing since changes by one application 4. Possible interference among users instantly apply to all others because of record locking, etc. 4. Uniform characteristics across system 5. Reduced application development and size since data storage and exchange mechanisms are shared
achieved by using standard models. More specifically, integrated systems should consist of applications that adopt common data, domain, and project models. 1.
A Common Data Model: By adopting a common data model, applications can be assured that the information they exchange at least will be structurally or syntactically compatible. A data model standard also permits standard languages both for defining how domain elements appear in the data model (a data-definition language) and for communicating specific data values (a data-exchange language).
2.
A Common Domain Model: If different applications that share a common objectoriented data model also adopt a standard domain model or schema, they can properly interpret the object information that might be passed between them. For example, a standard object-oriented domain model that defines an “activity” class will enable 26
Integration Through Common Models
different applications to understand that an “activity” object refers to a specific construction operation and that it has an associated duration, set of predecessor activities, etc. The development of a general domain model for construction and project management is one of the primary objectives of this research and is described in chapter 5. 3.
A Common Project Model: Typically, every computer application maintains its own data or project model. Different applications that share a common data model and schema can readily exchange elements of their project models between themselves. By designing applications to also share a common project model or central database, however, a single comprehensive model of the project exists and any changes made to the data by one application automatically and instantly apply to all other applications. Integration, then, is a fundamental and automatic characteristic of the system architecture.
Within the integrated system proposed in this dissertation, most applications will be created or altered to adopt the common models. However, applications utilizing other models can participate in the integrated system through translators that allow them to interact with the common modeling standards. Thus existing stand-alone programs can tie into the integrated system.
3.3.
Industry-Wide Integration
The approach of using common models applies to each of the three levels of system integration introduced in section 2.3.8: •
Inter-application integration: The immediate focus of this dissertations’ shared data, domain, and project models approach is the integration of all applications used by a single project management team. The proposed technology is sufficiently mature to implement such a system today.
•
Inter-system integration: The proposed technology could also help integrate the computer systems used by all project participants. However, this would also require a level of organizational and managerial coordination among the participating companies and agencies that is currently rare on construction projects.
•
Industry-wide integration : The long-term objective of this dissertation is to promote general industry-wide integration. In the future, any piece of AEC software should
27
Integration Through Common Models
have high compatibility with any other, and any AEC company should be able to routinely exchange project data with any other. There will be no single shared database for all companies, but many general access databases may exist, e.g., bidding databases, materials supplier directories, etc. Data and domain modeling standards are required for such integration. The standards discussed in this dissertation apply equally to individual corporate system integration and to industry-wide integration.
3.4.
Relationship to Other Research
This section outlines the relationship between this dissertation’s approach of using common models to achieve CAPM system integration and related integration, standards, and CAPM research efforts. Detailed descriptions of other research and comparison with the proposed approach are provided later in the dissertation, as noted below. 3.4.1.
Integrated Engineering Research
The following research projects typify various approaches being investigated to support integrated engineering support systems. 3.4.1.1.
PENGUIN
The PENGUIN system [Law 90] is an architecture that allows multiple engineering applications to share object-oriented data, but the objects are customizable for individual applications and they use a relational database as the underlying data-storage mechanism. Applications use objects called View-Objects that represent domain entities in a form designed specifically for that application (e.g., a CADD application would use View-Objects that focused on the graphical attributes of components). View-Objects map to information stored in a central relational database. Thus, while this approach uses a shared database to achieve integration, it differs from this dissertation’s approach since it uses translation from individual applications schemas to a global database schemas rather than using one overall standard. Furthermore, this translation is from an object-oriented representation to a relational one. 3.4.1.2.
KADBASE
The KADBASE system [Howard 89b] illustrates an integration approach that uses a central controller and translator instead of using standard models. In this system, the data
28
Integration Through Common Models
and domain models for different applications must be compatible (i.e., any one must map to another), but they need not be the same. Some global domain model or schema is still required. Applications integrated through KADBASE typically maintain their own data or project model, but extensive data sharing is possible. The project management elements of KADBASE’s domain model derive from the OARPlan system (discussed in section 5.8.2), and these data are not currently shared with any other applications. 3.4.1.3.
The DICE and IBDE Systems
DICE (Distributed and Integrated environment for Computer-aided Engineering) [Sriram 89a] [Sriram 90], developed at the Massachusetts Institute of Technology, and IBDE (Integrated Building Design Environment) [Fenves 90], developed at Carnagie Mellon University, are both integrated building design systems. Both systems comprise a number of applications (typically knowledge-based programs) integrated through a shared project database and a blackboard control structure. Both establish standard data models: DICE’s based on the GEMSTONE object database system [Bretl 89] and IDBE’s based on a relational database underlying an object-oriented data model. Both systems also define standard domain models which focus primarily on the product or structure, not on the construction process (with the exception of the PLANEX component of the IDBE system [Hendrickson 87]). Finally, both systems use a shared project database, though only projectspecific data are kept in this shared database; project-independent information is maintained in the individual application modules as specific application knowledge. 3.4.2.
Model Standardization Research
The technological approach to integration adopted in this dissertation is to standardize data, domain, and project models. Standardization enables integration not only throughout a single computer system, but also throughout the industry in general. The following efforts to produce modeling standards are relevant to this dissertation: 3.4.2.1.
Object-Oriented Data Model Standardization.
No widely accepted standard object-oriented data model yet exists (see chapter 4). However, various efforts currently underway to develop such standards, if successful, will significantly improve the integration potential of all object-oriented systems implemented across a wide range of languages and platforms. Examples of groups working to establish object-oriented standards are the ANSI SPARC OODB Task Group [Kim 91] and the
29
Integration Through Common Models
Object Management Group (OMG) [Atwood 91]. Object-oriented data model standards will be discussed in section 4.1. 3.4.2.2.
STEP/PDES
The International Standards Organization’s (ISO) Standard for the Exchange of Product model data (STEP) effort, called the Product Design Exchange using STEP (PDES) project in the United States, is a major international effort to establish standards for communicating product data [Warthen 88]. This specification will include standard data models (for use as exchange languages, not necessarily as internal representation models) and standard domain models or schemas for a wide variety of product and facility domains. STEP/PDES models have been initiated for buildings [Gielingh 88], [Gielingh 91]. These models are discussed further in sections 4.1, 5.4, 5.7, 5.8.4.3, and 7.4. 3.4.2.3.
Project Management Data Standards
Little research has been done to establish standards for project management and construction data. The MASTERFORMAT [Hartman 87] is a widely accepted construction standard, but it is used predominately for codifying construction specifications (see section 5.1). A few examples of flat-file scheduling data standards do exist [Corps 89a, 89b], but these have little to offer for advanced systems. Chapter 5 presents the data model for project management developed in this dissertation. 3.4.3.
CAPM Research
3.4.3.1.
Relational-Database-Centered Systems
Most current integrated CAPM systems build on relational database technology. Research continues in the area of relational database technology for integrated CAPM (see [Rasdorf 91] for a review of previous construction integration approaches, and [Abudayyeh 92] for an example of an advanced relational-database approach). The construction schemas or domain models of such systems have some bearing on the domain models for objectoriented systems, and are discussed in section 5.8.2. 3.4.3.2.
Knowledge-Based Systems for CAPM
Many researchers are investigating the application of knowledge-based systems (KBS) to a wide variety of project management problems, as described in section 2.3.5. Some of these systems currently use some degree of integration. For example, OARPlan [Darwiche 30
Integration Through Common Models
88] and COKE [Fischer 91] both operate on object-oriented data extracted from CIFECAD export files (see section 6.6). Many applications included in future integrated CAPM systems most likely will be KBSs. Several of these KBS research projects have been used as input to the domain model and the plan-generation application module of the proposed system (see sections 5.8.2 and 6.7, respectively). 3.4.3.3.
Integrated Object-Oriented Project Management Systems
One of the first researchers to suggest object-oriented programming for CAPM applications was Logcher [Logcher 87], [Brisson 87] and [Nasrallah 89], who suggested that using objects to represent activities would allow scheduling to be performed by message passing rather than by traditional CPM algorithms. Each activity could then position itself in time based on predecessors, on resource availability, or on other criteria, but this would be determined by the activity alone and would not require any modification to the overall scheduling calculations. Several recent research projects have focused on using objectoriented programming techniques to create integrated project management systems [Fischer 91], [Ito 91], [Kartam 91], [Yamazaki 91], and [Yau 91]. These projects often focus on AI techniques or shared project databases in addition to object-oriented programming technologies. Unlike the approach proposed in this dissertation, these systems typically aim to combine a specific set of functions into one integrated system rather than to provide a general, open-ended integration approach that can accommodate any number of project management applications. 3.4.3.4.
Object-Oriented Approaches for General CAPM integration.
A few researchers have studied general object-oriented models for construction. Sanvido has created an extensive model of the building process called the Integrated Building Process Model (IBPM) [Sanvido 90] (see sections 5.8.2 and 7.2.1.2). However, this represents the functions and information flows in the building process rather than modeling the information itself, and it is not intended as the basis for any specific software application. Björk and Penttilä [Björk 89, 91] have developed integration models for representing buildings and they have discussed models to represent the construction process itself, but they have not developed a construction process model. Research by Grobler [Grobler 88] focused on developing a general object-oriented approach for integrated CAPM. Grobler proposed a solution that is similar to, but less developed than, the approach in this dissertation (see section 5.8.2).
31
Integration Through Common Models
3.5.
Conclusions
The basic conceptual approach proposed in this dissertation is to build integrated systems that adopt common data, domain, and project models. Not only should data and domain modeling standards be established for a given integrated system, but they should prevail throughout the industry. The remainder of this dissertation explores suitable standards for all three of these modeling levels. Chapter 4 describes the characteristics of object-oriented data models and develops a data model in order to explore the capabilities necessary to support integrated CAPM; chapter 5 develops a general domain model for project management and construction that could serve as the core of an eventual industry standard; and chapter 6 describes the shared project model and overall architecture of the prototype integrated CAPM system implemented as part of this dissertation.
32
Chapter 4 An Object-Oriented Data Model Chapter Abstract: The first requirement for integration is a common data model; that is, a standard paradigm for representing and communicating information in general. This dissertation proposes an object-oriented data model. This chapter reviews the underlying concepts of objectoriented data models, object-oriented programming, and object-oriented databases. It then presents a specific object-oriented data model—the SOL model—for use in integrated CAPM systems.
4.1.
An Object-Oriented Data Model
Chapter 3 showed that the first step in using common models for CAPM integration is to establish a common data model—that is, a standard paradigm for representing and communicating information in general. This dissertation proposes that an object-oriented data model be used because of the advantages presented throughout this chapter. The data model must be very expressive and powerful; yet, more importantly, it must be readily accessible to all CAPM developers and users and must be compatible with systems from other related industries. For these reasons, it is strongly recommended that a major industry-standard data model be adopted as the standard data model for integrated CAPM. Unfortunately, no such industry standard currently exists for object-oriented approaches. At present, object-oriented systems’ data models are dictated by the languages, databases, or programming environments used to construct the system. However, several major object-oriented data model standards currently are being developed, including the following examples: •
A primary force for establishing object-oriented standards is the Object Management Group (OMG), “an international organization of information systems vendors, users, and researchers dedicated to promoting industry standards for object-oriented
33
An Object-Oriented Data Model
software development within networked computing environments [Atwood 91, p.8].” •
The ANSI SPARC OODB Task Group is also working towards a reference data model for object-oriented database systems [Kim 91].
•
The STEP/PDES organization (see section 3.4.2.2) endorses and uses the EXPRESS data modeling language [Schenck 90], [Eggers], but this is a schema definition and data exchange language, not a full OODBMS standard (e.g., it includes no specification of concurrency requirements) and its capacity for defining methods is limited.
•
Object-oriented standards should also arise from an alliance between IBM and Apple Computer [Farber 91]; however, these standards—anticipated in the mid-1990s— may deal more with object-oriented operating systems, inter-application mechanisms, and hardware than with general data models.
With so much activity in this area, general object-oriented data model standards are expected to be completed by late 1993. These standards should provide all of the characteristics needed to support integrated CAPM, and most commercial object-oriented databases are likely to adopt these standards as their fundamental data models. Meanwhile, an object-oriented data model for integrated CAPM has been developed as part of this dissertation. This model is not recommended as the actual data model that should be adopted for all integrated CAPM systems. Rather, it is an experiment in using a basic object-oriented data model, in identifying the specific modeling properties needed to support integrated CAPM, and in learning how to build integrated CAPM systems on a standard object-oriented data model foundation. This chapter discusses the concepts underlying object-oriented data models by first outlining the fundamentals of object-oriented programming (section 4.2), then describing the properties of object-oriented database management systems (section 4.3), and finally presenting the SOL data model (section 4.4).
4.2.
Concepts in Object-Oriented Programming
Object-oriented programming (OOP) currently receives a great deal of attention within the computer science community. New OOP languages are being created, existing 34
An Object-Oriented Data Model
languages are being given object-oriented characteristics, object-oriented versions of tools and environments such as databases and AI shells are proliferating, and many new applications are claiming object-oriented functionality. Several characteristics are generally associated with OOP, but no consensus has developed as to OOP’s exact definition. Most OOP languages offer many of these characteristics, but few offer them all. This section outlines the key OOP characteristics. More complete discussions are available in many texts such as [Cox 86] and [Booch 91] and articles such as [Dodani 89], [Thomas 89], and [Wegner 89]. 4.2.1.
An Object View
The fundamental concept underlying object-oriented programming is that software is organized into pieces, called objects, rather than processes. OOP is analogous to thinking about a car in terms of its components (engine, chassis, wheels, etc.) rather than its processes (e.g., accelerating, braking, steering, etc.). The objects have behavior which is defined in a context. The context is defined by “structural” relationships between the objects; and the system’s behavior emerges from an aggregation of its component objects’ behavior in their structural context. The car’s behavior, then, results from the interacting behavior of its engine, transmission, steering box, tires, etc. [Levitt 90]. Objects can be thought of as a way of combining software code and data into a single package. Several quite different but compatible reasons for organizing software into objects arise from three different points of view: software engineering, AI, and database. 4.2.1.1.
The Software Engineering Point of View
From a software engineering point of view, the underlying idea of objects is that importance lies in what operations can be applied to data, not in how these operations are performed or how the data is represented. An abstract data type—the object—is therefore defined in which the description of operations is public, but the representation and implementation details are kept private. This approach enforces the grouping of functionality with data and the separation of interface from implementation; this localizes much of the programming detail and data control, thereby minimizing programming complexity through reduced code “surface area” (the portion of a code segment that is visible to, and that must be understood by, other parts of the program). Advantages of this reduced software complexity, increased modularity, and increased component independence include easier prototyping, improved code reusability, shorter development times, and simplified software maintenance and upgrade. 35
An Object-Oriented Data Model
4.2.1.2.
The AI or Domain Modeling Point of View
In contrast to the software engineering field, OOP has become popular in AI work and in engineering systems because each object can represent some object or concept in the real-world. Thus object-oriented software constitutes a high-level functional model of reality, which lends itself well to knowledge-based processing. People work with problem-domain concepts, while hardware works with different (operator/operand) concepts. Some of the conceptual burden in translating from problem-domain to computer-domain should be carried by the machine, by making the machine work in terms of concepts closer to the user’s everyday world [Cox 86, p.31]. Symbolic models explicitly represent the structure and function of modeled systems, and they may be used for multiple purposes. Although initial creation of a symbolic model may take longer than creating a simple single expert system, symbolic modeling minimizes knowledge system life-cycle costs because it facilitates creation and extension of multiple related applications. Models support multiple uses and users and facilitate change and extension of applications. Object-oriented representation is a powerful technique to use in creating models [Kunz 88]. 4.2.1.3.
The Database Point of View
Finally, objects are being embraced for some database efforts because the database manager software can treat each object in a uniform manner, even though each object may contain very different data types (e.g., character fields, graphics, sounds, etc.). Using a single general data type (the object) has significant advantages over other database approaches such as relational databases for certain types of applications, as section 4.3 will show. 4.2.1.4.
Summary of the Use of Objects
To summarize, the rationale behind the use of objects is that, from a software engineering point of view, they provide an efficient, detail-hiding data abstraction; from an AI perspective, they provide a high-level representation of real-world entities; and for databases, they provide a general data type that allows very different forms of data to be treated in a uniform way. While these three motivation are quite distinct, they prove to be very compatible. Moreover, all three approaches contribute to an overall change in the way of thinking about computer programs in which software is conceptualized as components rather than processes. 36
An Object-Oriented Data Model
4.2.2.
Encapsulation
From a software engineering point of view, the emphasis of OOP is on reducing software complexity by organizing data and code into software objects. Encapsulation further strengthens the concept of objects by stating that an object’s data cannot be accessed directly—all interaction must be through the object’s procedures. In OOP languages that support encapsulation, the description of an object’s procedures is made public (in the object’s interface) while the details of how data and procedures are implemented are kept private (in the object’s implementation). [Object-oriented programming offers] several new tools and concepts that can help to produce software that is far more tolerant of change. Encapsulation is the foundation of the whole approach. Its contribution is restricting the effects of change by placing a wall of code around each piece of data. All access to the data is handled by procedures that were put there to mediate access to the data. By contrast, conventional programming makes the consumer of each operand responsible for choosing operators that are type-compatible with the operand on hand. Object-oriented programming moves this responsibility from the consumer and onto the operand and its supplier. These encapsulated operands are called objects. Whereas consumers once specified how each operation should be performed by naming specific code, they now specify only what should be done, leaving it to the object to choose code that is appropriate to its type or class [Cox 86, p.8]. 4.2.3.
Attributes, Methods, Messages, and Polymorphism
In OOP, an object’s data are sometimes called its attributes, while the code or procedures that operate on the object and its related objects are called its methods. Interaction with objects is performed by sending them messages that trigger their methods. Messages can provide data to an object, request that an object return data, or instruct an object to perform some action. Typically, the sender of the message is concerned only with an object’s response and is neither aware nor interested in the exact mechanisms triggered by the message. In fact, different objects can respond to the same message in very different ways. This characteristic, called polymorphism, can treat diverse types of objects in a very uniform manner. For example, different objects could be created to represent different types of construction activities, and each one could be given a “start date” method that returned its expected starting date. Some activities might use CPM precedents to determine their start date, some might use resource availability, and some might rely on contractual stipulations; however, the user or other object that sent the “start date” message need know none of this. 37
An Object-Oriented Data Model
4.2.4.
Hierarchies and Inheritance
In OOP, objects are normally organized into hierarchies (directed graphs) in which each object is a specific type of the object immediately higher in the hierarchy (called its superclass). Conversely, each object is a generalization of any objects below it in the hierarchy (its subclasses). These hierarchies (called specialization, generalization, or categorization hierarchies) have two main functions. First, they provide an intuitive and efficient organization of objects in a system. Second, they allow inheritance: the sharing of common properties. Without hierarchies and inheritance, each object with similar attributes or methods must duplicate those attribute and method definitions. In a hierarchy, these attributes and methods can be assigned to a generalization of the relevant objects, and inheritance allows subclasses to inherit these attributes and methods. In addition to simple specialization hierarchies and inheritance, OOP languages may support any of the following advanced features: •
Multiple inheritance: Objects may have multiple superclasses and be able to inherit from any one of them. The problem with multiple inheritance is that objects can inherit different versions of the same property from two different parents. Some mechanism for resolving such conflicts must be provided in multiple-inheritance systems.
•
Inheritance alternatives: Objects traditionally inherit attribute definitions, method definitions, or attribute values from the closest relevant superclass. However, some OOP systems support alternative inheritance mechanisms. For example, local values can replace inherited values, inherited values can replace local values, local values can add to inherited values (both values are maintained), etc.
•
Other hierarchies and relationships: Relationships other than specialization can exist between objects. Examples include aggregation (a subpart object is a part of a composite object), membership (an individual object is a member of a collection object), and association (one object depends upon another object). Hierarchies of objects can be formed using these relationships (e.g., an aggregation hierarchy in which each object represents a sub-component of the composite object above it in the hierarchy). In fact, a common error in object-oriented programming is to confuse specialization and aggregation in the same hierarchy, making interpretation of the relationships inconsistent. Specific forms of inheritance are often relevant along these alternative hierarchies and relationships, but their behavior usually depends upon the
38
An Object-Oriented Data Model
problem domain properties. For example, if a tire object is defined as a subpart of a car object in an aggregation hierarchy, the tire should not inherit the model year of the car (the tire’s model year is not the same as the car’s model year), but it could inherit the location (the tire is in the same location as the car). Thus these forms of relationships are rarely built into an OOP language, but they can be added to solve specific problems. 4.2.5.
Classes and Instances
Most OOP languages employ classes and instances. However, these terms have come to represent different concepts in different types of OOP languages. In systems such as IntelliCorp’s KEE® [IntelliCorp 88], [Fikes 85], a LISP-based AI environment, classes represent collections of things while instances represent specific things (members of the collection). The class can receive attributes and methods that describe the collection itself (e.g., number of elements in the collection) as well as attributes and methods that are typical of its members; these are then inherited by the class’s instances. Instances can be assigned attributes and methods that differ from those inherited from its class. In this system, both classes and instances are objects. Alternatively, in languages such as C++ [AT&T 89], an object-oriented version of C, a class defines the attributes and methods assigned to a type of object. An instance represents an actual object of that type and maintains the values of the attributes defined by the class. Thus instances are objects for which classes act as templates (an instance can only have attributes or methods that are defined in the class). In this system, an instance of one class could represent some collection while an instance of another class could represent each member of the collection. Classes can also be used as types for type checking (i.e., an attribute can be required to have a value that is an object of type “collection”). The remainder of this dissertation uses the template definition of the term “class.” Classes and instances that refer to collections of things use the word “category” in their name.
39
An Object-Oriented Data Model
4.3.
Object-Oriented Databases 4.3.1.
Properties of Object-Oriented Databases
The previous section outlined characteristics and advantages of OOP. However, OOP alone does not solve many of the difficulties arising from maintaining and using large quantities of complex data, as required in an integrated CAPM system. Rather, we must look further to the union of OOP and database technology: object-oriented database management systems (OODBMSs). See [Ahmed 91b], [Atkinson 91], [Barry 91], [Cattell 91], [Kim 90], and [Kim 91] for general discussions of OODBMSs. As with OOP, no standard definition exists to describe the exact capabilities of an OODBMS, but several properties have become typical of commercial and research OODBMSs. These properties can be summarized as the capabilities of OOP outlined in the previous section (e.g., hierarchical, encapsulated objects with polymorphic methods) with the addition of the following database capabilities: •
Persistence: In standard OOP, objects exist only while the program is running. In OODBMSs, objects exist during and beyond the execution of the program (stored in secondary memory) and can be accessed across different sessions. Such objects are called persistent. In OOP languages, each object has a unique identifier. In languages such as Objective-C, an object’s identifier is a pointer to its location in memory (thus the object’s identifier provides direct access to that object). However, this identifier is lost whenever the program ends. For object persistence, the object’s identity, as well as its data or state, must be maintained.
•
Concurrency and transaction management: Multiple users typically access databases from multiple application programs simultaneously. OODBMS mechanisms must therefore allow concurrent access to objects. Concurrent access creates the possibility of introducing inconsistencies into a database. The OODBMS must include processes to monitor database transactions and, through locking or other techniques, maintain data consistency.
•
Security and recovery: Data stored in a large database is a valuable resource. An OODBMS must protect it by providing security mechanisms and techniques for recovering the data in the event of a system crash or other problems.
40
An Object-Oriented Data Model
•
Query language: OODBMSs should include high-level, general-use query languages to allow ready access to the information in the database.
•
Performance: OODBMSs must be able to manage very large quantities of data at acceptable performance rates.
•
Extensibility: In a large complex database, the structure of the database will not remain static but will undergo periodic (perhaps frequent) additions and modifications. An extensible database is one that contains mechanisms to allow structural alterations without damaging the data contained in the database.
•
Modeling tools: The richness of objects’ data representation, the numerous relationships possible between objects, and the addition of methods make OODBMSs more complex than conventional databases. Thus it is particularly important to have tools to assist in the design and maintenance of the database structure. Many commercial OODBMS provide graphical database design tools.
•
Versioning: Versioning is the ability to represent different versions of data in the database simultaneously. This allows users to develop “what-if” scenarios without committing changes to the current data, enables multiple users to work on different copies of the data concurrently without interference, and permits evolutionary versions of the data to be archived (e.g., for a review of the design history or for rolling back to a previous version of a design). In OODBMSs, objects provide a useful unit for data versioning and inheritance can reduce redundant storage of data that is consistent between different versions. 4.3.2.
Advantages and Disadvantages of OODBMSs
Databases, particularly relational database management systems (RDBMSs), are pervasive in corporate computer systems. However, RDBMSs have severe shortcomings for several areas of application. Applications … that are difficult to implement using relational database systems … include computer-aided design, engineering, software engineering, and manufacturing systems (…CAx); knowledge-based systems …; multimedia systems …; statistical and scientific modeling and analysis programs; and so on. These applications present serious difficulties related to data modeling…. They often require facilities for modeling and managing complex nested entities (such as design and engineering objects and compound documents); a richer set of data types, i.e., user-defined data types and long unstructured data (such as 41
An Object-Oriented Data Model
images, audio, and textual documents); frequently useful semantic concepts (such as generalization and aggregation relationships); the concept of temporal evolution of data (i.e., temporal dimension of data and versioning of data); and so on. …Some of the applications are highly compute-intensive on a large volume of memory-resident data, and impose performance demands that cannot be met by relational and prerelational data management systems. The need to reduce the cost of developing and operating these applications pointed to the need for a fundamental advancement in database technology, i.e., for database technology to make yet another transition, rather than incremental extensions of the capabilities of existing data management systems. The basis of this fundamental advancement in database technology is the object-oriented paradigm… [Kim 91, p.21]. Because of these shortcomings in RDBMSs and the potential improvement offered by an object-oriented approach, OODBMSs are making inroads into the commercial database market: According to the Ovum’s recently published Object Technology Sourcebook, total revenues from OODBMS sales (in the United States and Europe) are currently $25 million. However, revenues from [OODBMSs] are expected to explode over the next five years with an average annual growth rate of 142% … eventually accounting for 9% of the total database management systems market [Friedman 91, p.6]. Advantages of OODBMSs over RDBMS technology are as follows: •
Modeling capability: OODBMSs have rich, powerful, and flexible modeling capabilities. Objects can represent extremely complex data (e.g., many forms of information with numerous complex interrelationships), yet manage the data at a high level without being burdened by the complex detail (because of encapsulation and hierarchies). Hierarchies provide efficient organization of these high-level objects. Objects can represent many similar, but not identical, entities (e.g., different types and shapes of structural components); inheritance hierarchies make this very efficient and polymorphism allows uniform treatment of the various objects. Thus, while RDBMSs proficiently handle large quantities of similarly structured data, OODBMSs excel at handling large quantities of diversely structured data. Finally, OODBMSs are extremely flexible since encapsulation permits changes to individual class definitions without affecting other classes, while dynamic extensibility allows such changes to be made in existing databases.
42
An Object-Oriented Data Model
•
Methods: OODBMSs maintain both data and processes (objects’ methods). RDBMSs do not provided this capability. Methods can model the behavior of entities rather than just their state or data. Furthermore, methods allow the creation of intelligent data: events such as accessing data can trigger objects to reason about the situation and react accordingly. For example, objects might reason about whether their current data values are valid or whether they require updating by other applications. Methods have all of the modeling richness of data; each object can have unique method definitions, yet inheritance prevents excessive redundancy of processing capabilities. Finally, methods are important because they integrate the programming language directly with the database management system far more than is possible with RDBMSs, thus preventing the “impedance mismatch between the database manipulation language and the general-purpose programming language in which the rest of the application is written” [Ahmed 91b, p. 7].
•
Object identity: RDBMSs are value-based: entities are identified by one or more unique data values called keys. OODBMS are identity-based: objects are identified by a unique identifier that is independent of the object’s data values. Not only do identity-based systems avoid the redundant data value storage necessary to represent relationships in value-based systems, but they allow navigational data access, in which objects can be accessed directly from other related objects since their exact identity is known. Navigational data access is significantly more efficient than nonnavigational data access for many uses. Furthermore, non-navigational data access— in which objects are located based on stated data value criteria (i.e., query-based access)—is evolving in OODBMSs and should become a standard capability.
•
Transaction management and concurrency: The increased representation richness and the existence of intelligent data present opportunities for OODBMSs to provide better transaction management and concurrency than RDBMSs. In the Object-oriented approach, the database system knows more about the operations that are being performed—they are not simply read or writes, but rather have greater semantics. “Correctness” can therefore be enforced on the basis of application semantics rather than using the noread-write conflict approach [Ahmed 91b, p. 8].
•
Versioning: OODBMSs provide efficient support for versioning because objects make effective units for multiple versions and inheritance (which doesn’t exist in RDBMSs) makes the storage of multiple versions efficient.
43
An Object-Oriented Data Model
•
Performance: Performance is critical for the key applications working on a database. The performance of OODBMSs is extremely difficult to predict in general and highly depends upon specifics of the OODBMS implementation, the type and quantity of data stored in the database, and the exact nature of the applications using the data. One study that compared an object-oriented database with several relational databases using a small version of the Sun Benchmark database concluded that: Overall, …an object system can meet and in many cases exceed the performance of a fast relational system, even in a problem clearly from the relational domain. The results also indicate that an object system can model a relational implementation and achieve response times comparable to the relational systems. Note that it is possible to achieve improvements in performance by using an alternative schema definition [Duhl 88, p. 159]. Other claims have been made regarding OODBMS performance: "Orders of magnitude" performance improvement over alternative data storage technologies … is true today for a specific class of application domains. Also, theoretically sound observers say there's no reason these performance claims might not be true one day for a very broad class of applications including the core domains of relational and on-line transaction processing (OLTP)-focused solutions. But how can we make that broad claim today? …[Nowhere are] hundreds or thousands of production users hammering transactions against terabyte stores. Instead, we should focus on the very dramatic and real improvements [users] are finding in a specific set of applications. A [user] in the network management area told me recently, for example, that she had built a test suite that simulated her most critical transaction and ONTOS had outperformed the leading client-server relational database 70:1 [Ingari 91, p. 17]. As a generalization, it is expected that OODBMSs can offer significant performance advantages over RDBMSs (perhaps several orders of magnitude) for some of the previously identified applications for which RDBMSs are not well suited.
There are clear advantages to using OODBMSs. However, some weakness of OODBMS arise largely from the immaturity of the field. Some major disadvantages of current OODBMSs are the following: •
Lack of standards: The lack of standards for OODBMSs leads to confusion over the definition of OODBMS and how their properties compare to conventional database technology. Applications must be constructed for a specific OODBMS and are not
44
An Object-Oriented Data Model
portable to other systems. There is little opportunity for integrating data and systems among different OODBMSs. Section 4.1 discussed emerging standards. •
Lack of formal foundation: Some critics oppose OODBMSs because they have no formal mathematical foundation. However, others believe that a unifying theory for expressing core object-oriented concepts exists in an extended relational algebra [Kim 91] or in first-order logic [Kifer 89].
•
Immaturity and complexity: Most currently available OODBMSs fail to live up to their expected potential in certain areas, such as data-access performance and querylanguage capability. Experts believe that OODBMSs have not been under development long enough to overcome their complexity and richness, and predict that a new generation of systems will soon solve most of these shortcomings [Kim 91].
4.4.
The SOL Data Model
This section describes an object-oriented data model called SOL (for Shared Object Libraries) and a corresponding database system, the SOL OODBMS. This model was developed as part of this dissertation to experiment with the principles of object-oriented data models and to determine the features that are critical to integrated CAPM systems. The data modeling concepts and design decisions, as well as the details of the corresponding database implementation, are discussed. Chapter 6 illustrates how a SOL database can be used in conjunction with a suit of integrated applications. 4.4.1.
Implementation Environment and Database Architecture
The SOL OODBMS is implemented in Objective-C, an extension of ANSI C that includes support for many OOP concepts [Cox 86], [NeXT 90]. The implementation consists of 30 classes (9,600 lines of Objective-C code). The implementation platform is the NeXT computer running NeXTstep version 2.0, and the prototype applications built around the shared SOL database make extensive use of NeXT’s Application Kit library of application and user-interface objects (shown in figure 4.1). However, no platformdependent functionality has been included in the basic SOL system.
45
OpenPanel
SavePanel
Cursor
Bitmap
FontPanel
Font
PrintPanel
FontManager
ChoosePrinter
SavePanel
Window
PrintInfo
PageLayout
Box
Speaker
Form
Matrix
PopUpList
Menu
Application
Responder
Pasteboard
Object
TextField
Control
View
FormCell
Listener
Button
Text
TextFieldCell
Slider
ScrollView
MenuCell
ButtonCell
ActionCell
Cell
Scroller
ClipView
SliderCell
SelectionCell
An Object-Oriented Data Model
Figure 4.1: The NeXTstep Application Kit application-building and user-interfacebuilding classes, shown in inheritance hierarchy (from [NeXT 90, p. 6-5])
46
An Object-Oriented Data Model
Two main alternative architectures for implementing a data model are extended database systems that extend the capabilities of a DBMS to include object-oriented concepts, and database programming languages that extend the functionality of an OOP language to provide database properties such as persistence and concurrency [Cattell 91, p.78]. The SOL system adopts the latter architecture. The system defines subclasses of the basic Objective-C “Object” class to provide persistence and other properties. Other classes are also defined that perform various database management duties. Figure 4.2 shows the main classes that make up the SOL system. The role of each SOL class is discussed below and detailed in the class documentation in appendix I. 4.4.2.
Objects
The SOL database system—a database programming language—adds functionality to the Objective-C language to provide object persistence. The core of the SOL database system is the SOLObject class. An application can create persistent database objects by defining subclasses of the SOLObject class rather than the Object class. Instances of SOLObject subclasses are not automatically persistent—they still must explicitly be moved between disk and working memory (see section 4.4.12). Unlike conventional objects, however, SOLObjects’ identifiers remain constant between different sessions and are valid whether or not the objects load into memory (see section 4.4.4). SOLObjects can be assigned attributes (section 4.4.5) and methods (section 4.4.6), and they possess other database properties described below. Every SOLObject has the following attributes (see the SOLMetaObject and SOLObject class documentation in appendix I): •
description: a description of the object (inherited from SOLMetaObject ).
•
edited: indicates whether the object has been altered since it was last saved.
•
library: a relationship to the library to which the object belongs (see section 4.4.3).
•
objectName: the name of the object. An object’s name should be unique throughout its library (see section 4.4.4).
Appendix III gives a full example of a SOLObject subclass definition. In order to utilize persistent SOL objects, an application must also include the database utility objects described in section 4.4.13.
47
Application
IntegerAttribute
SysApp
(NeXTstep AppKit)
NameMgr
DoubleAttribute
SOLError
StrAttribute
SingleValueAttribute
Attribute
Object (Objective-C)
Relationship
SOLLibrary
SOLMetaObject
BroadcastObj
RelationshipSet
AttributeSet
SOLObject
LibraryMgr
An Object-Oriented Data Model
Figure 4.2: The primary SOL OODBMS classes, shown in inheritance hierarchy
48
An Object-Oriented Data Model
4.4.3.
Libraries
In the SOL system, each persistent object is assigned to a library. Grouping objects into libraries provides a simple organization mechanism for dealing with large numbers of objects (more complex relationships and groupings can still exist among objects, regardless of which library they belong to). Libraries of objects, rather than individual objects, transfer between disk storage and working memory. Not only does this make it easier to load and save large groups of related objects, but it improves database performance by clustering related objects both on disk and in working memory. Libraries are themselves persistent objects (defined by the SOLLibrary Class). They have the following attributes: •
description: a description of the library (inherited from SOLMetaObject).
•
edited: indicates whether the library or any of its objects have been altered since they were last saved.
•
fileName: the name of the file used to store the library.
•
objects: a relationship to the set of objects assigned to the library.
•
libraryName: the name of the library. A library’s name should be unique throughout the database system (see section 4.4.4). 4.4.3.1.
Alternative Approaches
Although libraries provide a simple and effective object organization and clustering mechanism, they exhibit some disadvantages. Libraries impose additional structure on the database that is not strictly necessary. They are inflexible since they don’t allow single objects or larger groups of objects (multiple libraries) to be moved in and out of memory with a single action. A more sophisticated approach would be to save each object to disk individually, but to provide an optional, complex organization structure that would be used for manipulating groups of objects (e.g., objects may be assigned to multiple groupings, which could be nested hierarchically). 4.4.4.
Object Identifiers
Every object in an object-oriented system has a unique identifier. Objective-C uses an object’s memory address as its unique identifier (called an object’s id). This is a type of physical identifier which is very efficient since it can be used directly to access the object. 49
An Object-Oriented Data Model
However, an object’s memory address is not persistent; it disappears when the object is removed from working memory. (In Objective-C, references to objects can be saved to disk and restored, but only for objects that are maintained together in the same file.) An object can receive a unique name, a form of logical identifier, to serve as a persistent identifier. However, names require more memory to store and are less efficient for accessing objects since an index must be used to match the name to the location of the object in memory. The SOL system uses a structured object identifier that combines the advantages of physical and logical references. SOL objects are referred to by a pointer to this reference structure—called an objRef—and provided functions manipulate objRefs (see the ObjRefs library documentation in appendix I). This provides a level of encapsulation for SOL object identifiers, thus application programmers or users need to know very little of how object identifiers are implemented. From their point of view, it is only important that objects are referred to by their objRef, that an objRef can be constructed from an object’s name and library name, and that objRefs can be converted into a conventional Objective-C id-type reference using the function “objID(anObjRef)”. An objRef object-identifier is a pointer to a data structure—called an objRefStruct— that contains an object’s name and its library’s name, an object’s memory address, or all three. The combination of a library name and an object name uniquely identifies an object, and can be used whether or not the object is currently in working memory. If an application refers to an object using an objRef that contains these names but no memory address, then the SOL database system locates the object, loads it into working memory from disk if necessary, and adds the memory address to the objRef structure. Subsequent attempts to access the object using the objRef can use the memory address directly. 4.4.4.1.
Alternative Approaches
The SOL system’s use of objRefs provides object identifiers that are both persistent and efficient, yet it has some disadvantages. If an object is removed from memory, all references to that object which are in working memory must be located and checked to remove the object’s memory address, since they are then invalid. This could be computationally expensive and, if not performed perfectly, leave corrupted data references. One solution would be to make objRefs contain an indirect memory address or surrogate reference. Then, if an object is removed from memory, references would be left pointing to a “tombstone” rather than an invalid memory location. Another problem is that the object 50
An Object-Oriented Data Model
and library names require significantly more memory than pointer references, and the need to provide unique names for all libraries and objects (a responsibility of the application program or the user) can be onerous. If this approach were used for industry-wide systems, a hierarchical naming convention could be created so that, for example, all objects created by one company could be distinguished from similarly named objects created by another company. There are numerous different approaches to implementing OODBMS object identifiers (see [Cattell 91, p. 151] and [Ahmed 91b, p. 25] for comparisons of alternative schemes), and the impact on database performance is significant; however, the basic database functionality is not greatly affected by the different techniques. 4.4.5.
Attributes
SOL objects can have associated attributes, i.e., related data values. Attributes are defined and configured in an object’s class while the actual attribute values reside with the object (an instance of the class ). Attributes are assigned a name and are declared to be a specific data type. Currently, the SOL system supports integer, double (real number), string, relationship (a reference link to another object), and relationship set (a collection of relationships) attribute types. SOL can also record the date and time that the attribute’s value was assigned and a code identifying the source of the value. SOL defines valuesource codes for null value, unspecified, inherited, default, user-specified, and calculated, but applications can define other codes (see sections 6.8 and 6.10). Attribute operations include setting and returning their value, setting and returning their value-source code, returning their value date and time, and determining their type. For set-type attributes, operations include adding and removing values and determining the number of values in the set (see the SOL class documentation in appendix I for specific attribute configuration routines and access operations and appendix III for an example of how attributes are defined and configured). Although largely transparent to the application programmer and user, attributes are implemented as separate Objective-C objects in the SOL system. This improves the inheritance of attribute manipulation methods and simplifies multiple inheritance of attributes (see section 4.4.11). Each attribute type is implemented as a different class and new attribute types can be added by simply subclassing the existing attribute classes.
51
An Object-Oriented Data Model
4.4.5.1.
Alternative Approaches
Attributes are not strictly necessary in OODBMSs, since with proper encapsulation, all access to an object’s data should be through its methods. These methods can implement an object’s data as instance variables, can calculate necessary data values as needed, etc. (the implementation details should be private in any event). However, in a typical objectoriented program, a significant portion of objects’ methods perform simple object data (attribute) access. For database objects, however, simple data access methods must accommodate concurrency, change notification, and other database functionality. Thus providing a special mechanism for adding attributes to objects reduces a large amount of repetitive programming. Attributes are still accessed only through methods, but the methods are standardized and inherited, and the object definitions must alter these methods only if special treatment of the attribute is desired. Furthermore, this explicit treatment of attributes tends to give the object more knowledge of its own data properties, which improves “data intelligence.” For example, a user interface component can query an object about the nature of its attributes in order to better configure itself for that specific object. Currently, SOL offers only one type of relationship attribute. However, there are many different types of relationships. For example, classification relationships identify object’s subtypes, aggregation relationships identify object’s subparts, categorization relationships relate categories of objects to the individual members of the category, constituent relationships identify one-to-one subparts (for example, since a door object would have a subpart relationship to only a single doorknob object, all of the attributes of the doorknob could just be included with the door, but typically they should still be modeled as two separate objects for semantic clarity), ownership relationships relate one object to another that has responsibility for its creation and deletion, and compound relationships involve more than just two objects or have attributes that describe the relationship itself (see sections 5.9 and 6.10). If the data model allowed explicit declarations of these relationship types, then their characteristics and constraints could automatically be included in the data operations. 4.4.6.
Methods
SOL objects can have methods, just as any other Objective-C objects. As described in section 4.3.2, the ability to add processing to data is one of the primary advantages of OODBMSs over RDBMSs. However, SOL attributes automatically include methods for accessing and manipulating attribute values, and it is possible to modify and override these 52
An Object-Oriented Data Model
attribute methods (see section 4.4.10). Attribute methods significantly reduce the number of methods that would typically be required otherwise. 4.4.7.
The Broadcast/Subscribe Mechanism
The SOL system implements a simple broadcast/subscribe mechanism that fulfills several desired OODBMS properties. This section describes the broadcast/subscribe mechanism, while sections 4.4.8 (indirect relationships) and 4.4.9 (event notification) show why and how it is used. A broadcasting object is one which knows there may be other objects that are interested in some of its activities, but doesn’t know which these other objects are. If an object is interested in a broadcasting object’s activities, it can register itself as a subscriber of the broadcasting object. The broadcasting object keeps a list of the objects that have registered themselves as subscribers. When events occur within the broadcasting object’s methods that it thinks might be relevant to any of its subscribers, it will send out (or broadcast) a message to each subscriber that understands that message. Thus the broadcasting object need have no specific knowledge about the subscriber object. Broadcast messages always include the broadcaster’s id as an argument so that the subscriber object knows which object broadcast the message. Broadcast messages can optionally include other arguments, such as the value of some attribute before and after a change was made. Subscribers can register under a specific name so that other objects can access them through the broadcasting object. For example, a browser-type user interface object can register itself as a subscriber of some broadcasting object under the name “Browser Interface”. Then the broadcast object can respond to a message from any other object to return its subscriber named “Browser Interface,” without having any previous knowledge that it would have a relationship with such an object. A general broadcast/subscriber mechanism is implemented by the BroadcastObj Class (see class documentation appendix I). Subclasses of the BroadcastObj class can have objects register themselves as subscribers using their id-type reference, and can broadcast messages to these subscribers. A broadcast/subscriber mechanism customized for SOL objects is implemented by the SOLMetaObject Class. This class adds the additional capability that objects can register themselves as subscribers using the objRef-type reference. This capability is only required by SOL objects since it is permissible for SOL
53
An Object-Oriented Data Model
objects to register themselves as subscribers to other SOL objects but not to applicationspecific objects (which would require specific knowledge of those objects). All SOL objects are broadcasting objects since both SOLLibrary and SOLObject are subclasses of the SOLMetaObject Class. 4.4.7.1.
Alternative approaches
Currently, when a broadcasting object broadcasts a message it must access each of its subscribers to see if it they wish to respond. This is problematic since it causes many subscriber objects to move from disk into working memory even through they are unaffected by the current operation. A more efficient approach would be to allow objects to subscribe to specific events rather than to specific objects. Then broadcast objects could access pertinent subscribers only. However, this would require a more complex mechanism for storing subscriber references within the broadcast object, since subscribers’ interests as well as their references must be maintained ([Genesereth 92] addresses some of these issues). 4.4.8.
Indirect Relationships
The representation of relationships between objects is a critical capability for modeling complex information. In the SOL system, this capability is provided by relationship-type attributes. These are called direct relationships since they are explicitly included in the class definitions. However, the SOL system uses the broadcast/subscribe mechanism to allow the creation of indirect relationships between objects; that is, relationships that are not explicitly defined in class definitions. Indirect relationships address the situations identified in the following sections: 4.4.8.1.
Independence
Suppose that an object X depends upon another object Y, but Y is independent of X (X is affected in some way by Y’s actions, but Y is not affected by X’s). X must be made aware of Y’s actions so that it can react accordingly; however, it would rarely be practical for X to continuously monitor Y’s actions in search of relevant events. Rather, Y must notify X of its events and let X react accordingly. Y must have a relationship with X in order to send notification of its actions. Yet from a modeling point of view, it is burdensome to require an object to maintain explicit, direct relationships to objects with which it is entirely independent. A preferable mechanism would allow Y to react uniformly
54
An Object-Oriented Data Model
regardless of any independent objects, but would still notify X of Y’s actions. Such a mechanism is achieved by making Y a broadcasting object and making X a subscriber of Y. In some other OODBMSs, independent relationships could be implemented using an event notification mechanism similar to broadcast/subscribe (see section 4.4.9). [Abdalla 89] suggests that in order to control system complexity, no interaction should exist between objects unless a communication path is explicitly declared between the two objects. This point of view precludes implementation of an independent relationship mechanism. 4.4.8.2.
Relationships with Non-Persistent Objects
A non-persistent, non-SOL object can establish a relationship to a SOL object through which it can access the SOL object’s data, activate methods, etc. However, SOL objects cannot maintain direct relationships to non-SOL objects, since these objects are not persistent. Nevertheless, relationships are required from SOL-objects to non-SOL objects. For example, some SOL database object may need to notify an application-specific userinterface object that its data values have changed and must be re-displayed (this may or may not be an independent relationship as above). Relationships from SOL objects to non-SOL objects can be established using indirect, broadcast/subscribe relationships. A more explicit approach to creating relationships to non-persistent objects would be to define a new attribute type that exhibited special properties for non-persistent relationships. For example, it would be assumed that the attribute values are temporary and are not valid until it is confirmed that the related object still exists within the system. 4.4.8.3.
Dynamically-Defined Relationships
As implemented in the SOL system, attributes must be defined in an object’s class. This definition compiles into the executable database program and into any application programs that utilize that class. However, some relationships are not structurally constant over time, but rather are created and destroyed during an application’s execution. Such relationships cannot be expressed with direct relationship-type attributes. Indirect, broadcast/subscribe relationships, however, can be created and destroyed dynamically at run time. The ability to define relationships dynamically is a subset of dynamic domain-model extensibility. SOL domain models are extensible by saving the data to disk, modifying the
55
An Object-Oriented Data Model
domain model, recompiling the system, and restoring the data (see section 4.4.12). Alternatively, some OODBMSs offer dynamic extensibility, in which the domain model can be altered at any time during database execution. Dynamic extensibility allows the dynamic creation and destruction of relationships. However, the use of indirect relationships does not provide a general dynamic extensibility capability since only a specific type of relationship can be created dynamically. 4.4.8.4.
Separation of General and Specific Models
The SOL system supports databases that will be shared among many different applications and users. Clearly, the structure of the shared database (i.e., the domain model implemented using the SOL data model) must be very general. Furthermore, the domain model should not contain any non-general, application-specific information. Applicationspecific information obscures the interpretation of the model; consumes valuable shared resources with information that, by definition, need not be shared; and is likely to diminish the generality of the model. Ideally, this issue would be solved by allowing multiple, variably scoped views of the database (this would aid security mechanisms as well as keep local data definitions out of general models). However, the SOL system adopts the simpler approach of implementing general data model relationships directly using attributes and implementing application-specific relationships indirectly using the broadcast/subscribe mechanism. 4.4.9.
Event Notification
In addition to being a relationship representation, broadcast/subscribe is an event notification scheme since it provides a way of notifying related objects about events that occur within the broadcasting object. Event notification is a very powerful tool. In the SOL system, all directly related objects (i.e., all relationship and relationship-type attribute values) automatically become subscribers. While this is transparent to the user, it allows simple broadcast/subscribe event notification to be used for both indirectly and directly related objects. Event notification gives the SOL system the capabilities described in the following sections (these are distinct but overlapping features): 4.4.9.1.
Change Propagation
Every attribute can be configured to send out standard broadcast messages immediately before and after they are accessed. For example, the following are typical
56
An Object-Oriented Data Model
messages (where the word “object” is replaced with the name of the broadcasting object’s class and the word “Attribute” is replaced with the name of the affected attribute): — object: anObjRef willProvideAttribute: aValue — object: anObjRef providedAttribute: aValue — object: anObjRef willChangeAttributeFrom: oldValue to: newValue — object: anObjRef changedAttributeFrom: oldValue to: newValue — object: anObjRef willAddAttribute: aValue — object: anObjRef addedAttribute: aValue — object: anObjRef willRemoveAttribute: aValue — object: anObjRef removedAttribute: aValue Thus subscriber objects have the opportunity to respond to any operation that is about to be or has just been performed on an attribute value. For example, a subscriber object that implements an inspector window for displaying specific database values can use these messages to update its fields whenever the attribute values change. Furthermore, subscribers can respond to broadcast messages about some action that is about to be made by raising an exception [NeXT 90, p. 10-36]. This will cancel the attribute operation and return an exception code to the object that initiated the operation. When this happens, the subscriber is said to veto the attribute operation. 4.4.9.2.
Constraint Propagation
One primary use of change propagation is to check and enforce constraints between attribute values and other objects. If such constraints exist on some attribute value, then they can be checked by the related object in response to a message broadcast prior to a value change. If the new attribute value does not satisfy the constraint, then the veto mechanism can prevent the change. Alternatively, if constraints require that other objects be altered in response to a change in certain attribute values, then these changes can be done in response to a message broadcast after completing a change. Thus, while the broadcast/subscribe mechanism possesses no actual constraint-manipulation capabilities, it does propagate messages that can trigger constraint-manipulation routines within each class. More sophisticated constraint-management schemes are currently under investigation [El-Bibany 92], and could be added on top of the current SOL approach.
57
An Object-Oriented Data Model
4.4.9.3.
Inverse Relationships and Propagation Circularity
A special case of constraint propagation is that every relationship or relationship-set attribute must have an associated inverse relationship. For example, the inverse of the SOLObject “library” relationship is the SOLLibrary “objects” relationship. Logical constraints between inverse relationships are automatically maintained in the SOL system. For example, if the value of an object’s “library” attribute is changed from one library to another, then the object is removed from the first library’s “objects” attribute and is added to the second’s. Inverse relationships are a type of propagation circularity that receives special treatment. In the general case of a propagation circularity, an event in object A triggers a broadcast to object B, which in turn triggers a broadcast back to object A that restarts the propagation and results in a continuous loop. Many objects can be involved in the propagation before it loops back onto itself. The SOL system includes no mechanism for detecting and preventing such circularities; it is left to the designer of the domain model to prevent these interdependencies. It would be possible to add a mechanism that tracked propagation paths and aborted if circularities were detected. Identifying potential propagation circularities in a data model before the specific propagation was attempted would not be possible without making the domain model’s possible propagation paths more explicit than they currently are required to be. 4.4.9.4.
Event-Driven Reasoning
Broadcast/subscribe event notification, in conjunction with intelligent data (the grouping of data and associated procedures), provides the basis for event-driven reasoning in which processing is performed based on events that happen within the system. For example, changes made to an object representing a construction activity could result in broadcast messages that trigger a recalculation of the activity network dates; this may, in turn, trigger changes to a material procurement schedule or a cash-flow analysis. This approach to reasoning is an alternative to, for example, procedural reasoning (the conventional approach) or opportunistic reasoning (as used in blackboard systems). As stated in section 4.3.2, the addition of reasoning to the database is something not offered in relational systems and greatly expands the power of the database system. The broadcast/subscribe mechanism also supports as-needed, or lazy, processing. If an attribute value is derived from a calculation, for example, that calculation can be
58
An Object-Oriented Data Model
deferred until the broadcast announcing that the attribute value is about to be accessed. In this way, the calculation will only be performed as needed. 4.4.9.5.
Transaction Management
The SOL system breaks each attribute operation down into a check, a perform, and a confirm stage. Any locally-defined constraints are checked and a “will perform” message is broadcast during the check stage; the actual access operation occurs during the perform stage; and any locally-defined post-processing is performed and a “performed” message is broadcast in the confirm stage. No consequences of the operation are implemented during the check stage, and no vetoes can be made during the confirm stage. Thus the system never needs to undo a partially completed operation. This approach exhibits the characteristics of a simple transaction-management scheme. By including a check for locked attributes in the check stage and a locking operation during the perform stage, data consistency would be guaranteed for concurrent database use. A full-featured transaction management scheme, which would include mechanisms for breaking deadlocks and for serializing transactions, is not included in the SOL system because it is not intended to be used concurrently in its prototype version. 4.4.10.
Override Attribute Functions
As described throughout the preceding sections, SOL attributes perform processing for accessing and manipulating their values, for constraint-checking, and for broadcasting messages before and after attribute operations. These processing capabilities cover many typical situations, but are not appropriate or complete for all attributes. The SOL system allows these processes to be modified and overridden so that non-typical attributes can still exploit any applicable inherited capabilities. These modifications take the form of functions defined to perform the non-typical processing—called override functions—and attribute configurations statements that instruct the attributes to call these functions at the appropriate time (functions are used instead of methods simply to improve attributes’ inheritability). Override functions can be defined to replace access-value, set-value, addvalue, and remove-value methods. If any of these functions are defined, they will execute instead of the conventional method. In addition, a function can be defined to modify only the check, perform, or confirm stage of any of these operations. The system will execute these functions either instead of, or in addition to, the regular check, perform, or confirm methods, depending upon the return value of the override function. Override functions’ arguments may include the object’s id, the attribute’s id, and the attribute’s previous, 59
An Object-Oriented Data Model
current, and new values. The Attribute Classes’ documentation in appendix I gives the specific formats for override functions and the corresponding attribute configuration statements. Although most OODBMS systems offer some form of modification to standard attribute processing methods (for example, IntelliCorp’s KEE [IntelliCorp 88] and ProKappa™ [IntelliCorp 90] systems use a mechanism called “Active Values”), the SOL system’s override functions are particularly flexible and powerful. 4.4.11.
Inheritance
The SOL system supports the following forms of inheritance: •
Conventional specialization inheritance: Since SOL classes are Objective-C classes, they automatically inherit properties from their superclasses (their parents in the class specialization hierarchy). Attributes, methods, and instance variables can be inherited in this way. This type of inheritance is single, specialization inheritance.
•
Multiple specialization inheritance: A limited form of multiple inheritance has been added to the SOL system. Although each SOL class still has a single primary superclass, any number of additional secondary superclasses can be defined. SOL objects will then inherit all attributes, complete with any override functions, from each of these secondary superclasses. Methods and instance variables cannot be inherited in this way. If the same attribute name is defined differently in two superclasses, the first definition is used and subsequent ones are ignored. This is an arbitrary approach to resolving duplicate definitions, so the domain model designer should take care to prevent duplicate attributes in multiple-inheritance classes. The SOLMetaObject class documentation in appendix I and the example in appendix III provide more detail about multiple inheritance.
•
Non-specialization inheritance: Inheritance can be appropriate along relationships other than class specialization, but a general rule rarely applies. In the SOL system, the attribute override methods provide a good mechanism for implementing alternate forms of inheritance. For example, the domain model described in chapter 5 includes objects that inherit default attribute values from related category objects. 4.4.12.
SOL Object Persistence
As mentioned previously, SOL objects are not automatically persistent, but must be explicitly saved to disk. This section discusses the Library Manager, an object that moves 60
An Object-Oriented Data Model
libraries to and from disk storage and maintains ownership of all libraries. The format that objects use for reading and writing their data is also discussed. 4.4.12.1. Library Manager Every program that uses the SOL database must contain a single instance of the LibraryMgr class (see the class documentation in appendix I). This object, called the Library Manager, maintains ownership of all libraries loaded into the system and is responsible for creating, loading, saving, and destroying libraries (upon request from applications). Applications can generally request these operations for a specific library (e.g., open library X), or for a user-specified library (e.g., open a library that the user specifies). Typically, libraries are opened either because the user has asked an application to open a specific library in order to access a certain object, or because some operation (such as a change notification broadcast) has attempted to access an object that is not currently loaded into working memory. Libraries are typically saved back to disk either as a result of a “save” request by the user or as an automatic save operation performed by an application (e.g., before it shuts down). To load a library, the Library Manager accesses the file containing the library, and cyclically identifies the class of an object stored in the file, creates an object of that class, and then instructs the object to read its instance data from the file. To save a library, the Library Manager opens a file and instructs each object in the library to write its instance data out to the file. 4.4.12.2. Hierarchical Data Format Loading and saving libraries can be done in either the NeXTstep typed-stream format [NeXT 90, p.10-11], or in a format that uses ASCII characters. While the typed-stream format is fast, compact, and easy to use, the ASCII format is less affected by changes to the database structure, can be accessed and altered directly from outside of the database system, and can help convert an object from one class to another. The specific format for the ASCII file is called the Hierarchical Data Format (HDF) and is illustrated in appendix III. An HDF file consists of a series of units. Each unit consists of a unit name and a set of unit values in parentheses. The values can be literals (numbers), character strings, or sub-units (each value in a set of unit values must be the same type). HDF files are “self-documenting” since the unit names describe what the unit values refer to, and units need not be in a specific order. In order to change an object’s class, the object writes its instance data to a memory stream in
61
An Object-Oriented Data Model
HDF, then a new instance of the new class reads in the data, accepting the values of all attributes that are common to the two classes and ignoring other attributes. The HDF, then, is a formal object data exchange language. It is also used as a class definition language, as illustrated in appendix III. 4.4.12.3. Alternative Approaches A fundamental alternative to the SOL approach is to make database objects automatically persistent, thereby removing the responsibility for loading and saving objects from applications and users. Such a system would immediately commit any object changes to persistent memory (although a disk input/output buffer mechanism could be used so changes would not necessarily be written to disk instantly). Such an approach simplifies application programming and is probably preferable in the long term. However, it requires a more complex database management mechanism and reduces the flexibility of the application programmer. 4.4.13.
Other SOL Classes
Like the LibraryMgr class, three additional classes are intended to have a single instance in any SOL program. The NameMgr class implements methods for accessing an unloaded object given its objRef reference. These methods are encapsulated within a single object since different approaches to this mechanism are appropriate in different circumstances. For example, in some systems it may be appropriate to employ user dialogs to help locate unloaded libraries, while in other implementations the access attempt may be made from an external program running on a different machine and no user assistance can be obtained. The SysApp class implements a top-level application object that allows several sub-applications to co-exist and gives each access to the Library Manager and Name Manager objects. The SOLError class contains error codes and messages that are used by SOL objects to raise errors or exceptions (the SOL exception handling mechanism is based on the NeXTstep system described in [NeXT 90, p.10-36]). Finally, a series of classes, called the SOLKit classes, aid in developing applications that use the SOL database. SOLKit consists of user-interface and application support classes, but the details of these classes will not be given in this dissertation.
62
An Object-Oriented Data Model
4.4.14.
Weaknesses of the SOL System
As an experimental prototype, the SOL data model and database is not complete. The following are areas where improvements would be required for a deliverable system: •
Query language: Applications can access and manipulate SOL objects using the full range of Objective-C’s functionality. However, a database object query language is required to simplify and optimize common database operations and to give users flexible direct access into the database.
•
Versioning: Users can currently maintain different versions of objects by saving them in different files. However, this provides no mechanism for inheriting common values between different versions or for recombining different versions. A complete versioning mechanism is required.
•
Concurrency: As stated in section 4.4.9.5, the SOL system contains mechanisms that could support transaction management and concurrency. However, the system’s current capability in these areas is minimal.
•
Dynamic extensibility: As stated in section 4.4.8.3, SOL databases are extensible but not dynamically so. Dynamic extensibility would be a useful improvement.
•
Database design environment: A program called the Object Design System (ODS) can simplify the definition of SOL classes (see appendix III). However, a more extensive, graphical database design tool would greatly improve the process of creating and maintaining SOL databases.
4.5.
Conclusions
This chapter presented an object-oriented data model as the underlying information representation technology for integrated CAPM systems. While no widely-accepted standard object-oriented data model yet exists, several groups are currently attempting to produce such standards. Object-oriented programming offers the advantages of reduced software complexity and improved software development and management; higher-level programming and domain modeling; uniform treatment of large volumes of complex and highly variable data; and a different overall way of conceptualizing software. Objectoriented database management capabilities add data persistence and other database functionality to object-oriented programming concepts, resulting in a database technology 63
An Object-Oriented Data Model
that deals with complex, variable, and intelligent data far better than conventional relational systems. Finally, the SOL model and database system was described. The SOL system was developed as an experimental system for exploring OODBMS concepts, for identifying the functionality required to support integrated CAPM, and for supporting the prototype system described in chapter 6.
64
Chapter 5 A Domain Model for Project Management and Construction Chapter Abstract: After establishing a data model standard, we require a common domain model or schema to provide a standard construction terminology for integrated systems. This chapter describes the General Construction Object Model, GenCOM: a project management and construction domain model developed as part of this research. The model is arranged into major categories representing the construction product, the process, the resources, and the project organization. For each category, GenCOM distinguishes between project-specific information and project-independent information (general construction knowledge). GenCOM defines classes in each of these categories to represent basic project management and construction concepts.
5.1.
The Role of a General Domain Model
Of the three levels of shared models used for system integration—data, domain, and project—the domain model is perhaps the most important. Why? Although the domain model’s details depend upon the characteristics of the data model, the basic categorization of domain concepts instilled in the domain model are transferable to any data model. Furthermore, any form of system integration, from a shared project database to a set of custom inter-application translators, requires some type of general domain model. Thus a general domain model—i.e., a schema or ontology for project management and construction—is fundamental to CAPM integration. In current practice, the most successful attempt to establish a standard domain model is the MASTERFORMAT [Hartman 87], a widely accepted codification used predominately for construction specifications. The current technological context of OOP and KBSs, however, requires a much richer and more general domain model.
65
A Domain Model for Project Management and Construction
The basis for designing a domain model is an understanding of the domain itself and of the applications that will use the model. In the case of integrated CAPM, however, the application areas encompass virtually all conceivable CAPM programs. For example, the domain model should be able to support the following applications: • • • • • • •
distribution of design information bidding estimating scheduling on-line purchasing project accounting construction methods analysis
• • • • • •
resource allocation equipment management construction CADD simulation and 3-D graphical modeling financial planning constructibility analysis
A domain model, called the General Construction Object Model (GenCOM), has been developed as part of this dissertation. Unlike the data model described in chapter 4, which is an experiment rather than a recommendation, GenCOM recommends a kernel of basic concepts upon which future domain models for project management and construction can build. The primary difference between this domain model and other object-oriented project management systems is the overriding goal of generality adopted for this research. This chapter describes the GenCOM domain model by first showing how the model was derived and stating what guidelines or lessons were drawn from this modeling effort. Section 5.4 then identifies the general construction concepts underpinning the domain model. Section 5.5 gives an overview of the model itself, followed by descriptions of each major segment of the GenCOM model: the general classes, the product model, the process model, the resource model, and the organization model. Finally, section 5.11 illustrates how the GenCOM model can represent project information.
5.2.
Developing a General Domain Model
A domain model to support integrated construction and project management applications must be very general. It must support a wide range of applications but make no assumptions about which specific applications may exist. Two different modeling approaches enabled this research to meet these criteria: 1.
I evaluated existing project management programs and translated them into sets of objects capable of re-implementing them. The programs studied included Primavera Project Planner scheduling software, Timberline Precision Plus estimating package, and OARPlan plan-generation expert system. Appendix IV documents the working models derived from these application analyses 66
A Domain Model for Project Management and Construction
2.
I applied conceptual modeling to the construction domain. That is, I identified the fundamental concepts used in construction—independent of any specific computer applications—and represented them as objects. Section 5.4 describes this conceptual model. Several AI researchers have proposed representing knowledge using a set of fundamental primitives, e.g., Schank’s conceptual dependency work [Schank 77].
The class definitions derived from these two different perspectives merge into an overall model. Thus GenCOM provides the data attributes and relationships necessary to support conventional and KBS applications, yet remains general and independent of specific applications since it constitutes a comprehensive model of the overall project management and construction domain. It is possible to use more formal modeling methodologies that give specific mechanisms for translating domain concepts into models. Examples applied to construction domains include the NIAM modeling methodology used by [Abudayyeh 91] or the IDEF0 method used by [Sanvido 90]. One advantage of using a formal modeling methodology is that different parties independently can come up with similar models of some domain, thus improving consistency among models. However, modeling methodologies partially depend upon the characteristics of the selected data model. This research used the informal modeling approaches described above, not a formal modeling methodology.
5.3.
Modeling Principles
The process of designing a general domain model for project management and construction yielded a number of guiding modeling principles. These principles do not provide a specific methodology or recipe for creating models, but they do offer guidelines that help resolve many difficult design decisions facing the domain modeler. •
Include concepts in the model when they potentially relate to a number of applications. Concepts that only relate to a specific application should remain in the application itself.
•
Include knowledge (such as an attribute value or a constraint between attributes) that you expect to always hold true in the model in non-overridable form (e.g., as a function that calculates an attribute value whenever related values change). Also include knowledge you expect to frequently hold true, but in an overridable form (e.g., as default attribute values).
67
A Domain Model for Project Management and Construction
•
Seek maximum generality of representation (see section 4.4.8.4).
•
Select explicit representations instead of more obscure, but compact representations.
•
Give preference to approaches that simplify the representation of typical information, and that make it possible to represent complex and unusual information.
•
Do not avoid representations that lead to large numbers of objects or complex relationships, if they are otherwise appropriate, since applications can shield users from dealing with the model at this level.
•
The model should be of variable granularity. Normally define classes to represent general concepts, and then define specialization subclass hierarchies to add additional attributes at greater levels of detail. The extent of the level of detail depends upon how the model will be used. For example, if a company only collects cost and productivity data related to construction activities at a “construct column” level of detail, then they have little use for classes that represent activities at a “tie-rebar, transport-rebar, position-rebar, secure-rebar, etc.” level of detail.
•
Models are evolutionary. Expect that models will be modified and extended in response to feedback from users and to new demands placed on the system. This fact reinforces the principles of generality and explicitness.
5.4.
Fundamental Construction Concepts
A general domain model should evolve both from the requirements of the applications that will use it and from an analysis of the fundamental concepts involved in construction. This section surveys fundamental construction concepts, which are depicted in figure 5.1. The main perspective adopted while defining these conceptual construction ingredients has been that the heart of any construction project is the actual construction effort or activity. Our primary focus is the action of making a hammer meet a nail (though we usually work with a much higher aggregation level of construction effort, such as “install third-floor HVAC”). We should maintain a clear understanding of how all other project information relates to the central concept of construction effort. The following concepts, then, capture the essence of construction effort:
68
A Domain Model for Project Management and Construction
Concepts: Physical Project Component
Action
Method
Resource
Construction Activity
Construction Goal
Examples: Physical Project Component: Concrete Column
Action: place concrete
Construction Goal: place concrete for column
Method: pump concrete
Resource: concrete pump truck
Construction Activity: place concrete for column using pump
Figure 5.1: The major concepts involved in construction (represented by ovals) and the dependencies between them (arrows show a dependency relationship between concepts) •
Components: Construction effort involves the project’s physical components or components of the adjoining environment such as the surrounding geology, temporary construction facilities, etc.
•
Actions: Construction effort changes the state of a physical component. Components are created, moved, altered, destroyed, etc. For example, some construction effort may change a door from the “stock-piled” state to the “installed” state. This change in state is called an action.
•
Construction Goals: The concept of a required change in a component’s state (i.e., some action must be applied to a component) exists independently of the specific construction effort that achieves the change in state. This application of an action to a component is a construction goal since it is the objective of construction effort.
•
Resources: Construction effort utilizes various resources, including crews (labor and equipment), materials, information, and space to perform the work. The activity may or may not consume the resources. 69
A Domain Model for Project Management and Construction
•
Methods: Construction effort always employs some method or technique. Different methods can achieve the same goal. It is also reasonable to consider some construction method independently of the specific activity to which it might apply (e.g., compare the general advantages of “cast-in-place” methods versus “pre-cast” methods).
•
Construction Activities: I refer to a unit of actual construction effort as a construction activity. An activity, then, is construction effort applied to achieve some goal (i.e., the application of some action to some component), using some specific method and some set of resources. Some of the activities’ elements will often be expressed very generally. For example, some construction activities such as “general housekeeping” may involve the overall “site” as the physical component. Furthermore, it may often be impractical to distinguish between alternative methods of achieving a goal; thus the method defined for activities such as “install glazing” may simply be “typical method.”
Using a construction goal to represent some construction requirement, along with a construction activity to represent the construction effort that fulfills that requirement, parallels the STEP/PDES GARM [Gielingh 88], [Gielingh 91] approach of representing products using both a Functional Unit—which reflects the requirements of the product— and a Technical Solution—which represents the specific product design for fulfilling the requirements. (GARM considers these to be two stages of the product’s life-cycle; others include a Planned Unit, Physical Unit, Operational Unit, Alteration Unit, and Demolition Unit.) The following sections describe the GenCOM model, which builds on—but is not identical to—these construction concepts.
5.5.
An Overview of the GenCOM Domain Model 5.5.1.
Major Categories of Classes
The GenCOM domain model consists of a number of class definitions that can represent construction concepts and information. GenCOM has been implemented using the SOL data model; it consists of the 36 classes shown in figure 5.2 (4,550 lines of code). These classes can be arranged into major categories as illustrated in figure 5.3. These categories are for organizational purposes only; the system does not require them. This section provides an overview of the model by describing the major class categories as 70
Company
RectangularConcreteAddOn
CylindricalConcreteComponent
EquipmentResource
CrewResource
MaterialResourceCategory
MaterialResource
LaborResource
RectangularVoid
ResourceUse
RectangularConcreteComponent
Project
ProjectParticipant
EquipmentResourceCategory
Resource
Contract
Facility
RectangularVolume
LaborResourceCategory
ConcreteComponent
Component
ConstructionPlan
ResourceUseCategory
ResourceCategory
CrewResourceCategory
ActivityCategory
Volume CylindricalVolume SOLCategory
ComponentCategory
ResourceRelationship
ProjectSpecificObject
Person
ConstructionMethod
•
Activity
Action
SOLObject
A Domain Model for Project Management and Construction
follows (the remainder of this chapter goes on to describe the contents of each category in detail): The Product Model (see section 5.7) includes those classes that represent the actual
Figure 5.2: The classes that make up the GenCOM model, shown in inheritance hierarchy
71
A Domain Model for Project Management and Construction
ProjectSpecific
ProjectIndependent
Product Model
Process Model
Component Category concrete columns - standard dimensions
Activity Category pump conc. columns - avg. productivity rate
Concrete Component
Activity
column 42
pump conc. for column 42
- location
- duration
legend :
A Class
Resource Model Resource Category conc. pump truck - average unit cost Rental Equipment conc. pump truck 13 - rental company
Organization Model Material Supplier jake's lumber - phone number
Contract mechanical supply contract - contract price
An Instance - an attribute
Figure 5.3: The major categories in the GenCOM domain model for project management and construction, with example classes and instances product; i.e., the constructed facility and its physical components. This portion of the domain model overlaps significantly with models defined for other stages of the project life cycle, such as 3-D CADD models or models used by architectural and structural design programs. •
The Process Model (see section 5.8) consists of classes representing the construction process used to create the facility described by the product model. Unlike the product model, there is very little overlap between the representation of the construction process and any information represented in other project models. I have adopted the activity as a unit of construction effort. This is a more general concept than a typical scheduling activity, which is primarily a logically constrained interval in time, and it implies no specific level of detail (i.e., an individual laborer’s tasks and work packages are both specific types of the general concept “activity”).
•
The Resource Model (see section 5.9) contains classes that represent anything employed in performing the construction process.
•
The Organization Model (see section 5.10) consists of classes that represent the organizational context of the project—for example, the companies and individual people participating in the project, the contracts that exist between these companies, etc.
72
A Domain Model for Project Management and Construction
Besides the above four categories, most classes fall into one of the two following designations: • Project-Independent classes do not refer to any one specific project. These classes often, though not necessarily, represent collections or categories of things, such as a “form-concrete activities” class that represents information applicable to all concrete forming operations (e.g., average productivity rates). •
Project-Specific classes relate to one specific project. They often represent individual things that are members of project-independent category classes. For example, a “form column 42” class would represent a specific construction activity on some job, and would be a member of the project-independent “form-concrete activities” class.
At a high level, then, the domain model includes classes to represent the product, the construction process, the resources used to perform the process, and the project’s organizational context—for both project-independent and project-specific information in each case. 5.5.2.
Scope of the Domain Model
Since a general domain model provides a unifying ontology across a spectrum of project management applications, the model’s scope should include a wide variety of construction operations applied to many different project types, and the level of granularity should accommodate the most detailed applications. As stated in section 5.3, however, models are evolutionary in nature. The scope of the GenCOM domain model suggests directions for large-scale domain-model development and supports prototype experimentation. GenCOM’s breadth covers the central project management concepts from the viewpoint of most typical construction planning CAPM applications (e.g., scheduling or estimating; control applications such as schedule and cost control use very similar concepts). The depth of the model includes general, high-level representations of these central concepts, as well as specific specialization subclass hierarchies for representing the construction of typical cast-in-place concrete structural members. 5.5.3.
Diagrams and examples of GenCOM Classes
The remainder of this chapter uses a series of diagrams to depict the GenCOM classes and to provide an example of their use. Figure 5.4 provides a key for these diagrams. The example diagrams show the instances of the GenCOM classes used to represent a single
73
A Domain Model for Project Management and Construction
A Class: class name class attribute values
instance attribute definitions
ClassName -superclass=ASuperClass -secondarySuperclasses= AnotherSuperClass -anIntegerAttribute (i) -aRealNumberAttribute (d) -aCharacterStringAttribtue (s) -aRelationshipAttribute (r) -aRelationshipSetAttribute(R)
optional connection to inverse relationship
An Instance: class name instance name instance attribute values
Attribute Types: i = integer number d = real number (double percision) s = character string r = relationship R = relationship set (max. cardinality >1)
ClassName instanceName -anIntegerAttribute=7 -aRealNumberAttribute=427.94 -aCharacterStringAttribtue= any string -aRelationshipAttribute= anInstanceName -aRelationshipSetAttribute= anInstanceName1, anInstanceName2
optional connection to subclasses
optional connection to relationship value (in addition to, or in place of instance name)
Figure 5.4: A legend for the object diagrams used throughout this chapter concrete column, the construction activity of placing concrete for the column, and some of the related resources and project organization. The example shows each instance’s attributes and their values, although a few attributes such as libraryName and edited are omitted for clarity. This example is presented both incrementally throughout the following sections and as a complete illustration in figures 5.16 through 5.19. 5.5.4.
High-Level GenCOM Classes
Figure 5.5 illustrates classes used to represent high-level project management concepts. Subsequent sections provide greater detail about these classes and describe the related lower-level classes. These sections should be read in conjunction with section 5.11, which provides an example of how to use these classes to represent construction data, and with appendix II, which gives the full class documentation of each class.
74
Project-Independent
-components (R) -project (r)
ProjectSpecificObject
Facility -superclass=
-activities (R) -componentCategory (r) -count (i) -facility (r) -location (s) -quantity (d) -quantityUnits (s) -supportedComponents (R) -supportingComponents (R)
ProjectSpecificObject
Component -superclass= -activities (R) -defaultConstMethods (R) -durationUnits (s) -project (r)
ProjectSpecificObject
ConstructionPlan -superclass=
-activityCategories (R) -constructionPlans(R)
Method -superclass=SOLObject
-activityCategories (R)
Time Attribs. -earlyFinish (d) -earlyStart (d) -lateFinish (d) -lateStart (d) -duration (d) -totalFloat (d)
Topological Attribs. -activityCategory (r) -constructionPlan (r) -components (R) -predecessor Activities (R) -successor Activities (R)
Organizational Attribs. -responsibility (r)
Resource Attribs> -resourceUse (R)
Cost Attribs. -units (s) -quantity (d) -quantityFormula (s) -unitPrice (d) -cost (d)
ProjectSpecificObject
Activity -superclass=
-action (r) -activities (R) -componentCategories (R) -method (r) -partOf (R) -quantityFormula (s) -resourceUse (R) -subCategories (R) -subParts (R) -superCategories (R) -unitPrice (d) -units (s)
-activityCategories (R) -components (R)
Action -superclass=SOLObject
ActivityCategory -superclass=SOLCategory
ComponentCategory -superclass=SOLCategory
Process Model
Figure 5.5: Some of the high-level classes that make up the GenCOM domain model
Project- Specific
Product Model
-activity (r) -conversion (d) -cost (d) -quantity (d) -resourceUseCategory (r) -resourceCategories (R) -resources (R) -unitPrice (d) -units (s)
ResourceUse -superclass=ProjectSpecificObject
-resourcesCategory (R) -partOf (R) -subparts (R) -resourceUse (R) -units (s) -unitPrice (d)
Resource -superclass=ProjectSpecificObject
-resourceUse (R) -activityCategories (R) -resourceCategories (R) -units (s) -conversion (d) -unitPrice (d)
-participants (R) -project (r)
-superclass= ProjectSpecificObject
Contract
-activities (R) -company (r) -contactPeople (R) -contracts (R) -project (r)
-superclass= ProjectSpecificObject
ProjectParticipant
-address(s) -employer (r) -fax (s) -firstName (s) -lastName (s) -phone (s) -projects (R) -title (s)
Person -superclass=SOLObject
-address(s) -fax (s) -fullName (s) -personnel (R) -phone (s) -projects (R)
-resources (R) -partOf (R) -subparts (R) -resourseUseCategories (R) -resourceUse (R) -units (s) -unitPrice (d)
ResourceUse Category -superclass=SOLCategory
Company -superclass=SOLObject
Organization Model
ResourceCategory -superclass=SOLCategory
Resource Model
A Domain Model for Project Management and Construction
75
A Domain Model for Project Management and Construction
5.6.
General Classes
GenCOM includes a few classes that are very general in nature and apply across the breadth of the model. As shown in figure 5.6 and documented in appendix II, these classes are as follows: •
SOLCategory: SOLCategory is a meta-class (i.e., there should not be any instances of this class, only of its subclasses) that implements the general concept of a category.
•
ProjectSpecificObject: ProjectSpecificObject is a meta-class for all classes that represent information applicable to a specific project. The class adds the project number as an attribute that provides non-relationship access to any project-specific object’s project.
•
Project: The Project class provides a top-level representation of a construction project as a whole. The Project class defines relationship attributes to the representation of the facility (see the product model, section 5.7), the construction plan (see the process model, section 5.8), and the project’s contracts and participants (see the organization model, section 5.10), as well as an attribute to describe the project’s location.
SOLCategory -superclass=SOLObject
Volume -superclass=SOLObject
-memberSuperClass (s)
-dimensionUnits (s) -volume (d)
ProjectSpecificObject -superclass=SOLObject
CylindricalVolume -superclass=Volume
RectangularVolume -superclass=Volume
-diameter (d) -height (d)
-depth (d) -width (d) -height (d)
-projectNumber (s)
Project -superclass= ProjectSpecificObject -constructionPlan (r) -contracts (R) -facility (r) -location (s) -participants (R)
Figure 5.6: Class diagram for general classes 76
A Domain Model for Project Management and Construction
•
Volume, CylindricalVolume, and RectangularVolume: These classes define basic three-dimensional geometric shapes. The volume of these shapes recalculates automatically whenever their dimensional attributes change. Project component classes inherit these classes.
GenCOM currently uses character-string or numeric attributes to represent common data elements such as locations, dates, and times. Specially defined attribute types could better represent these. Ideally, however, the model would define special classes to represent such data (e.g., other objects would have relationships to location or time objects). This would allow operations for manipulating these common data types to be encapsulated with their representation scheme.
5.7.
The Product Model
The product model contains classes that represent the actual product being created or modified by the project: a building, for example. The representation of the product is central to all reasoning about the project. However, the product model is the focus of many research efforts throughout the AEC community because it is equally important to architects, structural engineers, facility managers, etc. For example, the CADDIE system [Chinowsky 91], a knowledge-based system to generate architectural space-layout plans, models buildings in terms of the spaces they encompass, while the structural-steel-framing model [Lavakare 89], [Phan 90], an object-oriented domain model for structural steel, models buildings in terms of their structural-steel members. The STEP/PDES effort also centers around the representation of the actual product. Many difficult issues remain to be solved in the representation of AEC products. For example, how can we represent buildings both as collections of spaces (an architectural view) and as sets of structural components (a structural engineering view), while simultaneously maintaining all the interrelationships and constraints necessary to maintain two different representations of the same thing? Because other researchers are addressing product modeling issues, this dissertation does not focus on this aspect of project modeling. Rather, it defines a simple, illustrative set of classes that can represent construction products, and it explores the requirements of a product model from a project management and construction point of view. Project management’s emphasis is on individual product components (e.g., individual beams, columns, mechanical equipment). Relevant information includes the components’
77
A Domain Model for Project Management and Construction
classification (the type of component), geometry (the components’ location, quantities, etc.), and topology (e.g., which components support other components, for identifying precedence relationships). Thus the product model represents product information that is relevant to construction. However, most construction information does not relate to the components directly, but rather to the construction operations involving the components. The GenCOM model represents this operational information in the process model (see section 5.8), and parallel product and process models coexist with many inter-relationships between them. This approach provides a richer and more explicit representation than models that assign all process information (e.g., schedule dates) directly to the component objects, or to CADD models, which are typically graphically oriented product models. Figure 5.7 shows the following product model classes, figure 5.8 provides example instances, and appendix II contains their full documentation: •
Facility: The Facility class represents a building or other construction product as a whole. The class defines relationships to the corresponding project object and to all the components that make up the facility.
•
Component: A component is the fundamental unit of the product model. It represents a specific physical object that is part of the final product. The Component class includes attributes describing the component’s location and quantity. Although there may be several different ways of defining the quantity of a component (e.g., we can measure columns in cubic yards of concrete, height of a standard-diameter column, tons of steel, etc.), I adopted a single measurement as the standard quantity format for each type of component. The Component class also has relationships to the component’s category, to the facility that the component is a part of, to the activities that operate on the component, and to any supporting or supported components. Although the current version of GenCOM does not allow aggregation hierarchies for components, this capability will likely exist in future systems since it significantly improves the flexibility of the model.
•
ComponentCategory: A ComponentCategory is a project-independent class that represents categories of components. For example, a typical instance might be “round concrete columns.” The class defines relationships to any components that are members of the category and to the activity categories that produce this component (see section 5.8.3 for a discussion of activities).
78
Project-Independent
A Domain Model for Project Management and Construction
Product Model ComponentCategory -superclass=SOLCategory -activityCategories (R) -components (R)
Component -superclass= ProjectSpecificObject
Project- Specific
-activities (R) -componentCategory (r) -count (i) -facility (r) -location (s) -quantity (d) -quantityUnits (s) -supportedComponents (R) -supportingComponents (R)
ConcreteComponent -superclass=Component -addOns (R) -concreteStrength (d) -reinforcementRatio (d) -voids (R)
CylindricalConcrete Component -superclass= ConcreteComponent -secondarySuperclasses= CylindicalVolume
Facility -superclass= ProjectSpecificObject -components (R) -project (r)
RectangularVoid -superclass= ProjectSpecificObject -secondarySuperclasses= RectangularVolume -partOf (r)
RectangularConcrete Component -superclass= ConcreteComponent -secondarySuperclasses= RectangularVolume
RectangularConcrete AddOn -superclass= Rectangular ConcreteComponent -partOf (r)
Figure 5.7: The GenCOM product model classes
79
A Domain Model for Project Management and Construction
ComponentCategory rectangularConcreteColumns -activityCategories= ActCats:formRectCols ActCats:rebarCols ActCats:placeConcCols -components= Facility:column_1 -description= the category of all rectangular concrete columns.
Facility
Component
testFacility
column_1
-components= Facility:column_1 Facility:singleFoundation_1 -description= the test-project facility -project= TestProj:testProject -projectNumber=001
-activities= Plan:form_column_1 Plan:rebar_column_1 Plan:placeConcrete_column_1 -addOns= -componentCategory= ComponentCategories: rectangularConcreteColumns -concreteStrength=3000 -count=1 -depth=24 -description= a rectangular column (object created by CADLink) -dimensionUnits=in -facility=Facility:testFacility -height=160 -location=(100.00, 100.00, 0.00) -projectNumber=001 -quantity=1.975 -quantityUnits=cy -reinforcementRatio=2 -supportedComponents= -supportingComponents= Facility:singleFoundation_1 -voids= -volumn=92160 -width=24
Figure 5.8: Example instances of the GenCOM product model classes
80
A Domain Model for Project Management and Construction
•
ConcreteComponent: The ConcreteComponent class represents cast-in-place concrete components. Besides the attributes inherited from the Components class, it defines concrete strength and reinforcement ratio attributes. The class also defines relationships to voids and add-ons, which are shapes that are excluded from or added on to the basic concrete component. For example, a window or door opening is treated as a void in a wall, while a column drop cap is treated as an add-on to a slab component.
•
CylindricalConcreteComponent and RectangularConcreteComponent: These classes represent concrete components of specific geometric shapes. These classes define no new attributes, but they inherit both from the ConcreteComponent class and the geometric volume classes.
•
RectangularConcreteAddOn and RectangularVoid: These classes represent add-ons and voids as described above.
5.8.
The Process Model 5.8.1.
Construction is a Process
While the product model describes the state of a facility, the process model describes the process used to create the facility—the construction process. During the construction phase, much of the information relevant to participants describes the facility-creating process rather than the facility itself. A domain model for project management and construction, then, must represent the construction process. 5.8.2.
Review of Existing Construction Process Representations
Some of the alternative techniques that various commercial and research construction software programs use to represent the construction process are as follows: •
Scheduling: Traditional scheduling systems represent the construction process by a plan or schedule that they break down into units typically called activities. Activities represent a process that must occur over some time interval. Activities have descriptive labels (e.g., “install glazing”), durations, and starting and ending dates. Network scheduling methods also add relationships to prerequisite activities, allowing the calculation of early and late starting and ending dates as well as float values.
81
A Domain Model for Project Management and Construction
Activities can include relationships to the resources they consume, and plans can include milestones, which are events that occur at an instant in time rather than over an interval and which typically represent the achievement of some state (e.g., “structure enclosed”). Appendix IV gives an object-oriented model of the information used to represent projects by the Primavera Project Planner schedule program. •
Estimating: An estimate calculates the cost of a project using the characteristics of the facility, as well as the characteristics of the methods used to construct the facility. An individual cost item cannot be accurately priced unless the facility component, the method, and the resources are specified. This even holds true for a simple lump-sum price to supply and install a component; it simply assumes that standard or typical methods and resources are used. Estimates, then, represent the construction process by enumerating the operations to be performed on the facility components, and by providing quantity, unit price, productivity, and similar attributes. Appendix IV gives an object-oriented model of the information used to represent projects by the Timberline Precision Plus Estimating program.
•
Work Breakdown Structure (WBS): A WBS divides the construction process into a hierarchy of specific sub-processes, often called work packages. Each work package receives a name and unique code number. The hierarchy and the code number often include elements of both specialization and aggregation relationships. For example, a work-package code may include a six-digit number identifying the classification of the work to be done, and a two-digit number identifying the portion of the project to which the work relates. Work packages can then be used as activities in a schedule, as estimate items in an estimate, etc., and can relate the units of one application to another.
•
Proprietary Integrated Systems: Large construction and engineering companies’ propriety integrated project-management systems, such as Kaiser’s KEMS system [Kaiser 90a], [Kaiser 90b], use estimating, scheduling, and other applications that represent the construction process as described above. Programs share data though direct file transfers between themselves or through shared relational databases. This requires that the units used in any one application be mapped to any other. The KEMS system, for example, allows the definition of a project WBS that identifies the facility area, the work element, the contract, etc. Planners assign identification codes to both estimate items and schedule activities based on the WBS codes, and assign 82
A Domain Model for Project Management and Construction
each estimate item to a specific activity. These systems, then, represent the construction process through a combination of specific applications’ representations. •
AI Planning Systems: AI planning systems represent the construction process as a plan made up of activities, similar to scheduling systems described above. However, the emphasis is on constraints that govern the relative ordering of the activities rather than on temporal attributes. The inputs of domain-independent AI planners are an initial-state description, a goal-state description, and a set of domain-specific activities with explicit applicability requirements and consequent operations. Their output is a linear or partial ordering of actions, termed a plan [Kartam 89, p. 8]. OARPlan, an example of a domain-specific knowledge-based planning system, defines activities as the application of an action to an object using specific resources [Darwiche 88] (this “object-action-resource” representation of activities originated with [Marshall 87]). Starting with a general activity such as “construct building,” OARPLAN uses rules to iteratively refine both the objects (e.g., “construct building” is refined to “construct floor 1,” “construct floor 2,” etc.) and the actions (e.g., “construct concrete column” is refined to “form column,” “install reinforcing for column,” “place concrete for column,” etc.). The system uses relationships extracted from the CADD building model such as “supported-by” to establish precedence relationships between activities.
•
Building Process Models: Sanvido’s Integrated Building Process Model is an extensive model of the building process [Sanvido 90]. It uses the IDEF0 modeling methodology [Integrated 81] to represent the entire building life cycle. The model identifies each function required to provide a facility (in a five-level hierarchical breakdown) and describes the inputs, outputs, controls, and mechanisms involved in each function. The main purpose of this model is to provide a better, more formal understanding of the steps involved in providing a facility and of the interrelationships that exist between these steps. This model’s relevance to the development of a general domain model for construction is that many of the IBPM functions’ outputs and most of its controls are forms of information. This provides a detailed listing of all the types of information that could potentially be represented in a model such as GenCOM. Furthermore, the IBPM functions correspond to areas that may benefit from computer applications that use integrated information.
•
Other Object-Oriented Domain Models: Grobler, in his work on reusable software objects for construction, defines a Primitive Element for Construction (PEC) [Grobler 88, p. 56] as a fundamental unit of construction work based on schedule 83
A Domain Model for Project Management and Construction
activities and budget items. Grobler defines a PEC as a task that can be performed by one crew type, can fit entirely into one scheduling activity, and can be associated with at least one identifiable physical object. This offers a fairly general representation of the construction process and allows good integration between specific applications. However, it implies a specific level of detail (e.g., it is performed by one crew type, it fits into one scheduling activity, etc.), thus the schedule and estimate cannot be integrated until the work is specified at this level of detail. Furthermore, PECs represent a mapping or relationship between specific applications (primarily the schedule and budget) rather than a fundamental construction concept. For example, the approach represents some quantity of construction effort using schedule activities and budget items, with PECs to interrelate them. A more explicit and general approach is to use an object that literally represents the construction effort, and to derive schedule activities, estimate items, etc., from these. 5.8.3.
A General Representation of the Construction Process
The GenCOM model represents the construction process in a way that combines the construction concepts discussed in section 5.4, the application analysis described in section 5.2, and many of the ideas adopted by other systems, as described in section 5.8.2. Figure 5.9 shows the following process model classes, figure 5.10 provides example instances, and appendix II contains their full documentation: •
Action: The product model represents physical components using ComponentCategory and Component classes. The actions that can be applied to these components are represented by the Action class in the process model. As shown in the conceptual model of construction (section 5.4), actions reflect a change in the state of a component. The Action class currently contains only a name, a description, and a relationship to the set of ActivityCategory objects that involve the action.
•
ActivityCategory: The conceptual model of construction identifies a construction goal as the application of an action to a component, and a construction activity as the construction effort used to achieve that goal. GenCOM does not represent the construction goal, since an explicit representation of a construction goal appears rarely to be useful for applications and it is possible to represent a goal as a partially defined activity (described below). GenCOM does represent construction activities
84
A Domain Model for Project Management and Construction
Project-Independent
Process Model Action -superclass=SOLObject
Method -superclass=SOLObject
-activityCategories (R)
-activityCategories (R) -constructionPlans (R)
ActivityCategory -superclass=SOLCategory -action (r) -activities (R) -componentCategories (R) -method (r) -partOf (R) -quantityFormula (s) -resourceUse (R) -subCategories (R) -subParts (R) -superCategories (R) -unitPrice (d) -units (s)
ConstructionPlan -superclass=
Activity -superclass=
Project- Specific
ProjectSpecificObject -activities (R) -defaultConstructionMethods (R) -durationUnits (s) -project (r)
ProjectSpecificObject Topological Attribs. -activityCategory (r) -constructionPlan (r) -components (R) -predecessor Activities (R) -successor Activities (R) Time Attribs. -earlyFinish (d) -earlyStart (d) -lateFinish (d) -lateStart (d) -duration (d) -totalFloat (d)
Cost Attribs. -units (s) -quantity (d) -quantityFormula (s) -unitPrice (d) -cost (d) Resource Attribs> -resourceUse (R) Organizational Attribs. -responsibility (r)
Figure 5.9: The GenCOM process model classes
85
A Domain Model for Project Management and Construction
Action
ConstructionMethod
placeConcrete
pumpMethod
-activityCategories= ActivityCategory:placeConcCol ActivityCategory:placeConcColPump ActivityCategory:placeConcColBucket -description= the action of placing concrete.
-activityCategories= ActivityCategory:placeConcColPump -constructionPlans= Plan:constructionPlan -description= the method of using a pump for concrete operations.
ActivityCategory
ActivityCategory
placeConcCol
placeConcColPump
-action= ActivityCategory:placeConcrete -activities= -componentCategories= ComponentCategories: rectangularConcreteColumns -description= the category of placing concrete for concrete columns. This is a superclass for bucket and pump method activities. -method= -partOf= -quantityFormula=[components quantity] -resourceUse= -subCategories= ActivityCategory:placeConcColPump ActivityCategory:placeConcColBucket -subparts= -superCategories= -unitPrice= -units=cy
-action= ActivityCategory:placeConcrete -activities= Plan:placeConcrete_column_1 -componentCategories= -description= the category of placing concrete for concrete columns using a pump. -method= ActivityCategory:pumpMethod -partOf= ActivityCategory:placeConcCol -quantityFormula=[components quantity] -resourceUse= ActivityCategory:placeConcMaterial ActivityCategory: placeConcColPumpCrew -subCategories= -subparts= -superCategories= -unitPrice=70.89 -units=cy
Activity placeConcrete_column_1
ConstructionPlan constructionPlan -activities= Plan:form_column_1 Plan:rebar_column_1 Plan:placeConcrete_column_1 -defaultConstructionMethods= pumpConcrete -description= the construction plan for the test project -durationUnits=day -project= TestProj:testProject -projectNumber=001
-activityCategory= ActivityCategory:placeConcColPump -components= Facility:column_1 -constructionPlan= Plan:constructionPlan -cost=140.04 -description= the activity of placing concrete for column 1. -duration=0.17 -earlyFinish=2.32 -earlyStart=2.15 -lateFinish=2.32 -lateStart=2.15 -predecessorActivities= Plan:form_column_1 Plan:rebar_column_1 -projectNumber=001 -quantity=1.975 -quantityFormula=[components quantity] -resourceUse= Plan:place_column_1_material Plan:place_column_1_crew -responsibility= TestProj:concSub -successorActivities= -totalFloat=0 -unitPrice=256.58 -units=cy
Figure 5.10: Example instances of the GenCOM process model classes
86
A Domain Model for Project Management and Construction
and, as in the product model, it defines classes to represent both categories of activities and individual activities. Each instance of the ActivityCategory class, then, represents the category of construction effort that involves the application of a particular action to a specific set of component categories using a method and, typically, a set of resources. Correspondingly, the ActivityCategory class defines relationship attributes to the set of component categories acted on, the action applied, the method used, and the resources typically employed, as well as to the set of individual activities that belong to the category. If only the ComponentCategory and Action attributes are supplied, the partially defined ActivityCategory corresponds to a construction goal. The ActivityCategory class also defines attributes to represent typical activity cost characteristics: specifically units, unitPrice, and quantityFormula. Like the resourceuse relationships, these attributes are “typical” since the category’s activities inherit them and they usually apply, but individual activities’ own attributes can override them (see discussions of the resource model, section 5.9, and the InCost application, section 6.8, for further information about cost and resource attributes). Finally, The ActivityCategory class defines relationships to sub-categories and supercategories, which are children and parents in an activity category specialization hierarchy, respectively. For example, the ActivityCategory object “construct concrete column” may have the specialization children ActivityCategories “construct cast-inplace concrete column using pump,” “construct cast-in-place concrete column using bucket,” and “install precast column.” Similarly, the class defines relationships to sub-parts and super-parts, which are children and parents in an aggregation hierarchy, respectively. For example, the same ActivityCategory object “construct concrete column” may have the aggregation children ActivityCategories “form column,” “rebar column,” and “pour column.” •
Method: A method, as represented by the Method class, is a particular technique for performing an activity. Currently, the significance of a method is to distinguish the way that one activity accomplishes some construction goal from the way that a different activity accomplishes the same goal. Thus the Method class defines only a name, description, a relationship to the set of activities that use the method, and a relationship to any plans that adopt the method as a default method (plans may, for example, adopt a “pump concrete” method as a default technique for placing concrete). 87
A Domain Model for Project Management and Construction
•
Activity: The Activity Class represents an individual activity or unit of construction effort. That is, an activity represents the application of some action to a specific set of physical components using a construction method and set of resources. Activities have the following attributes: — topological attributes (i.e., attributes that express basic relationships): a relationship to the activity category of which it is a member. Each activity must belong to an activity category, from which it inherits its relationships to an action and a method as well as several default attributes such as unit price. The class also defines relationships to the construction plan that it belongs to, to the components that it acts on (these components must belong to the component category associated with the activity’s activity category), and to predecessor and successor activities. — temporal attributes: early and late start and finish times, a duration, and a float value. — cost attributes: units (the standard units used for measuring the quantity of the activity), quantity, quantityFormula (an equation for determining the activity’s quantity), the unit price, and the cost. — resource attributes: a relationship to the resources uses of this activity (see the resource model, section 5.9). Activities inherit resource use from the activity category if no value is provided here. — organizational attributes: relationships to the party responsible for this activity. The current version of GenCOM offers no aggregation hierarchy for individual activities. This is to simplify the prototype version of the model. Hierarchical networks significantly complicate the development of applications such as network scheduling, yet they do offer may significant modeling advantages and should be incorporated into future construction domain models. For example, aggregation hierarchies could allow users to work with an estimate or schedule at either a high conceptual level or at a very detailed level, with work in either level correctly propagating to the other. Furthermore, the aggregation hierarchy should not be a strict hierarchy, but should allow multiple possible plan breakdowns (e.g., an estimating system might break the plan down into one set of activities while a scheduling system might arrange the plan into a different set of activities). This would provide different applications with maximum flexibility, but it would require a
88
A Domain Model for Project Management and Construction
complete set of algorithms and constraints to allow neither too much nor too little information sharing among these parallel units of construction activity. •
ConstructionPlan: The ConstructionPlan class represents the overall plan, or complete construction effort, involved in some project. The class defines an attribute to store the time unit used for activity durations in this plan, as well as relationship attributes to the project it acts upon, to the set of all activities involved in the plan, and to any methods adopted as default methods. If aggregation-hierarchical activities existed, a construction plan could just be a high-level activity and would not need to be represented as a separate class. 5.8.4.
Alternative Approaches
The following sections describe alternative approaches or future modifications to the way that the GenCOM model represents the construction process. 5.8.4.1.
Work Breakdown Structures
In existing construction applications, a work breakdown structure—a categorization of all construction tasks into a hierarchical coding system—is vital for indexing all data items and for mapping data between applications. This universal index is not as critical for the proposed system because relationships partially supplant the need for indices (e.g., the system can use relationships to access all the activities associated with some component, all the activities performed by some participant, all the subparts of some activity, etc.). However, work breakdowns could still provide useful organizational structures for identifying and sorting project data. I envision that the GenCOM model could represent work breakdown indices as separate objects that represent a code number, or an alias identifier, for a related hierarchical activity or activity category object. These work breakdown objects would have their own hierarchical relationships among themselves. Thus the work breakdown objects could help access specific activities, and activities would be able to report their work breakdown indices. Using this approach, GenCOM could create many different work breakdown structures for a project, and since we know the relationships among the corresponding activities, each work breakdown structure could map to the others. Furthermore, existing work breakdown structures are important for the GenCOM model since they currently organize project elements into useful units. These breakdowns
89
A Domain Model for Project Management and Construction
could provide input into the process of developing similar subclass hierarchies of activities, activity categories, etc. 5.8.4.2.
Versioning
Because the prototype GenCOM model’s scope is limited to project planning, all attributes represent “as-planned” values. In a complete model, it is necessary to maintain multiple value sets, such as “initial plan,” “current plan,” or “actual to-date.” There are several ways to achieve this. First, maintain multiple copies of the database, one for each value set. Comparisons can be made by evaluating the different database copies. This approach is inefficient, however, since there would be significant amounts of redundant data in each copy of the database, it would be difficult to establish definitive boundaries between different value states, and it would be difficult to maintain consistency among the database copies. Second, define multiple attributes, e.g., an “as-planned activity duration,” an “actual activity duration,” etc. This approach is useful if few versions are required, but it becomes unwieldy if many different versions of many attributes are required (existing programs such as Primavera use a combination of these two approaches). Third, the most explicit and flexible approach is to use versioning, as defined in section 4.3.1. This would allow the creation of an as-planned version of an activity object, an actual to-date version, etc. Each version would store only non-redundant data and the system would automatically maintain consistency among the versions. This third approach, then, is preferable if the data model supports versioning; however the SOL model used for defining GenCOM does not. 5.8.4.3.
Explicit Goal Representation
The definition of a construction goal is conceptually satisfying, but it does not seem relevant for typical construction applications and, therefore, it has been excluded from the GenCOM model. The model could define an explicit construction goal class if it was found to be useful for applications (e.g., for an expert planning system that first determines construction requirements and then evaluates different activities for achieving those goals). As always, significant changes to other portions of the model would not be needed because of the modularity of the object-oriented data model. More generally, it may be beneficial to represent multiple stages of a construction activity, of which an “as-required” stage would correspond to a construction goal. Other stages could include “as-planned,” “as-executed,” etc. This is similar to the STEP/PDES approach of representing multiple stages of a product’s life cycle (see section 5.4) and would use versioning, as described above.
90
A Domain Model for Project Management and Construction
5.8.4.4.
Actions and Method
Physical components and resources clearly exist independently of associated construction activities, and a construction domain model should explicitly and independently represent them. I contend that, although it is less obvious, actions and methods similarly exist independently of their associated construction activities and the model should explicitly and independently represent them as well. For example, it is possible to compare the general characteristics of a “cast-in-place” method versus a “precast” method. Other arguments exist, however. For example, the concept of a method might depend upon an activity, and should only be represented as an object dependent upon an activity object (e.g., the above methods would only exist if related to the activities “construct cast-in-place concrete component” and “install precast concrete component,” respectively, they would be meaningless as unrelated objects). Furthermore, it would be possible to represent both actions and methods as simple text attributes of activities rather than as relationships to separate objects. While maintaining actions and methods as separate objects enables efficient searching of activities by their action or method, text attribute searches can accomplish this as well. If any information that describes actions or methods needs to be represented, then they should exist as separate objects; however, if the only relevant attributes of actions and methods are their names, then they are better represented as simple text attributes of activities. More experience gained from using the model will help to resolve this issue. 5.8.4.5.
Replicating the Construction Process
A representation of the construction process can have two roles. First, it can describe the process. Second, it can replicate the process. For example, the representation of the construction process could alter the state of the product model just as the actual construction process alters the state of the actual facility. The model’s process-replication role could be represented explicitly as a series of simulation procedures, for example. The GenCOM approach, however, is to provide the representation of sufficient knowledge about the process to allow the replication of the process to be performed on the product model. Applications can then use the general model to perform the process simulation, which need not be incorporated into the model itself.
91
A Domain Model for Project Management and Construction
5.9.
The Resource Model
The resource model defines the representation of the resources used in the construction process. Resources can be labor, equipment, materials, or less tangible resources such as information, working space, etc. The main components of the resource model are the resources themselves (both resource categories and individual resources), and the representation of the application of a resource to an activity, called a resource use (again, both resource use categories and individual resource uses). Figure 5.11 shows the following product model classes (figures 5.12 and 5.13 provide example instances): •
ResourceCategory: Instances of the ResourceCategory class represent a category of resources used in construction (e.g., “25 Ton self-propelled cranes”). The ResourceCategory class defines the following attributes: — resources: a relationship to the individual resources that are members of this category. — resourceUseCategories and resourceUse: relationships to the sets of ResourceUseCategories and ResourceUse objects that involve this ResourceCategory (see the descriptions of these classes below). — partOf and subparts: relationships to the ResourceCategory’s parent and children respectively in a resource category aggregation hierarchy. — units and unitPrice: attributes to describe the typical units used for measuring resources of this type and unit price. These attributes are inherited by—but can be overridden by—individual resources in this category. If the resource category has subparts, the unit price should come from the summed unit prices of the subparts (see the InCost system, section 6.8).
•
Resource: The Resource class represents individual resources used in construction and defines the following attributes: — resourceCateogry: a relationship to the ResourceCategory to which the resource belongs. For example, the Resource “crane #37” might have a membership relationship to the ResourceCategory “25-Ton self-propelled cranes”. — partOf and subparts: relationships to the Resource’s parent and children respectively, in an aggregation hierarchy.
92
A Domain Model for Project Management and Construction
Resource Model
Project-Independent
ResourceUse Category -superclass=SOLCategory -resourceUse (R) -activityCategories (R) -resourceCategories (R) -units (s) -conversion (d) -unitPrice (d)
ResourceCategory -superclass=SOLCategory -resources (R) -partOf (R) -subparts (R) -resourseUseCategories (R) -resourceUse (R) -units (s) -unitPrice (d)
Resource Relationship -superclass=SOLObject
LaborResourceCategory -superclass=ResourceCategory
-partOf (r) -subparts (R) -conversion (d) -subpartCount (d)
EquipmentResourceCategory -superclass=ResourceCategory CrewResourceCategory -superclass=ResourceCategory MaterialResourceCategory -superclass=ResourceCategory
ResourceUse -superclass=
Project- Specific
ProjectSpecificObject -activity (r) -conversion (d) -cost (d) -quantity (d) -resourceUseCategory (r) -resourceCategories (R) -resources (R) -unitPrice (d) -units (s)
Resource -superclass= ProjectSpecificObject -resourcesCategory (R) -partOf (R) -subparts (R) -resourceUse (R) -units (s) -unitPrice (d)
LaborResource -superclass=Resource EquipmentResource -superclass=Resource CrewResource -superclass=Resource MaterialResource -superclass=Resource
Figure 5.11: The GenCOM resource model classes 93
A Domain Model for Project Management and Construction
ResourceUseCategory placeConcMaterial -activityCategory= ActivityCategory:placeConcColPump -conversion=1.0 -description= resource Use of concrete material for concrete components. -resourceCategories= Resources:concrete3000 -resourceUse= Plan:place_column_1_material -unitPrice=53.20 -units=cy
ResourceCategory concrete3000* -description= 3000 psi concrete. -partOf= -resources= -resourceUse= Plan:place_column_1_material -resourceUseCategories= ActivityCategory:placeConcMaterial -subparts= -unitPrice=53.20 -units=cy
ResourceUseCategory
ResourceCategory
placeConcColPumpCrew
crewC20 *
-activityCategory= ActivityCategory:placeConcColPump -conversion=0.087 -description= resource Use of concrete pump crew for concrete columns. -resourceCategories= Resources:crewC20 -resourceUse= Plan:place_column_1_crew -unitPrice=203.38 -units=hr
-description= medium sized concreting crew with pump. -partOf= -resources= -resourceUse= Plan:place_column_1_crew -resourceUseCategories= ActivityCategory:placeConcColPumpCrew -subparts= Resources:crewC20Equipment Resources:crewC20Laborers Resources:equipmentOperator -unitPrice=203.38 -units=hr
ResourceUse place_column_1_material -activity= Plan:placeConcrete_column_1 -conversion=1.0 -cost=105.09 -description= resource Use of concrete material for column 1. -projectNumber=001 -quantity=1.975 -resourceCategories= Resources:concrete3000 -resources= -resourceUseCategory= ActivityCategory:placeConcMaterial -unitPrice=53.20 -units=cy
* These instances repeated in figure 5.13
ResourceUse place_column_1_crew -activity= Plan:placeConcrete_column_1 -conversion=0.087 -cost=34.95 -description= resource Use of concrete pump crew for column 1. -projectNumber=001 -quantity=0.171 -resourceCategories= Resources:crewC20 -resources= -resourceUseCategory= ActivityCategory:placeConcColPumpCrew -unitPrice=203.38 -units=hr
Figure 5.12:
Example instances of the GenCOM resource model classes depicting resource use 94
A Domain Model for Project Management and Construction
ResourceCategory concrete3000 * -description= 3000 psi concrete. -partOf= -resources= -resourceUse= Plan:place_column_1_material -resourceUseCategories= ActivityCategory:placeConcMaterial -subparts= -unitPrice=53.20 -units=cy
Figure 5.13:
* These instances repeated in figure 5.12
ResourceCategory
ResourceCategory
crewC20 *
equipmentOperator
-description= medium sized concreting crew with pump. -partOf= -resources= -resourceUse= Plan:place_column_1_crew -resourceUseCategories= ActivityCategory:placeConcColPumpCrew -subparts= Resources:crewC20Equipment Resources:crewC20Laborers Resources:equipmentOperator -unitPrice=203.38 -units=hr
-description= equipment operator (med.). -partOf= Resources:crewC20 -resources= -resourceUse= -resourceUseCategories= -subparts= -unitPrice=22.10 -units=hr
ResourceRelationship
ResourceRelationship
crewC20Equipment
crewC20Laborers
-conversion=0.125 -description= converts equipment's units (day) to crew's units (hr). -partOf= Resources:crewC20 -subpartCount=1 -subparts= Resources:concPumpSmall
-conversion=1 -description= adds 7 laborers to the crew C20. -partOf= Resources:crewC20 -subpartCount=7 -subparts= Resources:laborer
ResourceCategory
ResourceCategory
concPumpSmall
laborer
-description= small concrete pump truck. -partOf= Resources:crewC20Equipment -resources= -resourceUse= -resourceUseCategories= -subparts= -unitPrice=489.8 -units=day
-description= buiding laborer. -partOf= Resources:crewC20Laborers -resources= -resourceUse= -resourceUseCategories= -subparts= -unitPrice=17.15 -units=hr
Example instances of the GenCOM resource model classes depicting a resource category hierarchy
95
A Domain Model for Project Management and Construction
— resourceUse: a relationship to the set of ResourceUse objects that involve this Resource (see the descriptions of this class below). — units and unitPrice: attributes to describe the units used for measuring this resource and its unit price. These attributes are inherited from the resource’s ResourceCategory object if they are not otherwise supplied. Again, the unit price should correspond to the unit prices of any subparts. •
ResourceUseCategory: The ResourceUseCategory class represents the use of a specific category of resources for a specific category of activities (e.g., painting [an activity category] uses painters [a resource category]). The class defines relationships to the associated ActivityCategory and ResourceCategory objects and to any ResourceUse objects that are members of this category. The class also defines attributes for describing the units used for measuring the resource use, the unit price derived from the resource categories’ unit prices, and a conversion factor for converting the unit price to the activity category’s units (see the InCost system, section 6.8).
•
ResourceUse: The ResourceUse class represents the use of a specific resource or resource category for a specific activity (e.g., painting wall #643 [an activity] uses painters [a resource category], or painting wall #643 [an activity] uses painter Jones [a resource]). The class defines relationships to the associated Activity, Resource, and ResourceCategory objects and to the ResourceUseCategory objects to which the ResourceUse object belongs. I define units, unit price, and conversion factor attributes as above, and provide a cost attribute to give the total cost of the resource use.
•
ResourceRelationship: The ResourceRelationship class exemplifies using a class to add information to a relationship, rather than to model some conceptual entity. ResourcesCategories or resources can have relationships to subparts (e.g., a crew resource object can have a subpart relationship to a laborer resource object). There may, however, be information relevant to this relationship; specifically the number of units of the subpart (if other than one) and the conversion factor from the units used to measure the subpart to the units used to measure the parent (e.g., a crew resource object [measured in hrs.] can have a subpart relationship to three laborer resource objects [measured in days] with a conversion factor of 8 working hrs/day). This additional relationship information is represented by forming subparts’ relationships
96
A Domain Model for Project Management and Construction
from the parent resource object to a ResourceRelationship object, and from that to the child resource object. The ResourceRelationship object’s attributes store the relationship’s conversion and subpart count data. GenCOM defines subclasses of both the ResourceCategory and the Resource classes to represent labor, equipment, material, and crew resources (a crew resource is an aggregation of labor and equipment resources that all operate together as a unit). These subclasses have no additional attributes in the current GenCOM model, but they allow resources to be classified appropriately (e.g., a resource can be identified as a labor resource if it is an instance of the LaborResource class).
5.10.
The Organization Model
The organization model consists of classes that represent organizational aspects of a construction project. These include such entities as the companies and individuals involved in the project and the contracts that exist among these companies. The representation of the project organization is beyond the primary focus of the prototype GenCOM model, and thus I do not develop it in detail here. However, it is central to many conceivable project management applications (e.g., contract management programs, change-order tracking programs, or knowledge-based systems such as the Virtual Design Team project to simulate organizations [Cohen 91], [Cohen 92]). Thus, a few organization classes are included to illustrate how the organization fits into the overall model. The organization model consists of the following classes (shown in figure 5.14 with example instances in figure 5.15): •
Company: The Company class represents any corporate entity involved in a construction project. The class’s attributes include the company’s full name, address, phone and fax number, a relationship to any of its employees that are represented in the system, and a relationship to the ProjectParticipant object that represents the company’s participation on a project.
•
Person: GenCOM represents any person by an instance of the Person class. Attributes include the person’s first and last names, title, phone and fax numbers, a relationship to the person’s company, and a relationship to the ProjectParticipant objects that represents the person’s participation on projects.
97
A Domain Model for Project Management and Construction
Project- Specific
Project-Independent
Organization Model Company -superclass=SOLObject
Person -superclass=SOLObject
-address(s) -fax (s) -fullName (s) -personnel (R) -phone (s) -projects (R)
-address(s) -employer (r) -fax (s) -firstName (s) -lastName (s) -phone (s) -projects (R) -title (s)
ProjectParticipant -superclass=
Contract -superclass=
ProjectSpecificObject -activities (R) -company (r) -contactPeople (R) -contracts (R) -project (r)
ProjectSpecificObject -participants (R) -project (r)
Figure 5.14: The GenCOM organization model classes •
Contract: The Contract class represents a contract that exists between two project participants. It defines relationships to the two participants and the project to which the contract applies.
•
ProjectParticipant: The ProjectParticipant class represents the participation of a company or individual in a project. The class defines relationships to the corporate participant, the individual participant (typically the contact person at the participating company for this project), any contracts involving the participant, and the activities that are their responsibility.
5.11.
Example
Figures 5.16 through 5.19 depict a series of instances of the GenCOM classes described above and documented in appendix II. These objects represent information
98
A Domain Model for Project Management and Construction
Company
Person
abc
brownJ
-address= 856 Main st. -description= concrete subcontractor -fax=(123) 456-7890 -fullName= ABC Concrete, Inc. -personnel= People&Co:brownJ -phone=(123) 456-7891 -projects= TestProj:concSub
-address= 856 Main st. -description= concrete sub's superintendent -employer= People&Co:abc -fax=(123) 456-7890 -firstName=Jim -lastName=Brown -phone=(123) 456-7895 -projects=TestProj:concSub -title=superintendent
ProjectParticipant concSub
Contract
-activities= Plan:placeConcrete_column_1 -company= People&Co:abc -contactPeople= People&Co:brownJ -contracts= TestProj:concSubContract -description= the project's concrete subcontractor -project= TestProj:testProject -projectNumber=001
concSubContract -description= the concrete subcontract -participants= TestProj:concSub -project= TestProj:testProject -projectNumber=001
Figure 5.15: Sample instances of the GenCOM organization model classes relating to a single construction activity, specifically a concrete-placement activity for a column. The example includes general information relating to the single activity, such as the representation of the overall project and standard productivity rates for the activity category. Of course, the GenCOM model is intended to represent such information in a computer, not on paper. However, the figures do give a specific example of the location of each piece of information and of the relationships that exist among objects.
5.12.
Conclusions
A general, standard domain model or schema is critical for all levels of system integration. This chapter has described the GenCOM model, a domain model for project management and construction. GenCOM’s major characteristics that past models do not
99
A Domain Model for Project Management and Construction
offer are its generality, richness, explicit representation of fundamental construction concepts, and object-oriented form. The model is derived both from a view of the basic concepts involved in construction, and from an analysis of the typical construction applications. GenCOM is organized into product, process, resource, and organization models. GenCOM requires further development in the areas of component and activity aggregation hierarchies and subclass hierarchies for specific branches of construction. Our intent is that the GenCOM model can act as the core of an eventual industry-wide objectoriented data standard. The full development of such a standard, however, would require extensive collaboration from all segments of the industry. This cooperative effort is a major challenge facing the industry if it is to take full advantage of future information integration capabilities.
100
A Domain Model for Project Management and Construction
Library: TestProj
a
Project
ComponentCategory
testProject
rectangularConcreteColumns
-constructionPlan= Plan:constructionPlan -contracts= TestProj:concSubContract -description= A small test project. -facility= Facility:testFacility -location= 1234 West 5th Ave. -participants= TestProj:concSub -projectNumber=001
-activityCategories= ActCats:formRectCols ActCats:rebarCols ActCats:placeConcCols -components= Facility:column_1 -description= the category of all rectangular concrete columns.
ProjectParticipant concSub
b
Library: ComponentCategories
-activities= Plan:placeConcrete_column_1 -company= People&Co:abc -contactPeople= People&Co:brownJ -contracts= TestProj:concSubContract -description= the project's concrete subcontractor -project= TestProj:testProject -projectNumber=001
Contract concSubContract -description= the concrete subcontract -participants= TestProj:concSub -project= TestProj:testProject -projectNumber=001
Company
Person
abc
brownJ
-address= 856 Main st. -description= concrete subcontractor -fax=(123) 456-7890 -fullName= ABC Concrete, Inc. -personnel= People&Co:brownJ -phone=(123) 456-7891 -projects= TestProj:concSub
-address= 856 Main st. -description= concrete sub's superintendent -employer= People&Co:abc -fax=(123) 456-7890 -firstName=Jim -lastName=Brown -phone=(123) 456-7895 -projects=TestProj:concSub -title=superintendent
c
Library: Facility Component column_1 -activities= Plan:form_column_1 Plan:rebar_column_1 Plan:placeConcrete_column_1 -addOns= -componentCategory= ComponentCategories: rectangularConcreteColumns -concreteStrength=3000 -count=1 -depth=24 -description= a rectangular column (object created by CADLink) -dimensionUnits=in -facility=Facility:testFacility -height=160 -location=(100.00, 100.00, 0.00) -projectNumber=001 -quantity=1.975 -quantityUnits=cy -reinforcementRatio=2 -supportedComponents= -supportingComponents= Facility:singleFoundation_1 -voids= -volumn=92160 -width=24
d
Facility testFacility
Library: People&Co
Figure 5.16:
-components= Facility:column_1 Facility:singleFoundation_1 -description= the test-project facility -project= TestProj:testProject -projectNumber=001
Example libraries and GenCOM instances used to represent a construction activity for placing concrete for a column (part one of four)
101
Figure 5.17:
c
e
placeConcColPump -action= ActivityCategory:placeConcrete -activities= Plan:placeConcrete_column_1 -componentCategories= -description= the category of placing concrete for concrete columns using a pump. -method= ActivityCategory:pumpMethod -partOf= ActivityCategory:placeConcCol -quantityFormula=[components quantity] -resourceUse= ActivityCategory:placeConcMaterial ActivityCategory: placeConcColPumpCrew -subCategories= -subparts= -superCategories= -unitPrice=70.89 -units=cy
placeConcCol
-action= ActivityCategory:placeConcrete -activities= -componentCategories= ComponentCategories: rectangularConcreteColumns -description= the category of placing concrete for concrete columns. This is a superclass for bucket and pump method activities. -method= -partOf= -quantityFormula=[components quantity] -resourceUse= -subCategories= ActivityCategory:placeConcColPump ActivityCategory:placeConcColBucket -subparts= -superCategories= -unitPrice= -units=cy f
ActivityCategory
ActivityCategory
-activityCategories= ActivityCategory:placeConcColPump -constructionPlans= Plan:constructionPlan -description= the method of using a pump for concrete operations.
-activityCategory= ActivityCategory:placeConcColPump -conversion=0.087 -description= resource Use of concrete pump crew for concrete columns. -resourceCategories= Resources:crewC20 -resourceUse= Plan:place_column_1_crew -unitPrice=203.38 -units=hr
placeConcColPumpCrew
ResourceUseCategory
-activityCategory= ActivityCategory:placeConcColPump -conversion=1.0 -description= resource Use of concrete material for concrete components. -resourceCategories= Resources:concrete3000 -resourceUse= Plan:place_column_1_material -unitPrice=53.20 -units=cy
placeConcMaterial
pumpMethod
placeConcrete
-activityCategories= ActivityCategory:placeConcCol ActivityCategory:placeConcColPump ActivityCategory:placeConcColBucket -description= the action of placing concrete.
ResourceUseCategory
ConstructionMethod
Action
Library: ActivityCategory
j
i
h
g
A Domain Model for Project Management and Construction
Example libraries and GenCOM instances used to represent a construction activity for placing concrete for a column (part two of four)
102
Figure 5.18:
b
a
f
d
e
-activities= Plan:form_column_1 Plan:rebar_column_1 Plan:placeConcrete_column_1 -defaultConstructionMethods= pumpConcrete -description= the construction plan for the test project -durationUnits=day -project= TestProj:testProject -projectNumber=001
constructionPlan
ConstructionPlan
-activityCategory= ActivityCategory:placeConcColPump -components= Facility:column_1 -constructionPlan= Plan:constructionPlan -cost=140.04 -description= the activity of placing concrete for column 1. -duration=0.17 -earlyFinish=2.32 -earlyStart=2.15 -lateFinish=2.32 -lateStart=2.15 -predecessorActivities= Plan:form_column_1 Plan:rebar_column_1 -projectNumber=001 -quantity=1.975 -quantityFormula=[components quantity] -resourceUse= Plan:place_column_1_material Plan:place_column_1_crew -responsibility= TestProj:concSub -successorActivities= -totalFloat=0 -unitPrice=256.58 -units=cy
placeConcrete_column_1
Activity
Library: Plan
-activity= Plan:placeConcrete_column_1 -conversion=0.087 -cost=34.95 -description= resource Use of concrete pump crew for column 1. -projectNumber=001 -quantity=0.171 -resourceCategories= Resources:crewC20 -resources= -resourceUseCategory= ActivityCategory: placeConcColPumpCrew -unitPrice=203.38 -units=hr
place_column_1_crew
ResourceUse
-activity= Plan:placeConcrete_column_1 -conversion=1.0 -cost=105.09 -description= resource Use of concrete material for column 1. -projectNumber=001 -quantity=1.975 -resourceCategories= Resources:concrete3000 -resources= -resourceUseCategory= ActivityCategory:placeConcMaterial -unitPrice=53.20 -units=cy
place_column_1_material
ResourceUse
j
l
h
k
A Domain Model for Project Management and Construction
Example libraries and GenCOM instances used to represent a construction activity for placing concrete for a column (part three or four)
103
A Domain Model for Project Management and Construction
Library:
Resources
ResourceCategory concrete3000
k g
l i
-description= 3000 psi concrete. -partOf= -resources= -resourceUse= Plan:place_column_1_material -resourceUseCategories= ActivityCategory:placeConcMaterial -subparts= -unitPrice=53.20 -units=cy
ResourceCategory
ResourceCategory
crewC20
equipmentOperator
-description= medium sized concreting crew with pump. -partOf= -resources= -resourceUse= Plan:place_column_1_crew -resourceUseCategories= ActivityCategory:placeConcColPumpCrew -subparts= Resources:crewC20Equipment Resources:crewC20Laborers Resources:equipmentOperator -unitPrice=203.38 -units=hr
-description= equipment operator (med.). -partOf= Resources:crewC20 -resources= -resourceUse= -resourceUseCategories= -subparts= -unitPrice=22.10 -units=hr
ResourceRelationship
ResourceRelationship
crewC20Equipment
crewC20Laborers
-conversion=0.125 -description= converts equipment's units (day) to crew's units (hr). -partOf= Resources:crewC20 -subpartCount=1 -subparts= Resources:concPumpSmall
-conversion=1 -description= adds 7 laborers to the crew C20. -partOf= Resources:crewC20 -subpartCount=7 -subparts= Resources:laborer
ResourceCategory
ResourceCategory
concPumpSmall
laborer
-description= small concrete pump truck. -partOf= Resources:crewC20Equipment -resources= -resourceUse= -resourceUseCategories= -subparts= -unitPrice=489.8 -units=day
-description= building laborer. -partOf= Resources:crewC20Laborers -resources= -resourceUse= -resourceUseCategories= -subparts= -unitPrice=17.15 -units=hr
Figure 5.19:
Example libraries and GenCOM instances used to represent a construction activity for placing concrete for a column (part four of four)
104
Chapter 6 A Project Model—the Core of an Integrated System Chapter Abstract: This chapter distills all the preceding chapters’ results into a prototype integrated system called the Object-model-based Project Information System, or OPIS. OPIS uses a shared object-oriented database as the central unifying core of an integrated project planning system that includes an interface to an intelligent CADD program, a plangeneration expert system, an estimating application, and a scheduling application. This chapter describes the OPIS system, its various applications, and provides an example of integrated CAPM using the system.
6.1.
The Project Model and Integrated Systems
If multiple applications adopt standard data and domain models, they will be able to routinely communicate project information among themselves. However, this capability does not solve questions such as where information will reside, how applications will know where to locate information, how redundant copies of information will be kept consistent, how applications will be connected to each other, and when communication should take place. These issues are addressed by the overall system architecture and control mechanisms. Chapter 3 showed that the basic alternatives are distributed systems, centrally controlled systems, or shared databases. In this dissertation, I have selected a shared database—or shared project model—as the basis of an experimental prototype system. In the future, distributed computing technologies are likely to advance significantly and become the basis for all integrated processing, but these capabilities will form a software layer that is largely transparent to the application developer and user, who can view the integrated system as if all applications shared a single large central database.
105
A Project Model—the Core of an Integrated System
The prototype system designed and implemented as part of this dissertation is called the Object-model-based Project Information System, or OPIS. It contains several CAPM applications that adopt all three levels of standard models: the SOL object-oriented data model, the GenCOM domain model, and a shared database. The next section gives an overview of OPIS and subsequent sections provide more details about its various components.
6.2.
Overview of OPIS System
OPIS is implemented in Objective-C on a NeXT computer. OPIS’s application modules consist of 43 classes (18,700 lines of Objective-C code). Thus the entire system— the SOL database, the GenCOM domain model, and the OPIS application modules— consist of 109 classes (32,800 lines of code). Figure 6.1 shows the prototype’s overall architecture, which consists of the following major components:
SystemLevel Objects
Shared Central Database
Application Modules
Stand-Alone Applications connected through interface module
General Database Browser
System-Level Interfaces, etc.
PlanGeneration Expert System Shared Object Database
Construction Estimating
Construction Scheduling
CAD Interface Module
CAD System
Figure 6.1: Overview of major components of OPIS, a prototype integrated Objectmodel-based Project Information System
106
A Project Model—the Core of an Integrated System
1.
System-Level Components in the integrated system include a small number of toplevel control and shared utility objects. These include, for example, a user-interface panel that allows the user to switch among the integrated system’s different applications.
2.
A Central Object-Oriented Database is the core of the system and is shared by all the integrated applications. This is a SOL database which stores project information using the GenCOM object-oriented standard domain model. The applications use this central database to store all information that may be relevant to other applications: only data that are completely application-specific stay within the application itself.
3.
Application Modules that perform the data input, processing, and reporting reside within the system and use the central database for primary data storage. These application modules consist of application-specific objects and links into the shared database objects. Applications can also use libraries or tool kits of general-purpose objects, such as generic user-interface objects. The specific application modules included in the prototype are a general database browser (for inspecting and editing objects in the database), an expert system that generates construction plans, an estimating system that assigns costs to construction activities to produce project estimates, and a scheduling system that calculates schedule dates for activities.
4.
Stand-Alone Applications can be used in conjunction with the integrated system by creating interface modules. An example of this is the prototype’s is an interface module to an intelligent CADD system that creates project component objects in the database. The following section illustrates how all the applications operate collaboratively on the central database.
This approach can extend to integrate a large number of construction-related applications, for example: construction planning, estimating and bid preparation, risk analysis, time and cost control, document control, contract management, materials management, project accounting and personnel, detailed activity planning, job-site CADD, 3–D construction simulation, legal analysis, construction-methods selection, and so on. The approach can also encompass all phases of the project life cycle from conception and feasibility analysis, through design and construction, and on to facilities management. While all of these phases would not physically share a single central database, they could share a standard domain model for constructed facilities and share much of the actual data for a project; thus the concept of a shared computational project model would remain.
107
A Project Model—the Core of an Integrated System
6.3.
An Example of Integration in OPIS
Figure 6.2 illustrates how OPIS would assist project planning. Typical user interfaces employed by the various applications also appear in the figure. Users work with traditional project management software interfaces and need have no direct interaction with the central database. The sequence of possible operations follows: 1.
CIFECAD, a prototype CADD system [Ito 89] is used to create a 3-D CADD model of the project. The internal representation of the CADD model identifies elements as specific project components rather than as geometric shapes only. CIFECAD is not an integrated application module within the OPIS system, but CADLink, an OPIS interface module, combines the CIFECAD model with general component category information from the central database to create a model of the facility within the shared database.
2.
AutoPlan, an expert system plan-generation application within OPIS, creates a
Shared Object Database
COMPONENT CATEGORIES:
concrete columns
Application Modules
CAD Link
CIFECAD
Example User Interfaces CAD
CAD system
COMPONENT:
column 42
AutoPlan,
interactive dialog
plan generation ACTIVITY CATEGORIES:
form conc. columns
spreadsheet ACTIVITY:
InCost,
form col. 42
estimating
total cost start date
network diagram
InTime, scheduling
Figure 6.2: An example of different application modules’ user interfaces and operations on the shared object-oriented database 108
A Project Model—the Core of an Integrated System
construction plan within the database using knowledge that identifies the activity types required to create each component type (stored in the component category objects), and knowledge that describes what activities must precede or follow each activity type (stored as rules in the AutoPlan application module). 3.
InCost, an integrated estimating application module, assigns costs to the activities to generate an estimate for the project (estimate line items appear as specific types of activities). The user may add quantity take-off and estimated cost values, or may allow the system to calculate costs automatically from the facility model’s quantity data and the activity category’s typical resource productivity and unit-cost data.
4.
Finally, a scheduling application module, InTime, calculates schedule dates for activities. Again, data about specific project activities and general activity categories aid in determining durations, precedence constraints, etc.
Note that the system does not require that applications execute in this sequence. For example, the estimating system could go first. The process of describing estimate line items and linking them to unit-cost data from the activity category objects would lead to the creation of project-specific product, process, and resource objects in the database. Alternatively, the scheduling system could initially help define project objects in the database. Because of the shared database, any operations performed by an application immediately and automatically become available to all other applications. The following sections go into each of the system’s components in greater detail.
6.4.
System-Level Functionality
The OPIS system contains certain system-level elements. The only system-level components visible to the user are a system menu and the System Dock, a user-interface panel that contains one button for each application in the system (see figure 6.3). The user can switch quickly between different applications by selecting the application’s button on the system dock. Other system-level components are application-services objects that the system makes available to individual applications in order to perform various functions that are common to the different applications, such as the following: •
the Library Manager object (described in section 4.4.12.1) that owns and manages the shared database
•
a Name Manager object for accessing unloaded database objects (see section 4.4.13)
109
A Project Model—the Core of an Integrated System
Figure 6.3: The main system menu and the System Dock, a user-interface panel that allows users to switch between different applications.
110
A Project Model—the Core of an Integrated System
•
a Units Converter object for performing units manipulations (e.g., converting from one unit to another)
•
a Class Information Manager that provides information about classes, e.g., their subclasses, which is information that is not normally available (see appendix I)
•
a Formula Parser
•
a class and object Chooser Panel
•
a Dialog Panel
Besides the system-level capabilities provided by OPIS itself, each application must provide certain system-level capabilities. Each application module’s menu contains a “System” sub-menu. This includes options for hiding the entire system (removing all of its windows from the screen except a single icon for returning to the system), and for bringing up the system dock.
6.5.
The Library Browser
The Library Browser application module provides users with direct, low-level access to the database. The Library Browser contains two main user-interface components, a library inspector and an object inspector (both shown in figure 6.4). The library inspector lists the libraries currently loaded in the system, and all the objects within each library. When a user selects an object from the library inspector, it appears in the object inspector. The object inspector lists all the object’s attributes. When a user selects an attribute, the object browser displays the attribute’s type and value, which the user can then edit. If the attribute is a relationship or relationship-set type, menu options allow the user to select a value from a list of objects, or to make the related object the current object in the object browser. One can implement and compile additional custom library or object inspectors, in which case the Library Browser will use them for any objects that the custom inspectors can display and will allow users to switch between the general inspectors and any custom inspectors. No changes are necessary to the Library Browser code to cause it to use custom inspectors. Through custom inspectors, programmers can use the Library Browser application module to quickly implement new application functionality. For example, a programmer could create an object inspector customized for viewing and editing resource111
A Project Model—the Core of an Integrated System
Figure 6.4: The user interface of the Library Browser application module, including the application menu, the Library Inspector, and the Object inspector.
112
A Project Model—the Core of an Integrated System
category objects. This could then become an application for reviewing and entering the resource database for estimating and other purposes. The Library Browser application illustrates the ability for users to directly access the database. This embodies the principles that data should be represented explicitly within the system and that users should have ultimate control over the data. It also illustrates flexible applications, since it provides access to any type of object and is designed to accommodate additional future user-interface components. However, the Library Browser also illustrates how cumbersome it is to deal with the system extensively at a low level. A viable system will require enough applications similar to those described below to ensure that users can conduct virtually all of their system interaction at a fairly high level.
6.6.
The CADLink Application Interface Module
The CADLink application-interface module provides a channel through which a CADD product model from CIFECAD, a stand-alone CADD system, can be translated to the OPIS system. CIFECAD is a package of menus and functions layered on top of AutoCAD to provide a simple prototype “intelligent” CADD system [Ito 89]. CIFECAD allows users to define buildings by selecting columns, beams, slabs, etc., from menus and position them in the 3-D model. The resulting 3-D files contain labeled blocks of data representing building components, rather than just sets of lines. CIFECAD can export this product model to an ASCII file. CADLink works by reading the data from a CIFECAD output file, creating an OPIS database object for each CIFECAD-defined component, adding attributes’ values to the component objects, and finally establishing relationships from the components to their corresponding category objects and to any supporting or supported components. CADLink also creates a Project object (using the name supplied in the CIFECAD file) and a Facility object (named “facility”). Both CIFECAD and CADLink currently support only cast-in-place concrete structural members. CADLink assumes that all the product model classes described in section 5.7 exist and that the following objects have been defined in the system: • • •
roundConcreteColumns rectangularConcreteColumns concreteBeams
113
A Project Model—the Core of an Integrated System
• • • •
concreteWalls concreteDropCaps windowOpenings doorOpenings
Figure 6.5 shows an example CIFECAD screen while figure 6.6 shows a CADLink user interface, which consists of a simple application menu and a transcript window that displays progress messages. CADLink fulfills three major functions. First, it demonstrates one of the many roles that CADD and graphical modeling can play in an integrated CAPM system. Engineering drawings are a standard communication mechanism in the AEC industry, and an integrated CAPM system cannot play a dominant role in the project management process unless it can converse in this medium. CADLink only allows information flow from CIFECAD to OPIS. It is envisioned that CADD interfaces will be provided to all aspects of future integrated CAPM systems, and that they will display more than just product model information. For example, CADD applications could use process data to graphically simulate construction sequences, or use resource data to assist materials layout planning. Second, CADLink illustrates the way that an external, stand-alone program can tie into the overall integrated system through an interface module. While this dissertation focuses predominantly on fully integrated application modules, it is expected that external applications will comprise a large portion of integrated systems (these applications will be designed to facilitate inter-application interaction). Third, the CADLink module provides a quick and effective mechanism for entering product models into the OPIS system. This illustrates the concept that applications must insulate the user from voluminous, low-level data entry and manipulation.
6.7.
The AutoPlan Application Module
The main function of the AutoPlan application module is to create a process model (i.e., a construction plan), which it does using the information contained in the product model and the general product, process, and resource objects. AutoPlan is based on the OARPlan system (section 5.8.2). It draws upon relationships stored in the database and on heuristic algorithms and rules stored in the application module itself; thus it illustrates higher-level, or knowledge-based, processing on the project model. When the user selects “Create Plan” from the menu, the application asks the user to locate the project object for the desired plan. It then creates a construction plan object in the database (an instance of
114
A Project Model—the Core of an Integrated System
Figure 6.5: A sample CIFECAD screen
115
A Project Model—the Core of an Integrated System
Figure 6.6: The user interface for the CADLink application-interface module.
116
A Project Model—the Core of an Integrated System
the ConstructionPlan class with a relationship to the project object). Next, the application initiates a two-phased set of operations to define the plan’s activities. In the first phase of the plan generation, AutoPlan creates the activities needed to construct each component in the facility. The following is a simplified version of the algorithm used: — for each of the facility’s components: — get the component’s component category. — for each of the activity categories that operate on the component category (the user may be required to select from alternative methods to identify the appropriate activity categories): — if the component does not already have an activity that is a member of the activity category, create one.
In the second phase of the plan generation, AutoPlan cycles through each activity created thus far and uses a set of rules to check for required prerequisite activities. This leads AutoPlan to create new activities and establish prerequisite relationships as necessary. AutoPlan currently implements the following heuristics as rules: 1.
Support constraints: If an activity’s component is supported by other components, then the last activities of the supporting components must precede the first activities of the supported components. Rules based on the activity’s actions determine the first and last activities for a component.
2.
Concreting sequences: Concrete placement activities must be preceded by reinforcing and forming activities for the same component.
AutoPlan represents rules in Objective-C code and SOL database calls, but a preferable approach would be to use a high-powered AI shell or environment that could interact with the OPIS system. The AutoPlan interface, shown in figure 6.7, consists of an application menu and a transcript window that displays progress messages and interacts with the user through multiple-choice questions. Although it is quite simple, AutoPlan demonstrates that knowledge-based systems can use OPIS’s integrated framework as easily as traditional applications. It also illustrates how programs can intelligently derive much of the detailed data required to populate a comprehensive project database, thereby reducing the data-entry burden that would otherwise fall to the system users.
117
A Project Model—the Core of an Integrated System
Figure 6.7: The user interface of the AutoPlan plan-generation expert system.
118
A Project Model—the Core of an Integrated System
6.8.
The InCost Application Module
The InCost application module helps the project planner to create project estimates. InCost assumes that a project’s costs stem from its construction activities’ costs, and it therefore uses activities as the basic unit of all estimates. Instead of including a line item for “cladding,” for example, an estimate might include an item for “supply and install cladding.” The estimator should not unduly be constrained by this, since activities are broadly defined and, in future systems, it will be possible to describe a project using different activity sets for different purposes. As discussed in section 5.8.3, however, the current implementations of GenCOM and OPIS do not support multiple parallel project plans. Thus, InCost can only integrate its estimating data with other OPIS capabilities (such as AutoPlan or InTime) if the same set of project activities is used throughout the system. InCost’s main function is to perform the unit-price, unit-conversion, quantity, totalcost, and duration calculations for all activities and to sum them for the entire project. The user can enter most of the data that InCost uses in these calculations, but they will be inherited from general resource and activity category objects if no user-defined values are supplied. These category objects, then, are available as an estimating database for pricing any project. InCost uses a series of procedures that calculate the estimating data for Activity, ActivityCategory, Resource, ResourceCategory, ResourceUse, ResourceUseCategory, and ResourceRelationship objects. Although the exact algorithms for these procedures are complex, the basic steps are as follows: 1. Obtain quantity: — Activity objects return a quantity value based on a user-supplied value or on a quantity-calculation formula inherited from the activity’s category object. — ResourceUse objects’ quantities are calculated from their activity’s quantity and their own conversion factors. 2. Obtain unit price: — If the object has subparts, obtain unit price by summing the subparts’ unit prices (after applying any necessary conversion factors). — Otherwise, if the user has specified a unit price, use that. — Otherwise, if the user has specified a total cost, calculate the unit price from the cost divided by the quantity. — Otherwise, inherit a unit price from the category object. 3. Obtain total cost: — If the object is an Activity or a ResourceUse and if the unit price was not calculated from the cost, then calculate the cost from the unit price multiplied by the quantity.
In addition, the unit prices and costs are tracked separately for labor, equipment, and materials; and all unit prices and costs are tabulated for the entire project. Activities’
119
A Project Model—the Core of an Integrated System
durations are calculated from the quantity of any time-based resources (e.g., crews). These calculations can be performed as a complete recalculation of the entire project, or focus on individual objects as a result of a single attribute value change. InCost’s user interface consists of a main menu and a transcript window that displays progress messages (see figure 6.8). However, a more appropriate interface for this type of application would include inspector panels for efficiently viewing and editing the attributes of the different activity and resource objects, and a configurable spreadsheet-like interface that would display the cost data for the project in a tabular format. The user should also be able to configure the categories in which to calculate subtotals (as an alternative to labor, equipment, and materials). The InCost application module illustrates how more traditional CAPM functionality can operate within the integrated OPIS environment. It also displays extensive use of inherited information to reduce data entry, and stored relationships to combine the attributes of many related objects into one calculation.
6.9.
The InTime Application Module
The InTime application module performs critical path method (CPM) scheduling on project plans and provides the user with a graphical interactive interface for viewing and editing plans. Users can select menu options to either create a new schedule from an existing database plan, or to create a new schedule and plan together. A schedule created from an existing plan reads in all of the plan’s activities and defines corresponding applicationspecific scheduling activity objects. These scheduling activities maintain links to the database activities and store application-specific information such as the coordinates of the box that represents the activity on the graphical network diagram. InCost can then perform CPM scheduling calculations on the plan in response to a user request or a change in any of the activities’ duration or precedence attributes. These calculations determine each activity’s early start and finish dates, late start and finish dates, and floats; these data are written immediately into the project database. Users can also create new project activities from within InCost.
120
A Project Model—the Core of an Integrated System
Figure 6.8: The user interface of the InCost application module.
121
A Project Model—the Core of an Integrated System
InCost’s user interface includes a Plan Inspector that lists all the activities, an Activity Inspector that allows users to view and edit activities’ schedule and precedence attributes, and a graphical network diagram (shown in figure 6.9). The network diagram shows each activity as a labeled box with links between them to represent precedence relationships. Critical activities are white while non-critical activities are gray. Users can scroll and zoom the network diagram, and the activities’ boxes show durations and dates when they are zoomed in. If users double-click on an activity box with the mouse, that activity displays in the Activity Inspector. Users can also move activities in the network by clicking and dragging the boxes on the screen, and can define new precedence relationships by clicking on the tabs on either side of the activity boxes and dragging a line to another activity (the left and right tabs correspond to an activity’s predecessors and successors, respectively). Finally, users can create a new activity by double-clicking in an empty position on the network diagram. Like InCost, the InTime application module illustrates traditional CAPM processing in an integrated framework. It also illustrates graphical interactive user interfaces, which provide users with much more convenient and efficient access to the project model in the database.
6.10.
Reasoning Illustrations
The modeling and integration approach demonstrated by the OPIS system is capable of supporting many different forms of reasoning. Reasoning can be incorporated declaratively (as a static description) or procedurally (as an executable procedure). The reasoning can also be included in the GenCOM domain model, in the project model or database, or in specific application modules. The following are specific examples of different reasoning mechanisms within OPIS: •
Reasoning expressed declaratively in the domain model: Reasoning can be incorporated into the definitions of classes’ attributes. For example, configuring an attribute to have a maximum cardinality will allow checking routines to be triggered and exceptions to be raised if too many values are entered.
•
Reasoning expressed procedurally in the domain model: The domain model’s definitions of volumetric shapes include methods to calculate their volumes from their dimensions using a broadcast message.
122
A Project Model—the Core of an Integrated System
Figure 6.9: The user interface of the InTime application module.
123
A Project Model—the Core of an Integrated System
•
Reasoning expressed declaratively in the project model: Activity quantity formulae can be stored in the database as string-type attribute values of activity objects. The estimating program can later interpret and executed these formulae.
•
Reasoning expressed declaratively as relationships in the project model: One can enter relationships into the database from component categories to the activity categories assumed to be required in order to construct the component. AutoPlan can then use these relationships to establish the activities required for each component.
•
Reasoning expressed declaratively in an application: AutoPlan implements precedent rules. Although these are actually implemented as Objective-C methods that more closely resemble procedural representation than declarative representation, the concept of a set of rules that execute to perform this type of reasoning would more typically be implemented in an expert-system shell that used a declarative-rule representation.
•
Reasoning expressed procedurally in an application: The CPM calculations performed by the InTime application module are traditional procedural calculations.
•
Multiple inheritance: The CylindricalConcreteComponent class inherits from both the ConcreteComponent and the CylindricalVolume classes.
•
Deferred reasoning: Because activities’ quantity calculations can be extensive, they are not automatically re-calculated every time their value is requested. Furthermore, since the quantity value depends upon the value of the quantityFormula attribute, it is difficult to base updates on change-notification links between the activity and the related objects. Thus, the quantity calculations are left to specific applications (i.e., InCost) to perform as necessary.
•
Complex relationships: ResourceRelationship objects (section 5.9) demonstrate how extra objects can add additional information to relationships.
•
Reasoning based on attribute value sources: The InCost estimating data calculations obtain attribute values and calculate new values conditionally upon the source of the data values. For example, if an InCost calculation previously defined an activity quantity value, it will be updated and re-written, but it will be maintained if it was defined by a user.
124
A Project Model—the Core of an Integrated System
6.11.
Results from the Prototype
The OPIS prototype was intended to test and allow experimentation with the theories developed throughout this dissertation. In this case, testing does not mean generating any specific body of data. Rather, the testing is intended to show that these theories can successfully be implemented with no major technological barriers—at least at a proof-ofconcept level—and that the resulting system displays the expected characteristics. To this end, the test was successful since a prototype was created, all major technical difficulties were overcome (either through the application of the theory or through traditional software engineering techniques), and the prototype clearly demonstrates the basic capabilities and potential of the theory described in this dissertation. To summarize, the test demonstrates that the approach is both possible and powerful. In addition, the prototype allowed experimentation with the system. It was used to try out different approaches, to see what worked well and what did not, and to generate new ideas. During this testing and experimentation, the prototype helped prepare plans for the concrete superstructures of several sample projects. Most of these were small structures consisting of a few dozen members, although the larger structure shown in figure 6.5 was also successful. These trials showed that the applications in the system were generally convenient to use, that the resulting plan, estimate, and schedule results were as expected, and that the allowable interaction among the applications was extensive and extremely flexible. The portions of the system that require data to be entered at a low level using the Library Browser (such as entering resource information) were powerful but tedious to use. New applications would correct this problem.
6.12.
Conclusions
This chapter has shown that a series of applications that all adopt standard data and domain models can be made to share a common project model or database. The OPIS system demonstrates this approach, combining a link to a stand-alone CADD program, a plan-generation expert application, an estimating application, and a scheduling application in a tightly-linked integrated system centered around a shared object-oriented database. The OPIS prototype proved that the approach outlined in this dissertation is both possible and powerful.
125
Chapter 7 Benefits, Contributions, and Recommendations Chapter abstract: To conclude this dissertation, this chapter first summarizes the three major technologies for achieving integrated CAPM systems: an object-oriented data model, a standard domain model for representing and communicating project management information, and a common database for information sharing. The next section reviews the technologies’ benefits and lists the research’s contributions. Finally, the chapter discusses the future research topics that, based on this dissertation, hold the promise of important results.
7.1.
Summary
This dissertation centers on the two themes of building models of AEC projects in computers, and of viewing individual computer applications as components of larger integrated systems. The research premise is that integrated CAPM systems can be achieved by creating applications that adopt standard project models (i.e., representations of project information that are uniform across all computer programs). There are three specific elements to these standard models. For each, this dissertation identifies and develops a supporting area of technology: 1.
A Data Model: A data model is a formal methodology for representing information in general. In this dissertation, I propose an object-oriented data model, review the emerging technologies of object-oriented programming and object-oriented databases, and develop an object-oriented data model that could serve as a data representation standard for integrated CAPM programs.
2.
A Domain Model: A domain model or schema uses the data model to express relevant project management and construction concepts. I propose standard domain models as a technology for enabling communication among software programs. I then design a 126
Benefits, Contributions, and Recommendations
domain model—the GenCOM model—based both on the requirements of typical CAPM applications and on the fundamental concepts that make up construction. The domain model is presented as a series of object-oriented class definitions that can be used as the software components for building CAPM programs and as the universal language for communicating AEC data and knowledge among integrated applications. 3.
A Project Model: A project model or database is the collection of actual project data stored using the data and domain models. This dissertation uses a shared project database as the mechanism for sharing data and controlling information flow in an integrated CAPM system. I test this approach by developing a working prototype system called OPIS that combines several project-planning applications around a shared object-oriented project database.
While these technologies—object-oriented data models, data communication through standard domain models, and information sharing through common databases—may be useful individually, they are most promising when blended to form a cohesive approach for developing powerful highly integrated CAPM software systems.
7.2.
Benefits of the Proposed Approach
This section summarizes the advantages and disadvantages of the approach developed in this dissertation. It first looks at the benefits over current technologies and then considers the advantages over alternative new approaches. 7.2.1.
Benefits Over Current Technologies
7.2.1.1.
Benefits for Application Developers
Application developers creating traditional CAPM programs benefit from the objectoriented data model, the standard domain model, and the shared project model proposed in this dissertation. From the object-oriented data model, developers receive all the programming efficiencies normally associated with object-oriented programming, such as high program modularity, inheritance, and the ability to use libraries of pre-programmed software components. With object-oriented systems, developers normally must map the application domain into a series of classes and must fully design each class. However, the standard domain model provides a ready-made class breakdown for all construction data. More importantly, the standard domain model provides the universal vocabulary for
127
Benefits, Contributions, and Recommendations
communicating project management and construction information among applications. Developers also benefit by writing applications as modules that share a common project model or database. In such systems, much of the data required by the application already resides within the integrated system, and elements such as user interfaces are already defined. Furthermore, applications have access to the functionality of other applications, so this functionality need not be re-implemented. Developers of new advanced CAPM applications also enjoy these benefits. They can go on, however, to extend the capabilities of the system beyond traditional uses. For example, they can take advantage of the comprehensive project model to perform complex model-based reasoning about the project, they can use the reasoning and constraint management capabilities of the database to perform broadly-scoped “what-if” simulations, or they can put the inter-application communication to synergistic uses such as making a 3-D CADD program operate as a user interface for accessing project schedule or cost data. 7.2.1.2.
Benefits for Users
The system presented in this dissertation offers many advantages for users, who would typically be members of a project management team. These advantages include common user interfaces across applications, information sharing among programs to reduce data entry, and interaction between applications so that, for example, one application can immediately display the effects of a change in another. Users would also benefit from new applications made possible by the proposed system’s advanced capabilities. These new applications would require little incremental cost or effort for the user, since much of the data would already exist and the interface would already be known. More generally, the user would enjoy the benefits of a more uniform, comprehensive, flexible, and powerful approach to CAPM. Much of the practice of project management involves the communication and transformation of various forms of project information. For example, figure 7.1 shows some of the high-level management functions and information flows from Sanvido’s Integrated Building Process Model [Sanvido 90, p.3-4]. This models the “Plan/Control Facility” function as the process of converting resources into a facility management plan and facility management knowledge under the control of facility planning, resource availability, performance, and optimization information. CAPM is one of the tools that project managers use to assist them in performing these functions. The effect on project management of better integrated CAPM systems will be to improve the quality of the input
128
RESOURCES
NEEDS
ESTABLISH MANAGEMENT TEAM
INTERNAL CAPABILITIES/ RESOURCES
DEVELOP WORK SCOPE AND NEEDS
RESOURCES
2
PLAN/CONTROL FACILITY
FACILITY PLANNING INFORMATION
PROJECT EXECUTION PLAN & PROGRAM
RESOURCE AVAILABILITY
MECHANISM
FUNCTION
CONTROL
OUTPUT
Figure 7.1: A model of the high-level management functions involved in providing and operating a facility, from Sanvido’s Integrated Building Process Model [Sanvido 90].
RESOURCES
FACILITY IDEA
RESOURCE AVAILABILITY
INPUT
LEGEND:
Benefits, Contributions, and Recommendations
129
Benefits, Contributions, and Recommendations
information that project managers depend upon and of the output information that they generate, thereby improving the practice and the result of project management. To summarize, the proposed system leads to improved CAPM and, correspondingly, to improved project management. The major disadvantages of this approach are its complexity and its reliance on accurate input data. One or more system experts could administer the proposed system, allowing typical users to avoid most of the complex system operations. However, users must have a good general understanding of how the system works and of the details of individual applications in order to benefit. This problem is not as severe for stand-alone project management applications since they are not mutually dependent upon each other’s operations. Furthermore, although the proposed system may require less data entry than a typical set of traditional CAPM programs, the entire approach would break down if users allow data entry to fall far behind actual progress or if the data are not accurate. This is particularly problematic since each application operates on a subset of the database; the complete project model is too expansive in breadth and depth to yield a comprehensive view by a single application. Moreover, poor data entered into the system by one application can corrupt the information used by all of the integrated applications. However, these problems are not significantly different from those facing any large integrated database system, and traditional database solutions such as data consistency checks, security access codes, and clear system-use protocols apply to the proposed system as well. 7.2.1.3.
Benefits for Others
Other parties would benefit from the proposed system as well. Field personnel would receive better information and control from project managers. This would help to provide crews with the resources they need to perform their work. Upper management, besides benefiting from the effects of improved project management, would be able to use the system directly for tracking project performance and for strategic planning such as forecasting trends across projects or simulating the performance of prospective jobs. Even the industry as a whole would benefit from improved information flow throughout.
130
Benefits, Contributions, and Recommendations
7.2.2.
Benefits Relative to Alternative Approaches
The technologies proposed in this dissertation are standard object-oriented data models, communication through standard domain models, and information sharing through common databases. Other technological approaches could produce advanced systems with similar advantage to those summarized in the preceding section. This section describes the major advantages and disadvantages of the proposed technologies over alternative technological approaches. 7.2.2.1.
Standard Data Models
Object-oriented programming, object-oriented databases, and object-oriented modeling (described in chapter 4) appear to support much richer data representation and to be more efficient for programming than more traditional programming and database technologies. However, good implementation tools and modeling standards are not yet common and the computational efficiency is not well understood. 7.2.2.2.
Communication through Standard Domain Models
Standards provide an effective and efficient mechanism for allowing applications to communicate with each other (as described in section 3.2 and chapter 5). The major disadvantages are the difficult development and acceptance of standards, lack of compatibility with existing software, and restrictions that standards can place on individual applications’ flexibility and on general technological advancement. However, the alternatives are direct translators, which are only practical for small numbers of applications, and global translators, which also require some form of global domain model and thus exhibit similar disadvantages to the standards approach. The standard domain model described in this dissertation has neither the breadth nor the depth to support large-scale integrated CAPM systems (see recommendations for future work, section 7.4). However, its primary advantage over most other object-oriented domain models is its generality and its foundation in basic construction concepts. 7.2.2.3.
Information Sharing though Common Databases
The use of common databases by multiple integrated applications offers the advantages of good data consistency and immediate automatic integration. The main disadvantages are the operational constraints imposed by tightly coupling applications and by requiring a high
131
Benefits, Contributions, and Recommendations
degree of connectivity. For example, applications must all be physically networked to the shared database, applications can “lock out” their active data and prevent its use by other applications, and changes made by one application can initiate activity by other applications, thereby consuming shared computational resources. Distributed-systems technology, as it evolves, will likely become the preferable basis for integrated CAPM systems. However, it may form a software layer that is largely transparent to application developers and users, who can view the system conceptually as having a single large project database. The prototype system described in chapter 6 demonstrates the capabilities of shared-database integrated systems.
7.3.
Contributions
I consider the following items to be the primary contributions of this dissertation. I believe that they each have the potential to make a useful and significant impact on the field of CAPM, and that they are distinctive from work done elsewhere: 1.
A framework, or overall approach, to CAPM integration through the technology of shared object-oriented models as presented in chapter 3 and illustrated throughout this dissertation.
2.
GenCOM, a general object-oriented domain model or schema for project management and construction, as described in chapter 5.
3.
OPIS, a prototype integrated system, as described in chapter 6, for illustrating and exploring the proposed integration approach. I consider the following items to be contributions of a secondary nature:
1.
The evaluation of probable future CAPM development, as described in chapter 2.
2.
The SOL data model and the analysis of object-oriented data modeling and objectoriented databases, as presented in chapter 4, in order to explore their applicability as the underlying technology for integrated CAPM systems and to identify key issues for their use in this area.
3.
A prototype system to serve as an integrated test bed for other CAPM research.
Through these contributions (summarized in figure 7.2), this research could provide guidance for future CAPM research and development, leading to improved CAPM and, in
132
Objectives
Benefits, Contributions, and Recommendations
CAPM Integration through Standard Models
Contributions
Existing Technology
Data Models
Non-Construction Standards Past Integration
General Approach
Schemas
OODBMS
Shared-Database
PM Applications
OOP
SOL, Data Model Lessons
GenCOM, Core of Standard Schema
OPIS, Proof of Concept
Improved CAPM Modeling and Integration Improved CAPM
Figure 7.2: Summary of dissertation objectives, point-of-departure technologies, and contributions turn, improved project management practice. However, none of these contributions constitutes a final or definitive solution. Additional research and development is required, as described in the following section.
7.4.
Future Work
The work in this dissertation has pointed to several areas of further research and development that are required to fully achieve the goal of model-based integrated CAPM systems, including the following: •
Object-oriented technologies must continue to advance. Object-oriented data modeling, data representation standards, modeling tools, and databases are all vital ingredients for the proposed system. These areas are sufficiently developed to demonstrate clear advantages over alternative approaches, but they are still immature technologies. Developers should use tools that show signs of becoming industry standards, or that offer significant functionality advantages over other approaches. If the OPIS system were re-implemented using currently available tools, for example, the 133
Benefits, Contributions, and Recommendations
C++ programming language and Object Design’s ObjectStore OODBMS would be preferable alternatives to Objective-C and a self-programmed database. Development in these areas is expected to flow from the field of computer science; the area of CAPM has no unique contribution to make to them. •
The domain model for project management and construction requires further development in breadth and depth. There are no significant impediments to this scaleup. In fact, the process should become progressively easier since new portions of the model can draw upon all pre-existing pieces. Additional organization schemes will be required to keep the model manageable as it becomes large. Modeling support tools, such as graphical model editors, would be very helpful for large-scale model development. The proposed form of domain model for CAPM data representation and communication needs further validation for numerous different application types and industry segments. Ties to other data standards efforts such as STEP/PDES must be fully explored. Most importantly, meaningful industry standards cannot come into common use without significant industry-wide involvement and cooperation.
•
The domain model could benefit from research into a more basic set of primitives. For example, the Action class could evolve into a set of fundamental primitive actions, such as grasp, lift, transport, rotate, release, etc. This would increase the ability of the computer to make inferences about the nature of the information represented in the model (see [Schank 77] for related work in the AI field or [Howard 92] in the data modeling area).
•
Exploration of application-connectivity technologies must continue. The shared database approach described in this dissertation is effective and the necessary implementation technology currently exists and will soon be commonplace. However, much more powerful distributed-computing technologies eventually will become the basis for most integrated computing.
•
New applications must be developed to take advantage of the full potential of modelbased integrated CAPM systems. These applications will allow project managers to perform innumerable useful functions and will help to promote acceptance of the central integrated system. Furthermore, research should investigate “universal applications” that have no pre-defined purpose, but which allow the user to easily adapt the project model to new and spontaneous uses.
134
Appendix I SOL Class Documentation This appendix contains the documentation for the classes that make up the SOL database (see chapter 4).
List of Classes Attribute...................................................................................................................... 136 AttributeSet ................................................................................................................ 139 BroadcastObj.............................................................................................................. 144 ClassInfoMgr .............................................................................................................. 147 DoubleAttribute........................................................................................................... 148 IntegerAttribute........................................................................................................... 151 LibraryMgr .................................................................................................................. 154 NameMgr ................................................................................................................... 158 Relationship................................................................................................................ 159 RelationshipSet .......................................................................................................... 162 SingleValueAttribute ................................................................................................... 166 SOLErrors .................................................................................................................. 170 SOLLibrary ................................................................................................................. 171 SOLMetaObject.......................................................................................................... 175 SOLObject.................................................................................................................. 182 StrAttribute ................................................................................................................. 185 SysApp....................................................................................................................... 188 ObjRef Function Library.............................................................................................. 191
135
Appendix I - SOL Class Documentation
Attribute SUPER CLASS
Object
SUB-PROJECT
SOL
CLASS DESCRIPTION Attribute objects represent the attributes of SOLObjects. This class is a superclass of several specific types of attributes. This class defines several constants for use with attributes, as follows: Value-source codes: Gen_Null Gen_Unspecified Gen_Inhereted Gen_Default Gen_UserSpecified Gen_UserSpecified_ValueConfirmed Gen_Calculated Attribute-type codes: ATTRIB_INT ATTRIB_DBL ATTRIB_STR ATTRIB_REL ATTRIB_REL_SET ATTRIB_GEN Inverse-relationship-cardinality codes: ATTRIB_NOINVERSE ATTRIB_SINGLE ATTRIB_SET
INSTANCE VARIABLES NXAtom
attributeName A pointer to the name used to refer to this attribute.
short
minCard The minimum allowable cardinality (number of values) of the attribute.
id short
object The SOL object that this attribute belongs to. type The type of this attribute (see "setType" method for list of alternatives).
METHOD CATEGORIES Instance creation/destruction - free - initObject: Attribute configuration methods - attributeName - minCard: - object - setAttributeName: - setMinCard: - setType: - type Object deletion
136
Appendix I - SOL Class Documentation
- objectDeleted: Archiving methods - readObjData: - writeObjData:
METHODS attributeName - (NXAtom)attributeName Returns the name by which this attribute is referred. free - free Deallocates the object from memory. initObject: - initObject: anObject Initializes instances of this class and assigns the attribute to a specific class. This method should always be called rather than "init" so that the object can be assigned (some of the other configuration methods require that the object be assigned first, and this guarantees it). minCard: - (short)minCard Returns the minimum cardinality (number of values) of the attribute. The default value of 0 indicates no minimum number of values. object - object Returns the object to which this attribute belongs. objectDeleted: - objectDeleted: (objRef)anObjRef Responds to a message that an object is being deleted. Does nothing if the attribute is not a relationship. readObjData: - readObjData: objData Reads attribute data from an ObjData object. setAttributeName: - setAttributeName: (NXAtom)aName Assigns the name by which this attribute is referred. This name should be of type NXAtom, which is a pointer to a unique character string. The unique character string should be set to the attribute's name in the object's "+initialize" method. setMinCard: - setMinCard: (short)aValue Configures the minimum cardinality (number of values) of the attribute. The default value of 0
137
Appendix I - SOL Class Documentation
indicates no minimum number of values. setType: - setType: (short)aValue Configures the type of the attribute. Must be one of ATTRIB_INT, ATTRIB_DBL, ATTRIB_STR, ATTRIB_REL, or ATTRIB_REL_SET (or some other type defined in a subclass). type - (int)type Returns the attribute type (see "setType:" method). writeObjData: - writeObjData: (NXTypedStream *) stream Writes attribute data to a stream in hierarchical data format.
138
Appendix I - SOL Class Documentation
AttributeSet SUPER CLASS
Attribute
SUB-PROJECT
SOL
CLASS DESCRIPTION The metaClass of all attribute sets (attributes with cardinality greater than 1).
INSTANCE VARIABLES int
(* addCheckMethod)(id, id, id, void *) An optional function for checking new values (see the "setAddCheckMethod:" method).
int
(* addConfirmMethod)(id, id, id, void *) An optional function for confirming that a value has been added (see the "setAddConfirmMethod:" method).
SEL
addedBroadcast The selector of a method that will be sent to the object's subscribers to confirm that the attribute's value has changed (see the "setAddedBroadcast:" method).
id
(*
addMethod)(id, id, id, void *) An optional function for adding a new value (see the "setAddMethod:" method).
int
(*
addPerformMethod)(id, id, id, void *) An optional function for adding a new value (see the "setAddPerformMethod:" method).
short
int
duplicates A flag indicating whether or not duplicate values are allowed in the set. The default value is NO. (*
short int
getCheckMethod)(id, id, void*) An optional function for checking or processing before a value is returned (see the "setGetCheckMethod:" method). maxCard The maximum allowable cardinality of the attribute.
(*
removeCheckMethod)(id, id, id, void *) An optional function for checking before a value is "setRemoveCheckMethod:" method).
removed
(see
the
int
(*
removeConfirmMethod)(id, id, id, void *) An optional function for confirming that a value has been removed (see the "setRemoveConfirmMethod:" method).
SEL
removedBroadcast The selector of a method that will be sent to the object's subscribers to confirm that the attribute's value has changed (see the "setRemovedBroadcast:" method).
int
(*
id
valueSet The collection object that contains the set of values.
SEL
willAddBroadcast A method that will be sent to the object's subscribers to check if the attribute's value can be changed (see the "setWillAddBroadcast:" method).
removePerformMethod)(id, id, id, void *) An optional function for removing a value (see the "setRemovePerformMethod:" method).
139
Appendix I - SOL Class Documentation
SEL
willProvideBroadcast A method that will be sent to the object's subscribers to check if the attribute's value can be provided to another object (see the "setWillProvideBroadcast:" method).
SEL
willRemoveBroadcast a method that will be sent to the object's subscribers to check if the attribute's value can be changed (see the "setWillRemoveBroadcast:" method).
METHOD CATEGORIES Instance creation/destruction - free Attribute configuration methods - maxCard - setAddCheckMethod: - setAddConfirmMethod: - setAddedBroadcast: - setAddMethod: - setAddPerformMethod: - setDuplicates: - setGetCheckMethod: - setMaxCard: - setRemoveCheckMethod: - setRemoveConfirmMethod: - setRemovedBroadcast: - setRemovePerformMethod: - setWillAddBroadcast: - setWillProvideBroadcast: - setWillRemoveBroadcast: Value access methods - count Semi-private value access methods - _valueSet Archiving methods - readObjData: - writeObjData:
METHODS count - (unsigned)count Returns the number of values in the attribute set. free - free Deallocates the attribute's value set. maxCard - (short)maxCard Returns the maximum cardinality (number of values) of the attribute. The default value of 0 indicates no maximum number of values.
140
Appendix I - SOL Class Documentation
readObjData: - readObjData: objData Reads attribute data from an ObjData object. setAddCheckMethod: - setAddCheckMethod: (int(*)(id, id, id, void*))func Sets the "addCheckMethod", a function that, if supplied, will be executed from within the "_addTYPEValueCheck:" method to check to see if a new value can be added to the attribute set. This method should perform any checking or processing that must be done before a new value can be added (raising an exception if the value should not be added). If this function returns nil, the "_addTYPEValueCheck" exits after executing the function, otherwise any other processing normally performed by the method is performed before exiting. The function's arguments are the id of the attribute's object, the id of the attribute, the id of the value set, and a pointer to the new value variable (note that this pointer is of type "void*", and passes the variable by reference--e.g., int*, STR*, objRef*). setAddConfirmMethod: - setAddConfirmMethod: (int(*)(id, id, id, void*))func Sets the "addConfirmMethod", a function that, if supplied, will be executed from within the "_addTYPEValueConfirm:" method to confirm that a new value has been added to the attribute set. This method should perform any checking or processing that must be done after a new value can be added. If this function returns nil, the "_addTYPEValueConfirm" exits after executing the function, otherwise any other processing normally performed by the method is performed before exiting. The function's arguments are the id of the attribute's object, the id of the attribute, the id of the value set, and a pointer to the new value variable (note that this pointer is of type "void*", and passes the variable by reference--e.g., int*, STR*, objRef*). setAddedBroadcast: - setAddedBroadcast: (SEL)aMethod Sets the "addedBroadcast" method, a method that will be sent by the "_addTYPEValueConfirm" method to the object's subscribers to confirm that an attribute value has been added. The method should perform any processing that is required in response to the added value. The method should be of the form "CLASS: (objRef)anObjRef addedATTRIBUTE: (dataType)newValue", where dataType is a pointer to the data (e.g., int*, STR, objRef, etc.). setAddMethod: - setAddMethod: (id(*)(id, id, id, void*))func Sets the "addMethod", a function that, if supplied, will be executed in place of the normal "addTYPEValue:" method. The function's arguments are the id of the attribute's object, the id of the attribute, the id of the valueList, and a pointer to the new value variable. (note that this pointer is of type "void*", and pass the variable by reference--e.g., int*, STR*, objRef*). The function should return the attribute's id. setAddPerformMethod: - setAddPerformMethod: (int(*)(id, id, id, void*))func Sets the "addPerformMethod", a function that, if supplied, will be executed from within the "_addTYPEValuePerform:" method to add a new value to the attribute set. If this function returns nil, the "_addTYPEValuePerform" exits after executing the function, otherwise any other processing normally performed by the method is performed before exiting. The function's arguments are the id of the attribute's object, the id of the attribute, the id of the value set, and a pointer to the new value variable (note that this pointer is of type "void*", and passes the variable by reference--e.g., int*, STR*, objRef*).
141
Appendix I - SOL Class Documentation
setDuplicates: - setDuplicates: (short)newValue Configures the attribute set for allowing duplicate values. By default, duplicate values are NOT allowed. setGetCheckMethod: - setGetCheckMethod: (int(*)(id, id, void*))func Sets the "getCheckMethod", a function that, if supplied, will be executed from within the "_getTYPEValueCheck" method before a value is returned. This method should perform any checking or processing that must be done before a value can be returned (raising an exception if the value should not be returned). If this function returns nil, the "_getTYPEValueCheck" exits after executing the function, otherwise any other processing normally performed by the method is performed before exiting. The function's arguments are the id of the attribute's object, the id of the attribute, and a pointer to the attribute value variable (note that this pointer is of type "void*", and passes the variable by reference--e.g., int*, STR*, objRef*--so that the function can directly alter the attribute value. setMaxCard: - setMaxCard: (short)aValue Configures the maximum cardinality (number of values) of the attribute. The default value of 0 indicates no maximum number of values. This MUST be set to 1 if the attribute is single-valued. setRemoveCheckMethod: - setRemoveCheckMethod: (int(*)(id, id, id, void*))func Sets the "removeCheckMethod", a function that, if supplied, will be executed from within the "_removeTYPEValueCheck:" method to check to see if a new value can be removed from the attribute set. This method should perform any checking or processing that must be done before a value can be removed (raising an exception if the value should not be removed). If this function returns nil, the "_removeTYPEValueCheck" exits after executing the function, otherwise any other processing normally performed by the method is performed before exiting. The function's arguments are the id of the attribute's object, the id of the attribute, the id of the value set, and a pointer to the new value variable (note that this pointer is of type "void*", and passes the variable by reference--e.g., int*, STR*, objRef*). setRemoveConfirmMethod: - setRemoveConfirmMethod: (int(*)(id, id, id, void*))func Sets the "removeConfirmMethod", a function that, if supplied, will be executed from within the "_removeTYPEValueConfirm:" method to confirm that a new value has been removed from the attribute set. This method should perform any checking or processing that must be done after a value has been removed. If this function returns nil, the "_removeTYPEValueConfirm" exits after executing the function, otherwise any other processing normally performed by the method is performed before exiting. The function's arguments are the id of the attribute's object, the id of the attribute, the id of the value set, and a pointer to the new value variable (note that this pointer is of type "void*", and passes the variable by reference--e.g., int*, STR*, objRef*). setRemovedBroadcast: - setRemovedBroadcast: (SEL)aMethod Sets the "removedBroadcast" method, a method that will be sent by the "_removeTYPEValueConfirm" method to the object's subscribers to confirm that an attribute value has been removed. The method should perform any processing that is required in response to the removed value. The method should be of the form "CLASS: (objRef)anObjRef removedATTRIBUTE: (dataType)aValue", where dataType is a pointer to the data (e.g., int*, STR, objRef, etc.).
142
Appendix I - SOL Class Documentation
setRemovePerformMethod: - setRemovePerformMethod: (int(*)(id, id, id, void*))func Sets the "removePerformMethod", a function that, if supplied, will be executed from within the "_removeTYPEValuePerform:" method to actually returns an attribute value. This method should perform only the local processing required to remove a value. If this function returns nil, the "_removeTYPEValuePerform" exits after executing the function, otherwise any other processing normally performed by the method is performed before exiting. The function's arguments are the id of the attribute's object, the id of the attribute, and pointers to the original attribute value variable, the actual attribute value variable, and the new value variable. (note that these last three pointers are of type "void*", and pass the variables by reference--e.g., int*, STR*, objRef*--so that the function can directly alter the attributes values. setWillAddBroadcast: - setWillAddBroadcast: (SEL)aMethod Sets the "willAddBroadcast" method, a method that will be sent by the "_addTYPEValueCheck" method to the object's subscribers to check that an attribute value can be added. The method can raise an error to prevent the addition, but any processing that assumes that the addition has been made should be performed in the "addedBroadcast" method. The method should be of the form "CLASS: (objRef)anObjRef willAddATTRIBUTE: (dataType)newValue", where dataType is a pointer to the data (e.g., int*, STR, objRef, etc.). setWillProvideBroadcast: - setWillProvideBroadcast: (SEL)aMethod Sets the "willProvideBroadcast" method, a method that will be sent by the "_getTYPEValueCheck" method to the object's subscribers to check if the attribute's value can be provided to another object. The method can perform any processing that is required before the value can be returned (e.g., "lazy" updating), or can raise an error to prevent the value from being returned. The method should be of the form "CLASS: (objRef)anObjRef willProvideATTRIBUTE: (dataType)aValue", where dataType is a pointer to the data (e.g., int*, STR, objRef, etc.). setWillRemoveBroadcast: - setWillRemoveBroadcast: (SEL)aMethod Sets the "willRemoveBroadcast" method, a method that will be sent by the "_removeTYPEValueCheck" method to the object's subscribers to check that an attribute value can be removed. The method can raise an error to prevent the removal, but any processing that assumes that the removal has been made should be performed in the "removedBroadcast" method. The method should be of the form "CLASS: (objRef)anObjRef willRemoveATTRIBUTE: (dataType)aValue", where dataType is a pointer to the data (e.g., int*, STR, objRef, etc.). writeObjData: - writeObjData: (NXTypedStream *) stream Writes attribute data to a stream in hierarchical data format. _valueSet - _valueSet Returns the object that contains the set of attribute values. Any changes to this set should generally be performed through the attribute methods (e.g., add...). Thus use this method carefully.
143
Appendix I - SOL Class Documentation
BroadcastObj SUPER CLASS
Object
SUB-PROJECT
General
CLASS DESCRIPTION The BroadcastObj class implements a broadcast/subscriber mechanism. The broadcast/subscribe paradigm allows objects to form "indirect" relationships, or relationships that are not precisely defined at the time the objects are defined. A "broadcasting" object is one which knows that there may be other objects that are interested in some of its activities, but it doesn't know which these other objects are. If an object is interested in a broadcasting object's activities, it can register itself as a "subscriber" of the broadcasting object. The broadcasting object keeps a list of the objects that have registered as subscribers. When certain events occur within the broadcasting object's methods, it will send out (or broadcast) a message to all of its subscribers that understand that message. Subscribers can register under a specific name so that other object's can accessing them through the broadcasting object (i.e., objects can access the broadcast object's subscribers that are registered under a given name). Broadcast messages are also sent to self if the broadcast method is implemented. This is particularly useful for subclasses to add functionality to existing superclass methods. This class implements methods for adding, accessing, and removing subscribers and for sending out broadcast messages.
INSTANCE VARIABLES idStackLink * subTop The top of the subscribers linked-list.
METHOD CATEGORIES Instance creation/destruction - free Adding subscribers - addSubscriber: - addSubscriber:named: Accessing subscribers - subscriberAt: - subscriberNamed: Removing subscribers - removeSubscribersNamed: - removeSubscriber: Broadcasting - broadcast: - broadcast:with: - broadcast:with:with: Archiving - read: - write:
144
Appendix I - SOL Class Documentation
METHODS addSubscriber: - addSubscriber: newSubscriber Adds a subscriber without a name (the same as addSubscriber: newSubscriber name: ""). addSubscriber:named: - addSubscriber: newSubscriber named: (const char *)aName Adds the subscriber "newSubscriber" along with a name that can be used for accessing this subscriber from the broadcast object. Currently, if the object is already a subscriber, a duplicate reference will be added. broadcast: - broadcast: (SEL)selector Broadcast a message to all subscribers that implement the method, and to self if it implemented the method. The message name is given by "selector" and should have a single argument which is assigned the sender's id. This message is always sent to self (from a subclass) when some event has happened that subscribers might be interested in. Subscribers can, in turn, respond to the sender by sending a message or by raising an exception, which will halt the broadcasting operation and will be passed on to the method that called this method. broadcast:with: - broadcast: (SEL)selector with: (void *)argument The same as broadcast:, but uses "argument" on as a second argument to the message that is broadcast (the first argument is set to self). "argument" must be a pointer of some type. broadcast:with:with: - broadcast: (SEL)selector with: (void *)argument1 with: (void *)argument2 The same as broadcast:, but uses "argument1" and "argument2" on as a second and third argument to the message that is broadcast (the first argument is set to self). "argument1" and "argument2" must be pointers of some type. free - free Deallocates the object and all of its attributes. read: - read: (NXTypedStream *) stream Reads the object data from the typed stream "stream". removeSubscribersNamed: - removeSubscribersNamed: (const char *)aName Removes all subscribers that were registered with name "aName". removeSubscriber: - removeSubscriber: aSubscriber Removes all instances of the subscriber "aSubscriber" from the set of subscribers for this object.
145
Appendix I - SOL Class Documentation
subscriberAt: - subscriberAt: (int)i Returns the subscriber at position "i". Note that a subscriber is not guaranteed to maintain the same index if other subscribers are added or removed. subscriberNamed: - subscriberNamed: (const char *)aName Returns the first subscriber registered with the name "aName". Returns NULL if no subscriber of that name is found. write: - write: (NXTypedStream *) stream Writes the object data to the typed stream "stream".
146
Appendix I - SOL Class Documentation
ClassInfoMgr SUPER CLASS
Object
SUB-PROJECT
General
CLASS DESCRIPTION A single instance of the ClassInfoMgr class is always available to any application that uses the SOL database through the SysApp object. A ClassInfoMgr object maintains information about classes (or instances) for other objects to access. For example, a start-up routine can make each class store its name in the ClassInfoMgr object as a subclass of the class's superclass. Then any object can find a class's subclasses by getting all of the names stored in the ClassInfoMgr object under that class's subclasses (a class's subclasses are not otherwise available in Objective-C).
INSTANCE VARIABLES NXHashTable * classTable A pointer to a hash table that maps class object id's to lists of information about each class.
METHOD CATEGORIES Instance creation/destruction - init Adding class information - addObject:underName:toClass: Accessing class information - objectListForClass:name: - _classInfoListForClass:
METHODS addObject:underName:toClass: - addObject: anObject underName: (STR)infoName toClass: aClass Adds a pointer to an object to the ClassInfoMgr under some index name for a given class. The object is typically some type of information-storing object, but it is application defined. init - init Initializes instances of this class. objectListForClass:name: - objectListForClass: aClass name: (STR)infoName Returns a list of pointers to objects that have been stored under some index name for a given class. _classInfoListForClass: - _classInfoListForClass: aClass Returns a list of indexed lists for a given class.
147
Appendix I - SOL Class Documentation
DoubleAttribute SUPER CLASS
SingleValueAttribute
SUB-PROJECT
SOL
CLASS DESCRIPTION A double-type (double precision real number) attribute.
INSTANCE VARIABLES double
(* getMethod)(id, id, double *) An optional function that is executed to return an attribute value (see the "setGetMethod:" method).
double
originalValue During a "setDoubleValue:" method, this variable holds the original attribute value until all processing and notification has been completed. Can be used for undoing the operation (note that the value is only valid during a "setDoubleValue:" call).
double
value The value of the double-type attribute.
METHOD CATEGORIES Instance creation/destruction - initObject: Attribute configuration methods - setGetMethod: Value access methods - doubleValue - setDoubleValue: Semi-private value access methods - _doubleValuePtr - _getDoubleValueCheck - _setDoubleValueCheck: - _setDoubleValueConfirm: - _setDoubleValuePerform: Archiving methods - readObjData: - read: - writeObjData: - write:
METHODS doubleValue - (double) doubleValue Returns the attribute value. If there is a "getMethod" override method, it is called and its value is returned. Otherwise, any preliminary processing or checking is done by calling the "_getDoubleValueCheck" method. Finally, the double value of the attribute is returned.
148
Appendix I - SOL Class Documentation
initObject: - initObject: anObject Initializes instances of this class and assigns the attribute to a specific class. This method should always be called rather than "init" so that the object can be assigned (some of the other configuration methods require that the object be assigned first, and this guarantees it). Set the default attribute type to ATTRIB_DBL. readObjData: - readObjData: objData Reads attribute data from an ObjData object. read: - read: (NXTypedStream *) stream Reads the instance data from the typed stream "stream". setDoubleValue: - setDoubleValue: (double)newValue Assigns a new value to the attribute. If there is a "setMethod" override function, it is called and its value is returned. Otherwise, the new value is set by calling the semi-private methods "_setDoubleValueCheck:", "_setDoubleValuePerform:", and "_setDoubleValueConfirm:," respectively. setGetMethod: - setGetMethod: (double (*)(id, id, double*))func Sets the "getMethod", a function that, if supplied, will be executed in place of the normal "doubleValue" method. The function's arguments are the id of the attribute's object, the id of the attribute, and a pointer to the attribute value variable (note that this pointer is of type "void*", and passes the variable by reference--e.g., double*--so that the function can directly alter the attribute's value). The function should return a double value to be returned by calls to the "doubleValue" method. writeObjData: - writeObjData: (NXTypedStream *) stream Writes attribute data to a stream in hierarchical data format. write: - write: (NXTypedStream *) stream Writes the instance data to the typed stream "stream". _doubleValuePtr - (double *)_doubleValuePtr Returns a pointer to the value variable for direct access (e.g., from an overriding "setDoubleValue" method). Should be used carefully. _getDoubleValueCheck - _getDoubleValueCheck Checks that the attribute can provide its value to another object. First calls the "getCheckMethod" function if it exists and returns if the function returns nil. The method then sends the "willProvideBroadcast" method to the object's subscribers. Examples of possible responses include
149
Appendix I - SOL Class Documentation
doing any "lazy" or "as needed" processing that must be performed before the value can be returned, or raising an error to stop the process because of a locking or permission problem. _setDoubleValueCheck: - _setDoubleValueCheck: (double)newValue Checks that the attribute can be set to "newValue". First calls the "setCheckMethod" function if it exists and returns if the function returns nil. The method then assigns the current value to the originalValue variable, checks for null values if the minimum cardinality is 1, checks if the new value is identical to the old value, and sends the "willChangeBroadcast" method to the object's subscribers. _setDoubleValueConfirm: - _setDoubleValueConfirm: (double)newValue Performs processing that must be done as a consequence of the attribute value being set. First calls the "setConfirmMethod" function if it exists and returns if the function returns nil. The method then sets the object's edited value to YES and broadcasts the "changedBroadcast" method to the object's subscribers. _setDoubleValuePerform: - _setDoubleValuePerform: (double)newValue Sets the attribute value to "newValue". First calls the "setPerformMethod" function if it exists and returns if the function returns nil. The method then assigns the new value to the value variable.
150
Appendix I - SOL Class Documentation
IntegerAttribute SUPER CLASS
SingleValueAttribute
SUB-PROJECT
SOL
CLASS DESCRIPTION An integer-type attribute.
INSTANCE VARIABLES int
(*
getMethod)(id, id, int *) An optional function that is executed to return an attribute value (see the "setGetMethod:" method).
int
originalValue During a "setIntValue:" method, this variable holds the original attribute value until all processing and notification has been completed. Can be used for undoing the operation (note that the value is only valid during a "setIntValue:" call).
int
value The value of the integer-type attribute.
METHOD CATEGORIES Instance creation/destruction - initObject: Attribute configuration methods - setGetMethod: Value access methods - intValue - setIntValue: Semi-private value access methods - _getIntValueCheck - _intValuePtr - _setIntValueCheck: - _setIntValueConfirm: - _setIntValuePerform: Archiving methods - readObjData: - read: - writeObjData: - write:
METHODS initObject: - initObject: anObject Initializes instances of this class and assigns the attribute to a specific class. This method should always be called rather than "init" so that the object can be assigned (some of the other configuration methods require that the object be assigned first, and this guarantees it). Set the default attribute type to ATTRIB_INT.
151
Appendix I - SOL Class Documentation
intValue - (int)intValue Returns the attribute value. If there is a "getMethod" override method, it is called and its value is returned. Otherwise, any preliminary processing or checking is done by calling the "_getIntValueCheck" method. Finally, the integer value of the attribute is returned. readObjData: - readObjData: objData Reads attribute data from an ObjData object. read: - read: (NXTypedStream *) stream Reads the instance data from the typed stream "stream". setGetMethod: - setGetMethod: (int(*)(id, id, int*))func Sets the "getMethod", a function that, if supplied, will be executed in place of the normal "intValue" method. The function's arguments are the id of the attribute's object, the id of the attribute, and a pointer to the attribute value variable (note that this pointer is of type "void*", and passes the variable by reference--e.g., int*--so that the function can directly alter the attribute's value). The function should return an integer value to be returned by calls to the "intValue" method. setIntValue: - setIntValue: (int)newValue Assigns a new value to the attribute. If there is a "setMethod" override function, it is called and its value is returned. Otherwise, the new value is set by calling the semi-private methods "_setIntValueCheck:", "_setIntValuePerform:", and "_setIntValueConfirm:," respectively. writeObjData: - writeObjData: (NXTypedStream *) stream Writes attribute data to a stream in hierarchical data format. write: - write: (NXTypedStream *) stream Writes the instance data to the typed stream "stream". _getIntValueCheck - _getIntValueCheck Checks that the attribute can provide its value to another object. First calls the "getCheckMethod" function if it exists and returns if the function returns nil. The method then sends the "willProvideBroadcast" method to the object's subscribers. Examples of possible responses include doing any "lazy" or "as needed" processing that must be performed before the value can be returned, or raising an error to stop the process because of a locking or permission problem. _intValuePtr - (int *)_intValuePtr Returns a pointer to the value variable for direct access (e.g., from an overriding "setIntValue" method). Should be used carefully.
152
Appendix I - SOL Class Documentation
_setIntValueCheck: - _setIntValueCheck: (int)newValue Checks that the attribute can be set to "newValue". First calls the "setCheckMethod" function if it exists and returns if the function returns nil. The method then assigns the current value to the originalValue variable, checks for null values if the minimum cardinality is 1, checks if the new value is identical to the old value, and sends the "willChangeBroadcast" method to the object's subscribers. _setIntValueConfirm: - _setIntValueConfirm: (int)newValue Performs processing that must be done as a consequence of the attribute value being set. First calls the "setConfirmMethod" function if it exists and returns if the function returns nil. The method then sets the object's edited value to YES and broadcasts the "changedBroadcast" method to the object's subscribers. _setIntValuePerform: - _setIntValuePerform: (int)newValue Sets the attribute value to "newValue". First calls the "setPerformMethod" function if it exists and returns if the function returns nil. The method then assigns the new value to the value variable.
153
Appendix I - SOL Class Documentation
LibraryMgr SUPER CLASS
BroadcastObj
SUB-PROJECT
SOL
CLASS DESCRIPTION A single instance of the LibraryMgr class is always available to any application that uses the SOL database through the SysApp object. The library manager maintains ownership of all of the libraries loaded into the system. It also is responsible for creating, loading, saving, and destroying libraries (upon requests from applications). Applications can generally request these operations for a specific library (e.g. open library X), or for a user-specified library (e.g., open a library that the user specifies). The library manager object is a broadcasting object and broadcasts messages about it's actions to its subscribers.
INSTANCE VARIABLES id
libraryList A list (NameList type) of all the libraries currently loaded into the system.
METHOD CATEGORIES Instance creation/destruction - init Creating libraries - createLibraryClass:name: - createUserSpecifiedLibrary - createUserSpecifiedLibraryClass: Opening libraries - importASCIIFilename: - importUserSpecifiedASCII - openLibraryFilename: - openLibraryRef: - openUserSpecifiedLibrary - revertLibraryRef: Accessing libraries - libraryCount - libraryRefAt: - libraryRefNamed: - libraryRef: Saving and closing libraries - closeLibraryRef: - exportASCIIRef: - saveAsLibraryRef: - saveLibraryRef: Target/action methods - importASCII: - newLibrary: - openLibrary: Private library manager methods - _addLibrary: - _defaultNameForClass: - _removeLibrary:
154
Appendix I - SOL Class Documentation
METHODS closeLibraryRef: - closeLibraryRef: (objRef)anObjRef Allows the user to save any modifications before closing. Returns NULL if the user selects cancel from the close panel (this is utilized by terminate). Once a document is closed, another document is assigned as current if one exists, or the scheduler is cleared otherwise. createLibraryClass:name: - (objRef)createLibraryClass: aClass name: (const char *)aName Creates a new library of class "aClass" and name "aName". If either "aClass" or "aName" are NULL, default values are used. The objRef of the new library is returned. Creates a new virtual memory zone for each library. createUserSpecifiedLibrary - (objRef)createUserSpecifiedLibrary Creates a library, getting the class and library name from the user (gets class from user and then calls "createUserSpecifiedLibraryClass:"). The objRef of the new library is returned. createUserSpecifiedLibraryClass: - (objRef)createUserSpecifiedLibraryClass: aClass Creates a library of class "aClass," getting the library name from the user (gets name from user and then calls "createLibraryClass:name:"). If "aClass" is NULL, a default value is used. The objRef of the new library is returned. exportASCIIRef: - exportASCIIRef: (objRef)anObjRef Gets a filename. Does nothing if user selects cancel from save panel. Otherwise saves the library in ASCII format. importASCIIFilename: - (objRef) importASCIIFilename: (const char*)aFilename Loads in a library from the ASCII file "filename". Returns the library's objRef. importASCII: - importASCII: sender Imports a user-specified library. importUserSpecifiedASCII - (objRef) importUserSpecifiedASCII Loads in a library from an ASCII file specified by the user. Returns the library's objRef. init - init Initializes instances of this class.
155
Appendix I - SOL Class Documentation
libraryCount - (unsigned)libraryCount Returns the number of libraries currently loaded in the system. libraryRefAt: - (objRef) libraryRefAt: (unsigned)index Returns the library (objRef-type reference) of the library currently stored and position "index." Note that any changes to the list of loaded libraries can alter libraries' index positions, this method is provided only for iterating through all loaded libraries. libraryRefNamed: - (objRef)libraryRefNamed: (const char *)aName Returns the library named "aName" if it is currently loaded in the system. Otherwise returns NULL. libraryRef: - (objRef)libraryRef: (objRef)anObjRef Returns the library equal to "anObjRef" if it is currently loaded in the system. Otherwise returns NULL. newLibrary: - newLibrary: sender Creates a user-specified library. openLibraryFilename: - (objRef)openLibraryFilename: (const char*)aFilename Loads in a library from the file "filename". Returns the library's objRef. openLibraryRef: - (objRef)openLibraryRef: (objRef)anObjRef Loads in the library referred to by "anObjRef". Currently asks the user for the file containing that library. Offers options if the user can't or doesn't wish to open the library. Returns the library's objRef. openLibrary: - openLibrary: sender Opens a user-specified library. openUserSpecifiedLibrary - (objRef)openUserSpecifiedLibrary Loads in a library specified by the user. Returns the library's objRef. revertLibraryRef: - revertLibraryRef: (objRef)anObjRef Reverts the library referred to by "anObjRef" to its previously stored state.
156
Appendix I - SOL Class Documentation
saveAsLibraryRef: - saveAsLibraryRef: (objRef)anObjRef Saves a library using a new user-specified filename. saveLibraryRef: - saveLibraryRef: (objRef)anObjRef Gets a filename if none exists yet. Do nothing if user selects cancel from save panel or if document not edited. Otherwise saves the library to the file and sets edited to NO. _addLibrary: - _addLibrary: aLibrary Private method that adds a library to the library manager. This method checks to see if a library of same name exists (though this should already have been checked); adds the library manager as a subscriber of the library; broadcasts the message that a library has been added; and finally adds the library to the set of loaded libraries. _defaultNameForClass: - (const char *)_defaultNameForClass: aClass Private method to create a default name for a library of a given class (Note: the name returned should NOT be freed). _removeLibrary: - _removeLibrary: aLibrary Private method that removes a library to the library manager. This method removes the library manager as a subscriber of the library; broadcasts the message that a library will be removed; closes the library, and finally removes the library from the set of loaded libraries.
157
Appendix I - SOL Class Documentation
NameMgr SUPER CLASS
Object
SUB-PROJECT
SOL
CLASS DESCRIPTION A single instance of the NameMgr class is always available to any application that uses the SOL database through the SysApp object. This object is responsible for finding the ID's of objects, given the object's name and library. This may involve loading a library from file, which may require information from the user (this object requests the library from the libraryMgr). Object's may not be able to be found (which can have important consequences in some case, i.e., may not allow other actions to be performed on existing objects since related objects can't be notified).
METHOD CATEGORIES Accessing objects - idForObjRefIfLoaded: - idForObjRef:
METHODS idForObjRefIfLoaded: - idForObjRefIfLoaded: (objRef)anObjRef Similar to "idForObjRef:", but will not try to load a library if it is not already. idForObjRef: - idForObjRef: (objRef)anObjRef Returns the id-type reference of the object referred to by the "anObjRef" objRef-type reference. This may involve loading the appropriate library (and asking the user to locate the library's file). This method is normally called from the "objID()" function.
158
Appendix I - SOL Class Documentation
Relationship SUPER CLASS
SingleValueAttribute
SUB-PROJECT
SOL
CLASS DESCRIPTION A relationship attribute. Values are objRef-type references to other SOL objects.
INSTANCE VARIABLES objRef
(* getMethod)(id, id, objRef*) An optional function that is executed to return an attribute value. "setGetMethod:" method.
See the
short
inverseCard The cardinality of the inverse relationship.
NXAtom
inverseRel The attribute identifier of the inverse relationship (or NULL or no inverse relationship exists).
objRef
originalValue During a "setRelValue:" method, this variable holds the original attribute value until all processing and notification has been completed. Can be used for undoing the operation (note that the value is only valid during a "setRelValue:" call).
objRef
value The attribute value.
METHOD CATEGORIES Instance creation/destruction - initObject: Attribute configuration methods - setGetMethod: - setInverseCard: - setInverseRel: Value access methods - relValue - setRelValue: Semi-private value access methods - _getRelValueCheck - _relValuePtr - _setRelValueCheck: - _setRelValueConfirm: - _setRelValuePerform: Object deletion - objectDeleted: Archiving methods - readObjData: - read: - writeObjData: - write:
159
Appendix I - SOL Class Documentation
METHODS initObject: - initObject: anObject Initializes instances of this class and assigns the attribute to a specific class. This method should always be called rather than "init" so that the object can be assigned (some of the other configuration methods require that the object be assigned first, and this guarantees it). Set the default attribute type to ATTRIB_INT. objectDeleted: - objectDeleted: (objRef)anObjRef Responds to a message that an object is being deleted. If "anObjRef" is the current value of this relationship, then the value of this attribute is set to NULL. readObjData: - readObjData: objData Reads attribute data from an ObjData object. read: - read: (NXTypedStream *) stream Reads the instance data from the typed stream "stream". relValue - (objRef)relValue Returns the attribute value. If there is a "getMethod" override method, it is called and its value is returned. Otherwise, any preliminary processing or checking is done by calling the "_getRelValueCheck" method. Finally, the objRef value of the attribute is returned. setGetMethod: - setGetMethod: (objRef(*)(id, id, objRef*))func Sets the "getMethod", a function that, if supplied, will be executed in place of the normal "relValue" method. The function's arguments are the id of the attribute's object, the id of the attribute, and a pointer to the attribute value variable (note that this pointer is of type "void*", and passes the variable by reference--e.g., objRef*--so that the function can directly alter the attribute's value). The function should return an objRef value to be returned by calls to the "relValue" method. setInverseCard: - setInverseCard: (short)anInverseCard Sets the attribute cardinality of the inverse relationship. setInverseRel: - setInverseRel: (NXAtom)anInverseRel Sets the attribute identifier of the inverse relationship (or NULL or no inverse relationship exists). setRelValue: - setRelValue: (objRef)newObjRef Assigns a new value to the attribute. If there is a "setMethod" override function, it is called and its value is returned. Otherwise, the new value is set by calling the semi-private methods "_setRelValueCheck:", "_setRelValuePerform:", and "_setRelValueConfirm:," respectively.
160
Appendix I - SOL Class Documentation
writeObjData: - writeObjData: (NXTypedStream *) stream Writes attribute data to a stream in hierarchical data format. write: - write: (NXTypedStream *) stream Writes the instance data to the typed stream "stream". _getRelValueCheck - _getRelValueCheck Checks that the attribute can provide its value to another object. First calls the "getCheckMethod" function if it exists and returns if the function returns nil. The method then sends the "willProvideBroadcast" method to the object's subscribers. Examples of possible responses include doing any "lazy" or "as needed" processing that must be performed before the value can be returned, or raising an error to stop the process because of a locking or permission problem. _relValuePtr - (objRef *)_relValuePtr Returns a pointer to the value variable for direct access (e.g., from an overriding "setRelValue" method). Should be used carefully. _setRelValueCheck: - _setRelValueCheck: (objRef)newValue Checks that the attribute can be set to "newValue". First calls the "setCheckMethod" function if it exists and returns if the function returns nil. The method then assigns the current value to the originalValue variable, checks for null values if the minimum cardinality is 1, checks if the new value is identical to the old value, and sends the "willChangeBroadcast" method to the object's subscribers. _setRelValueConfirm: - _setRelValueConfirm: (objRef)newValue Performs processing that must be done as a consequence of the attribute value being set. First calls the "setConfirmMethod" function if it exists and returns if the function returns nil. The method then sets the object's edited value to YES, broadcasts the "changedBroadcast" method to the object's subscribers, and frees the original value (if the value has been altered). _setRelValuePerform: - _setRelValuePerform: (objRef)newValue Sets the attribute value to "newValue". First calls the "setPerformMethod" function if it exists and returns if the function returns nil. The method then assigns the new value to the value variable.
161
Appendix I - SOL Class Documentation
RelationshipSet SUPER CLASS
AttributeSet
SUB-PROJECT
SOL
CLASS DESCRIPTION An relationship-type attribute set. That is, the values are objRef-type references to other SOL objects, and the maximum cardinality of the value is greater than 1.
INSTANCE VARIABLES objRef
(* getMethod)(id, id, objRef *) A function that, if supplied, will be executed instead of the normal "setRelValue:". The function's arguments are the id of the attribute's object, the id of the attribute, and a pointer to the attribute value. The function should return an objRef value that is returned by the "relValue" method.
short
inverseCard The cardinality of the inverse relationship.
NXAtom
inverseRel The attribute identifier of the inverse relationship (or NULL or no inverse relationship exists).
METHOD CATEGORIES Instance creation/destruction - initObject: Attribute configuration methods - setGetMethod: - setInverseCard: - setInverseRel: Value access methods - addRelValue: - indexOfRelValue: - relValueAt: - removeRelValue: - removeValueAt: Semi-private value access methods - _addRelValueCheck: - _addRelValueConfirm: - _addRelValuePerform: - _getRelValueCheck - _removeRelValueCheck: - _removeRelValueConfirm: - _removeRelValuePerform: Object deletion - objectDeleted: Archiving methods - readObjData: - read: - writeObjData: - write:
162
Appendix I - SOL Class Documentation
METHODS addRelValue: - addRelValue: (objRef)newObjRef Adds the value "newValue" to the set of attributes. Raises an exception if the value cannot be added (e.g., if a subscriber prevents it, the value already exists and duplicates are not allowed, if there is a maximum cardinality, etc.) indexOfRelValue: - (int) indexOfRelValue: (objRef)aValue Returns the index of attribute value "aValue". Returns -1 if the set does not contain "aValue". initObject: - initObject: anObject Initializes instances of this class and assigns the attribute to a specific class. This method should always be called rather than "init" so that the object can be assigned (some of the other configuration methods require that the object be assigned first, and this guarantees it). Set the default attribute type to ATTRIB_INT. objectDeleted: - objectDeleted: (objRef)anObjRef Responds to a message that an object is being deleted. If "anObjRef" is a current value of this relationship set, then the value is removed. readObjData: - readObjData: objData Reads attribute data from an ObjData object. read: - read: (NXTypedStream *) stream Reads the instance data from the typed stream "stream". relValueAt: - (objRef) relValueAt: (int)index Returns the objRef of the related object at index position “index.” Note that there are no guarantees that the index positions of values will remain constant if other values are added or removed. removeRelValue: - removeRelValue: (objRef)anObjRef Removes the value "newValue" from the set of attributes. Raises an exception if the value cannot be removed. removeValueAt: - removeValueAt: (int)index Removes the value at index position "index". Note that index positions may not remain constant after values are added or removed. Raises an exception if the value cannot be removed.
163
Appendix I - SOL Class Documentation
setGetMethod: - setGetMethod: (objRef(*)(id, id, objRef*))func Sets the "getMethod", a function that, if supplied, will be executed in place of the normal "intValue" method. The function's arguments are the id of the attribute's object, the id of the attribute, and a pointer to the attribute value. The function should return an integer value to be returned by calls to the "intValue" method. setInverseCard: - setInverseCard: (short)anInverseCard Sets the attribute cardinality of the inverse relationship. setInverseRel: - setInverseRel: (NXAtom)anInverseRel Sets the attribute identifier of the inverse relationship (or NULL or no inverse relationship exists). writeObjData: - writeObjData: (NXTypedStream *) stream Writes attribute data to a stream in hierarchical data format. write: - write: (NXTypedStream *) stream Writes the instance data to the typed stream "stream". _addRelValueCheck: - _addRelValueCheck: (objRef)newValue Checks that the attribute can be set to "newValue". Checks for null values if the minimum cardinality is 1, checks if the new value is identical to the old value (in which case nothing is done), and sends the "willChange" method to the object's subscribers. _addRelValueConfirm: - _addRelValueConfirm: (objRef)newValue Performs processing that must be done as a consequence of the attribute value being set. Specifically, the object's edited value is set to YES, and a "changed" message is broadcast to the object's subscribers. _addRelValuePerform: - _addRelValuePerform: (objRef)newValue Sets the attribute value to "newValue". _getRelValueCheck - _getRelValueCheck Checks that the attribute can provide its value. Sends the "willProvideBroadcast" method to the object's subscribers. Examples of possible responses include doing any processing that must be performed before the value can be returned, or raising an error to stop the process because of a locking or permission problem.
164
Appendix I - SOL Class Documentation
_removeRelValueCheck: - _removeRelValueCheck: (objRef)aValue Checks that the attribute can be set to "newValue". Checks for null values if the minimum cardinality is 1, checks if the new value is identical to the old value (in which case nothing is done), and sends the "willChange" method to the object's subscribers. _removeRelValueConfirm: - _removeRelValueConfirm: (objRef)aValue Performs processing that must be done as a consequence of the attribute value being set. Specifically, the object's edited value is set to YES, and a "changed" message is broadcast to the object's subscribers. _removeRelValuePerform: - _removeRelValuePerform: (objRef)aValue Sets the attribute value to "newValue".
165
Appendix I - SOL Class Documentation
SingleValueAttribute SUPER CLASS
Attribute
SUB-PROJECT
SOL
CLASS DESCRIPTION The class of all single-valued attributes (i.e., maximum attribute cardinality is 1).
INSTANCE VARIABLES SEL
changedBroadcast The selector of the broadcast method that will be sent to the object's subscribers to confirm that the attribute's value has changed (see the "setChangedBroadcast:" method).
int
(*
getCheckMethod)(id, id, void*) An optional function that is executed to check whether the attribute value can be provided to another object (see the "setGetCheckMethod:" method).
int
(*
setCheckMethod)(id, id, void *, void *, void *) An optional function that is executed to check whether the attribute value can be set to a new value (see the "setSetCheckMethod:" method).
int
(*
setConfirmMethod)(id, id, void *, void *, void *) An optional function that is executed to confirm that the attribute value has been set to a new value (see the "setSetConfirmMethod:" method).
id
(*
setMethod)(id, id, void *, void *) An optional function that is executed to assign a new value to an attribute (see the "setSetMethod:" method).
int
(*
setPerformMethod)(id, id, void *, void *, void *) An optional function that is executed to assign a new attribute value (see the "setSetPerformMethod:" method).
int
valueSource An indication of the source of the current value of the attribute. General values are defined in the Attribute class, other values are application specific.
time_t
valueTime The date and time that the attribute value was assigned.
SEL
willChangeBroadcast The selector of the broadcast method that will be sent to the object's subscribers to check whether the attribute's value can be changed (see the "setWillChangeBroadcast:" method).
SEL
willProvideBroadcast The selector of the broadcast method that will be sent to the object's subscribers to check whether the attribute's value can be provided to another object (see the "setWillProvideBroadcast:" method).
METHOD CATEGORIES Instance creation/destruction - initObject: Attribute configuration methods - maxCard - setChangedBroadcast: - setGetCheckMethod: - setMinCard:
166
Appendix I - SOL Class Documentation
- setSetCheckMethod: - setSetConfirmMethod: - setSetMethod: - setSetPerformMethod: - setWillChangeBroadcast: - setWillProvideBroadcast: Value access methods - setValueSource: - valueSource - valueTime Archiving methods - readObjData: - read: - writeObjData: - write:
METHODS initObject: - initObject: anObject Initializes instances of this class and assigns the attribute to a specific class. This method should always be called rather than "init" so that the object can be assigned (some of the other configuration methods require that the object be assigned first, and this guarantees it). Sets the value-source code to Gen_Null. maxCard - (short)maxCard Returns the maximum cardinality (number of values) of the attribute. For single-valued attributes, this is one by definition. readObjData: - readObjData: objData Reads attribute data from an ObjData object. read: - read: (NXTypedStream *) stream Reads the instance data from the typed stream "stream". setChangedBroadcast: - setChangedBroadcast: (SEL)aMethod Sets the "changedBroadcast" method, a method that will be sent by the "_setTYPEValueConfirm" method to the object's subscribers to confirm that the attribute's value has changed. The method should perform any processing that is required in response to the change in value. The method should be of the form "CLASS: (objRef)anObjRef changedATTRIBUTEFrom: (dataType)oldValue to: (dataType)newValue", where dataType is a pointer to the data (e.g., int*, STR, objRef, etc.). setGetCheckMethod: - setGetCheckMethod: (int(*)(id, id, void*))func Sets the "getCheckMethod", a function that, if supplied, will be executed from within the "_getTYPEValueCheck" method before a value is returned. This method should perform any checking or processing that must be done before a value can be returned (raising an exception if the value should not be returned). If this function returns nil, the "_getTYPEValueCheck" exits after
167
Appendix I - SOL Class Documentation
executing the function, otherwise any other processing normally performed by the method is performed before exiting. The function's arguments are the id of the attribute's object, the id of the attribute, and a pointer to the attribute value variable (note that this pointer is of type "void*", and passes the variable by reference--e.g., int*, STR*, objRef*--so that the function can directly alter the attribute value. setMinCard: - setMinCard: (short)aValue Configures the minimum cardinality (number of values) of the attribute. For single-valued attributes, this can only be zero (no minimum) or 1 (non-null). setSetCheckMethod: - setSetCheckMethod: (int(*)(id, id, void*, void*, void *))func Sets the "setCheckMethod", a function that, if supplied, will be executed from within the "_setTYPEValueCheck:" method to check whether the attribute can be set to a new value. This method should perform any checking or processing that must be done before a new value can be assigned (raising an exception if the value should not be assigned). If this function returns nil, the "_setTYPEValueCheck" exits after executing the function, otherwise any other processing normally performed by the method is performed before exiting. The function's arguments are the id of the attribute's object, the id of the attribute, and pointers to the original attribute value variable (not assigned to anything at this point), the actual attribute value variable, and the new value variable. (note that these last three pointers are of type "void*", and pass the variables by reference--e.g., int*, STR*, objRef*--so that the function can directly alter the attributes values. setSetConfirmMethod: - setSetConfirmMethod: (int(*)(id, id, void*, void*, void *))func Sets the "setConfirmMethod", a function that, if supplied, will be executed from within the "_setTYPEValueConfirm:" method to confirm that the attribute has been set to a new value. This method should perform any checking or processing that must be done after a new value can be assigned. If this function returns nil, the "_setTYPEValueConfirm" exits after executing the function, otherwise any other processing normally performed by the method is performed before exiting. The function's arguments are the id of the attribute's object, the id of the attribute, and pointers to the original attribute value variable, the actual attribute value variable, and the new value variable. (note that these last three pointers are of type "void*", and pass the variables by reference-e.g., int*, STR*, objRef*--so that the function can directly alter the attributes values. setSetMethod: - setSetMethod: (id(*)(id, id, void*, void*))func Sets the "setMethod", a function that, if supplied, will be executed in place of the normal "setTYPEValue:" method. The function's arguments are the id of the attribute's object, the id of the attribute, and pointers to the attribute value variable and the new value variable. (note that these two pointers are of type "void*", and pass the variables by reference--e.g., int*, STR*, objRef*--so that the function can directly alter the attribute's values). The function should return the attribute's id. setSetPerformMethod: - setSetPerformMethod: (int(*)(id, id, void*, void*, void *))func Sets the "setPerformMethod", a function that, if supplied, will be executed from within the "_setTYPEValuePerform:" method to actually assign a new attribute value. This method should perform only the local processing required to assign a new value. If this function returns nil, the "_setTYPEValuePerform" exits after executing the function, otherwise any other processing normally performed by the method is performed before exiting. The function's arguments are the id of the attribute's object, the id of the attribute, and pointers to the original attribute value variable, the actual attribute value variable, and the new value variable. (note that these last three pointers are of type "void*", and pass the variables by reference--e.g., int*, STR*, objRef*--so that the function can directly alter the attributes values.
168
Appendix I - SOL Class Documentation
setValueSource: - setValueSource: (int)newSource Assigns an indicator of the source of the current attribute value. Source codes are defined in the Attribute class, or in specific applications. setWillChangeBroadcast: - setWillChangeBroadcast: (SEL)aMethod Sets the "willChangeBroadcast" method, a method that will be sent by the "_setTYPEValueCheck" method to the object's subscribers to check if the attribute's value can be changed. The method can raise an error to prevent the change, but any processing that assumes that the change has been made should be performed in the "changedBroadcast" method. The method should be of the form "CLASS: (objRef)anObjRef willChangedATTRIBUTEFrom: (dataType)oldValue to: (dataType)newValue", where dataType is a pointer to the data (e.g., int*, STR, objRef, etc.). setWillProvideBroadcast: - setWillProvideBroadcast: (SEL)aMethod Sets the "willProvideBroadcast" method, a method that will be sent by the "_getTYPEValueCheck" method to the object's subscribers to check if the attribute's value can be provided to another object. The method can perform any processing that is required before the value can be returned (e.g., "lazy" updating), or can raise an error to prevent the value from being returned. The method should be of the form "CLASS: (objRef)anObjRef willProvideATTRIBUTE: (dataType)aValue", where dataType is a pointer to the data (e.g., int*, STR, objRef, etc.). valueSource - (int)valueSource Returns an indicator of the source of the current attribute value. Source codes are defined in the Attribute class, or in specific applications. valueTime - (time_t)valueTime Returns the time that the current attribute value was assigned. writeObjData: - writeObjData: (NXTypedStream *) stream Writes attribute data to a stream in hierarchical data format. write: - write: (NXTypedStream *) stream Writes the instance data to the typed stream "stream".
169
Appendix I - SOL Class Documentation
SOLErrors SUPER CLASS
Object
SUB-PROJECT
SOL
CLASS DESCRIPTION This Class implements the necessary exception handling definitions and functions for all SOL classes. This class must be compiled and must be sent a "registerErrorReporter" message (typically done from App's "initialize" method).
METHOD CATEGORIES Instance creation/destruction - initialize Error handling methods - registerErrorReporter
METHODS initialize + initialize Initializes the class before it is used for the first time. Registers error reporters. registerErrorReporter + registerErrorReporter Method to register the error reporting function. Typically called from the application's "initialize" method.
170
Appendix I - SOL Class Documentation
SOLLibrary SUPER CLASS
SOLMetaObject
SUB-PROJECT
SOL
CLASS DESCRIPTION The class of all SOL libraries, which are SOL database object's whose primary responsibility is to manage collections of SOLObjects. Every SOLObject must belong to a single SOLLibrary.
ATTRIBUTES edited A boolean value indicating whether or not this library or any of its objects have been altered since it was last saved. Note that the edited attribute is configured differently for SOLLibraries and SOLObjects since we specifically want a different broadcast message for libraries and objects. This is because objects must check the library's messages to see if their library has become un-edited, but we don't want this to cause objects to check all other objects' edited messages. Constraint: If edited set to NO (i.e., the file has been saved), set edited of all of this library's objects to NO. Attribute is a boolean (integer) type. If the value of an object's edited attribute is set to YES, then this value must also be set to YES. If this attribute is set to NO (because the library was saved) then the value of all object's edited attribute must be set to NO. filename The name of the last file that was used to save this library. Library's filenames are normally made to be equal to the library's name, but they don't need to be. A string-type attribute. Broadcasts the message "object:changedFilenameFrom:to:" when the value is changed. libraryName The name of the library. This is part of the library's and all of its objects' objRef identity references, so changes can result in significant propagation to update all references to this library and all of its objects. Attribute is string type. Value must be non-null. If the value is changed, "library:willChangeLibraryNameFrom:to:" and "library:changedLibraryNameFrom:to:" as well as "library:willChangeObjRefFrom:to:" and "library:changedObjRefFrom:to:" messages are broadcast. objects A relationship to the set of objects that belong to this library. Attribute is a relationship set type. Duplicate values are not allowed (so that all object name-library name combinations will be unique), otherwise a "Library_addObjExists" exception is raised. Values are fully dependent upon the object (if a library is deleted, the object must be deleted). If the values are added or removed, the appropriate "library:willAddObject:", "library:addedObject:", "library:willRemoveObject:", or "library:removedObject:" message is broadcast.
171
Appendix I - SOL Class Documentation
METHOD CATEGORIES Instance creation/destruction - close - delete - free - init Accessing library objects - defaultObjectName - objectNamed: Broadcast methods sent by SOLObject objects - objectClosed: - objectDeleted: - object:changedEditedFrom:to: Archiving methods - readObjData: - read: - writeObjData: - write: Templates of methods sent to subscribers - libraryChangedName: - libraryWillFree: - library:addedObject: - library:removedObject: - library:willAddObject: - library:willRemoveObject:
METHODS close - close This method "unloads" the library from memory. It broadcasts a "libraryWillClose:" message to it's subscribers to allow them to block the action, and a "libraryClosed:" message to allow them to clean up their references to the library, e.g., remove id-type references (in response to these messages, the library's objects send out similar messages of their own). The method then frees the library and it's objects. Generally, this method should only be called from the libraryMgr object which will attempt to save the library to disk before closing it. defaultObjectName - (STR)defaultObjectName Returns a default name for a new object. This name is guaranteed not to exist currently in the library. delete - delete This method permanently removes the library. It broadcasts a "libraryWillDelete:" message to it's subscribers to allow them to block the action, and a "libraryDeleted:" message to allow them to remove all references to the library, and delete themselves if they are wholly dependent on it (in response to these messages, the library's objects send out similar messages of their own). The method then frees the library and it's objects. Note that while this method will not remove any versions of the library that have been saved to disk, it will sever all relationship links to this library by objects in other libraries.
172
Appendix I - SOL Class Documentation
free - free Deallocates the memory for the library's objects itself. Generally, this method should not be called directly, the "close" or "delete" methods should be used instead. init - init Initializes instances of this class. Sets the object's objectName to "#lib". libraryChangedName: - libraryChangedName: aLibrary Template for method that subscribers implement if they need to respond to the fact that a library has changed its name. libraryWillFree: - libraryWillFree: aLibrary Template for method that subscribers implement if they need to respond to the fact that a library will free. library:addedObject: - library: (objRef)aLibrary addedObject: (objRef)anObjRef Template for method that subscribers implement if they need to respond to the fact that a library added an object. library:removedObject: - library: (objRef)aLibrary removedObject: (objRef)anObjRef Template for method that subscribers implement if they need to respond to the fact that a library removed an object. library:willAddObject: - library: (objRef)aLibrary willAddObject: (objRef)newObjRef Template for method that subscribers implement if they need to respond to the fact that a library is going to add an object. The method should raise an exception if the subscriber wishes to prevent the addition. Any changes that are required locally as a result should be performed in the "library:addedObject:" method, not here. library:willRemoveObject: - library: (objRef)aLibrary willRemoveObject: (objRef)anObjRef Template for method that subscribers implement if they need to respond to the fact that a library is going to remove an object. The method should raise an exception if the subscriber wishes to prevent the addition. Any changes that are required locally as a result should be performed in the "library:removedObject:" method, not here. objectClosed: - objectClosed: (objRef)anObjRef Does nothing is "anObjRef" is a member of this library, since the necessary actions will be handled later. Otherwise calls the superclass' objectDeleted: method.
173
Appendix I - SOL Class Documentation
objectDeleted: - objectDeleted: (objRef)anObjRef Does nothing is "anObjRef" is a member of this library, since the necessary actions will be handled when the object removes itself from the library's objects attribute. Otherwise calls the superclass' objectDeleted: method. objectNamed: - (objRef)objectNamed: (const char *)aName This method returns the object named "aName", if it exists within the library. NULL is returned if no such object exists. object:changedEditedFrom:to: - object: (objRef)anObjRef changedEditedFrom: (int*)oldValue to: (int*)newValue Implements the constraint that if an object is a member of this library and that object has been edited, then the library has been edited. readObjData: - readObjData: objData Reads subscriber data from an ObjData object. Sets edited to YES. read: - read: (NXTypedStream *) stream Reads the instance data from the typed stream "stream". writeObjData: - writeObjData: (NXTypedStream *) stream Writes instance data to a stream in hierarchical data format. Passes message along to all objects. write: - write: (NXTypedStream *) stream Writes the instance data to the typed stream "stream".
174
Appendix I - SOL Class Documentation
SOLMetaObject SUPER CLASS
BroadcastObj
SUB-PROJECT
SOL
CLASS DESCRIPTION The SOLMetaObject class is a meta-class that provides properties common to both SOLLibraries and SOLObjects (no instances should be created from the SOLMetaObject class directly). This class implements the following properties: 1. provides each SOL object with an objRef-type reference. 2. adds methods for assigning attributes to SOL objects. 3. adds attributes that are common to all SOL objects. 4. adds limited multiple inheritance. 5. provides a broadcast/subscribe mechanism for SOL objects. 6. reacts to general broadcast messages from other objects. Implementing attributes in subclasses: In order to add an attribute (called "anAttribute") to a subclass (named "ASubclass"), the following code should be added to the ASubclass.h file to declare the attribute name as a variable: #ifndef ANATTRIBUTE #define ANATTRIBUTE NXAtom anAttribute; #endif The "+initialize" method should read as follows: + initialize; { [super initialize]; /* Since this method can be called more than once through inheritance...*/ if (self == [ASubclass class] ) { /* Initialize attribute name variables. */ anAttribute = NXUniqueStringNoCopy("anAttribute"); } return self; } The "+configureAttributes:" method should read as follows: + configureAttributes: anInstance { /* Add attributes from superclasses */ [[self superClass] configureAttributes: anInstance]; /* Add attributes for this class. */ if(![anInstance attribute: anAttribute]) [anInstance addAttribute: [self configureAnAttribute: anInstance] as: anAttribute]; return self; }
175
Appendix I - SOL Class Documentation
Furthermore, a "+configureAnAttribute:" method should be added as described in Attribute class. All of this code is added automatically by the ODS system if attributes are specified. Multiple-inheritance: Multiple-inheritance superclasses are added with the "configureSuperClasses" statement. If any superclasses are added in this way, then the attributes defined in those superclasses will be added to instances of this class. Thus multiple-inheritance doesn't affect the normal inheritance from the prime superclass and cannot be used for multiple inheritance of methods or instance variables. If different multiple-inheritance superclasses implement the same attributes, only the first definition will be added to instances of this class. SOL Broadcast/Subscribe: The SOL broadcast/subscriber mechanism builds on the capabilities of this class's superclass, the BroadcastObj class. This additional functionality centers around the use of objRef's as references to subscribers in addition to id's. Only SOL objects can be referenced by objRef's. Thus non-SOL objects can never have objRef-type subscribers (since SOL objects should only know about other SOL objects, not application-specific or non-SOL objects). However, SOL objects can have subscribers that are non-SOL objects (referenced by id) or that are other SOL objects (referenced by objRef).
INSTANCE VARIABLES NXHashTable * attributeTable A hash table used for storing references to the object's attributes. objRefStruct selfRef[1] The object's own objRef reference. refStackLink * subRefTop The top of the "objRef"-type subscribers linked-list. id
superClassList A list of all multiple-inheritance superclass objects for this object.
METHOD CATEGORIES Instance creation/destruction - configureAttributes: - configureSuperClasses - free - init - initialize Attribute access and manipulation methods - addAttribute:as: - attributeAt: - attributeCount - attributeNameAt: - attribute: objRef-type reference methods - objRef General attribute access methods - configureDescription: Adding subscribers - addSubscriberRef: - addSubscriberRef:named: Accessing subscribers - subscriberRefAt: - subscriberRefEqualTo: - subscriberRefNamed:
176
Appendix I - SOL Class Documentation
Removing subscribers - removeSubscriberRefsNamed: - removeSubscriberRef: Broadcasting - broadcast: - broadcast:mode: - broadcast:with: - broadcast:with:mode: - broadcast:with:with: - broadcast:with:with:mode: Broadcast methods sent by SOLObject or SOLLibrary objects - libraryClosed: - libraryDeleted: - library:changedObjRefFrom:to: - objectClosed: - objectDeleted: - object:changedObjRefFrom:to: Archiving methods - readObjData: - read: - writeObjData: - write:
METHODS addAttribute:as: - addAttribute: anAttribute as: (NXAtom)name Adds the attribute "anAttribute" to this object using the attribute name "name". Does nothing if an attribute with that name already exists. addSubscriberRef: - (objRef)addSubscriberRef: (objRef)newSubscriberRef Adds a subscriber of objRef-type without a name (the same as addSubscriberRef: newSubscriberRef name: ""). addSubscriberRef:named: - (objRef)addSubscriberRef: (objRef)newSubscriberRef named: (const char *)aName Adds a subscriber of objRef-type along with a name that can be used for accessing this subscriber from the broadcast object. Currently, if the object is already a subscriber, a duplicate reference will be added. attributeAt: - attributeAt: (int)index Returns the attribute at position "index". Returns NULL if index is beyond the range of attributes.
177
Appendix I - SOL Class Documentation
attributeCount - (int)attributeCount Returns the number of attributes of an object. attributeNameAt: - (NXAtom)attributeNameAt: (int)index Returns the name of the attribute at position "index". attribute: - attribute: (NXAtom)name Return the id of the attribute named "name". broadcast: - broadcast: (SEL)selector The same as "broadcast:mode:" with aMode = BROADCAST_NORMAL. broadcast:mode: - broadcast: (SEL)selector mode: (int)aMode Broadcast a message to all subscribers that implement the method, and to self if it implemented the method. The message name is given by "selector" and should have a single argument which is assigned the sender's id for id-type subscribers and for messages sent to self, and the sender's objRef for objRef-type subscribers. This message is always sent to self (from a subclass) when some event has happened that subscribers might be interested in. Subscribers can, in turn, respond to the sender by sending a message or by raising an exception An exception will halt the broadcasting operation and will be passed on to the method that called this method. Various modes can be used. if "aMode" is NULL or BROADCAST_NORMAL, then normal broadcasting is performed. If "aMode" is BROADCAST_IFLOADED, then the message will only be broadcast to objects that are already loaded into the system (i.e. it will not load libraries in order to broadcast messages to them). broadcast:with: - broadcast: (SEL)selector with: (void *)argument The same as "broadcast:with:mode:" with aMode = BROADCAST_NORMAL. broadcast:with:mode: - broadcast: (SEL)selector with: (void *)argument mode: (int)aMode The same as broadcast:, but uses "argument" on as a second argument to the message that is broadcast (the first argument is set to self or objRef). "argument" must be a pointer of some type. If "aMode" is BROADCAST_IFLOADED, then the message will only be broadcast to objects that are already loaded into the system (i.e. it will not load libraries in order to broadcast messages to them). broadcast:with:with: - broadcast: (SEL)selector with: (void *)argument1 with: (void *)argument2 The same as "broadcast:with:with:mode:" with aMode = BROADCAST_NORMAL.
178
Appendix I - SOL Class Documentation
broadcast:with:with:mode: - broadcast: (SEL)selector with: (void *)argument1 with: (void *)argument2 mode: (int)aMode The same as broadcast:, but uses "argument1" and "argument2" on as a second and third argument to the message that is broadcast (the first argument is set to self or objRef). "argument1" and "argument2" must be pointers of some type. If "aMode" is BROADCAST_IFLOADED, then the message will only be broadcast to objects that are already loaded into the system (i.e. it will not load libraries in order to broadcast messages to them). configureAttributes: + configureAttributes: anInstance Adds the attributes defined for this class to the object "anInstance", which is usually an instance of this class or some subclass, but could be an instance of some other class if multiple inheritance is being used. configureDescription: + configureDescription: anInstance Configures the description attribute (string type) of all SOL objects and libraries. configureSuperClasses - configureSuperClasses Adds and multiple-inheritance superclasses to the object. For this class, this method does nothing since there are no multiple-inheritance superclasses, but is provided so that all subclasses can include a '[super configureSuperClasses]' statement. To add a multiple-inheritance superclass (called "ASuperclass") to a subclass, add the following method: - configureSuperClasses; { [super configureSuperClasses]; [superClassList addObject: [ASuperclass class]]; return self; } This method is added automatically by the ODS system if multiple-inheritance superclasses are specified. free - free Deallocates the object and all of its attributes. Generally, this method should not be called directly, the "close" or "delete" methods should be used instead (see SOLLibrary and SOLObject). init - init Initializes instances of this class. Configures multiple-inheritance superclasses by calling own "configureSuperClasses" method. Configures attributes by calling class's and all superclasses "configAttributes:" method for self. initialize + initialize Initializes the class before it is used for the first time (called automatically by the run-time system). Defines the attribute name variables. Registers information such as "subclasses" with the classInfoMgr.
179
Appendix I - SOL Class Documentation
libraryClosed: - libraryClosed: (objRef)anObjRef Responds to a broadcast message that a library is being closed by checking to see if the library is a subscriber and, if so, removing the id-type reference. libraryDeleted: - libraryDeleted: (objRef)anObjRef Responds to a broadcast message that a library is being deleted by checking to see if the library is a subscriber and, if so, removing it. library:changedObjRefFrom:to: - library: (objRef)currObjRef changedObjRefFrom: (objRef)oldObjRef to: (objRef)newObjRef Responds to a broadcast message that a library's objRef is changing by checking to see if the library is a subscriber (based on the "oldObjRef") and, if so, changing the reference to that subscriber to "newObjRef". objectClosed: - objectClosed: (objRef)anObjRef Responds to a broadcast message that an object is being closed by checking to see if the object is a subscriber and, if so, removing the id-type reference. objectDeleted: - objectDeleted: (objRef)anObjRef Responds to a broadcast message that an object is being deleted by checking to see if the object is a subscriber and, if so, removing it. object:changedObjRefFrom:to: - object: (objRef)currObjRef changedObjRefFrom: (objRef)oldObjRef to: (objRef)newObjRef Responds to a broadcast message that an object's objRef is changing by checking to see if the object is a subscriber (based on the "oldObjRef") and, if so, changing the reference to that subscriber to "newObjRef". objRef - (objRef)objRef Returns the objRef reference of the object. Note that this is not a copy, and should not be altered in any way or freed. readObjData: - readObjData: objData Reads subscriber data and attributes from an ObjData object.
180
Appendix I - SOL Class Documentation
read: - read: (NXTypedStream *) stream Reads the instance data from the typed stream "stream". removeSubscriberRefsNamed: - removeSubscriberRefsNamed: (const char *)aName Removes all subscribers of objRef -type that were registered with name "aName". removeSubscriberRef: - removeSubscriberRef: (objRef)aSubscriberRef Removes all instances of the objRef-type subscriber identified by "aSubscriberRef". subscriberRefAt: - (objRef)subscriberRefAt: (int)i Returns the objRef-type subscriber at position "i". Note that a subscriber is not guaranteed to maintain the same index if other subscribers are added or removed. subscriberRefEqualTo: - (objRef)subscriberRefEqualTo: (objRef)anObjRef Returns a pointer to the objRef of the subscriber whose objRef is equal to "anObjRef". Returns NULL if such a subscriber can't be found. This method solves the problem that even if we know the objRef of a subscriber, this still doesn't give us access to the place where the subscriber's objRef is stored in the subscriber lists. subscriberRefNamed: - (objRef)subscriberRefNamed: (const char *)aName Returns the first objRef-type subscriber registered with the name "aName". Returns NULL if no subscriber of that name is found. writeObjData: - writeObjData: (NXTypedStream *) stream Writes subscriber data and attributes to a stream in hierarchical data format. Note that only objReftype subscribers can be stored in an ASCII format. write: - write: (NXTypedStream *) stream Writes the instance data to the typed stream "stream".
181
Appendix I - SOL Class Documentation
SOLObject SUPER CLASS
SOLMetaObject
SUB-PROJECT
SOL
CLASS DESCRIPTION The meta-class for all SOL database objects (that is, all SOL object classes should be subclasses of this).
ATTRIBUTES edited A boolean value indicating whether or not this object has been altered since it was last saved. Attribute is a boolean (integer) type. If the value is set to YES, then the value of the object's library's edited attribute must also be set to YES. If the library's edited attribute is set to NO (because the library was saved) then the value of this attribute must be set to NO. library A relationship to the library to which this object belongs. Attribute is a relationship type. Value must be non-null. The object fully depends upon the value (if a library is deleted, the object must be deleted). If the value changes, "object:willChangeLibraryFrom:to:" and "object:changedLibraryFrom:to:" as well as "object:willChangeObjRefFrom:to:" and "object:changedObjRefFrom:to:" messages are broadcast. objectName The name of the object. This is part of the object's objRef identity reference, so changes can result in significant propagation to update all references to this object. Attribute is string type. Value must be non-null. If the value is changed, "object:willChangeObjectNameFrom:to:" and "object:changedObjectNameFrom:to:" as well as "object:willChangeObjRefFrom:to:" and "object:changedObjRefFrom:to:" messages are broadcast.
METHOD CATEGORIES Instance creation/destruction - delete Broadcast methods involved by SOLLibrary objects - libraryClosed: - libraryDeleted: - libraryWillClose: - libraryWillDelete: - library:changedEditedFrom:to: - library:changedLibraryNameFrom:to: - library:willChangeLibraryNameFrom:to: Archiving methods - readObjData: - read: - writeObjData: Templates of methods sent to subscribers - object:changedRefTo: - object:willChangeRefTo:
182
Appendix I - SOL Class Documentation
METHODS delete - delete This method permanently removes the object. It broadcasts an "object:willDelete" message to its subscribers to allow them to block the action, and an "object:deleted" message to allow them to remove all references to the object, and delete themselves if they wholly depend on it. The method then removes itself from its library and frees itself. Note that if an object is deleted, but then the library is replaced with a previously stored version that still has the object, all relationship links to the object will no longer exist. libraryClosed: - libraryClosed: (objRef)anObjRef Responds to a "libraryClosed:" message from the object's library by broadcasting an "objectClosed:" message (BROADCAST_IFLOADED mode). libraryDeleted: - libraryDeleted: (objRef)anObjRef Responds to a "libraryDeleted:" message from the object's library by broadcasting an "objectDeleted:" message (BROADCAST_IFLOADED mode). libraryWillClose: - libraryWillClose: (objRef)anObjRef Responds to a "libraryWillClose:" message from the object's library by broadcasting an "objectWillClose:" message (BROADCAST_IFLOADED mode). libraryWillDelete: - libraryWillDelete: (objRef)anObjRef Responds to a "libraryWillDelete:" message from the object's library by broadcasting an "objectWillDelete:" message (BROADCAST_IFLOADED mode). library:changedEditedFrom:to: - library: (objRef)anObjRef changedEditedFrom: (int*)oldValue to: (int*)newValue Implements the constraint that if an object's library becomes unedited (i.e., it has been saved), then the object becomes unedited. library:changedLibraryNameFrom:to: - library: (objRef)anObjRef changedLibraryNameFrom: (STR)oldValue to: (STR)newValue Implements the constraint that if an object's library changes it's name, the object's objRef changes. This method updates the object's selfRef and broadcasts a "object:changeObjRefFrom:to:" message in response to its library's "library:changedLibrarynameFrom:to:" message. library:willChangeLibraryNameFrom:to: - library: (objRef)anObjRef willChangeLibraryNameFrom: (STR)oldValue to: (STR)newValue Implements the constraint that if an object's library changes it's name, the object's objRef changes. This method broadcasts a "object:willChangeObjRefFrom:to:" message in response to its library's "library:willChangeLibraryNameFrom:to:" message.
183
Appendix I - SOL Class Documentation
object:changedRefTo: - object: (objRef)anObjRef changedRefTo: (objRef)newObjRef Template for method that subscribers implement if they need to respond to the fact that an object's objRef reference has changed. This could be a change in object name, library, library name, etc. object:willChangeRefTo: - object: (objRef)anObjRef willChangeRefTo: (objRef)newObjRef Template for method that subscribers implement if they need to respond to the fact that an object's objRef reference is going to change. This could be a change in object name, library, library name, etc. The method should raise an exception if it wishes to prevent the change. Any changes that are required locally as a result should be performed in the "object:changedRefTo:" method, not here. readObjData: - readObjData: objData Reads subscriber data from an ObjData object. read: - read: (NXTypedStream *) stream Reads the instance data from the typed stream "stream". In this case, the only action performed is to make the selfRef's library name refer to the libraryName attribute's value. writeObjData: - writeObjData: (NXTypedStream *) stream Writes subscriber data to a stream in a hierarchical data format.
184
Appendix I - SOL Class Documentation
StrAttribute SUPER CLASS
SingleValueAttribute
SUB-PROJECT
SOL
CLASS DESCRIPTION A string-type attribute.
INSTANCE VARIABLES STR
(*
getMethod)(id, id, STR *) An optional function that is executed to return an attribute value. See the "setGetMethod:" method.
STR
originalValue During a "setStrValue:" method, this variable holds the original attribute value until all processing and notification has been completed. Can be used for undoing the operation (note that the value is only valid during a "setStrValue:" call).
STR
value The value of the string-type attribute.
METHOD CATEGORIES Instance creation/destruction - free - initObject: Attribute configuration methods - setGetMethod: Value access methods - setStrValue: - strValue Semi-private value access methods - _getStrValueCheck - _setStrValueCheck: - _setStrValueConfirm: - _setStrValuePerform: - _strValuePtr Archiving methods - readObjData: - read: - writeObjData: - write:
METHODS free - free Deallocates the attribute's value string.
185
Appendix I - SOL Class Documentation
initObject: - initObject: anObject Initializes instances of this class and assigns the attribute to a specific class. This method should always be called rather than "init" so that the object can be assigned (some of the other configuration methods require that the object be assigned first, and this guarantees it). Set the default attribute type to ATTRIB_INT. readObjData: - readObjData: objData Reads attribute data from an ObjData object. read: - read: (NXTypedStream *) stream Reads the instance data from the typed stream "stream". setGetMethod: - setGetMethod: (STR(*)(id, id, STR*))func Sets the "getMethod", a function that, if supplied, will be executed in place of the normal "strValue" method. The function's arguments are the id of the attribute's object, the id of the attribute, and a pointer to the attribute value variable (note that this pointer is of type "void*", and passes the variable by reference--e.g., STR*--so that the function can directly alter the attribute's value). The function should return a string value to be returned by calls to the "strValue" method. setStrValue: - setStrValue: (STR)newValue Assigns a new value to the attribute. If there is a "setMethod" override function, it is called and its value is returned. Otherwise, the new value is set by calling the semi-private methods "_setStrValueCheck:", "_setStrValuePerform:", and "_setStrValueConfirm:," respectively. strValue - (STR)strValue Returns the attribute value. If there is a "getMethod" override method, it is called and its value is returned. Otherwise, any preliminary processing or checking is done by calling the "_getStrValueCheck" method. Finally, the string value of the attribute is returned. writeObjData: - writeObjData: (NXTypedStream *) stream Writes attribute data to a stream in hierarchical data format. write: - write: (NXTypedStream *) stream Writes the instance data to the typed stream "stream". _getStrValueCheck - _getStrValueCheck Checks that the attribute can provide its value to another object. First calls the "getCheckMethod" function if it exists and returns if the function returns nil. The method then sends the "willProvideBroadcast" method to the object's subscribers. Examples of possible responses include doing any "lazy" or "as needed" processing that must be performed before the value can be returned,
186
Appendix I - SOL Class Documentation
or raising an error to stop the process because of a locking or permission problem. _setStrValueCheck: - _setStrValueCheck: (STR)newValue Checks that the attribute can be set to "newValue". First calls the "setCheckMethod" function if it exists and returns if the function returns nil. The method then assigns the current value to the originalValue variable, checks for null values if the minimum cardinality is 1, checks if the new value is identical to the old value, and sends the "willChangeBroadcast" method to the object's subscribers. _setStrValueConfirm: - _setStrValueConfirm: (STR)newValue Performs processing that must be done as a consequence of the attribute value being set. First calls the "setConfirmMethod" function if it exists and returns if the function returns nil. The method then sets the object's edited value to YES, broadcasts the "changedBroadcast" method to the object's subscribers, and frees the original value (if the value has been altered). _setStrValuePerform: - _setStrValuePerform: (STR)newValue Sets the attribute value to "newValue". First calls the "setPerformMethod" function if it exists and returns if the function returns nil. The method then assigns the new value to the value variable. _strValuePtr - (STR *)_strValuePtr Returns a pointer to the value variable for direct access (e.g., from an overriding "setStrValue" method). Should be used carefully.
187
Appendix I - SOL Class Documentation
SysApp SUPER CLASS
Application
SUB-PROJECT
OL
CLASS DESCRIPTION An instance of SysApp is the application object for any system that uses the SOL database. SysApp inherits all of the functionality of the Application Kit Application class, and adds functionality for managing a series of sub-applications, for providing a system-level menu and system dock (a panel for switching between sub-applications), and makes a number of objects available throughout the system (such as a library manager, a formula parser, etc.).
INSTANCE VARIABLES id
apps[APPCOUNT] An array that holds the AppModule objects for each application module.
id
chooser The system's chooser, a panel that can be used by applications to allow the user to select either a class or an object.
id
classInfoMgr A pointer to a class information manager available to any object in the system.
char
classPath[500] A string containing the browser path used to select a class in the previous chooser operation (so that the next operation can start at the same place).
id
currentApp The current sub-application.
id
dialogPanel A pointer to a dialog panel available to any object in the system.
id
formulaParser A pointer to a formula parser available to any object in the system.
id
libraryMgr A pointer to a library manager available to any object in the system.
id
nameMgr A pointer to a name manager available to any object in the system.
char
objectPath[500] A string containing the browser path used to select an object in the previous chooser operation (so that the next operation can start at the same place).
id
sysMenu The main system menu.
id
systemDock The system dock panel.
id
unitsConverter A pointer to a units converter available to any object in the system.
METHOD CATEGORIES Instance creation/destruction - new - becomeCurrentApp:
188
Appendix I - SOL Class Documentation
- relinquishCurrentApp - setApp: - setCurrentApp: - systemDock: Accessing application components - chooserClassPath - chooserObjectPath - classInfoMgr - dialogPanel - formulaParser - libraryMgr - nameMgr - unitsConverter - importASCII: - newLibrary: - openLibrary: Configure objects menu - updateObjectMenuItem:
METHODS becomeCurrentApp: - becomeCurrentApp: sender Makes SysApp the current application. chooserClassPath - (char *)chooserClassPath Returns the path used to select a class in the last class selection chooser operation. chooserObjectPath - (char *)chooserObjectPath Returns the path used to select a class in the last object selection chooser operation. classInfoMgr - classInfoMgr This method returns the class information manager for the system. dialogPanel - dialogPanel This method returns the dialog panel for the application. A dialog panel can be configured for different dialog messages to the user. This method enables all methods within an application to share a single dialog panel rather than creating an new one for each use. See the DialogPanel class. formulaParser - formulaParser This method returns a formulaParser object. importASCII: - importASCII: sender Creates a user-specified library.
189
Appendix I - SOL Class Documentation
libraryMgr - libraryMgr This method returns the system's library manager object. nameMgr - nameMgr This method returns the current library index manager object. new + new Initializes this class before it responds to any messages. This also sends a message to every class in the system so that they can all be initialized before any processing is done. initializing is used for attribute name variables, classInfoMgr, registering error reporters, etc. newLibrary: - newLibrary: sender Creates a user-specified library. openLibrary: - openLibrary: sender Opens a user-specified library. relinquishCurrentApp - relinquishCurrentApp This message is sent to the current application module just before some other module is made the current one. setApp: - setApp: sender Instructs SysApp to set the current application based on the tag id of the sender (which is the system dock). setCurrentApp: - setCurrentApp: anApp Sets the current application module to "anApp". systemDock: - systemDock: sender Brings the system dock to the front of the screen. unitsConverter - unitsConverter This method returns a unitsConverter object.
190
Appendix I - SOL Class Documentation
ObjRef Function Library DESCRIPTION The ObjRef Function Library contains many C functions for working with objRef’s (SOL’s persistant object identifiers).
DECLARATIONS typedef struct objRefStruct { id id; STR objName; STR libName; } objRefStruct; typedef objRefStruct *objRef; typedef objRef * objRefP;
FUNCTIONS equal extern BOOL equal(objRef A, objRef B); Compares two object references, Returns YES if they refer to the same object. freeObjRef freeObjRefZone extern void freeObjRef(objRef anObjRef); extern void freeObjRefZone(objRef anObjRef, NXZone *aZone); Frees an objRef. Note that this doens't free the object being refered to by the objRef. Also note that all elements of the anObjRef must be initialized (even if its just to NULL) so that this function won't attempt to free un-malloc'ed memory. initObjRef extern void initObjRef(objRef anObjRef); Initializes the values of the objRef pointer to NULL. isLibrary extern BOOL isLibrary(objRef anObjRef); Returns YES if the object reference refers to a library. Returns NO otherwise. libName extern const char *libName(objRef anObjRef); Returns the name of an object's library. objID objIDIfLoaded extern id objID(objRef anObjRef); extern id objIDIfLoaded(objRef anObjRef); Returns the id of an object. If the objRef doesn't contain an id, then this function requests one from
191
Appendix I - SOL Class Documentation
the name manager. objIDIfLoaded is the same except that no value is returned if the library is not currently loaded into the system. objName extern const char *objName(objRef anObjRef); Returns a pointer to the name of an object (note that this is not a copy). objRefCopy objRefCopyZone extern objRef objRefCopy(objRef anObjRef); extern objRef objRefCopyZone(objRef anObjRef, NXZone *zone); Returns a pointer to a copy of anObjRef (i.e., a new objRef that referes to the same object). Note that the receiver is responsible for freeing the copy when it is no longer needed. objRefToStr objRefToStrZone extern STR objRefToStr(objRef anObjRef); extern STR objRefToStrZone(objRef anObjRef, NXZone *zone); Converts an objRef into a string of the form "libraryName: objectName". Note that the string must be freed when it is no longer needed. If anObjRef is not valid, returns a string that reads "***unacceptable object***". readObjRef readObjRefZone extern objRef readObjRef(NXTypedStream *stream); extern objRef readObjRefZone(NXTypedStream *stream, NXZone *aZone); Reads an objRef from a typed stream. Used with writeObjRef. strToObjRef strToObjRefZone extern objRef strToObjRef(STR aStr, STR defaultLibName); extern objRef strToObjRefZone(STR aStr, STR defaultLibName, NXZone *zone); Parses a string of the form "libraryName objectName" and returns the corresponding objRef. The library and object names can be separated by any of {space, comma, colon, semi-colon, dash, slash, back-slash or period}. The library name can be left out if the optional default library is supplied. Note that the objRef must be freed when it is no longer needed. writeObjRef extern void writeObjRef(NXTypedStream *stream, objRef aRef); Writes an objRef to a typed stream. Used with readObjRef.
192
Appendix II GenCOM Class Documentation This appendix contains the documentation for the classes that make up the GenCOM domain model for project management and construction (see chapter 5).
List of Classes Action ......................................................................................................................... 194 Activity ....................................................................................................................... 195 ActivityCategory ......................................................................................................... 198 Company.................................................................................................................... 200 Component................................................................................................................. 201 ComponentCategory................................................................................................... 203 ConcreteComponent................................................................................................... 204 ConstructionMethod.................................................................................................... 206 ConstructionPlan ........................................................................................................ 207 Contract...................................................................................................................... 208 CrewResource ............................................................................................................ 209 CrewResourceCategory .............................................................................................. 210 CylindricalConcreteComponent .................................................................................. 211 CylindricalVolume....................................................................................................... 212 EquipmentResource ................................................................................................... 213 EquipmentResourceCategory ..................................................................................... 214 Facility........................................................................................................................ 215 LaborResource ........................................................................................................... 216 LaborResourceCategory ............................................................................................. 217 MaterialResource........................................................................................................ 218 MaterialResourceCategory ......................................................................................... 219 Person........................................................................................................................ 220 Project........................................................................................................................ 221 ProjectParticipant ....................................................................................................... 222 ProjectSpecificObject ................................................................................................. 223 RectangularConcreteAddOn ....................................................................................... 224 RectangularConcreteComponent ................................................................................ 225 RectangularVoid ......................................................................................................... 226 RectangularVolume .................................................................................................... 227 Resource .................................................................................................................... 228 ResourceCategory ...................................................................................................... 229 ResourceRelationship................................................................................................. 230 ResourceUse .............................................................................................................. 231 ResourceUseCategory................................................................................................ 233 SOLCategory.............................................................................................................. 234 Volume....................................................................................................................... 235
193
Appendix II - GenCOM Class Documentation
Action SUPER CLASS
SOLObject
SUB-PROJECT
ConstrObjs
CLASS DESCRIPTION Actions represent "transformations" that must be applied to the physical project components in order to complete the project, e.g., "install" window. Actions are purely conceptual, they do not represent construction effort (construction effort is represented by activities which are defined as the application of some action to some component using some method and set of resources).
ATTRIBUTES activityCategories A relationship to the set of objects that represent the activities types that can be used to achieve this action for different component types. A relationship-set attribute. Each value must be a kind of ActivityCategory.
194
Appendix II - GenCOM Class Documentation
Activity SUPER CLASS
ProjectSpecificObject
SUB-PROJECT
ConstrObjs
CLASS DESCRIPTION Activities are the basic unit of representation for construction effort and are the central objects in the process model. An activity is defined as "the application of some action to some component using some method and set of resources."
ATTRIBUTES activityCategory A relationship to the object that represents the generic type of activity that characterizes this activity. When the activity category is set, any existing resourceUse objects are destroyed and new resoucesUse objects are created based on the activity category's resouceUseCategory objects. This is achieved through a "set-perform" override function. A relationship attribute. Max. cardinality 1. Value is kind of activityCategory. Object is a member of the value (a category). components A relationship to the set of individual components that are acted on by this activity. A relationship-set attribute. Values must be kinds of Components. constructionPlan A relationship to the project's construction plan (of which this activity is a part). A relationship attribute. Max. cardinality 1. Value is kind of ConstructionPlan. cost The total cost for the activity in dollars. Broadcasts the message "activity:changedCostFrom:to:" when the value is changed. A real-number attribute. duration The duration required to complete this activity. An integer attribute. Max. card. 1. earlyFinish The earliest possible time that this activity can finish, given the logic and durations of itself and its predecessor activities. An integer attribute. Max. card. 1. earlyStart The earliest possible time that this activity can start, given the logic and durations of its predecessor activities. An integer attribute. Max. card. 1.
195
Appendix II - GenCOM Class Documentation
lateFinish The latest possible time that this activity can finish, given the logic and durations of its successor activities. An integer attribute. Max. card. 1. lateStart The latest possible time that this activity can start, given the logic and durations of itself and its successor activities. An integer attribute. Max. card. 1. predecessorActivities Activities that must be completed before this activity can be performed. Broadcasts the messages "activity:addedPredecessorActivity:" and "activity:removedPredecessorActivity:." A relationship-set attribute. Values are kinds of Activities. quantity A measure of the quantity of the activity in the units specified by the "units" attribute. Broadcasts the message "activity:changedQuantityFrom:to:" when the value is changed. A real-number attribute. quantityFormula A formula used for calculating the quantity of this activity. This formula is not automatically triggered, it must be activated by sending the object a "calculateQuantity" message. If no other value is supplied, a default value is inherited from the activity's activityCategory (this is implemented as a "get check" override function). A "set confirm" override function recalculates the quantity when the formula is changed, but this does not guarantee that the quantity value will always be current since it is not recalculated if the activity category or other attributes change. An application must send the object a "calculateQuantity" message! A string attribute. Max. card. 1. Value must be a formula as defined in the FormulaParser class. resourceUse A relationship to the uses of resources for this activity. The message "activity:addedResourceUse:" is broadcast when values are added and "activity:removedResourceUse:" when a value is removed. A relationship attribute. Value is kind of ResourceUse. The value is fully dependent upon this object. responsibility A relationship to the object that represents the person or company that is responsible for performing this activity. A relationship attribute. Max. cardinality 1. Value is kind of ProjectParticipant. successorActivities Activities that cannot be started before this activity has been completed. A relationship-set attribute. Values are kinds of Activities. totalFloat The duration that the activity's finish can be delayed past the early finish date before the total project duration is affected. An integer attribute. Max. card. 1.
196
Appendix II - GenCOM Class Documentation
unitPrice The overall unit price for the activity given in dollars per unit specified by the "units" attribute. If no value is otherwise supplied, a value is inherited from the activity's activityCategory (this is implemented as a "get-check" override method). Broadcasts the message "activity:changedUnitPriceFrom:to:" when the value is changed. A real-number attribute. Max. card. 1. units Identifies the units used for measuring the quantity and unit price of this activity. If no value is otherwise supplied, a value is inherited from the activity's activityCategory (this is implemented as a "get check" override method). Broadcasts the message "activity:changedUnitsFrom:to:" when the value is changed. A string attribute. Max. card. 1. Value should be one of: m, m2, m3, hr, ft, sf, cf, yd, sy, cy, etc.
METHOD CATEGORIES Quantity calculation - calculateQuantity
METHODS calculateQuantity - calculateQuantity If the quantity is null or previously calculated and if a quantity formula exists, then this method calculates the quantity by sending the quantity formula to the formula parser.
197
Appendix II - GenCOM Class Documentation
ActivityCategory SUPER CLASS
SOLCategory
SUB-PROJECT
ConstrObjs
CLASS DESCRIPTION An ActivityCategory represents a category of construction activities that can be used in completing a project. Each activity category corresponds to the application of a specific action to a specific component type using a specific method and set of resources. Members of the activity category are the specific activities that make up project construction plans.
ATTRIBUTES action A relationship to the action that is achieved by this type of activity. A relationship attribute. The value must be a kind of Action. activities A relationship to the set of individual activities that are members of this category of activities. A relationship-set attribute. Values must be kinds of Activities. Values are members of the object (a category). componentCategories A relationship to the component type that is acted on by this type of activity. A relationship attribute. Max. card. 1. The value must be a kind of ComponentType. method A relationship to the method that is used by this type of activity. A relationship attribute. The value must be a kind of Method. partOf A relationship to the composite object that this object is a part of (i.e., the parent object in an aggregation hierarchy). Currently, multiple inheritance is allowed. A relationship-set attribute. The value must be a kind of ActivityCategory. The object is a part of the value (i.e. a parent in an aggregation hierarchy). quantityFormula A default value for the formula used for calculating the quantity of an activity of this type. A string attribute. Max. card. 1. Value must be a formula as defined in the FormulaParser class. resourceUse A relationship to the resource use categories for this activity. Broadcasts the messages "activityCategory:addedResourceUse:" and "activityCategory:removedResourceUse:." A relationship attribute. Value is kind of ResourceUse.
198
Appendix II - GenCOM Class Documentation
subCategories A relationship to the set of sub-category objects (the children objects in a specialization hierarchy) that make up this partially defined activityCategory (i.e., this object doesn't refer to a specific method). These related objects are specific alternative methods of performing the activity represented by this superCategory. A relationship-set attribute. The values must be kinds of ResourceCategory. The values are part of the object. An ActivityCategory should not have both subparts and subCategories. An ActivityCategory should not have a method if it has subCategories. subparts A relationship to the set of objects that make up this composite (i.e., the children objects in an aggregation hierarchy). A relationship-set attribute. The values must be kinds of ActivityCategory. The values are part of the object. An ActivityCategory should not have both subparts and subCategories. superCategories A relationship to the set of partially defined ActivityCategory objects (i.e., they don't refer to a specific method) that is a generalization super-category of this activityCategory object. This object is a specific alternative method of performing the activities represented by the related superCategories. A relationship-set attribute. The value must be a kind of ActivityCategory. The object is a part of the value (i.e. a parent in an aggregation hierarchy). unitPrice The default unit cost for this type of activity given in the units specified in the units attribute. A double attribute. Max. card. 1. units Value should be one of: m, m2, m3, hr, ft, sf, cf, yd, sy, cy, etc. A string attribute. Max. card. 1.
199
Appendix II - GenCOM Class Documentation
Company SUPER CLASS
SOLObject
SUB-PROJECT
ConstrObjs
CLASS DESCRIPTION A representation of any corporation or organization that may be involved in a project.
ATTRIBUTES address The address of the company. A string attribute. fax The fax number of the company. A string attribute. fullName The full name of the company. A string attribute. personnel A relationship to individual employees of the company (typically only contact people, etc.). A relationship-set attribute. Values must be a kind of Person. phone The phone number of the company. A string attribute. projects A relationship to all of the projects that the company is or has participated in any capacity (e.g., owner, designers, contractors, etc.). See "ProjectParticipants" class. A relationship-set attribute. Values must be a kind of ProjectParticipant.
200
Appendix II - GenCOM Class Documentation
Component SUPER CLASS
ProjectSpecificObject
SUB-PROJECT
ProjObjs
CLASS DESCRIPTION Instances of the Component class represent physical elements of the facility to be constructed.
ATTRIBUTES activities A relationship to the set of activities that operate on this component. Broadcasts "component:willAddActivity:," "component:addedActivity:," "component:willRemoveActivity:," and "component:removedActivity:" messages. A relationship-set attribute. Values must be kinds of Activity. componentCategory A relationship to the generic type of component that characterizes this component. A relationship attribute. Max. cardinality 1. Value is kind of ComponentType. Object is a member of the value (a category). count The number of units in this component (e.g., number of flag poles if all are represented as one component). Broadcasts the messages: "component:willProvideCount:," "component:willChangeCountFrom:to:," and "component:changedCountFrom:to:." A real-number attribute. Max. Card. 1. Default value of 1.0 (implemented as a "get-check" override function that sets the value source to Gen_Default). facility A relationship to the facility of which this component is a part. A relationship attribute. Max. cardinality 1. Value is kind of Facility. The object is part of the value. location The location of the component (relative to the project coordinates if appropriate). This should be a relationship to a location object, so that different forms of location representation can be used, but at present location is not used by the system, and this attribute is just a text description of the component's location. A string attribute. Max. card. 1. quantity The quantity of the component (given in the units specified by the units attribute). Note that a standard quantitative descriptor should be defined for each type of component (e.g., concrete components quantified in cubic yards of concrete). An real-number attribute. Max. card. 1.
201
Appendix II - GenCOM Class Documentation
quantityUnits The units used for measuring the component quantity. A string attribute. Max. card. 1. supportedComponents A relationship to any components that are supported by this component. A relationship-set attribute. Values must be kinds of Components. supportingComponents A relationship to any components that support this component. A relationship-set attribute. Values must be kinds of Components.
202
Appendix II - GenCOM Class Documentation
ComponentCategory SUPER CLASS
SOLCategory
SUB-PROJECT
ConstrObjs
CLASS DESCRIPTION A ComponentCategory represents a category of physical facility components that may be involved in projects. Members of the component category are the specific components that make up project facilities.
ATTRIBUTES activityCategories A relationship to the set of activity categories that act on this type of component. In order for this component to be constructed, ALL of the activity categories must be performed. A relationship-set attribute. The value must be a kind of ActivityCategory. components A relationship to the set of individual components that are members of this category of components. A relationship-set attribute. Values must be kinds of Components. Values are members of the category object.
203
Appendix II - GenCOM Class Documentation
ConcreteComponent SUPER CLASS
Component
SUB-PROJECT
ProjObjs
CLASS DESCRIPTION The class of cast-in-place concrete components.
ATTRIBUTES addOns A relationship to the set of components that represent sub-components that should be considered to be a part of this component (e.g., column drop-caps are considered to be add-ons to the slab). Broadcasts "concreteComponent:willAddAddOn:," "concreteComponent:addedAddOn:," "concreteComponent:willRemoveAddOn:," and "concreteComponent:removedAddOn:" messages. A relationship-set attribute. Values must be kinds of Volume. concreteStrength The concrete strength given in psi. A real-number attribute. Max. card. 1. reinforcementRatio The reinforcement ratio of the component. A real-number attribute. Max. card. 1. voids A relationship to the set of components that represent block-outs or voids (e.g., doors, windows, etc.) in the concrete component. Broadcasts "concreteComponent:willAddVoid:," "concreteComponent:addedVoid:," "concreteComponent:willRemoveVoid:," and "concreteComponent:removedVoid:" messages. A relationship-set attribute. Values must be kinds of Volume.
METHOD CATEGORIES Methods broadcast from self or from voids and add ons - concreteComponent:addedAddOn: - concreteComponent:addedVoid: - concreteComponent:removedAddOn: - concreteComponent:removedVoid: - volume:changedVolumeFrom:to: Quantity calculation - calculateQuantity
METHODS calculateQuantity - calculateQuantity Calculates the quantity of the component based on the volume and the volume of voids and add-ons.
204
Appendix II - GenCOM Class Documentation
This method is called from the broadcast methods sent by self or sub-parts in response to volume changes. Quantity is given in cubic yards (cy). Converts units if necessary. concreteComponent:addedAddOn: - concreteComponent: anObj addedAddOn: (objRef) anObjRef Responds to a message that a component has added an add-on by checking to see if the message came from self and, if so, recalculating the quantity. concreteComponent:addedVoid: - concreteComponent: anObj addedVoid: (objRef) anObjRef Responds to a message that a component has added a void by checking to see if the message came from self and, if so, recalculating the quantity. concreteComponent:removedAddOn: - concreteComponent: anObj removedAddOn: (objRef) anObjRef Responds to a message that a component has removed an add-on by checking to see if the message came from self and, if so, recalculating the quantity. concreteComponent:removedVoid: - concreteComponent: anObj removedVoid: (objRef) anObjRef Responds to a message that a component has removed a void by checking to see if the message came from self and, if so, recalculating the quantity. volume:changedVolumeFrom:to: - volume: (objRef) anObjRef changedVolumeFrom: (double*) oldValue to: (double*) newValue Responds to a message that a component has changed its volume by checking to see if the message came from self, a void, or an add-on and, if so, recalculating the quantity.
205
Appendix II - GenCOM Class Documentation
ConstructionMethod SUPER CLASS
SOLObject
SUB-PROJECT
ConstrObjs
CLASS DESCRIPTION A construction method represents a specific way of applying an action to a component. This implies a specific technique and a specific set of resources, e.g., place concrete for column "using 1 cy bucket and crane". Methods are purely conceptual, they do not represent construction effort (construction effort is represented by activities which are defined as the application of some action to some component using some method). The method defined for an activity may frequently be no more than "standard method," since construction data is not tracked with enough precision to distinguish between alternative methods.
ATTRIBUTES activityCategories A relationship to the set of objects that represent the generic types of activities that used this method. A relationship-set attribute. Each value must be a kind of ActivityCategory. constructionPlans A relationship to the set of ConstructionPlan objects that use this method as a default construction method. A relationship-set attribute. Each value must be a kind of ConstructionPlan.
206
Appendix II - GenCOM Class Documentation
ConstructionPlan SUPER CLASS
ProjectSpecificObject
SUB-PROJECT
ProjObjs
CLASS DESCRIPTION The construction plan is the representation of the entire process used to complete a project (i.e., to create the facility).
ATTRIBUTES activities A relationship to the set of activities that make up the construction plan. Broadcasts "constructionPlan:addedActivity:" and "constructionPlan:removedActivity:" messages. A relationship-set attribute. Values must be kinds of Activity. Values are owned by the object. defaultConstructionMethods A relationship to the set of ConstructionMethod objects are declared to be default construction methods for this plan. A relationship-set attribute. Each value must be a kind of ConstructionMethod. durationUnits The units used for measuring durations in the plan. A string attribute. Max. card. 1. project A relationship to the project of this plan. For every project there is one construction plan (a future extension may allow multiple "alternative" plans to be associated with a project). A relationship attribute. The max. card. is 1. The value must be a kind of Project. The object is owned by the value. The object is a constituent of the value.
207
Appendix II - GenCOM Class Documentation
Contract SUPER CLASS
ProjectSpecificObject
SUB-PROJECT
ProjObjs
CLASS DESCRIPTION A representation of a contract between any project participants.
ATTRIBUTES participants A relationship to the project participants involved in the contract. A relationship-set attribute. Values must be a kind of ProjectParticipant. project A relationship to the contract's project. A relationship attribute. The max. card. is 1. The value must be a kind of Project. The object is owned by the value.
208
Appendix II - GenCOM Class Documentation
CrewResource SUPER CLASS
Resource
SUB-PROJECT
ProjObjs
CLASS DESCRIPTION A crew resource consisting of specific labor and equipment resources (this is a specific instance, e.g., the crew made up of Joe, Frank, and crane #42).
209
Appendix II - GenCOM Class Documentation
CrewResourceCategory SUPER CLASS
ResourceCategory
SUB-PROJECT
ConstrObjs
CLASS DESCRIPTION A type of resource.
210
Appendix II - GenCOM Class Documentation
CylindricalConcreteComponent SUPER CLASS
ConcreteComponent
MULTIPLE-INHERETENCE SUPER CLASSES CylindricalVolume SUB-PROJECT
ProjObjs
CLASS DESCRIPTION The class of cylindrical cast-in-place concrete components. Inherits from both ConcreteComponent and CylindricalVolume.
211
Appendix II - GenCOM Class Documentation
CylindricalVolume SUPER CLASS
Volume
SUB-PROJECT
ProjObjs
CLASS DESCRIPTION A cylindrical 3-dimensional geometric shape.
ATTRIBUTES diameter The diameter of the cylinder Given in the dimension units. A real-number attribute. Max. card. 1. The volume must be equal to (pi*(diameter/2)^2)*height. This is implemented as diameter and height "set-confirm" override methods, and the volume value source is set to Gen_Calculated. height The height of the cylinder Given in the dimension units. A real-number attribute. Max. card. 1. The volume must be equal to (pi*(diameter/2)^2)*height. This is implemented as diameter and height "set-confirm" override methods, and the volume value source is set to Gen_Calculated.
212
Appendix II - GenCOM Class Documentation
EquipmentResource SUPER CLASS
Resource
SUB-PROJECT
ProjObjs
CLASS DESCRIPTION An equipment resource (a specific instance, e.g., Crane #42).
213
Appendix II - GenCOM Class Documentation
EquipmentResourceCategory SUPER CLASS
ResourceCategory
SUB-PROJECT
ConstrObjs
CLASS DESCRIPTION A type of resource.
214
Appendix II - GenCOM Class Documentation
Facility SUPER CLASS
ProjectSpecificObject
SUB-PROJECT
ProjObjs
CLASS DESCRIPTION The facility is the representation of the actual physical object (e.g., the building, bridge, highway, etc.), the creation (or modification or removal) of which is the goal of the project.
ATTRIBUTES components A relationship to the set of physical components that make up the facility. A relationship-set attribute. Values must be kinds of Components. Values are part of the object. project A relationship to the project that will create this facility. For every project there is one facility (a future extension may allow multiple "alternative" facilities to be associated with a project). A relationship attribute. The max. card. is 1. The value must be a kind of Project. The object is owned by the value. The object is a constituent (1-to-1 aggregation subpart) of the value.
215
Appendix II - GenCOM Class Documentation
LaborResource SUPER CLASS
Resource
SUB-PROJECT
ProjObjs
CLASS DESCRIPTION A labor resource (a specific instance, e.g., Joe, a carpenter).
216
Appendix II - GenCOM Class Documentation
LaborResourceCategory SUPER CLASS
ResourceCategory
SUB-PROJECT
ConstrObjs
CLASS DESCRIPTION A type of resource.
217
Appendix II - GenCOM Class Documentation
MaterialResource SUPER CLASS
Resource
SUB-PROJECT
ProjObjs
CLASS DESCRIPTION A material resource. This is a specific instance, but the definition of a material resource instance depends upon the nature of the resource, e.g., rebar #10123 or Concrete load #15. This information may be relevant for materials handling or accounting purposes, for example.
218
Appendix II - GenCOM Class Documentation
MaterialResourceCategory SUPER CLASS
ResourceCategory
SUB-PROJECT
ConstrObjs
CLASS DESCRIPTION A type of resource.
219
Appendix II - GenCOM Class Documentation
Person SUPER CLASS
SOLObject
SUB-PROJECT
ConstrObjs
CLASS DESCRIPTION An individual person, typically someone involved in the project in some capacity.
ATTRIBUTES address The address of the person. A string attribute. Should return the address of the person's employer if no value is given. employer A relationship to the company that employs this person. A relationship attribute. Max. Card. 1. Values must be a kind of Company. Inverse relationship is employer, card. n. fax The fax number of the person. A string attribute. firstName The first name of the person. A string attribute. lastName The last name of the person. A string attribute. phone The phone number of the person. A string attribute. projects A relationship to all of the projects that this person is or has participated in. See "ProjectParticipants" class. A relationship-set attribute. Values must be a kind of ProjectParticipant. Inverse relationship is contactPeople, card. n. title The title of the person. A string attribute.
220
Appendix II - GenCOM Class Documentation
Project SUPER CLASS
ProjectSpecificObject
SUB-PROJECT
ProjObjs
CLASS DESCRIPTION A project object represents a construction project as a whole. It is the root class of all objects relating to the specific project (i.e., all objects relating to the project are owned directly or indirectly by the project object).
ATTRIBUTES constructionPlan The construction plan of the project is the representation of the entire process used to complete the project (i.e., to create the facility). For every project there is one construction plan (a future extension may allow multiple "alternative" plans to be associated with a project). A relationship attribute. Values must be a kind of ConstructionPlan. The value is owned by the object. The value is a constituent of the object. contracts A relationship to contracts established between project participants. A relationship-set attribute. Values must be a kind of Contract. facility The facility of the project represents the overall object or product that will be created by the project. The facility object is the root object of all objects that represent the physical components or actual pieces being constructed. For every project there is one facility object (a future extension may allow multiple "alternative" facility to be associated with a project). A relationship attribute. Values must be a kind of Facility. The value is owned by the object. The value is a constituent of the object. location The location of this project. A string attribute. participants A relationship to all of the companies participating on this project (e.g., owner, designers, contractors, etc.). See "ProjectParticipants" class. A relationship-set attribute. Values must be a kind of ProjectParticipant. Values are owned by the object. projectNumber The identify code number for this project. A string attribute.
221
Appendix II - GenCOM Class Documentation
ProjectParticipant SUPER CLASS
ProjectSpecificObject
SUB-PROJECT
ProjObjs
CLASS DESCRIPTION A representation of a specific company's participation on a specific project. Project Participant objects refer to a project, a company, relevant contact people, and any project contracts.
ATTRIBUTES activities A relationship to activities that this participant is responsible for. A relationship-set attribute. Values must be a kind of Activity. company A relationship to the company is participating in this project. A relationship attribute. The max. card. is 1. The value must be a kind of Company. contactPeople A relationship to individual company employees that are working on this project. A relationship-set attribute. Values must be a kind of Person. contracts A relationship to project contracts that this participant is a party to. A relationship-set attribute. Values must be a kind of Contract. project A relationship to the project that the company is participating in. A relationship attribute. The max. card. is 1. The value must be a kind of Project. The object is owned by the value.
222
Appendix II - GenCOM Class Documentation
ProjectSpecificObject SUPER CLASS
SOLObject
SUB-PROJECT
ProjObjs
CLASS DESCRIPTION A meta-class (a class not intended to have direct instances) that is the root of all classes that represent information about a specific project. It implements the common attribute of the identification number of the project to which the object applies.
ATTRIBUTES projectNumber The number of the project to which this object belongs. This is somewhat redundant since there is always some relationship to the actual project object, but this gives a short, locally stored identifier that is useful in quickly identifying which project objects belong to. The value should be the project number of this object's project. Currently this is not maintained automatically, though it probably should be through a more formal representation of object ownership (e.g., each object knows which object owns it, and maintains its project number through that relationship).
223
Appendix II - GenCOM Class Documentation
RectangularConcreteAddOn SUPER CLASS
RectangularConcreteComponent
SUB-PROJECT
ProjObjs
CLASS DESCRIPTION The class of rectangular cast-in-place structural concrete add-ons, or components treated as minor sub-parts of other components.
ATTRIBUTES partOf A relationship to the component that treats this object as an add-on, or minor sub-part. A relationship attribute. Values must be kinds of Component.
224
Appendix II - GenCOM Class Documentation
RectangularConcreteComponent SUPER CLASS
ConcreteComponent
MULTIPLE-INHERETENCE SUPER CLASSES RectangularVolume SUB-PROJECT
ProjObjs
CLASS DESCRIPTION The class of rectangular cast-in-place structural concrete components. Inherits from both ConcreteComponent and RectangularVolume.
225
Appendix II - GenCOM Class Documentation
RectangularVoid SUPER CLASS
ProjectSpecificObject
MULTIPLE-INHERETENCE SUPER CLASSES RectangularVolume SUB-PROJECT
ProjObjs
CLASS DESCRIPTION The class of rectangular voids or block-outs in components.
ATTRIBUTES partOf A relationship to the component that treats this object as an add-on, or minor sub-part. A relationship attribute. Values must be kinds of Component.
226
Appendix II - GenCOM Class Documentation
RectangularVolume SUPER CLASS
Volume
SUB-PROJECT
ProjObjs
CLASS DESCRIPTION A rectangular 3-dimensional geometric shape.
ATTRIBUTES depth The depth of the rectangular shape. Given in the dimension units. A real-number attribute. Max. card. 1. The volume must be equal to width*depth*height. This is implemented as width, depth, and height "set-confirm" override methods, and the volume value source is set to Gen_Calculated. height The height of the rectangular shape. Given in the dimension units. A real-number attribute. Max. card. 1. The volume must be equal to width*depth*height. This is implemented as width, depth, and height "set-confirm" override methods, and the volume value source is set to Gen_Calculated. width The width of the rectangular shape. Given in the dimension units. A real-number attribute. Max. card. 1. The volume must be equal to width*depth*height. This is implemented as width, depth, and height "set-confirm" override methods, and the volume value source is set to Gen_Calculated.
227
Appendix II - GenCOM Class Documentation
Resource SUPER CLASS
ProjectSpecificObject
SUB-PROJECT
ProjObjs
CLASS DESCRIPTION Any specific resource or entity used during the course of the project. Can be physical (e.g., a crane) or conceptual (e.g., space or information). May or may not be consumed during use.
ATTRIBUTES partOf A relationship to the composite object that this object is a part of (i.e., the parent object in an aggregation hierarchy). Currently, multiple inheritance is allowed. A relationship-set attribute. The value must be a kind of Resource (or a ResourceRelationship). The object is a part of the value (i.e. a parent in an aggregation hierarchy). resourceCategory A relationship to the object that represents the generic type of resource that characterizes this resource. A relationship attribute. Max. cardinality 1. Value is kind of ResourceCategory. Object is a member of the value (a category). resourceUse A relationship to the uses of this resource for activities. The message "resource:addedResourceUse:" is broadcast when values are added and "resource:removedResourceUse:" when a value is removed. A relationship attribute. Value is kind of ResourceUse. The value is fully dependent upon this object. subparts A relationship to the set of objects that make up this composite (i.e., the children objects in an aggregation hierarchy). A relationship-set attribute. The values must be kinds of Resource (or a ResourceRelationship). The values are part of the object. unitPrice The overall unit price for the resource given in dollars per unit specified by the "units" attribute. Can inherit a value from the resource category object (implemented in a "get-check" method). Broadcasts the message "resource:changedUnitPriceFrom:to:" when the value is changed. A real-number attribute. units Identifies the units used for measuring the quantity and unit price of this resource. Can inherit a value from the resource category object (implemented in a "get-check" method). Broadcasts the message "resource:changedUnitsFrom:to:" when the value is changed. A string attribute. Value should be one of: m, m2, m3, hr, ft, sf, cf, yd, sy, cy, etc.
228
Appendix II - GenCOM Class Documentation
ResourceCategory SUPER CLASS
SOLCategory
SUB-PROJECT
ConstrObjs
CLASS DESCRIPTION A type of resource.
ATTRIBUTES partOf A relationship to the composite object that this object is a part of (i.e., the parent object in an aggregation hierarchy). Currently, multiple inheritance is allowed. A relationship-set attribute. The value must be a kind of ResourceCategory (or a ResourceRelationship). The object is a part of the value (i.e. a parent in an aggregation hierarchy). resources A relationship to the specific resources represented by this resource category. A relationship-set attribute. Value is kind of Resource. Values are a member of this object (a category). resourceUse A relationship to the uses of this resource for activities. The message "resourceCategory:addedResourceUse:" is broadcast when values are added and "resourceCategory:removedResourceUse:" when a value is removed. A relationship attribute. Value is kind of ResourceUse. The value is fully dependent upon this object. resourceUseCategories A relationship to the uses of this resource for activities. The message "resourceCategory:addedResourceUse:" is broadcast when values are added and "resourceCategory:removedResourceUse:" when a value is removed. A relationship attribute. Value is kind of ResourceUse. The value is fully dependent upon this object. subparts A relationship to the set of objects that make up this composite (i.e., the children objects in an aggregation hierarchy). A relationship-set attribute. The values must be kinds of ResourceCategory (or a ResourceRelationship). The values are part of the object. unitPrice The default unit price for the resource given in dollars per unit specified by the "units" attribute. Broadcasts the message "resourceCategory:changedUnitPriceFrom:to:" when the value is changed. A real-number attribute. units Identifies the default units used for measuring the quantity and unit price of this resource. Broadcasts the message "resourceCategory:changedUnitsFrom:to:" when the value is changed. A string attribute. Value should be one of: m, m2, m3, hr, ft, sf, cf, yd, sy, cy, etc.
229
Appendix II - GenCOM Class Documentation
ResourceRelationship SUPER CLASS
SOLObject
SUB-PROJECT
ConstrObjs
CLASS DESCRIPTION This object is used for representing a relationship between a child resource and a parent resource (or resourceUse) in which attributes are required to describe the relationship. The attributes that can be described using this object are count, or a quantity of the sub-resource (i.e., a "crew" parent resource contains 3 "carpenter" sub-resources); or a conversion factor for converting the units of the subresource to the units of the super-resource. If neither of these attributes is required for a resource relationship, then this object is not used (the relationship is directly between the two resources).
ATTRIBUTES conversion A conversion factor converting the sub-resource units to the super-resource units. The conversion factor should be in units of (Sub-ResourceUse units)/(Super-ResourceUse units). A real-number attribute. A default value of 1.0 is returned if no other value has been assigned or inherited (implemented using a "get-check" override function). partOf A relationship to the composite object that this object is a part of (i.e., the parent object in an aggregation hierarchy). Currently, multiple inheritance is allowed. A relationship-set attribute. The value must be a kind of Resource (or a ResourceRelationship). The object is a part of the value (i.e. a parent in an aggregation hierarchy). subpartCount The number of sub-resources. For, example, 3 carpenters. Broadcasts the messages: "resourceRelationship:willProvideSubpartCount:," "resourceRelationship:willChangeSubpartCountFrom:to:," and "resourceRelationship:changedSubpartCountFrom:to:." A real-number attribute. Max. Card. 1. Default value of 1.0 (implemented as a "get-check" override function that sets the value source to Gen_Default). subparts A relationship to the set of objects that make up this composite (i.e., the children objects in an aggregation hierarchy). A relationship-set attribute. The values must be kinds of Resource (or a ResourceRelationship). The values are part of the object.
230
Appendix II - GenCOM Class Documentation
ResourceUse SUPER CLASS
ProjectSpecificObject
SUB-PROJECT
ProjObjs
CLASS DESCRIPTION A ResourceUse object represents the utilization of some resource for a particular activity. It identifies the activity and resource involved (both resource categories and individual resources), and describes the quantity, conversion factor, and pricing data of the resource application.
ATTRIBUTES activity A relationship to the activity object associated with this resource use. A relationship attribute. Max. cardinality 1. Value is kind of activity. The conversion A conversion factor converting the resource units to the activity units. The conversion factor should be in units of (ResourceUse units)/(Activity units). Broadcasts the message "resourceUse:changedConversionFrom:to:" when the value is changed. A real-number attribute. A default value of 1.0 is returned if no other value has been assigned or inherited (this is implemented as a "get-check" override function). cost The total cost for the activity in dollars. Broadcasts the message "resourceUse:changedCostFrom:to:" when the value is changed. A real-number attribute. quantity A measure of the quantity of the activity in the units specified by the "units" attribute. Broadcasts the message "resourceUse:changedQuantityFrom:to:" when the value is changed. A real-number attribute. resourceCategories A relationship to the resources categories associated with this resource use. Any related resources (specific instances) should correspond to these resourceCategory objects. A relationship-set attribute. Value is kind of ResourceCategory (or ResourceRelationship). resources A relationship to the resources (specific instances) associated with this resource use. These resources should correspond to the related resourceCategory objects. A relationship-set attribute. Value is kind of Resource (or ResourceRelationship). resourceUseCategory A relationship to the object that represents the generic type of resource use that characterizes this resource use. A relationship attribute. Max. cardinality 1. Value is kind of ResourceUseCategory. Object is a
231
Appendix II - GenCOM Class Documentation
member of the value (a category). unitPrice The overall unit price for the activity given in dollars per unit specified by the "units" attribute. Broadcasts the message "resourceUse:changedUnitPriceFrom:to:" when the value is changed. A real-number attribute. A value can be inherited from the ResourceUseCategory (this is implemented as a "get-check" override function). units Identifies the units used for measuring the quantity and unit price of this activity. Broadcasts the message "resourceUse:changedUnitsFrom:to:" when the value is changed. A string attribute. Value should be one of: m, m2, m3, hr, ft, sf, cf, yd, sy, cy, etc. A value can be inherited from the ResourceUseCategory (this is implemented as a "get-check" override function).
232
Appendix II - GenCOM Class Documentation
ResourceUseCategory SUPER CLASS
SOLCategory
SUB-PROJECT
ConstrObjs
CLASS DESCRIPTION Instances of the ResourceUseCategory class represent the use of a type of resource for a type of activity, e.g., the use of "25 ton cranes" for "steel beam erection" activities (see the ResourceUse class).
ATTRIBUTES activityCategories A relationship to the activity categories associated with this type of resource use. A relationship-set attribute. Value is kind of activityCategory. conversion A default conversion factor converting the resource units to the activity units. The conversion factor should be in units of (ResourceUse units)/(Activity units). Broadcasts the message "resourceUseCategory:changedConversionFrom:to:" when the value is changed. A real-number attribute. A default value of 1.0 is returned if no other value has been assigned (this is implemented as a "get-check" override function). resourceCategories A relationship to the resources categories associated with this type of resource use. A relationship-set attribute. Value is kind of ResourceCategory (or ResourceRelationship). resourceUse A relationship to the specific resource use objects represented by this resource use category. A relationship-set attribute. Value is kind of ResourceUse. Values are a member of this object (a category). unitPrice The default overall unit price for this type of resource use given in dollars per unit specified by the "units" attribute. Broadcasts the message "resourceUseCategory:changedUnitPriceFrom:to:" when the value is changed. A real-number attribute. units Identifies the default units used for measuring the quantity and unit price of this type of resource use. Broadcasts the message "resourceUseCategory:changedUnitsFrom:to:" when the value is changed. A string attribute. Value should be one of: m, m2, m3, hr, ft, sf, cf, yd, sy, cy, etc.
233
Appendix II - GenCOM Class Documentation
SOLCategory SUPER CLASS
SOLObject
SUB-PROJECT
ConstrObjs
CLASS DESCRIPTION A meta-class (or class not intended to have direct instances) that represents categories of similar things. Attributes that are generic to all categories are a member superclass (or a class that is an ancestor of all members). Members could also be an attribute at this level, but this is difficult because the inverse relationship must be specified and this is not identical for all membership relations.
ATTRIBUTES memberSuperClass The name of a class that is an ancestor of all members of this category. This is typically used for checking member class types and as a default class for creating new members. A string attribute. Max. card. 1. Must be the name of a class.
234
Appendix II - GenCOM Class Documentation
Volume SUPER CLASS
SOLObject
SUB-PROJECT
ProjObjs
CLASS DESCRIPTION A meta-class (a class not intended to have direct instances) of 3-dimensional geometric shapes.
ATTRIBUTES dimensionUnits The units used for measuring the linear dimensions of the shape. A string attribute. Max. card. 1. volume The volume of the shape. Given in the dimension units cubed. Broadcasts the messages "volume:willProvideVolume:," "volume:willChangeVolumeFrom:to:," and "volume:changedVolumeFrom:to:." A real-number attribute. Max. card. 1. Subclasses generally calculated the value automatically from the linear dimension attributes.
235
Appendix III SOL Class Definition and Data Samples GenCOM classes are subclasses of the SOLObject, a SOL database class that adds persistence and other database capabilities to the basic Objective-C Object. Thus, GenCOM classes are implemented in Objective-C code. During this research, I developed a programming tool—the Object Design System, or ODS—that helped produce the Objective-C code and documentation for the GenCOM model and the OPIS applications. This appendix describes ODS, presents a sample GenCOM-like class, and gives examples of the code required to implement the sample1 . It also provides an example of the ASCII form of SOL database data when they are written out to files.
A3.1. The ODS Object Design System The implementation of any Objective-C class requires a header file (that declares class information required by other elements of the program), a main file (that implements the object’s methods), and an optional documentation file. During the creation of the OPIS system, I created the Object Design System, or ODS. ODS allows all the necessary class information to be entered into a single hierarchical browser (see figure A3.1), and it can then generate the header, main, and formatted documentation files automatically. ODS can create regular Objective-C classes—in which case the user enters information such as the instance variables and the method’s code—or SOL database classes—in which case the user enters information such as attribute names and attribute-configuration code. ODS created the class documentation supplied in appendices I and II from descriptive information that I supplied to it. ODS stores its information in ASCII characters using the same Hierarchical Data Format (HDF) that the SOL database uses for writing out its data (section 4.4.12.2). The next section provides the class documentation for a small sample
1
Readers interested in the actual OPIS source code should contact the author through the Center for Integrated Facility Engineering, Dept. of Civil Engineering, Stanford University, CA, 94305-4020.
236
Appendix III- SOL Class Definition and Data Samples
Figure A3.1: ODS, the Object Design System, is a utility for creating Objective-C and SOL classes, including documentation files
237
Appendix III- SOL Class Definition and Data Samples
SOL class that illustrates two attributes, an override function, a broadcast method, and multiple inheritance. This is followed by the sample class’s header file and main file created by ODS for compiling in Objective-C. The appendix then gives the HDF grammar, the ODS’s own HDF file, and an HDF file created by the SOL database that contains the instance data from a library containing a single instance of the sample class.
A3.2. ATestClass Class Documentation
ATestClass SUPER CLASS
AClass1
MULTIPLE-INHERETENCE SUPER CLASSES AClass2 SUB-PROJECT
ProjObjs
CLASS DESCRIPTION This is a test object to demonstrate the SOL class-definition formats.
ATTRIBUTES testDouble A real-number attribute with an confirm override function. A real-number attribute. Max. card. 1. Value constraint is implemented in "set-confirm" override function. testRelationship A relationship attribute. Broadcasts a "aTestClass:changedTestRelationshipFrom:to:" message when the value has been changed. A relationship attribute. Max. cardinality 1.
A3.3. ATestClass.h (the Objective-C header file) /*****file generated by ODS - the Object Design System**** ATestClass.h (see ATestClass.doc file) */ /* Import files */ #import "AClass1.h" #ifndef TESTDOUBLE #define TESTDOUBLE NXAtom testDouble; #endif
238
Appendix III- SOL Class Definition and Data Samples
#ifndef TESTRELATIONSHIP #define TESTRELATIONSHIP NXAtom testRelationship; #endif @interface ATestClass: AClass1 /* Attribute configuration */ + configureAttributes: anInstance; + initialize; + configureTestDouble: anInstance; + configureTestRelationship: anInstance; - configureSuperClasses; @end
A3.4. ATestClass.m (the Objective-C main file) /*****file generated by ODS - the Object Design System**** ATestClass.m (see ATestClass.doc file) */ /* Import files */ #import "ATestClass.h" #import "AClass2.h" static int _testDoubleSetCheck(id anObject, id aSelf, double* origValue, double* currentValue, double* newValue) /* A function used as an override function for the testDouble attribute * * Implements the constraint-check on new values */ { /* Constraint-checking code goes here. */ /* Return NO to prevent new value from being set. */ return YES; } @implementation ATestClass /*---------------------------------------------------------------------*/ /* Attribute configuration */ + configureAttributes: anInstance { /* Add attributes from superclasses */ [[self superClass] configureAttributes: anInstance]; /* Add attributes for this class. */ if(![anInstance attribute: testDouble]) [anInstance addAttribute: [self configureTestDouble: anInstance] as: testDouble]; if(![anInstance attribute: testRelationship]) [anInstance addAttribute: [self configureTestRelationship: anInstance] as: testRelationship];
239
Appendix III- SOL Class Definition and Data Samples
return self; } + initialize; { [super initialize]; /* Since this method can be called more than once through inheritence...*/ if (self == [ATestClass class] ) { /* Initialize attribute name variables. */ testDouble = NXUniqueStringNoCopy("testDouble"); testRelationship = NXUniqueStringNoCopy("testRelationship"); } return self; } + configureTestDouble: anInstance; { return [[[DoubleAttribute allocFromZone: [self zone]] setSetCheckMethod: (int(*)(id, id, void*, void*, void*)) _testDoubleSetCheck] initObject: anInstance]; } + configureTestRelationship: anInstance; { return [[[[[Relationship allocFromZone: [self zone]] initObject: anInstance] setInverseRel: testInverseRelationship] setInverseCard: ATTRIB_SET] setChangedBroadcast: @selector(aTestClass:changedTestRelationshipFrom:to:)]; } - configureSuperClasses; { [super configureSuperClasses]; [superClassList addObject: [AClass2 class]]; return self; } @end
A3.5. The Hierarchical Data Format, HDF A formal hierarchical data grammar is used by the SOL database system for saving data to disk in ASCII format, and by ODS for storing its information. This grammar must be flexible and expressive, simple to process computationally, and easy for humans to understand and edit. The grammar uses hierarchical "frames" of "units" written in ASCII characters:
240
Appendix III- SOL Class Definition and Data Samples
Where: — commas and parenthesis are literal symbols that to appear exactly as shown — square brackets indicate optional elements — ellipses indicate a repetition of similar elements — identifier = a sequence of any alpha-numeric ASCII characters — constant = a number — string = a sequence of ASCII characters enclosed in quotation marks The HDF is defined as follows: hierarchical-data-file: unit [, ...] unit: unit-name ( unit [, ...] ) unit-name ( string [, ...] ) unit-name ( literal [, ...] ) unit-name: identifier literal: identifier constant
A3.6. ATestClass.hdf (the ODS data file) class( name(ATestClass) attributes( attribute( name(testDouble) configCode( ``{ return [[[DoubleAttribute allocFromZone: [self zone]] setSetCheckMethod: (int(*)(id, id, void*, void*, void*)) _testDoubleSetCheck] initObject: anInstance]; }`` ) constraints( ``A real-number attribute. Max. card. 1. Value constraint is implemented in "set-confirm" override function.`` ) description( ``A real-number attribute with an confirm override function.`` ) overrideFuncs( ``static int _testDoubleSetCheck(id anObject, id aSelf, double* origValue, double* currentValue, double* newValue) /* A function used as an override function for the testDouble attribute * * Implements the constraint-check on new values */ { /* Constraint-checking code goes here. */ /* Return NO to prevent new value from being set. */ return YES;
241
Appendix III- SOL Class Definition and Data Samples
}`` ) ) attribute( name(testRelationship) configCode( ``{ return [[[[[Relationship allocFromZone: [self zone]] initObject: anInstance] setInverseRel: testInverseRelationship] setInverseCard: ATTRIB_SET] setChangedBroadcast: @selector(aTestClass:changedTestRelationshipFrom:to:)]; }`` ) constraints( ``A relationship attribute. Max. cardinality 1.`` ) description( ``A relationship attribute. Broadcasts a "aTestClass:changedTestRelationshipFrom:to:" message when the value has been changed.`` ) ) ) description( ``This is a test object to demonstrate the SOL class-definition formats.`` ) frontCode( hImports( ``#import "AClass1.h" `` ) mImports( ``#import "ATestClass.h" #import "AClass2.h"`` ) ) methodCategories( ) subProject(ProjObjs) superclass(AClass1) superClasses( superClass( name(AClass2) ) ) variables( ) )
A3.7. ATestLibrary.hdf (SOL Data File) object( class("SOLLibrary"), refSubscribers( subscriber( objName ("aTestObject") libName ("ATestLibrary") subscriberName ("") )
242
Appendix III- SOL Class Definition and Data Samples
) attributes( attribute( class("RelationshipSet") name("objects") valueSet( value( objName ("aTestObject") libName ("ATestLibrary") ) ) ) attribute( class("IntegerAttribute") name("edited") valueTime (707375684) valueSource (101) value (01) ) attribute( class("StrAttribute") name("description") valueTime (707375684) valueSource (105) value ("This is a test library, containing a single test object.") ) attribute( class("StrAttribute") name("libraryName") valueTime (707375349) valueSource (101) value ("ATestLibrary") ) attribute( class("StrAttribute") name("filename") valueTime (707375599) valueSource (101) value ("/Users/froese/ATestLibrary.olib") ) ) objects( object( class("ATestClass"), refSubscribers( subscriber( objName ("anotherObject") libName ("AnotherLibrary") subscriberName ("") ) subscriber( objName ("#lib") libName ("ATestLibrary") subscriberName ("") ) ) attributes( attribute( class("DoubleAttribute") name("testDouble")
243
Appendix III- SOL Class Definition and Data Samples
valueTime (707375707) valueSource (105) value (42.6) ) attribute( class("Relationship") name("library") valueTime (707375391) valueSource (101) value( objName ("#lib") libName ("ATestLibrary") ) ) attribute( class("Relationship") name("testRelationship") valueTime (707375566) valueSource (105) value( objName ("anotherObject") libName ("AnotherLibrary") ) ) attribute( class("StrAttribute") name("description") valueTime (707375697) valueSource (105) value ("This is a test object, an instance of ATestClass.") ) attribute( class("StrAttribute") name("objectName") valueTime (707375391) valueSource (101) value ("aTestObject") ) attribute( class("IntegerAttribute") name("edited") valueTime (707375697) valueSource (101) value (01) ) ) ) ) )
244
Appendix IV Scheduling and Estimating Object Models This appendix contains the object models derived from an analysis of the Primavera Project Planner scheduling system and the Timberline Precision Plus estimating system (see section).
A4.1. Domain Model for Project Scheduling Based on Primavera Project Planner A4.1.1.
List of Classes Activity Logic Constraint Activity Code Resource Use
Scheduling System Project Calendar Activity Code Definition Resource Definition
A4.1.2.
Class Diagram Scheduling System
Project
Activity Code Def'n
Activity Code
Interface
Report
Calendar
Activity
Resource Def'n
Resource Use
Logic Constraint
Figure A4-1: Classes for Project Scheduling Based on Primavera Project Planner
245
Appendix I V- Scheduling and Estimating Object Models
A4.1.3.
Class Documentation
class:
Scheduling System
description: Relationships
The top-level object for the scheduling system.
project: interfaces: reports:
The current project. A series of interface objects for the system that perform user i/o. A set of report objects that produce output reports for the project.
class:
Project
description:
The top level representation of a "project". Contains information about the project as a whole such as project name, owner, etc.
General attributes name: project title: company name: report center heading: network type:
A unique 4 digit identifier for the project. Used as first part of file names. Used in menus for selecting specific projects. The title (full name) of the project. The company name (user). The title to appear as a heading for reports. Either PDM or ADM indicating precedence network or arrow network. Can’t be changed after project is created.
General relationships target #1: target #2: Calendar attributes
The name of another project that is used for comparison with this one. The name of another project that is used for comparison with this one.
planning unit:
D, W, or M indicating whether scheduling is performed using days, weeks, or months. Can’t be changed after project is created. The date on which the project starts. The latest allowable finish date for the project. The actual current date for the purpose of schedule calculations. The earliest finish date for the project from schedule calculations. The day that a week starts on for this project. A set of intervals during which no work is performed. Apply to all activities in the project (i.e. override other calendars). A set of intervals during which work occurs even though they are included in non-work periods. Apply to all activities in the project (i.e. override other calendars).
project start date: latest finish date: schedule data date: early finish date: week start day: non-work periods: exception periods:
Calendar relationships calendar ids:
The ids of the calendars used in computing the project schedule. Calendar 1 is always created when a project is created and is always one of the project calendars. Two additional calendars can be assigned. Activity Code Dictionary attributes and relationships act. code definitions:
A series of activity code definitions that govern the activity codes used for all the activities in this project. act. code subtitles: A series of value combinations for multiple activity codes along with corresponding sub-titles or descriptions. act. id definitions: A series of name, length, and description statements that define what various portions of the activity ID’s represent. Cost Code Dictionary attributes cost categories:
A series of codes with corresponding titles that define the cost categories that activities can be assigned to.
246
Appendix I V- Scheduling and Estimating Object Models
cost account titles:
A series of cost account numbers with corresponding titles that costs can be assigned to in the project. Resource Dictionary relationships resource definitions: Methods
A series of resource definitions that can be used for this project.
attribute access: attribute calculation:
Methods for setting and getting attributes and relationship values. Methods for calculating attributes that are derived from other attribute values (including resource use and cost attributes). Methods for performing the CPM scheduling calculations. Methods for performing resource leveling calculations. Some methods associated with generating output reports, such as summing resource use and costs, etc.
scheduling: resource leveling: reporting methods:
class:
Calendar
description: Attributes
Define working and non-working periods.
calendar name: title: workdays: non-work periods: exception periods:
A unique identification for the calendar . A descriptive name of the title. Indicates which days of the week are normal work days. A set of intervals during which no work is performed. A set of intervals during which work occurs even though they are included in non-work periods.
class:
Activity Code Definition
description:
Activity codes are user defined codes used for assigning activities to various categories. The user definition of each code is represented in by this object.
Attributes code name: description: length: titles:
A unique 4 digit identification for the code. A description of the activity code. The maximum length of a value for the code. A series of values with corresponding titles or descriptions for the code.
class:
Resource Definition
description:
Define resources that are used on the project, along with availability limits and unit prices.
Attributes name: description: units: limits: unit price:
A unique 8 digit identification for the resource. A description of the resource. The units used for quantifying the resource (i.e., man hours). A normal availability limit and a maximum availability limit; several sets of limits along with the time periods to which they apply can be given. the price per unit of the resource; several prices along with the time periods to which they apply can be given.
class:
Activity
description:
A tasks to be performed in the project.
247
Appendix I V- Scheduling and Estimating Object Models
General attributes activity id: title: pct: activity code values: log: General relationships
A unique 4 digit identification of an activity. Describes the required task. the schedule percent complete, the relative portion of the activity that has been completed. an optional series of activity code names and their corresponding values. Descriptive notes regarding the activity.
calendar id: Date attributes
The id of the calendar used in computing the dates for this activity.
es: ef: ls: lf: tf: ff: original duration: remaining duration: actual start: actual finish: eswp: efwp: lswp: lfwp: Logic relationships
The early start date. The early finish date. The late start date. The late finish date. The total float. The free float. The estimated total duration of the activity. The estimated remaining duration of the activity. The actual starting date of the activity. The actual finishing date of the activity. The early start work period (i.e. no calendar, consecutive work units). The early finish work period . The late start work period . The late finish work period .
predecessors: The ids of all predecessor relationships (Logic Constraints). successors: The ids of all successor relationships (Logic Constraints). Schedule constraint attributes earliest start: latest start: earliest finish: latest finish: start on: mandatory start: mandatory finish: float/dur constraint:
The earliest allowable starting date for the activity. The latest allowable starting date for the activity. The earliest allowable finishing date for the activity. The latest allowable finishing date for the activity. constrains both early and late start dates. overrides network logic. overrides network logic. One of ZFF, HA, ZTF, or XF for zero free float, hammock activity, zero total float, or expected finish constraint. expected finish: The expected finish date (applies only if XF constraint is used. milestone: SM or EM if the activity is a start or finish milestone. Schedule constraint constraints :
Only one of earliest start, earliest finish, start on, mandatory start, mandatory finish, or actual start dates can be used. : Only one of latest start, latest finish, start on, or actual finish dates can be set. : No finish constraint can be used along with a float/duration constraint. Resource use relationships resource use:
A set of all resource-use information relating to this activity. These represent all resource use and cost information.
Methods attribute access:
Methods for setting and getting attributes and relationship values.
248
Appendix I V- Scheduling and Estimating Object Models
attribute calculation: scheduling: resource leveling: reporting methods:
Methods for calculating attributes that are derived from other attribute values (including resource use and cost attributes). Methods for performing the CPM scheduling calculations. Methods for performing resource leveling calculations. Some methods associated with generating output reports, such as summing resource use and costs, etc.
class:
Logic Constraint
description: Attributes
A logical constraint between two activities.
relationship type:
FS, FF, SF, or SS indicating a finish-start, finish-finish, start-finish, or start-start relationship. A lag value for the relationship (can be positive or negative).
lag: Relationships predecessor activity: successor activity:
The id of the earlier activity in the relationship. The id of the later activity in the relationship.
class:
Activity Code
description:
The values of the activity codes (defined by activity code definition objects).
Attributes activity: code name: code value: Constraints
The activity that is being described by this object. A name of the code. The value of the code for a specific activity.
:
The value must conform to the definition for that activity code.
class:
Resource Use
description: Attributes
Represents information about the use of a resource on an activity.
activity: resource name: resource designation:
The activity that the resource is being used on. The resource that is being used. If more than one instance of a specific type of resource is used on the activity, then a designation character can be used to distinguish between them. The cost account to which the costs of this resource should be charged. The quantity of the resource that is required per time period. The time from the beginning of the activity to the time when the resource begins to be used. The duration of the resource use. The relative completion of the resource use for this activity. The amount spent on the resource use so far relative to the total expected expenditure. The original or latest estimate of the total resource quantity required for this activity. The original or latest estimate of the total cost of this resource for this activity. The quantity of the resource that was originally expected to be used on this activity by this date (requires a target #1 baseline project).
cost account: units per time period: resource lag: resource duration: resource % complete: resource % expended: budgeted quantity: budgeted cost: scheduled budget:
249
Appendix I V- Scheduling and Estimating Object Models
scheduled budget cost: earned value (quant.): earned value ($): quant. this period: cost this period: actual quantity to date: actual cost to date: quantity to complete: cost to complete: quant. at completion: cost. at completion: quantity variance: cost variance:
The cost of the resource that was originally expected to be spent on this activity by this date (requires a target #1 baseline project). The quantity of the resource that was expected to be used to achieve the current percent complete. The cost of the resource that was expected to be spent to achieve the current percent complete. The quantity of the resource that has been used this period (for batch updates only). The cost of the resources that has been spent this period (for batch updates only). The quantity of the resource that has actually been used on this activity to date. The cost of the resource that has actually been spent on this activity to date. The quantity of the resource required to complete this activity. The cost of the resource required to complete this activity. The current estimate of the quantity of the resource that will be used on this activity. The current estimate of the cost of the resource that will be spent on this activity. The difference between the budgeted quantity and the quantity at completion. The difference between the budgeted cost and the cost at completion.
A4.2. Domain Model for Project Estimating Based on Timberline Precision Plus List of Classes Estimating System Spreadsheet Takeoff Totals Database Add-On Definition Formula Labor/Equipment Class Rate table Labor/Equipment Rates Material Class Subcontractor Group Phase Definition Phase Definition Item Definition Crew Category Definition Group Work Package Definition Work Package Definition Work Package Item Definition
Estimate Add-On Item Category One-Time Item One-Time Category Calculations Location Phase Work Package Work Package Item
250
Appendix I V- Scheduling and Estimating Object Models
A4.2.2.
Class Diagram interfaces Estimating System
Takeoff Spreadsheet Totals
database
estimate
Database
Add-On Def'n
Add-On
Estimate
Subcontractor
Group Phase Def'n
Phase Def'n
Phase
Material Class
Calculations
Item Def'n
Formula
Categroy Def'n
Crew
Item
Category
Location
Crew
Lab/Equip Class
Lab/Equip Rates
Rate Table
W.P. Item
W.P. Item Def'n
W.P. Def'n
Work Package
Group W.P. Def'n
Figure A4-2: Classes for Project Estimating Based on Timberline Precision Plus
251
Appendix I V- Scheduling and Estimating Object Models
A4.2.3.
Class Documentation
class:
Estimating System
description: Relationships
The top-level system object.
database:
totals: interfaces:
The database that contains project-independent and default projectspecific data. The project-specific information. An interface to the estimate that lists items sorted by phase. An interface to the estimate that lists items in the chronological order that they were taken off. An interface to the estimate that lists add ons and totals. Misc. interfaces to the database and estimate.
class:
Spreadsheet
description:
An interface listing of phases/items in the estimate sorted by phase. Shows all item data.
class:
Takeoff
description:
An interface chronological listing of phases/items in the estimate. Shows item's phase, description, quantities, and units.
class:
Totals
description:
An interface listing of estimate add on and totals.
class:
Database
description: General attributes
A project estimate
company name: company address: equip. rate headings: labor rate headings: Relationships
The company's name The company's address and phone. The headings of the labor rate table columns. The headings of the equipment rate table columns.
add on definitions: formulae: labor/equip. classes: material classes: phase group def'ns: rate tables: subcontractors: w.p. group def'ns:
The add-on definitions. The formulas. The labor classes The material classes. The phase-group definition objects. The rate tables. The subcontractors. The work package group definitions.
class:
Add-On Definition
description:
An add-on cost item definition.
estimate: spreadsheet: takeoff:
252
Appendix I V- Scheduling and Estimating Object Models
General attributes code: description: basis:
calculation type: rate: taxables only?: allocatable?:
An ID code. A description. The value upon which this add on is calculated. Can be one of labor, material, subcontract, equipment, other, all categories, current total (all costs listed in the estimate prior to this; i.e., depends on position in list of add ons). The type of add on calculation. One of lump sum, constant dollar, straight percentage, dollar add ons with breaks, or bond add-ons. The constant dollar, percentage, etc. rate. Indicates whether this add on applies to taxable categories only. Indicates whether this add-on should be incorporated into category amounts (when add-on allocation is requested ) or add at the end of the estimate.
Relationships jc phase & category:
The job cost phase and category that this add on maps to.
class:
Formula
description: General attributes
A formula for calculating some quantity.
code: formula:
An ID code (name). A mathematical formula.
class:
Labor/Equipment Class
description: General attributes
A labor or an equipment class definition.
code: description: Relationships
An ID code. A description.
rates:
The rates for this class in a specific rate table.
class:
Rate table
description: General attributes
A labor and equipment rate table.
code: Relationships
An ID code (name).
labor rates: equipment rates:
The rates for this each labor class in this rate table (six for each class). The rates for this each equipment class in this rate table (six for each class).
class:
Labor/Equipment Rates
description: General attributes
A rates for a labor or equipment class in a specific rate table.
rate:
A rate per unit time.
253
Appendix I V- Scheduling and Estimating Object Models
Relationships class: rate table:
The labor or equipment rate. The labor or equipment rate table.
class:
Material Class
description:
A material class, used for sorting and summarizing items by materials (bill of materials)
General attributes code: notes:
An ID code (class). The subcontractor's name.
class:
Subcontractor
description: General attributes
A subcontractor.
code: name: short name: address/phone: contact: type: memo:
An ID code (number). The subcontractor's name. A name abbreviation to use on spreadsheet. The subcontractor's address and phone number. A contact person for the subcontractor. The type (e.g., trade) of the subcontractor.
class:
Group Phase Definition
description:
A first level "node" in the indexing scheme or work breakdown structure. Also called a division.
General attributes code: description: unit: Relationships
An ID number (number). A description of the phase. The unit used for summing this phase.
jc phase: sub-phases:
The job cost phase that this phase maps to. The individual sub-phases.
class:
Phase Definition
description:
A second level "node" in the indexing scheme or work breakdown structure.
General attributes code: description: unit: Relationships
An ID number (number). A description of the phase. The unit used for summing this phase.
items: jc phase: group phase:
The items contained in this phase. The job cost phase that this phase maps to. The group phase that his phase belongs to.
254
Appendix I V- Scheduling and Estimating Object Models
class:
Item Definition
description:
Defines items, or data and default values common to all estimate items of a specific description.
General attributes code: description: takeoff unit: Relationships
An ID code. A description of the item. The units used for taking off the quantity of the item.
formula: The formula for calculating the takeoff quantity for items of this type. phase: The phase (index grouping for this item). categories: The specific categories of this item (e.g., labor, equip., etc.) up to three. "Distribution" attributes & relationships alternate bom desc: Alternate description for items of this type when list in bill of materials. j.c. phase: The job cost phase that items of this type map to. material class: The material class that this item maps to. materials position: A sorting position for bill of materials listings. price update code: A code used for updating prices according to specific criteria. units to j.c.: Indicates whether to send takeoff, order, or no units to job cost system. Default value attributes & relationships crew: waste factor:
The default crew used for this item (optional). The default waste factor (%) for this item.
class:
Crew
description: Relationships
A crew made up of labor and equipment classes.
lab/equip classes:
The classes that make up this crew, along with the quantity of each class.
class:
Category Definition
description:
A specific category of an item's cost . Can be Labor, Equipment, Materials, Subcontract, or Other.
General attributes order unit: round off? subcategory: Relationships
The units used for ordering materials for this item. If the category is lab or equipment and a crew is used, this should be a time unit. Indicates whether and how to round off order quantities. The subcategory(s) that this category belongs to.
item definition: linked item:
The item definition that this category is a part of. An item/category to which the price of this item is linked (or are categories linked?). Default value attributes & relationships apply waste?: conversion factor: date price changed: price:
Indicates whether the waste factor should be applied for this category. Convert takeoff units to order units. conversion factor units are automatically (takeoff unit/order unit). The date that this price was last changed. The unit price of this category. If this category is linked, this is taken from the linked item. It the category is labor or equipment and there is a crew, the price must come from the rate table.
255
Appendix I V- Scheduling and Estimating Object Models
taxable?:
Indicates whether this category is taxable.
class:
Group Work Package Definition
description: General attributes
A group of work package definitions.
code: description: Relationships
An ID number. A description of the work package.
sub-w.p.'s:
The individual sub-work packages.
class:
Work Package Definition
description: General attributes
A work package (collection of related items) definitions.
code: description: unit: memo: Relationships
An ID number (number). A description of the work package. The unit used for summing this work package.
formula: group w.p.: items:
The formula for calculating the quantity of work packages of this type. The group work package that this work package belongs to. The items contained in this work package.
class:
Work Package Item Definition
description: General attributes
An item contained in a work package.
calculation method:
Identifies how the quantity of this item should be calculated. One of: use w.p. formula, use item formula, use quantity of previous item, or custom calculation. The calculation formula if the calculation method is "custom calculation".
calculation: Relationships w.p. definition: item definition:
The work package. definition that this belongs to. The item definition that describes this item.
class:
Estimate
description: General attributes
A project estimate
filename: heading: description: job address: client: architect: estimator: bid date, time: document notes: job size:
The name of the estimate. A title used for reports, etc. A description of the estimate. The address of the project The client's name, address, etc. The architect's name. The estimator's name. The date and time of the bid closing. Notes re: bidding documents used. The size (quantity) of the overall job.
256
Appendix I V- Scheduling and Estimating Object Models
job size units: dimension audit?: MWBE requirements: totals: Relationships
The units of the job size. Indicates whether an audit trail of all takeoff calcs. should be kept. Minority/Women Business requirements in lump sum or project cost percentage. totals for each category, of all add-ons, overall, and per job unit.
add-ons: items: locations: phases: rate table: work packages:
The add-ons applied to the estimate. The individual estimate items. The locations defined for in the estimate. The individual phase items. The rate table used for labor and equipment rates. The work packages included in the estimate.
class:
Add-On
description: General attributes
An add-on cost item.
amount: basis:
The amount of the add on. The value upon which this add on is calculated. Can be one of labor, material, subcontract, equipment, other, all categories, current total (all costs listed in the estimate prior to this; i.e., depends on position in list of add-ons). The constant dollar, percentage, or what ever rate.
rate: Relationships add on def'n:
The add-on definition
class:
Item
description: General attributes
An item to be measured and priced in the estimate.
amount: date: memo: price: quantity: sequence number: waste factor: Relationships
The total dollar amount of this item (calculated from category prices). The date and time that the item's quantity was entered or last changed. Notes for this item. The total unit price for this item (calculated from category prices). The takeoff quantity of this item. The chronological sequence in which this item was taken off. The waste factor (%) for this item.
calculations:
An audit trail of the calculations used to determine this item's quantity (called dimensions in program). categories: The specific categories of this item (e.g., labor, equip., etc.) up to three. The categories must correspond to the category definitions for this item's item definition object. crew: The crew used for this item (optional). item def'n: The item definition that this item is a type of. location: The location of this item. subcontractor: The subcontractor for this item. work package: The work package that created this item (if this item was created by a work package). "Distribution" attributes & relationships j.c. phase: material class:
The job cost phase that this item maps to. The material class that this item maps to.
257
Appendix I V- Scheduling and Estimating Object Models
materials position:
A sorting position for bill of materials listings.
class:
Category
description:
A specific category of an item's cost . Can be Labor, Equipment, Materials, Subcontract, or Other.
General attributes amount: apply waste?: conversion factor: order quantity: price: taxable?: Relationships
The total cost of this category. If a value is assigned, the unit price is recalculated accordingly. Indicates whether the waste factor should be applied for this category. Convert takeoff units to order units. The quantity used for pricing this category. The unit price of this category. If a value is assigned, the amount is calculated accordingly. Indicates whether this category is taxable.
item:
The item that this category is a part of.
class:
One-Time Item
description:
An item to be measured and priced in the estimate that is not linked to an item definition. General attributes (as defined above) amount:, code:, description:, memo:, price:, quantity:, takeoff unit:, waste factor: Relationships calculations:, categories:, crew:, formula:, location:, phase def'n:, subcontractor: "Distribution" attributes & relationships alternate bom desc:, j.c. phase:, material class:, materials position:, price update code:, units to j.c.:
class:
One-Time Category
description: A specific category of a one-time item's cost General attributes (defined above) amount:, apply waste?:, conversion factor:, order quantity:, order unit:, price:, taxable?: Relationships item:
class:
Calculations
description: General attributes
An audit of the quantities and calculations used to calculate quantities.
calculations:
The formula variable values or calculations used to determine a quantity.
class:
Location
description:
A location defined for one or more estimates.
258
Appendix I V- Scheduling and Estimating Object Models
General attributes name:
The location's name.
class:
Phase
description: General attributes
An instance of a particular phase in an estimate (e.g., excavation).
quantity: price:
The quantity of the phase instance (in terms of the phase's units). The unit cost of the phase. Calculated from the entered quantity and the total cost of all items in this phase.
Relationships phase definition:
The phase definition that describes this phase.
class:
Work Package
description: General attributes
A work package (collection of related items).
amount: memo: price: quantity: sequence number: unit: Relationships
The total cost of this work package.
location: w.p. definition items:
The location of this item. The work package definition that this work package is a type of. The items contained in this work package.
class:
Work Package Item
description: General attributes
An item contained in a work package.
calculation method:
Identifies how the quantity of this item should be calculated. One of: use w.p. formula, use item formula, use quantity of previous item, or custom calculation. The calculation formula if the calculation method is "custom calculation".
calculation: Relationships w.p.: item:
The unit cost of this work package. The quantity of this work package. The chronological sequence in which this work package was taken off. The unit used for summing this work package.
The work package. that this belongs to. The item that is created by this work package item.
259
List of References [Abdalla 89]
Abdalla, G.A. Object-Oriented Principles and Techniques for Computer Integrated Design. Ph.D. Thesis, Dept. of Civil Engineering, University of California at Berkeley. 1989.
[Abudayyeh 91]
Abudayyeh, O.Y., and W.J. Rasdorf. “Design of Construction Industry Information Management Systems.” Journal of Construction Engineering and Management. Vol. 117, No. 4 (Dec. 1991). pp. 698-715.
[Abudayyeh 92]
Abudayyeh, O.Y., and W.J. Rasdorf. “I(CS)2: A Prototype Integrated Cost and Scheduling Control System.” submitted to Journal of Construction Engineering and Management. 1992.
[Ahmed 91]
Ahmed, S., A. Wong, D. Sriram, and R. Logcher. A Comparison of Object-Oriented Database Management Systems for Engineering Applications. Research Report No: R91-12 (Order No: IESL-90-03, 91-03), Intelligent Engineering Systems Laboratory, Dept. of Civil Engineering, Massachusetts Institute of Technology. May 1991.
[Ashley 87]
Ashley, D.B., and R.E. Levitt. “Expert Systems in Construction: Work in Progress.” Journal of Computing in Civil Engineering. Vol. 1, No. 4 (Oct. 1987). pp. 253-269.
[Atkinson 91]
Atkinson, M., F. Bancilhon, D. DeWitt, K. Dittrich, D. Maier, and S. Zdonik. "The Object-Oriented Database System Manifesto." Deductive and Object-Oriented Databases. Proceedings of the First International Conference (DOOD89). Amsterdam, Netherlands: North-Holland. 1990. pp. 223-240.
[AT&T 89]
AT&T Bell Laboratories. UNIX System V AT&T C++ Language System, Release 2.0 Product Reference Manual. Murray Hill NJ. 1989.
[Atwood 91]
Atwood, Thomas. "Why the OMG Object Request Broker Should Mean Good News for Object Databases." Journal of ObjectOriented Programming. Vol. 4, No. 4 (Jul./Aug. 1991). pp. 8-11.
[Badger 87]
Badger, A.A., K.A. Reinschmidt, and A.R. Gandt. “Project Control System Integration,” Project Controls: Needs and Solutions. New York: American Society for Civil Engineers. 1987. pp. 88-100.
260
List of References
[Barry 91]
Barry, D.K. "Perspectives on Changes for ODBMSs." Journal of Object-Oriented Programming. Vol. 4, No. 4 (Jul./Aug. 1991). pp. 19-20.
[Björk 89]
Björk, B.-C., and H. Penttilä. “A Scenario for the Development and Implementation of a Building Product Model Standard.” Advanced Engineering Software. Vol. 11, No. 4 (1989). pp. 176186.
[Björk 91]
Björk, B.-C., and H. Penttilä. “Building Product Modelling Using Relational Databases, Hypermedia Software and CAD Systems.” Microcomputers in Civil Engineering. No. 6, 1991. pp. 267-279.
[Booch 91]
Booch, G. Object Oriented Design with Applications, Redwood City CA: Benjamin/Cummings. 1991.
[Bretl 89]
Bretl, R., et al. “The Gemstone Data Management System.” Object-Oriented Concepts, Databases and Applications. Reading MA: Addison-Wesley. 1989.
[Brisson 87]
Brisson, F. Knowledge Based Expert System for Planning and Monitoring Construction Projects. S.M. Dissertation, Dept. of Civil Engineering, Massachusetts Institute of Technology. 1987.
[Construction 86]
Construction Industry Press. CCAD: Construction Computer Applications Directory. Silver Spring MD. 1986.
[Cattell 91]
Cattell, R.G.G. Object Data Management: Object Oriented Extended Relational Database Systems. Reading MA: AddisonWesley. 1991.
[Chang 91]
Chang, D.Y., and C. Milligan. “Object-Oriented Design Methodology for Systems Integration. A Research-in-progress Report.” Preparing for Construction in the 21st Century. New York: American Society of Civil Engineers. 1991. pp. 366-368.
[Chinowsky 91]
Chinowsky, P. The Caadie Project: Applying Knowledge-Based Paradigms to Architectural Layout Generation. Ph.D. Thesis, Dept. of Civil Engineering, Stanford University. 1991.
[Cohen 91]
Cohen, G., and R.E. Levitt. “Virtual Design Team. An ObjectOriented Model of Information Sharing in Project Design Teams.” Preparing for Construction in the 21st Century. New York: American Society of Civil Engineers. 1991. pp. 348-353.
[Cohen 92]
Cohen, G. The Virtual Design Team. An Object-Oriented Model of Information Sharing in Project Design Teams. Ph.D. Thesis, Dept. of Civil Engineering, Stanford University. 1992.
[Corps 89a]
Corps of Engineers. Draft Guide Specification, TP 01013 Scheduling System Data Exchange Format. Construction Engineering Research Laboratory. Mar. 1989.
261
List of References
[Corps 89b]
Corps of Engineers. Draft Guide Specification, SC-20 Contractor Prepared Network Analysis System (NAS). Construction Engineering Research Laboratory. Mar. 1989.
[Cox 86]
Cox, B.J. Object-Oriented Programming, An Evolutionary Approach. Reading MA: Addison-Wesley. 1986.
[Cusack 90]
Cusack, M.M. (Chairman). Proceedings of the 7th International Symposium on Automation and Robotics in Construction. Bristol, England: Bristol Polytechnic. Jun. 1990.
[Darwiche 88]
Darwiche, A., R.E. Levitt, and B. Hayes-Roth. “OARPLAN: Generating Project Plans in a Blackboard System by Reasoning about Objects, Actions and Resources.” Artificial Intelligence in Engineering Design, Analysis and Manufacturing. Vol. 2, No. 3 (1988). pp. 169-181.
[Demsetz 90]
Demsetz, L., and C.W. Ibbs. “Integrated Smart Tool Concepts.” Proceedings of the 7th International Symposium on Automation and Robotics in Construction. Bristol, England: Bristol Polytechnic. Jun. 1990. pp. 366-373.
[Dodani 89]
Dodani, M.H., C.E. Hughes, and J.M. Moshell. “Separation of Powers.” Byte. Vol. 14, No. 3 (Mar. 1989). pp. 255-262.
[Duhl 88]
Duhl, J., and C. Damon. “A Performance Comparison of Object and Relational Databases Using the Sun Benchmark.” SIGPLAN Notices. Vol. 23, No. 11 (Nov. 1988). pp. 153-161.
[Dym 91]
Dym, C.L. and R.E. Levitt. Knowledge-based Systems in Engineering. New York: McGraw-Hill. 1991.
[Eggers]
Eggers, J.A. An Introduction to Express. St. Louis, MO: McDonnell Douglas Aerospace Information Services Company, Dept. W315.
[El-Bibany 92]
El-Bibany, H. Architecture for Human-Computer Design, Management and Coordination in a Collaborative AEC Environment. Ph.D. Thesis, Dept. of Civil Engineering, Stanford University. 1992.
[Farber 91]
Farber, D. “Apple, IBM Lay Groundwork for Next Decade of Computing.” MacWeek. Vol. 5, No. 34 (Oct. 8, 1991). p. 1.
[Fenves 90]
Fenves, S., U. Flemming, C. Hendrickson, M. Maher, and G. Schmitt. “Integrated Software Environment for Building Design and Construction.” Computer Aided Design. Vol. 22, No. 1 (Jan./Feb. 1990). p. 27-36.
[Fersko-Weiss 89]
Fersko-Weiss, H. “One Project, 3,000 Tasks: High-end Project Managers Make the Plans.” PC Magazine. Vol. 8, No. 9 (May 1989). pp. 155-195.
262
List of References
[Fikes 85]
Fikes, R.E., and T. Kehler. “The Role of Frame-Based Representation in Reasoning.” Communications of the ACM. Vol. 28., No. 9 (Sep. 1985). p. 904.
[Fischer 91]
Fischer, M., and C.B. Tatum, “Framework for Reasoning About CAD Data.” Preparing for Construction in the 21st Century. New York: American Society of Civil Engineers. 1991. pp. 318-323.
[Fondahl 87]
Fondahl, J.W. “The History of Modern Project Management, Precedence Diagraming Methods: Origins and Early Development.” Project Management Journal. Vol. 18, No. 2 (Jun. 1987). pp. 3336.
[Friedman 91]
Friedman, R. P. Editorial. Journal of Object-Oriented Programming. Vol. 4, No. 4 (Jul./Aug. 1991). p. 6.
[Froese 90]
Froese, T.M., and B.C. Paulson, Jr. “Object-Oriented Programming for Project Management Software.” Proceedings of the 7th International Symposium on Automation and Robotics in Construction. Bristol, England: Bristol Polytechnic. Jun. 1990. pp. 513-521.
[Froese 91]
Froese, T.M., and L.M. Waugh, “Project Management and Computers in the Year 2010.” Proceedings of the 1991 Annual Conference of the Canadian Society for Civil Engineering. Montreal, Canada: Canadian Society for Civil Engineering. May 1991. pp. 435-444. Also published as Technical Report No. 46, Center for Integrated Facility Engineering, Stanford University. 1991.
[Genesereth 92]
Genesereth, M.R. An Agent-Based Approach to Software Interoperability. Research Report LOGIC-91-6, Logic Group, Dept. of Computer Science, Stanford University. 1992.
[Gielingh 88]
Gielingh, W. General AEC Reference Model (GARM). ISO TC 184/SC4/WG1 doc. 3.2.2.1, TNO report Bi-88-150. Delft, Netherlands. Oct. 1988.
[Gielingh 91]
Gielingh, W., and F.P. Tolman. “Information Integration in the Building and Construction Industries.” Microcomputers in Civil Engineering. Vol. 6, No. 4 (1991). pp. 329-334.
[Grobler 88]
Grobler, F. Object-Oriented Data Representation for Unified Construction Project Information. Ph.D. Thesis, Dept. of Civil Engineering, University of Illinois at Urbana-Champaign. 1988.
[Grobler 89]
Grobler, F., and S. Kim. “Symbolic Unified Project Representation (SUPR) Model: An Environment for Automated Construction,” Proceedings of the 6th International Symposium on Automation and Robotics in Construction. Burlingame CA. Jun. 1989. pp. 545-552.
263
List of References
[Hansen 87]
Hansen, Soren, "Hardware & Software Implications on: PM and the Computer: The Year 2001," Project Management Journal, Vol.18, No. 3, Aug. 1987. pp. 47-48.
[Hartman 87]
Hartman, R. “Masterformat Numbers Are For More Than Specs.” Construction Specifier. Vol. 44, No.1 (Jan 1991). pp. 102-108.
[Hendrickson 87]
Hendrickson, C., C. Zozaya-Gorostiz, D. Rehak, E. Baracco-Miller, and p. Lim. “Expert System for Construction Planning.” Journal of Computing in Civil Engineering. Vol. 1, No. 4 (Oct. 1987). pp. 253-269.
[Howard 92]
Howard, H.C., J.A. Abdalla, and D.H. Phan. “A PrimitiveComposite Approach for Structural Data Modelling,” Journal of Computing in Civil Engineering. Vol. 6, No. 1 (Jan. 1992). pp. 19-40.
[Howard 89a]
Howard, H.C., R.E. Levitt, B.C. Paulson, Jr., J.G. Pohl, and C.B. Tatum. “Computer-Integrated Design and Construction: Reducing Fragmentation in the AEC Industry.” Journal of Computing in Civil Engineering. Vol. 3, No. 1 (Jan. 1989). pp. 18-32.
[Howard 89b]
Howard, H.C., and D. Rehak. “KADBASE: A Prototype Expert Systems-Database Interface for Engineering Systems,” IEEE Expert, Vol. 4, No. 3 (Fall 1989). pp 65-76.
[Ibbs 85]
Ibbs, C.W., Jr. Proceedings of a Workshop for the Development of New Research Directions in Computerized Applications to Construction Engineering and Management Studies. Dept. of Civil Engineering, University of Illinois at Urbana-Champaign. 1985.
[Ibbs 87]
Ibbs, C.W., Jr. D.B. Ashley, J.M. Neil, and F.W. Feiler. “An Implementation Strategy for Improving Project Control Systems.” Project Controls: Needs and Solutions. New York: American Society for Civil Engineers. 1987. pp. 101-112.
[Ingari 91]
Ingari, Frank. “The Object Database Market: Stranger Than It Needs To Be?” Journal of Object-Oriented Programming. Vol. 4, No. 4 (Jul./Aug. 1991). pp. 16-18.
[Integrated 81]
Integrated Computer Aided Manufacturing (ICAM). Function Modeling Manual (IDEF0). Materials Laboratory, AF Wright Aeronautical Laboratories. Jun. 1981.
[Intellicorp 88]
Intellicorp, Inc. KEE User’s Guide (version 3.1). Pub. No. K3.1UG-1. Mountain View CA. May 1988.
[Intellicorp 90]
Intellicorp, Inc. ProKappa User’s Guide (version 1.1). Pub. No. PK1.1-UG-1. Mountain View CA. Nov. 1990.
264
List of References
[Ito 89]
Ito, K., Y. Ueno, R.E. Levitt, and A. Darwiche. Linking Knowledge-Based Systems to CAD Design Data with ObjectOriented Building Product Model. Technical Report No. 17, Center for Integrated Facility Engineering, Stanford University. 1989.
[Kaiser 90a]
ICF Kaiser Engineers, Inc. IEST Interactive Estimating System, User’s Reference Manual (version 2.30). Oakland CA. 1990.
[Kaiser 90b]
ICF Kaiser Engineers, Inc. KEMS, Kaiser Engineers Management System, User’s Reference Manual (version 6.0). Oakland CA. 1990.
[Kartam 89]
Kartam, N. Investigating the Utility of Artificial Intelligence Techniques for Automatic Generation of Construction Project Plans. Ph.D. Thesis, Dept. of Civil Engineering, Stanford University. 1989.
[Kartam 91]
Kartam, N., and T. Tongthong. “Integration of CAD and knowledge-based systems. An AI architecture.” Preparing for Construction in the 21st Century. New York: American Society of Civil Engineers. 1991. pp. 324-329.
[Kifer 89]
Kifer, M., and J. Wu. “A Logic for Object-Oriented Logic Programming (Maier's O-logic Revisited).” Proceedings of the Eighth ACM SIGACT-SIGMOD-SIGART Symposium on Principles of Database Systems. New York: Assoc. for Computing Machinery. 1989. pp. 379-393.
[Killen 89]
Killen, T.S. “Dynamics of Automation.” Proceedings of the First Symposium of the Center for Integrated Facilities Engineering. Center for Integrated Facilities Engineering, Stanford University. 1989.
[Kim 90]
Kim, W. Introduction to Object-Oriented Databases. Cambridge, MA: The MIT Press. 1990.
[Kim 91]
Kim, W. “Object-Oriented Database Systems: Strengths and Weaknesses.” Journal of Object-Oriented Programming. Vol. 4, No. 4 (Jul./Aug. 1991). pp. 21-29.
[Kunz 88]
Kunz, J.C. “Model Based Reasoning in CIM,” Intelligent Manufacturing: Expert Systems and the Leading Edge in Production Planning and Control. Reading MA: Addison-Wesley. 1988.
[Lavakare 89]
Lavakare, A., and H.C. Howard. Structural Steel Framing Data Model. Technical Report No. 12, Center for Integrated Facility Engineering, Stanford University. 1989.
[Law 90]
Law, K.H., T. Barsalou, and G. Wiederhold. “Management of Complex Structural Engineering Objects in a Relational Framework.” Engineering with Computers. Vol. 6, No. 2 (Spring 1990). pp. 81-92. 265
List of References
[Levitt 87a]
Levitt, R.E. “Expert Systems in Construction: State of the Art.” Expert systems for Civil Engineers: Technology and Application. New York: The American Society for Civil Engineers. 1987. pp. 85-112.
[Levitt 87b]
Levitt, R.E., and J.C. Kunz. “Using Artificial Intelligence Techniques to Support Project Management.” Artificial Intelligence in Engineering Design, Analysis and Manufacturing. Vol. 1, No. 1 (1987). pp. 3-24.
[Levitt 90]
Levitt, R.E. Merging Artificial Intelligence with CAD: Intelligent, Model-Based Engineering. Twenty-Eigth Henry M. Shaw Lecture, Dept. of Civil Engineering, North Carolina State University. 1990.
[Lichtenberg 74]
Lichtenberg, S. Project Planning - a Third Generation Approach. Polyteknisk Forlag: Copenhagen. 1974.
[Livingston 90]
Livingston, D. “Engineering Giant Upgrades to 3-D CAD.” Systems Integration. Oct. 1990.
[Logcher 87]
Logcher, R.D. “Adding Knowledge Based Systems Technology to Project Control Systems,” Project Controls: Needs and Solutions. New York: American Society for Civil Engineers. 1987. pp. 7687.
[Logcher 91]
Logcher, R.D. “What Are We Doing Wrong?” Civil Engineering Research Foundations, National Civil Engineering Research Needs Forum. 1991.
[Mahoney 90]
Mahoney, J.J., C.B. Tatum, and K. Kishi. Construction Site Applications of CAD. Technical Report No. 36, Center for Integrated Facility Engineering, Stanford University. 1990.
[Marshall 87]
Marshall, G., T.J. Barber, and J.T. Boardman. “Methodology for Modelling a Project Management Control Envinment.” IEE Proceedings. Part D, Vol. 134, No. 4 (Jul. 1987). pp. 287-300.
[Nasrallah 89]
Nasrallah, W. Practical Issues in Message-Passing Style CPM Scheduling. S.M. Dissertation, Dept. of Civil Engineering, Massachusetts Institute of Technology. 1989.
[NeXT 90]
NeXT Computer, Inc. NeXTstep Concepts (version 2.0). Redwood City, CA. 1990.
[Paulson 72]
Paulson, B.C., Jr. “Man-Computer Concepts for Planning and Scheduling,” Journal of the Construction Division. Vol. 98, No. CO2 (Sep. 1972). pp. 275-286.
[Paulson 73]
Paulson, B.C., Jr. “Project Planning and Scheduling: Unified Approach,” Journal of the Construction Division. Vol. 99, No. CO1 (Jul. 1973). pp. 45-58.
266
List of References
[Paulson 75]
Paulson, B.C., Jr. Continuing research in the Development of Interactive Man-computer Systems for Engineering-construction Projects. Technical Report No. 200, The Construction Institute, Dept. of Civil Engineering, Stanford University. 1975.
[Paulson 85]
Paulson, B.C., Jr. “Automated Control and Robotics for Construction.” Journal of Construction Engineering and Management. Vol. 111, No. 3 (Sep. 1985). pp. 190-207.
[Paulson 87]
Paulson, B.C., Jr., and R.E. Levitt. “New Directions in Construction Engineering and Management.” Proceedings of the US-Korea Joint Seminar/Workshop on Critical Engineering System . (NSF / KOSEF), Seoul, Korea. May 1987. pp. 287-301.
[Phan 90]
Phan, D.H., and H.C. Howard. Evaluation of the Structural Steel Framing Data Model. Technical Report No. 41, Center for Integrated Facility Engineering, Stanford University. Nov. 1990.
[Rasdorf 91]
Rasdorf, W.J., and O.Y. Abudayyeh. “Cost- and schedule-control integration. Issues and needs.” Journal of Construction Engineering and Management. Vol. 117, No. 3 (Sep. 1991). pp. 486-502.
[Riggs 87]
Riggs, L.S. “Project Control Techniques,.” Project Controls: Needs and Solutions. New York: American Society for Civil Engineers. 1987. pp. 11-25.
[Russell 91]
Russell, A.D. “Contractor Sponsored Expert System.” Preparing for Construction in the 21st Century. New York: American Society of Civil Engineers. 1991. pp. 375-380.
[Sanvido 90]
Sanvido, V.E. An Integrated Building Process Model. Technical Report No. 1, Computer Integrated Construction Research Program, Dept. of Architectural Engineering, The Pennsylvania State University, University Park PA. Jan. 1990.
[Schank 77]
Schank, R.C., and R.P. Abelson. Scripts, Plans, Goals, and Understanding. Hillsdale NJ: Lawrence Erlbaum. 1977.
[Schenck 90]
Schenck, Douglas (ed). EXPRESS Language Reference Manual. ISO TC 184/SC4/WG1, IS 10303:Part 11., Doc. N496 (available from NIST, Gaithersburg MD). May 1990.
[Skibniewski 89]
Skibniewski, M.J., and J.S. Russell. “Robotic applications to construction.” Cost Engineering. Vol. 31, No. 6 (Jun. 1989). pp. 10-18.
[Skibniewski 90]
Skibniewski, M.J. “On the Use of Microcomputers by Small Contractors: Implications of a survey and Recommendations for the Future.” Project Management Journal. Vol. 21, No. 1 (Mar. 1990). pp. 25-31.
267
List of References
[Sriram 89]
Sriram, D., R.D. Logcher, N. Groleau, and J. Cherneff. Dice: An Object Oriented Programming Environment for Cooperative Engineering Design. Technical Report No: IESL-89-03, Intelligent Engineering Systems Laboratory, Dept. of Civil Engineering, Massachusetts Institute of Technology. 1989.
[Sriram 90]
Sriram, D., R. Logcher, A. Wong, and S. Ahmed. A case study in Computer-Aided Cooperative Product Development. Technical Report No: IESL-90-01, Intelligent Engineering Systems Laboratory, Dept. of Civil Engineering, Massachusetts Institute of Technology. 1990.
[Teicholz 87]
Teicholz, P.M. “Current Needs for Cost Control Systems.” Project Controls: Needs and Solutions. New York: American Society for Civil Engineers. 1987. pp. 47-57.
[Thomas 89]
Thomas, D. “What’s in an Object?” Byte. Vol. 14, No. 3 (Mar. 1989). pp. 231-240.
[Timberline 89]
Timberline Software Co. Precision Primavera Integrator, (Users Documentation). Beaverton OR. 1989.
[Timberline 91]
Timberline Software Co. Precision CAD Integrator, (Users Documentation). Beaverton OR. 1991.
[Timberline 90]
Timberline Software Co. Precision Estimating Plus, (Users Documentation). Beaverton OR. 1991.
[Thisner 87]
Thisner, A., P.M. Teicholz, and G. Havas. “PM and the Computer: The Year 2001.” Project Management Journal. Vol. 18, No. 3 (Aug. 1987). pp. 39-45.
[Warthen 88]
Warthen, B. “PDES—A CAD Standard for Data Exchange,” UNIX World. Dec. 1988. pp.103-104.
[Waugh 90]
Waugh, L.M., and T.M. Froese. “Constraint Knowledge for Construction Scheduling.” Proceedings of the First International Conference on Expert Planning Systems. IEE Conference Publication Number 322. 1990. pp. 114-118.
[Wegner 89]
Wegner, P. “Learning the Language.” Byte. Vol. 14, No. 3 (Mar. 1989). pp. 245-253.
[Yamazaki 91]
Yamazaki, Y. “Integrated design and construction planning by knowledge-based systems.” Preparing for Construction in the 21st Century. New York: American Society of Civil Engineers. 1991. pp. 400-405.
[Yau 91]
Yau, N.-J., J.W. Melin, J.H. Garrett, and S. Kim. “Integrating the processes of design, scheduling and cost estimating within an object-oriented environment.” Preparing for Construction in the 21st Century. New York: American Society of Civil Engineers. 1991. pp. 342-347.
268