Open Collections

UBC Theses and Dissertations

UBC Theses Logo

UBC Theses and Dissertations

A formalism for object-based information systems development Takagaki, Ken 1990

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

Item Metadata

Download

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

Full Text

A F O R M A L I S M F O R O B J E C T - B A S E D I N F O R M A T I O N S Y S T E M S D E V E L O P M E N T By Ken Takagaki A THESIS SUBMITTED IN PARTIAL F U L F I L L M E N T OF T H E REQUIREMENTS FOR T H E D E G R E E OF D O C T O R OF PHILOSOPHY in T H E FACULTY OF G R A D U A T E STUDIES C O M M E R C E We accept this thesis as conforming to the required standard T H E UNIVERSITY OF BRITISH COLUMBIA March, 1990 © Ken Takagaki, 1990 In presenting this thesis in partial fulfilment of the requirements for an advanced degree at the University of British Columbia, I agree that the Library shall make it freely available for reference and study. I further agree that permission for extensive copying of this thesis for scholarly purposes may be granted by the head of my department or by his or her representatives. It is understood that copying or publication of this thesis for financial gain shall not be allowed without my written permission. Department DE-6 (2/88) Abstract Most current approaches to Information Systems Development (ISD) tend to derive from past experience and practice, rules of thumb and technology trends. The lack of theoret-ical foundations hinders the systematic development and evaluation of new ISD method-ologies. The research undertaken in this thesis addresses this issue by proposing a formal, theory-based model, Ontology/Object-Based Conceptual Modelling (OBCM) , for concep-tually representing IS applications. The formalism is novel in that it is grounded in first principles derived from metaphysics, in particular the system of Ontology developed by Mario Bunge. Underlying this approach is the premise that an Information System is a model of reality and that model should be therefore rooted in a theory of reality, ie. a metaphysics. As a result, basic assumptions in reality such as thing, substance, property, attribute, time, state and change are explicitly and rigorously addressed. O B C M features an ontologically well-defined construct, "object", which is used to directly represent enti-ties in reality, thus lending theoretical credence to the so-called object-oriented paradigm found in recent programming languages and databases. In addition, the thesis presents a framework, Ontology/Object-Based Information System (OBIS), for systems implementation based on this model. This framework di-rectly implements the object construct so that it can be immediately utilized by the information systems user in a "direct manipulation" style of end-user interaction. Fur-ther, OBIS strives for a single, homogeneous concept of system operation drawn from ontology rather than in terms of IS or computing technology. In principle, this one concept can be applied to any object in the IS, this simplifying the understanding and use of the Information System. In this way, the model attempts to unify the analysis, i i implementation and user-interface aspects of Information Systems Development, thereby reducing the so-called "semantic gap" which has often been observed between the reality of the application and its final implementation in an IS. A "proof of concept" prototype is described which illustrates the main principles and explores practical applications of the proposed model. This prototype is implemented as a single, stand-alone "shell" which can be used to support a wide variety of applications as well as providing the basis of a rapid prototyping or C A S E tool. The prototype is used to implement sample problems including the well-known IFIP Working Conference problem, thus demonstrating the feasibility of the overall approach. ui Table of Contents Abstract ii List of Figures xiii Acknowledgement xv 1 Introduction 1 1.1 Information Systems Development and Conceptual Modelling 1 1.2 Object-Oriented Modelling 3 1.3 Research Objectives and Motivation 6 1.3.1 Formalization of Object-Oriented Conceptual Modelling 6 1.3.2 Operationalization of Object-Oriented Information Systems . . . . 10 1.3.3 Some Caveats 11 1.4 Research Methodology 13 1.5 Expected Contributions 14 1.6 Thesis Overview and Organization 16 2 Conceptual Modelling and Abstraction 17 2.1 Programming Languages 18 2.1.1 Programming Abstraction 18 2.1.2 Object-Oriented Programming 20 2.2 Semantic Data Modelling 23 2.2.1 Semantic Data Models 23 iv 2.2.2 Abstraction Mechanisms 26 2.2.3 Object-Oriented Data Models 28 2.3 Systems Development Methodologies 30 2.3.1 Early Approaches to Information Systems Modelling 30 2.3.2 Modelling an Universe of Discourse 30 2.3.3 Object-Oriented Software Engineering 33 2.3.4 Object-Oriented Methodologies 33 2.4 Discussion 35 2.4.1 Conceptual Modelling and the Object Paradigm 35 2.4.2 Issues in Object-Oriented Modelling 36 2.4.3 Theoretical Foundations for Object-Oriented Modelling 38 3 A n Ontological Basis for Conceptual Modelling 44 3.1 Motivation for the Ontological Basis 44 3.2 Previous Work with Ontological Formalisms in Information Systems . . . 47 3.2.1 Stamper 47 3.2.2 Wand and Weber Ontological Formalisms 49 3.2.3 Wand's Ontological Model of Objects 53 3.3 Bunge's Ontology 55 3.3.1 Basic Assumptions 56 3.3.2 Substance, Association and Composition 57 3.3.3 Form 61 3.3.4 Thing and Model Thing 64 3.3.5 Laws and Lawful State Space , 66 3.3.6 Class and Natural Kinds 67 3.3.7 Change, Event and Interaction 69 v 3.3.8 Spacetime 74 3.4 Summary 7 6 4 Ontology-Based Conceptual Model - O B C M 77 4.1 Background 7 7 4.2 O B C M - Ontology-Based Conceptual Model 82 4.3 Surrogate 82 4.3.1 Definition 82 4.3.2 Composite Surrogates 83 4.3.3 Surrogate Semantics 84 4.4 Model Object 85 4.4.1 Definition 85 4.4.2 Multiple Views 91 4.4.3 Example 91 4.5 Object 93 4.5.1 Definition 93 4.5.2 Example 93 4.5.3 Object Composition 95 4.5.4 Object Interaction 99 4.6 A n O B C M Notation 100 4.6.1 Names 101 4.6.2 Basic Object Functions 102 4.6.3 Object Sets 103 4.7 A Visual Notation for O B C M 106 4.7.1 Example 108 4.8 O B C M and Semantic Modelling - Comparative Analysis 110 vi 4.8.1 Pre-Defined vs Law-Based Models I l l 4.8.2 OBCM and Entity-Relation Models 112 4.8.3 Cardinality Constraints in OBCM 113 4.8.4 Classification and Generalization 113 4.8.5 Aggregation 115 4.8.6 Association 116 4.9 Summary 117 5 Object-Based Information Systems - An Implementation Framework 119 5.1 Conceptual Framework 119 5.1.1 OBIS - Definition 119 5.1.2 OBIS Design Approach 122 5.2 The OBIS User Interface 122 5.2.1 Direct Manipulation Style 122 5.2.2 End-User Interface 123 5.2.3 View 125 5.2.4 Change 126 5.3 Extended Example 135 5.3.1 The OBIS Design Process 136 5.3.2 Order Example - Overview 137 5.3.3 Customers 137 5.3.4 Products 141 5.3.5 Orders 144 5.3.6 Order Entry System 147 5.3.7 Order Example - Operation 152 5.4 Summary 154 vn 6 An OBIS Prototype Implementation 156 6.1 Role of the Prototype 156 6.1.1 Choice of Prototype Language 157 6.1.2 The Smalltalk Programming Language 158 6.2 The Implementation Framework 159 6.2.1 A Smalltalk Programming Protocol for OBIS 159 6.2.2 Prototype Operation - Overview 160 6.2.3 Prototype User Interface 161 6.2.4 OBIS Prototype Shell 164 6.3 Implementation Example 173 6.3.1 M O C 173 6.3.2 Prototype Operation 178 6.3.3 The OBIS Implementation Process 181 6.4 Summary 182 7 IFIP Working Conference Case Study 185 7.1 Requirements Analysis 186 7.2 O B C M Interpretation of the IFIP Case 188 7.2.1 Simple Objects 189 7.2.2 Composite Objects 190 7.2.3 Committees and Conferences 191 7.3 IFIP Case Study - Operation 192 7.3.1 Populating the IFIP 193 7.3.2 Programme Committee Activities 193 7.3.3 Organizing Committee Activities 194 7.3.4 Implementation of the IFIP Case Study 195 vm 7.4 O B C M / I S and Other ISD Approaches 196 7.4.1 Origin and Experience 198 7.4.2 Development Process 198 7.4.3 Model 199 7.4.4 Iteration and Test 199 7.4.5 Representation Means 199 7.4.6 Documentation 200 7.4.7 User Orientation 200 7.4.8 Tools and Prospects 200 7.5 Summary 200 8 Contributions and Extensions 202 8.1 Thesis Summary 202 8.2 Contributions 204 8.2.1 Theoretical Contributions 204 8.2.2 Practical Contributions 205 8.3 Future Extensions to the Research 206 8.3.1 Extensions and Improvements to O B C M / I S 206 8.3.2 Enhancements to the Ontological Basis 207 Bibliography 208 Appendices 217 A Bunge's Theorems 217 A . l T H E O R E M 1.1 217 A .2 T H E O R E M 1.2 2 1 7 A .3 T H E O R E M 1.3 • 2 1 7 ix B Smalltalk OBIS Prototype Shell 219 B . l O B C M / I S Primitives - OBIS 219 B.2 Windowing and Display Management - OBISForm 226 B.3 User Interface - OBISInterface 233 B . 4 M O C Subsystem - ModelObject 236 C Order Entry Example - OBIS Implementation 240 C. l Customers 240 C.2 Products 242 C.3 Orders 244 C. 4 Order Entry System 246 D The IFIP Working Conference Problem 249 D. l IFIP Working Conference Problem 249 D . l . l Background 249 D. l .2 Information System to be Designed 250 D. l .3 Boundaries of System 251 D.2 O B C M Interpretation of the IFIP Case 251 D.3 Person 252 D.4 Author 253 D.5 Attendee 255 D.6 Referee 256 D.7 Text 257 D.8 Facility 258 D.9 Invitation Letter 259 D.10 Intent Letter 260 D . l l Paper 262 x D.12 Referee Report 2 f i 3 D.13 Programme Committee 265 D.14 Organizing Committee 267 D.15 Session 268 D.16 Working Conference 269 D. 17IFIP 2 7 1 E IFIP Working Conference Problem - OBIS Implementation 272 E. l Person 272 E.2 Author 2 7 3 E.3 Attendee 274 E.4 Referee 2 7 4 E.5 Text 2 7 $ E.6 Facility 2 7 6 E.7 Invitation Letter 2 7 7 E.8 Intent Letter 2 7 8 E.9 Paper 2 7 9 E.10 Referee Report 2 7 9 E . l l Programme Committee 2 8 1 E.12 Organizing Committee 2 83 E.13 Session 2 8 4 E.14 Working Conference 2 85 E. 15 IFIP 2 8 7 F Semantic Data Bases 2 8 8 F. l Kroenke and Dolan 2 8 8 F . l . l Object Properties 2 8 8 x i F.1.2 Object Categories 2 8 8 F.1.3 Objects and DataBase 289 F.2 A C M / P C M 289 F.2.1 Structure Modelling 289 F.2.2 Behaviour Modelling 290 F.2.3 Methodology 291 F.3 Prototype Activity Modelling System 291 F.3.1 Containment 291 F.3.2 Conditional Abstraction 292 F.3.3 Abstraction Support 292 G Figures 2 9 5 xii List of Figures 2.1 Different mechanisms for interrelating types 295 2.2 Object diagram 295 3.1 Semilattice generated by < 5, o, • , o > 296 3.2 Trajectory of a thing undergoing change 296 4.1 Relationships between the Reality being represented and the Information System 297 4.2 Different forms of composition. See Section 4.5.3 297 4.3 Two views of the (real) thing JOHN 298 4.4 A visual notation for objects 298 4.5 A specific object x0 299 4.6 A simple notation depicting change 299 4.7 The vehicle example in the visual notation of Chapter 4 300 4.8 Typical Entity-Relationship diagram 300 5.1 OBIS as composition of three objects 301 5.2 Display of objects via a technology. 301 5.3 OrderSystem as composition of orders, customers, and products 302 6.1 A Smalltalk-based OBIS implementation 303 6.2 The SmaUtalk Prototype Shell 303 6.3 A window onto a Smalltalk implementation of the object OrderSystem. . 305 6.4 Scanning fAComp and fPartOf 305 6.5 Scanning all objects of kind P R O D U C T in the composition of OrderEntry. 306 xiii 6.6 Adding customer and product to an order 306 6.7 History of an object 307 7.1 Visual notation of IFIP Working Conference Problem 309 7.2 Visual notation of PROGRAM COMMITTEE 309 7.3 Smalltalk implementation of IFIP 310 7.4 Accessing a paper and its text submitted to the Program Committee. . . 310 7.5 Two views of the real world thing JOHN, as AUTHOR and as PERSON. 311 xiv Acknowledgement It gives me great pleasure to acknowledge the many individuals who participated in the preparation of this dissertation. Without them, it would simply not have been possible. I freely acknowledge my special debt to Yair Wand who was generous both with his time and his ideas. The basic idea of the ontological approach came from him and his influence is evident throughout the thesis. Professor Richard Mattessich was responsible for rekindling my interest in basic philosophy and metaphysics. I learned much from him. Son Vuong and Carson Woo were the other two members of my supervisory committee and they supported me constantly throughout this project. I also wish to thank Jim Varah, A l Dexter, Paul Gilmore and Fred Lochovsky for their careful reading of the thesis and their many observations and suggestions. They have contributed significantly to the final result. Further, I am grateful for the professional and intellectual environment provided by the faculty and students of the MIS Division at the University of British Columbia. Finally, I thank Anita and Tetsu. I owe them everything. xv Chapter 1 Introduction The purpose of this thesis is to offer a contribution to a theory of object-oriented software development More specifically, this thesis proposes a new approach to Information Systems Devel-opment (ISD) involving the formalization and extension of the object-oriented paradigm to ISD. The result is an ISD model which emphasizes a single, well-defined, theory-based construct, object, which provides a central, unifying principle for the conceptual modelling, design, implementation and end-use of Information Systems. The model is an attempt to address two important issues in the development of Information Systems: (1) the need for suitable theories of Information Systems (IS), in particular for conceptual modelling, and (2) the desire to narrow the "semantic gap" between user views of IS applications and final working systems. This chapter introduces the issues, articulates the research problem, and presents the research plan followed in the thesis. 1.1 Information Systems Development and Conceptual Modelling The development of Information Systems encompasses a wide range of technical, orga-nizational, and social issues including individual and organizational behaviours, project management, data base design, documentation and software engineering. A vast collec-tion of tools, techniques and methodologies has accumulated over the years to assist IS 1 Chapter 1. Introduction 2 designers with this process. Nevertheless, the design and construction of complex infor-mation systems is still generally conceded to be difficult and error-prone [Sibley, 1986; Bubenko, 1986; Brooks, 1987]. The study and improvement of Information Systems Development, therefore, continues to be the subject of intensive research effort. One aspect of ISD which has attracted considerable interest is an approach to systems description known as conceptual modelling [Brodie et al., 1984; Kung k Solvberg, 1986]. Traditional ways of understanding and describing information systems usually involve concepts such as programs, processes, files, data flows and other computer-related con-structs. These are becoming recognized as being too remote from the problem domain, which typically consists of "real world" entities and phenomena such as people, products, services, and activities. The result is systems which are difficult to understand, validate and use [Brodie, Mylopoulos k Schmidt, 1984; Abbott, 1987]. Conceptual modelling, on the other hand, is based on the premise that an IS is, in part at least, an abstract model of some reality underlying the application. Its goal is to discover and refine modelling approaches which allow users and designers to de-scribe information systems in ways which are as "natural" to the application as possible, rather than in terms of the computer; that is, to narrow the "semantic gap" between the application reality and its implementation in an Information System. The value of conceptual modelling (also called reality modelling, semantic modelling and enterprise modelling) has been widely recognized [ANSI /X3/SPARC; Bubenko, 1980; Essink, 1986; Gibbs, 1985; Kung k Solvberg, 1986; Kung, 1983; Brodie et al., 1984]. For example, Kung k Solvberg [1986] describe the role of conceptual models as providing: • a common reference framework for users and system designers, ie. a communica-tions tool; • improved modelling of the reality underlying the application; Chapter 1. Introduction 3 • a blueprint for implementation; • a basis for validation; • documentation. And Gibbs [1985] suggests that conceptual models simplify the design of complex systems by providing a modelling methodology; give a high degree of logical independence, as is required by evolving applications; document the structure of a system at varying levels of detail; and aid the user in interpretation of data [p. 195]. In general, it has been observed that as the scope of computer-based information systems widens, applications become more complex and comprehensive, and the number of users expands, the value of conceptual models will continue to increase correspondingly [Bubenko, 1986]. 1.2 Object-Oriented Modelling This thesis explores the link between conceptual modelling and an evolving approach or paradigm in software development referred to as object-centered or object-oriented. The term 'object-oriented' has been used in a number of contexts including program-ming languages, database, and knowledge representation. Perhaps the best established use of the term to date is in software engineering and the tradition of the object-oriented programming languages such as Simula, Smalltalk and its derivatives [Robson &; Gold-berg, 1981; Stefik & Bobrow, 1986; Goldberg k Robson, 1984; Cox, 1986; Booch, 1986]. To oversimplify somewhat, an "object" in this context is a software entity which combines both data, ie. static information, and allowable operations on this data, ie. dynamics or behaviour, into a single construct. Chapter 1. Introduction 4 There also exists, however, a more general view of object-orientation: that of a frame-work for direct and natural representations of the world. In this view, "objects" are seen as a convenient way of directly describing entities in reality. Greenspan expresses the concept as follows: In [an object-centered] framework, concepts/entities of the world are repre-sented by units of description called objects. The creation, modification, and ma-nipulation of objects are taken to represent the behaviour of their counterparts in the world [1984, p. 3]. In both the programming and the more general representation contexts, important techniques have been developed for dealing with objects such as their interrelation by properties and their organization into classes and class hierarchies. Other techniques allow objects to inherit properties or behaviours along these class hierarchies. These fun-damental ideas also appear in Artificial Intelligence techniques such as semantic networks, frames and related knowledge representation schemes as well as in Object-Oriented Pro-gramming Languages, Semantic Data Models and other forms of information modelling [Quillian, 1968; Greenspan, 1984; Fikes k Kehler, 1985; Gibbs, 1985]. The idea of directly representing real-world constructs as software "objects" has led to a growing appreciation of the object paradigm as a powerful model for software and databases [Greenspan, 1984; Borgida, Mylopoulos &: Wong, 1984; Nierstrasz, 1985; Gibbs, 1985; Tsichritzis, 1985; Tsichritzis et al., 1986]. For example, ideas such as ob-ject classification and inheritance of properties along class hierarchies appear to have epistemological1 parallels in how we organize knowledge about the world. For these and other similar reasons, the object-oriented approach has been described as an important development in narrowing the semantic gap between the human understanding of a real 1That is, theories of how humans understand and organize knowledge. Chapter 1. Introduction 5 world application and the information system as implemented in the computer. Brooks [1987], for example, views object-oriented programming as allowing ...the designer to express the essence of the design without having to express large amounts of syntactic material that add no information content. Danforth and Tomlinson [1988] have pointed out how object-oriented language concepts make possible ...a natural connection between the formal, extensional objects represented by a program and their concrete, intensional representations with memory or a file sys-tem [p. 33]. And Wand [1989] poses the question, Is the emergence of the object paradigm an empirical indication that humans find it easier to describe perceptions of the world through the notion of object? This growing interest in exploiting the object paradigm for abstract, high-level sys-tems and software description is evident in a wide range of research contexts including programming languages [Brookes, 1987; Shriver & Wegner, 1987; Danforth &; Tomlinson, 1988], semantic database modelling, [Banerjee et al., 1987; Fishman et al., 1987; Hull &; King, 1987], office systems modelling [Tsichritzis et al., 1987; Nierstrasz, 1985; Woo, 1988] and software engineering [Booch, 1986; Cox, 1986]. This thesis follows in the footsteps of this research by extending the object paradigm to the ISD process, first by providing an appropriate theoretical context and second, by formalizing an approach to object-oriented Information Systems Development. A concept of object is proposed which can be transported intact from the conceptual model through to the implementation and end-use of the resulting IS. Chapter 1. Introduction 6 1.3 Research Objectives and Motivation The overall goal of the research can be expressed in the following way: To define and formalize a theory-based, object-oriented metamodel 2 for de-scribing and developing Information Systems. To accomplish this goal, this thesis focuses on two questions. • Can the intuitions in the object paradigm be sufficiently formalized into a theory-based, Conceptual Modelling scheme for Information Systems Development? • Can such a formalization be sufficiently operationalized to provide a single, unifying principle for the conceptual modelling, implementation and end-use of Information Systems? The motivation behind these questions and the research approach to their resolution are discussed below. 1.3.1 Formalization of Object-Oriented Conceptual Modelling The first objective of this thesis is to propose a theoretical basis for object-oriented conceptual modelling of information systems. Many well-known and useful conceptual modelling schemes have been proposed, in-cluding the semantic data models such as Entity-Relationship (ER) [Chen, 1976], Taxis [Borgida et al., 1984], R M / T [Codd, 1979], Semantic Database Model (SDM) [Hammer k McLeod, 1981], and the data abstractions of [Smith k Smith, 1977, 1979]. In addition, high-level modelling approaches have been proposed and incorporated into numerous 2That is, a model for describing other models. The term "metamodel" or "model" in this case is not meant as a formal mathematical or logical model, but rather a framework or approach for describing and developing information systems. Chapter 1. Introduction 7 design methodologies which support the systems development life cycle. Examples in-clude Jackson's Method (JSD) [Jackson, 1983; Cameron, 1986], N I A M [Verheijen k van Bekkum, 1982], A C M / P C M [Brodie k Ridjanovic, 1984], and P A M S [Flint, 1986]. Increasingly, however, the literature has observed that such models and methodolo-gies have proliferated and led to a profusion of analytical constructs such as transactions, activities, events, processes and data flows, but for the most part with little or no the-oretical justification [Bubenko, 1986; Floyd, 1986; Sibley, 1986; Wand k Weber, 1987; Wand, 1988; Brachman, 1983; Stamper, 1986]. This has resulted in a number of calls for a grounded theory of information systems development. For example, Floyd [1986] writes, Unfortunately, our understanding of the nature of systems development as a whole is haphazard at present and tends to be based on opinions and individual experiences rather than on systematic empirical research. In my view, the lack of a suitable theory about systems development as a whole explains many shortcomings in the existing methods [p. 31]. Bubenko [1986] has stated that "no generally accepted, workable theory of information systems and their development has evolved [p. 295]" and that ... there is a great need to 'clean up' this area [sic. IS methodologies] and to introduce and agree upon a coherent conceptual reference model and framework with formally well defined concepts, interactions, etc [p.307]. Wand [1988] observes It has been claimed that "hundreds, if not thousands" of methodologies for information systems development exist. Al l these methodologies have the same purpose - to support the successful development of information systems. Yet, there Chapter 1. Introduction 8 still exists no common set of criteria to compare methodologies. Indeed, when using different methodologies to describe the same system one may wonder how could there be such varying ways to describe it. Are the important constructs activities, processes, data flows, or objects [p. 1]? And Hull and King [1987] ask An interesting question is why the central components of semantic models - objects, attributes, ISA relationships - are necessarily the best mechanisms to use to enrich a data model [p. 210]. Similarly, despite its powerful intuitive appeal, the object paradigm remains largely an ad hoc collection of techniques, methodologies and philosophies rooted mainly in common sense practice, metaphor, and simple cognitive views of the world. The academic and practitioner literature reveals broad interpretations of the types of phenomena which can be described by the term "object" [King, 1989; Nierstrasz, 1987; Danforth Sz Tomlinson, 1988; Beech, 1987; Wegner, 1987]. Candidates have been pro-p403XwMih range in diversity from entity, activity, and assertions [Greenspan, 1984] to tangible things, roles, incidents, interactions, and specifications [Schlaer &: Mellor, 1988]. One practitioner-oriented reference lists as many as 18 separate object categories and dozens of associated relationships and rules [Ross, 1987]. Seemingly arbitrary distinctions are often made among object types such as concrete and abstract objects, independent objects and characteristic or dependent objects [Gibbs, 1985]. Organizational disciplines for objects such as inheritance have also met with controversy and many variations have been proposed including multiple and incomplete inheritance, classless inheritance, dele-gation, and specialization [Wegner, 1987; Sciore, 1989]. In addition, although the idea of representing phenomena in the world by the construct "object" is appealing, it is recognized that defining the correspondence between reality Chapter 1. Introduction 9 and objects is largely intuition-based [Brodie & Mylopoulos, 1986; Kent, 1977; Stamper, 1986; Brachman, 1983]. The limited research to date in this area has led to complex and profound issues involving cognitive and epistemological questions of how we perceive and organize knowledge of the world into representations. Increasingly, therefore, researchers have called for a better understanding of the fundamental philosophical and metaphysical premises assumed by object-oriented modelling. These include such basic concepts as entities, relations and basic issues of existence itself [Borgida, Mylopoulos & Wong, 1984; Stamper, 1986; Beech, 1987; Wegner, 1987]. The research undertaken in this thesis addresses the call for a stronger theory for IS development by proposing a Conceptual Modelling system which is grounded in a formal ontology or theory of reality. This approach is motivated by the premise that any IS conceptual modelling system claiming to represent an aspect of reality should be rooted first and foremost in a theory of reality, that is, a systematic, coherent and consistent metaphysics. Very briefly, the thesis develops a rigorous description of real world phenomena based on the system of ontology developed by Mario Bunge as part of his Treatise on Ba-sic Philosophy [1977, 1979]. Notions such as thing, property, state, event, process, and change as well as a schema for representing reality are defined in strict ontological terms, without reference to the technology and techniques of Information Systems. It is shown how ontology can provide an underlying theoretical foundation for a formal definition of the object construct which is suitable for conceptual modelling. The thesis then demon-strates how this construct can be directly utilized in the implementation and end-use of Information Systems. Chapter 1. Introduction 10 1.3.2 Operationalization of Object-Oriented Information Systems Information Systems have a dual nature, that of both representation and artifact. That is, systems are (1) in some significant sense, models or representations of some "slice of reality", and (2) a human-created artifact which participates in reality as an entity in its own right [Essinck, 1986; Jansson, 1985]. Given an understandable conceptual model of some application reality, it is desirable to transform the model into a working IS artifact as directly as possible while preserving intact the essence of the original conceptual representation. In contrast, in the traditional "waterfall" systems life-cycle model [Royce, 1987; Boehm, 1976], systems development proceeds from some abstract specification of the system to increasingly more "physical" implementation in a series of steps. A l l too often, however, the original semantics of the application are hidden or lost with each succeeding step. The result is a final system consisting of software code, data files, hardware and procedures which are difficult for developers to validate and end-users to comprehend and use. The proposed conceptual modelling system deals with this issue by supporting a direct operationalization of the object-oriented conceptual model into a working IS implementa-tion. The design of the implementation is based on the same ontological principles as the underlying conceptual model. The modelling construct object is implemented directly in software and in addition, is directly manipulable by end-users of the system. In this way, the model strives to provide a seamless, homogeneous path from the conceptual model to implementation and through to final end-use of systems based on this approach. To briefly anticipate the work to follow, the proposed model formally defines the systems description construct, object, which incorporates ontological concepts of identity, property, state, and change in a single, consistent, and unified entity. A n implementation approach is developed whereby the essence of the conceptual model is preserved in the Chapter 1. Introduction 11 implemented system. The object construct serves as both high level, conceptual modelling units and simultaneously as highly visible artifacts which can be directly manipulated by users of the information system much in the same manner as they would manipulate entities in reality. In this environment, the users interact directly with the same objects used in con-ceptual modelling rather than traditional, implementation-level constructs such as files, programs, records, and data fields. As a result, this model provides fundamental support for modes of user-interface whereby users have a sense of directly manipulating real-world objects when dealing with the system [Schneiderman, 1980]. This is in contrast to most other approaches to ISD where user-interface is typically treated as a separate implemen-tation issue in systems design with little or no intrinsic relation to the application. 1.3.3 Some Caveats At this point, it should be recognized that this notion of "seamless" or "homogeneous operationalization" makes a basic assumption concerning the value of conceptual mod-elling. Conceptual models are intended to facilitate IS users and developers in perceiving, understanding and describing information systems in terms appropriate to the application rather than in terms related to computer technology or implementation detail. Motivating conceptual models is a basic premise that as system descriptions, implementations and end-user interfaces become more and more separated from the concepts and terminology of the application domain, there is a greater danger of mistranslation and erroneous transformation, hence "semantic gaps", between the original problem and the final IS. The result is increased probability of system failure. This thesis accepts the need for high-level conceptual models. Its primary purpose is not to support or dispute the basic premise motivating such models. Nor does it attempt Chapter 1. Introduction 12 to demonstrate its corollary, ie. that the proposed framework will necessarily reduce the probability of IS failures. These issues are viewed as subjects of separate research efforts [Lyytinen, 1987]. What this research does attempt to show, however, is the feasibility of an ontology-based conceptual modelling scheme whose basic constructs can be preserved intact through problem analysis, conceptual design, implementation and end-use of an IS. It will do this via theory-building and "proof of concept" prototyping of systems which illustrate the homogeneous path from conceptualization to implementation and end-use. The thesis leaves the problem of evaluating the value and benefits of the proposed conceptual mod-elling approach to subsequent empirical validation and research. Further, it should be emphasized that the model presented in this thesis is not in-tended to be a complete ISD methodology. Practical methodologies are the cumulative result of much experience and development effort by numerous contributors. Popular methodologies are supported by many tools, training programs, project management techniques and a vast literature by both academic researchers and practitioners. As such, the development of an object-oriented ISD methodology is beyond the scope of this dissertation. On the other hand, this research does attempt to suggest foundation principles upon which future methodologies based on this model can be built. Further, it suggests specific tools, techniques and interfaces which appear suited to this approach. Finally, it should be noted that this research is based specifically on Bunge's system of ontology. Therefore, the resulting model has a "look and feel" which reflects his general approach, terminology and notation. Moreover, since this thesis builds on Bunge's system as given, with only minor modifications, the model will reflect any controversies associated with his work. In particular, it does not presume to revise Bunge nor to build a new ontology. Since the focus of this thesis to operationalize fundamental concepts of an Chapter 1. Introduction 13 existing ontology into an ISD model, such controversies do not affect the main thrust of this research. It is recognized, however, that ontology has a long and rich history with contribu-tions from many sources. Different ontological assumptions will very likely lead to quite different IS models. Further, existing ontologies, including Bunge's, are continually un-dergoing rethinking and reassessment. In this light, this thesis recognizes that the model proposed here is only one step toward other possible ontology-based models of Informa-tion Systems. 1.4 Research Methodology The research methodology includes model building, comparative analysis, prototype im-plementation and case study. Model building is directed at the first question: Can the intuitions in the object paradigm be sufficiently formalized into a theory-based, Conceptual Modelling scheme for information systems develop-ment? In addition, some comparative analysis will be performed to evaluate the sufficiency of the model against some of the more important modelling approaches. The second question Can such a formalization be sufficiently operationalized to provide a single, unifying principle for the conceptual modelling, implementation and end-use of Information Systems ? is interpreted as a feasibility question, and addressed by the prototype implementation and case study. The prototype and case study are seen as providing a test bed for experimentation, development and validation of the theoretic model. In this thesis, Chapter 1. Introduction 14 experience with the prototype played an important role in influencing and refining the model over several iterative cycles. In this respect, this research and in particular, the prototype, can be viewed as an empirical inquiry into conceptual modelling in the spirit advocated by Newell and Simon [1975]. According to Newell and Simon, each new machine and program that is built is an experiment. It poses a question from which lessons can be drawn. Thus, each experiment provides the potential for the "development of new basic understanding by empirical inquiry". [As] basic scientists we build machines and programs as a way of discovering new phenomena and analyzing phenomena we already know about...[The] phenom-ena surrounding computers are deep and obscure, requiring much experimentation to assess their nature. ...[As] in any science, the gains that accrue from such experimentation and understanding pay off in the permanent acquisition of new techniques; and [it] is these techniques that will create the instruments to help society in achieving its goals [1975, p. 114]. 1.5 Expected Contributions The overall contribution of this research is to the growing theoretical effort in conceptual modelling and information systems development in general and object-oriented systems in particular. A brief summary of the specific contributions from this line of research includes: • A novel, theory-based approach to the conceptual modelling of information systems derived from basic principles in ontology. This study responds to the cry for greater theoretical grounding in the study of information systems development [Bubenko, Chapter 1. Introduction 15 1986; Floyd, 1986; Sibley, 1986; Wand, 1988]. The ontology-based approach is ad-vanced as a means of providing a theoretical basis for the model and a framework for its evaluation. Further, since the model is based on a general system of meta-physics, it has the potential of being applicable to a wide range of systems rather than being limited to specific domains (such as office systems, business enterprises or transactions processing systems). • The formalization and extension of the object paradigm to information systems de-velopment The model contributes to recent interest in establishing better "philo-sophical" grounding for the object-oriented approach [Danforth and Tomlinson, 1988; Wegner, 1987]. • An ISD model which reduces the semantic gap between the IS and its underlying application reality. This study proposes a consistent and homogeneous construct which can be shared by analysts, programmers and end users of information sys-tems. Instead of the typical "waterfall" approach, the proposed model facilitates smooth, equivalence-preserving3 transformations from the initial conceptual model to final implementation, thereby narrowing the "semantic gap" between the user view of the application and its final implementation in a system. • A demonstration of a working prototype of IS based on the proposed model. Pro-gram development methodologies, tools and software engineering techniques for use with object-oriented programming languages are still emerging in the litera-ture and in the field. Although this thesis will not present a complete, working ISD methodology, the prototype implementation will illustrate applications of the proposed object-oriented model by designers, implementors and end-users. In this 3That is, the semantics of the original application are carried forward relatively intact in each stage of implementation. Chapter 1. Introduction 16 way, it contributes to the growing collection of practical tools, ideas and techniques for working with the object paradigm. This is the major practical contribution of the thesis. 1.6 Thesis Overview and Organization Chapter 2 of the thesis reviews the development of conceptual modelling and similar abstract, high-level systems description as found in the programming language, data base and software engineering literature. The review also examines the emergence and uses of the object paradigm as described in these various literatures. The common trend toward higher levels of abstract description through constructs such as object in all three research areas is analysed. Chapter 3 presents the ontological background underlying the proposed conceptual modelling approach. This chapter describes previous work in IS which consider ontolog-ical principles. Finally, the chapter summarizes the relevant aspects of Bunge's system of ontology. Chapter 4 formally presents the Object/Ontology-Based Conceptual Model ( O B C M ) . 4 Chapter 5 discusses the implementation framework for creating an Object/Ontology-Based Information System (OBIS) from the O B C M . A simple example is used to illustrate the principles. Chapter 6 describes a working prototype in the programming language Smalltalk. Chapter 7 presents an O B C M / I S solution to the IFIP Working Conference Problem [Olle, 1982]. Chapter 8 provides conclusions, summarizes the contributions of the thesis and sug-gests areas for future research. 4The model is both Ontology-based and Object-based. The acronyms OBCM and OBIS are intended to reflect both these aspects of the model. Chapter 2 Conceptual Modelling and Abstraction The scale and complexity of information systems have resulted in the drive toward higher, more abstract levels of system descriptions. In the common dictionary meaning of the term, abstraction is concerned with the "essence" of things apart from their concrete realizations or instances.1 The exact nature of this "essence" is elusive, as reflected in the various ways that abstraction is treated by different researchers in Computer Science and IS. For example, in Computer Science, Goguen et al. [1978] have identified three distinct (although closely related) meanings for the term: • A mathematical or conceptual model of something as in "abstract machine"; • The process of generalizing and thereby ignoring certain details, and; • Consideration of a concept apart from its representation or implementation, eg. "abstract data type". In the areas of Artificial Intelligence and Knowledge Representation, abstraction may refer to methods of representing the idea of something (as opposed to representing in-dividual things or sets of things) [Nilsson, 1980]. Abstraction in AI also can refer to techniques for summarizing and simplifying complex representations or descriptive nets [Winston, 1984]. 1Eg. ...the ideal or theoretical way of regarding things; consider apart from the concrete. Concise Oxford Dictionary. 17 Chapter 2. Conceptual Modelling and Abstraction 18 In Semantic Data Modelling, abstraction is generally viewed as a specific set of tools which provide organizational guidelines and support database design methodologies. In this regard, abstraction mechanisms based on epistemological 2 intuitions such as gen-eralization, aggregation, and classification have received considerable attention [Gibbs, 1986; Borgida et al., 1985]. This chapter reviews the background related to abstraction and conceptual modelling in the contexts of programming languages, data modelling, and information systems methodologies. It traces a common shift away from technology-based, implementation-specific levels of system description toward high-level, abstract descriptions in all three disciplines. In particular, it focuses on the emergence of object-oriented constructs as an important step in this process. There are a large number of object-oriented programming languages, data models and IS methodologies in existence. Hence, this chapter is selective in highlighting the major issues relevant to this thesis, namely how the concept of object is used in forming high level, abstract descriptions of reality. 2.1 P r o g r a m m i n g Languages 2.1.1 P r o g r a m m i n g A b s t r a c t i o n In the modern view of programming, the themes of high level modelling and abstrac-tion emerge as the principal means of dealing with and controlling the complexity of software development [Shaw, 1984a; Zilles, 1984; Liskov & Guttag, 1986]. Technical innovations such as object-oriented programming are seen as techniques for enhancing the expressiveness of programming languages. They represent significant steps in the "continuing abstraction of programs away from the computer and toward the problem 2That is, theories of how humans understand and organize knowledge. Chapter 2. Conceptual Modelling and Abstraction 19 [Abbott, 1987]". According to Abbott [1987], for example, in the early history of software development, programs were closely associated with the machines on which they ran. That is, appli-cation domain information tended to be invisible in the program which existed only as machine-level codes that reflected poorly, if at all, the nature of the application problem. Symbolic and high-level languages, macros and procedures, data structures, data types, domain-oriented languages, and so forth, gradually freed software from dependence on underlying hardware and permitted higher, more conceptual ways of expressing applica-tion domain information in programs. As a result, this encouraged the idea of regarding programs not as simply sequences of codes tied to some underlying hardware, but also as representations or models of a problem. In modern programming languages, there is an emphasis on techniques for modelling the application through a many-to-one mapping whereby certain details are ignored and similarities highlighted. In this way, complex problems are converted into simpler ones. In addition, where possible, details of implementation are ignored to allow implementation-independent descriptions of programs and program objects. These ideas and approaches have been generally refered to as programming abstractions. According to this view, "good" abstractions emphasize significant information and suppress irrelevant or inap-propriate details [Shaw, 1984a; Shaw, 1984b]. Some of the earliest software abstraction techniques centered around functions and procedures. For example, Liskov and Guttag [1986] distinguish between abstractions such as parameterization 3 and specification.4 3The abstraction of a set (potentially infinite) of computational instances by binding the formal parameters of a single program text an arbitrary number of times to actual parameters or arguments at run time. 4The use of a formal specification language or informal program comments or "meaningful" names and labels to hide the details of underlying implementation from the user during the design of the program. Chapter 2. Conceptual Modelling and Abstraction 20 Other programming abstractions are designed to reduce the difficulty of software con-struction by providing new ways of expressing the application in some virtual machine defined by the programming language. For example, procedural abstraction permits the extension of the virtual machine by adding new operations as required by the application problem. Data abstraction allows the virtual machine to be enhanced with user-specified data objects and operation sets characterizing their behaviour. Overall control of proce-dures over data objects is conveniently expressed by familiar iteration or control abstrac-tions such as if-then-else, for all-do, for each-do, and while-do [Shaw, 1984a; Shaw, 1984b; Liskov k Guttag, 1986]. Together with the emergence of high-level and domain-oriented languages, these tech-niques can be viewed as a means of freeing computational models from underlying hard-ware architectures, providing the means of expressing programs in domain terms, and generally establishing programs as objects of study independent of the hardware on which they executed [Abbott, 1987]. 2.1.2 Object-Oriented Programming The development of abstract data types (ADT) and object-oriented programming rep-resents a further important step toward the expression of programs in problem-domain terms and constructs. These concepts allow the creation of program units defined by a name, a set of possible values, and a set of operations rather than storage structures, program text, and other details of implementation [Brooks, 1987]. The virtual machine can thereby be populated with software units which, in theory, can be designed to reflect the static and behavioural characteristics of entities in the application domain. The goal is to improve the programmers' ability to deal with the essence of the problem and ignore those syntactic and machine-oriented issues which are not directly related to the problem at hand. Languages which stress these concepts are Chapter 2. Conceptual Modelling and Abstraction 21 generally known as object-oriented. There exists a widely acknowledged confusion surrounding the term object-oriented programming language (OOPL) [Nierstrasz, 1986; Hailpern k Nguyen, 1987; Stefik k Bobrow, 1986; Pascoe, 1986]. The term object-orientated has not always been clearly distinguished from associated concepts such as abstract data types, information hiding, dynamic binding, inheritance, and class hierarchies. The literature on the topic has applied the term to a variety of languages including Smalltalk, Simula, Ada, and Modula [Stefik k Bobrow, 1986]. Object-related extensions and support have also been claimed for a large number of existing, more conventional languages including Pascal [Jacky k Kalet, 1987], Fortran [Isner, 1982], C [Cox, 1986; Stroustrup, 1986], Lisp [Stefik k Bobrow, 19861 and even C O B O L [Bassett, 1987]. Stefik k Bobrow [1986] in their 1986 survey on the topic have estimated that over fifty languages exist which purport to be object-oriented. Nierstrasz [1987] stresses that object-orientation is an approach rather than a set of specific language constructs. He identifies data abstraction, independence, message-passing paradigm, inheritance, homogeneity and possibly concurrency as hallmarks of this approach. Pascoe [1986] considers information hiding, data abstraction, dynamic binding, and inheritance as the critical of object-oriented languages. Wegner [1987] lists seven "dimensions for objects-based language design": objects, classes or object types, inheritance, strong typing, data abstraction, concurrency, and persistence. He applies the term "object-oriented" only to those languages which possess the first three features, ie. objects, classes and inheritance, thus narrowing the use of the term. According to this definition, objects are considered to consist of a set of operations and a state that remembers the effects of the operations. Classes specify an interface for operations and serve as templates for object instances. Class inheritance is viewed as a mechanism for relating certain classes, ie. inheriting classes called subclasses and Chapter 2. Conceptual Modelling and Abstraction 22 inherited classes called superclasses. Regardless of differences in terminology, the ideas behind object-orientation have been applied against many problem areas in software engineering and programming. The local-ization, or encapsulation, of data and operations into a single unit is said to promote more effective modularization.of programs [Cox, 1984; Cox, 1986]. Object-oriented program-ming (OOP) has been claimed to smooth program design and implementation [Halbert & 0'Brian, 1987; Wegner, 1987; Booch, 1986]. Object-oriented languages have also been proposed to address issues in reusability [Meyer, 1987; Woodfield et al., 1987], program readability [Goldberg, 1987], experimental prototyping [Diederich & Milton, 1987], and user interaction, particularly iconic interfaces [Cox &; Hunt, 1986; Ledbetter & Cox, 1985]. Object-oriented programming languages have stimulated much research interest with respect to their conceptual modelling potential. For example, data abstraction, a cor-nerstone of object-orientation, provides two key modelling concepts: (1) type, a precise characterization of structural or behavioural properties shared by a collection of entities; and (2) identity, whereby a specific instance (of a type) can be distinguished from all other instances. Some researchers have viewed abstract data types (ADT) as an algebra, ie. a collection of types together with a family of operations closed upon those types, capable of capturing much of the behavioural semantics of an application [Deutsch, 1981; Zilles, 1984; Goguen et al., 1978]. Object-orientation research appears to have shifted attention away from many tradi-tional concerns in programming (eg. data structures, algorithms and proofs of correct-ness) and toward other issues such as type theories, object classification, class hierarchies and class inheritance [Halbert & O'Brian, 1987; Wegner, 1987; Beech, 1987]. For in-stance, Wegner [1987] has suggested a possible new basis for the study and analysis of Chapter 2. Conceptual Modelling and Abstraction 23 programming, one which stresses the historical development of hierarchical class struc-tures and incremental evolution of individuals and classes in the domain of discourse. The description of programs by their derivation history rather than by their execution properties has become a central goal of software engineering... Since historical evolution more accurately reflects the intellectual and social processes of program development than proofs of functional correctness, its formalization might identify primitives and inference rules more relevant to software technology than those of current program verification systems. Such formalization presents formidable problems and is still in its infancy. Object-oriented programming pro-vides a starting point for a technology of evolutionary program development... [p. 482]. 2.2 Semantic Data Modelling In the database literature, the complexity of applications and the large numbers of data elements have resulted in researchers turning to high-level, abstract models for organizing and exploiting databases. Many of these constructs have been borrowed from develop-ments in programming languages and artificial intelligence theory. As in the case of programming languages, a consistent theme is the gradual abstraction of data models from implementation and technology-based models to higher-level, conceptual models. 2.2.1 Semantic Data Models Brodie [1984], Bubenko [1980], Kent [1978], Gibbs [1985], Hull and King [1987] and others have documented the evolution of data models toward ever "higher" levels of conceptu-alization. Successive models rely less and less on the computer-related mechanisms for representing and storing data (such as files, records, pointers, "navigation paths") and Chapter 2. Conceptual Modelling and Abstraction 24 strive to describe the data in terms of their "natural", real world structure and underlying meanings. The trend is from the "classic models" (hierarchical, network and relational) to data models which are increasingly semantically-based. Afsarmanesh and McLeod [1986] illustrate this progression as follows: • Extensions to the relational model such as R M / T [Codd, 1979]; • Incorporation of abstraction mechanisms such as aggregation and generalization [Smith k Smith, 1977a, 1977b]; • Binary database models [Abrial, 1974]; • Functional database models; • Entity-relationship models such as E-R [Chen, 1976] and Semantic Database Model [Hammer k McLeod, 1981]; • Behavioural models such as Taxis [Greenspan k Mylopoulos, 1983] and A C M / P C M [Brodie k Ridjanovic, 1984]; • Semantic-object-based models [Afsarmanesh k McLeod, 1986]. Brodie and Mylopoulos [1986] have argued that this trend represents a fundamental shift in information processing, from a primarily computationally-based to a semantic theory of information. The computational theory is concerned with supporting large amounts of data shared among many users and gives rise to issues such as data structures, concurrency, query languages, normalization, and integrity constraints. The semantic theory focuses on the representation of knowledge by applying such techniques as mathe-matical logic, semantic nets and frames. Throughout this evolutionary development, the goal has been to characterize the database and its operation in application-domain or Chapter 2. Conceptual Modelling and Abstraction 25 "real-world" terms, in short, to capture more semantics in the database. For example, the system should support the real world concept of "hiring" an employee rather than the technical operation of "inserting" an employee record into the database [Ledgard k Taylor, 1977]. Many of these alternative models are beginning to explicitly take on object-oriented constructs borrowed from Artificial Intelligence, ie. semantic network, frames and other knowledge representation schemes, as well as the object-oriented tradition in program-ming languages. The basic idea is to provide constructs which have direct correspondence to entities (or perceived entities) in the world of the application. These constructs (mod-elled as frames, semantic network nodes, objects, etc) are interrelated and manipulated to reflect corresponding situations in the real world. This basic idea is refined and extended in various proposals for semantic data models which are designed to provide better repre-sentations of real world phenomena and to achieve more "natural" manipulations on the data [Smith k Smith, 1977; Tsichritzis k Lochovsky, 1982; Brodie, 1984; Hull k King, 1987]. Generally speaking, most semantic models support direct representation of objects or entities, as distinct from indirect representation by attribute values 5 . They generally support constructs such as IS-A which determine object attributes and relationships among objects. Semantic data models make heavy use of abstract data types including primitive or atomic types as well as constructed and derived types, that is types con-structed or derived from existing types or data in the system. Many models recognize that entities in the data base may not be uniquely identifiable with printable attribute values or keys, therefore they reference entities with internal identifiers not visible to the user. 5In a relational database, for example, a real world entity is typically represented as a collection of attribute values within a tuple. Chapter 2. Conceptual Modelling and Abstraction 26 Most semantic models support some concept of attribute or directed relationship among types. Different semantic models vary in the kinds of mechanisms used for in-terrelating types. Some emphasize the explicit construction of types while others may rely heavily on attributes. For instance, Figure 2.1, adapted from Hull and King [1987], shows four alternate ways of modelling the type ENROLLMENT. In Figure 2.1a, EN-ROLLMENT is an aggregation of types COURSE and STUDENT with the attribute GRADE. 6 Figure 2.1b views it as a ternary aggregation with no attributes. In Figure 2.1c, ENROLLMENT is an atomic type with three attributes. Finally, Figure 2.Id does not explicitly model the type ENROLLMENT but simply considers GRADE to be an attribute of the pair STUDENT and COURSE. Data definition and manipulation languages have been proposed for specifying and using semantic models. In contrast to traditional record-oriented models, languages for semantic models must directly support the query and management of types and instances. Most semantic data models have concentrated on modelling the structural aspects of data, ie. the types and interrelationships among types. However, some semantic models have also explored facilities for handling dynamic and behavioural aspects of data [Brodie & Ridjanovic, 1984]. Comparative descriptions of the above features as well as specific proposals for seman-tic data models are described in detail in a number of sources including Hull and King [1987], Brodie [1984], Peckham and Maryanski [1988], and Tsichritzis and Lochovsky [1982]. 2.2.2 Abstraction Mechanisms In order to reduce the complexity of large data bases to manageable dimensions, abstrac-tion mechanisms are typically used to organize objects by extracting essential and hiding 6 I n Figure 2, the aggregation of types is represented by dashed lines and attributes by solid lines. Chapter 2. Conceptual Modelling and Abstraction 27 irrelevant information. Many of these mechanisms have been inspired by theories about the way humans appear to represent and organize knowledge in their minds and the way they seem to express reality in language. Three specific organizing mechanisms, classi-fication, generalization and aggregation, have received particular attention in database research. Classification Classification is usually defined as an abstraction in which a single construct, variously called class, type or sometimes set, is used to describe a set of related objects. The notion of a class implies both a property structure, ie. the relevant common properties which make the objects similar, and a set, ie. the objects in the class [Brodie, 1984; Gibbs, 1985]. Members of a class have an instance-of relation to the class. The reverse of classifi-cation is sometimes referred to as instantiation. Generalization Generalization is normally defined as an abstraction which organizes classes into useful hierarchies [Gibbs, 1985]. Generalization is often referred to as an IS-A relationship between a specialized object and some higher-level, generic one. The idea of hierarchy is emphasized as well as the inheritance of properties by the specialized object from the generic [Brodie, 1984]. The concept of generalization, however, is not straightforward and a number of contro-versies have been raised regarding its precise meaning as well as the notion of inheritance as a principle for organizing knowledge [Brachman, 1983]. Chapter 2. Conceptual Modelling and Abstraction 28 Aggregation Aggregation refers to an abstraction whereby a single object is viewed as a collection or aggregate of several other objects. Several distinct interpretations of aggregation have been proposed including Cartesian, cover and statistical aggregation. Cartesian aggregation [Codd, 1979; Smith & Smith, 1977a], considers aggregations of properties, eg. the class P E R S O N is an aggregate of properties such as N A M E , A D D R E S S and other relevant properties. Cover aggregation [Codd, 1979] abstracts an object as an aggregation of other ob-jects. Both Cartesian and cover aggregation suggest a part-of relationship between the individual parts and the aggregate. Statistical aggregation provides summary information related to a database such as the number of instances and averages of particular attribute values. 2.2.3 Object-Oriented Data Models In many ways, the concepts in semantic data modelling are closely related to those found in object-oriented programming languages. Consider, for example, the following features of O O P L [Nierstrasz, 1986]: • Encapsulation of statics and dynamics (eg. as instance variables and methods); • Class hierarchy mechanisms; • Homogeneity. In fact, Maier and Stein [1987] have suggested that "an object-oriented language is complete enough to handle database design, database access, and applications". They offer a database model, Gemstone, and a language, O P A L , which are closely derived from Chapter 2. Conceptual Modelling and Abstraction 29 Smalltalk. Other models have been reported which allow data items to have attributes which can be database queries or even application programs [Hull &: King, 1987] Not surprisingly, some recent work in database research has been inspired directly by the object-oriented programming paradigm. Systems such as ORION [Banerjee et al., 1987], IRIS [Fishman et al., 1987], OMT [Blaha et al., 1988] and Gemstone [Maier & Stein, 1987] have explicitly acknowledged this relationship. One result of these trends is the gradual blurring of past distinctions between the more-or-less static aspects of data base design and the more dynamic aspects of programming and data query languages. Afsarmenesh and McLeod [1986] have summarized these trends in semantic database modelling as follows: • From a record-orientation to an object orientation • From strictly static views of the database to accommodating dynamics • From separate mechanisms for handling data and meta-data to a uniform treatment of all information. Appendix F briefly reviews, without comment, three selected data models which are representative of these trends and illustrative of the wide variety of ways in which object-oriented concepts have been incorporated into data modelling. The first, by Kroenke and Dolan, focuses the object paradigm as a way of unifying disparate data base concepts. The second, A C M / P C M illustrates the incorporation of dynamics into a data model. The third, PAMS, is an attempt at integrating all aspects of data modelling, including both structural and dynamic modelling, in a consistent and homogeneous manner. Chapter 2. Conceptual Modelling and Abstraction 30 2.3 Systems Development Methodologies 2.3.1 Early Approaches to Information Systems Modelling A s w i t h e a r l y approaches to p r o g r a m m i n g a n d d a t a base, t r a d i t i o n a l I n f o r m a t i o n S y s t e m D e v e l o p m e n t me thodo log ies u s u a l l y r evea l a s t rong t echno logy o r i e n t a t i o n i n the i r de-sc r ip t ions of i n f o r m a t i o n systems: files, processors, p r o g r a m s , d a t a f lows, i n p u t s , ou tpu t s a n d so fo r th . I m p o r t a n t me thodo log ie s often emphas i ze one or ano ther aspect of th i s focus. D a t a flow d i a g r a m s , for e x a m p l e , stress the t r a n s f o r m a t i o n of d a t a b y different processes. W a r n i e r - O r r [Warn ie r , 1981; O r r , 1982] a n d J S P [Jackson , 1975] o n the o ther h a n d , re la te d a t a s t ruc tu re to p r o g r a m s t ruc ture . A n d ea r ly f o r m a l i z a t i o n s of i n f o r m a t i o n sys tems m o d e l l i n g focused a r o u n d abs t rac t no t ions of i n p u t s , o u t p u t s , files, procedures a n d o ther cons t ruc t s c lose ly r e l a t ed to systems i m p l e m e n t a t i o n [ Y o u n g & K e n t , 1958; Langefo r s , 1966]. 2.3.2 Modelling an Universe of Discourse T h e e x p l i c i t s epa ra t ion of l o g i c a l versus p h y s i c a l des ign , the deve lopment of "business ana ly s i s " techniques (eg. B I A I T [Ca r l son , 1982] a n d B S P [ I B M , 1982]) a n d the " top-d o w n " me thodo log ie s reflect a shift to a b s t r a c t i o n away f r o m t e c h n o l o g y a n d i m p l e m e n -t a t i o n issues a n d t o w a r d the real- l i fe s i t u a t i o n m o t i v a t i n g the IS . A s n o t e d b y B u b e n k o [1986], m o s t m o d e r n me thodo log ies n o w e m p l o y some f o r m of h igh - l eve l , c o n c e p t u a l de-s c r i p t i o n of the i n f o r m a t i o n sys t em, w i t h v a r y i n g degrees of f o r m a l i s m , the m a i n purpose of w h i c h is to specify the sys t em i n mach ine - independen t , user -or ien ted t e rms . A n i m -p o r t a n t t heme of mos t m o d e r n I S D methodo log ies is tha t " i n f o r m a t i o n sys tems m a i n t a i n a f o r m a l , s y m b o l i c m o d e l of some concre te a n d / o r abs t rac t un iverse o f d iscourse ( U o D ) [ B u b e n k o , 1986]" . Chapter 2. Conceptual Modelling and Abstraction 31 T h i s i d e a , w h i c h has o n l y been e x p l i c i t l y a r t i c u l a t e d r e l a t i v e l y r ecen t ly [ W a n d & W e -ber , 1988; B u b e n k o , 1986; E s s i n k , 1986; G r e e n s p a n , 1984], makes a s t rong a n d clear d i s t i n c t i o n be tween desc r ip t ions o f the p r o b l e m s i t u a t i o n a n d desc r ip t ions o f the final i m p l e m e n t e d sys t em. T h e resul t has been to concen t ra te m o r e a n d m o r e u p o n the ear l ier stages o f the I S D process i n the c o n v i c t i o n tha t f u n c t i o n a l requ i rements a n d i m p l e -m e n t a t i o n canno t be unde r s tood w i t h o u t first cons ide r ing a n a p p r o p r i a t e m o d e l of the a p p l i c a t i o n or enterpr ise [ B u b e n k o , 1986; J a c k s o n , 1983]. T y p i c a l of these approaches are methodo log ies such as J S D [Jackson , 1983] w h i c h stresses e x p l i c i t " r ea l i t y m o d e l l i n g " of ent i t ies i n an U n i v e r s e o f D i scou r se a n d N I A M [Verhei jen & V a n B e k k u m , 1982] w h i c h exp lo i t s l i n g u i s t i c d e c o m p o s i t i o n of sentences de-s c r i b i n g some r e a l - w o r l d s i t u a t i o n . U n l i k e mos t ear l ie r me thodo log ie s , t h e y also a t t e m p t to p r o v i d e h igh - l eve l descr ip t ions of b o t h s t r u c t u r a l a n d a c t i v i t y aspects o f the enterprise . F o r m a l ( m a t h e m a t i c a l ) approaches to abs t rac t i n f o r m a t i o n sys tems m o d e l l i n g have also been cons idered . B u b e n k o [1980] has p roposed the C o n c e p t u a l I n f o r m a t i o n M o d -e l l i n g ( C I M ) w h i c h is based o n first-order l o g i c . G r e e n s p a n has dev i sed a f o r m a l l anguage , R M L , u s ing first-order l o g i c ex tended to hand le concepts d e a l i n g w i t h t i m e . These , a n d s i m i l a r mode l s are i n t e n d e d to generate h igh- l eve l , f o r m a l desc r ip t ions o f requi rements m o d e l l i n g f r o m a p r o b l e m - d o m a i n perspec t ive [Greenspan , 1984; B o r g i d a , G r e e n s p a n & M y l o p o u l o s , 1985]. Because of the i r e x p l i c i t emphas is o n " rea l i ty m o d e l l i n g " , m a n y of these approaches bear a s t rong f l avour of simulation. T h a t i s , i n f o r m a t i o n systems are seen as m a p p i n g to r e a l - w o r l d p h e n o m e n a a n d states a n d t r a c k i n g r e a l - w o r l d events [ W a n d & W e b e r , 1988]. T h i s is i n cont ras t to the m o r e conven t i ona l v i e w of i n f o r m a t i o n systems as cons i s t ing of p r o g r a m s , c o m p u t a t i o n a l processes, procedures , a n d d a t a bases. It is ev ident tha t compu te r -ba sed mode l s or s i m u l a t i o n s of th ings i n the rea l w o r l d c a n become e x t r e m e l y de t a i l ed . F o r e x a m p l e , F o l e y [1987] describes h o w advances i n c o m p u t e r t e chno logy Chapter 2. Conceptual Modelling and Abstraction 32 have been exploited to generate sophisticated "artificial realities" which act as powerful, compelling models of some aspect of reality. A good example of a systems development methodology which centers around "reality modelling" is Jackson's Method (JSD) [Jackson, 1983; Cameron, 1982; McNeile, 1986]. J S D insists upon defining an initial model of the part of the real world of interest even before functional requirements are fully analyzed. Functional requirements are then added to this model at a later stage. It is a fundamental principle of JSD that the developer must begin by modelling this reality, and only then to go on to consider in full detail the functions that the system is to perform. The system itself is regarded as a kind of simulation of the real world; as the real world goes about its business, the system goes about simulating that business, replicating within itself what is happening in the real world outside. The functions of the system are built upon this simulation; in JSD they are explicitly added in a latter development step [Jackson, 1983, p. 4]. JSD takes the position that although the model generated in this phase has no func-tionality (except to faithfully simulate real world behaviour), the model implicitly defines a complete range of possible system functionality. The methodology recommended for JSD consists of • Identifying and defining real world entities and actions 'performed or suffered' by these entities. • Creating an initial 'process model' in terms of the entities and their actions in terms of communicating sequential processes [Hoare, 1985]. • Adding functionality, mainly in the form of system outputs such as reports. Chapter 2. Conceptual Modelling and Abstraction 33 • Operationalizing the process model and outputs on appropriate hardware, software and data base technologies. 2.3.3 Object-Oriented Software Engineering In the software engineering literature, developments in object-oriented programming languages have stimulated activity in object-oriented software development approaches which reflect OOPL principles. These approaches are generally viewed as partial lifecycle techniques which focus on the design and implementation phases of software development [Booch, 1983; Booch, 1986; Buzzard & Mudge, 1985; Meyer, 1988]. Booch [1986], for example, suggests that requirements analysis techniques such as JSD or SREM [Alford, 1985] can be integrated into object-oriented program design. The basic approach is to identify and represent real world entities with abstract data types or OOPL objects. • Objects and their attributes in the real world are identified. • Operations suffered by and required of each object are identified. • The relationships among objects are established. • Object interfaces are described by producing a module specification which can then be implemented in a suitable program module such as an ADA package [Booch, 1986]. 2.3.4 Object-Oriented Methodologies Recently, various database design and information system analysis methodologies which have clearly been influenced by the object-oriented programming paradigm have been Chapter 2. Conceptual Modelling and Abstraction 34 proposed b y academics a n d p rac t i t i one r s . In m a n y cases, these are b a s i c a l l y "front-ends" to r e l a t i o n a l d a t a mode l s , d a t a flow [de M a r c o , 1977] representa t ions a n d other m o r e c o n v e n t i o n a l me thodo log ie s . In some cases, t hey are p r a c t i c a l me thodo log ie s based o n m o d e l l i n g approaches such as E n t i t y - R e l a t i o n s h i p . F o r e x a m p l e , the K r o e n k e a n d D o l a n p r o p o s a l p rov ides for a c o n c e p t u a l l eve l of m o d e l l i n g i n w h i c h the un iverse of d iscourse is first represented i n te rms of "objec ts" . A t r a n s l a t i o n process t h e n conver ts the ob jec t -based m o d e l i n t o a conven t i ona l r e l a t i o n a l d a t a m o d e l . T o t ake ano the r e x a m p l e , B l a h a et a l . [1988] have p roposed a des ign me thodo logy , O b j e c t M o d e l l i n g T e c h n i q u e ( O M T ) , for s u p p o r t i n g the des ign of r e l a t i o n a l databases . O M T suppor t s g e n e r a l i z a t i o n a n d aggrega t ion abs t rac t ions a n d is used to generate a n abs t rac t , h igh - l eve l d e s c r i p t i o n of the p r o b l e m d o m a i n i n te rms o f objec ts . A h igh -l eve l g r a p h i c a l n o t a t i o n fur ther suppor t s the me thodo logy . T h i s r ep resen ta t ion is t h e n conver ted to a m i d d l e - l e v e l , D B M S - i n d e p e n d e n t set of gener ic r e l a t i o n a l tab les . T h i s m i d d l e - l e v e l decouples the m a p p i n g of objects f r o m the id iosyncras ies o f a specific D B M S . F i n a l l y , the m i d d l e - l e v e l is conver ted i n t o the tables o f a specific D B M S . B l a h a et a l . c l a i m t ha t m u c h of the convers ion c a n be a u t o m a t e d . O M T is seen as p r o v i d i n g t w o i m p o r t a n t advantages over o ther r e l a t i o n a l da tabase design me thods : • O b j e c t s p r o v i d e a h igher l eve l of sys tem desc r ip t i on t h a n express ing the a p p l i c a t i o n d i r e c t l y i n tables (eg. v i a S Q L ) or even the m o r e h igher - l eve l representa t ions such as E n t i t y - R e l a t i o n s h i p or L o g i c a l R e l a t i o n a l D e s i g n M e t h o d o l o g y ( L R D M ) [Teory et a l . , 1986]; • T h e use of objects i n da tabase des ign fac i l i ta tes the i n t e g r a t i o n o f the da tabase a n d p r o c e d u r a l code expressed i n ob jec t -o r ien ted p r o g r a m m i n g languages . Chapter 2. Conceptual Modelling and Abstraction 35 Shlaer and Mellor [1988] have presented a similar methodology which they call Object-Oriented Systems Analysis. Their approach appears to be closely derived from the Entity-Relationship model and employs three basic constructs: object, attribute and relationship. They provide some additional constructs for classifying and associating objects as well as concepts such as object life cycles, states, and state transitions. Traditional data flow diagrams are advocated for analyzing and describing state transformations. Ross [1987] has described a methodology which he calls Entity Modelling which again appears to be directly inspired by the Entity-Relationship model. Entities are equated to things or objects in the real world and guidelines provided for identifying, naming and associating objects. Ross further introduces the concept of Behaviour Modelling which attempts to integrate dynamics into the data model. Included in behaviour modelling are various integrity rules, entity life-cycle transitions and triggers which attempt to describe and represent the "business rules" of the application. 2.4 Discussion 2.4.1 Conceptual Modelling and the Object Paradigm The preceding sections have described some important trends in conceptual, or high-level modelling as found in programming, database design and systems development methodologies: • Abstraction Principle. Separation from implementation issues (computer technol-ogy, program code, data storage detail, etc); • Reality Modelling. Support for describing and organizing information on an epis-temological or human conceptualization basis (generalization, aggregation, classifi-cation, etc); Chapter 2. Conceptual Modelling and Abstraction 36 • Representation Principle. Simulation or modelling of the Universe of Discourse rather than a strict computational or functional model; • Mapping Principle. Direct correspondence between real world entities and repre-sentation or software units such as "objects". Overall, there appears to be a general trend in the programming language, database, and systems development areas to include explicit, formal constructs to capture human perceptions and intuitions about the domain of discourse. This trend is characterized by employing constructs which provide direct correspon-dences between aspects of reality and the model. These include constructs such as en-tities, attributes, relationships and their many refinements and derivatives which are independent of specific technologies or implementations. Further, modern technical in-novations such as abstract data types, objects in programming languages, and frames in artificial intelligence languages appear to offer the potential of allowing the direct oper-ationalization of conceptual modelling constructs in hardware or software. Therein appears to lie much of the intuitive appeal of the object-oriented approach to conceptual modelling. 2.4.2 Issues in Object-Oriented Modelling Although the object paradigm appears to offer powerful modelling and representational capabilities, it also gives rise to methodological and conceptual difficulties. For one thing, the mappings between reality and their representations are not clearly understood. As Brodie and Mylopoulos observe, "...the semantics of most data models and database languages is intuitive and lacks formal definitions [1986]". The search for improved modelling precision is evidenced by the proliferation of different semantic model proposals and the profusion of modelling constructs: activities, events, processes, data Chapter 2. Conceptual Modelling and Abstraction 37 flows, entities, attributes, and so forth [Gibbs, 1985; Hull and King , 1987]. Further, the object-oriented modelling approaches reported in the literature appear to rely upon past practice, intuition and ad hoc rules of thumb in defining the basic constructs. In the requirements modelling language R M L , for example, Greenspan [1984] proposes three object types: entity, activity, and assertion. Nelson [1982] presents an object-oriented prototyping approach which identifies four different object categories: entity object, process object, event object and relationship object. Often, there is an apparent failure to distinguish between objects as constructs for representing things in the real world and programming or software constructs [Wand, 1989]. In the practitioner-oriented literature, Ross [1987] shows six categories of objects: people, places, things, organizations, concepts, and events. A t a later time, measure-ment is recognized as a seventh category. Intuitive distinctions are made between things, concepts, events, relationships, and so forth. Altogether, eighteen object types, nine re-lationship types and dozens of rules for their interaction are listed. Similarly, Shlaer and Mellor [1988] define five categories of objects: tangible things, roles, incidents, interac-tions, and specifications [p. 15]. Yet, in most cases, the choice of these categories appears to be basically ad hoc with little or no theoretical justification or rationalization. O n a more fundamental level, there has been discussion concerning the validity of dif-ferent representations of reality as well as the nature of reality itself in the context of IS modelling. Kent [1978, 1977], for example, has provided especially compelling accounts of the difficulties in making consistent and coherent semantic correspondences between reality and data modelling constructs, including both record-oriented and semantic con-structs such as Entity-Relationship. The ambiguities of abstraction mechanisms such as classification, aggregation and generalization and difficulties with semantic nets have been noted by several writers [Gibbs, 1986; Brachman, 1983; Kent, 1978; Israel & Brachman, 1984; Stamper [1986]; Brodie k Mylopoulos, 1986]. Chapter 2. Conceptual Modelling and Abstraction 38 A basic question is how well these modelling constructs reflect human mental processes or reality in the world. Although such abstractions have been found to be powerful and useful, it would be naive to claim that they completely capture all aspects of the application, especially given that the mental and linguistic processes upon which they are based are so poorly understood. Indeed, much empirical evidence from the cognitive sciences has been presented which challenge the basic assumptions underlying these ways of organizing knowledge and information [Lakoff, 1987]. 2.4.3 T h e o r e t i c a l F o u n d a t i o n s for O b j e c t - O r i e n t e d M o d e l l i n g These concerns have led to several research directions in investigating theoretical foun-dations for the object-oriented paradigm. Among them can be included the anthropro-morphic, abstract data type and metaphysical approaches. T h e A n t h r o p r o m o r p h i c A p p r o a c h Danforth and Tomlinson [1988] observe that most programming languages incorporate "a metaphor in which computation is viewed in terms divorced from the details of ac-tual computation". In some programming paradigms, such as logic programming or functional programming, the metaphor is usually mathematically precise. In the case of object-oriented programming, however, they see the metaphor "generally expressed in philosophical terms, resulting in a natural proliferation of opinions, concerning exactly what OOP really is". For Danforth and Tomlinson, the heart of the metaphor is the anthropromorphic view in which objects have identity, ie. a self, that persists over time and can respond intelligently to requests or messages addressed to them. Chapter 2. Conceptual Modelling and Abstraction 39 This anthropromorphic metaphor is frequently invoked in the context of object-oriented programming, and particularly in the practitioner-oriented literature. For ex-ample, the language manual for Actor [Whitewater, 1987], describes object-oriented pro-gramming languages in this way: "To many indigenous cultures, the world is populated by entities. Mountains, plants, animals, bodies of water are all governed by spirits that oversee the op-eration of that particular aspect of the world. This is directly opposed to the "civilized", western world view in which human beings are the only active entities around, and everything else is there for man to use for his own ends. Oddly enough, programming in Actor seems to have a lot in common with the first, animistic world view. In more traditional languages, we approach program-ming as writing a lot of code to do all the things that have to be done. The code is the rocks, plants, bricks and mortar that the programmer uses to build struc-tures. The programmer is the only active entity, and the code just basically a lot of building materials. Object-oriented programming is more like creating a lot of helpers that take on an active role - a spirit - and form a community whose interactions become the application. When you design a class, you can think of the class as an expert or consultant that you can then use again wherever you need its specific expertise. Because of the loose coupling between classes, there is a high likelihood that you will be able to use them in more places than you had originally planned. After a while, classes become like old friends that you know are reliable, and always there when you need them [p. 380]." To quote another example, the manual for the Smalltalk V programming language introduces OOPL in the following way. Chapter 2. Conceptual Modelling and Abstraction 40 ...What could be more natural. We experience our world largely as a vast collection of discrete objects, acting and reacting in a shared environment. At the human social level we are a society of doctors, lawyers, beggars and thieves, etc. Although we are a population of unique individuals, we cluster in occupation groups based on the behavioural skills and knowledge we each develop and exhibit... Break a leg, call in a doctor and tell him or her about your condition. You trust the doctor's special knowledge and skills to help make you better... Want to become a lawyer? You learn the law and how to behave like a lawyer. Then as corporate counsel in response to the MagaCorp CEO's questions, "What's our exposure to this new project?", your answer is couched in legal considerations while the chief financial officer reflects on fiscal impacts. In Smalltalk's object-oriented terms, occupational abstractions like doctor, lawyer, programmer, etc., are classes of which we individuals are instances. To become a lawyer, we learn legal methods. Communications between individuals are comparable to Smalltalk messages, their context equivalent to Smalltalk selec-tors... Correspondence between our perception of the world and its representation in machine terms through Smalltalk gets at the heart of Smalltalk's power [pp. 11 -13]. This anthropromorphic image has been pursued in detail by Tsichritzis [1985] who has proposed an environment in which objects called KNOS (for KNOwledge objects) behave according to analogies taken from the animal world: birth, movement, communication, and death. Tsichritzis, Fiume, Gibbs, and Nierstrasz have elaborated on some technical details for implementing KNOS in [Tsichritzis et al., 1987]. Chapter 2. Conceptual Modelling and Abstraction 41 The Abstract Data Type Approach Danforth and Tomlinson stress the need for well-grounded theories of O O P concepts such as object types and inheritance. In their opinion, a powerful type theory 7 in O O P , for instance, can provide potential benefits such as • a uniform framework for the entities in a programming language; • a means of relating and representing the denotations or meaning of program-level expressions; • a framework for more "natural" connections between the application domain-level entities and their actual computer-based representations. They point out that current type theories do not appear to provide a formal, consistent basis for supporting the objects and behaviours observed in O O P , and that most object-oriented programming languages attempt to provide such benefits, in ad hoc ways, for example, with special notations or language-specific mechanisms. Another important O O P concept, inheritance, also poses theoretical issues as noted by several researchers [Danforth & Tomlinson, 1988; Brachman, 1985; Minsky, 1989]. Normally, inheritance reflects special relationships between entities. But not all the properties of a receiver are necessarily inherited. Nor are all the properties of a giver necessarily bequeathed. What formal theory, then, is appropriate for explaining inher-itance including issues such as multiple inheritance? Depending upon the relationships supported by O O P (eg. is-a, part-of, etc), many different disciplines and restrictions on inheritance would appear to possess face validity. In most cases, object-oriented programming languages have provided their own disciplines and mechanisms related to inheritance, without considering any formal underlying models. Types in programming can be thought of as a way of describing the possible values in a computation even though they may not be known in advance [Danforth & Tomlinson, 1988]. Chapter 2. Conceptual Modelling and Abstraction 42 Metaphysical Approaches Recently, some researchers have looked to metaphysics to provide foundations for the object paradigm. In the case of object-oriented database models, Beech [1987] argues that given the current state of our understanding, these models must still be developed informally. He looks to developments in metaphysics and philosophy such as recent axiomatizations and formalisms in the metaphysics of entities, relations and existence [eg. Parsons, 1980; Zalta, 1983] for providing a basis for a more rigorous validation and evaluation of object-oriented models. In the search for better theories for object-oriented programming, Wegner [1987] observes that seemingly straightforward object-oriented concepts such as classification and types actually have rich and complex philosophical implications. He points out, for example, how classification can be viewed in terms of: • evolutionary hierarchies and mathematical equivalencies; • inheritance relationships; • formalisms such as lambda calculus and algebras; • metaphysical concepts such as "natural kinds" and the nature of reality. He also observes that object-oriented concepts reach deeply into important philosoph-ical controversies such as those concerning typed versus untyped universes. That is, while certain "realists" believe that types are man-made abstractions for organizing real world phenomena, there is also a strong philosophical tradition which stresses the primacy of ab-stractions such as types, ideals and categories. For example, Platonic ideals and Kantian a priori categories can be seen as possessing a greater reality than their often imperfect Chapter 2. Conceptual Modelling and Abstraction 43 specific instances. This raises questions about, for instance, whether types or values, ie. instances, should be the starting point for an object-oriented modelling scheme. In this context, therefore, Wegner sees simple, intuitive notions of classification and types as inadequate in developing truly powerful and comprehensive logical and computational formalisms or models of reality. A recent step in developing more powerful models of Information Systems is the work of Wand and Weber who have drawn upon first principles taken from the philosophy of science [Wand k Weber, 1988; Wand, 1989]. Similarly, this thesis attempts to apply first principles in formal metaphysics (or ontology) to understanding and clarifying the object paradigm in the context of Information Systems. The next chapter provides the motivation and background for this approach. Chapter 3 A n Ontological Basis for Conceptual Modelling 3.1 Motivation for the Ontological Basis This chapter lays the background for an object-oriented ISD model which is grounded in a formal ontology or theory of reality. More specifically, this model can be viewed as an operationalization of a substantial metaphysical system as formalized by Mario Bunge in his work, Treatise on Basic Philosophy [1977], published in seven volumes. The advantages of this approach for ISD include the following: • the resulting model is more likely to be "in the world", rather than influenced by technology or implementation considerations; • there is a theoretical basis for the selection of the constructs used in describing and implementing the information system; • the completeness and consistency of the model can be established against the stan-dard set by the underlying ontology. Surveys of existing conceptual modelling approaches reveal that they are generally rooted in a combination of one or more of the following [Lyytinen, 1987]: • process and functions (activities that process, transform, store, access and modify data); • implementation terms (eg. files, programs, records); 44 Chapter 3. An Ontological Basis for Conceptual Modelling 45 • technological innovations (eg. abstract data types, objects, frames); • mathematical formalisms (eg. first order logic); or • intuitions, experience and common sense knowledge about the world. This thesis, however, takes a different approach to conceptual modelling. It proposes that since the purpose of a conceptual model is to represent aspects of reality, the con-structs in the model should, therefore, be based upon a systematic and preferably formal theory of reality itself. The goal is an IS conceptual modelling scheme that fits a given theory of the world, rather than trying to fit the world to some theory of representation [Gibbs, 1985]. In the philosophy of science, the study of theories or systems of reality is known as metaphysics or ontology. To function as a basis for an IS conceptual model, a system of ontology is required which is sufficiently formalized, complete and compelling. This thesis proposes that Bunge provides one such formalization which can be adapted to a formal model of IS conceptual modelling.1 The choice of Bunge will be discussed in more detail shortly. For now, it is suggested that his ontology results in the desired requirements as follows. • Bunge's system represents a view of the world independent from any existing tech-nological considerations related to computing or information systems. Hence, a model based strictly on his system is more likely to be free from technological or implementation influence. • Bunge provides a rigorous, consistent formalism and axiomatization for the ba-sic concepts in his system. Hence, there exists a well-defined foundation for the JThis is not to imply that other suitable ontological systems do not exist. In fact, it is recognized that other, possibly quite different metaphysical systems for conceptual modelling are possible, probably likely. Chapter 3. An Ontological Basis for Conceptual Modelling 46 fundamental constructs in the conceptual modelling scheme to be proposed. • The proposed model operationalizes Bunge's theory of reality. His ontology, there-fore, provides a ready basis for evaluating the completeness of the proposed model as a way of describing reality. • Bunge's ontology provides a foundation for the implementation and end-use of information systems based on the proposed conceptual modelling approach. To summarize, the proposed model is motivated by the premise that an information system which purports to represent reality must make assumptions about the nature of reality itself. Therefore, as representations become more conceptual and technical innovations make possible increasingly more powerful modelling possibilities, the nature of this reality needs to be explicitly articulated and its implications clearly understood. Ontology provides one such articulation. For comparison, it is useful at this point to briefly note the difference in emphasis between this approach and models based on formal or mathematical logic. It is accepted that mathematical logic supports a clean, straightforward, and well-accepted semantic theory once the connection is established between real-world phenomena and the individ-uals and predicates in the logical expressions [Mendelson, 1964; Tarski, 1941]. However, the task of making this connection is a matter of intuitive and imaginative interpretation. Logic says nothing about the nature of reality itself. Here, philosophy in general, and ontology in particular, is useful since they are concerned with the basic nature of the world. Indeed, there is an important tradition in the philosophy of science which addresses issues in representation, reality and man's relation to reality [Hacking, 1983; van Frassen, 1980; Lakoff, 1987]. A theme of this literature is concerned with how basic assumptions about reality are inevitably reflected in our models and representations of the world. A Chapter 3. An Ontological Basis for Conceptual Modelling 47 consequence of this tradition would indicate that information systems, as representations or models of reality, are similarly affected by the metaphysical assumptions underlying their construction. Most existing information system descriptions have typically been developed from "outside reality", for example, in terms of implementation, technology, hardware and software, formal and mathematical logic, and so forth. This research proposes to work in the opposite direction, from "within reality" by basing IS descriptions directly upon a theory of the world. 3.2 Previous Work with Ontological Formalisms in Information Systems In some respects, it should be recognized that all IS models make implicit ontological assumptions about the applications they describe. Rarely, however, are these assumptions explicitly articulated or defined in a consistent or formal manner. Typically, fundamental concepts such as entities, relationships, and activities are undefined or defined informally. Recently, however, some researchers have begun to address these basic issues. 3.2.1 Stamper In a series of works, Stamper [1986, 1979, 1978, 1977] has observed the need for better understanding of the links between data and reality. He criticizes conventional approaches such as first-order languages by observing that they model sets of individuals, hence make the assumption that these individuals exist, that they can be distinguished from each other, and that there is no equivocation about identity. He points out that any interpretation in a logic model, therefore, necessarily begs questions of individuation and identity. That is, real world entities must be sufficiently individuated in order to sustain an interpretation [Tarski, 1941] into the set-theoretic logic model. Even if individuation is obtained, one must assume that individuals can be identified, Chapter 3. An Ontological Basis for Conceptual Modelling 48 again in order to sustain an interpretation. Stamper argues that in real world situations, much business activity is concerned with disputing the boundaries of entities. In fact, the entire point of some information systems is to identify objects in the real world. Also, the reality of business is not just in easily identified physical objects but in social constructs (rights, contracts, orders, etc). He observes that social constructs are often modelled as documents in information systems because most logical formalisms have difficulties with abstract social constructs. For example, a business concept such as an "order" is almost invariably modelled as a document, ie. a header and one or more order-lines and ignores the social reality of an order as a contract, a directive, or a particular kind of relationship between vendor and buyer, with all its social and legal richness which only marginally involves the document. As a result, semantic ambiguities are inevitable in these models. Stamper expresses this viewpoint as follows: Language, logic and mathematics all employ discrete tokens. These tokens can be studied in a formal way using themselves as instruments of enquiry without raising the problems of ontology I have identified. However, when we turn our attention to language, logic and mathematics as a way of expressing things about reality, we cannot ignore questions about the ways in which discrete, formal tokens are coordinated with a reality which has no such discrete structure [1986, p. 236]. He concludes by noting For the analysis of business information, a semantic theory should account for such notions as truth, individuation, identity, time, space and so on, instead of adopting them as primitive concepts [p. 251]. Stamper has proposed alternative formalisms which address these issues based on Chapter 3. An Ontological Basis for Conceptual Modelling 49 natural language approaches such as the LEGOL Project [Stamper, 1978] and recent theories in psychobiology [Stamper, 1986]. 3.2.2 W a n d a n d W e b e r O n t o l o g i c a l F o r m a l i s m s Recently, Wand and Weber have presented a formal model of information systems which draws upon Bunge's work in ontology [Wand Sz Weber, 1988; Wand & Weber, 1987; Weber, 1987; Wand, 1988a; Wand, 1988b]. Their objective is to develop a model of information systems which is independent of technological or implementation considera-tions and which can be used as a basis for a general theory of information systems design. They use their model to describe and explain important IS concepts such as batch and real time, transactions processing, and decision support systems. Wand and Weber observe the wide differences among the many information system development methodologies used in practice and described in the literature. They note that these methodologies employ a wide range of underlying constructs and assumptions: activities, processes, data flows, objects, events, and so forth. They make the point that the lack of a suitable theory of information systems and IS development is hampering the comparison and evaluation of these competing methodologies and their underlying approaches. They introduce their model by defining an information system as a "human created representation of a real world system as perceived by humans". In this light, information system development is seen as a "transformation from some perceptions of the real world into an implementation of a representation of these perceptions". According to their perspective, this transformation proceeds through three progressive stages: • Analysis: From perceptions of reality into a formal model of this perception. It follows that a key element in IS design methodologies is the provision of a suitable Chapter 3. An Ontological Basis for Conceptual Modelling 50 modelling tool for describing reality. • Design: From the model of reality to a model of a representation. • Implementation: From a model of the information system into a realization of the information system. In their view, one important (though certainly not the only) measure of an information system depends upon the "goodness" of the representation of the real world. As a result, a formalization of "goodness of representation" is an important objective. They do this by positing characteristics, termed "invariants", which must be preserved during these transformations for a representation to qualify as a good design. Their modelling formalism is an adaptation of some of the concepts and the formal notation used by Bunge in his system of ontology. Pertinent details of Bunge's ontology will be presented in the next section of this chapter. For now, a general overview of Wand and Weber's interpretation of Bunge's approach can be summarized here as follows: • It is assumed that the real world is made of things, which have properties. 2 Things can be composed of other things, that is, things have a composition. • It is assumed that things can be modelled by what Bunge calls a functional schema, ie. a set of functions which assign values to its properties. • A combination of property values comprises the state of a thing and the set of pos-sible states that a thing may assume is termed the state space of a thing. A specific information system will normally not attempt to model all the properties of a thing. The values for some particular set of properties of interest is the state vector, which 2Bunge's use of terms such as thing, property, state and so forth, have formal definitions which will be presented later in this chapter. er 3. An Ontological Basis for Conceptual Modelling 51 contains all necessary structural information about the thing as required by the system. The dynamics of a thing are modelled by state changes, called events. An event is fully defined by the pre- and post-states of a thing. The set of states over time is called the history of the thing. Two things are said to interact if their histories are not independent. A system is a set of interacting things. Interactions among things constrain the possible states of things in the system. Things that interact with the system but are not included in the composition are called the environment of the system. System dynamics are formalized by the concept of stability. Wand and Weber assume that 1. a change of state will happen if and only if the system assumes a state that is not a stable state. 2. a system in an unstable state will change to a stable state which is uniquely defined by the unstable state. Rules or laws define the possible unstable/stable pairs of states of the system and hence describe the behaviour of the system. An external event occurs when the environment forces the system to change from a current stable state to a new one. If the new state is unstable, internal events or system responses move the system to a stable state. From the systems point of view, then, the dynamics of the system are described in terms of the sequence stable state —> external event —> unstable state —• internal event (or system response) —> stable state. Chapter 3. An Ontological Basis for Conceptual Modelling 52 Based on these concepts, a full description of the statics and dynamics of a system is given by the pair < S,L > where S is the possible state space of the system and L is the set of system laws. In practice, external events are limited to a subset of relevant events, hence, the formal scheme is a triple < S,L,E >. In the model, the "goodness of representation" of the information system is its ca-pacity as a state tracking mechanism, that is a mechanism whose states reflect the states in the real world. Four conditions are presented as necessary for an information system to qualify as a "good representation". • Mapping requirement. A l l real-world states of interest must be mappable into the IS states. • Tracking requirement. When an event occurs in the real-world, the sequence of real-world state changes initiated by that event must have a correspondence in the sequence of IS state changes. • Reporting requirement. A l l real-world events of interest must be reported to the IS. • Sequencing requirement. The sequence of reporting events in the IS must be the same as the corresponding sequence of events in the real world. Wand and Weber claim that this model also explains fundamental concepts and intu-itions in IS which have been used intuitively by practitioners. For example, definitions of transaction processing, management reporting and real-time systems are usually based on how systems are used. According to the model, however, transactions processing systems are seen as transformations of states according to system laws in response to transaction events. Management reporting and decision support systems are seen as models of the decision situation. Real time implies that any real event must be reported to the information system and processed before the next real event occurs. Chapter 3. An Ontological Basis for Conceptual Modelling 53 W a n d a n d W e b e r suggest the fo l l owing advantages for this m o d e l . • T h e r e is a n o n t o l o g i c a l basis for m o d e l l i n g b o t h r e a l i t y a n d the IS . • T h e m o d e l stresses l aws r a the r t h a n processes a n d a c t i v i t i e s . T h e advan tage o f l aws are tha t they are tes table for cons i s tency a n d comple teness . • T h e m o d e l fo rmal izes the n o t i o n of sys t em d e c o m p o s i t i o n . • T h e m o d e l c a n c o m p a r e methodo log ies i n d e p e n d e n t l y of i m p l e m e n t a t i o n . • T h i s a p p r o a c h p rov ides a basis for a u t o m a t e d ana lys i s a n d des ign . 3.2.3 Wand's Ontological Model of Objects A f o r m a l m o d e l of objects based o n B u n g e ' s o n t o l o g y has been p roposed i n [ W a n d , 1989]. W a n d suggests tha t ob jec t -or ien ted p r o g r a m m i n g suffers f r o m c o n c e p t u a l p rob l ems because the n o t i o n of objects "emerged as p r o g r a m m i n g concepts a n d , therefore, were d r i v e n b y i m p l e m e n t a t i o n cons ide ra t ions" . H e advocates t a k i n g a m o d e l l i n g ra the r t h a n a p r o g r a m m i n g pe r spec t ive to the object p a r a d i g m a n d looks to o n t o l o g y to p r o v i d e the bas ic p r i nc ip l e s for a theo ry o f objects . In c o m p a r i n g B u n g e ' s o n t o l o g y to the object concept i n ob jec t -o r i en ted p r o g r a m m i n g languages ( O O P L ) , he finds some i m p o r t a n t r e l a t i onsh ips . • T h e p r inc ip l e s of encapsulation, independence, a n d persistence are f u n d a m e n t a l to b o t h O O P L a n d O n t o l o g y ; • Message passing, also a basic concept i n O O P L , is no t a n i n t r i n s i c o n t o l o g i c a l concep t . Messages c a n be v i e w e d as one (perhaps ou t of m a n y ) m e c h a n i s m for interaction i n O n t o l o g y bu t not a bas ic p r i n c i p l e ; Chapter 3. An Ontological Basis for Conceptual Modelling 54 • Classic OOPL's such as Smalltalk are characterized by homogeneity in that every-thing in the language is an object. Ontology does not insist on this principle; • Class inheritance in O O P L has parallels in Bunge's theory of kinds which are classes of things in the world which share common properties and laws. In Bunge's system, the collection of kinds is a lattice under inclusion which, in Wand's view, parallels the concept of inheritance in OOPL. Wand proposes a formal model of objects which includes the following characteristics. • The world is made up of objects with properties and laws. • Objects can be composite and possess hereditary (ie. inherited from its components) or emergent (ie. unique to the composite object) properties. • Objects interact with each other and can affect each other's states. • State transitions in objects are described as events. Objects switch states until they are in some lawful or stable state. This model distinguishes clearly between the use of object as a modelling construct and an implementation or programming construct. And it has been acknowledged as an important initial step toward a formal and precise theory of objects based on ontologi-cal principles [Kilov, 1989]. This thesis shares the same approach and is motivated by many of the same considerations as Wand's model. There are, however, some significant differences. • Wand's model is a general theory of objects which stresses first principles and overall approaches. This thesis proposes an operationalization of Bunge's Ontology in the context of Information Systems Development. There are, therefore, significant differences in level of detail and purpose. Chapter 3. An Ontological Basis for Conceptual Modelling 55 • The model proposed in this thesis provides both a written and visual notation as well as an implementation framework which are not considerations in Wand's work. • The proposed model develops principles for object interaction, object change, and end-user interfaces. Wand's model was not intended to consider these issues in any detail. 3.3 Bunge's Ontology In the opinion of this thesis, Bunge's ontological system is compatible with IS concep-tual modelling by virtue of its rigorous formalism, its commitment to realism, and its methodical distinction between reality and representation of reality. The value of Bunge's work has been acknowledged by others for its (1) completeness, (2) rigorous formalization, (3) respect for the results of science as well as the needs of society, (4) recognition of emergent properties, and (5) wide acceptance among practicing scientists [Mattessich, 1986; Mattessich, 1982]. Moreover, as observed by Wand [1989], Bunge's objectives for a formal ontological theory are especially relevant to any attempt at developing a theoretical basis for information systems development: Metaphysics can dig up, clarify, and systematize some basic concepts and prin-ciples occurring in the course of scientific research and even in scientific theories... Metaphysics can render service by analyzing fashionable but obscure notions such as those of system, hierarchy, structure, event, information...[Bunge, 1977, pp. 23-24]. In the remainder of this chapter, features of Bunge's ontology salient to a theory of object-oriented conceptual modelling are summarized and interpreted. This material is drawn from [Bunge, 1977] and [Bunge, 1979]. Chapter 3. An Ontological Basis for Conceptual Modelling 56 3.3.1 B a s i c A s s u m p t i o n s Bunge's basic ontological assumptions about the world are stated as follows 3 1. There is a world external to the cognitive subject. If no such world existed, it would not be subject to scientific inquiry. 2. The world is composed of things. Consequently, the sciences of reality (natural or social) study things, their properties and changes. 3. Forms are the properties of things. We study and modify properties by examining things and forcing them to change. Properties are. represented by predicates (eg. functions) defined on domains that are, at least in part, sets of concrete objects. 4. Things are grouped into systems or aggregates of interacting components. There is no thing that fails to be part of at least one system. There are no independent things: the borders we trace between entities are often imaginary. What there really is, are systems - physical, chemical, living, or social. 5. Every system, except the universe, interacts with other systems in certain respects and is isolated from other systems in other respects. Totally isolated things would be unknowable. And if there were no relative isolation we would be forced to know the whole before knowing any of its parts. 6. Every thing changes. 7. Nothing comes out of nothing and no thing reduces to nothingness. Assumptions Ml - M10 [pp. 16 - 17]. All references to Assumptions, Definitions, Postulates, and Theorems are to [Bunge, 1977] unless otherwise specified. Chapter 3. An Ontological Basis for Conceptual Modelling 57 8. Every thing abides by laws. W h e t h e r n a t u r a l or soc i a l , l aws are i n v a r i a n t re la t ions a m o n g proper t ies , a n d they are jus t as ob jec t ive as proper t ies . M o r e o v e r , a l a w is a p roper ty . 9. There are several kinds of law. T h e r e are causa l l aws a n d s tochas t i c l aws . T h e r e are same- leve l (eg. b i o l o g i c a l ) l aws a n d cross- level (eg. p sychosoc ia l ) l aws . 10. There are several levels of organization. E g . p h y s i c a l , c h e m i c a l , b i o l o g i c a l , soc ia l , t e c h n o l o g i c a l , etc. T h e so-ca l led h igher levels emerge f r o m o ther levels i n the course of processes: bu t once fo rmed - w i t h laws of the i r o w n - they enjoy a c e r t a i n s t ab i l i ty . 3.3.2 Substance, Association and Composition B u n g e begins his o n t o l o g y w i t h a theory of substance . H e assumes the exis tence of substantial individuals 4 a n d a f u n d a m e n t a l p r o p e r t y of association. F o r m a l l y , he proposes the f o l l o w i n g : P O S T U L A T E . 5 T h e r e exists a n o n - e m p t y set S a n d a b i n a r y o p e r a t i o n o such tha t : • S is the set o f a l l subs t an t i a l or concrete i n d i v i d u a l s ; • o represents the assoc ia t ion of i n d i v i d u a l s w h i c h is assoc ia t ive a n d c o m -m u t a t i v e ; • m e m b e r s of S are i d e m p o t e n t under assoc ia t ion (ie. s o s = s); • s\ o s2 o ... o sn, where s, € 5, represents a composite i n d i v i d u a l , • there exis ts a n e u t r a l o r n u l l e lement • £ S such tha t for a n y x £ S, X o • = x. 4Ie. concrete or material things. Postulate 1.1. Chapter 3. An Ontological Basis for Conceptual Modelling 58 Association can be either natural or man-made. For example, one view of o is the "putting together of perceptible things by somebody" [P. 29]. The fundamental property of association is a step toward complexity6 and is formalized in the concept of composition. DEFINITION.7 An individual x is composite iff it is composed of individuals other than itself and • . Ie. 1. x ± • , 2. x e S, 3. there exists y, z £ S, 4. x^y,x^ z, 5. x = y o z. Otherwise, the individual is simple. A related term, part-of is defined as DEFINITION.8 For x,y e 5, x is part-of y iff x o y — y. In symbols, x c y. The relation c is also called the whole-part relation. The composition of an individual is the set of its parts. DEFINITION.9 The composition of an individual equals the set of its parts. Ie., let C:S —> 2 5 be a function from individuals into sets of individuals, such that C(x) = {y G S\y c x) for any x e S; then C(x) is called the composition of x. 6Ie. complex things. 7Definition 1.1. definition 1.2. 9 Definition 1.6. Chapter 3. An Ontological Basis for Conceptual Modelling A number of consequences flow from the definitions above. COROLLARY. 1 0 The totality S of substantial individuals is partially ordered by the part-whole relation c . Ie., < S, C > is a poset (partially ordered set). and THEOREM. 1 1 The association of any two individuals is the suprenum (least upper bound or l.u.b.) for them with respect to the part-whole ordering: If x, y £ 5 then sup{x, y) = x o y. This concept of suprenum can be generalized by POSTULATE. 1 2 Every set T C S of substantial individuals has a suprenum, which is denoted by [T]. Ie., for any T C S, there exists an individual [T] £ S such that L i e [T] for all x £ T; 2. if y £ S is an upper bound of T, then [T] precedes y, ie., if x c y for all x E T, then sup T = [T] c y. DEFINITION. 1 3 Let T C S be a set of substantial individuals. Then the aggregation or association of T, or [T] for short, is the suprenum of T. Ie., [T] = supT. THEOREM. 1 4 The world o is the aggregation of all individuals: o = [S] = sup S. 10Corollary 1.2. "Theorem 1.1. Proofs for all theorems from Bunge are found in Appendix A. "Postulate 1.3. "Definition 1.7. "Theorem 1.2. Chapter 3. An Ontological Basis for Conceptual Modelling 60 T H E O R E M . 1 5 The ordered quadruple < 5, o, o, o > is a sup-semilattice with least element • and last element o with respect to the part-whole relation c (refer to Figure 3.1 adapted from [1977, p. 33]). Bunge recognizes that the notion of composition is too general for most purposes. Therefore, he introduces the concept of B-composition and A-composition. P O S T U L A T E . 1 6 There is a proper subset B of S such that every substantial individual is the aggregation of members of B. Ie., for every x £ S other than the null individual, there is a unique subset Bx C B such that x = [Bx\. This is, of course, the axiom of atomism expressed in terms of Bunge's association theory. Another refinement of the notion of composition is: DEFINITION. 1 7 Let A C S be a set of entities. Then the A-composition (or composition at the A level of a substantial individual x £ S is the set of parts of x belonging to A: CA(x) = C(x) n A = {y £ A\y c x}. Bunge uses the example of molecular composition of a body of water as the set of H2O molecules. On the other hand, the atomic composition of the same body of water is a set of H and 0 atoms. Bunge presents the notion of a level as follows: ...we may split the totality S of entities into a certain number n of disjoint sets A{, each member of which is composed...by entities of the next lower level 1 5Theorem 1.3. 1 6Postulate 1.4. 1 7Definition 1.15. Chapter 3. An Ontological Basis for Conceptual Modelling 61 At. i-1 . The levels hypothesis may then be formulated as follows: ri n S = U Ai, fl Ai = 0, with Ai = {< |n € N} «=1 i=l and a •i = [«?_!], where a?_i C A, 3.3.3 Form Bunge then proceeds to develop a theory of form. His position with respect to form is stated as a basic assumption: Forms are properties of things. There are no Platonic Forms in themselves flying above concrete things. This is why (a) we study and modify properties by exam-ining things and forcing them to change, and (b) properties are represented by predicates (eg. functions) defined on domains that are, at least in part, sets of concrete objects [ 1 9 7 7 , p. 16]. For Bunge, all (concrete) entities have properties. A distinction is made between prop-erties of substantial or concrete entities, called substantial properties or simply properties, and properties of constructs, call formal properties, predicates, or attributes. Substantial properties are possessed by substantial individuals even if we are ignorant of them. In contrast, an attribute is a feature we assign or attribute to an object. A correspondence can exist between attributes and properties in that an attribute can reflect or represent a property. However, the correspondence is not necessarily isomorphic. Some attributes may not represent any substantial properties, others may represent several, and there may exist properties to which we assign no attributes (either by ignorance or design). We know properties through their attributes and we distinguish between them by a representation function Chapter 3. An Ontological Basis for Conceptual Modelling 62 p : P - » 2 A where P is the set of substantial properties and 2 A is the power set of attributes A . That is, "the representation function is a correspondence between a proper subset of all conceivable attributes and the ill-defined set of all (known and unknown) substantial properties [1977, p. 60]". There can be, of course, attributes with no ontic correspondence such as set membership, disjunction and negation. More formally, Bunge presents the following: P O S T U L A T E . 1 8 Let S be the set of substantial individuals or some subset thereof, and let T to Z be arbitrary nonempty sets, equal to or different from S. Then 1. any substantial property in general is representable as a predicate (or propositional function) of the form A : S x T x ... x Z —• Propositions including A,19 2. any individual substantial property or property of a particular substantial individual s £ 5, is representable as the value of an attribute at s, ie. as A(s, t , z ) where t £ T...Z £ Z. Implicit in this postulate are the following: 1. Properties are attributable to individuals, ie. properties do not exist on their own. 2. Entities possess properties but are not "bundles" of properties. Specifically, an entity is not a set of properties. That is, a notion of identity exists which is independent of properties. 18Postulate 2.1. 19Bunge's example involves the property of being able to read represented by the function R, the set of humans H, and the set of propositions containing the predicate R such that R : H —» P where R(b) for b G H means "6 can read" and R(b) £ P. Chapter 3. An Ontological Basis for Conceptual Modelling 63 Bunge defines the scope of a substantial property as the collection of entities possessing it. DEFINITION. 2 0 The scope of a substantial property is the collection of entities possessing it. In other words, the scope S is the function S: P —> 2s from the set of all substantial properties to the set of all the subsets of substantial individuals, such that ux £ S(P)n, for x £ S, is interpreted as "Individual x possesses property P ". Bunge postulates a special class of properties called laws. He assumes that "all entities satisfy some laws" and the following P O S T U L A T E . 2 1 Every substantial property is lawfully related to some other substantial property. Since laws interrelate substantial properties, laws themselves are properties of entities. For composite individuals, global properties characterize the entity as a whole. There are two types of global properties: hereditary or resultant, possessed by at least one part of the whole; and emergent, possessed by the whole but no component. More formally, DEFINITION. 2 2 Given some entity a; £ S with properties p(x) and composition C(x). Let P £ p(x) be a property of x. Then, P is a resultant ox hereditary property of x iff P is a property of some component y £ C(x) ol x other than x; otherwise P is an emergent property of x. That is, 1. P is a resultant or hereditary property of x iff there exists y £ C(x), y^ x, such that P is a property of y. 2 0Definition 2.5. "Postulate 2.7. "Definition 2.16. Chapter 3. An Ontological Basis for Conceptual Modelling 64 2. P is an emergent property of x if there is no y 6 C(x), y / x, such that P is a property of y. 3.3.4 T h i n g and M o d e l T h i n g A substantial individual endowed with all its properties is called a thing. Formally, Definition 3.1. Let x € S be a substantial individual and call p(x) the col-lection of its properties. The individual together with its properties is called the thing X, ie.: X =d}< x,p(x) > . For Bunge, "there are constructs, ie. creations of the human mind to be distinguished not only from things...but also from individual brain processes". This distinction between things and constructs is made in the following postulate: POSTULATE. 2 3 Every object is a thing or a construct; no object is neither and no object is both. Theoretical science, ontology and information systems do not usually deal with things directly, but with perceptions or representations of things. Bunge formalizes a theory of representation by defining the notion of model thing: DEFINITION. 2 4 Let X =< x,p(x) > be a thing of class T. A functional schema Xm of X is a certain nonempty set M together with a finite sequence F of nonpropositional functions on M, each of which represents a property of T's. That is, "Postulate 3.4. 24Definition 3.6. Chapter 3. An Ontological Basis for Conceptual Modelling 65 Xm = M where F =< Fi\Fi: is a function on M >. The following postulate relates the set of functional schemata to reality: POSTULATE. 2 5 Any thing can be modelled as a functional schema. For any representation Xm, Bunge defines the concept of state. DEFINITION. 2 6 Let X be a thing with functional schema Xm = < M , F >. For any F, £ F , F,; : M —> Vi, where K is the domain of values for the property represented by Fi. Fi are the state variables or state functions for X in the representation Xm. F is the total state function for X and its value F(m) =< FuF2,...,Fn > (771) =< F1(m),F2(m),...,Fn(m) > for m £ M is said to represent the state of X at m in the representation Xm. According to this conceptualization, there are no 'absolute' state functions, only state functions in a specified representation. There can be as many state functions as functional schemata, ie. different ways of conceiving a thing. Even within a specified functional schema, there are many choices of systems of units, each possibly leading to a different state function. As Bunge states, The sole test for the adequacy of a choice of state functions is the adequacy (factual truth) of the theory as a whole, in particular that of its key formulas, which are those interrelating the various components of the total state function - namely the law statements and constraint formulas of the theory... "Postulate 3.4. 26Definition 3.9. Chapter 3. An Ontological Basis for Conceptual Modelling 66 Bunge also points out that ...[The] choice of state functions is not uniquely determined by empirical data but depends partly on our available knowledge, as well as upon our abilities, goals, and even inclinations [1977, p. 127]. 3.3.5 Laws and Lawful State Space State functions represent properties. Laws are represented by law statements. DEFINITION.27 Let Xm =< M, F > be a functional schema for a thing X. Any restriction on the possible values of the components of F and any relation among two or more such components is called a law statement!^ (1) it belongs in a consistent theory about the X ' s and (2) it has been confirmed empirically to a satisfactory degree. That is, a law statement L(x) can be represented as a value of a certain function L, a law function which has as domain a class T of things and codomain the set of laws, ie. L : T —> L(T) where T is the set of things possessing laws L. Further, the notion of lawful state space is defined as DEFINITION.28 Let Xm =< M, F > be a functional schema for thing X where F :< Fi, F 2 , F n >: M —> Vi x V2 x ••• x V„ is the state function, and call L(X) the set of all law statements of X. Then the subset of the codomain V =< V\ x V2 x ... x Vn > of F restricted by the conditions (law statements) in T-i(X) is called the lawful state space of Xin the representation 2 7Definition 3.10. 2 8Definition 3.11. Chapter 3. An Ontological Basis for Conceptual Modelling 67 Xm or Si,(X) for short: SL{X) = {< xux2,...,xn >e VixV2x ... x Vn\ F satisfies jointly every member of L ( X ) } , and every point of Si(X) is called a lawful (or really possible) state of X in the representation Xm. 3.3.6 Class and Natural Kinds Bunge develops an ontological theory of class as follows. As previously defined, the scope of a property, S, is the set of things possessing it. That is, given a property P, S(P) = {x\P € p(x)}. A class then is defined as DEFINITION.29 A subset X of things is called a class iff there exists a property P such that X is the scope of P, ie. X = S(P). The intersection of any two classes of things, if nonempty, is also a class. DEFINITION.30 Let 0 be the set of all things. Further, let k : 2 P —• 2 e , be the function assigning to each nonempty set R 6 2 P of substantial properties the set = n s(P) of things sharing the properties in R. This value &(R) is called the H-kind of things. 29Definition 3.14. 30Definition 3.17. Chapter 3. An Ontological Basis for Conceptual Modelling 68 If R is finite, the corresponding R-kind is a class. That is, given R = {Pi,P2, . . . ,P„} , *(R) = f | S(Pi) = S(PX A P 2 A ... A P n ) , The notion of R-kind allows a definition of equivalence. DEFINITION. 3 1 Let R be a set of substantial properties. Then two things £ 0 are said to be R-equivalent, or equal in every respect P G R, iff they possess precisely the same properties in R: x ~R V —df (P)(P G R =4> {x possesses P y possesses P)) or equivalently x ~ny =df p(x) n R = p(y) n R. R-kinds are defined with respect to a subset R of properties. A more restrictive notion of equivalence is the natural kind, defined with respect to subsets of laws (which are also properties). That is, DEFINITION. 3 2 Let L be the set of laws and let k : 2 L -* 2® be the function assigning to each L,- C L of laws the set fc(L,-) = f | S(L) Lei, of entities sharing the laws in L ; . This value fc(L,-) is called the L-species or natural kind. This leads to the concept of nomological equivalence: 3 1Definition 3.18. 3 2Definition 3.21. Chapter 3. An Ontological Basis for Conceptual Modelling 69 DEFINITION. 3 3 Let x and y be two things and L , C L a set of laws. Then x and y are nomologically equivalent relative to L , iff x and y share all their species-specific properties, ie. all the laws in L , : x ~L, y =df p(x) n L i = p(y) n L , . Bunge asserts that the preceding provides a theory of reality We now have a theory of properties, distinct from the theory of predicates, and a theory of kinds, different from the algebra of sets. We can therefore use without qualms the concepts of a property and a kind. The differences between predicates and properties, and between sets and kinds, suffice to ruin the ontological interpretations of logic and of set theory. There is no reason to expect that pure mathematics is capable of disclosing, without further ado, the structure of reality [p. 150]. 3.3.7 Change, Event and Interaction Bunge begins his theory of change with a theory of possibility. Every "actual thing has some actual properties and others which it may - or may not - acquire [1977, p. 163]". That is, if a change occurs then it was possible to begin with. This possibility is one of the properties of the thing undergoing change [1977, p. 164]. Bunge links possibility to lawfulness, something is possible iff it is lawful. Therefore, "every law statement describes possibles [1977, p. 174]". Change is seen as a construct which cannot be separated from things. A change is an event or process, whether quantitative or qualitative or both. Whatever its nature, a change is a modification in or of some thing or things: more 33Definition 2.23. Chapter 3. An Ontological Basis for Conceptual Modelling 70 precisely, it consists in a variation of the state of an entity. To put it negatively, there is no change separate from things - nor, indeed, are there changeless things even though some change slowly or only in certain limited respects [1977, p. 215]. Bunge bases his theory of change upon the concept of state space, that is, change is seen as a transition of a thing from one state to another. As such, his concept of change does not require detailed knowledge of the nature of the thing involved nor does it make explicit use of the time concept. Further, since states are representations of properties, our knowledge of states, and hence change, depends to some extent upon ourselves and the state of the art. Recall the concept of the lawful state space of a thing in which every point in the space represents a lawful state of the thing. The actual state of the thing is represented by a specific point, the representative point, in the state space. A change in the thing can be represented by a trajectory of the representative points (see Figure 3.2 adapted from [1977, p. 218]). Bunge presents as a basic postulate, the following: POSTULATE. 3 4 Every thing has at least two distinct states. That is, all (concrete) things are changeable. Representing changes as state transitions (as opposed to turning into different things) allows Bunge to adopt that he calls the principle of nominal invariance, which may be stated as: PRINCIPLE. 3 5 A thing, if named, shall keep its name throughout its history as long as the latter does not include changes in natural kind - changes which call for changes of name. 34Postulate 5.1. 35Principle 5.1. Chapter 3. An Ontological Basis for Conceptual Modelling 71 This implies, of course, that the state space of a thing must include all of the latter's possible states, from beginning to end. Since state spaces are representations, the prin-ciple of nominal invariance allows the designation of a permanent identity, even if the components of a thing change (eg. a given person is identified by the same name from age 5 to age 50, even if every atom in the physical body has been renewed over the years). A change of state is called an event Events are represented by the ordered pair < s\,S2 > where Si and s2 are the states before and after the change. Given a thing X with lawful state space Si(X), the set of all possible events is E(X) = S(X) x S(X). This includes the identity event that results in no change, ie. < Si,s2 > where s i = s2. Further, two or more events can combine to produce a complex event or process, ie. < s\,s2 > o < s2,s3 >=< S \ , S 3 > . These concepts can be summarized by D E F I N I T I O N . 3 6 Let S(x) ^ 0 be a state space for a thing x and let E(x) = S(x) x S(x). The triple E =< S(x), E(x), * >, where * is a partial (not every defined) binary operation in E(x) such that, for all a, b,c,d in S(x), { < a,d > iib = c not defined if 6 ^  c, is the event space of x associated with S(x) iff 1. every element of E(x) represents a conceivable change of (or event in) thing x; 2. for any e, / € E(x), e * f represents the event consisting in that event e composes with event / in the indicated order; 3 6Definition 5.4. Chapter 3. An Ontological Basis for Conceptual Modelling 3. for any s G S(x), < s,s > G E(x) represents the identity event (or non-event) at s, ie. the staying of x in state s. Two special cases are dealt with as follows: CO R O L L A R Y . 3 7 Let s,s' G S(x) be states of x. Then 1. no event other than an identity event is immediately repeatable: < s, s' > * < s, s' > is not defined in E(x); 2. if an event is followed by its converse then no net change results: < s,s' > * < s',s >=< s,s >. A concept of precedence is developed as follows. DEFINITION. 3 8 Let e and e' be two events in a given event space, ie. e, e' € E(x) for some thing x, such that e and e' compose to form a third event e" = e * e'. Then, e is said to precede e' relative to the reference frame involved in E(x): If e, e' G E(x) then e -< e' =df e * e' G E(x). And Collorary. 3 9 For any given thing x and every state representation, < E(x), •<> is a strictly partially ordered set. A mechanism for an event < s\, s2 > can be described by functions which are laws transformations of the state space Si,(x) compatible with the laws of x. That is, 3 7Corollary 5.4. 3 8Definition 5.7. 3 9Collorary 5.5. Chapter 3. An Ontological Basis for Conceptual Modelling 73 DEFINITION. 4 0 Let Si,(x) be a lawful state space for a thing x. Then the family of lawful transformations of the state space into itself is the set of functions GTJ(X) — {d is a function | g : S L —• SL(X) & g is compatible with the laws of x}. Since change can thus be represented as a series of successive states, a concept of history is now defined as DEFINITION. 4 1 Let F be a state function for a thing x which includes in its domain T , the set of time instants. Then, the history of x during the interval T G T is the set of ordered pairs h(x) = {< t,F(t) > \t G r } . The principle of change does not consider sources of change. Bunge recognizes spon-taneous change in a thing or change in a thing induced by other things. 4 2 Induced change can be defined as DEFINITION. 4 3 Let x and y be two different things with state functions F and G respectively relative to a common reference frame / , and let h(x) = {< t, F(t) >\te S(f)}, and h(y) = {< r, G(t) > |t G S(f)} be their respective histories. Further, let H = g(F, G) / G be a third state function, depending upon both F and G , and call % | x ) = {<r ,H(<)> |<€S( / )} 40Definition 5.8. 41Definition 5.27 and [1979, p. 24]. Bunge's definition 5.7 is in terms of a time/space frame of reference in four dimensions. 4 2 This thesis will be concerned only with induced change. 43Definition 5.29. Chapter 3. An Ontological Basis for Conceptual Modelling 74 the corresponding history. Then, x acts on y, or x t> y for short, iff, for some state function H determining the trajectory h(y\x),h(y\x) / h(y). Further, DEFINITION. 4 4 TWO different things x and y interact iff each acts upon the other. In symbols: x M y =dj x t> y & y t> x. DEFINITION. 4 5 TWO different things are bonded (ox linked ox coupled) together iff at least one of them acts upon the other. In symbols: If x and y are things, then Bxy =df x i> y or y t> x. The above provides the basis for the following. DEFINITION. 4 6 Let X be a thing composed of parts Xi for 1 < i < n. Then X is an aggregate (or conglomerate or heap) iff, in every representation of X (ie. for every choice of state functions), its history h(X) equals the union of the partial histories h(X{). Otherwise, X is a system. 3.3.8 Spacetime Bunge then proceeds to demonstrate that the above principles are sufficient for a theory of spacetime. Space and time are usually regarded as external to things and their changes. That is, they are seen as " a fixed scenario... absolute, autonomous, and self-existing [pp. 276-277]". Bunge, however, argues that space and time result from things. 4 4Definition 5.30. 4 5Definition 5.33. 4 6Definition 5.35. Chapter 3. An Ontological Basis for Conceptual Modelling 75 For, in the absence of things, there should be no spatial relations; and in the absence of change there should be no temporal relations. Bunge begins his theory of space47 with a formal definition of interposition or between-ness based on the fundamental principles of thing and change.48 From this definition, he develops a formal notion of a separation function o between any two arbitrary things.49 Finally, he defines space as DEFINITION.50 The set B of basic things, together with the separation func-tion o, is called the thing space, abbreviated d =< B,o >. In other words, the thing space is nothing but the collection of spaced things, or the set of things related by their mutual separations. The idea of a changing thing is also the basis for Bunge's theory of time. A duration is the duration of some event or process: a changeless universe would be timeless. Just as space is the spacing of things, so time is the pace of events. And just as spatial distance is the separation among things, so temporal interval is the separation between different states. This is the intuitive germ of the relational theory of time [pp. 296-297]. Bunge's theory of time begins with a definition of temporal ordering which is based on the ordering relation among the different states of a thing.51 Definitions of past, present, and future of some thing x are developed relative to a distinguished zero or origin state 47Bunge's theory of spacetime is not directly relevant to this thesis. Therefore, definitions and postu-lates are not detailed here. 48Postulate 6.1. 49Definition 6.1. 50Definition 6.2. 51Postulates 6.7 k 6.8. Chapter 3. An Ontological Basis for Conceptual Modelling 76 of x.52 A potential clock is defined as a thing in which every one of its state spaces is strictly partially ordered. 5 3 A n important conclusion resulting from these principles is COROLLARY. 5 4 There is no time where there are no changing things. 3.4 S u m m a r y This chapter has presented the motivation for the use of Ontology as the basis for an object-oriented model for ISD. Some previous work applying ontology to Information Systems was discussed. It has also briefly outlined the definitions and propositions of Bunge's formal system of ontology. The next chapter develops an ontology-based conceptual modelling scheme which is based directly on these metaphysical principles. "Definition 6.8. 5 3Definition 6.9. By "strict partial ordering", Bunge means asymmetric and transitive. Most things can, therefore, be considered to be clocks. Nor do clocks need to be regular. 5 4Corollary 6.3. Chapter 4 Ontology-Based Conceptual Model - O B C M This chapter proposes the Object-Based Conceptual Model (OBCM) , a system for the conceptual modelling of IS applications. O B C M is an approach to conceptual modelling which is based directly on Bunge's ontological formalism presented in the previous chap-ter. The formal description of Ontology-Based Conceptual Modelling is developed as fol-lows. First, the main premises from Bunge upon which O B C M is based are highlighted. Next, details of O B C M are described, in particular the three major constructs surrogate, model object and object. Two different notations for O B C M are proposed: a formal writ-ten notation, and a somewhat more informal visual notation. Examples are presented to illustrate the conceptual material. The chapter concludes with a comparative analysis of O B C M to other, well-known modelling schemes. O B C M is independent of implementation. In chapter 5, a framework is introduced for implementing an Ontology-Based Information System (OBIS) based on O B C M . 4.1 Background The following premises from Bunge form the backbone of O B C M . 1. The world consists of things which possess both substance and form (ie. properties).1 definitions 3.1 & 3.2. All references to Definitions, Postulates, and Theorems in the footnotes are to [Bunge, 1977] unless otherwise stated. 77 Chapter 4. Ontology-Based Conceptual Model - OBCM 78 2. Things are characterized by properties. Known properties are represented by one or more attributes, ie. concepts or values assigned to things by people.2 Some properties are well-known, others are unknown and subject to further investigation. Further, the relation between properties and attributes is not necessarily isomorphic (ie. not one-to-one). 3. Things possess a fundamental property of association (symbol o),3 which is the basis for forming complex things. Two or more things can associate to form another thing separate from the originals.4 4. Assume x and y associate to form z, ie. x o y = z, then x and y are said to be part-of z (written x,y c z).5 For the purposes of modelling, a null element o is assumed such that • O X — X. 5. A thing x is composite if it is composed (ie. is an association) of more than one thing other than itself and null. Otherwise, it is simple. The composition of a thing is defined as the set of its parts. More specifically, given a set of things T and a function, C, such that C : T -» 2T where C(x) = {y e T\y c x} Postulate 2.1. 3Not related to the abstraction mechanism of association found in semantic data models. 4Definition 3.3 and Postulate 3.2. definition 3.4. Chapter 4. Ontology-Based Conceptual Model - OBCM 79 for any x £ T, then C(x) is the composition of x.e In the case of a simple thing x, x c x and the composition of x is {x} (ie. a; has no parts other than itself). 6. The A-composition CA of a thing x is defined as the set of parts of x belonging to some set A. That is, given x and its composition C(x), CA(x) = C(x) n A = {y £ A\y c *}. The A-composition is composition relative to a certain set or level of things. For example, the molecular composition of a body of water is some set of H20 molecules. On the other hand, the atomic composition of the same body of water is a set of H and O atoms.7 7. For composite individuals, global properties characterize the entity as a whole. There are two types of global properties: hereditary, possessed by some part of the composite; and emergent, possessed by the whole but not any component of the whole. Given some entity x £ S with properties p(x) and composition C(x), let P £ p(x) be a property of x. Then, P is a resultant ov hereditary property of x iff P is a property of some component y £ C(x) of x other than x; otherwise P is an emergent property of x. That is, • P is a resultant or hereditary property of x iff there exists y £ C(x), y ^ x, such that P is a property of y. • P is an emergent property of x if there is no y £ C(x), y ^ x, such that P is a property of y.8 definition 1.6. 7Definition 1.15. definition 2.16. Chapter 4. Ontology-Based Conceptual Model - OBCM 80 8. Properties are interrelated by relations called laws which are also properties of things.9 9. There exists a thing o such that every other thing is a part of o. o is called the world or universe.10 Assuming some null thing • such that a o x = x, and the set of all things T, the totality of < T, • , o, o > is a sup-semilattice11 structure with last element o and least element • with respect to the part-whole relation c. 1 2 10. The scope of a property is the collection of things possessing that property. 1 3 A class of things are those things in the scope of a property or set of properties.1 4 A kind is a class in the scope of a set of properties and laws. 1 5 11. A thing of some class T can be represented by a functional schema which is a dual < M, F > where M is a base set and F a set of functions on M , each of which represents a property of T. The base set M can be interpreted as a means of parameterizing the functions in F according to the purpose of the representation. It can be, for example, a set of time instants or a mapping to some subset of spacetime. Each function in F is evaluated at a fixed x G T in addition to other variables in M . 1 6 definition 3.10. 10Postulate 3.3. n A n ordered set (M,C) is called sup semi-lattice if M contains an upper limit of any two elements [Gericke, 1966]. 1 2Theorem 3.1. The nodes of the semi-lattice represent things and the edges represent the part-whole relations among the things. The lattice structure ensures an access path from any thing in the lattice to either o or O. The significance of this will be explored later. "Definition 3.13. "Definition 3.14. 15Definition 3.21. 16Definition 3.6. Chapter 4. Ontology-Based Conceptual Model - OBCM 81 An example from Bunge is that of population, an important property of commu-nities which changes constantly with time and can be represented as Pop : E x R —> N in which E is the set of all communities, M = R is the real line representing time instants, and N the set of natural numbers. 12. Law statements express relationships among the functions in F or restrictions on their values.17 13. The state of a thing in some representation < M , F > is the value F (m) or < Fi(m), F2(m),Fn(m) > where m € M 1 8 14. An eventis a change in state which can be represented as an ordered pair < s 1 ? 52 > where si and s2 are the states before and after the change respectively. Events can also be represented as a triple < s\,s2,g > where g is a function such that s2 = d(si)- The function g may or may not be a law statement. For any thing x, there is a set E(x) of possible events, which describes all possible changes in x. E(x) is a partially ordered set.19 15. Given some class of things T and its representation < M, F > where M includes the set of time instants T, the history of a thing t G T during the interval r C T, is the set of ordered pairs20 h(x) = {< t,F(x,t) >\te T}. 17Definition 3.10. "Definition 3.9. 19Definitions 5.4, 5.5 & Corollary 5.5. 20Definition 5.27 and [p. 24, 1979]. Chapter 4. Ontology-Based Conceptual Model - OBCM 82 16. A thing acts upon another if it modifies the latter's history. 2 1 A thing composed of interacting components is called a system.22 4.2 O B C M - Ontology-Based Conceptual Model The Ontology-Based (or Object-Based) Conceptual Model ( O B C M ) 2 3 operationalizes Bunge's ontological system so that it can be used to describe some "slice of reality" or Universe of Discourse of an IS application. The implementation of an application modelled with O B C M is called an Ontology-Based (or Object-Based) Information System (OBIS). Informally, O B C M can be viewed as an abstract space populated by constructs called objects, each of which is a representation of some thing in the world. A n object is a pair <surrogate, model object>, where surrogate is an entity corresponding to some specific thing in the world and model object is an operationalization of Bunge's concept of functional schema or model thing. The following sections develop the constructs surrogate, model object and object in detail. 4.3 Surrogate 4.3.1 Definition DEFINITION 4.1 A surrogate is a modelling element corresponding to some thing of in-terest in the real world.24 . 21Definition 5.29. 22More accurately, a thing is a system if its components interact in every representation (Definition 5.35). 2 3As mentioned earlier, the proposed model is both ontology-based and object-based. The acronym OBCM can be interpreted to refer to both of these aspects of the model. I^mplementation will be discussed later. For now, it may be useful to note that surrogates can be viewed roughly in the same way as abstract objects in semantic data bases and typically implemented Chapter 4. Ontology-Based Conceptual Model - OBCM 83 4.3.2 Composite Surrogates Ontology allows for things to associate to form other things. Similarly, surrogates can associate to form other surrogates. That is, given the set of all surrogates 5, there is an operation o closed on S such that for any x,y 6 S, x o y is also an element in S. Surrogates are idempotent under the o operation, ie. x o x — x. DEFINITION 4.2 A surrogate is composite if it is formed by the association of surrogates other than itself. Otherwise, it is simple. The composition of a surrogate is the set of its components. The composition of a simple surrogate is itself. DEFINITION 4.3 Assume a composite surrogate z = a o b, then a is said to be part-of z and b is said to be part-of z, or in symbols, a c z and b c z. More formally, for surrogates x and y, x C y iff x o y = y. In the world, a specific thing may be considered to be part-of several different as-sociations. For instance, a person is part-of a family, a work group, a community, and so forth. Similarly, there is nothing to prevent a surrogate from being part-of several composite surrogates. DEFINITION 4.4 The part-of context25 of a surrogate is defined as the set of surrogates to which the surrogate is in a part-of relationship. That is, if s c /, w, c, then the part-of context of s is {/, w, c}. as user transparent, system generated, internal identifiers [Hull & King, 1987]. 2 5Bunge also refers to this concept as the environment of a thing [Bunge, 1979, p. 6]. Chapter 4. Ontology-Based Conceptual Model - OBCM 84 4.3.3 Surrogate Semantics Although the set of surrogates S is closed under o, not all associations of elements in S are of interest.26 This leads to a discussion of the semantics of surrogates. Whether a surrogate is simple or composite is a matter of interpretation or perception and the purpose of the application. That is, although the thing in reality may be com-posite, its surrogate can be simple. For example, a person is composed of various parts such as blood, bone, and tissue, but its surrogate may be simple because the application is only concerned with the person as a single unit and not its parts. In addition, the nature of the part-of relation c can be interpreted broadly. It need not be viewed in simple physical or spatial terms. Bunge makes this point as follows: Indeed, an individual on our planet and another in a distant galaxy may be taken to associate to form a third individual, so that each component will be a part of the whole...[1977, p. 30]. To summarize, surrogates are substitutes for things in the real world. Ideally, there will be a one-to-one isomorphic correspondence between the surrogates in the OBCM and the things of relevance in the real world of the application. Surrogates correspond to Bunge's notion of "substantial individuals" and provide the bridging mechanism between reality and the OBCM. This reflects the fact that the OBCM (and its implementation in an OBIS) is a representation of some subset of reality, it is not the reality itself (although the implementation of the OBIS is also a real thing, or artifact, in its own right). Further, an information system normally does not deal directly with things in the world. It can, however, handle and manipulate their surrogates (or more accurately, implementations of surrogates). 26Bunge assumes that any two things can associate to form a third, hence the set of things is closed under association. However, when the things in a composition interact, the composite thing is called a system [1979, pp. 6-14]. Chapter 4. Ontology-Based Conceptual Model - OBCM 85 On the other hand, surrogates have little significant descriptive power. Descriptive power is provided by model objects and objects. 4.4 Model Object Information Systems normally do not handle concrete things but rather their representations. A concept of representation is adapted from Bunge which in this thesis is called model object. 4.4.1 Definition D E F I N I T I O N 4.5 . Given a set of things TK which share a set of properties PK and laws LK (ie.- TK is a kindj, and a set SK of surrogates in which each element corresponds to an individual in TK, a model object28 XM of TK is a named 4-tup^e < M , F , L , C > where • M is some base set appropriate to the purpose of the Information System to be implemented; • F is a list of functions called state functions or state variables with domain SK X M , each of which represents a property or properties of interest in PK', • L is a set of law statements, each of which represents a law or laws in LK and expresses a relationship among the values of one or more of the state variables in F or restricts the values of state variables; • C is a set of change functions, each of which specifies a possible change in the values of one or more state functions in F. 27Process control, embedded and similar systems will not be specifically addressed in this thesis. 28Alternate terms are simply model, or sometimes view. The notation Xm is Bunge's, presumably to suggest model of thing X. Chapter 4. Ontology-Based Conceptual Model - OBCM 86 Model object29 operationalizes Bunge's notions of model thing or functional schemata, state, law and event30 A discussion of each component of model object follows below. The Base Set M In the model, the domain of F is taken to be SK X M , where SK is the set of surrogates corresponding to the class of things TK being represented by the model object. Given a model object X m , M is a cartesian product of certain sets appropriate to the purpose of the representation Xm. Bunge does not clearly specify the components of M except in very general ways. Eg. The base set M will be denumerable or nondenumerable, as the case may be. It may or may not be thought of as mapped on a subset of physical spacetime. (In systems theory M is usually taken to be a set of time instants.) [1977, p. 120], and The domain A of the state function F of systems of kind K is the cartesian product of certain sets, such as K, the family 2E of sets of environmental items with which the members of K are coupled, the set F of reference frames, the set T of time instants, and so on [1979, p. 20]. In this thesis, M will be assumed to be at least the set of time instants T. The state functions in F, therefore, will be evaluated at some instant of time; that is, the domain of F is SK x M where M = T. In most of the examples to follow, moreover, the functions in F will always be assumed to be evaluated at the current point in time. That is, each function is evaluated at some 29The term model object corresponds to Bunge's use of the term model thing for the functional schemata of a thing. 30Definitions 3.6, 3.9, 3.10, and Principle 5 .8. Chapter 4. Ontology-Based Conceptual Model - OBCM 87 p o i n t F, (s , r ) where S £ SK a n d T is the current p o i n t i n t i m e . T h e p a r a m e t e r r w i l l n o r m a l l y be u n d e r s t o o d a n d no t e x p l i c i t l y specif ied. T h i s resul ts i n a time dependent m o d e l of the a p p l i c a t i o n . T h a t i s , the values of F m a y v a r y d e p e n d i n g u p o n w h e n the func t ions i n F are e v a l u a t e d . 3 1 O t h e r poss ib i l i t i e s for M such as frames of re fe rence 3 2 are ou t s ide the scope of th is thesis a n d w i l l not be pursued . State Function and State E a c h c o m p o n e n t F,- £ F represents a p r o p e r t y or proper t ies o f the th ings i n class TK-G i v e n S £ SK co r r e spond ing to some specific t h i n g t £ TK, a n d a state v a r i a b l e F,-represen t ing a p r o p e r t y P R , , the value of F,- at S (ie. F,(s)) represents a n i n d i v i d u a l p r o p e r t y of the t co r r e spond ing to S. T h a t i s , a p r o p e r t y in general is represented b y a f u n c t i o n F, a n d a n individual p r o p e r t y of a p a r t i c u l a r t h i n g t £ TK is representable as the va lue o f F; at s, i e . F;(s). 3 3 DEFINITION 4.6 Given a model object Xm, the set of values of the components F, £ F, F(s)=<F1(s),F2(s),...,Fn(s)> for any s £ SK is called the s ta te of the thing corresponding to s in the model XM. T h i s is d i r e c t l y a d a p t e d f r o m B u n g e ' s c h a r a c t e r i z a t i o n of the s tate c o n c e p t . 3 4 T h e carte-s i an p r o d u c t o f the codoma ins of the componen t s F, i n F is c a l l e d the conceivable state space of the m o d e l o b j e c t . 3 5 31Bunge's ontology lays the basis for a more elaborate model involving an explicit time parameter. Enhancement of OBCM with time, however, is not pursued in this thesis. 32Definition 3.6 k 5.36. 33Postulate 2.1. 34Definition 3.9. 35Definition 3.9. Chapter 4. Ontology-Based Conceptual Model - OBCM 88 I n B u n g e ' s t heo ry of f o r m , the a t t r i bu t e -p rope r ty cor respondence is no t necessar i ly i s o m o r p h i c . S i m i l a r l y , the state var iab les i n F are no t necessar i ly one- to-one w i t h the set of p roper t ies PR. H e n c e , any state va r i ab l e F , c a n represent one or m o r e proper t ies i n PK-Law Statements DEFINITION 4.7 L a w s ta tements are restrictions on the values of the components Fi G F or relationships among two or more such components?6 B u n g e uses the e x a m p l e of O h m ' s l a w for D C c i r cu i t s . A s s u m e a class o f c i r cu i t s C , a specif ic c i r c u i t c G C, a n d i t s co r re spond ing sur rogate C. O h m ' s l a w c a n be expressed i n O B C M as O h m ' s L a w = [E(c) = R(c) x 1(c)] where E is a s tate f u n c t i o n represent ing vo l t age a n d R a n d I are s tate func t ions repre-sen t ing res is tance a n d cur ren t respect ively . F o r the mos t pa r t , B u n g e is concerned w i t h natural l aws as f o u n d i n the p h y s i c a l a n d b i o l o g i c a l sciences. I n IS a p p l i c a t i o n s , i t is more l i k e l y tha t l a w s ta tements w i l l refer to business a n d soc ia l laws or r ides. A business e x a m p l e m i g h t be a l a w s ta tement ref lec t ing the p e r m i t t e d indebtedness for any cus tomer of a firm, ie . Debt Law = [debt(c) < creditlimit(c)] where C is a sur roga te represent ing some cus tomer , debt(c) is a va lue represent ing the i n -debtedness of the cus tomer a n d creditlimit(c) is a va lue represent ing the firm's p e r c e p t i o n of the c red i t -wor th iness of the cus tomer . 36Definitions 2.7 k. 3.10. Law statements can therefore express constraints in semantic databases. Chapter 4. Ontology-Based Conceptual Model - OBCM 89 Since law statements restrict the values of F,- 6 F, they define a subset of the con-ceivable state space of a model object. This subset is called the lawful state space or Sx, of the model object. As with state functions, law statements are not necessarily isomorphic to the set of laws LK-Change Functions In the world, change is a modification in or of things. In Bunge's ontology, change in a thing is represented by the transition of one state of the thing to another state. Such transitions are representable by the ordered triple < si,s2,g > where S i is the state of a thing before the change, s2 the state after the change, and g is a function which provides the transformation mechanism between the two states.37 DEFINITION 4.8 The change functions of a model object are mechanisms for changing the values of Fi £ F. More precisely, they are mechanisms which define possible changes in the values of the F,-. That is, given a state sx of some thing, a change function c € C potentially transforms Si to some other state s2.38 All changes in a thing must be lawful. In OBCM, change functions may or may not be defined in terms of the law statements L. Ideally, the set of change functions C describes the transformation of lawful state spaces to themselves, ie.3 9 C : SL -» SL 37Principle 5.3. 3 8The word potential is important since Bunge's ontology does not admit changeless things. 39Definition 5.8. Chapter 4. Ontology-Based Conceptual Model - OBCM 90 where Sj, is the lawful state space of a model object.40 The lawful state space 5 L of a change function, however, pertains to a particular representation or model object. Therefore, although the result of a change might be lawful locally, ie. for some particular s G SK and in some particular model X M , a lawful local change may nevertheless result in unlawful changes elsewhere in the Information System. The ideas behind this issue are developed in more detail in section 4.5.4 to follow. The set of change functions C is a partially ordered set. That is, there is a relation X defined between some (but not necessarily all the) elements gi € C such that if gi -< g2 is permitted then g2 -< g\ is not.41 The partial ordering of change functions describes a trajectory or more accurately, set of possible trajectories. Such a potential trajectory can also be viewed as the (potential) life cycle for the thing represented by the model object. The actual trajectory or ordered set of states (ie. the values of the state functions F actually taken) for a particular s over a period of time is called the history of s (more accurately, the thing represented by s). Change functions are implemented as procedures and may involve input of values or data from sources external to the O B C M . Recall that the set of change functions C is a mechanism for local changes in state. That is, C defines state changes for some specific surrogate as described by a particular model object. The value of a state variable for surrogate s\ in representation XM may affect the value of a state variable for some other surrogate 32 in representation X N . Such changes are effected through another mechanism, namely through law statements describing object interaction. This will be described in detail in the section describing object interaction laws (section 4.5.4). 40Definition 3.11. •"Definitions 5.4 - 5.7. Recall from Chapter 3 that Bunge's Corollary 5.4 (i) explicitly prohibits < s, s' > * < s, s' > and (ii) treats an event followed by its converse as resulting in no change, ie. < s,s' > * < s',s >=< s, s >. Similarly, for any £ C, </,• -< g\ is not defined. Also, for any gi, gi £ C, if for any two states s\ and s2, ffi(si) = «2 and 02(^ 2) = S\, then neither g\ -< g2 nor gi < gi is defined. Chapter 4. Ontology-Based Conceptual Model - OBCM 91 4.4.2 Mult iple Views Bunge assumes that the set of functional schemata is nonempty and can grow indefinitely.^ Similarly in O B C M , it is also assumed that for any class of things TK, there can be more than one model object. In other words, there can be more than one representation for a class (or any particular thing in that class). Where there are several models for the same class TK, each model is called a view of the class TK-For example, suppose the model object, P E R S O N , represents a class of persons of interest to the firm. The state functions in this representation refer to properties of the kind persons such as age, sex, height, blood type, and so forth. The model object, C U S T O M E R , may be the representation for the class of customers of the firm. The state functions may refer to debt, credit limits and other properties of the customers of the firm. Assuming that some members of the class of persons are also customers of the firm, there will be a set of surrogates QK which corresponds to individuals which are also customers. QK will, therefore, be represented by both model objects P E R S O N and C U S T O M E R . In this way, the information system can support more than one view or representation of a class of things in the real world. 4.4.3 Example Customers in some restricted Universe of Discourse can be represented by the model object C U S T O M E R = < M, F, L, C > where • TK— {JOHN, MARY, JACK} where each element in the set is a customer of interest in the application. 42Postulate 3.4 and Definitions 3.7 & 3.8. Chapter 4. Ontology-Based Conceptual Model - OBCM 92 • SK= {'JOHN', 'MARY', 'JACK'} where each element in the set is a surrogate cor-responding to each customer in TK-• F is a set of functions consisting of 1. fCreditLimit: SK —• Integers 2. fDebt: 5A- —> Integers where fCreditLimit and fDebt represent credit worthiness and total indebtedness, two important properties of customers of a firm. • L is a set of law statements, in this case consisting of a single statement ICredit : = [fDebt(s) < fCreditLimit(s)] for all S £ SK-• C is a set of change functions, in this case consisting of the single function clnit = [fDebt(s) := 0] & [fCreditLimit(s) :— External Source], for all S £ 5A-. That is, for any S £ 5, the change function clnit defines a change from some initial state si (say fDebt = nil and fCreditLimit = nil) to a new state with the values fDebt(s) and fCreditLimit(s) as defined above. The notation External Source indicates that the value for fCreditLimit is taken from a source external to the model (such as, for instance, keyboard entry or an external database). Chapter 4. Ontology-Based Conceptual Model - OBCM 93 4.5 Object The main modelling construct in O B C M is the object which is a representation of some thing in reality. Objects are used as a conceptual modelling construct, are implemented as an Information Systems artifact, and are directly manipulated by the end-users of the final system. 4.5.1 Definition DEFINITION 4.9 Given a model object XM representing a kind TK, an object is a pair < S,XM > in which • S is an element in SK, where SK is a set of surrogates each element of which corresponds to an individual in TK, and • X m is a model object < M , F, L, C >, representing TK-Given an object x = < S, X T O >, the element S is called the surrogate for the object x, x is called the object for the surrogate S, and X m is the model object, model or view for x. The object x is also called an object of type or kind X m . Alternately, x can be said to be in the scope of X m . There can be more than one view of a thing. That is, the thing can be represented by more than one object. Therefore, the surrogate corresponding to the thing can participate in more than one object. 4.5.2 Example In the model object C U S T O M E R above, consider the surrogate 'JOHN'. The O B C M object John = < 'JOHN',CUST0MER > 4 3 is an object of kind C U S T O M E R representing 4 3 I f there are multiple views of JOHN, they can be distinguish as (for example) jo/m.PERSON and ;o/m.CUSTOMER. Chapter 4. Ontology-Based Conceptual Model - OBCM 94 the real world thing, that is, person, corresponding to the surrogate 'JOHN'. The values of the state functions in F consist of 1. fDebt('JOHN') 2. fCreditLimit('JOHN'). These values represent the individual properties of JOHN. The state of the object John is the vector < fDebt('JOHN'),fCreditLimit('JOHN') >. The notational convention used is UPPER CASE for model objects and their names, SMALL CAPS for things, quoted 'SMALL CAPS' or single SMALL CAP characters for surro-gates and italics for OBCM objects and their names. Names of state functions, law state-ments and change functions are sans serif beginning with lowercase f,l or c respectively. A more convenient notation for the example above is john.iDebt and jo/m.fCreditLimit for fDebt('JOHN') and fCreditLimit('JOHN') respectively. Figure 4.1 summarizes the relationships among things in the world, surrogates, model objects and object. The vertical dotted line divides the Universe of Discourse, ie. the things to be represented, from the Information System. In reality, there can be several views or perceptions of the things in the world. This is indicated in Figure 4.1 by the l:n relationship between things and their views. Each thing is assigned a 1:1 relationship with a surrogate in the OBCM. In addition, each relevant view or perception of a thing has a 1:1 relationship with a model object.44 A surrogate can be associated l:n with different models. As the diagram indicates, then, for any thing in reality, there can be several objects in the OBCM, each corresponding to a different perception or view of that thing. However, there is only one surrogate. 44Which is the reason why model object is also referred to as a view. Chapter 4. Ontology-Based Conceptual Model - OBCM 95 4.5.3 Object Composition Where the surrogate for an object is simple, the object is also called simple. When the surrogate for an object is composite, the object is also composite. D E F I N I T I O N 4.10 Given a composite surrogate S with composition { A , B , . . . , N } and ob-jects s and a, b , n for these surrogates, the S-composition Cs of the object s is defined to be the set of objects {a,b, ...,n}, that is Cs(s) = {a,b,...,n}. All objects in OBCM have a composition. Simple objects consist of themselves, ie. C(x) = {x} where x is simple. OBCM regards composition as a basic property of all things, a property which is representable as a state function.45 All model objects, therefore, contain a state function fSComp representing this property defined as fSComp : SK -> 2 0 where O is the set of all objects in the OBCM. The S-Composition of an object includes all possible views of the composition of its surrogate. This is because there may be several objects for any particular surrogate. For instance, suppose in the example from section 4.5.2., the individual J O H N with cor-responding surrogate ' J O H N ' is represented by two models, CUSTOMER and PERSON. Then, there can be at least two objects representing J O H N , one of type CUSTOMER and one of type PERSON. Call them John.CUSTOMER and jo/m.PERSON. Assume some object x with surrogate X which includes ' J O H N ' in the composition of X . Then, the S-Composition of x will include John.CUSTOMER and jo/m.PERSON. This prompts some other, more specific notions of composition such as: 4 5Bunge also refers to the property of being composed, ie. of having parts [1977, p. 26] and [1979, p.20]. Chapter 4. Ontology-Based Conceptual Model - OBCM 96 DEFINITION 4.11 The A - C o m p o s i t i o n , CA, of an object x is the set of objects in the S-Composition of x belonging to some set A. T h i s is r e l a t ed to , bu t no t e x a c t l y equivalent to B u n g e ' s f o r m u l a t i o n of A - C o m p o s i t i o n . 4 6 In O B C M , the set A is implicitly defined b y KA, a set of m o d e l objec ts . T h a t i s , g i v e n KA = {KUK2, Kn}, n A — ( J {x\x of t y p e A ' , } T h a t i s , i f for some object x, KA — {Km, Kq, Ks], t hen the A - c o m p o s i t i o n o f x is the subset of objects i n C$(x) of t y p e Km, Kq a n d Ks. A l l m o d e l objects p r o v i d e the state func t i on f K i n d s such tha t f K i n d s : SK -> 2 K where K is a set of m o d e l objects . T h i s i m p l i c i t l y defines the set of objec ts p e r m i t t e d i n the A - c o m p o s i t i o n of an objec t . A - c o m p o s i t i o n i t se l f is represented i n a l l m o d e l objects b y a s tate f u n c t i o n f A C o m p such tha t f A C o m p : 5A- -> 20. In the p rev ious e x a m p l e , i f for object x, f K i n d s = { C U S T O M E R } , t hen the A - c o m p o s i t i o n of x w i l l i n c l u d e j o / m . C U S T O M E R bu t no t j o / m . P E R S O N . 4 7 46Definition 1.5. It should be noted that Bunge's theory of association and composition refers to things in the real world. The composition of objects, however, refers to representations, hence the need to modify definitions. 47Bunge's concept of A-composition is, in the opinion of this thesis, open to some interpretation. In certain respects, an A-composition of a thing depends upon its representation. For instance, in one representation, a body of water is a collection of H2O molecules. In another representation, the same body of water is a collection of hydrogen and oxygen atoms. For this reason, in OBCM, every model object (ie. every representation) requires the state function fKinds which defines how the composition of a thing is to be represented. Chapter 4. Ontology-Based Conceptual Model - OBCM 97 Since objects are representations or views, for an object x, the A-composition of each object in CA{%) yields a consistent view of the internal structure of x. For example, an anatomical representation of a person48 may yield an A-composition of head, arms, legs, and trunk. An anatomical representation of the head, in turn, yields an A-composition which includes eyes, ears, nose and mouth. This yields an appropriate "explosion" of the person according to the anatomical representation. On the other hand, an inconsistent view might mix an anatomical view of a person with a molecular view of the head. In the general consistent representation of the structure of the A-composition of an object can be expressed by V-Composition or Cv which is defined recursively as follows. D E F I N I T I O N 4 . 1 2 The V-Composition of a simple object is itself. The V-Composition of a complex object x is the union of the CA(X) and the V-Composition of each component of the A-Composition. That is, suppose CA(x) consists of n objects a 1 ,a 2 , . . . ,a n and denote the union of the V-compositions of the a, as Vc = ( J Cv(at). «=i Then, Cv(x) =CA{x)UVc where Cy(x) = x when x is simple. From this point on, unless explicitly specified, any reference to the composition of an object will always mean V-Composition since this provides a consistent internal structure of an object. V-composition is represented in all model objects by a state function fComp such that fComp : SK -> 2 e . 4 8That is, an object representing a person. Chapter 4. Ontology-Based Conceptual Model - OBCM 98 A n object x in the composition of another object y is said to be part-of y, in symbols x C y. A n object may be part-of more than one object. DEFINITION 4.13 The part-of context of an object x is defined as the set of all objects of which x is part-of. A l l model objects provide a state function f P a r t O f : S -> 2® where 0 is a set of objects. This operationalizes Bunge's definition of the part-whole relation. 4 9 Figure 4.2, adapted from Bunge [1977, p.48] shows the relationships among S-composition, A-composition, and V-composition. Different surrogates are depicted by different geomet-ric shapes. The figure at the top of the diagram shows a composite surrogate composed of four separate simple surrogates. Suppose that the object for the composite surrogate is ZQ and that three composing surrogates are represented by objects x\,x2, and y\. The fourth surrogate is represented by two objects, y2 and y3 (ie. there are two different views of this surrogate). Suppose further that the four surrogates associate in different ways as shown with corresponding objects z-i, z2, z3 and z4. Then, Cs(z0) = {x1,x2,y1,y2,y3, zx, z2, z3, z4}. Now, suppose that for zo, fK inds = {ZUZ2} and z\ and z2 are in the scope of models Z\ and Z2 respectively. Then, CA{zo) = {z\,z2}. 49Definition 1.2 [Bunge, 1977]. Chapter 4. Ontology-Based Conceptual Model - OBCM 99 F u r t h e r , suppose tha t for object z\, f K i n d s = {YUY2} a n d y\ a n d y2 are i n the scope of mode ls Y\ a n d Y2. F i n a l l y , assume tha t for z2, fKinds= {XUX2} a n d x\ a n d x2 are i n the scope of models X\ a n d X2. T h e n , Cv(zo) = {xi,x2,yl,y2,z1,z2}. T h e proper t ies of a t h i n g c a n be affected b y i t s c o m p o s i t i o n or the th ings of w h i c h i t is p a r t - o f . 5 0 T h i s concept is o p e r a t i o n a l i z e d i n the m o d e l b y a l l o w i n g the l a w s ta tements i n the m o d e l for a n object to reference the state funct ions of any objec t i n i t s c o m p o s i t i o n , A - c o m p o s i t i o n or pa r t -o f con tex t . T h i s is c la r i f ied fur ther i n the next sec t ion . 4.5.4 Object Interaction In the w o r l d , t h ings in t e rac t w i t h each other . T h a t i s , the proper t ies of a t h i n g c a n be affected b y some o ther t h i n g . B u n g e defines interaction or bondage be tween two th ings as o c c u r r i n g whenever the history or trajectory of one is affected b y the o t h e r . 5 1 In his on to logy , a n aggrega t ion of i n t e r a c t i n g th ings is a system. [In the case of a system], here the history of every component is determined at least partly by the states other components are in, so that the history of the whole does not equal the sum of the individual histories [p. 263]. 50[Bunge, 1979, Chapter 1]. "Definitions 5.27, 5.29, 5.30, 5.32 and 5.33. Refer also to Chapter 3 of this thesis. Chapter 4. Ontology-Based Conceptual Model - OBCM 100 Although Bunge defines the general concept of interaction, his ontology does not discuss specific ways by which interaction is achieved. In nature, the interaction of things would involve natural forces and mechanisms which could, at least partly, be described by the laws of the things concerned. In O B C M , two mechanisms are introduced to model interaction: (1) local change: the invocation of change functions of one object by another, and (2) interobject change: inter-object referencing of state function values in the law statements of a model object. 5 2 The first mechanism was briefly described in section 4.4.1 under the section on change functions. As an example of the second mechanism, consider some object pt composed of objects pi and p2. Assume further a state function fCost which represents the cost of the things corresponding to pt, p\ and p2. If the cost of the thing corresponding to pt is summative of its components, the cost of pt can be represented by a law statement ICost : p t.fCost = px.fCost + p 2.fCost where pt.fCost, pi.fCost and p 2.fCost are the values of fCost for pt,Pi, and p2 respectively. That is, the values which can be taken on by pt .fCost are determined by the law statement ICost. Such law statements are called interobject law statements. The next section presents some notation to facilitate the expression of law statements. 4.6 A n O B C M N o t a t i o n The basic constructs in O B C M are objects and model objects with their associated state functions, law statements and change functions. This section develops a notation for dealing with these constructs. The format of the 5 2 This is a relatively simple model of change. Other models are certainly possible. Unfortunately, the change models cited by Bunge [Appendix B, 1979] are too general and not directly applicable to this thesis. However, the development of a full model of change is beyond the scope of this thesis. Chapter 4. Ontology-Based Conceptual Model - OBCM 101 notation is functional, thus facilitating nested application.53 Much of the notation is drawn from conventional set theory. Despite the formal appearance of the notation, however, the ideas which it expresses invariably have simple, readily understood, natural language versions. 4.6.1 Names Names of state variables, law statements and change functions need not be unique. Where potential ambiguities arise, names can be qualified with model object names or object names. For example, CUSTOMER.fDebt refers to the function fDebt € F of the model object CUSTOMER. Similarly, the law statement CUSTOMER.IComp refers to the law statement IComp € L of the model object CUSTOMER. And, the change function CUS-TOMER.clnit refers to the event function clnit G C of the model object CUSTOMER. Although state function values can be expressed in conventional functional notation such as F,.(s) where s is some surrogate, a more convenient notation is by reference to the object of interest. For example, for some object x, the value of state variable F,- is x.Fi. An object can refer to itself with the keyword self. For example, a law statement constraining the composition of a simple object can be written ISimple : fComp - {self}. In plain language, this law of simple objects says that the only object in the V-composition of a simple object is itself. A further naming convention deals with references to objects as opposed to model objects. Often, references will be made not to specific objects but to all objects of a kind. 5 3The notation described here does not constitute a complete or formal language for OBCM. Such an undertaking is beyond the scope of the current work. Chapter 4. Ontology-Based Conceptual Model - OBCM 102 As a naming convention, where the context is clear, the name of the model object by itself may refer to all objects in the scope of the model object. For example, one may say that Q has a certain composition rather than "all objects of kind Q have a certain composition". Finally, where the context is clear, given a model object Xm, its law statements and state variable names will be understood always to refer to all objects in the scope of Xm. For example, the law ISimple given above is equivalent to Xm.ISimple: a;.f Comp = {self} for all objects x in the scope of Xm. 4.6.2 Basic Object Functions As modelling constructs, objects and model objects have a number of basic functions or operators. The surrogate of an object x is returned by a function Sg on the domain of objects to the co-domain of surrogates, ie. Sg : 0 -> S, where 0 is the set of objects in the system and S the set of surrogates. For example, any object can refer to its surrogate as 53(self). The objects for a surrogate S are returned by a function Ob on the domain of surrogates to the powerset of objects, ie. Ob : S -> 2E, where 0 is the set of objects in the system and S the set of surrogates. For instance, as-sume that some individual JOHN in the real world with corresponding surrogate 'JOHN' is Chapter 4. Ontology-Based Conceptual Model - OBCM 103 represented by object jx of type C U S T O M E R and j2 of type P E R S O N . Then, 0 6 ('JOHN') returns the set {ji,J2}-A useful notational convention is the function Osa which is simply Sg o Ob- This returns all other objects that have the same surrogate as some particular object. That is, for any object x, 0Sg(*) = Ob(Sg(x)). For example, given j\ and j2 above, Osg(ji) returns the set { j i , }• More simply, the function Osg can be said to return all alternative views of object x. Figure 4.3 illustrates the relationships among thing, surrogate, model object and objects expressed by these functions. 4 . 6 . 3 Object Sets A number of useful functions on sets of objects are now defined. Functions of Object Sets Where all the objects in a set are of the same kind, the following notation is introduced to refer to the list (or vector) of values for a particular state function i*1, for the set: { x i , x 2 , ...,xn}.Fi, where all x,- are of the same kind. For example, assume the set {John, mary} of type P E R S O N and state function PERSON.fAge: 5A- -> Integers. The notation {John, mary).fAge refers to the set {jo/m.fAge, mary.iAge}. That is, it refers to a vector of the age of each person represented by the set of objects {John, Chapter 4. Ontology-Based Conceptual Model - OBCM 104 mary} 54 Object Set Partitioning Often, there is an interest in partitions or subsets of some set of objects. Given a set of objects, a relation ~ „ can be defined which returns a subset of the original defined in some nth respect. For example, 0 -> 0 „ where O n C 0 . Such partitions are expressed in the form Os / ~ n , where ©s is a set of objects. For instance, the A-composition of an object is given by fAComp. The set of objects of type Q in the composition of the object is written fAComp/ ~ q . (4.1) Similarly, the set of objects of type Q in the part-of context of the object is fPartOf/ ~ Q . (4.2) This partitioning also allows a specific view of an object to be returned as follows: OsJ ~ Q • (4.3) To explain further, Osg returns a set containing all alternate views of the object (ie. objects with the same surrogate as the given object). The partition ~ Q then returns only those objects of type Q. The final result is an alternative view (ie. object) of type Q of the original object. 5 4This implies that x.fValue will return values either for a single object or a set depending upon whether x is an object or a set of objects. Chapter 4. Ontology-Based Conceptual Model - OBCM 105 To take a trivial example, given C U S T O M E R object j i and P E R S O N object j2 as described previously, the P E R S O N view 5 5 of ji is returned by Osg(jl)/ ~ P E R S O N • Similarly, the C U S T O M E R view of j2 is given by Osg{J2)l ^ C U S T O M E R • The relation ~ n can be more complex than the above. For example, the expression fAComp/ ~ ( Q & f c o s t = j , ) (4-4) returns the subset of fAComp of type Q with values of Q.fCost equal to y. Objects to Scalars The following notation defines a class of functions which maps any set of objects to a scalar value, ie. Q : {xi, x2,.. •, xn} —> scalar where x,- are objects. In particular, the function qSize £ Q is defined such that given a set of objects 0 , qSize(O) returns the cardinality (or number, size, population, etc) of objects in 0 . For example, qSize(fAComp/ ~ Q) (4.5) returns the number of objects of kind Q in the A-composition of an object. This allows a convenient notation for expressing the cardinality, size or population of any particular group of objects. 55Ie. the object of type P E R S O N with the same surrogate as j\. Chapter 4. Ontology-Based Conceptual Model - OBCM 106 Value Sets to Scalars The notation e.Fi refers to the vector of the values of state function F, over the set of objects 0 . The following class of functions maps these value vectors to a scalar: V :< v\,V2, ...,u„ >—* scalar where t>,- are values. For instance, the function S G V is defined such that given V =< Ui, V2,vn >, E (V) returns the sum of the individual values in V. For example, the expression fAComp/ ~ Q denotes all objects of type Q in the A-composition of an object. The expression (fAComp/ ~Q).fValue denotes a vector of values of the state variable fValue for each object of type Q in the A-composition of the object. And the expression S[(fAComp/ ~Q).fValue] (4.6) returns the sum of this vector. Suppose, for example, that an object represents a sales order, composed partially of several objects of type Q, each representing some specific item. This expression denotes the sum of the values of the items in the order. 4.7 A Visual Notation for O B C M This section presents a simple visual notation to describe O B C M objects. The technique is a modification of a visual formalism known as higraphs [Harel, 1988]. Higraphs have been shown to be useful in diagramming E-R schemes, activity charts, state diagrams and generally, any situations which involve set-theoretic structures. Although the visual notation described here is based on higraphs, it is not defined as formally as in [Harel, 1988]. Chapter 4. Ontology-Based Conceptual Model - OBCM 107 Figure 4.4 shows the basic format for the modified higraph used in O B C M . A n object is depicted as a rounded rectangle. State functions are shown as circles along the top of the rectangle. Law statements are represented by smaller rectangles along the side. Change functions are also diagrammed as circles, but along the left side of the rectangle. The concept of composition of an object is diagrammed in a special way, by showing the composing objects directly within the original rounded rectangle. The diagram in Figure 4.4 can actually refer to either a model object or a specific object. The name of the model or object can be placed in some convenient location within the rectangle. In this case, the diagram refers to a model object named Xm. The usual notational conventions are used to distinguish between object and model names, ie. lower case italics for objects and upper case for model object names. Figure 4.4 shows some additional information which can be conveyed by this dia-gramming technique. In Harel's visual formalism, a dashed line allows representation of cartesian product of sets. Similarly, a dashed line is used to indicate the composition of an object of type Xm and consisting of objects of types Am and Bm. Along the bottom is a rectangle representing a law statement which regulates composition. The l:n notation represents the essence of the law, that the composition of Xm must consist of one object of type Am and one or more objects of type Bm. The arrows (edges) in the diagram represent the various relationships among state functions, law statements, change functions, and objects in the composition or part-of context. The edges in themselves, however, have no formal semantics. Their meanings are obtained from the state variables, law statements and change functions of the model object being depicted. The edges in Figure 4.4 do suggest, however, that the value of state variable XmA3 is affected by the values of Bm .f5 and that law Xm. L 2 specifies the nature of this relationship. Figure 4.5 shows a more complex situation. Here, object XQ is composed of several Chapter 4. Ontology-Based Conceptual Model - OBCM 108 objects, xi,X2,qi,q2,Pi,P2iP3 a n ( i PA- The diagram also shows the composition of X\ as {<72,P3,P4} and x 2 as {pi,P2> 92}- It can be seen that q2 is part-ofboih of x\ and x2. Since this diagram shows specific objects, the value for the state function Xo-f i is also shown (in this case, the integer 25). Figure 4.6 shows the invocation of change functions. The edges from c l indicates that this change function changes the value of f l to some value from the set of integers N obtained from a source external to the object being diagrammed. The change invoked by c2 is slightly different. Here, the edges represent a change function which requires the original value of f2 as well as a value from an external source. The change invoked by c3 shows a change to the composition of the object. Here, an object of type Ym external to the object is brought into its composition. In the next section, a brief example shows how both the written and visual notations are used in an O B C M description of a simple application. Note throughout the example that despite the symbolic notation, an easily understood, natural language expression is always readily available. 4.7.1 Example Suppose a manufacturer produces vehicles constructed of 4 wheels and a motor. Let Sw be the set of surrogates corresponding to wheels, SM the surrogates corresponding to motors, and Sv the set of surrogates corresponding to complete vehicles. Further, let W H E E L , M O T O R and V E H I C L E be model objects for wheels, motors and vehicles respectively. Worth or value is a property of all the things (ie. wheels, motors and vehicles) and is represented by the state functions WHEEL.fCost, MOTOR.fCost, and VEHICLE.fCost, which map the surrogate for each thing to a number representing dollars, ie. Chapter 4. Ontology-Based Conceptual Model - OBCM 109 WHEEL.fCost:5^ N MOTOR.fCost: SM -» N VEHICLE.fCost:Sy -* N where N is the subset of real numbers for expressing dollars. Now, let v be an object representing a specific vehicle. Let 101,102,103,104 be objects representing four different wheels and let m be an object representing a motor. The state variable u.fAComp represents the A-composition of v. A law statement can be formulated to constrain the values of v.fAComp as follows: lAComp : qSize[fAComp/ ~ W H E E L ] < 4 & qSize[fAComp/ ~ M O T O R ] < 1-The law statement lAComp states that the A-composition of objects of type V E H I C L E contains a maximum of four wheels and one motor. 5 6 The law statements of an object can reference state variables of objects in its compo-sition or part-of context. Suppose the cost of a vehicle is determined by the manufacturer to be the sum of the costs of its wheels and motor. Then, a law statement can be defined to express this relation by the following steps. • The object representing the motor in v is fAComp/ ~ M O T O R • • The cost of the motor is represented by (fAComp/ ~M O ToR)-fCost. 5 6That is, a maximum of four objects of type WHEEL and one object of type MOTOR. This particular formulation of lAComp does not limit the A-composition of V E H I C L E only to objects of type WHEEL and MOTOR. Nor does it require objects of type VEHICLE to always have a certain A-composition (it could be, for example, a frame travelling down a production line). Chapter 4. Ontology-Based Conceptual Model - OBCM 110 • The objects representing the wheels in the composition of v are fAComp/ ~WHEEL • • The cost of all the wheels is represented by S[(fAComp/ ~wHEEL)-fCost]. • The cost of the vehicle represented by v then is expressed by the law statement: ICost: fCost = (fAComp/ ~MOTOR)-fCost + E [(fAComp/ ~wHEEL)-fCost]. More informally, the law statement ICost defines the value of fCost for vehicles to be the sum of the cost of motor and the wheels of which it is composed. The result of the above is equivalent to u.fCost = m.fCost + Wi.fCost + ... + u^.fCost for any particular v with A-composition {m,Wi,1112,103,104}. Figure 4.7 depicts an object of type V E H I C L E using the visual notation. In addition to diagramming the state variables and law statements discussed above, Figure 4.7 also shows two change functions, cM and cW. These functions can be invoked to add objects of type M O T O R and W H E E L to the composition of V E H I C L E , subject of course to the constraints of lAComp. 4.8 O B C M and Semantic Modelling - Comparative Analysis This section describes how O B C M supports various abstraction mechanisms commonly used for semantic data modelling. Chapter 4. Ontology-Based Conceptual Model - OBCM 111 A-Composition, for example, can be viewed as the direct equivalent of the aggrega-tion abstraction mechanism when applied to aggregation of physical entities. The state functions and law statements of O B C M allow equivalents to other common modelling abstractions found in the conceptual modelling literature. 4.8.1 P r e - D e f i n e d vs L a w - B a s e d M o d e l s In general, it can be observed that many conceptual modelling approaches described in the literature attempt to support one or more pre-defined structures which are considered useful for modelling the world. These structures must be generalized enough to meet a wide range of situations and intuitive enough to be understandable to users. IS designers then attempt to fit real world entities and phenomena into these pre-defined structures. In contrast, O B C M is conceived as a collection of objects with no pre-defined struc-turing except for the basic concept of association which results in the composition and part-of relationships. It relies on the use of law statements to define and constrain the relationships among the state function values of objects. Each situation must be analysed individually and distilled into a set of law statements describing the situation. On the other hand, it can be shown that many of the common modelling abstractions can be developed by selecting an appropriate set of laws. Further, they can be viewed as specializations of Bunge's concept of association. This provides the basis for a more generalized form of data modelling which can be called law-based.57 The next few sections discusses how O B C M can provide the equivalent forms of some common, well-known semantic modelling schemes. 5 7 As emphasized in the introduction, this thesis does not try to prove that OBCM can model all applications nor, for that matter, that OBCM is a better modelling scheme than other models. Such claims must be based, at least partly, on usage over a period of time and empirical study. On the other hand, it might be noted that there are no intrinsic grounds for supposing that other modelling schemes such as data flows diagrams, E-R, or abstraction mechanisms can themselves model all applications. In contrast, since OBCM is based on a metaphysics which purports to explain the nature of reality, there would appear to be a stronger basis for such claims. Chapter 4. Ontology-Based Conceptual Model - OBCM 112 4.8.2 O B C M and Entity-Relation Models The Entity-Relationship or E-R model [Chen, 1976] is a well-known, high-level modelling scheme used in database design. A typical situation in the E-R model is a CUSTOMER set in an ORDERS relationship to a PRODUCT set. Cardinality rules are used to describe aspects of the ORDERS relationship. Customers and products may have certain attributes which describe them. Alternately, ORDERS is converted into a so-called weak entity to which CUSTOMER is in a PLACE relationship and PRODUCT is in a FOR relationship (such as in Figure 4.8 adapted from [Hall & Mosevich, 1988]). As the above example shows, in E-R modelling, the distinctions between entities, relationships and even attributes are open to interpretation. O B C M , however, requires a strict ontological interpretation upon the application, ie. the world consists of things which are grouped into systems or aggregates; things have properties which can be rep-resented by attributes or values; everything abides by laws. 5 8 The equivalent to E-R modelling is achieved in O B C M by viewing a relationship as a composite thing. 5 9 For example, an order can be viewed as a thing composed of a customer thing and one or more product things. Since the order is a thing, it has certain properties, particularly emergent ones such as its value and composition, as well as certain laws or rules by which these properties are governed. A l l things of interest, customers, products and orders, are represented in the O B C M as objects. The state functions of each object represent the relevant properties of these things. For instance, in an O R D E R object, 6 0 an emergent property, order value, can be represented by a state function fValue whose value is determined by a law statement relating ORDER.fValue to the sum of PRODUCT.fValue of all objects of type P R O D U C T 58Assumptions Ml - M10 [Bunge, 1977]. 5 9In a different context, others have also noted that the relationships in the E-R model can be gener-alized as a composite object [Hull & King, 1987]. 6 0That is, an object of type ORDER. Chapter 4. Ontology-Based Conceptual Model - OBCM 113 in the composition of the O R D E R object, ie. ORDER.fValue : So -> N , (So is a set of surrogates corresponding to the orders of a firm) and IValue : fValue = S[(fAComp/ ~ P R O D u c T ) - f V a l u e ] . 4.8.3 Cardinality Constraints in O B C M The cardinalities in the E-R model can be expressed by law statements constraining the composition or A-composition of objects. For example, a law statement may restrict the number of C U S T O M E R and P R O D U C T objects allowed in the composition of O R D E R as follows: lAComp : qSize(fAComp/ - C U S T O M E R ) = 1 & minsize < qSize(fAComp/ — P R O D U C T ) < maxsize. That is, the law statement lAComp restricts the A-composition of O R D E R objects to exactly one C U S T O M E R object and a range < minsize, maxsize > of P R O D U C T objects. 4.8.4 Classification and Generalization Variations on classification or IS-A constructs are also supported since O B C M provides multiple views of any thing of interest. For instance, an individual in the world can be represented by several models such as S T U D E N T , G R A D - S T U D E N T , P E R S O N , etc., each with their own state functions, law statements and change functions. One form of IS-A is generalization with strict inheritance where an object type must be a specialization of another. For example, suppose that all S T U D E N T objects must Chapter 4. Ontology-Based Conceptual Model - OBCM 114 also have a P E R S O N view (ie. all students are also persons). In this case, the law of strict specialization can be formulated as: STUDENT.IIsA : qSize[053(self)/ ~ P E R S ON] = 1. That is, there must be exactly one object of type P E R S O N among all the alternate views of a S T U D E N T object. Similarly, the equivalent of property inheritance can be achieved by law statements of one object referring to state variables of other objects. For instance, assuming the strict specialization above, the state variable STUDENT.fName can be defined to take its value from the state variable PERSON.fName as follows: STUDENT.IName : STUDENT.fName := 0 5 f l(self)/ ~PERSON . F N A M E . That is, S T U D E N T name must be the same as the name of the P E R S O N view of the S T U D E N T object. Or more informally, a student's name must be the same as his or her personal name. O B C M can also be used to support a more permissive form of generalization where a strict inheritance is not necessarily required. For example, the customers of a firm can be other firms, individuals (ie. persons), or organizations such as government agencies. Suppose that individuals are represented by the model object P E R S O N and customers are represented by the model C U S T O M E R . The following law statement relates objects of kind C U S T O M E R to any existing P E R S O N view: CUSTOMER.IName : PERSON.fName if 3 0Sg(se\i)/ PERSON External source otherwise. CUSTOMER.fName := I Chapter 4. Ontology-Based Conceptual Model - OBCM 1 1 5 This expresses the idea that if the customer is also a person, then the customer's name is the same as that person's name. Otherwise, the customer's name comes from an external source. 4.8.5 Aggregation Aggregation is interpreted in a number of different ways in the literature. As discussed in Chapter 2, distinctions can include Cartesian, cover and statistical aggregation. Cartesian aggregation refers to an aggregation of properties, eg. a P E R S O N is an ag-gregate of properties such as N A M E , ADDRESS, and so forth. The set of state functions F in a model object directly captures this idea in O B C M . Cover aggregation refers to an aggregation of entities, eg. a V E H I C L E is an aggregate of W H E E L S and a M O T O R . This abstraction is directly captured by the concept of object composition. Statistical aggregation provides summary information. This is reflected in the notion of emergent properties. For example, the number of items in the composition of an object in O B C M is an attribute representing the emergent property of population, cardinality, or numerosity (ie. number of components) of the composite object. In some cases, not only are the properties of the aggregate dependent upon the prop-erties of its components but certain properties of a component may depend upon one or more properties of the aggregate. For example, an O R D E R object may consist of a CUS-T O M E R object and one or more P R O D U C T objects. The O R D E R object will have a state function fValue representing the value of the order being represented. On the other hand, one of the state functions of the C U S T O M E R object is fDebt which represents the total indebtedness of the customer being represented. The value of fDebt, however, depends upon fValue of all orders of which the customer is in a part- of relationship. This Chapter 4. Ontology-Based Conceptual Model - OBCM 116 idea is easily expressed by a law statement for C U S T O M E R such as: IDebt : fDebt = E[(fPartOf/ ~ 0 R D E a ) . f V a l u e ] . In plain English, the law states that the debt of a customer is the sum of all orders of which the customer is part-of. 4.8.6 Association Association is defined as an abstraction in which a collection of entities is considered a higher-level set [Brodie, 1984], although, this abstraction is not always clearly distin-guished from classification [Peckham & Maryanski, 1988]. Generally, it is conceded that associations consist of similar, and not different, entities [Brodie, 1984]. In O B C M , abstractions equivalent to association can be modelled by explicitly formu-lating appropriate law statements. For example, a club might be viewed as an association of individuals. It may be represented by an object of type C L U B composed of individ-uals of type P E R S O N with an explicit law statement constraining all the objects in the composition of a C L U B object to be of type P E R S O N . One way of expressing this might be with a law of strict composition similar to IComp : qSize(fComp) = qSize(fComp/ ~ Q ) which constrains composition to objects of a certain type only. For example, in the example of C L U B , CLUB.IComp : qSize(fComp) = qSize(fComp/ ~PERSON)-This simply states that the composition of C L U B must consist only of objects of type P E R S O N . Chapter 4. Ontology-Based Conceptual Model - OBCM 117 4.9 S u m m a r y This chapter has presented an Ontology-Based Conceptual Modelling (OBCM) scheme for describing information systems. This scheme is based on ontology or a system of metaphysics and not on concepts based on computing or implementation technologies. As such, it can be seen as one answer to the call for a more theory-based approach to information systems development [Wand, 1988; Floyd, 1986; Bubenko, 1986]. In summary, the model • attempts to ground IS conceptual modelling in a consistent and formal metaphysics with a theoretical foundation for its basic constructs (eg. thing, property, change, state, etc.) and • provides a representation for both structural and dynamic aspects of reality through state variables, law statements, and change functions. Through examples and comparison to other conceptual modelling approaches, this chapter shows how a small number of ontologically-based concepts might be powerful enough to model a range of information systems and applications. The model appears general enough to encompass many of the features of other modelling techniques such as Entity-Relation and abstraction mechanisms such as generalization, aggregation and association. It further supports a concept of multiple views. O B C M is a formal model and uses a formal notation. However, its ontological basis gives its formalism a straightforward, intuitively understood interpretation. For every situation described by its formal notation, a relatively simple, ontology-based description is possible, using natural language terms. This chapter has also proposed a simple and useful visual notation for O B C M . The next chapter describes how O B C M leads to direct implementation into a working Chapter 4. Ontology-Based Conceptual Model - OBCM 118 system and details how support is provided to model the dynamic or behavioural aspects of an application. Chapter 5 Object-Based Information Systems - An Implementation Framework This chapter describes the relation between O B C M and its implementation as an Ontology-Based Information System or OBIS. Like O B C M , the structure and operation of an OBIS derives directly from Bunge's ontology. Its design principles attempt to preserve a direct relationship between the conceptual (OBCM) description of the application and its implementation in a work-ing system. And its underlying motivation is the seamless, homogeneous path from a conceptual model of the application to an implementation, as was first discussed in the introduction to this thesis. 5.1 Conceptual Framework 5.1.1 OBIS - Definition The overall framework for OBIS results from Bunge's conceptualization of the world or the universe: POSTULATE: There exists a thing such that every other thing is part-of the former. That thing is unique and we call it the world.1 Similarly, an Ontology-Based Information System is conceptualized as the total aggre-gation of all the objects of concern to the application. This aggregation is itself treated as an object representing the Universe of Discourse of the application. In other words, Postulate 1.2 & 3.3 and Definition 1.3 [Bunge, 1977]. 119 Chapter 5. Object-Based Information Systems - An Implementation Framework 120 the OBIS is simply another object described by its own state functions, law statements and change functions. Conceptually, then, system implementation is homogeneous and consistent with its underlying O B C M description in the sense that no other additional constructs are required other than those related to object and model object. As with any other object, the OBIS has a composition. Objects in this composition have, in turn, compositions of their own. One possible (although not the only) way of looking at the OBIS is as an object with an A-composition containing one or more objects representing specific applications areas. Each of these application objects has, in turn, its own A-composition containing other appropriate objects. This recursion can be repeated to any arbitrary level of granularity as required for the application. For example, in a data processing application, the OBIS may have an A-composition of several application objects such as Order, Payroll, and Inventory objects. In turn, each application object is composed of other relevant objects. The Order object might, for instance, be composed of objects representing customers and products for sale. The composition of the Payroll object may include objects representing the employees of the firm. Figure 5.1 shows a possible OBIS composed in this way. The preceding can be more formally expressed by the following. P O S T U L A T E 5.1 Given a set of surrogates SK each corresponding to some thing of inter-est in an application domain A, there exists an individual o £ SK such that every other element in SK is part-of it.2 Ie. (3x)[x £ SK & (Vy)(y £ SK y C x)\. DEFINITION 5.1 An OBIS for the application domain A is an object for o. That is, an OBIS is an object or representation for the aggregation o of the surrogates corresponding to the things of interest in the application domain. As with any surrogate, o may be represented by more than one model object. 2 I n Bunge's notation as described in Theorem 1.2, © = [SK]-Chapter 5. Object-Based Information Systems - An Implementation Framework 121 Since the composition of o consists of all surrogates in SK, an OBIS provides informa-tion about any thing of interest in the application domain A. Access to the constituent components of an OBIS can be described by the following. P O S T U L A T E 5.2 There exists an element • £ SK such that for any x £ SK, x o a = X. • is part-of every element in SK-T H E O R E M 5.1 The quadruple < SK,o,o,o > is a semi-lattice with least element • and last element o. Proof. The proof is similar to Bunge's.3 There exists a supremum for any two elements of SK, namely their association. • is part of every individual, o contains every individual. These conditions define a sup-semilattice. The nodes of the lattice are the surrogates and the edges are the part-whole relation-ships c formed by the o operation. C O R O L L A R Y 5.1 Given an OBIS, an access path is available from an object to any other in the OBIS by virtue of its composition and part-of state functions. Proof. By Theorem 5.1, < SK,O, °,° > has the semi-lattice structure. Since an OBIS is an object for o and each object in the OBIS has a surrogate in SK, an access path exists between any two objects. This implies that conceptually4, at least, the OBIS does not require a separate navi-gation mechanism to access its components other than composition or part-of. In other words, access to the components of the OBIS is completely defined on strict ontological grounds.5 3Theorems 1.3 & 3.1. 4Ignoring, for example, implementation or efficiency issues. 5Compared to, for example, Information Systems which require user knowledge of indexes, keys, relational joins, etc. Chapter 5. Object-Based Information Systems - An Implementation Framework 122 5.1.2 OBIS Design Approach The implementation process does not include the explicit design phase found in some methodologies [Freeman & Wasserman, 1984]. Instead, the IS development process for O B C M / I S proceeds directly from analysis to implementation. Analysis involves not only understanding the application but also interpreting it in ontological terms so that it can be modelled by O B C M . Then, the O B C M is directly converted into a working OBIS without an intervening design phase in the usual sense. The effect is to reduce the number of steps in the IS development process. Further, since both the conceptual model and implementation share the same representational constructs, ie. objects, there are fewer opportunities for "semantic gaps" to occur between the application world and the final IS. The goal is an IS implementation which is close to the original conceptual model of the application, is easily understood, and appeals to the intuitions of developers and end-users. The process for O B C M / I S development will be illustrated later in this chapter through an extended example.6 Since all the components of the OBIS including the OBIS itself are objects, in prin-ciple, a single, common concept of examining, manipulating and otherwise interfacing with objects is sufficient to provide a complete user-interface to the Information System. The two basic forms of end-user interaction with objects involve inspection of objects and change tb objects. 5.2 The OBIS User Interface 5.2.1 Direct Manipulation Style In OBIS, users interact directly with objects in accordance with ontological principles. development of a complete ISD methodology for OBCM/IS is beyond the scope of this thesis. However, the principles presented here should form the foundations for any future practical methodology. Chapter 5. Object-Based Information Systems - An Implementation Framework 123 The aim is to achieve a close parallel between object manipulation and the way things are manipulated in the real world. Users work with constructs, operations, and manipulations in the OBIS which are semantically closely related to the real-life entities and phenomena they encounter in the application world. The overall result is a formalism to support the direct manipulation style of user interface [Schneidermann, 1983], in which the user enjoys a sense of manipulating real world entities when working with the system. In this way, O B C M / I S is a representation which is not only descriptive of some aspect of reality but also can be examined and manipulated like the things in that reality. Thus, the representation can be richer and potentially more powerful than conventional IS representations such as files, records and programs.7 5.2.2 End-User Interface The accessing of state variables by end-users is called inspect? or view. The invoking of change functions to modify the values of state variables is called change. • View. This involves the examination of objects, more precisely, of the state of objects (ie. the values of the state functions). The underlying implementation technology must be capable of displaying these values in some appropriate manner 7Such representations may have significant intuitive power. For instance, Mattessich [1987] presents some interesting archaeological evidence of the use of tangible, visually identifiable clay tokens for so-phisticated accounting and record-keeping purposes, even before the invention of writing and abstract counting systems. These fire-hardened artifacts from the Fertile Crescent in the Middle East date as far back as 8000 B.C. They often possessed morphological similarities (ie. in shape or by inscriptions) to the things being accounted for (eg. sheep, jars of oil, measures of grain). More importantly, however, tokens were often used in such a way that the "morphological tokens and pictographs not only describe structures, they themselves are similar structures'". These prehistoric "accounting systems reveal the logical, indeed set-theoretical, structure inherent in certain economic aspects of reality [pp. 88 - 89]". Similarly, objects in OBCM/IS are not only descriptive by virtue of their state variables but also reflect the composition and structure of the things they represent. For instance, by these standards OBCM/IS objects are inherently more powerful representations than icons which normally do not reflect such detailed structure. 8 A number of OBIS terms, including inspect, are borrowed from the terminology used in the Smalltalk programming environment. Chapter 5. Object-Based Information Systems - An Implementation Framework 124 (eg. icons, images or text on a video display). Examining sets of objects (such as the composition of an object) is referred to as scanning or browsing.9 • Change. Change is defined as modification of the values of state functions. Change functions can be specified to modify the value of any state variable of interest, including the composition of objects. As will become apparent shortly, changing the composition of an object is an especially important manipulation in the OBIS. A l l changes must be lawful, that is, subject to validation with respect to the law statements of all objects affected by the change. To give an intuitive example, Order Entry, a typical data processing application, can be modelled as a collection of three kinds of objects with the models C U S T O M E R , P R O D U C T and O R D E R . The real world activity of generating an order can be represented by aggregating together a C U S T O M E R object and one or more P R O D U C T objects into a composite O R D E R object. 1 0 The law statements, L , declared in the models C U S T O M E R , OR-D E R and P R O D U C T ensure that the composition of the O R D E R object is lawful. For instance, O R D E R objects must have only one customer in their composition but can have several products. Or, customers may not be part-of orders which exceed a cer-tain value. Since the interface involves objects only, the user is not concerned with technology-dependent operations typically found in traditional information systems such as file updates, record inserts, or manipulation of relations. View and change can be related to fundamental and explicitly stated ontological prin-ciples. View is based on Bunge's assumption of an external world subject to inspection 9Again borrowed from Smalltalk terminology. 1 0 A suitable graphical interface such as user manipulation of visual representations of customer and products, etc., can be employed to enhance and emphasize the user's perceptions and intuitions regarding this activity. Chapter 5. Object-Based Information Systems - An Implementation Framework 125 and inquiry. 1 1 Change assumes the principle of inherent flux in the world. 1 2 The next two sections discuss view and change in more detail. 5.2.3 View Display Technology Values of an object's state functions can include conventional numeric values, character strings, and sets of objects such as those returned by state functions representing compo-sition or part-of context View or inspect refers to displaying these values to the end-user. The term can also refer to the state function fHistory which returns an ordered set of time/value pairs giving the history of an object. Normally, the actual physical display of information in an IS is technology-dependent. To minimize this dependency, in OBIS, the values of state variables can be thought of as being received and interpreted by the implementation technology which then presents or displays them to the user in an appropriate manner (Figure 5.2). In many cases, values such as numbers and text strings are presented to the user conventionally. However, this approach also makes it possible to introduce state functions such as fForm : SK —> G where G is a set of implementation-specific values or codes which is interpreted by the im-plementation technology as color, shape, placement and other parameters for displaying the object on the physical hardware. This state function can be viewed as representing certain properties of identity, shape, or form of the thing represented by the object and returning a value which can be appropriately interpreted by the implementation platform (such as, for instance, control sequences to drive a physical display device). 1 1 Ml There is a world external to the cognitive subject [Bunge, 1977, p. 16]. 12M2 Every thing changes [Bunge, 1977, p. 17]. Chapter 5. Object-Based Information Systems - An Implementation Framework 126 Scanning or Browsing Sets of objects such as the composition or part-of context of an object in OBIS are examined by scanning or browsing. Because of the lattice structure of the objects in the OBIS, users can reach any object in the system by scanning the composition or part-of context of any other object in the system. The actual scan mechanism is implementation dependent. In particular, implemen-tation specific mechanisms will be required to manage browsing large sets of objects. In a realistic application, the composition of some objects (such as the OBIS itself) will be too large to display each component individually and some method of limiting the search space is required. For example, instead of immediately attempting to browse through the entire composition of an object, it may be more useful to initially scope the composition in terms of its models. That is, instead of returning a set of the individual objects in the composition, the scan mechanism returns a list of model object names related to the objects. Then, the user need only scan the subset of objects of a selected type of interest. The subset may, of course, still be too large. In that case, further mechanisms for selecting objects may be required such as by the values of certain state variables. 5.2.4 Change In the O B C M / I S model, changes in state occur explicitly as a result of change functions or implicitly through interobject law statements.13 Users of the OBIS can directly change state variables in objects by invoking change functions (subject to satisfying the appro-priate law statements for the objects being changed). Further, a direct change in one object can result in change propagation to other objects in the OBIS as a consequence of 1 3 T h i s is consistent with Bunge's definition of event or change functions as either laws or transforma-tions compatible with these laws (Definition 5.80.) Chapter 5. Object-Based Information Systems - An Implementation Framework 127 the interobject laws statements of affected objects. Bunge distinguishes between induced and spontaneous change.14 In OBIS, change is always induced.15 Further, all objects are subject to change. Once an object comes into existence, it can be changed by user invocation of a change function or it may change as a result of changes to objects in its composition or part-of context as determined by its interobject laws. Conceptually, many objects may be changing simultaneously and in parallel (although in practice, they are subject to the limitations of the implementation technology). Change functions are normally implemented as procedures and can include data from sources external to the OBIS such as keyboard input by human operators, external databases, and so forth. As such, they provide the primary mechanism by which the OBIS interfaces with the outside world. But invocation of change functions is not arbitrary. Since the set of change functions is partially ordered, not all change functions may be available to the user at any time (or in a given state). Further, every change in an object must be valid or lawful in that the resulting object must not contradict any of the law statements of the object itself or any other affected object in its composition or part-of context. The "user" invoking the change may be a human operator. It can also be an au-tomated agent programmed appropriately. Since the objects in an OBIS are governed by their own local, internal law statements, there is no requirement for global integrity controls in the OBIS. Further, there is no concept of the user needing to "know" the permitted legal changes for an object. This is in contrast to traditional D B M S or pro-gramming languages where integrity rules and constraints are often coded as part of the "Definitions 5.28, 5.29 k 5.30. 15Bunge defines spontaneity as a change in a thing where no other thing has acted upon it. The case of true spontaneous change raises a number of philosophical issues and is not incorporated in the OBCM/IS as presented in this thesis. Chapter 5. Object-Based Information Systems - An Implementation Framework 128 application software. The next sections describe some basic principles behind a single, common concept of object change which can be applied to any object within the OBIS (including the OBIS itself). The discussion includes ideas such as change propagation, change validation, change in composition, partial ordering of change functions, history, and the creation of new objects. Change Propagation Users directly modify objects by invoking change functions. The impact of such changes can be propagated to other objects through interobject law statements in L which refer to state functions of other objects in the composition and part-of context of the original object undergoing direct change. For example, consider the example of an object pt composed of p\ and p2> a n ( l the law statement lawi : pt.fValue = pi.fValue 4-P2-fValue. Suppose that pi.fValue is changed by a change function. This change will result in a corresponding change to the value pf.fValue by virtue of the interobject law statement lawi. Conceptually, changes are not necessarily propagated serially but may be propagated to all affected object in parallel. Thus, many objects in the OBIS can be changing simultaneously.16 1 6 O f course this parallelism must be simulated where the implementation technology is not able to support this concept directly. Chapter 5. Object-Based Information Systems - An Implementation Framework 129 Change Validation Any change to an object must be lawful not only for the target object itself, but also for all other affected objects in its composition and part-of environment to which change effects are propagated. In practice, however, since change functions are local to each object, it is difficult to specify these functions in sufficient detail to ensure the validity of all affected objects after their invocation. In fact, it may be difficult even to identify which objects would be affected by the invocation of a particular change function. In O B C M / I S , therefore, change functions are specified as transformations of existing states into conceivable new states, not necessarily lawful new states.1 7 However, the result of invoking change functions must be validated to ensure that the new state is indeed lawful for all affected objects. In order to achieve this, each object in the OBIS incorporates a validation function VL such that VL : L - > B where L is the set of law statements for an object and B the Boolean results {true,false}. The validation function V L is invoked for each affected object following invocation of a change function. In the worst case, the validation function for all objects in the OBIS must be invoked. If the validation function fails, that is, returns false, then the change is considered unlawful and is disallowed. Change in Composition The association of things in the real world is represented in OBIS by an important type of change, change in composition. The converse of association is disassociation, where 17Recall Bunge's distinction between the conceivable state space and lawful state space. Chapter 5. Object-Based Information Systems - An Implementation Framework 130 objects are removed from the composition of an object. As some of the examples later will demonstrate, in O B C M / I S , many significant phenomena in the world can be modelled by changing the composition of objects. As the composition of an object is changed, either by association or disassociation, at some point, the object of interest may become non-existent. That is, the object has changed so much that it can no longer be described by its model (ie. state functions, law statements and change functions). This is Bunge's principle of nominal invariance.18 In other words, there is a point at which the object of concern has changed so drastically that it can no longer represent the thing it is intended to represent. Object Creation A n object enters the OBIS by being added to its composition (or the composition of another object within the OBIS). Whenever an object is added to the composition of another, it must first be located. If it does not already exist, it must be created. Object creation must be distinguished from surrogate creation, because if Bunge's ontological principles are followed strictly, there is no true concept of creating things and in particular, Bunge does not allow the creation of things out of nothing. 1 9 In OBIS, therefore, surrogates are system generated and are assumed to always exist for any thing of interest. That is, OBIS assumes P O S T U L A T E 5.3 A surrogate always exists in the OBIS for any thing of interest in the application. Generation of a new object is, therefore, a matter of assigning a model to the assumed surrogate and is not strictly a creation activity. Put differently, in the OBIS, new objects 1 8Principle 5.1 [Bunge, 1977]. 19M7 Nothing comes out of nothing and no thing reduces to nothingness. [Bunge, 1977, p. 17] and Theorems 1.5, 1.6 & 1.7 and Corollaries 1.5, 1.6 & 1.7. Chapter 5. Object-Based Information Systems - An Implementation Framework 131 (ie. representations or views) can be created but not new surrogates. Surrogates without models, of course, are of little interest to users of the OBIS since they have no descriptive or representational power. Partial Ordering of Change Functions In Bunge's ontology, an event space is a set of events, each of which represents a change in state. Events compose with each other and are partially ordered. This partial ordering is not necessarily fully connected. That is, there may be events which neither precede nor succeed each other. 2 0 In the OBIS, the set of change functions C is a partially ordered set. The partial ordering reflects the sequence of changes that an object may go through during its existence from creation to extinction. In the OBIS, partial ordering is best interpreted in terms of an entity life cycle which is found in certain ISD methodologies and semantic data models [Jackson, 1983; Ross, 1987; Rosenquist, 1982]. More accurately, it represents a range of possible states that an object can take. OBIS supports the ordering of change functions through a partial ordering function V : T -> 2 C where T is the set of time instances. V returns the subset of C which is available to be invoked by the user at any point in time. The partial ordering of the change functions for an object can also be defined by reference to the current state of the object. That is, as a function V : SL 2 C where Sj, is the lawful state space for the object concerned. This is similar to the 20Definitions 5.4, 5.5, 5.6 k 5.7 and Corollaries 5.3, 5.4, k 5.5. Chapter 5. Object-Based Information Systems - An Implementation Framework 132 use of preconditions for defining functions found in certain programming languages and modelling schemes [Meyer, 1988]. In this thesis, a simple and informal notation is used to indicate the partial ordering as follows. • The -< operator indicates that ordering is in effect. For example, {oi -< a 2} (where O i , a 2 £ C) indicates that a.\ precedes o 2-• Otherwise, no ordering is in effect. Eg. {0:1 ,02} . • Ordered and unordered functions can be mixed. Parentheses are used to group ordered and unordered functions. Eg. {(ai -< a2) -< (0:3 ,04)} indicates that a i precedes a 2 and a i and ct2 both precede either a 3 or 0:4. However, neither 0:3 nor 04 are ordered with respect to each other. Just as Bunge allows the composition of events,21 OBIS allows a change function ao to be defined as the composition of two or more other change functions a,-. Eg. Oo = O i * a 2 * . . . * an. History In Bunge's ontology, the history of a thing is the succession of its states over time. 2 2 The history of an object is its actual state trajectory or life cycle during its existence in the OBIS. The state function fHistory, defined for all objects in the OBIS, returns pairs of values < t, F(t) > where H s a point in time and F(t) the vector of values for the state functions of the object. 21Definitions 5.4, 5.5 & 5.6. 22Bunge defines the term more generally, ie. as a succession of states over a spacetime frame of reference. For the type of applications relevant to OBIS, only the time co-ordinate seems appropriate. Chapter 5. Object-Based Information Systems - An Implementation Framework 133 Change Invocation Invocation of a change function results in a series of activities. The behaviour of objects in the OBIS depends on how their change functions are specified. The typical sequence for changing the composition of an object (call it the target object) illustrates many of the concepts related to change discussed above. 1. For the composition of the target object to be modifiable by the user, a change func-tion must be defined in the object's model. Give this function the name cAddComp. 2. The target's partial ordering function V provides the user access to cAddComp at certain points in the target's existence. Suppose that at one of these points, the user invokes cAddComp to add an object xa of type Xa to the composition of the target. 3. The change function is defined as a procedure which first permits the user to scan the composition of the OBIS (or other relevant object) for xa. If the object exists, cAddComp adds it to the composition of the target. Note in this case that the target's underlying surrogate is now changed as wel l . 2 3 4. If the object to be added does not exist, cAddComp attempts to create it by as-signing the model Xa to a surrogate. cAddComp assists the user to locate an appropriate surrogate. It may be possible that an appropriate surrogate exists as an alternate view, let's say object ya. If so, cAddComp assigns Xa to the surrogate for ya, generating a new object xa which is added to the target.2 4 23Recall that the surrogate of a composition object is also composite. 2 4If ya must exist, the change function should return an error message is ya is not found. This results in a form of referential integrity constraint. Chapter 5. Object-Based Information Systems - An Implementation Framework 134 5. If an appropriate surrogate does not exist, even as another object, then the assumed?5 surrogate is assigned to model Xa. The resulting object is added to the target. This sequence assumes that the object to be added, xa, is simple. If xa is complex, then a change function of xa may be invoked to "build" xa by adding to its composition. This procedure can be followed recursively to build new objects of any complexity. 6. The law statements L of the target as well as all affected objects in the target's composition and part-of context are validated. If any violations are found, the change is disallowed and the user informed. 7. The values of fHistory of the target as well as the histories of any other affected objects now reflect the change. It should be noted that a change function such as cAddComp can be implemented as a procedure which invites considerable decision-making assistance from the user. How-ever, it is also conceivable that change functions can be defined to minimize human intervention. The above example showed how the composition of an object is changed in terms of its underlying surrogates. However, the user will normally perform this operation in terms which are more intuitive and natural to the situation. For example, suppose that objects of type O R D E R are defined as the aggregate of one C U S T O M E R object and one or more P R O D U C T objects. Assume that the requirement is to add a new C U S T O M E R object to an object Order. Assume further that the real world customer of interest is the individual J O H N . 1. Order supports a change function cAddComp for changing its composition. The user invokes this function. 2 5 R e c a l l the assumption that a surrogate always exists in the OBIS for all things of interest in the application. Chapter 5. Object-Based Information Systems - An Implementation Framework 135 2. cAddComp looks for a CUSTOMER view26 of JOHN. cAddComp may, for example, initiate a scan of all objects of type CUSTOMER in the composition of the OBIS. Once the correct object is found, cAddComp adds it to the composition of Order.27 3. If a CUSTOMER view of JOHN does not exist, cAddComp checks for any other object with the surrogate for JOHN. For example, a PERSON view may exist.28 A new CUSTOMER object, John, is created using the surrogate of the PERSON object. The new object is then added to the composition of system. There are now two (at least) different objects describing the real world individual JOHN in the OBIS. 4. If there are no views (or objects) for JOHN, a new CUSTOMER object is created using the assumed surrogate for JOHN and is added to Order. 5. The validation function for Order is invoked. The user is notified if the change violates any law statements. 5.3 Extended Example This section presents a simple example illustrating the main principles of OBIS develop-ment. The example chosen involves a typical data processing application, Order Entry. The OBIS for this application is a single object of kind ORDER ENTRY composed of objects of kinds CUSTOMER, ORDER, and PRODUCT. 26Ie. an object of type CUSTOMER with surrogate corresponding to JOHN. 2 7In a small system, it is reasonable to assume that a human user can scan all CUSTOMER objects and identify the particular object of interest. With large OBIS, however, the cognitive load may be such that a human operator cannot be expected handle this task unaided. In such cases, the change function can provide more assistance or an automated process can be substituted. 28Again, in a small system, the user can be expected to know whether such a view already exists (or at least search for such a view.) Chapter 5. Object-Based Information Systems - An Implementation Framework 136 5.3.1 The OBIS Design Process The overall implementation process for developing an OBCM/IS application can be out-lined as follows. 1. The analyst/designer (or end-user) examines the application and identifies the things of interest in the application according to ontological principles. 2. These things are grouped into kinds by identifying common sets of properties and laws. 3. Within each kind, for each property of interest, one or more state functions are defined which map individual things to appropriate attribute values. 4. For each law of interest, one or more law statements are defined which constrain state function values or express relationships among state functions. 5. A set of change functions is defined which specifies possible transformations of object states. This set is partially-ordered and defines the potential life-cycle of the objects in a kind. 6. The state functions, law statements and change functions together form a model object for the kind. More than one model may be formed for any kind. 7. Model objects are implemented in a computer-based form. For each thing of interest in the application, surrogates are generated and objects created for each surrogate. The collection of objects constitutes the OBIS. 8. In practice, this process can be supported by special computer-based tools and "shells". Chapter 5. Object-Based Information Systems - An Implementation Framework 137 5.3.2 Order Example - Overview A n examination of this application reveals at least three major kinds of things related to Order Entry. Customers are individuals, other firms or perhaps government agencies. Products are items for sale by the firm. Orders are interpreted as collections of products to be sold to some customer. That is, they are aggregations of n products and 1 customer. Therefore, the composition of an order is a set consisting of products and a customer. And those products and the customer are part-of the order. The next three sections develop the models for these three kinds. 5.3.3 Customers The customers of the firm are represented by the model object C U S T O M E R . Assume a collection of surrogates, Sc, each of which corresponds to a real customer of the firm. State Functions As with all model objects, C U S T O M E R includes the following standard state functions: fComp : Sc ->• 2 s , fAKinds: Sc -> 2 0 - , fAComp : Sc -> 2 e , fPartOf: Sc -* 2 e , fForm : Sc -* {G}, fHistory : Sc -* {< t,F(t) >}. The specific properties of customers include their indebtedness to the firm and their ability to pay, or credit worthiness. These are represented by the following functions in Chapter 5. Object-Based Information Systems - An Implementation Framework 138 F: fDebt : Sc - • N , fCreditLimit: Sc -> N , where N is the set of numbers representing money. Another useful property is the customer's identity. While this can be represented by any number of attributes, a conventional one is the use of a name: fName : Sc -> N „ where N s is the set of names. L a w S ta tements For the purposes of this application, objects of type CUSTOMER are simple. The law statement IComp restricts the value of fComp as follows: IComp : fComp = {self}. That is, the composition of CUSTOMER objects will only be composed of one object of kind CUSTOMER (ie. CUSTOMER objects are simple). The law I Debt relates fDebt to the value of orders to which the customer is in a part-of relationship. That is, fDebt is the sum of all orders of which the customer is part-of. Assuming the model object ORDER (to be defined later) and the state variable ORDER.fValue, I Debt : fDebt = E[(fPartOf/ ~ O H D E , i ) . f V a l u e ] . That is, the total debt of a customer is the sum of the values of the orders to which the customer is in a part-of relationship.29 2 9More precisely, the value of fDebt of an object of type CUSTOMER is the sum of the values of fValue of all objects of type ORDER in fPartOf of the object of type CUSTOMER. Generally, the more intuitive wording will be used in this and other examples. Chapter 5. Object-Based Information Systems - An Implementation Framework 139 The law ICreditLimit restricts the value of fDebt according to ICreditLimit: fDebt < fCreditLimit. That is, the total debt of a customer must not exceed its credit worthiness (or credit limit). Change Functions A n analysis of possible changes for a customer indicates the following life cycle: 1. Customers are first recognized by the firm as individuals or other firms who express an interest in dealing with the firm. 2. Customers are provided with an initial credit limit and various identifying charac-teristics. 3. The credit limit can change over the duration of the customer's relation with the firm 4. Certain identifying characteristics may change during the customer's relation with the firm. This suggests the following change functions. A change function to change the value of fCreditLimit is defined as: cCreditLimit: fCreditLimit := external source, where the value of fCreditLimit is set from an external source. This change can occur at any time during the customer's relation with the firm. Chapter 5. Object-Based Information Systems - An Implementation Framework 140 A function to change the value of fName can be expressed as cName: fName := external source. This change can occur at any time during the customer's relation with the firm. A function to change the value of f Form to some implementation-specific value appro-priate to the implementation technology is defined as cForm : fForm := external source. This change can occur at any time during the customer's relation with the firm (whenever, for example, the implementation technology is changed). A change function is required to initialize the value of fKinds as follows cKinds : fKinds:= { C U S T O M E R } . A function is required to provide the initial values for the customer when it is first recognized by the firm and entered into the system. This function is defined as the composition of changes defined earlier as follows clnit : cKinds * cCreditLimit * cName * cForm. This change can only occur once and precedes any of the other change functions.3 0 The partial ordering of these change functions can be depicted as clnit -< (cCreditLimit, cForm, cName). 30Note that clnit -< {cCreditLimit, cName.cForm}, even though clnit is composed of the latter. Chapter 5. Object-Based Information Systems - An Implementation Framework 141 That is, c l n i t precedes c C r e d i t L i m i t , c F o r m and c N a m e but the latter three are not ordered.31 To summarize, the model CUSTOMER is a representational schema for surrogates Sc consisting of F = { f D e b t , f C r e d i t L i m i t , f N a m e } 3 2 L = { I C r e d i t L i m i t , I D e b t } C = { c l n i t -< ( c C r e d i t L i m i t , c F o r m , c N a m e ) } . 5.3.4 Products The products for sale in the firm are modelled by the model object PRODUCT. Assume a collection of surrogates, Sp, each of which corresponds to a real product for sale by the firm. State Functions The following standard state functions apply. f C o m p : SP -> 2 0, f A K i n d s : SP -> 20"*, f A C o m p : SP -> 2 e, f P a r t O f : SP -» 2 0, f F o r m : SP -> { G } , f H i s t o r y : SP -> { < t, F(t) >}. 3 1There is considerable flexibility in how change function definitions and ordering can be expressed. For example, instead of defining clnit, the ordering of change functions above can be expressed as (cKinds -< cCreditLimit -< cName -< cForm) -< (cCreditLimit, cForm, cName). 3 2 In addition to the standard state functions for all objects. Chapter 5. Object-Based Information Systems - An Implementation Framework 142 Among the specific properties of products are their value, which is represented by the state function fPrice : P —> N . The identity of a product can be represented by the conventional state function fName fl\lame : P -> N . . Law Statements The law IComp defines objects of kind P R O D U C T as simple. IComp : fComp = {self}. Another law restricts a specific product to be part-of only one order lOrder: [qSize(fPartOf/ - O R D E R ) < 1]. Change Functions A n analysis of a possible life cycle for a product indicates the following: 1. Products are recognized when they are first acquired by the firm. 2. Products are initialized with a name and price. It is assumed that neither the name nor the price will change during the life of the product with the firm. The result of this analysis suggests the following change functions. The standard change function to to modify the value of fForm is defined as cForm : fForm := external source. Chapter 5. Object-Based Information Systems - An Implementation Framework 143 This change can occur at any time during the product's life with the firm. A change function to change the value of fPrice is defined as cPrice : fPrice := external source, where the value of fPrice is set from an external source. This change occurs only once. A function to change the value of fName is expressed as cName: fName := external source. Again, this change occurs only once. A change function is required to initialize the value of fKinds. cKinds: fKinds := {PRODUCT} . A function is defined to provide the initial values for the product when it is first acquired by the firm and entered into the system. This is a composite function. clnit : cKinds * cPrice * cName * cForm. This change can only occur once and precedes all of the other change functions. The partial ordering for these change functions can be expressed as clnit -< cName -< cPrice -< (cForm). In summary, the surrogates for the products of the firm is the set Sp. These products are described by the model object P R O D U C T which consists of F = {fPrice, fName} L = {IComp.lOrder} C = {clnit -< cName -< cPrice -< (cForm)}. Chapter 5. Object-Based Information Systems - An Implementation Framework 144 5.3.5 Orders A n order is viewed as a composition of a customer and one or more products. It is represented by the model object O R D E R . The collection of possible surrogates for the orders of the firm is therefore defined as S0 = Scx2Sp. That is, So is the cartesian product of one customer surrogate and one or more product surrogates. State Functions The standard state functions for O R D E R are fComp : So -> 2 e , fAKinds : So -* 2 e™, fAComp : So - • 2 e , fPartOf : So - • 2 e , fForm : So - • {G}, fHistory : So -* {< t,F(t) >}. Other relevant properties of orders include value and size (number of products or-dered) represented by the functions fValue: So -> N , fSize: So —>• I where I is the set of integers. The identity property of an order can be represented by a conventional order number as follows Chapter 5. Object-Based Information Systems - An Implementation Framework 145 fNumber: So —• I-Law Statements Assume the following relationships among the properties of orders: 1. an order must have one and only one customer in its composition; 2. the size of the order is the number of products in its composition (order size can be zero); and 3. the value of an order is the sum of the prices of the products in its composition. These relationships can be captured by the following law statements. The law statement IComp restricts the value of fComp as follows: IComp : [qSize(fAComp/ - C U S T O M E R ) = 1 & qSize(fAComp/ — P R O D U C T ) > 0]. This is the cardinality law which specifies that every order must be composed of one customer and zero or more products. The law statement ISize relates fSize to the number of objects of kind P R O D U C T in the composition of an O R D E R object. ISize : fSize = qSize[fAComp/ — P R O D U C T ] -The law statement I Value relates fValue to the sum of the prices of all objects of kind P R O D U C T in the composition of an order. IValue : [fValue = E(fAComp/ — P R O D U C T .fPrice)]. Chapter 5. Object-Based Information Systems - An Implementation Framework 146 Change Functions The life cycle for an order can be analysed as follows. 1. A n order is first created by bringing together a customer and zero or more products. 2. The composition of an order can be changed by adding products but not by adding customers. Assume that products can be added at any time during the life of the order. A change function is required to add a C U S T O M E R object to the composition of an O R D E R object. cAddCustomer: fAComp := fAComp o c, where c is an object of kind C U S T O M E R . (This notation indicates that the value of fAComp is changed by adding c to its previous value fAComp.) This event can occur only once. A change function is required to add a P R O D U C T object to the composition of an O R D E R object. cAddProduct : fAComp :— fAComp o p, where p is an object of kind P R O D U C T . This event can occur more than once. The standard change function cForm modifies the value of fForm. cForm : fForm := external source. This change can occur at any time during the order's life with the firm. A change function changes the value of fNumber. cName: fNumber := external source. Chapter 5. Object-Based Information Systems - An Implementation Framework 147 This change will occur only once during the life of the order. The external source for this function will typically be a serial numbering function which assigns each new order with a unique sequential order number. 3 3 The change function cKinds is defined as cKinds : fKinds := { C U S T O M E R , P R O D U C T } . A function provides the initial values for the order when it is first created. clnit : cKinds * cNumber * cAddCustomer * cForm. o This change can only occur once and precedes any of the other change functions. The partial ordering of these change functions can be expressed as clnit ~< (cAddProduct, cForm). In summary, O R D E R is a model object for describing surrogates So = Sc x 2Sp. O R D E R consists of the following F = {fNumber, fValue, fSize} L = {IComp, IValue, ISize} C = {clnit -< (cAddProduct, cForm)}. 5.3.6 Order Entry System The collection of all customers, items and orders in an Order Entry application can be viewed as a single aggregation, represented in the OBIS by an object of kind ORDER-E N T R Y . That is, in the ontological view, the Order Entry application itself is seen as a single, composite thing. 3 3A law statement can be used to confirm unique serial numbering. Chapter 5. Object-Based Information Systems - An Implementation Framework 148 The surrogate for the Order Entry application can be defined as SOE = 2 5 c x 2Sp x 2S°. That is, the surrogate corresponding to the application is the aggregate of surrogates corresponding to customers, products and orders in the application. State Functions The standard state functions for O R D E R E N T R Y are fComp : SOE - • 2 0 , fAKinds:So £ - + 2 0 - , fAComp : SOE -* 2 0 , f Pa rtOf : SOE ~^2e, fForm : SOE -> {G}, fHistory : S O E -> {< t,F(t) >}. A number of additional properties of the Order Entry application are of interest. Population or numerosity is an important emergent property of any composite thing. The number of customers in the application is represented by the state function fCustomerCount: SOE —• I> where I is the set of integers. The number of orders in the application is represented by fOrderCount : SOE —* I-The number of products available for sale is represented by fProductCount: SOE —*• I-Chapter 5. Object-Based Information Systems - An Implementation Framework 149 The value of this state variable is equivalent to the conventional notion of available inventory. Other emergent properties of the application include the value of its various compo-nents. In this example, the total value of the orders in the application is represented by fValue: SOE -» N. Laws Statements The law ICustomerCount relates fCustomerCount to the number of objects of kind CUS-T O M E R in the composition of the order entry application. 3 4 ICustomerCount: fCustomerCount = qSize(fComp/ — C U S T O M E R ) -Similarly, the law lOrderCount relates fOrderCount to the number of objects of kind O R D E R in the composition of the application. lOrderCount: fOrderCount = qSize(fComp/ — O R D E R ) -The law IProductCount relates fProductCount to the number of objects of kind PROD-U C T in the application which are still available for sale, that is, which are not part-of any orders. IProductCount : fProductCount = qSize(fComp/ — P R O D U C T ) & NOT [(fComp/ - O R D E R -fComp)/ - P R O D U C T ) ] -That is, all objects of type P R O D U C T in the composition of the application which are not in the composition of objects of type ORDER. 3 4That is, an object of kind ORDERENTRY. Chapter 5. Object-Based Information Systems - An Implementation Framework 150 The value of fValue is given by the law IValue : fValue — S[(fComp/ ~ 0 RDER)-fValue]. That is, fValue is the sum of the values of fValue for all objects of kind O R D E R in the application. Change Functions The life cycle of an order entry system can be summarized as • The system is created (possibly with a null composition). • Customers are added. • Products are added. • Customers and products are combined to create orders. Change functions are defined to reflect this life cycle as indicated below. The change function cAddCustomer adds objects of kind C U S T O M E R to the compo-sition of the application. cAddCustomer: fAComp := fAComp o c, where c is an object of kind C U S T O M E R . This event can occur many times. The change function cAddProduct adds objects of kind P R O D U C T to the composition of an object of type O R D E R E N T R Y . cAddProduct : fAComp := fAComp o p, where p is an object of kind P R O D U C T . This change can occur many times. Chapter 5. Object-Based Information Systems - An Implementation Framework 151 The change function cAddOrder adds objects of kind ORDER to the composition of the application. cAddOrder: fAComp := fAComp o o, where o is an object of kind ORDER. This event can occur many times. Note that object o itself is a composition of objects of type CUSTOMER and PRODUCT. Therefore, this function may invoke change functions associated with o if o needs to be created. The following change functions change the state variables fKinds and fForm. cKinds : fKinds := {PRODUCT,CUSTOMER,ORDER} and cForm : fForm := external source. A composite change function clnit provides the initial values for the Order Entry object when it is first created. clnit : cKinds * cForm. This change can only occur once and precedes any of the other change functions. The partial ordering for ORDERENTRY can be expressed as clnit -< (cAddCustomer, cAddProduct, cAddOrder, cForm). In summary, ORDERENTRY is a representation for the aggregation of customers, products and orders related to the application. The surrogate for this aggregation can be defined as SOE = 2 5 c x 2Sp x 2 S ° . The model consists of the following. F = {fValue, fCustomerCount, fOrderCount.fProductCount} L = {IComp, IValue, ICustomerCount, lOrderCount, IProductCount} C = {clnit -< (cAddCustomer, cAddProduct, aAddOrder, cForm)}. Chapter 5. Object-Based Information Systems - An Implementation Framework 152 5.3.7 Order Example - Operation The OBIS for this example consists of objects representing all the customers, products and orders of interest to the application. The collection of all the objects in the OBIS is itself an object, in this case, of type O R D E R E N T R Y . Call this object OrderSystem. Populating the OBIS The operation of the OBIS is described in O B C M / I S terms (and not in computer or implementation related terms). The user begins with the OrderSystem and populates it with C U S T O M E R and P R O D U C T objects by invoking the change functions cAddProduct and cAddCustomer. Each time a C U S T O M E R or P R O D U C T object is created, their respective clnit change functions are invoked, setting their initial values.3 5 Creating New Orders In response to the real world situation in which an order is received, the user represents this activity by creating a new O R D E R object and changing its composition with CUS-T O M E R and P R O D U C T objects to reflect the real world situation. The procedure is as follows. 1. A n object of type O R D E R is created. At the moment of creation, this object will have a null composition (and is therefore an unlawful object). 3 6 2. The composition of OrderSystemis scanned for the relevant customer which is then selected and added to the composition of the O R D E R object. 3 5This is analogous to updating Customer and Inventory master files in a conventional IS. 3 6 An unlawful object cannot be added to the OBIS but is permitted to exist temporarily outside the OBIS. Chapter 5. Object-Based Information Systems - An Implementation Framework 153 3. The composition of OrderSystem is then scanned for relevant P R O D U C T objects which are also selected and added to the composition of the order. 4. The O R D E R object (which is now lawful) is now added to the composition of OrderSystem. 5. The validation functions of the affected objects, in this case the customers and products in the composition of the order as well as the order, are invoked. Any violations are reported. 3 7 Figure 5.3 shows selected aspects of OrderSystem using the informal visual notation of Chapter 4. In this example, there are two orders, order#l and order#2 both with the same customer c\. It is seen that C\ is part-of order#l, order#2, and OrderSystem The customer c 2 , however, is part-of OrderSystem only. OBIS Queries The equivalent of conventional database queries are accomplished by scanning the com-position of OrderSystemiox the desired object then viewing the value of the state function of interest. Since all the objects in OrderSystem are connected in a lattice through their composition and part- of relationships, an object of interest generally can be accessed from any other object with a known relationship to the target object. For example, suppose the user has current access to OrderSystem If the user wishes to query a particular customer, the composition of OrderSystem is scoped for all objects of type C U S T O M E R . This set is then scanned to locate the customer of interest. The customer's credit limit and outstanding debt can now be determined by viewing the values for state functions fCreditLimit and fDebt. 3 7The mechanisms for invoking validation functions are implementation-specific. It is also feasible (and reasonable) to validate the new ORDER object before it is added to OrderSystem. Chapter 5. Object-Based Information Systems - An Implementation Framework 154 The user can then scope the part-of context of the customer for all objects of type O R D E R . This reveals all the orders for the customer. A particular order can then be selected and its value viewed. If desired, the composition of the order can then be scanned to determine the different products ordered and their individual values. 3 8 For any object, its history (ie. fHistory) can be viewed to determine the trajectory generated by changes as they occurred to the object. 5.4 Summary The OBIS framework presented in this chapter provides an integrated approach to im-plementation of an IS from the O B C M conceptual model proposed in Chapter 4. The result is a homogeneous path from conceptual model to implementation of an Informa-tion System. The goal is to reduce the opportunities for semantic gaps which develop as the concepts from the application domain are implemented into a working IS. The proposed framework also provides a single, ontologically consistent concept of user-interface and system operation in terms drawn from a theory of reality rather than in terms which are computer or technology-dependent. In principle, this one model of user-interface and system operation can be applied to any object in the OBIS including the OBIS itself, thus simplifying the understanding and use of the IS. The operation of the OBIS is defined around ontologically-oriented concepts of view and change. These concepts are developed into ontology-based interactions with the user rather than the technical operations typically associated with conventional information systems such as file updates, relational joins, and so forth. In the next chapter, a prototype implementation in a microcomputer environment using Smalltalk is described. This prototype is intended to be a "proof of concept" 3 8 An ad hoc query can be accommodated by defining a state function specifically for the query and adding it to the appropriate model. Chapter 5. Object-Based Information Systems - An Implementation Framework 155 implementation of O B C M / O B I S , that is, an experiment in software to determine the feasibility of the theoretical model [Newell & Simon, 1975]. Chapter 6 A n OBIS Prototype Implementation 6.1 Role of the Prototype This chapter describes a Smalltalk prototype of an Ontology-Based Information System as implemented on an I B M AT-class microcomputer. The prototype is implemented as a "shell" which provides basic support for O B C M / I S objects. The OBIS is then generated by populating the shell with objects specific to the application. In this thesis, the prototype plays an important role for the following reasons. • Proof of concept. The prototype implementation serves to demonstrate the feasi-bility of the theoretical model presented in Chapters 4 and 5. As such, it forms the most basic form of validation for the model. Although implementation is not an exhaustive validation, it can reveal inconsistencies or unexpected behaviour for further study. • Model refinement The prototype can be viewed as a series of experiments [Newell & Simon, 1975] designed to test and refine aspects of the theoretical model. In this respect, implementation is an important research tool in refining and testing the O B C M / I S framework. • Comparison to other models. A working prototype facilitates the comparison of O B C M / I S to other systems development approaches. • Tools and techniques. Through implementation, a number of practical tools and 156 Chapter 6. An OBIS Prototype Implementation 157 techniques are demonstrated. Although a complete systems development method-ology is beyond the scope of this project, such tools may prove useful in future work in O B C M / I S . The following sections discuss the general approach to the prototype implementation and provide a brief overview of selected implementation issues. Details of the prototype are included in the Appendices to this thesis. The chapter concludes with a description of a working OBIS based on the extended example from Chapter 5. 6.1.1 Choice of Prototype Language Smalltalk was selected for the implementation for the following reasons. • Object-oriented approach. A n implementation language consistent with the object-oriented approach was considered desirable for maintaining homogeneity and ease of implementation. • Availability. Smalltalk is well-known as a pioneering object-oriented language which is well-documented and readily available [Goldberg Sz Robson, 1983]. Several ver-sions of Smalltalk have been developed, some of which are implemented on mi-crocomputers [Digitalk, 1986; ParcPlace, 1989]. The version selected for this im-plementation is Smalltalk/V 286 which executes on I B M AT-class microcomputers [Digitalk, 1986]. • Software environment Smalltalk supports a programming environment which in-cludes object browsers, editors and other object management and manipulation tools which can be adapted for implementing the OBIS. The Smalltalk library of objects provides basic constructs and operators such as collections and sets use-ful in implementing the O B C M concept. In addition, the Smalltalk environment Chapter 6. An OBIS Prototype Implementation 158 supports windowing and other graphical interfaces useful for displaying objects. • Embedded Prolog. The particular version of Smalltalk used, Smalltalk V/286, sup-ports an embedded Prolog which facilitates the expression of laws statements. 6.1.2 The Smalltalk Programming Language Smalltalk is an integrated programming language and programming environment. As one of the first acknowledged Object-Oriented Programming Languages (OOPL), it has had considerable influence-in OOPL design and implementation. In Smalltalk, an object1 is some private or local data and a collection of procedures, called methods that can access that data. The local data of an object cannot be accessed except through the methods of the object. Methods, on the other hand, are public to all other objects in a Smalltalk environment. To access a method of another object, Smalltalk objects send messages corresponding to the method which then executes. A message can also include parameters which are used by the method during its execution. Objects are instances of special objects called classes. Classes describe the local data structures and the methods of objects. Sending the appropriate message to a class object results in the creation of a new instance as specified by the class object. Classes are organized into a class hierarchy in which classes lower in the hierarchy can inherit the data structures and methods from those higher in the hierarchy (called superclasses). Smalltalk supports a comprehensive programming environment which fully integrates the programming language, support tools (such as editors, linkers, and debuggers) and the operating system. It exploits a highly visual environment with browsers and windows which can display objects and their behaviours. The visual environment supports display xThe Smalltalk object should not be confused with the OBCM/IS object. Unless specifically stated, the term object will always refer to the OBCM object as defined in Chapters 4 and 5. Chapter 6. An OBIS Prototype Implementation 159 formats such as GraphPanes which display graphics, TextPanes which display conven-tional text-based material, and ListPanes which supports lists of text-based information. Further details on Smalltalk can be found in [Goldberg & Robson, 1983; Goldberg, 1984; Robson k Goldberg, 1981]. 6.2 The Implementation Framework The prototype is implemented as a shell which provides generic support for O B C M / I S objects. OBIS objects and their models are implemented within the shell by specifying a programming protocol or discipline in the Smalltalk language. 6.2.1 A Smalltalk Programming Protocol for OBIS The programming protocol for the prototype implementation can be summarized as fol-lows. • A Smalltalk class is defined to represent surrogates. Surrogates are implemented as instances of this class. • Smalltalk classes are defined for each model object. These are called Model Object Classes or MOC's . A n object is implemented as an instance of an M O C paired with an instance of class Surrogate. There is no hierarchy defined among the M O C ' s . 2 • State functions and change functions are implemented as methods of M O C ' s . 3 These methods are strictly partitioned into one of the following categories: 2Neither Bunge's ontology nor OBCM/IS supports a concept of inherent hierarchy or inheritance among the things in the world. 3In the prototype, a slightly modified version of the standard Smalltalk Class Hierarchy Browser along with its associated editor is used to created MOC's and implement state and change function methods. A more refined implementation would use specialized tools and editors to generate MOC's. Chapter 6. An OBIS Prototype Implementation 160 1. State function methods. These methods return values which are stored in instance variables or computed within the methods. 2. Change methods. These methods change the values returned by state function methods. • Law statements for a model object are implemented as Prolog statements. • The following state function methods are common to all MOC's . 1. fComp - answers the V-composition of the object.4 2. fKinds - answers the set of M O C names allowed in the A-composition of the object. 3. fAComp - answers the A-composition of the object. 4. fPartOf - answers the part-of context of the object. 5. fHistory - answers the history of the object. 6. fForm - answers a set of implementation-dependent parameters which control the appearance on an object on the display device. 7. fSurrogate - answers the set of objects which have the same surrogate as the object. 6.2.2 Prototype Operation - Overview Users interface with OBIS implementations by viewing and changing objects in the sys-tem. These two activities are meaningful only in the context of a specific object with 4Recall from Chapter 4 that V-composition is recursively defined as the A-composition of other A-compositions. Chapter 6. An OBIS Prototype Implementation 161 which the user is interacting at any time. This object is called the current object and is said to have the focus5. The object of focus can be changed as a result of scanning. Scanning a set of objects reveals each of the objects in the set. By choosing one of these objects (eg. with a mouse click), the focus is transferred to the selected object. Change involves the invocation of change functions. In the prototype, the user can display the allowable change functions of the object with the focus. By selecting a specific change function, the user invokes the Smalltalk change method associated with that change function. In this prototype, the user is assumed to be a human operator working with a display screen, keyboard and pointing device (ie. mouse). On the other hand, the user may also be substituted by an automated process or procedure consisting of a set of rules (or possibly heuristics) which scan and manipulation the OBIS. 6.2.3 Prototype User Interface Object Window The user interface provides mechanisms for viewing, scanning and changing objects in the system. The interface employs a visual format which is similar, but not identical, to the visual notation introduced in Chapter 4. The state function, fForm, provides some basic implementation-specific parameters which controls the appearance of an O B C M object in the Smalltalk environment as well as its interface to the keyboard and mouse. The default value for fForm of an object defines a Smalltalk GraphPane window for displaying graphical and text information 5 This use of the term focus is borrowed from Smalltalk terminology. Technically, it is the window of the object (to be described shortly) which has the focus and not the object itself. Chapter 6. An OBIS Prototype Implementation 162 related to the object.6 This window supports a "pop-up" service menu which offers the user a number of services including access to the state function values, law statements, and change functions of the object. This menu also provides mechanisms for manipulating sets of objects returned by state functions such as fComp or fPartOf. This window and the service menu implements the basic elements of the user interface described in Chapter 5. Figure 6.1 shows a sample window (A) opening on an object, in this case, of type O R D E R E N T R Y . 7 Typically, the user will be interacting with an object entirely through the services offered by this window. In addition to the basic elements of user interface, additional services actually offered to the user through the object window are implementation-specific. In the current prototype, the following are included in the choices offered by the service menu. Viewing States, Law Statements and Change Functions 1. States - allows the scanning and selection of the state functions of the current object. Selecting this option displays all the state functions of the object in a separate "pop-up" window. The user can then select a specific state function to display its value. 2. Changes - allows the scanning and selection of the change functions of the current object. Selecting this option displays all the change functions defined for the object in a "pop-up" window. The user can invoke any display state function by selecting it. Since the set of change functions is partially ordered, certain functions may not be allowed at all times and are either not displayed or marked as unavailable. 6The Smalltalk environment and standard windows are described in detail in [Digitalk, 1988]. 7Actual screen displays produced by the prototype will differ somewhat from these figures which do not completely capture the highly interactive dynamics of the Smalltalk windowing environment. Chapter 6. An OBIS Prototype Implementation 163 3. Laws - allows the scanning and viewing of the law statements of the current object. In the present implementation, a special Smalltalk "browser" is opened in which the Prolog statements corresponding to the laws are displayed. In Figure 6.1, label (B) points to a "popup" menu providing these three functions. Scanning and Selection 1. fComp - allows scanning of the composition of the current object and selection of any specific object in the composition. The focus changes to the selected object. 2. fAComp - allows scanning of the A-composition of the current object and selection of any specific object in the A-composition. The focus changes to the selected object. 3. fPartOf - allows scanning of the part-of context of the current object and selection of any specific object in the part-of context. The focus changes to the selected object. 4. fSurrogates - allows scanning of all objects with the same surrogate as the current object and selection of any specific object therein. The focus changes to the selected object. The label (C) in Figure 6.1 points to a menu providing these services. Manipulating Sets of Objects The implementation provides services to manipulate sets of objects such as the A-composition or the part-of context of the current object. Some of these services include the following. Chapter 6. An OBIS Prototype Implementation 164 1. ofKind:/; - selects the subset of objects of specified type k and allows scanning and selection over this subset. The focus changes to the selected object. 2. compOf - returns the union of the composition of each object in the original set. Allows scanning and selection over this new set. The focus changes to the selected object. 3. partOf - returns the union of the part-of context of each object in the original set. Allows scanning and selection over this new set. The focus changes to the selected object. 4. stateValueOf:/ withValue::r - selects the subset of objects in which state function / has value x. Permits scanning and selection over this subset. A l l the objects in the original set must be of the same type. Label (D) in Figure 6.1 shows a ListPane displaying a list of objects. A "popup" menu on the ListPane (E) provides the above services to the objects listed in (D). Every collection of objects always includes one object of type NIL. This object is part-of all other objects in the OBIS. Therefore, invocation of partOf over the set {NIL} returns all the objects in the OBIS. 6.2.4 O B I S Pro to type Shell A l l these basic services as well as the protocol for defining MOC's is provided by the prototype shell system. This shell provides the implementation-level support to manage objects and surrogates, handle the windowing and menuing systems, and provide the scanning, viewing and selection facilities described above. Generating a working OBIS is a matter of using the shell to generate and maintain MOC's , then populating the shell with the specific objects related to the application. Chapter 6. An OBIS Prototype Implementation 165 Shell Structure The basic structure of the shell consists of five components or subsystems. 1. OBCM/IS Primitives. Provides the basic support to manage objects and surrogates at the program code level. 2. Windowing and Menuing Subsystem. Supports the display of objects on the physical hardware. Much of this subsystem is by necessity implementation-specific to the Smalltalk environment. 3. User Interface. Provides the user with access to the system on the object level. That is, allows for scanning and selecting of O B C M objects. 4. MOC Support Subsystem. Supports the definition and maintenance of Model Ob-jects for the system. 5. Law Statement Subsystem. Supports the definition and maintenance of law state-ments. Figure 6.2 shows a standard Smalltalk Class Hierarchy Broswer which displays Smalltalk classes and their relationship to each other. As indicated, the shell components (with the exception of the Law Statement Subsystem) are implemented as Smalltalk classes arranged in a class hierarchy beginning with the primitives. In this particular imple-mentation, since the MOC's are at the bottom of the class hierarchy, any instance of a M O C 8 inherits the functionality of the User Interface, Windowing Subsystem, and basic primitives. Although the components of the shell are laid out as a hierarchy, it is important to note that this hierarchy is simply a technique used in the implementation of the 8That is, any object (or more accurately, any implementation of an object). Recall that an OBCM/IS object is implemented as an instance of a MOC coupled with a surrogate. Chapter 6. An OBIS Prototype Implementation 166 prototype itself. The Model Object Classes themselves do not form a hierarchy. Indeed, the O B C M / I S model as presented in this thesis does not support a concept of hierarchy nor is such a concept supported in the prototype. Figure 6.2 also shows the Law Statement Subsystem in its own browser. In the prototype, the Law Statement Subsystem is implemented separately from the other four components although it is still considered part of the prototype shell system. This is strictly an implementation convenience related to the Smalltalk V/286 embedded Prolog interpreter. There is no inherent reason why shells implemented beyond the prototype stage (or, for that matter, in a different programming environment) cannot combine all five components into a single unit. The shell components are described in more detail in the following paragraphs.9 O B C M / I S P r imi t i ve s This component, implemented as class O B I S , provides support for the basic ontological concepts in the O B C M / I S model. This support includes 1. Internal systems management for objects and surrogates on the implementation level. 2. Internal management of change function invocation. 3. Automatic update of the history as changes occur. 4. Support for validation functions. 5. Partial ordering of change functions. (Some further details of the mechanisms for validation functions and partial ordering will be described when discussing the M O C subsystem.) 9Appendix B contains the relevant Smalltalk code for a current version of the prototype shell. Chapter 6. An OBIS Prototype Implementation 167 In addition, a major function of this component provides methods for implementing the basic O B C M notation as described in Chapter 4 in Smalltalk. This includes returning surrogates from objects and vice-versa (Sg and Ob), object set partitioning a n d scalar functions (Q and V) . For example, the sum of all values of the state function fValue of all objects of type Q in the part-of context of an object is expressed by the the notation 1 0 E[(fPartOf/ ~g).fValue]. The implementation of this notation in Smalltalk takes the form of the following method of class O B I S sumValuesOf:#fValue fromObjectsOfKind:Q in:#fPartOf. W i n d o w i n g and M e n u i n g Subsystem This component, implemented as class O B I S F o r m , provides the windowing and menuing support required to display and view objects on the physical display. This component is technology-dependent and draws heavily upon the facilities provided by the Smalltalk programming environment. Any changes to the display technology are isolated in this component. The methods in this component intercepts the values of fForm of an object and trans-lates them into a display image for the object. Some of the functionality provided by this component includes 1. Basic windowing support to convert the values of fForm into a displayable Smalltalk window. 10Refer, for example, to Section 4.6.3 of Chapter 4. Chapter 6. An OBIS Prototype Implementation 168 2. Menuing support for "popup menus" and their interface with a mouse device. 3. Additional window support for listing objects, displaying state functions values, law statements, history and other displayable items. User Interface This component implemented as class OBISInterface supports scanning and selection on an object level. The functionality of this component includes 1. Display, scanning and selection of the composition and part-of context of an object. 2. Display, scanning and selection of objects with the same surrogate as the current object. 3. Manipulation of sets of objects such as selection of objects of a specified type, unions of the compositions and part-of contexts of sets of objects, and subsets of objects which meet specified conditions. These manipulations have been detailed in Section 6.2.2. Law Statement Subsystem This component defines and maintains the law statements of model objects. In Smalltalk V/286, the embedded Prolog interpreter is implemented in such a way that it is convenient to define laws statements in a separate component rather than in the M O C subsystem along with their associated state variables and change functions. Law statements are expressed as conventional Prolog assertions. For example, in Chapter 5, the law statement ICreditLimit for the model C U S T O M E R was expressed as ICreditLimit: Chapter 6. An OBIS Prototype Implementation 169 fDebt < fCreditLimit. Its equivalent Prolog assertion is "Debt is <= Credit Limit" lCreditLimit(fDebt, fCreditLimit) :-le(fDebt ,fCredit Limit). To take another example, the law statement CUSTOMER.IDebt in Chapter 5 1 1 was defined as IDebt : fDebt = E[(fPartOf/ ~0RDER)-fValue]. That is, the value of CUSTOMER.fDebt is equal to the sum of the values of the orders of which a customer is part-of. This is implemented as the Prolog assertion "Customer debt = sum of order values" lDebt(debt, aCustomer) :-is(order Values, aCustomer sumValuesOf:#fValue fromObjectsOfKind:Order in:#fPartOf). eq(debt ,or der Values). (Here, the Prolog predicate is binds the variable order Values to the sum of the values of objects of kind O R D E R in the part-of context of the customer. Variable orderValues is then bound to the variable debt.) Model Object Subsystem In this subsystem, model objects are defined and maintained as Model Object Classes. A M O C is created for every model object and the state functions and change functions are "Section 5.5. Chapter 6. An OBIS Prototype Implementation 170 denned in the form of Smalltalk methods as outlined earlier in Section 6.2.1. In addition, the state functions common to all objects in the OBIS are predefined in this component. State Functions. State functions are implemented as state function methods of a M O C . These methods return values corresponding to the state of the object. These values are computed within the method or are carried in instance variables of the M O C . For example, the following method returns the value of the state function fCreditLimit. fCredi tLimit "Answer credit limit" | fCreditLimit. In this case, the value is carried in the instance variable fCreditLimit. The value for a state function can also be computed. For example, in Chapter 5, the state variable fDebt represented the total indebtedness of a customer. The value of this state variable can be defined according to the law statement C U S T O M E R . I Debt (ie. the sum of the values of all orders of which the customer is part-of). The Prolog version of IDebt was described in the previous section. The value of fDebt can therefore be defined as fDebt "Answers fDebt defined as law IDebt" |debt | (CustomerLaws new :? lDebt(x,self)). Tx. The expression1 2 CustomerLaws new :? lDebt(x,self) refers to the Prolog clause IDebt and binds the free variable x to the value as defined within the clause. The value of x is then returned by the method fDebt. In this way, the values of state functions such as fDebt can be defined directly with respect to relevant law statements. Change Functions. Change functions are implemented as change methods of the M O C . In the prototype, they always start with lowercase c. In Chapter 5, the change function to change the credit limit of a customer was defined as cCreditLimit: fCreditLimit := external source. The Smalltalk implementation is cCreditLimit |oldCreditLimit| "Change fCreditLimit" fCreditLimit isNil ifTrue:[fCreditLimit := 0]. oldCreditLimit := fCreditLimit. fCreditLimit := (Prompter prompt: 'Credit Limit?' default: (fCreditLimit printPaddedTo:l)) aslnteger. self validateLaws ifFalse:[fCreditLimit := oldCreditLimit. T nil]. "Syntactical detail irrelevant to the example has been removed from this expression. The embedded Prolog in Smalltalk V/286 uses a non-standard syntax. The assertion is equivalent to the standard Prolog query ?- IDebt(X) in which X is instantiated to a value according to the rules in its database. 171 t fCreditLimit. This procedure obtains an input value from the external world (using the Smalltalk Prompter) and assigns it the instance variable fCreditLimit. The procedure also invokes a validation function. If the change validates false, the method restores the original value. The validation function presents law statements coded as Prolog clauses with specific values. The function returns boolean values (true or false) depending upon whether Prolog succeeded or failed with these values. For example, the validation function in this example presents the Prolog clause f D e b t 1 3 described previously with specific values for fDebt and fCreditLimit. The Prolog clause succeeds or fails according to whether these values satisfy its rules. Validation functions can be invoked at any time, either explicitly as above or automatically for an object whenever it is changed.1 4 The next example implements the change function CUSTOMER.cKindsfrom Chapter 5. Recall that this change was defined as cKinds : fKinds := { C U S T O M E R } . The Smalltalk implementation is cKinds "Initialize fKinds." fKinds := Customer asSet. pOrder add:#clnit. T self. The reference to pOrder concerns the partial ordering of the change functions of CUS-T O M E R objects. In the prototype, a relatively simple form of partial ordering was 1 3The syntactical detail is omitted in the example. 1 4The mechanism for invoking validation functions is implementation-specific. Efficiency issues must be considered in designing such a mechanism. In the worst case, every object in the system can be validated whenever a change is made to any object. 172 Chapter 6. An OBIS Prototype Implementation 173 implemented whereby each change function explicitly affects the partial ordering of the change functions of an object. Upon successful completion of a change, the change func-tion can remove or add itself to the list of change functions disallowed for the object. In this example, after setting the values of fKinds, change function cKinds adds itself to the set of disallowed changes. In the next section, highlights of a Smalltalk OBIS implementation for the Order example from Chapter 5 is described. The description here is necessarily incomplete and meant to be illustrative only of the basic approach. Details of the full working example including much of the Smalltalk code can be found in Appendix C. 6.3 Implementation Example 6.3.1 M O C The basic structure of the sample implementation is as follows. OBIS OBISForm OBISInterface ModelObj Customer Order Product OrderEntry The first four parts constitute the basic shell of the prototype and remains constant for all applications. The last four entries are the Model Object Classes which define the model objects for this application. The state functions, law statements and change functions Chapter 6. An OBIS Prototype Implementation 174 of a model object are implemented directly as a M O C . In the next few pages, a sample M O C implementation of the model C U S T O M E R is presented. The MOC's for the other models (ie. O R D E R , P R O D U C T and O R D E R E N T R Y ) are detailed in the appendix. State Funct ions Within a M O C , state functions of the model object are implemented as methods of the M O C . For the M O C Customer , the following state function methods are defined.15 f C r e d i t L i m i t Answers the credit limit of the customer. This is a stored value. fCredi tLimit "Answer credit limit" 1 fCreditLimit fDebt Answers the total indebtedness of the customer. This is a value computed according to the law statement I Debt. fDebt "Answers fDebt defined as law IDebt" | debt | (CustomerLaws new :? lDebt(x,self)) do: [:each | debt := each at:l]. t debt fName Answers the name of the customer. This is a stored value. 1 5 I n some cases, irrelevant syntactic details have been removed to simplify the presentation. Chapter 6. An OBIS Prototype Implementation 175 fName "Answer customer name" t fName fGForm Answers a Form 1 6 controlling the size and position of the Customer display window. This is a stored value. fGForm T fGForm Change Functions Change functions are also implemented as methods of MOC's for the M O C Customer. cCreditLimit Changes the stored value of fCreditLimit. Obtains new value from a Prompter. 1 7 fCredi tLimit "Answer credit limit" f fCreditLimit cKinds. Changes the stored value of cKinds to {Customer}. Upon successful completion, removes itself from the list of allowable changes. clnit "Initialize fKinds." 16Equivalent to fForm. A Form is a special Smalltalk object which controls the display screen. 1 7 A Prompter is a Smalltalk object which obtains input data from the user. . The following are defined Chapter 6. An OBIS Prototype Implementation 176 fKinds := Customer asSet. pOrder add:#clnit. t self. cName Changes the stored value of fName. Obtains a new value from either the Prompter or a P E R S O N object with the same surrogate as the customer.1 8 cName "Change the customer name." |oldName name| oldName := fName. (name := CustomerLaws new :? lName(x,self)) notNil ifTrue:[name do:[:each | fName := each at:l]]. name isNil ifTrue:[fName := (Prompter prompt: 'Name?' default: oldName)]. self validateLaws ifFalse: [fName := oldName. T nil]. t fName c G F o r m Changes the stored value of fGForm. Obtains a new value from the Prompter. cGForm self changeVar:#fGForm to:('Customer' magnifyBy:2@6). pOrder add:#cGForm 1 8This definition is enhanced somewhat from the original as presented in Chapter 5. Chapter 6. An OBIS Prototype Implementation 177 clnit Sets initial values. Includes methods cKinds, cCreditLimit, cName, and cForm. Upon successful completion, removes itself from the list of allowable changes. clnit "Initialize new object name & composition. self cName; cGForm; cCreditLimit. pOrder a d d c l n i t . Law Statements Law statements are defined as Prolog clauses in a separate section of the prototype. The following describes Prolog clauses which implement the law statements of the model ob-ject C U S T O M E R . IComp The composition of C U S T O M E R must be simple. "Composition Law - simple object" lComp(aCustomer) :-is(cardinality, aCustomer ctObjectsln:^composition), eq(cardinality,l). IDebt Indebtedness is the sum of the values of all orders of which the C U S T O M E R is part-of. "Customer debt = sum of order values" Chapter 6. An OBIS Prototype Implementation 178 lDebt(debt, aCustomer) :-is(orderValues, aCustomer sum Values Of: #fValue fromObjectsOfKind:Order in:#fPartOf), eq(debt, order Values). ICreditLimit Indebtedness is equal to or less than fCreditlimit. "Debt is < = Credit Limit" lCreditLimit(fDebt, fCreditLimit) :-le(fDebt,fCreditLimit). The state functions, law statements and change functions of the other MOC's in this example are implemented similarly. 6.3.2 Prototype Operation Recall that, in this example, the entire application is represented by the object Order-System which is the aggregation of all the Customers, Products and Orders of interest. Figure 6.3 shows the prototype implementation of OrderSystem as viewed through its Smalltalk window. The GraphPane of this window (A) provides a graphical view of the object, in this case, a logo or icon (although a more elaborate graphical image can be substituted). The pop-up service menu (B) displays the various services available to the user. For example, the state functions of OrderSystem can be display as in (C) by select-ing the appropriate entry from the service menu. In this case, selecting States results in (C) as indicated by the arrow (a). The values of any state function can then be displayed by selecting from (C). Chapter 6. An OBIS Prototype Implementation 179 Similarly, the change functions (D) are displayed by selecting Changes as indicated by the arrow (b). A change function can then be invoked by choosing from (D). The partial ordering function in the prototype ensures that only the allowed change functions are displayed in (D). For instance, the change function clnit which is one of the original changes for OrderSystem is not displayed. This reflects the fact that this change was invoked when OrderSystem was created and the object cannot be initialized a second time. In Figure 6.1, the ListPane (D) showed all the objects in the A-composition of Or-derSystem, Figure 6.4 shows an O R D E R object No. 1 which is in the composition of OrderSystem. The service menu provides access to the objects in the A-composition and part-of context of No. 1 as shown in (a) and (c) respectively. In this case, it can be seen that No.l is composed of the C U S T O M E R object John and a P R O D U C T object a. In addition, No. 1 is part-of OrderSystem Selecting any object in either of the ListPanes changes the focus to the selected object. In this way, the user can navigate from one object to any other object in the application. Figure 6.5 shows how sets of objects can be manipulated in the prototype. The ListPane (A) displays all the objects in OrderSystem A service menu (B) is brought up on the ListPane to provide a list of manipulations. In this example, the subset of objects ofKind P R O D U C T are selected as shown by the sequence of arrows (a) and (b). This subset is then displayed in (C). Figure 6.6 demonstrates some important principles when invoking change. Here, the O R D E R object No.l is being created and added to OrderSystem A n order is created by making OrderSystem the object of focus then invoking the change function cACompOrder from its service menu (refer back to Figure 6.3). This function creates a new O R D E R object and adds it to the composition of OrderSystem Chapter 6. An OBIS Prototype Implementation 180 Since O R D E R objects consist of a C U S T O M E R and one or more P R O D U C T ob-jects, however, No.l cannot be lawfully added to OrderSystem until its own composition is complete. Therefore, as shown in Figure 6.6, the focus switches from OrderSystem to the newly created No.l (A). Change functions for No.l are then invoked to add CUS-T O M E R and P R O D U C T objects to its composition. For example, the change function cACompCustomer for No. 1 leads the user through a sequence of steps (as suggested by the arrow (a) but not shown in detail here) to create a C U S T O M E R object, assign it a credit limit and then add it to the composition of No.l. Similarly, one or more products are added to the composition of No. 1 as indicated by the arrow (b). When the composition of No.l is complete (and validated) it can be added to Order-System, which will then regain the focus. In general, this recursiveness may be applied as many times as necessary.19 The user can verify that No.l was added to OrderSystem by checking its state function fAComp. Displaying the value of this state function shows that the composition of OrderSystem includes an object of type O R D E R (as in Figure 6.5). Figure 6.7 shows the history of object No.l. The history window is selected from the service menu of No.l and displays a set of time/state value pairs corresponding to changes in No.l as they occurred. This history reveals, for example, that the state functions fName and fKinds were initialized when the object was created. Then, a customer and a product were added to its composition (fAComp). As a result of adding a product, the value of No.l represented by the state function fValue changed to 50 in accordance with its interobject law statements. 19In this example, sequential operation is assumed. That is, no other changes are allowed for Order-System until the No.l is complete. Relaxing this assumption results in concurrent manipulation of more than one object. Implementation of concurrent operation of OBIS is beyond the scope of this thesis. Chapter 6. An OBIS Prototype Implementation 181 6.3.3 The OBIS Implementation Process The implementation process for developing an O B C M / I S application used in this proto-type can be summarized as follows. 1. The analyst/designer (or end-user) examines the application and identifies the things of interest according to ontological principles. State functions, law state-ments and change functions are developed into an O B C M / I S specification, with the assistance of an appropriate notation. 2. Each state function, law statement and change function in the O B C M / I S is di-rectly converted into Smalltalk code. Implementation consists of specifying classes (MOC's) for each model object and converting the O B C M / I S specifications into methods and Prolog assertions. A coding protocol or discipline guides this con-version. Although the conversion was manual in the prototype, support tools to automate the process are feasible. 3. The OBIS implementation is typically supported by an implementation "shell" con-sisting of object window handlers, service menus, and the various viewing, scanning, and manipulation operations. The shell will also support the O B C M / I S notation on the programming level. 4. Finally, since the prototype was designed to demonstrate proof of concept only, it utilized the standard Smalltalk windowing, menuing and user interface environ-ment. However, the inherently visual form of OBIS encourages far more elaborate interfaces. For example, objects can be displayed in a variety of iconic images rather than simple windows. The user interface can also support more direct manipula-tion such as "dragging" object icons and placing them within each other icons to Chapter 6. An OBIS Prototype Implementation 182 represent composition and so forth. A direct implementation of the visual notation from Chapter 4 is a further possibility. The traditional IS Systems Life Cycle [Freeman & Wasserman, 1984] usually specifies some form of explicit design phase, sometimes referred to as logical and physical design. The OBIS implementation process does not include such a phase. Instead, the conceptual model is directly converted into an implementation. There is no transformation of the constructs in the O B C M specification into a separate physical or logical design. In this way, the end-user interacts directly with an implementation which is semantically closely related to the original conceptual model of the application. 2 0 6.4 Summary This chapter has described a prototype implementing the O B C M / I S model proposed in Chapters 4 and 5. The prototype demonstrates that O B C M / I S has a relatively straight-forward implementation in an object-oriented programming language such as Smalltalk. A basic "shell" and a simple protocol or set of rules for defining model objects are sufficient for the prototype. There is no inherent reason why implementation in other programming languages would not be possible. Although the prototype used only the standard Smalltalk programming environment, it is able to support the basic principles behind the theoretical O B C M / I S model as well as the direct manipulation style of user interface. Given the many recent commercial developments in graphical interfaces and tools, it should be straightforward to implement more elaborate versions of the prototype, including an implementation of the visual notation discussed in Chapter 4. 2 0 0 f course, in practice, implementation variations to the basic OBIS framework may be necessary for performance or other reasons. Chapter 6. An OBIS Prototype Implementation 183 The following additional observations can be made regarding the operation of the prototype. • The prototype avoids the technology-dependent operations typical of many con-ventional IS implementations. Users interface with the prototype on an ontological level, that is, a level that remains relatively close to the original conceptualization of the application. As such, the user deals with directly visible and manipulable representations of orders, customers, products and so on. There are no computer-dependent concepts such as updating data files, joining or selecting relations, or entering records. • The prototype presents a highly homogeneous and consistent interface to the user. Every object essentially behaves in the same manner as any other object in the system, including the object representing the IS itself. In this way, the focus is on the properties and behaviour of the things represented by the object and not on the mechanics of the IS. • Since the basic principles of composition and part-of context apply no matter which object the user is dealing with, navigation through the system and access to any ob-ject of interest is conceptually straightforward. That is, they involve only ontologi-cal concepts and not technology-dependent ones such as keys, data base navigation, and so forth. It is important to emphasize that although the prototype is promising as a proof of conceptto test out the theoretical model, it does not constitute proof that O B C M / I S will work for all real situations and in all cases. On the other hand, it is doubtful whether such a proof is possible for any IS methodology, data model or software development technique. Chapter 6. An OBIS Prototype Implementation 184 In the final analysis, moreover, the success of a software development methodology is probably best measured by practical application in the field over many years. Such an extended field test is beyond the scope and resources of this thesis. However, case study is often offered as an acceptable demonstration of the usefulness of an IS development approach. Indeed, certain cases have become established as "benchmark standards" in the literature for this purpose. The IFIP Working Conference Problem [Olle, Sol & Verron-Stuart, 1986] is one of these case studies. The next chapter presents the O B C M / I S solution to the IFIP Working Conference problem. Chapter 7 IFIP Working Conference Case Study The IFIP Working Conference problem [Olle, 1982] is a popular reference case study for the evaluation and comparison of Information System Development methodologies and semantic data models [Olle et al., 1986]. Therefore, it provides a convenient "yardstick" for comparing and analysing different ISD approaches. Recall from Chapter 1 that the intent of this thesis is not to develop a complete ISD methodology. It is limited to demonstrating the feasibility of an ontology-based approach to ISD. Hence, this thesis does not attempt to compare O B C M / I S to the many different methodologies and models applied against the IFIP case study. Nor does it attempt to implement a complete production-quality IFIP information system in all its detail. Rather it attempts to demonstrate in a general way how O B C M / I S can be applied to a significant real world problem. The actual O B C M / I S solution to the IFIP case study is presented in Appendix D. This chapter focuses on two critical aspects of the O B C M / I S approach, namely (1) the interpretation of the IFIP problem in ontological terms so that it can be modelled by O B C M / I S , and (2) the ability of the prototype shell described in Chapter 6 to support an implementation of the IFIP case study. The chapter concludes with some brief comments relating O B C M / I S to other ISD approaches. 185 Chapter 7. IFIP Working Conference Case Study 186 7.1 Requirements Analysis The IFIP Working Conference problem is presented in its entirety in Appendix D. In this section, an O B C M / I S approach to requirement analysis is described. Many approaches can be taken to perform the preliminary requirements analysis of this problem. One possible first step used here is an analysis of the nouns and noun phrases in the problem description to identify the things of interest.1 The extraction of the real world things of interest from the written problem description can be informal, intuitive and somewhat arbitrary. The following list summarizes some important components of the IFIP problem as deduced from the written description. • Working Conference. A conference bringing together experts to discuss some topic of interest. Involves a Programme Committee and an Organizing Committee. Or-ganized as a series of sessions. A Working Conference must achieve a break-even position. • Person. A human being or individual. • Session. A group of individuals meeting together at some specified time and place to discuss certain issues. The discussions will center around several papers accepted for the session. • .Programme Committee A group of individuals responsible for soliciting, collecting, evaluating, and approving the papers for a Working Conference. The Programme Committee organizes these papers into various sessions. • Organizing Committee A group of individuals responsible for finding and organizing the facilities, issuing invitations and otherwise providing all the amenities required 1 Grammatical and content analysis of problem descriptions in the context of ISD have been pioneered by methodologies such as NIAM [Verheijen & van Bekkum, 1982]. Chapter 7. IFIP Working Conference Case Study 187 for a conference. • Invitation Letter. A piece of text addressed to an individual inviting the individual to submit a paper to a conference. • Letter of Intent A piece of text addressed to the Programme Committee indicating an intent to submit a paper in response to a call for papers. • Author. A n individual who produces a paper. • Attendee. A n individual who has expressed an intent to attend a conference. • Paper. A piece of writing or text, produced by an author or authors, which has been submitted to the Working Conference. A selected paper is one which has been duly refereed and recommended for inclusion in a particular session. • Text A n organized collection of symbols expressing ideas, suggestions, and other conceptual information. Can be physically expressed in a variety of physical or electronic formats. • Facility. A building, location, or other physical location at which some IFIP con-ference activity can occur. • Referee. A n individual who is responsible for evaluating a paper. • Referee Report. A text giving a judgement upon a paper. Written by a Referee (or referees). • Chairman. A n individual who is responsible for a specific session. Chapter 7. IFIP Working Conference Case Study 188 7.2 O B C M Interpretation of the IFIP Case It should be noted that much of the preliminary analysis above is open to interpretation and alternate formulation. Indeed, Bunge's Ontology stresses that our understanding of the world is a matter of state of art and depends on our "available knowledge, as well as upon our abilities, goals and even inclinations" [1977, p. 127]. Although other versions are possible, in this chapter the IFIP case study is described as an O B C M model in the following terms. • Things which can be represented in O B C M by simple objects. These are described by the following model objects. P E R S O N A U T H O R A T T E N D E E R E F E R E E T E X T F A C I L I T Y • Things which can be represented as compositions of the simple objects implied above. These can be described by the following models. I N V I T A T I O N L E T T E R I N T E N T L E T T E R P A P E R R E F E R E E R E P O R T . • Further components of the IFIP case are viewed as aggregations of the objects Chapter 7. IFIP Working Conference Case Study 189 above. A Programme Committee, for example, is an aggregation of persons, invita-tion and intent letters, papers, referee reports and so forth. A Working Conference Session is organized around a number of selected papers and a facility (or facilities) in which to meet. A Working Conference is a collection of sessions. The IFIP system itself is an aggregation of all the objects of interest in the system. These components can be described by the models P R O G R A M M E C O M M I T T E E O R G A N I Z I N G C O M M I T T E E SESSION W O R K I N G C O N F E R E N C E IFIP. The next few sections briefly sketch the O B C M models for this interpretation. Details of the formal definitions of state functions, law statements and change functions are fully described in Appendix D. 7.2.1 Simple Objects The model object P E R S O N describes all human beings (or individuals) of interest to the IFIP problem. A collection of surrogates Sp is assumed, each of which corresponds to some person of interest. A n author is an individual who is involved in producing a paper. The model object A U T H O R is a view of persons. That is, the surrogates for A U T H O R is a subset Spa C sP. A n attendee is an individual who has declared an intent to attend a Working Con-ference. The model object A T T E N D E E is a view of persons. That is, the surrogates for A T T E N D E E is a subset SPt C SP. Chapter 7. IFIP Working Conference Case Study 190 A n referee is an individual who has agreed to referee papers for a Working Conference. The model object R E F E R E E is a view of persons. That is, the surrogates for R E F E R E E is a subset Spr C Sp. A text is an organized collection of symbols expressing ideas, suggestions, and other information.2 Assume a collection of surrogates STX each corresponding to some unique text. 7.2.2 Composite Objects A n invitation letter or call for papers is a piece of text addressed to some individual inviting that individual to submit a paper on some topic. It is represented by the model object INVITATION. The possible surrogates for INVITATION is defined as Sc = Sp x STX, that is, an invitation letter is composed of a P E R S O N object and a T E X T object.3 A n intent letter is a text from some individual indicating an intent to submit a paper in response to an invitation. It is represented by the model object I N T E N T whose possible surrogates are defined as SI = Sp x STX, A paper is a text produced by an author or authors, which has been submitted to the Working Conference in response to a call for paper. It is modelled by P A P E R with 2It can be argued that in Bunge's ontology, text is not a substantial things and cannot be represented by a model thing (see also [Bunge, 1977, pp. 116-117]). This thesis assumes, however, that a text has some physical form which can be described by a model object. 3In the interest of simplicity, the possibility of addressing an invitation letter jointly to more than one individual is not considered. Chapter 7. IFIP Working Conference Case Study 191 possible surrogates4 SpP = 2Sp° x STx. That is, for O B C M modelling purposes, a paper is an aggregate of one or more authors and a text. A Referee Report is a text written by a referee, commenting upon a paper. It is described by the model R E F E R E E R E P O R T . Assuming for simplicity that a paper is assessed by a single referee, the surrogate for a referee report is defined as SRR = SRX Spp x STX-That is, for O B C M modelling purposes, a referee report is an aggregation of a referee, a paper and a text commenting upon the paper. 7.2.3 Committees and Conferences For O B C M modelling purposes, the Programme Committee is viewed as an aggregation of the invitation letters, intent letters, papers, and referee reports which are required to support the activities of the Committee. The Programme Committee is represented by the model object P R O G C O M and its surrogate is defined as SPC = 2Sc x 2 5 / x 2Sp" x 2Srr. Conceptually, in the O B C M / I S model, as invitations are generated, they are added to the Programme Committee. As intent letters and papers are received, they are also added to the Programme Committee. And when a paper is distributed for refereeing, a referee report is generated and added to the Programme Committee. 4This is a fairly liberal interpretation. A more restrictive version might assume, for example, that the only papers of interest are those (1) in response to a call (ie. no unsolicited papers are acceptable) and (2) for which an intent to submit was declared (ie. there is an intent letter on file). In this case, the surrogates for PAPER would be modified as Spp = 2sPa x STX X SC X SI. Chapter 7. IFIP Working Conference Case Study 192 For O B C M modelling purposes, the Organizing Committee is viewed as a set of facilities and attendees. Soc — SF x Spt-Conceptually, in the model, as facilities are located, they are added to the composition of the Organizing Committee. Similarly, as individuals confirm their intent to attend, they are added to the Organizing Committee. A Working Conference consists of a Programme Committee, an Organizing Commit-tee and a number of sessions. It is described by the model W O R K I N G C O N F E R E N C E . Its surrogate is Swc = 2 5 s X SpcOM x SOCOM The IFIP is the collection of all Working Conferences and all individuals of interest to the IFIP system.5 It is described by the model IFIP which has the surrogates SIFIP = 2 W x 2Sp. 7.3 IFIP Case S tudy - Opera t ion The OBIS for the IFIP case study consists of the aggregation of all the objects of interest to the application. The OBIS is itself an object, in this case, of type IFIP. Call this object IFIP. Figure 7.1 shows selected aspects of IFIP in O B C M visual notation. IFIP is viewed as an aggregation of Working Conferences and people. Change functions allow users to add new Working Conferences and people to the composition of IFIP in response to conditions in the real world. A Working Conference, in turn, is composed of one Programme Committee, one Organizing Committee and any number of Sessions. 5 This is an appropriate place to populate with objects of type PERSON since individuals can partic-ipate in several Working Conferences. Chapter 7. IFIP Working Conference Case Study 193 7.3.1 Populating the IFIP Starting from IFIP, new Working Conferences can be created and added by invoking iFZP.cAddConference. The act of creating a new Working Conference results in the creation and inclusion of a Program Committee and an Organizing Committee for the new conference.6 7.3.2 Programme Committee Activities The activities of the Programme Committee, as specified in the problem statement, are supported as follows. 1. Preparing a list for the call for papers. The value of PROGCOM.fCallList returns a set of persons in the composition of IFIP from which invitations can be generated. For each object in fCallList, an object of type INVITATION is created. In the prototype, these are created manually and added to the composition of the Pro-gram Committee. However, in a working system, invitations would be generated automatically by the system. 2. Registering letters of intent. For each letter of intent received by the Programme Committee, an object of type I N T E N T is created and added to the Programme Committee. 3. Registering papers. For each paper received by the Programme Committee, an object of type P A P E R is created and added to the Programme Committee. 4. Distributing papers among referees. The distribution of papers among referees is represented by creating objects of type R E F E R E E R E P O R T . This involves bringing together a referee with a paper. 6 T h i s is automatically performed as part of WORKINGCONFERENCE . c ln i t . Chapter 7. IFIP Working Conference Case Study 194 5. Collecting Referee Reports. The collection of referee reports is represented by adding evaluations to referee reports as they are received by the committee. 6. Grouping papers into sessions and selecting chairmen This is represented by in-voking WORKINGCONFERENCE.cAddSession. 7 Figure 7.2 illustrates some of the basic structure of a Programme Committee in the O B C M visual notation. Invitations and letters of intent are seen as an aggregation of people and text. A paper is an aggregation of one or more authors and a text. A referee report is an aggregation of a paper, a referee and a text (commenting upon the paper).8 The visual notation as developed in Chapter 4 does not provide a specific way of showing that authors and referees are also persons but an additional comment such as that shown in the figure is useful. 7.3.3 Organizing Committee Activities The activities of the Organizing Committee as specified in the problem description are supported as follows. 1. Preparing a list of invitees. The list of invitees is simply again a list of all persons in the composition of IFIP. Note that both the Organizing Committee and the Programme Committee are capable of generating the same list. 2. Priority Invitations. The IFIP problem description does not define the meaning of priority invitations or their significance. In this version of the case, it is assumed that invitations above include priority invitations. 3. Invitations to authors of accepted papers. Since all persons receive invitations and authors are persons, it is assumed that this is a redundant requirement for the 7The selection of chairmen is not detailed in this presentation of the case study. 8For clarity, Figure 7.2 repeats the model object TEXT several times. Chapter 7. IFIP Working Conference Case Study 195 OBIS. A list of authors only is possible, however, by scanning for all objects of type A U T H O R in the composition of the Working Conference. 4. Invitations to authors of rejected papers. This is also assumed to be a redundant requirement. 5. Avoiding duplicate invitations. Duplicate invitations are avoided because the col-lection of objects of type P E R S O N in the composition of IFIP is a set. 6. Registering acceptance of invitations. The registration of invitation acceptances is represented by the creation of objects of type A T T E N D E E as each acceptance is received. 7. Generating final list of attendees. Lists of attendees can be generated by Session. The final list of attendees is union of the sets of attendees in the composition of all sessions of the Working Conference. 7.3.4 Implementation of the IFIP Case Study Figures 7.3 through 7.5 depict the IFIP Case Study as implemented in the O B C M / I S Prototype Shell described in Chapter 6.9 In Figure 7.3, the arrow (a) represents the addition of a Working Conference, in this case, WC#1, to IFIP. When WC#1 is created, Programme and Organizing Committees were also created and added to WC#1. Also at some time, a Session was created and added to WC#1. These activities are not shown but the resulting composition of WC#1 is shown by scanning its A-composition as indicated by arrow (b). Figure 7.4 shows how the prototype deals with the Programme Committee. Scanning its A-composition (arrow (a)) reveals that the committee has issued three invitations 9These figures attempt to summarize the dynamics of user interaction. Therefore, they vary somewhat from the actual screen images produced by the prototype. Chapter 7. IFIP Working Conference Case Study 196 letters and that two individuals (ie. objects Mary and John) have filed an intent to submit papers. Two papers (Objects and Bunge) have been received by the committee and a referee report has been commissioned for one of these (the Objects paper). Arrow (b) shows a shift in focus to the paper Bunge. Scanning the composition of Bunge (arrow (c)) reveals how it is composed of the author John and a text. Shifting the focus to the text of the paper (arrow (d)) reveals an object with the actual written text. Figure 7.5 shifts the focus to the paper's author, John. Arrow (a) shows objects with the same surrogate as the author John. As revealed, an object of type P E R S O N exists which shares the same surrogate. Arrow (b) shows the part-of context of the author John. It shows that John is part-of the paper Bunge, Programme Committee, a Working Conference, and finally, IFIP itself. 7.4 O B C M / I S and Other ISD Approaches Although many solutions to the IFIP Working Conference problem have been published [Olle et al., 1986], the assessment and comparison of methodologies still poses enormous difficulties [Flint, 1986; Brodie et al., 1983; Bubenko et al., 1983; Rzevski, 1983]. For example, Sol [1983] suggests at least five different approaches for such assessments: 1. Describe an ideal methology and evaluate against it. The problem is, of course, to develop the ideal. 2. Distill a set of important features from various methodologies. Determination of which features are important, however, depends heavily on subjective evaluation. 3. Formulate a priori hypotheses on the partial ordering of features and their impor-tant. Again, such hypotheses are difficult to derive. Chapter 7. IFIP Working Conference Case Study 197 4. Define a meta-language for describing and comparing a wide range of methodolo-gies. However, the basis of such a meta-language is not well-understood. 5. Follow a contingency approach whereby a methodology is evaluated for specific situations. A true comparison is difficult with such an approach. Research is ongoing in understanding and developing an appropriate basis for evaluation and comparison, as well as for creating taxonomies of ISD methodologies [Olle et al., 1983]. Anything beyond a superficial comparison of OBCM/IS to other methodologies is, therefore, beyond the scope of the current work. Further, it is important to stress that the intent of this thesis is not simply to generate another Semantic Data Model or ISD Methodology but rather to explore the feasibility of an ontology-based approach to ISD. However, some brief comments placing OBCM/IS in relation to other ISD approaches are appropriate. To this end, these comments are organized according to Brandt's eight part taxonomy for comparing ISD methodologies [Brandt, 1983]. This taxonomy can be summarized as follows: 1. Origin and Experience. This reports on the environment in which the methodol-ogy has been developed and is practiced. Differences in academic and commercial methodologies are highlighted. 2. Development Process. Coverage of the development process is discussed here. The transformation of the final specification to programs in of special interest. 3. Model. The basic constructs, degree of formalism, mathematical or other founda-tions, etc. are of interest. 4. Iteration and Tests. This addresses the validation and verification aspects of a methodology. Chapter 7. IFIP Working Conference Case Study 198 5. Representation Means. Here, use of graphical elements, formal languages and other presentation features are covered. 6. Documentation The integration of documentation and its importance are dis-cussed. 7. User Orientation The knowledge expected of the end user, and ways of user par-ticipation are of interest here. The following sections briefly summarize OBCM/IS according to these parameters. 7.4.1 Origin and Experience OBCM/IS was developed over a two year period in an academic environment. Some experience has been gained utilizing the Smalltalk prototype shell, including an imple-mentation of the IFIP problem. A major feature is that its origins are based on a significant theory of the structure of the world, ie. ontology, rather than implementation considerations. Another impor-tant feature is its use of modern, object-oriented concepts (which are supported by its underlying theoretical foundations). 7.4.2 Development Process OBCM requires an analysis of the application according to ontological principles. The analysis then proceeds to a formal OBCM specification, a direct implementation into an OBIS, and end-use. An explicit logical or physical design phase is missing. The original constructs in the OBCM are carried forward to the end use of the resulting system. Written and visual notations as well as an implementation shell support the process. In particular, the ability to directly implement the OBCM specification and to directly interact with the results of the implementation should be noted. This is an attempt to Chapter 7. IFIP Working Conference Case Study 199 achieve the "homogeneous path" from conceptual specification to end-use discussed in Chapter 1 of this thesis. 7.4.3 Model The model is ontology-based as derived from Bunge. The basic constructs are not re-lated to any prominant database or ISD models such as entity-relationship or relational. Instead, they are grounded in ontology. Basic concepts such as thing, property, change, state, etc. are explicitly defined. OBCM/IS shares with semantic models an emphasis on the "meaning" of data as well as its structure. Unlike most semantic models, however, OBCM/IS supports a very general structure and depends on the use of law statements to represent relationships among objects. 7.4.4 Iteration and Test OBCM/IS can be applied iteratively starting with simple models which are continually being refined and enhanced with additional state functions, law statements and change functions. An OBIS is "self-testing" in the sense that the entire system and all objects within the system are always subject to validation against law statements.10 7.4.5 Representation Means A written and visual notation have been described in Chapter 4 of this thesis. Im-provements on these as well as a complete formal language are a desirable and possible enhancements. 1 0 T h i s does not imply that the OBIS is error-free since the original analysis and formulation of law statements might be in error. Chapter 7. IFIP Working Conference Case Study 200 7.4.6 Documentation OBCM/IS is self-documenting in that, in theory, access is always available to state func-tions, law statements and change functions of model objects. These fully define all aspects of an implementation. State functions, law statements and change functions will be, in principle, be available to the system user in their original form although in practice, they may be more readily available in their implemented form, ie. as program code. 7.4.7 User Orientation OBCM/IS is designed for use by both end-users and system developers. In principle, end-users can specify the conceptual model and operate an implementation which directly corresponds to the original conceptual model. 7.4.8 Tools and Prospects A prototype shell is available but will require considerable refinement for practical use. Many of the ideas behind object-orientation can also be applied, often directly to OBCM/IS. In particular, concepts such as software reusability, graphical user interfaces (GUI), and OOPL software development environments are compatible with OBCM/IS. Therefore, while OBCM/IS is still an academic product with little practical applica-tion, it can both take advantage of and contribute to modern software practice. 7.5 Summary This chapter has described an OBCM/IS solution to the IFIP Working Conference prob-lem. A detailed comparison of OBCM/IS to other Semantic Models and IS methodologies is beyond the scope of the current work. However, this chapter concludes with a brief set of comments attempting to relate OBCM/IS to current practice in ISD. Chapter 7. IFIP Working Conference Case Study 201 It was not the intent of this thesis to produce a complete and full O B C M / I S spec-ification in all its fine detail. 1 1 Nor was there any attempt to generate a customized, production-quality implementation. Such an effort would primarily be a matter of addi-tional detail but no significant new principles. What was shown in this chapter and in Appendix D, however, is how an ontology-based interpretation of the IFIP problem can be sustained and how an O B C M represen-tation of the problem can be generated. The adequacy of the prototype shell of Chapter 6 was illustrated, at least for the IFIP problem, by an actual OBIS implemention of the case study. In summary, the material in this chapter together with Appendix D demonstrates the feasibility of an ontology-based approach to IS development which unifies analysis, implementation and end-use. Moreover, the written problem description does not provide the necessary particulars. C h a p t e r 8 C o n t r i b u t i o n s a n d E x t e n s i o n s 8.1 T h e s i s S u m m a r y This thesis has developed an object-oriented model for the conceptual modelling of in-formation systems with a theoretical grounding in ontology. Further, a framework for systems implementation based on this model was presented. A "proof of concept" pro-totype was implemented to advance the model-building, illustrate the major principles, and explore practical applications of the model. Consider the overall goal of this research as defined in Chapter 1: To define and formalize a theory-based, object-oriented metamodel for describing and developing Infor-mation Systems. In working toward this objective, two sub-goals were articulated in terms of the following research questions: 1. Can the intuitions in the object paradigm be sufficiently formalized into a theory-based, Conceptual Modelling scheme for Information Systems Development? 2. Can such a formalization be sufficiently operationalized to provide a single, unifying principle for the conceptual modelling, implementation and end-use of Information Systems? The first of these was addressed by appealing to metaphysics or ontology. The basic premise behind this approach is that if a conceptual model is an abstraction of reality, then the constructs in the model should be based on a theory of reality, ie., an ontology. 202 Chapter 8. Contributions and Extensions 203 The well-known system of Mario Bunge was chosen for its rigor, formalism and accep-tance among the scientific community. This system was operutionalized into the Object-Based Conceptual Model or OBCM. Thus, unlike many other ISD approaches, all of the underlying assumptions are explicitly stated and the basic principles and concepts are formally defined. In the sense that ontology helps us better understand reality, it is hoped that OBCM provides the potential for better models of IS applications. The second sub-goal was addressed by the Object-Based Information System or OBIS, a framework for implementing IS applications expressed in terms of OBCM. This frame-work deals with issues such as implementing abstract OBCM constructs, maintaining semantic continuity between the application and the implementation, and producing user interfaces consistent with the ontological approach. The OBIS is a direct implementation of the constructs in the OBCM model of the application. This has the following important implications. 1. The analyst and user interpret the application in accordance with ontological prin-ciples. This interpretation is the OBCM-based conceptual model or specification. 2. There is no concept of logical or physical design, in which the designer attempts to convert a specification to some technically feasible IS design. Instead, the imple-mentor works directly from the OBCM using a set of tools and/or programming protocols to implement the analyst's specification immediately into a systems im-plementation. 3. The end-user interacts directly with this implementation. Thus, OBIS strives for a seamless, homogeneous path from conceptual model to the end-user. As such, it is an attempt to unify three major aspects of information systems development: analysis, implementation and user interface. Chapter 8. Contributions and Extensions 204 The prototype which was developed as part of this thesis attempts to provide a practical demonstration of the potential of OBCM/IS as an approach to ISD. Its main features can be summarized as follows: 1. is theory-based and object-oriented; 2. employs a small set of simple, unifying principles; 3. has an inherently homogeneous structure composed of very high-level, abstract entities which can be directly related to the application domain; and 4. supports a direct manipulation style of end-user interface. 8.2 Contributions In chapter 1, a number of potential contributions offered by the thesis were listed. These can be summarized as follows. 8.2.1 Theoretical Contributions Theory-Based Model for ISD OBCM/IS is an attempt to ground ISD in a basic metaphysics. Previous approaches to ISD are usually not theory-based and have tended to derive from individual experience, past practice, rules of thumb, and technological trends. The proposed model, therefore, provides one answer to the call for a theory-based approach to Information Systems Development. This is the main theoretical contribution of the thesis. Extension of the Object Paradigm The proposed model is object-oriented and provides a conceptual context within which the intuitive appeal and modelling power of the object paradigm can be better understood. Chapter 8. Contributions and Extensions 205 Thus, it extends the use of the object paradigm to the general case of Information Systems Development. Reducing the Semantic Gap This thesis proposes a well-defined, theory-based modelling construct object which can be shared by the analysts, implementors and end-users of information systems. Since all parties share the same basic construct, the likelihood of "semantic gaps" between users and systems developers is reduced. 8.2.2 Practical Contributions Implementation Although there have been a number of calls for theoretical models, it is not obvious how theory can actually be applied in practice. The prototype developed in this thesis is crude and designed to be illustrative only. However, it provides a demonstration of the practical impact of a basic theory such as ontology on the design, implementation and use of information systems. This demonstration is perhaps the primary practical contribution of this thesis. OBIS Prototype Tools The prototype utilizes a simple protocol or programming discipline to implement the O B C M object construct. Further, it incorporates a number of working tools and imple-mentation ideas such as the "shell" concept, object scanners, service menus, and visual interfaces. Thus, it demonstrates how basic concepts from object-oriented programming environments can be adapted to the ISD context. Chapter 8. Contributions and Extensions 206 8.3 Future Extensions to the Research T h e ideas a r i s i n g f r o m th is research suggest severa l poss ib le ex tens ions . 8.3.1 Extensions and Improvements to O B C M / I S Enhancements to the Model A s d iscussed i n C h a p t e r 4, B u n g e a l lows for a n e x p l i c i t t i m e p a r a m e t e r i n his t heo ry of r ep resen ta t ion . O p e r a t i o n a l i z i n g th is aspect of th i s o n t o l o g y c a n p o t e n t i a l l y resul t i n an ex t ens ion of O B C M w i t h t i m e . A n o t h e r poss ib le enhancement is the deve lopment of a f o r m a l l anguage for O B C M u s i n g B u n g e ' s o n t o l o g y as a base. Improving the Prototype Shell Since the c o n t r i b u t i o n o f th is projec t focussed o n the t h e o r e t i c a l m o d e l a n d "p roof of concep t " , ne i the r the efficiency of the she l l n o r i t s user in ter face was g i v e n h i g h p r io r i t y . T h e p r o t o t y p e i s , therefore, not su i t ed for p r o d u c t i o n use a n d w o u l d requ i re pe r fo rmance enhancements such as (1) i m p r o v e d m e c h a n i s m s for l a w v a l i d a t i o n a n d the p a r t i a l order-i n g of change func t ions , (2) i m p r o v e d user interface (such as i n c o r p o r a t i o n of the O B C M v i s u a l n o t a t i o n ) , a n d (3) genera l i m p r o v e m e n t s i n robustness , speed a n d pe r fo rmance . Automated Tools T h e cur ren t i m p l e m e n t a t i o n makes extens ive use o f the s t a n d a r d S m a l l t a l k p r o g r a m m i n g e n v i r o n m e n t to create M o d e l O b j e c t Classes ( M O C ' s ) , s ta te f u n c t i o n me thods , change m e t h o d s , a n d P r o l o g clauses for express ing l a w s ta tements . A poss ib le ex t ens ion is to c u s t o m i z e o r create a p r o g r a m m i n g env i ronmen t to a u t o m a t e the t a sk of genera t ing M O C ' s d i r e c t l y f r o m the O B C M spec i f i ca t ion . T h i s w o u l d i n c l u d e parsers to in te rp re t Chapter 8. Contributions and Extensions 207 O B C M notation and automatically generate the necessary software (eg. classes and methods if Smalltalk is used as the host language). Rapid Prototyping and C A S E Many of the ideas suggested by the OBIS implementation framework potentially simplify and streamline the systems development process. As such, O B C M / I S can potentially serve as the basis of a rapid prototyping or Computer-aided software engineering ( C A S E ) tool [Hughes k Clark, 1990]. Interfacing with Conventional Systems In concept, an O B C M / I S can obtain the values for state variables of its objects from conventional databases. The values of state functions can also be returned to the con-ventional database. In this way, an O B C M / I S can act as a common access point to heterogeneous data bases [Chung, 1990]. 8.3.2 Enhancements to the Ontological Basis In a different direction, enhancements can be made to the Ontological basis itself. For instance, in the opinion of this thesis, Bunge's ontology provides only a very general model of change. A more specific model of change may improve substantially the dynamic aspects of O B C M . More generally, a research programme to build an ontology (or ontologies) suitable for IS modelling may prove an important step in developing future theories of information systems. Bibliography [1] Abbott, R. "Knowledge Abstraction" CACM. August, 1987. [2] Afsarmanesh, H. and McLeod, D. "A Framework for Semantic Database Models". New Directions for Database Systems. Ariav, G. and Clifford, J. (Eds). Ablex, 1986. [3] Banerjee, J., Chou, H., Garza, J., Kim, W., Woelk, D., and Ballou, N. "Data Model Is-sues for Object-Oriented Applications". ACM Transactions on Office Information Systems. January, 1987. [4] Baroody, A. and DeWitt, D. "An Object-Oriented Approach to Database System Imple-mentation". ACM Transactions on Database Systems. December, 1981. [5] Bassett, P. "Frame-Based Software Engineering". IEEE Computer. July, 1987. [6] Beech, D. "Groundwork for an Object-Oriented Database Model". Research Directions in Object-Oriented Programming. Shriver, B. and Wegner, P. (Editors). MIT Press, 1987. [7] Berzins, V., Gray, M. and Nauman, D. "Abstraction-Based Software Development". CACM. May, 1986. [8] Blaha, M., Premerlani, W. and Rumbaugh, J. "Relational Database Design Using an Object-Oriented Methodology". CACM. April, 1988. [9] Booch, G. "Object-Oriented Design". Software Engineering with ADA. Ben-jamin/Cummings, 1983. [10] Booch, G. "Object-Oriented Design". IEEE Transactions on Software Engineering. Febru-ary, 1986. [11] Borgida, A., Greenspan, S. & Mylopoulos, J. "Knowledge Representation as the Basis for Requirements Specifications". IEEE Computer. April, 1985. [12] Borgida, A., Mylopoulos, J., k. Wong, H. "Generalization/Specialization as a Basis for Software Specification". On Conceptual Modelling. Brodie, Mylopoulos & Schmidt (Ed), Springer-Verlag, 1984. [13] Brachman, R. "What IS-A Is and Isn't: An Analysis of Taxonomic Links in Semantic Networks". Computer. October, 1983. [14] Brandt, I. "A Comparative Study of Information System Design Methodologies". Infor-mation Systems Design Methodologies: A Feature Analysis. Olle, T., Sol, H., and Tully, C, Editors. North-Holland. 1983. 208 Bibliography 209 [15] Brodie, M. "On the Development of Data Models". On Conceptual Modelling. Brodie, Mylopoulos & Schmidt (Ed), Springer-Verlag, 1984. [16] Brodie, M., Mylopoulos, J. & Schmidt, J. (Eds). On Conceptual Modelling. Springer-Verlag, 1984. [17] Brodie, M. and Mylopoulos, J. "Knowledge Bases and Databases: Semantic vs. Compu-tational Theories of Information". New Directions for Database Systems. Ariav, G. and Clifford, J. (Eds). Ablex, 1986. [18] Brodie, M. and Ridjanovic, D. "On the Design and Specification of Database Transactions". On Conceptual Modelling. Brodie, Mylopoulos & Schmidt (Ed), Springer-Verlag, 1984. [19] Brodie, M., Ridjanovic, D., and Silva, E. "On A Framework for Information System Design Methodologies". Information Systems Design Methodologies: A Feature Analysis. Olle, T., Sol, H., and Tully, C , Editors. North-Holland. 1983. [20] Brooks, F. "No Silver Bullet: Essence and Accidents of Software Engineering". Computer. April, 1987. [21] Bubenko, J. "Information Modelling in the Context of Systems Development". Information Processing 80. Lavington, S. (Ed). North-Holland, 1980. [22] Bubenko, J. Information System Methodologies - A Research View. Syslab Report No 40, February, 1986. [23] Bubenko, J., Gustafsson, M., and Karlsson, T. "Comments on Some Comparisons of In-formation System Design Methodologies". Information Systems Design Methodologies: A Feature Analysis. Olle, T., Sol, H., and Tully, C , Editors. North-Holland. 1983. [24] Bunge, M. Treatise on Basic Philosophy: Volume 3, The Furniture of the World. D. Reidel Publishing. 1977. [25] Bunge, M. Treatise on Basic Philosophy: Volume 4, A World of Systems. D. Reidel Publishing. 1979. [26] Buzzard, G. and Mudge, T. "Object-Based Computing and the ADA Programming Lan-guage". IEEE Computer. March, 1985. [27] Cameron, J.R. "Two Pairs of Examples in the Jackson Approach to Systems Development'" IEEE Tutorial on Software Design Techniques. Freeman, P. and Wasserman, A. (Editors). IEEE, 1983. [28] Cameron, J.R. "An Overview of JSD". IEEE Transactions on Software Engineering. February, 1986. Bibliography 210 [29] Carlson, W. "Business Information Analysis and Integration Technique (BIAIT) - The New Horizon". Advanced System Development/Feasibility Techniques. Couger, J., Colter, M., and Knapp, R. (Editors). John Wiley, 1982. [30] Chen, P. "The Entity-Relationship Model: Toward a Unified View of Data". ACM Trans-actions on Data Base. March, 1976. [31] Chung, C. "DATAPLEX: An Access to heterogeneous Distributed Databases". CACM. January, 1990. [32] Codd, E. "Extending the Database Relational Model to Capture More Meaning". ACM Transactions on Data Base. December, 1979. [33] Cox, Brad. Object-Oriented Programming. Addison-Wesley, 1986. [34] Cox, Brad. "Message/Object Programming: An Evolutionary Change in Programming Technology." IEEE Software. January, 1984. [35] Cox, B. and Hunt, B. "Objects, Icons and Software-IC's". BYTE. August, 1986. [36] Danforth, S. and Tomlinson, C. "Type Theories and Object-Oriented Programming". ACM Computing Surveys. March, 1988. [37] Diederich, J. and Milton, J. "Experimental Prototyping in Smalltalk." IEEE Software. May, 1987. [38] Digitalk. Smalltalk/V286: Tutorial and Programming Handbook. 1988. [39] Fischer, G. "Cognitive View of Reuse and Redesign". IEEE Software. July, 1987. [40] Fishman, D., Beech, D., Cate, H., Chow, E., Connors, T., Davis, J., Derrett, N., Hoch, C , Kent, W., Lyngbaek, P., Mahbod, B., Neimat, M., Ryan, T., and Shan, M. "Iris: An Object-Oriented Database Management System". ACM Transactions on Office Informa-tion Systems. January, 1987. [41] Flint, R. "An Activity Model of the Working Conference Problem". Information Systems Design Methodologies: Improving the Practice. Olle, T., Sol, H., & Verrjin-Stuart, A (Eds). Elsevier Science Publishers, 1986. [42] Flint, R. and Leveson, N. "The PAMS Approach top Modelling Database Activity". In-formation Systems: Theoretical and Formal Aspects. Sernadas, A., Bubenko, J., & Olive, A. (Eds). North-Holland, 1985. [43] Floyd, C. "A Comparative Evaluation of System Development Methods". Information Systems Design Methodologies: Improving the Practice. Olle, T., Sol, H., & Verrjin-Stuart, A (Eds). Elsevier Science Publishers, 1986. [44] Foley, J. "Interfaces for Advanced Computing". Scientific American. October, 1987. Bibliography 211 [45] Gibbs, S. "Conceptual Modelling and Office Information Systems". Office Automation. Tsichritzis, D. (Editor) Springer-Verlag, 1985. [46] Gilmore, P. Concepts and Methods for Database Design. Technical Report 87-31. Depart-ment of Computer Science. University of British Columbia. 1987. [47] Goguen, J., Thatcher, J., and Wagner, E. "An Initial Algebra Approach to the Specifi-cation, Correctioness, and Implementation of Abstract Data Types". Current Trends in Programming Methodology. Volume IV, Data Structuring. Yeh, R. (Ed). Prentice-Hall, 1978. [48] Goldberg, A. "Programmer as Reader". IEEE Software. September, 1987. [49] Goldberg, A. Smalltalk-80: The Interactive Programming Environment. Addison-Wesley, 1984. [50] Goldberg, A. and Robson, D. Smalltalk-80: The Language and Its Implementation. Addison-Wesley, 1983. [51] Greenspan, S. Requirements Modelling: A Knowledge Representation Approach to Software Requirements Definition Computer Systems Research Group, University of Toronto, 1984. [52] Greenspan, S. and Mylopoulos, J. A Knowledge Representation Approach to Software En-gineering: The Taxis Project. CIPS Proceedings, Ottawa, 1983. [53] Hacking, I. Representing and Intervening. Cambridge University Press, 1983. [54] Halbert, D. and O'Brien, P. "Using Types and Inheritance in Object-Oriented Program-ming". IEEE Software. September, 1987. [55] Harel, D. "On Visual Formalisms". CACM. May, 1988. [56] Hoare, C.A.R. Communicating Sequential Processes. Prentice-Hall International, 1985. [57] Hughes, C. and Clark, J. "The Stages of CASE Usage." Datamation. February 1, 1990. [58] Hull, R. and King, R. "Semantic Database Modelling: Survey, Applications and Research Issues". ACM Computing Surveys. September, 1987. [59] IBM. "Business Systems Planning". Advanced System Development/Feasibility Techniques. Couger, J., Colter, M., and Knapp, R. (Editors). John Wiley, 1982. [60] Isner, J. "A Fortran Programming Methodology Based on Data Abstraction". CACM. October, 1982. [61] Jackson, M. Principles of Program Design Academic Press, 1975. [62] Jackson, M. System Development. Prentice-Hall International, 1983. Bibliography 212 Jacky, J. and Kalet, I. "An Object-Oriented Programming Discipline for Standard Pascal". CACM. September, 1987. Jansson, C-G. "A Framework for Representation". Information Systems: Theoretical and Formal Aspects. Sernadas, A., Bubenko, J., & Olive, A. (Eds). North-Holland, 1985. Kent, W. "Entities and Relationships in Information". Architecture and Models in Data Base Management Systems. Nijessen, G. (Editor). North Holland, 1977. Kent, W. Data and Reality. North Holland, 1978. Kent, W. "The Realities of Data: Basic Properties of Data Reconsidered". Data Semantics (DS-1). Steel, T. and Meersman, R. (Editors). North Holland, 1986. Kilov, H. "Reviews of Object-Oriented Papers". SIGMOD Record. December, 1989. Kim, W. and Lochovsky, F. Object-Oriented Concepts: Databases and Applications. ACM Press, Addison-Wesley, 1989. Kimura, G. "A Structure Editor for Abstract Document Objects". IEEE Transactions on Software Engineering. March, 1986. Konsynski, B. "Databases for Information Design". New Directions for Database Systems. Ariav, G. and Clifford, J. (Eds). Ablex, 1986. Kroenke, D. and Dolan, K. Database Processing. Science Research Associates, 1988. Kung, C. and Solvberg, A. "Activity Modelling and Behaviour Modelling". Information Systems Design Methodologies: Improving the Practice. Olle, Sol & Verrijn-Stuart (Ed). North-Holland, 1986. Lakoff, G. Women, Fire, and Dangerous Things. University of Chicago Press, 1987. Ledbetter, L. and Cox, B. "Software-IC's". BYTE. June, 1985. Ledgard, H. and Taylor, R. "Two Views of Data Abstraction". CACM. June, 1977. Liskov, B. and Guttag, J. Abstraction and Specification in Program Development. McGraw-Hill, 1986. Liskov, B. and Zilles, S. "Specification Techniques for Data Abstractions". IEEE Transac-tions of Software Engineering. March, 1975. Maier, D. and Stein, J. "Development and Implementation of an Object-Oriented DBMS". Research Directions in Object-Oriented Programming. Shriver, B. and Wegner, P. (Edi-tors). MIT Press, 1987. Mattessich, R. "Axiomatic Representation of the Systems Framework: Similarities and Differences Between Mario Bunge's World of Systems and My Own Systems Methodology". Cybernetics and Systems. 13:51-71, 1982. Bibliography 213 [81] Mattessich, R. "An Applied Scientist's Search for a Methodological Framework". Proceed-ings of the 11th International Wittgenstein Symposium. August, 1986. [82] Mattessich, R. "Prehistoric Accounting and the Problem of Representation: On Recent Archeological Evidence of the Middle-East from 8000 B.C. to 3000 B.C.". The Accounting Historians Journal. Vol 14, No 2, 1987. [83] Mattessich, R. "Social and Physical Reality in Accounting: Onion model vs. Pygmalion Syndrome". UBC Working Paper. 1989. [84] Mendelson, E. An Introduction to Mathematical Logic. Princeton: Van Nostrand. 1963. [85] Meyer, B. "Reusablity: The Case for Object-Oriented Design". IEEE Software. March, 1987. [86] Meyer, B. Object-Oriented Software Construction. Prentice-Hall, 1988. [87] Minsky, N. Law-Governed Systems. Technical Report LCSR-TR-101. Department for Computer Science. Rutgers University. 1989. [88] Minsky, N. and Rozenstein, D. "A Law-Based Approach to Object-Oriented Program-ming." OOPSLA '87 Proceedings. 1987. [89] Nierstrasz, 0. "An Object-Oriented System". Office Automation. Tsichritzis, D. (Editor) Springer-Verlag, 1985. [90] Nierstrasz, 0. "What is the 'Object' in Object-Oriented Programming?". Objects and Things. Tsichritzis, D. (Editor) 1987. [91] Nilsson, N. Principles of Artificial Intelligence. Tioga Publishing. 1980. [92] Olle, T., Sol, H., and Tully, C , Editors. Information Systems Design Methodologies: A Feature Analysis. North-Holland. 1983. [93] Orr, K. "Structured Systems Design". Advanced System Development/Feasibility Tech-niques. Couger, J., Colter, M., and Knapp, R. (Editors). John Wiley, 1982. [94] Pascoe, G. "Elements of Object-Oriented Programming". BYTE. August, 1986. [95] ParkPlace Systems, Inc. The Smalltalk-80 Programming System. Version 2.4- ParkPlace Systems, Inc, 1989. [96] Parsons, T. Non-existent Objects. Yale University Press. 1980. [97] Peckham, J. and Maryanski, F. "Semantic Data Models". ACM Computing Surveys. September, 1988. [98] Quillian, M. "Semantic Memory". Semantic Information Processing. Minskey (Ed). MIT Press, 1968. Bibliography 214 [99] Reiss, S. "An Object-Oriented Framework for Conceptual Programming". Research Direc-tions in Object-Oriented Programming. Shriver, B. and Wegner, P. (Editors). MIT Press, 1987. [100] Robson, D. and Goldberg, A. "The Smalltalk-80 System". BYTE. August, 1981. [101] Rosenquist, C. "Entity Life Cycle Models and their Applicability to Information Systems Development Life Cycles". The Computer Journal. Vol 25, No3, 1983. [102] Ross, R. Entity Modelling: Techniques and Application. Database Research Group, 1987. [1031 Royce, W. "Managing the Development of Large Software Systems: Concepts and Tech-niques." Proceedings of the Ninth International Conference on Software Engineering. IEEE Press, 1987. [104] Rosenquist, C. "Entity Life Cycle Models and their Applicability to Information Systems Development Life Cycles". The Computer Journal. Vol 25, No 3, 1982. [1051 Rozenshtein, D. and Minsky, N. "A Law-Governed Object-Oriented System". Journal of Object-Oriented Programming. Vol 1, No 6, 1989. [106] Rzevski, G. "On the Comparison of Design Methodologies". Information Systems Design Methodologies: A Feature Analysis. Olle, T., Sol, H., and Tully, C , Editors. North-Holland. 1983. [1071 Sciore, E. "Object Specialization". ACM Transactions on Information Systems. April, 1989. [1081 Shaw, M. "Abstraction Techniques in Modern Programming Languages". IEEE Software. October, 1984a. [1091 Shaw, M. "The Impact of Modelling and Abstraction Concerns on Modern Programming Languages". On Conceptual Modelling. Brodie, Mylopoulos &; Schmidt (Ed), Springer-Verlag, 1984b. [1101 Shneiderman, B. "Direct Manipulation: A Step Beyond Programming Languages". IEEE Computer. August, 1983. [llll Sibley, E. "The Evolution of Approaches to Information Systems Design Methodology". Information Systems Design Methodologies: Improving the Practice. Olle, T., Sol, H., & Verrjin-Stuart, A (Eds). Elsevier Science Publishers, 1986. [1121 Shlaer, S. and Mellor, S. Object-Oriented Systems Analysis: Modelling the World in Data. Yourdon Press, 1988. [1131 Smith, R., Barth, P. and Young, R. "A Substrate for Object-Oriented Interface Design". Research Directions in Object-Oriented Programming. Shriver, B. and Wegner, P. (Edi-tors). MIT Press, 1987. Bibliography 215 1141 S m i t h , J . and Smi th , D . "Database Abstract ions: Aggregat ion and Genera l iza t ion" . ACM Transactions on Data Base. June, 1977. 1151 Sol , H . " A Feature Analys is of Information Systems Design Methodologies: Method-ological Considerat ions". Information Systems Design Methodologies: A Feature Analysis. Olle , T . , So l , H . , and Tu l ly , C , Edi to rs . Nor th -Hol l and . 1983. 1161 Stamper, R . " A Logic of Social Norms for the Semantics of Business Informat ion". Data Semantics (DS-1). Steele, T . and Meersman, R . (Eds) . Nor th -Ho l l and , 1986. 1171 Stamper, R . "Towards a Semantic N o r m a l F o r m " . Database Architecture. Bracch i and Nijssen (Eds) . Nor th -Ho l l and , 1979. 1181 Stamper, R . "Aspects of D a t a Semantics: Names, Species and Complex Phys ica l Ob-jects". Information Systems Methodologies. Bracch i and Lockemann (Eds) . Springer-Ver lag , 1978. 1191 Stamper, R . "Phys ica l Object , H u m a n Discourse and F o r m a l Systems". Models in Database Management Systems. Nijssen ( E d ) . Nor th -Hol l and , 1977. 1201 Stefik, M . and Bobrow, D . "Object-Oriented Programming: Themes and Var ia t ions" . AI Magazine. W i n t e r , 1986. 1211 Stroustrup, B . The C++ Programming Language. Addison-Wesley. 1986. 1221 Ta r sk i , A . Introduction to Logic. Oxford Univers i ty Press. 1941. 123] Teorey, T . , Y a n g , D . &; Fry , J . " A Logica l Design Methodology for Re la t iona l Databases Us ing the Extended Ent i ty-Rela t ionship M o d e l " . ACM Computing Surveys. June, 1986. 124] Ts ichr i tz i s , D . (Ed i to r ) . Office Automation. Springer-Verlag, 1985. 125] Ts ichr i tz i s , D . "Objec twor ld" . Office Automation. Ts ichr i tz i s , D . (Edi to r ) Springer-Ver lag , 1985. 126] Ts ichr i tz i s , D . , F iume , E . , G ibbs , S. and Nierstrasz, 0 . " K N O s : KNowledge Acqu i s i t ion , Disseminat ion, and Man ipu l a t i on Objects" . ACM Transactions of Office Information Sys-tems. January, 1987. 127] van Frassen, B . The Scientific Image. Clarendon Press, 1980. 128] Verheijen, G . and van B e k k u m , J . " N I A M : A n Information Ana lys i s M e t h o d " . Proceedings of the IFIP WG 8.1 Working Conference. Ol le , T et a l . (Edi tors ) . Nor th -Ho l l and , 1982. [129] W a n d , Y . An Ontological Foundation for Information Systems Design Theory. W o r k i n g Paper . Facu l ty of Commerce, Univers i ty of B r i t i s h C o l u m b i a . Bibliography 216 [130] Wand, Y. "A Proposal for a Formal Model of Objects". Object-Oriented Concepts: Databases and Applications. Kim, W. and Lochovsky, F., Editors. ACM Press, Addison-Wesley, 1989. [131] Wand, Y. and Weber, R. Formalization of Information Systems Design. Working Paper. Faculty of Commerce, University of British Columbia. May, 1987. [1321 Wand, Y. and Weber, R. An Ontological Analysis of Some Fundamental Information Systems Concepts. Working Paper 88-MIS-002. Faculty of Commerce, University of British Columbia. March, 1988. [133] Wand, Y. and Weber, R. A Deep Structure Theory of Information Systems. Working Paper 88-MIS-003. Faculty of Commerce, University of British Columbia. March, 1988. [134] Warnier, J. Logical Construction of Systems. Van Nostrand Reinhold, 1981. [1351 Weber, R. Life's Complexities: The Decomposition of Systems. Working Paper. Faculty of Commerce, University of British Columbia. August, 1987. [136] Wegner, P. "The Object-Oriented Classification Paradigm". Research Directions in Object-Oriented Programming. Shriver, B. and Wegner, P. (Editors). MIT Press, 1987. [137] Winston, R. Artificial Intelligence. Addison-Wesley. 1984. [1381 Woo, C. An Object-Oriented Model for Supporting Office Work. Technical Report 88-MIS-025. MIS Division, Faculty of Commerce. University of British Columbia. 1988. [1391 Woodfield, S., Embley, D. and Scott, D. "Can Programmers Reuse Software?". IEEE Software. July, 1987. [1401 Young, J. and Kent, H. "Abstract Formulation of Data Processing Problems". Journal of Industrial Engineering. Nov.-Dec, 1958. [141] Zachman, J. "A Framework for Information Systems Architecture". IBM Systems Jour-nal. V. 26,N. 3, 1987. [142] Zalta, E. Abstract Objects. Reidel, Dordrecht. 1983. [1431 Zilles, S. "Types, Algebras and Modelling". On Conceptual Modelling. Brodie, Mylopou-los & Schmidt (Ed), Springer-Verlag, 1984. Appendix A Bunge's Theorems A . l T H E O R E M 1.1 The association of any two individuals is the supremum (least upper bound or l.u.b.) for them with respect to the part-whole ordering: If x, y € S then sup{x, y} = x o y. Proof. By associativity and idempotence x o (x o y) = (x o x) o y = x o y. By Definition 1 .2 1 the last formula is the same as: x C (x o y). Likewise y o (x o y) = x o y, whence y C (x o y). Hence x o y is an upper bound of x and y. It is also their least upper bound. In fact call z an upper bound of x and y, ie. x,y [Z z. Then x o y o z = z. Thus x o y C z. A.2 T H E O R E M 1.2 The world is the aggregation of all individuals: © = [S] = sup S. Proof. By Postulate 1.2, 2 © exists and is the last individual, ie. for every x € 5 , x C ©. But this individual fits the conditions of Definition 1.7, 3 ie. © = sup S. A . 3 T H E O R E M 1.3 The ordered quadruple < 5 , o, • , © > is a sup-semilattice with least element • and last element © with respect to the part-whole relation C Proof. By Theorem 1.1 (above) there exists a supremum for any two individuals, namely their association. DEFINITION 1.2. If x and y are substantial individuals, then x is a part of y iff x o y = y. Symbol: x C y. 2POSTULATE 1.2. There exists an individual such that every other individual is part of it. Ie. (3x)[x € Sk(y)(y e S => y C x)]. 3DEFINITlON 1.7. Let T C S be a set of substantial individuals. Then the aggregation or association of T, or [T] for short, is the supremum of T. Ie., [T] = sup T. 217 Appendix A. Bunge's Theorems 218 Besides, • is part of every individual, so it lies at the bottom of the net. Dually, © contains every individual, so it perches on top. These conditions, together with the commutativity of association, define a sup-semilattice. Appendix B Smalltalk OBIS Prototype Shell B . l O B C M / I S Primitives - OBIS (Object) subclass; #OBIS instanceVariableNam.es: surrogate stateFunctions history pOrder classVariableNames: SystemObject poolDictionaries: OBIS class methods OBIS methods asSet "Answers a set with self" 1 Set with:self. change:sf totvalue "Generic method to change value of :sf to .-value" | result old Value | CursorManager execute change, sf = #fAComp ifFalse:[ oldValue := stateFunctions at:sf ifAbsent:[nil]. stateFunctions at:sf asSymbol put:value]. (result := self validateLaws) ifTrue:[self cHistory:sf to:value] ifFalse:[ sf = #fAComp ifTrue:[self surrogateRemove:value] ifFalse:[stateFunctions at:sf put:oldValue]. 219 Appendix B. Smalltalk OBIS Prototype Shell 220 self validateLaws ifFalse:[Menu message:'System Error', self inspect]]. self sfUpdate. CursorManager normal change change Var:sf to:value "Generic method to change value of :sf to -.value. No validation 'performed." |result oldValue| CursorManager execute change. oldValue := stateFunctions at:sf if Absent: [nil]. stateFunctions at:sf asSymbol put:value. self cHistory:sf to:value. CursorManager normal change checkSurrogate:anObject "Find all other objects with same surrogate as -.anObject." | surrogates | t SystemObject fComp select:[:each| each surrogate = self surrogate] checkSurrogate:anObject with:surrogate "Verifies -.anObject has surrogate -.surrogate" |surrogateLattice| anObject surrogate isNil ifTrue:[surrogateLattice := (anObject lattice collect:[:each | each surrogate]) asSet] ifFalse:[surrogateLattice := Set with:anObject surrogate], surrogate do: [:each | surrogateLattice remove:each ifAbsent:[f false]]. surrogateLattice size = 0 ifTrue:[t true] ifFalse:[ | false]. cHistory:sfName to:sfValue "Update History" history addLast:(Association Appendix B. Smalltalk OBIS Prototype Shell key:Date today asSeconds + Time now asSeconds value:(Array withrsfName with:sfValue)). composition "Primitive function. Answer all objects in composition of current object" |objects| objects := Set new. (self surrogate composition) do:[:each | objects addAlheach objects], t objects debug "Systems testing method" self inspect initialize "Initialize all base state functions" self class = System ifIrue:[SystemObject :— self]. history:= OrderedCollection new. stateFunctions:= Dictionary new. stateFunctions at:#fKinds put:(Set with:self class); at:#fComp put:self fComp; at:#fAComp putrself fAComp; at:#fPartOf put:self fPartOf. pOrder := Set new. t nil. is Change:aChange "Verifies if change method" (aChange printString size >= 2 and: [ (aChange printString at: 1) == $c and: [ (aChange printString at: 2) isUpperCase ]]) ifTrue:[t true] ifFalse:[| false]. isFunctiontaFunction "Verifies if State Function method" Appendix B. Smalltalk OBIS Prototype Shell 222 (aFunction printString size >= 2 and: [ (aFunction printString at: 1) == $f and: [ (aFunction printString at: 2) isUpperCase ]]) ifTrue:[t true] ifFalse:[| false]. isLaw:aLaw "Verifies if Law method" (aLaw printString size >= 2 and: [ (aLaw printString at: 1) == $1 and: [ (aLaw printString at: 2) isUpperCase ]]) ifTrue:[t true] ifFalse:[| false]. isView:aMethod (aMethod printString size >= 2 and: [ (aMethod printString at: 1) == $v and: [ (aMethod printString at: 2) isUpperCase ]]) ifTrue:[T true] ifFalse:[f false]. latticeraComp "Primitive method. Answers the recursive composition of :aComp" |collection lattice aKinds comp| aKinds := self fKinds. collection :— OrderedCollection with:self. comp := aComp select:[:each | aKinds includes:each class]. comp remove:self. comp size = 0 ifTrue:[f collection asSet]. comp do:[:each| lattice := each composition. collection addAll:(each lattice:lattice)]. | collection asSet objectName "Answer the objectName and its Model Object name" Appendix B. Smalltalk OBIS Prototype Shell 223 | name | (self respondsTo:#fName) ifTrue:[name := self fName] ifFalse:[name := stateFunctions at:#fName ifAbsent:['object']]. | name,'<',self printString,'>'. objectOf*Kind:k in:objectSet "Returns first object ofKind:k in :objectSet" |aSet| aSet := (self perform:objectSet asSymbol) select:[:each | each class = k]. aSet size = 0 ifTrue:[T nil] ifFalse:[f (aSet asArray) at:l] objectsOfKind:k "Returns objects ofKindtk in System" | (SystemObject fComp) select:[:each | each class = k]. objectsOfKind:k in:objectSet "Returns objects ofKindik in :objectSet" t (self perform:objectSet asSymbol) select:[reach | each class = k]. objectsOfKind:k inSet:objectSet "Returns objects ofKind:k in :objectSet" | objectSet select:[:each | each class = k]. part Of instances "Primitive. Answers all part-of" |collection| instances size = 0 ifTrue:[| Set new], collection := OrderedCollection new. Appendix B. Smalltalk OBIS Prototype Shell 224 instances do: [reach | (each fComp includes:self) ifTrue: [collection add:each]]. | collection asSet same:vl as:v2 "Primitive. Answer true if vl same as v2" v l = v2 ifTrue:[T true], ((vl isKindOf:Collection) and:[ v2 isKindOf.-Collection]) ifFalse:[| false], v l do:[:each | (v2 includes:each) ifFalse:[f false]]. v2 do:[:each | ( v l includes:each) ifFalse:[| false]]. | true sfUpdate "Primitive. Updates state Functions and History" |sFunctions baseFunctions | baseFunctions := ModelObj selectors select:[:aSelector| self isFunction:aSelector]. SystemObject fComp do:[:each | sFunctions := each class selectors select:[:aSelector | self isFunction:aSelector]. sFunctions addAlhbaseFunctions. sFunctions do:[:sf | each sfvChange:sf]]. sfvChange:function "Primitive. Updates stateFunctions and History" | old Value new Value | newValue:=self perform:function asSymbol. function asSymbol = #fHistory ifTrue: [| new Value]. oldValue := stateFunctions at:function asSymbol if Absent: [nil], (self same:oldValue as:newValue) ifFalse:[self cHistory:function to:newValue. Appendix B. Smalltalk OBIS Prototype Shell 225 stateFunctions at:function asSymbol put:newValue]. | newValue sumValuesOftstate fromObjectsOfKind:k in:objectSet "Answers the sum of values of -.state from objects of kind :k in :objectSet" | sum | sum := 0. (self valuesOf:state fromObjectsOfKind:k in:objectSet) do:[:each | sum := sum + each]. T sum surrogate "Primitive. Answers surrogate" J surrogate surrogateAdd:anObject "Primitive. Add :anObject to composition of current surrogate." self surrogate compositionAdd:anObject surrogate, self surrogate objectsAdd:anObject surrogateRemove:anObject "Primitive. Remove :anObject from composition of current surrogate." self surrogate compositionRemove:anObject surrogate, self surrogate objectsRemove:anObject surrogateSet "Primitive. Assign surrogate to current object and check consistency" |object| (Menu oneOf:#('New Surrogate?' 'Same as Existing Surrogate?') and:#(l 2)) = 1 ifTrue: [ surrogate := Surrogate new:self] ifFalse:[ Appendix B. Smalltalk OBIS Prototype Shell (object := MoMenu selectFrom:SystemObject fComp) isNil ifTrue :[T nil] ifFalse:[surrogate := object surrogate. (object surrogate) objectsAddrself]]. values Of:state fromObjectsOfKind:k in:objectSet "Answers vector of values of -.state from objects of kind :k in -.objectSet" |return| return := OrderedCollection new. (self objectsOfKind:k in:objectSet) do:[:each | return add:(each perform:state asSymbol)]. t return view:anObject as:kind "Answers object of -.kind with same surrogate as -.anObject" set := (self checkSurrogate:anObject) select:[:object | object class = kind], (set size = 0) ifTrue:[T nil], (set size = 1) ifTrue:[f set asArray at:l]. B.2 Windowing and Display Management - OBISForm |set| (OBIS) subclass: #OBISForm graphForm instanceVariableNames: graphRect classVariableNames: poolDictionaries: ActiveList OBISForm class methods OBISForm methods changeList "List all change methods" Appendix B. Smalltalk OBIS Prototype Shell |changeList| changeList := (self class selectors select:[:each | self isChange:each]) asArray. changeList := changeList reject:[:each | (pOrder includes:each)]. | changeList asSortedCollection display:buffer "Primitive. Displays the buffer in Graph Pane" |textForm aStream y| textForm := CharacterScanner new initialize:Display boundingBox font:Font eightLine dest:graphForm. textForm blankRestFrom:0. self changed:#displayGraph:. aStream := ReadStream on:buffer withCrs. y := 0. [aStream atEnd] whileFalse: [ textForm display:aStream nextLine at:0@y. y := y+8]. self changed:#displayGraph:. displayGraph:aRect "Primitive. Sets the display Form" graphRect := aRect. graphForm display At: aRect origin clippingBox:aRect. | graphForm doNothing "Do nothing" T nil doNothingzparm "Answer nil" t nil graphRect "Primitive. Appendix B. Smalltalk OBIS Prototype Shell 228 Answer GraphPane rectangle" | graphRect list M e n u "Primitive. Service Menu" | Menu labels:'ofKind\compOf\partOf\stateValue' withCrs lines:#() selectors:#(mKinds\mComp\mPart\mState). listObjects "Primitive. Answer collection of objects" 1 ActiveList asOrderedCollection collect:[:eachObject | eachObject objectNamej. list Select selection "Primitive. Control window." Scheduler topDispatcher close Window. Scheduler systemDispatcher redraw. (Scheduler dispatchers select:[:each | each pane model isKindOf:OBIS] ) do:[:each | each close Window]. "kill all object panes" Scheduler systemDispatcher redraw. (ActiveList asOrderedCollection at:selection) openOn. Scheduler resume. objectMenu "Primitive. Bring up the Service Menu " ] Menu labels:'States\Changes\Laws\fComp\fAComp\fPartOf\fSurrogates\Scan\A-Comp\Scan\ Part-Of\debug' withCrs lines:#(3 7) selectors:#(sStates\sChanges\sLaws\scanfC\scanfAC\ scanfP\scanSurrogates\mAComp\mPartOf\de open Appendix B. Smalltalk OBIS Prototype Shell 229 | index aDispatcher| "Primitive. Open window" (Scheduler topDispatcher pane model isKindOf:OBIS) and:[ (Scheduler topDispatcher pane model) = SystemObject ifTrue: [Scheduler topDispatcher close Window]], index := (Scheduler dispatchers collect:[:each | each pane model] ) indexOf:self i£Absent:[| self openOn]. aDispatcher := Scheduler dispatchers atdndex. Scheduler remove:aDispatcher; add: aDispatcher. (aDispatcher pane collapsed) ifTrue: [aDispatcher collapse]. aDispatcher openWindow. op en Back "Primitive. Re-open window" (Scheduler topDispatcher pane model) = self ifFalse: [Scheduler topDispatcher close Window. Scheduler systemDispatcher redraw, self open. Scheduler resume]. T nil openOn "Primitive. Create a browser window for ModelObjects" |aTopPane pixelHeight| pixelHeight := ListFont height + 4. aTopPane := TopPane new model: self; label: self objectName; minimumSize: 20 * SysFontWidth @ (10 * SysFontHeight); rightlcons: #( resize collapse); yourself. graphForm := Form width:Display width height:Display height. graphForm white, self fGForm isNil Appendix B. Smalltalk OBIS Prototype Shell ifFalse:[graphForm copy:self fGForm boundingBox from:self fGForm to:0@0 rule:Form over]. aTopPane addSubpane: (GraphPane new model: self; menu: #objectMenu; change:#test:; name: #displayGraph:; framingRatio: (0 @ 0 extent: 1 @ 1)). self fForm isNil ifTrue:[ Scheduler add:(aTopPane dispatcher open)] ifFalse:[Scheduler add:(aTopPane dispatcher openln: ((self fForm at: 1) extent: (self fForm at:2)))]. aTopPane displayWindow. aTopPane dispatcher openWindow. openOnList "Primitive. Create a List window for Objects" |aTopPane| Scheduler topDispatcher close Window. aTopPane := TopPane new model: self; label: 'List Objects'; minimumSize: 20 * SysFontWidth @ (10 * SysFontHeight); rightlcons: #( resize collapse); yourself. aTopPane addSubpane: (ListPane new model: self; menu: #listMenu; name: #listObjects; change: #listSelect:; returnlndex-.true; framingRatio: (0 @ 0 extent: 1 @ 1)). Scheduler add:(aTopPane dispatcher open). Scheduler resume. printObjects:objects Appendix B. Smalltalk OBIS Prototype Shell "Primitive. Return string of object names in •.objects" |collection| collection := OrderedCollection new. objects do:[:each | collection add:each objectName]. t collection s Changes "Primitive. Select a change function" | changes selection| changes := self changeList asArray. changes size < 20 ifTrue:[selection := Menu oneOfxhanges] ifFalse: [selection := Menu oneOfManyxhanges]. selection isNil ifTrue:[| nil]. (self isChange:selection) ifFalse:[Terminal bell. | nil]. (pOrder includes:selection asSymbol) ifTrue:[Terminal bell, f nil]. | self performrselection asSymbol. sLaws "Primitive. Display Law Statement" LogicBrowser new openOn:(Array with: (Smalltalk at:(self class printString,'Laws') asSymbol)) sStates "Primitive. Display State Functions" |states selection textBuffer| states := self stateList as Array. states size < 20 ifTrue:[selection := Menu oneOf:states] ifFalse:[selection := Menu oneOfMany:states]. Appendix B. Smalltalk OBIS Prototype Shell 232 selection isNil ifTrue:[j nil]. (textBuffer:=self perform:selection asSymbol) isNil ifTrue:[| nil]. (textBuffer isMemberOf:String) ifFalse:[textBufFer := textBuffer printString]. SysFont := Font eightLine. Menu oneOf:(self sStatesString:textBuffer). SysFont := Font fourteenLine. self display:textBuffer. sStatesString:aString "Primitive. Answer an array of substrings from the receiver. The receiver is divided into substrings at the occurrences of $ which is converted to space character" | aStream answer index a| answer := OrderedCollection new. aStream := ReadStream on: aString. index := 1. [aStream atEnd] whileFalse: [ (aStream skipTo: $ ) ifTrue: [ answer add: (aString copy From: index to: (aStream position - 1)). index := aStream position+1]]. answer add: (aString copyFrom: index to: (aStream position)), t answer asArray stateList "Primitive. Answer list of state functions" 1 ((self class selectors as Array, ModelObj selectors asArray) select: [:each | self isFunction:each]) asSortedCollection. test:something "Primitive. System testing function" Appendix B. Smalltalk OBIS Prototype Shell 233 CursorManager crossHair change. [Terminal read == (FunctionKeys at:'EndSelectFunction')] whileFalse: []. CursorManager normal change. view:buffer "Primitive. Displays the buffer in Graph Pane" |textForm aStream y| textForm := CharacterScanner new initialize:Display boundingBox font:Font eightLine dest:graphForm. textForm blankRestFrom:0. self changed: #displayGraph:. aStream := ReadStream on:buffer withCrs. y := 0. [aStream atEnd] whileFalse: [ textForm display:aStream nextLine at:0@y. y == y+8]. self changed:#displayGraph:. B.3 User Interface - OBISInterface (OBISForm) subclass: #OBlSInterface instance VariableNames: class VariableNames: poolDictionaries: OBISInterface class methods OBISInterface methods mAComp "Manipulate A-composition of current object" ActiveList := self fAComp. self openOnList mComp "Manipulate composition of current object" Appendix B. Smalltalk OBIS Prototype Shell 234 |newList| newList := OrderedCollection new. ActiveList do: [:object | newList addAlhobject fAComp]. ActiveList := newList asSet. self changed:#listObjects. mKinds "Scope by kinds" |index selection| index := Dictionary new. ActiveList do: [:object | index at:object class symbol put:object class], (selection := Menu oneOfManydndex keys asOrderedCollection) isNil ifTrue:[f nil], selection := index at:selection. ActiveList := ActiveList select:[:object | object isMemberOf:selection]. self changed:#listObjects. mPart "Answer part-of" | newList | newList := OrderedCollection new. (ActiveList size = 0) ifTrue:[ActiveList := SystemObject composition]. ActiveList do: [:object | newList addAll:object fPartOf]. ActiveList := newList asSet. self changed:#listObjects. mPartOf "Manipulate objects part-of current object" ActiveList := self fPartOf. self openOnList mState "Answer state functions" | index states selection value | (ActiveList collect: [:object | object class]) asSet size = 1 ifFalse:[T nil]. Appendix B. Smalltalk OBIS Prototype Shell states := ActiveList asArray first class selectors select:[:each | self isFunction:* (selection := Menu oneOf:states asOrderedCollection) isNil ifTrue:[T nil], value := Prompter prompt:'Value?' default:". ActiveList := ActiveList select:[:object | (object perform:selection) = value], self changed:#listObjects. remove "Removes an object from composition" |selection| selection := MoMenu selectOne:self fComp. (selection isNil or:[selection = self]) ifTrue:[T nil], self surrogateRemove:selection scan:objects "Primitive. Scans objects" |selection| objects size = 0 ifTrue:[T nil], selection := MoMenu selectOne:objects. (selection isNil or:[selection = self]) ifTrue:[| nil], selection open. Scheduler resume. s c a n f A C "Scanner for A-composition of current object" self scan:self fAComp s c a n f C "Scanner for composition of current object" self scan:self fComp s c a n f P Appendix B. Smalltalk OBIS Prototype Shell 236 "Scanner for objects part-of current object" self scan:self fPartOf scanSurrogates "Scanner for surrogates of current object" self scan:(self checkSurrogate:self) validateLaws "Primitive. Validate laws of all related objects" |objects| (SystemObject fComp select:[:each | each respondsTo:#lLaws]) do:[:anObject | (anObject perform: #lLaws) ifFalse:[ Menu message:('Law! ',anObject printString). t false]]. | true B.4 M O C Subsystem - ModelObject (OBISInterface) subclass: #ModelObj instanceVariableNames: class VarlableNames: poolDictionaries: ModelObj class methods new |object| "Create and initialize object." object := super new. object surrogateSet; initialize; clnit. | object ModelObj methods Appendix B. Smalltalk OBIS Prototype Shell addComp:kind "Generic method for adding object of kind to self." |object composition! (Scheduler topDispatcher pane model) = self ifFalse: [self open]. (Menu confirm:'Adding ',kind printString) ifFalse:[T nil]. (Menu oneOf:#('New?' 'Existing?') and:#(l 2)) = 1 ifTrue:[ object := kind new] ifFalse: [ object := MoMenu selectFrom:kind alllnstancesMO]. object isNil ifTrue:[Terminal bell. self openBack. | nil]. (Menu confirm: 'include ',object objectName,'?') = true ifFalse:[object become:String new. Terminal bell. | self openBack]. self surrogateAdd: object. (Scheduler topDispatcher pane model) = self ifFalse:[Scheduler topDispatcher closeWindow. Scheduler systemDispatcher redraw, self open]. | object fAComp "Answers the A-composition of current object" |aKinds a| aKinds := self fKinds. 1 self composition select:[:each | aKinds includes:each class ]. fComp "Answer all objects in composition of current object" f self lattice:(self composition). Appendix B. Smalltalk OBIS Prototype Shell fForm "Answer fForm" f stateFunctions at:#fForm ifAbsent:[j nil]. fGForm "A nswer fGForm " t stateFunctions at:#fGForm ifAbsent:[t nil]. fHistory "Answer fHistory" |string| string := String new. history do:[:aHistory | string := string, (Date fromDays:(aHistory key)//86400) formPrint,' (Time fromSeconds:aHistory key) printString,' ', (aHistory value) printString,']. | string fKinds "Answer the Kinds allowed in the composition of the current object." | stateFunctions at:#fKinds ifAbsent:[| self class]. fLaws "Primitive. System testing" CursorManager execute change, (self respondsTo:#lLaws ) ifTrue: [self lLaws]. CursorManager normal change. T 'Done' fName "Answers name" | stateFunctions at:#fName if Absent: ['object']. Appendix B. Smalltalk OBIS Prototype Shell 239 f P a r t O f "Answers all objects partOf current object" t self partOf:(SystemObject fComp) f S i z e A C o m p "Answers size of A-composition" t self fAComp size f S i z e C o m p "Answers size of composition" t self fComp size Appendix C Order Entry Example - OBIS Implementation C . l Customers (ModelObj) subclass: ^Customer State Function Methods fCredi tLimit "Answer credit limit" t stateFunctions at:#fCreditLimit ifAbsent:[t 0]. fDebt "Answers fDebt defined as law IDebt" | debt | (CustomerLaws new :? lDebt(x,self)) do: [:each | debt := each at:l]. T debt. fName "Answer customer name define as law IName." |result name | (result := CustomerLaws new :? lName(x,self)) notNil ifTrue:[result do:[:each | name := each at:l]. T name] ifFalse:[f stateFunctions at:#fName ifAbsent:[| nil]]. Change Function Methods cCredi tLimit "Change fCreditLimit" |creditLimit| 240 Appendix C. Order Entry Example - OBIS Implementation 241 creditLimit := self fCreditLimit. creditLimit := (Prompter prompt: 'Credit Limit?' default: (creditLimit printPaddedTo:l)) aslnteger. self change:#fCreditLimit toxreditLimit c G F o r m "Change fGForm" self changeVar:#fGForm to:('Customer' magnifyBy:2@6). pOrder add:#cGForm clnit "Initialize new object." self cName; cGForm; cCreditLimit. pOrder add:#clnit. c N a m e "Change the customer name." | name oldName | oldName := self fName. (name := CustomerLaws new :? lName(x,self)) notNil ifTrue:[name do:[:each | name := each at:l]]. name isNil ifTrue:[name := (Prompter prompt: 'Name?' default: oldName)]. self change:#fName to:name. Law Statements l L a w s "Validate all laws" |fDebt| "Validate ICreditLimit - Credit Limit Law " fDebt := self fDebt. fCreditLimit := self fCreditLimit. (CustomerLaws new :? lCreditLimit(fDebt,fCreditLimit)) notNil ifFalse:[| false]. Appendix C. Order Entry Example - OBIS Implementation 242 "Validate IDebt - Debt Law " (CustomerLaws new :? lDebt(fDebt,self)) notNil ifFalse iff false]. "Validate IComp - Composition Law" (CustomerLaws new :? lComp(self)) notNil ifFalse:[| false]. | true (Prolog) subclass: #CustomerLaws "Composition Law - simple object" lComp(aCustomer) :-is(cardinality, aCustomer ctObjectsIn:#composition), eq(cardinality,l). "Debt is <= Credit Limit" lCreditLimit(fDebt, fCreditLimit) :-le(fDebt,fCreditLimit). "Customer debt = sum of order values" lDebt(debt, aCustomer) :-is(orderValues, aCustomer sumValuesOf:#fValue fromObjectsOfKind:Order in:#fPartOf), eq(debt,orderValues). "Check for Person with same Surrogate" lName(name,aCustomer) :-consult(name(x,aCustomer),PersonLaws new), eq(name,x). C .2 Products (ModelObj) subclass: #Product Appendix C. Order Entry Example - OBIS Implementation 243 State Function Methods fValue "Answer value" f stateFunctions at:#fValue ifAbsent:[| 0]. Change Function Methods cGForm "Change fGForm" self changeVar:#fGForm to:('Product' magnifyBy:6@10). pOrder add:#cGForm clnit "Initialize new object." self cName; cGForm; c Value. pOrder add:#clnit. cName "Change name" self changeVar:#fName to:(Prompter prompt:'Product Name?' default:"). cValue "Change value from external source" | oldValue value | oldValue := self fValue. value := (Prompter prompt: 'Value?' default: (oldValue printPaddedTo:l)) aslnteger. self change:#fValue to:value. Law Statements ILaws "Validate laws" Appendix C. Order Entry Example - OBIS Implementation 244 "Order Law: Product can only be partOf one Order" (ProductLaws new :? lPartOf(self)) notNil ifFalse:[T false]. "Composition Law" (ProductLaws new :? lComp(self)) notNil ifFalse:[| false]. | true (Prolog) subclass: #ProductLaws "Composition Law - simple object" lComp(aProduct) :-eq(cardinality,l), is(cardinality, aProduct composition size). "Product can only be part-of one Order" lPartOf(aProduct) :-is(orders, (aProduct objectsOfKind:Order in:#fPartOf)size), le(orders,l). C .3 Orders (ModelObj) subclass: #Order State Function Methods fValue "Answer fValue defined as law IValue" lvalue | (OrderLaws new :? lValue(x,self)) do: [:each | value := each at:l]. | value Change Function Methods cACompCustomer "Add a customer to Order." Appendix C. Order Entry Example - OBIS Implementation self change:#fAComp to:(self addComp:Customer). pOrder add:#cACompCustomer. cACompProduct "Add a product to Order." | continue | continue := true, [continue] whileTrue:[ self change:#fAComp to:(self addComp:Product). continue := Menu confirm:'Add another product?'] clnit "Initialize new object name." self cName; cGForm; cKinds; cACompCustomer; cACompProduct. pOrder add:#clnit. cKinds "Initialize fKinds to Customer, Product" self change:#fKinds to:(Set with:self class with:Customer with:Product). pOrder add:#cKinds cName "Change name from external source" self changeVar:#fName to:(Prompter prompt:'Order No?' default:"). Law Statements lLaws "Validate laws" |fValue| Appendix C. Order Entry Example - OBIS Implementation 246 "Validate IComp - cardinality law" (OrderLaws new :? lComp(self)) notNil ifFalse:[| false]. "Validate IValue - value law" fValue := self fValue. (OrderLaws new :? lValue(fValue,self)) notNil ifFalse:[| false]. | true (Prolog) subclass: #OrderLaws "Cardinality Law - each order has one customer and 0 or more products" lComp(anOrder) :-is(crdCustomer, (anOrder objectsOfKind:Customer in:#fAComp) size), is(crdProduct, (anOrder objectsOfKind:Product in:#fAComp) size), eq(crdCustomer, 1), ge(crdProduct,0). "Order Value Law - Order value = sum of values of products in its composition" 1 Value (order Value, anOrder) :-eq(orderValue,productValues), is(product Values, anOrder sumValuesOf:#fValue fromObjectsOfKind:Product in:#fAComp). C.4 Order Entry System (ModelObj) subclass: #OrderEntry Change Function Methods cACompCustomer "Add a customer to OrderEntry." Appendix C. Order Entry Example - OBIS Implementation 247 t self change :#fAComp to:(self addComp:Customer). cACompOrder "Add a Order to Order Entry." f self change :#fAComp to:(self addComp:Order). cACompProduct "Add a Product to Order Entry." j self change:#fAComp to:(self addComp:Product). cForm "Change the fForm parameters " self change:#fForm to:(OrderedCollection with:0@0 with: Display width * 3//4 @ (Display height * 3//4)). cGForm "Change the cGForm parameters" self changeVar:#fGForm to:('0/E' magnifyBy:6@10). pOrder add:#cGForm clnit "Initialize " self cKinds; cGForm; cForm. pOrder add:#clnit. T nil cKinds "Kinds are Customer, Order, Product" self change:#fKinds to:(Set with:self class with:Customer with:Order Appendix C. Order Entry Example - OBIS Implementation with:Product). Appendix D The IFIP Working Conference Problem This appendix details the OBCM specifications for the IFIP Working Conference problem. Portions of a current implementation of this case study using the prototype OBCM/IS shell is found in Appendix E. D . l IFIP Working Conference Problem The IFIP Working Conference Problem is presented in its entirety below. The problem statement is relatively brief but it has been observed that it supports a wide range of interpretations and perceptions [Essink, 1986; Flint, 1986]. D . l . l Background "An IFIP Working Conference is an international conference intended to bring together experts from all IFIP countries to discuss some technical topic of specific interest to one or more IFIP Working Groups. The usual procedure, and that to be considered for the present purposes, is an invited conference which is not open to everyone. For such conferences it is something of a problem to ensure that members of the involved IFIP Working Group(s) and Technical Committee(s) are invited even if they do not come. Furthermore, it is important to ensure that sufficient people attend the conference so that the financial break-even point is reached without exceeding the maximum dictated by the facilities available. IFIP Policy on Working Conferences suggest the appointment of a Program Commit-tee to deal with the technical contents of the conference and an Organizing Committee to handle financial matters, local arrangement, and invitations and/or publicity. These committees clearly need to work together closely and have a need for common information and to keep their recorded information consistent and up to date. 249 Appendix D. The IFIP Working Conference Problem 250 D.l .2 Information System to be Designed The information system which is to be designed is that necessary to support the activities of both a Programme Committee and an Organising Committee involved in arranging an IFIP Working Conference. The involvement of the two committees is seen as analogous to two organizational entities within a corporate structure using some common information. The following activities of the committee should be supported. Programme Committee 1. Preparing a list to whom the call for papers is to be sent. 2. Registering the letters of intent received in response to the call. 3. Registering the contributed papers on receipt. 4. Distributing the papers among those undertaking the refereeing. 5. Collecting the referees' reports and selecting the papers for inclusion in the pro-gramme. 6. Grouping selected papers into sessions for presentation and selecting chairman for each session. Organizing Committee 1. Preparing a list of people to invite to the conference. 2. Issuing priority invitations to National Representatives, Working Group members and members of associated working groups. 3. Ensuring all authors of each selected paper receive an invitation. 4. Ensuring authors of rejected papers receive an invitation. 5. Avoiding sending duplicate invitations to any individual. 6. Registering acceptance of invitations. 7. Generating final list of attendees. Appendix D. The IFIP Working Conference Problem 251 D . l . 3 Boundaries of System It should be noted that budgeting and financial aspects of the Organizing Committees's work, meeting plans of both committees, hotel accommodation for attendees and the matter of preparing camera ready copy of the proceedings have been omitted from this exercise, although a submission may include some or all of these extra aspects if the authors feel so motivated." D.2 O B C M Interpretation of the IFIP Case The IFIP case study is described as an OBCM model in the following terms. • Things which can be represented in OBCM by simple objects. These are described by the following model objects. PERSON AUTHOR A T T E N D E E R E F E R E E T E X T FACILITY • Things which can be represented as compositions of the simple objects implied above. These can be described by the following models. INVITATIONLETTER INTENTLETTER PAPER REFEREEREPORT. • Further components of the IFIP case viewed as aggregations of objects as described above. A Programme Committee, for example, is an aggregation of persons, invitation and intent letters, papers, referee reports and so forth. A Working Conference Session is organized around a number of selected papers and a facility (or facilities) in which to meet. A Working Conference is a Appendix D. The IFIP Working Conference Problem 252 collection of sessions. The IFIP system itself is an aggregation of all the objects of interest in the system. These components can be described by the models PROGRAMME COMMITTEE ORGANIZING COMMITTEE SESSION WORKING CONFERENCE IFIP. Each of the above models are specified in detail below. D.3 Person The model object PERSON describes all human beings (or individuals) of interest to the IFIP problem. A collection of surrogates Sp is assumed, each of which corresponds to some person of interest. State Functions In addition to the standard state functions common to all OBCM objects1 a useful property is the person's identity. This is represented by the conventional attribute fName : SP -> N 5 , where N 5 is the set of names. Law Statements Objects of type PERSON are simple. The law statement IComp enforces this idea IComp : fComp = self. 1 Recall from Chapter 5: fComp, fAComp, fKinds, fPartOf, fForm and fHistory. Appendix D. The IFIP Working Conference Problem 253 C h a n g e F u n c t i o n s The relevant change functions are as follows. First, to set the value of fForm, cForm : fForm = external source. The person's name is set as cName: fName : external source. The following change function initializes the value of fKinds: cKinds : fKinds := {PERSON}. The compound2 change function clnit initializes new objects as follows: clnit : cForm * cKinds. As expected, clnit can be invoked only once. The partial ordering of these change functions can be depicted as clnit -< (cForm, cName). D.4 A u t h o r An author is an individual who is involved in producing a paper. The model object AUTHOR is a view of persons. That is, the surrogates for AUTHOR is a subset Spa C Sp. State F u n c t i o n s The identity of an author is represented by the state function fName fName : SPa -+ N 5 . 2 Recall from Chapter 5 the notion of composite change. Appendix D. The IFIP Working Conference Problem 254 L a w S ta tements Objects of type AUTHOR are simple. The law statements IComp and IComp enforce this idea IComp : fComp = self. The law of strict generalization is applied to objects of type AUTHOR. That is, authors are special-izations of persons.3 In Chapter 4, this law was given as MsA: qSize[Os9(self)/ ~ P B R S O N ] = 1. In addition, the state function fName must take its value from the PERSON object with which the AUTHOR object shares its surrogate, ie. IName : fName = [0Sg(se\{)/ ~ P E R S O N -fName]. C h a n g e F u n c t i o n s The relevant change functions include cKinds: cKinds : fKinds := {AUTHOR}. Change function clnit is described as4 clnit : cForm * cKinds. Note that since fName depends upon the person sharing the same surrogate as the author, there is no change function to change the author's name. The partial ordering for change functions is clnit -< (cForm). 3This version of the IFIP case ignores situations where authors might be deemed to be corporate or other entities which may not be considered to be human beings. 4Assume cForm defined for all model objects as cForm : fForm = external source. Appendix D. The IFIP Working Conference Problem 255 D.5 Attendee An attendee is an individual who has declared an intent to attend a Working Conference. The model object A T T E N D E E is a view of persons. That is, the surrogates for A T T E N D E E are a subset SPt C SP. State Functions The identity of an attendee is represented by the state function fName fName : SPt -> N 5 . Law Statements Objects of type A T T E N D E E are simple and enforced by IComp : fComp = self. The law of strict generalization is applied to objects of type A T T E N D E E . That is, attendees are specializations of persons, ie. MsA: qSize[0s,(self)/ ~ P ER SON] = 1-This allows the state function fName to take its value from the PERSON object with which the A T T E N D E E object shares its surrogate, ie. IName : fName = 0 5 j (se l f ) / ~ P E R S O N .fName. Change Functions The relevant change functions include cKinds : fKinds := {ATTENDEE}, and clnit : cForm * cKinds. The partial ordering is clnit -< (cForm). Appendix D. The IFIP Working Conference Problem 256 D.6 Referee A referee is an individual who has agreed to referee papers for a Working Conference. The model object R E F E R E E is a view of persons. That is, the surrogates for R E F E R E E are a subset SPr C Sp. State Functions The identity of a referee is represented by the state function fName fName : SPt - » N s . Law Statements R E F E R E E objects are simple: IComp : fComp = self. The law of strict generalization is also applied to objects of type REFEREE. Referees are special-izations of persons, ie.5 llsA : qSize[0 5 3(self)/ ~ P ERSON] = 1-The state function fName must take its value from the PERSON object with which the R E F E R E E object shares its surrogate, ie. IName : fName = Osg(self)/ ~ P ERSON .fName. Change Functions The following change functions are relevant to REFEREE. First, the change function cKinds. cKinds : fKinds := {REFEREE}, 5Again, this ignores the possibility that a referee may not be an individual. Consider, for example, that chess players are no longer necessarily humans. Given the current state of art, these laws above still apply. However, they may change at some future date. In OBCM, law statements can be added or changed at any time (any change, of course, must not violate the current state of the OBIS). Appendix D. The IFIP Working Conference Problem 257 The function clnit initializes new objects of type REFEREE. clnit : cForm * cKinds. Partial ordering is clnit -< (cForm). D.7 Text A text is an organized collection of symbols expressing ideas, suggestions, and other information.6 Assume a collection of surrogates STX each corresponding to some unique text. State Functions The state function fCopy represents the contexts of a text as follows fCopy : STX — 2 T s , where Ts is the set of relevant characters and symbols. Law Statements T E X T objects are simple: IComp : fComp - - self. Change Functions The following change functions are defined for T E X T . First, the function cKinds: cKinds : fKinds := {TEXT}. 6It can be argued that in Bunge's ontology, text is not a substantial thing and cannot be represented by a model thing (see also [Bunge, 1977, pp. 116-117]). This thesis assumes, however, that a text has some physical form which can be described by a model object. Appendix D. The IFIP Working Conference Problem 258 The value of fCopy comes from an external source as follows: cCopy: fCopy := external source. The function clnit is defined as clnit : cForm * cKinds * cCopy. D .8 Facility A facility is some building, place or location at which a conference activity can occur. Assume the set of surrogates Sp, each corresponding to a facility of interest. State Functions The state function fName represents the identify of the facility. fName : SF -* N s . The cost of using the facility can be represented by the state function fCost fCost: SF -> N . Law Statements FACILITY objects are simple: IComp : fComp = self. Change Functions The change function cKinds is defined as cKinds : fKinds := {FACILITY}. The value of fCost is set from an external source cCost: fCost := external source. Appendix D. The IFIP Working Conference Problem 259 The usual clnit is defined as clnit : cForm * cKinds * cCost. D.9 Invitation Letter An invitation letter or call for a paper is a piece of text addressed to some individual inviting that individual to submit a paper on some topic. It is represented by the model object INVITATION. The possible surrogates for INVITATION are denned as Sc = Sp x Sn, that is, an invitation letter is composed of a PERSON object and a T E X T object.7 State Functions An invitation letter has the property of being directed or addressed to some individual. This is repre-sented by the state function fName fName : Sc —• N 5 . Law Statements The cardinality of INVITATION is enforced by the law statement IComp : [qSize(fAComp/ ~PERSON) = 1 & qSize(fAComp/ ~TEXT) = 1]-The value of fName is defined to be the name of the person in the composition of the invitation. This is reflected in the law statement IName : fName = (fAComp/ ~ P E R s o N ) . f N a m e . 7In the interest of simplicity, the possibility of addressing an invitation letter jointly to more than one individual is not considered. Appendix D. The IFIP Working Conference Problem 260 C h a n g e F u n c t i o n s Change functions are required to add P E R S O N and TEXT objects to the composition of an INVITA-TION object. cAdd Person : fAComp := fAComp o p, where p is an object of kind P E R S O N . 8 Similarly, cAddText: fAComp := fAComp o t, where t is an object of kind TEXT. Both the above changes can occur only once.9 The change function cKinds is cKinds : fKinds := {PERSON ,TEXT}. The initialization change function not only sets the values for fForm and fKinds but also adds a person and text to an invitation when it is first created: clnit : cForm * cKinds * cAddPerson * cAddText. This function can be invoked only once. Thus, the partial ordering of change functions can be expressed as clnit •< cForm. D.10 Intent L e t t e r An intent letter is a text from some individual indicating an intent to submit a paper in response to an invitation. It is represented by the model object INTENT whose possible surrogates are defined as Si = Sp x S T X ) 8 Recall from Chapter 5 that the expression f := f o x sets the new value of f to its previous value aggregated with x. 9Assuming that neither the addressee nor the text of an invitation letter should be changed after it is produced. Appendix D. The IFIP Working Conference Problem 261 State Functions The state function fName represents the sender of an intent letter and is defined as fName : Sj -> N s . Law Statements Law statements for INTENT are similar to invitation letters. First, cardinality is enforced10 IComp : [qSize(fAComp/ ~ P E R S O N ) = 1 & qSize(fAComp/ ~ T E X T ) = ! ] • That is, an intent letter is addressed to only one person and has only one text. The value of fName is defined to be the name of the person in the composition of the intent letter. This is the law statement IName : fName = (fAComp/ ~ P E R S O N ) . f N a m e . Change Functions Change functions for INTENT are similar to those for INVITATION. The function cKinds is defined cKinds : fKinds := {PERSON,TEXT}. Functions are needed to add persons and text to intent letters. cAdd Person : fAComp := fAComp o p, where p is an object of kind PERSON. Similarly, cAddText: fAComp := fAComp o t, where i is an object of kind T E X T . The initialization of new INTENT objects is achieved by clnit : cForm * cKinds * cAddAuthor * cAddText. As expected, this function is invoked once only for each intent letter. 1 0Again, assuming the sender of an intent letter is a single individual. Appendix D. The IFIP Working Conference Problem 262 D . l l Paper A paper is a text produced by an author or authors, which has been submitted to the Working Conference in response to a call for paper. It is modelled by PAPER with possible surrogates11 SPp =2 5 p* x STx-That is, for OBCM modelling purposes, a paper is an aggregate of one or more authors and a text. State Functions The state function fName is defined to represent the paper's identity.12 fName : Spp —* N5. Law Statements An important law statement for PAPER is its cardinality law IComp : [qSize(fAComp/ ~ A U T H O R ) > 1 & qSize(fAComp/ ~ T E X T ) = 1-That is, a paper is authored by at least one author and has only one text. Change Functions Change functions for PAPER include adding the author: cAddAuthor : fAComp := fAComp o a, n T h i s is a fairly liberal interpretation. A more restrictive version might assume, for example, that the only papers of interest are those (1) in response to a call (ie. no unsolicited papers are acceptable) and (2) for which an intent to submit was declared (ie. there is an intent letter on file). In this case, the surrogates for PAPER would be modified as Spp = 2 5 p» x Sjx X SC X SI. 1 2 A more elaborate model may include other state variables. For instance, a state function can be defined to map papers to sets of keywords or topic names which can then be matched to an equivalent state variable in REFEREE. In this way, the system can assist in identifying suitable referees for papers. Appendix D. The IFIP Working Conference Problem 263 where a is an object of kind AUTHOR. Inclusion of the paper's text is as follows: cAddText: fAComp := fAComp o t, where t is an object of kind T E X T . Both these change functions are invoked once only.1 3 The value of fName is taken from an external source14 cName: fName := ezternalsource. The change function cKinds is defined as cKinds : fKinds := {AUTHOR,TEXT). The initialization of a paper is defined as clnit : cForm * cKinds * cAddAuthor * cAddText * cName. D.l2 Referee Report A Referee Report is a text written by a referee, commenting upon a paper. It is described by the model REFEREEREPORT. Assuming for simplicity that a paper is assessed by a single referee, the surrogate for a referee report is defined as SRR = SR x Spp x STX-That is, for OBCM modelling purposes, a referee report is an aggregation of a referee, a paper and a text commenting upon the paper. State Functions The following state function maps each report to accept/ reject values. fEval : SRR —» {accept, reject). Another useful state function identifies the referee report as follows fName : SRR -> N 5 . 1 3 The possibility of modifying the text is not considered in this version of the case (although not difficult to add). 1 4 This is the simplest alternative. The name by which a paper is called can be changed in many ways. Appendix D. The IFIP Working Conference Problem 264 Law Statements A cardinality law applies to REFEREEREPORT. IComp : [qSize(fAComp/ ~ R E F E R E E ) = 1 & qSize(fAComp/ ~ P A P E R ) = 1 & qSize(fAComp/ ~ T E X T ) = !•]• Change Functions Change functions for REFEREEREPORT include the addition of the paper: cAddPaper : fAComp := fAComp o p, where p is an object of kind PAPER. This is invoked once only. The following adds the referee: cAdd Referee : fAComp := fAComp o r, where r is an object of kind REFEREE. The comments or text of the report is added by cAddText : fAComp := fAComp o t, where t is an object of kind T E X T . The last two change functions can be invoked more than once (that is, it is possible that a referee may be unable to complete an evaluation and the substitution of a new referee and related comments are possible). This requires the change function cRemoveRef: fAComp := fAComp © r © t, where © indicates that the object r of type R E F E R E E and/or t of type T E X T in A-composition of the referee report are removed. A composite change function cChangeRef is defined as cChangeRef: cRemoveRef * cAdd Referee. Appendix D. The IFIP Working Conference Problem 265 Various techniques can be applied to assign a value for fEval. In this case study, the value is assigned manually from an external source. That is, the external source (eg. a human operator) reviews the referee's comments and decides whether the recommendation is to accept or reject the paper.15 This requires the change function cEval : fEval = external source. The change function cKinds is cKinds : fKinds := {REFEREE, PAPER, TEXT}. The initialization of a new referee report is represented by clnit : cForm * cKinds * cAdd Referee * cAddPaper. The partial ordering is somewhat more complex than usual: clnit -< (cChangeRef) -< cAddText -< cEval. That is, the referee's comments are accepted only after a referee is assigned and the evaluation is made after the referee's comments are received. Note also that the referee can be changed only after he/she is assigned (in clnit). D.13 Programme Committee For OBCM modelling purposes, the Programme Committee is viewed as an aggregation of the invita-tion letters, intent letters, papers, and referee reports which are required to support the activities of the Committee. The Programme Committee is represented by the model object PROGCOM and its surrogate is defined as SPC - 2Sc x 2Sl x 2Sp- x 2 S f i R. Conceptually, in the OBCM/IS model, as invitations are generated, they are added to the Programme Committee. As intent letters and papers are received, they are also added to the Programme Committee. And when a paper is distributed for refereeing, a referee report is generated and added to the Programme Committee. 1 5 A more complex law statement might possibly be formulated which assigns the value resulting from some form of automated content analysis of the referee's comments. Appendix D. The IFIP Working Conference Problem 266 State Functions An important property of the Program Committee is its ability to generate lists of individuals to whom it can issue a call for papers. The state function fCall List maps a Programm Committee to sets of persons as follows: f Call List: SPC - » 2S Another property of interest is its ability to select a set of papers for the conference. The state function fSelected Papers maps a Programme Committee to a set of papers. fSelectedPapers : SPC -» 25p". Law Statements Assuming that the Program Committee will want to issue invitations to the widest range of individuals as possible the law statement ICall List defines the value of fCall List as ICallList: fCallList = IFIP.fComp/ ~ P E R S O N . That is, the list to whom the call for papers is to be sent is the set of all objects of type PERSON in the IFIP system.16 The law statement ISelectPapers is defined as ISelectPapers : fSelected Papers = (fAComp/ ~ ( R E F E R E E R E P O R T & f E v . i = JVcc«pt))-fAComp/ ~ P A P E R • That is, given all the referee reports in the composition of the Programme Committee, the selected papers are the papers in the composition of all referee reports with fEval = accept. Interestingly enough, for the purposes of this case study, the cardinalities of the components of a Programme Committee are not relevant. Therefore, no law statements concerning the composition of Programme Committees are specified. 1 6Recall that the IFIP system is the total aggregation of all objects of interest to the IFIP case study. It is also reasonable to modify this law statement to restrict invitations to some selected group or groups of individuals. In the absence of additional information in the problem description, however, ICallList remains as defined. Appendix D. The IFIP Working Conference Problem 267 Change Functions Change functions for PROGCOM include adding calls for papers (ie. invitations) cAddCall : fAComp := fAComp o c, where c is an object of kind INVITATION. The function cAddlntent allows adding letters of intent as they are received by the committee. cAddlntent : fAComp := fAComp o i, where i is an object of kind INTENT. Similarly, papers are added as they are received. cAddPaper : fAComp := fAComp o p, where p is an object of kind PAPER. The following allows referee reports to be generated and added. cAddRefereeReport : fAComp := fAComp o r, where r is an object of kind REFEREEREPORT. The change cKinds is cKinds : fKinds := {PERSON, INVITATION, INTENT, PAPER, REFEREEREPORT}. Initialization involves clnit : cForm * cKinds. D.14 Organizing Committee For OBCM modelling purposes, the Organizing Committee is viewed as a set of facilities and attendees. Soc = SF x Spt. Conceptually, in the model, as facilities are located, they are added to the composition of the Organizing Committee. Similarly, as individuals confirm their intent to attend, they are added to the Organizing Committee. Appendix D. The IFIP Working Conference Problem 268 Change Functions Change functions for ORGCOM include the addition of facilities: cAdd Facility : fAComp := fAComp o / , where / is an object of kind FACILITY. The addition of attendees is represented by cAddAttendee : fAComp := fAComp o a, where a is an object of kind A T T E N D E E . The change cKinds is defined as cKinds : fKinds :- {FACILITY, ATTENDEE}. Initialization is represented by the change function clnit : cForm * cKinds. D.15 Session A session is viewed as an aggregation of attendees, papers and facilities. That is, attendees meet at one or more facilities to discuss a set of papers. The model for a session is SESSION and its surrogate is Ss = 2Sp' x 2 5 f x 2Sp". State Functions The cost of a session can be represented by the state function fCost fCost : Ss - » N . Law Statements The law statement ICost defines the value of fCost as ICost: fCost = E(fAComp/ ~ F A C I L I T Y .fCost). That is, the cost of a session is equal to the sum of the costs of its facilities. Appendix D. The IFIP Working Conference Problem 269 Change Functions Change functions for SESSION consist of the following. A change to add a facility. cAddFacility: fAComp := fAComp o / , where / is an object of kind FACILITY. A change to add an attendee. cAddAttendee : fAComp := fAComp o a, where a is an object of kind A T T E N D E E . A change to add a paper. cAddPaper: fAComp := fAComp o p, where p is an object of kind PAPER. Other changes include cKinds cKinds : fKinds := {FACILITY, A T T E N D E E , PAPER}. Initialization is defined as clnit : cForm * cKinds. D.16 Working Conference A Working Conference consists of a Programme Committee, an Organizing Committee and a number of sessions. It is described by the model WORKINGCONFERENCE. Its surrogate is Swc = 2 5 s X SpcOM x SOCOM State Functions The state function fCost represents the total cost of a Working Conference: fCost: Swc -> N . A Working Conference can be identified by a name: fName : Swc -* N s . Appendix D. The IFIP Working Conference Problem 270 Law Statements A cardinality law applies to WORKINGCONFERENCE. IComp : [qSize(fAComp/ ~ P R O G C O M ) = 1 & qSize(fAComp/ ~ O R G C O M ) = 1-The law statement I Cost defines the value of f Cost as I Cost: fCost = E[(fAComp/ ~ s E s s i o N ) - f C o s t ) ] . That is, the cost of a Working Conference is equal to the sum of the costs of its sessions. Change Functions The following change functions apply to WORKINGCONFERENCE. A change to add its Program Committee. cAddProgCom : fAComp := fAComp o p, where p is an object of kind PROGCOM. Next, a change to add its Organizing Committee. cAddOrgCom : fAComp := fAComp o o, where o is an object of kind ORGCOM. Both cAddProgCom and cAddOrgCom can only be invoked once. A change cAddSession adds sessions to the Working Conference: cAddSession : fAComp := fAComp o s, where s is an object of kind SESSION. The fKinds of a Working Conference are changed by cKinds : fKinds := {SESSION, PROGCOM, ORGCOM}. A Working Conference is initialized by clnit : cForm * cKinds * cAddProgCom * cAddOrgCom. Appendix D. The IFIP Working Conference Problem 271 D.17 IFIP The IFIP is the collection of all Working Conferences and all individuals of interest to the IFIP system. It is described by the model IFIP which has the surrogates SIFIP = 2 S w c x 2 5 p . Change Functions The following change functions are found in IFIP. New Working Conferences are added by cAddConference : fAComp := fAComp o c, where c is an object of kind WORKINGCONFERENCE. The state variable fKinds is changed by cKinds : fKinds := {WORKINGCONFERENCE, PERSON}. Initialization of the IFIP system itself is achieved by clnit : cForm * cKinds. 1 7 This is an appropriate place to populate with objects of type PERSON since individuals can partic-ipate in several Working Conferences. Appendix E IFIP Working Conference Problem - OBIS Implementation E . l Person (ModelObj) subclass: #Person cForm self change:#fForm to:(OrderedCollection with:100@50 with: Display width * 1//2 @ (Display height * 3//4)). pOrder add:#cForm. cGForm self change Var:#fGForm to:((FreeDrawing pictureDictionary at:'aGraph') offset:0@0). pOrder add:#cGForm clnit "Initialize the new object" self cForm; cGForm; cName. pOrder add:#clnit. cName "Change the Person name." | name | name := (Prompter prompt: 'Name?' default: self fName). self changeVar:#fName to:name. lLaws |compSize| "Composition Law" compSize := self fAComp size. (PersonLaws new :? lComp(self)) notNil 272 Appendix E. IFIP Working Conference Problem - OBIS Implementation ifFalse:[f false]. | true (Prolog) subclass: #PersonLaws "Composition Law - simple object" lComp(aPerson) :-is(cardinality, aPerson fComp size), eq(cardinality,l). "If a Person view exists of :anObject, return its name" lName(name,anObject) :-is(x,anObject view:anObject asrPerson), eq(x,nil),!,fail(). lName(name,anObject) :-is(x,anObject view:anObject as:Person), is(name,x fName). E.2 Author (ModelObj) subclass: #Author cGForm self changeVar:#fGForm to:('Author' magnifyBy:6@10). pOrder add:#cGForm clnit "Initialize the new object" self cGForm; cName. pOrder add:#clnit. cName "Change the author name." |name oldName | oldName := self fName. (name := AuthorLaws new :? lName(x,self)) notNil ifTrue:[name do:[:each | name := each at:l]]. name isNil iflrue:[name := (Prompter prompt: 'Name?' default: oldName)]. self change:#fName to:name. (Prolog) subclass: #AuthorLaws Appendix E. IFIP Working Conference Problem - OBIS Implementation "Composition Law - simple object" lComp(compositionSize) :-eq(compositionSize,l). "Name from Person View if any" lName(name,anAuthor) :-consult (name (x,an Author), PersonLaws ne w), eq(name,x). E.3 Attendee (ModelObj) subclass: ^Attendee cGForm self changeVar:#fGForm to:('Attendee' magnifyBy:6@10). pOrder add:#cGForm clnit "Initialize the new object" self cGForm; cName. pOrder add:#clnit. cName "Change the attendee name." |name oldName| oldName := self fName. (name := AttendeeLaws new :? lName(x,self)) notNil ifTrue:[name do:[:each | name := each at:l]]. name isNil ifTrue:[name := (Prompter prompt: 'Name?' default: oldName)]. self change:#fName to:name. E.4 Referee (ModelObj) subclass: #Referee cGForm self changeVar:#fGForm to:('Referee' magnifyBy:6@10). pOrder add:#cGForm Appendix E. IFIP Working Conference Problem - OBIS Implementation clnit "Initialize the new object" self cGForm; cName. pOrder add:#clnit. cName "Change the Referee name." |name oldName| oldName := self fName. (name := RefereeLaws new :? lName(x,self)) notNil ifTrue:[name do:[:each | name := each at:l]]. name isNil ifTrue:[name := (Prompter prompt: 'Name?' default: oldName)]. self change:#fName tomame. (Prolog) subclass: #RefereeLaws "Composition Law - simple object" lComp(compositionSize) :-eq(compositionSize, 1). "Name from Person View i f any" lName(name,aReferee) :-consult (name (x, aReferee), PersonLaws ne w), eq(name,x). E.5 Text (ModelObj) subclass: #Text cCopy "Change text copy" |text| text := (Prompter prompt: 'Text Copy?' default:"), self change:#fCopy to:text. pOrder add:#cCopy. clnit "Initialize Text object. Set its text. " Appendix E. IFIP Working Conference Problem - OBIS Implementation self cCopy. pOrder add:#clnit. fCopy "Answer Text Copy" t stateFunctions at:#fCopy ifAbsent:[f nil]. E .6 Facility (ModelObj) subclass: #Facility cCost |oldCost cost | oldCost := self fCost. cost := (Prompter prompt: 'Cost?' default: (oldCost printPaddedTo:l)) aslnteger. self change:#fValue to:cost. cGForm self changeVar:#fGForm to:('Facility' magnifyBy:6@10). pOrder add:#cGForm clnit "Initialize new object" self cGForm; cCost. pOrder add:#clnit. cName "Change the Facility name." | name | name := (Prompter prompt: 'Name?' default: self fName). self changeVar:#fName to:name. fCost "Answer the cost of facility" t stateFunctions at:#fCost ifAbsent:[f 0]. (Prolog) subclass: #FacilityLaws "Composition Law - simple object" lComp(compositionSize) :-Appendix E. IFIP Working Conference Problem - OBIS Implementation 277 eq(compositionSize, 1). E.7 Invitation Letter ( M o d e l O b j ) s u b c l a s s : ^Invitation c A C o m p P e r s o n "Add a Person to Invitation." self change:#fAComp to:(self addComp:Person). pOrder add:#cACompPerson. c A C o m p T e x t "Add a text to Invitation." self change:#fAComp to:(self addComp:Text). pOrder add:#cACompText. T self c l n i t "Initialize new object" self cKinds; cACompPerson; cACompText. pOrder add:#clnit. c K i n d s "Kinds are Person, Text" self change:#fKinds to:(Set with:self class with:Person with:Text). pOrder add:#cKinds c N a m e | name | (InvitationLaws new :? lName(x,self)) do: [:each | name := each at:l]. self changeVar:#fName to:name. ( P r o l o g ) s u b c l a s s : #InvitationLaws "Name Law: identify Invitation as name of addressee" lName(name,anInvitation) :-is(name, (anlnvitation objectOfKind:Person in:#fAComp) fName). Appendix E. IFIP Working Conference Problem - OBIS Implementation 278 E.8 Intent Letter (ModelObj) subclass: #Intent cACompPerson "Add a Person to Intent Letter." self change:#fAComp to:(self addComp:Person). pOrder add:#cACompPerson. cACompText "Add a text to Intent Letter." self change:#fAComp to:(self addComp:Text). pOrder add:#cACompText. clnit "Initialize new object " self cKinds; cACompPerson; cACompText; cName. pOrder add:#clnit. cKinds "Kinds are Person, Text" self change:#fKinds to:(Set with:self class withrPerson with:Text). pOrder add:#cKinds cName | name | (IntentLaws new :? lName(x,self)) do: [reach | name := each at:l]. self changeVar:#fName to:name. pOrder add:#cName. (Prolog) subclass: #IntentLaws "Name Law: identify as name of sender" lName(name,anIntent) :-is(name, (anlntent objectOfKind:Person in:#fAComp) fName). Appendix E. IFIP Working Conference Problem - OBIS Implementation E.9 Paper (ModelObj) subclass: #Paper cAComp Author "Add an author." self change:#fAComp to:(self addComp:Author). pOrder add:#cACompAuthor. cACompText "Add Text." self change:#fAComp to:(self addComp:Text). pOrder add:#cACompText. t self clnit "Initialize new object " self cKinds; cACompAuthor; cACompText. pOrder add:#clnit. cKinds "Kinds are Author, Text" self change:#fKinds to:(Set with:self class with:Author with:Text). pOrder add:#cKinds cName "Change the Paper title." | name | name := (Prompter prompt: 'Paper Title?' default: self fName). self changeVar:#fName to:name. E.10 Referee Report (ModelObj) subclass: #RefereeReport cACompPaper "Add a Paper to RefereeReport." Appendix E. IFIP Working Conference Problem - OBIS Implementation 280 self change:#fAComp to:(self addComp:Paper). pOrder add:#cACompPaper cAComp Referee "Add a Referee to RefereeReport." self change:#fAComp to:(self addComp:Referee). pOrder add :#cAComp Referee cACompText "Add a Text to RefereeReport." self change:#fAComp to:(self addComp:Text). pOrder add:#cACompText cChangeRef "Change a Referee" pOrder remove:#cAddReferee. self cRCompReferee; cAComp Referee. cEval self changeVar:#cEval to: (Prompter prompt: 'Evaluation?' default:"). pOrder add:#cChangeRef. clnit "Initialize " self cKinds; cACompPaper; c ACompReferee. pOrder add:#clnit. T nil cKinds "Kinds are Referee, Paper, Text" self change:#fKinds to:(Set with:self class with: Referee with:Text with:Paper). pOrder add:#cKinds cRCompReferee Appendix E. IFIP Working Conference Problem - OBIS Implementation "Remove a Referee from Referee Report." self change :#fAComp to:(self removeComp:Referee). pOrder add:#cACompReferee fEval "Answer Evaluation" t stateFunctions at:#fEval ifAbsent:[| 0]. fName "Report name = title of Paper" |paper| paper := self objectOfKind:Paper in:#fAComp. | paper fName. (Prolog) subclass: #RefereeReportLaws "Cardinality Law - one Referee, one Paper and one Text" lComp(aReport) :-is(referee, (aReport objectsOfKind:Referee in:#fAComp) size), is(paper, (aReport objectsOfKind:Paper in:#fAComp) size), is(text, (aReport objectsOfKind:Text in:#fAComp) size), eq(referee,l), eq(paper,l), eq(text,l). E . l l Programme Committee (ModelObj) subclass: #ProgCom cACompIntent "Add a Letter of Intent." self change:#fAComp to:(self addCompdntent). cACompInvitation "Add an Invitation." self change:#fAComp to:(self addComp:Invitation). Appendix E. IFIP Working Conference Problem - OBIS Implementation 282 cACompPaper "Add a Paper." self change:#fAComp to:(self addComp:Paper). c A C o m p RefereeReport "Add a RefereeReport." self change :#£AComp to:(self addComp:RefereeReport). cGForm self changeVar:#fGForm to:('ProgCom' magnifyBy:6@10). pOrder add:#cGForm clnit "Initialize new object name" self cGForm; cKinds. pOrder add:#clnit. cKinds |kinds| kinds := Set with:self class, kinds add:ProgCom; add:Invitation; add: RefereeReport; add:Paper; add:Intent. self change:#fKinds to:kinds. pOrder add:#cKinds. fCallList "Answers a list to whom the call for papers can be sent. Determined by law ICallList" | list | (ProgComLaws new :? lCallList(x,self)) do: [:each | list := each at:l]. T list fSelectedPapers "Answers a list of Selected Papers" | list | (ProgComLaws new :? lCallList(x,self)) do: [:each | list := each at:l]. Appendix E. IFIP Working Conference Problem - OBIS Implementation 283 T list (Prolog) subclass: #ProgComLaws "Call list is all Persons in the IFIP System" lCallList(callList,aProgCom) :-is(callList, aProgCom objectsOfKind:Person). "Selected papers all have Referee Reports with fEval — 'accept"' lSelect(sPapers,aProgCom) :-is(reports, aProgCom objectsOfKind:RefereeReport with:#fEval equah'accept' in:#fAComp), is(papers, aProgCom objectsOfKind:Paper in:reports). E.12 Organizing Committee (ModelObj) subclass: #OrgCom c A C o m p Attendee "Add an Attendee." self change:#fAComp to:(self addComp:Attendee). cAComp Facility "Add an Facility." self change:#fAComp to:(self addComp:Facility). cGForm self changeVar:#fGForm to:('OrgCom' magnifyBy:6@10). pOrder add:#cGForm clnit "Initialize new object" self cGForm; cKinds. pOrder add:#clnit. cKinds | kinds | kinds := Set with:self class, kinds add:OrgCom; Appendix E. IFIP Working Conference Problem - OBIS Implementation 284 add:Facility; add:Attendee. self change:#fKinds to:kinds. pOrder add:#cKinds. E.13 Session (ModelObj) subclass: #Session cAComp Attendee "Add an Attendee." self change:#fAComp to:(self addComp:Attendee). cACompChai rman "Add a Chairman." self change:#fAComp to:(self addComp:Chairman). pOrder add:#cACompChairman cACompFaci l i ty "Add a Facility." self change:#fAComp to:(self addComp:Facility). cACompPaper "Add a Paper." self change:#fAComp to:(self addComp:Paper). cGForm self changeVar:#fGForm to:('Session' magnifyBy:6@10). pOrder add:#cGForm clnit "Initialize " self cKinds; cGForm. pOrder add:#clnit. T nil cKinds "Kinds are Attendees, Facilities, Papers" self change:#fKinds to:(Set with:self class with:Facility with:Attendee Appendix E. IFIP Working Conference Problem - OBIS Implementation 285 with:Paper). pOrder add:#cKinds cName "Change the Session name." | name | name := (Prompter prompt: 'Session name?' default: self fName). self changeVar:#fName to:name. (Prolog) subclass: #SessionLaws "Session cost = sum of costs of facilities" lCost(cost,aSession) :-is(cost, aSession sumValuesOf:#fCost fromObjectsOfKind:Facility in:#fAComp). E.14 Working Conference (ModelObj) subclass: ^Conference cACompOrgCom "Add a OrgCom to Conference." self change:#fAComp to:(self addComp:OrgCom). pOrder add:#cACompOrgCom cACompProgCom "Add a ProgCom to Conference." self change:#fAComp to:(self addComp:ProgCom). pOrder add:#cACompOrgCom cACompSession "Add a Session to Conference." self change:#fAComp to:(self addComp:Session). cGForm self changeVar:#fGForm to:('Conference' magnifyBy:9@15). pOrder add:#cGForm clnit self cKinds; Appendix E. IFIP Working Conference Problem - OBIS Implementation 286 cGForm; cName; cACompProgCom; cACompOrgCom. pOrder add:#clnit. cKinds |kinds| kinds := Set with:self class with:Session with:ProgCom with:OrgCom. self change :#fKinds to:kinds. pOrder add:#cKinds. cName "Change the Conference name." | name | name := (Prompter prompt: 'Conference Name?' default: self fName). self changeVar:#fName torname. fCost "Answer fCost defined as law ICost" | value | (ConferenceLaws new :? lCost(x,self)) do: [:each | value := each at:l]. t value (Prolog) subclass: #ConferenceLaws "Cardinality Law - one Referee, one Paper and one Text" lComp(aConference) :-is(progCom, (aConference objectsOfKind:ProgCom in:#fAComp) size), is(orgCom, (aConference objectsOfKind:OrgCom in:#fAComp) size), eq(progCom,l), eq(orgCom,l). "Cost is sum of cost of all Sessions" Appendix E. IFIP Working Conference Problem - OBIS Implementation lCost(cost,aConference) :-is(cost, aConference sumValuesOf:#fCost fromObj ectsOfKind: Session in:#fAComp). E.15 IFIP (ModelObj) subclass: #IFIP cACompConference "Add a Conference to IFIP." self change:#fAComp to:(self addComp-.Conference). cACompPerson "Add a Person to IFIP." self change:#fAComp to:(self addComp:Person). cForm "Change the fForm parameters " self changeVar:#fForm to:(OrderedCollection with:0@0 with: Display width * 3//4 @ (Display height * 3//4)). pOrder add:#cForm cGForm self changeVar:#fGForm to:('IFIP' magnifyBy:9@15). pOrder add:#cGForm clnit "Initialize IFIP object" self cForm; cGForm; cKinds. pOrder add:#clnit. cKinds "Kinds" self change:#fKinds to:(Set with: self class with:Conference with:Person). pOrder add:#cKinds. Appendix F Semantic Data Bases F . l Kroenke and Dolan Kroenke k Dolan [1988] describe object orientation as a means of unifying database concepts. They view an object as a "stored data representation" of an entity which is loosely defined as "something a user perceives as an independent unit" in the world of interest. Entities are perceptions and may or may not be physical. More specifically, in their view, an object is "a named collection of properties that sufficiently describes an entity in the user's work environment".1 A property is defined as a characteristic of the corresponding entity which is deemed important to one or more users of the database. The notion of sufficiency emphasizes that not all aspects of an entity need be represented to meet the needs of users. Both entities and objects are viewed as classes or types. Individuals are called entity instances or object instances. F . l . l Object Properties Kroenke k Dolan use object diagrams to visually describe objects (Figure 2.2 adapted from [Kroenke k Dolan, 1988]). An object diagram is drawn as a box within which properties are listed. The name of an object instance is the value of one of the properties of the object. Names need not be unique. Object properties can be single or multi-valued (multi-valued properties are marked MV in the diagram). There are two types of properties, non-object and object properties. Non-object properties have domains such as numbers or strings. The domain of an object property is a set of object instances. Not all the properties of an object instance need be accessible to a user. A particular application may have access to only a subset of the properties of an object instance. The portion of an object accessible to an application is called a view. F . l . 2 Object Categories The specification for a database consists of object definitions, ie. the names and properties of the objects, and domain specifications. Heuristics and rules of thumb are presented for identifying the objects. Kroenke and Dolan distinguish among various categories of objects such as simple, compound, composite, association and aggregation objects. Simple objects contain only single-valued, non-object properties. Composite objects contain one or more non-object multi-valued properties. Compound 1Ie. object appears to be defined as a Cartesian aggregation of properties. 288 Appendix F. Semantic Data Bases 289 objects contain at least one object property. Association objects represent relationships between two (or more) objects. For example, a FLIGHT-SCHEDULE object relates PILOT and AIRPLANE objects. Finally, aggregated objects represent groups of entities. For example, a FACULTY object includes as one of its properties, multi-valued occurrences of T E A C H E R objects. Aggregated objects can be arranged in hierarchies and inheritance can be defined over these hierarchies. F.1.3 Objects and DataBase The notion of object is used to support a user-oriented perspective of databases. Kroenke and Dolan claim that users perceive their environment in terms of entities and associated objects. However, DBMS do not directly support objects. Hence, they provide specific methodologies whereby the different categories of objects are transformed into their equivalent relational database representations. The database design task involves the integration of different user views of some entity into a single object in a process they call object materialization. This object is then transformed into a relational representation using their methodologies. Database languages, menus, forms design software, and display screens are viewed as tools and techniques to aid the materialization process. F.2 A C M / P C M Most semantic data models have focused almost exclusively on the structural aspects of representing information. However, only part of the semantics of an application are described by structural descrip-tions. Although behavioural properties are sometimes implied by structural properties, primitives and procedures outside the data model are usually required to complete the semantics and describe the application completely. Brodie & Ridjanovic [1984] present a data modelling methodology which attempts to integrate both structural and behavioural aspects of conceptually modelling in the database context. They present both a data model (SHM+) and a methodology (ACM/PCM), which draw heavily from concepts in database and programming languages such as data abstraction, abstract data types, procedural abstractions, and specification techniques. As such, their approach has a strong "object-oriented" flavour. F.2.1 Structure Modelling The modelling approach, SHM+, uses one construct, object, and four abstraction mechanisms to struc-turally organize objects: classification, aggregation, generalization, and association. The process of structure modelling at the conceptual level involves identifying all objects and their relationships in an application. Classification is used to achieve the notion of object classes in terms of the properties shared by all object instances in a class. This allows the world to be described in terms of object classes (referred to from this point as simply "objects") rather than in terms of individual object instances. Aggregation is used to describe a relationship between component objects and a higher level aggregate object in a part-of relationship. Generalization relates object classes into hierarchical structures as is-a relationships. Association expresses the relationship between member objects and a higher level set object, ie. a Appendix F. Semantic Data Bases 290 member-of relationship. Brodie [1982] and others have defined .these abstractions in terms of predicate axioms and set-theoretic functions. Repeated application of these abstractions result in aggregation, association and generalization hi-erarchies. Brodie and Ridjanovic see these abstractions as orthogonal, so objects can participate si-multaneously in many hierarchies. Further, to reduce the complexity of monolithic database design, a principle of localization is invoked whereby only one object and those objects immediately related are considered at any one time. A graphical representation called an object scheme is used for describing overall, gross properties of the conceptual model. Object schemes are directed graphs in which nodes are strings denoting objects and edges identify the abstraction mechanisms related objects. Algorithms are available for converting object schemes to traditional database designs (eg. relational). Further, a concept of semantic relativism is developed whereby object properties can be viewed as attributes, entities or relationships, depending upon the needs of the user. A specification language, Beta, is provided for a more detailed description. F.2.2 Behav iour M o d e l l i n g Brodie and Ridjavonic note that most traditional DB models offer only primitive operations and little or no support for higher conceptual levels of modelling dynamics. SHM-f- is a descriptive language which provides for both high-level structure and behavioral modelling. Behavioral modelling involves three concepts at three different levels of conceptualization. First, primitives (INSERT, D E L E T E , UPDATE, FIND, C R E A T E and REQUEST) operate on the database level. Second, two forms of procedural abstractions, transactions and actions, are provided for describing operations on an object level. Finally, control abstractions (sequence, choice and repetition) are provided for the user interface. In SHM+, an action is a behavioural property of an object defined in terms of a primitive operation and an invocation context. The invocation context consists of pre-conditions, postconditions, and exception handling. Actions define completely the behaviour of objects and provide the only means for their alteration. Further, the principle of localization is invoked whereby designers model properties of application object independently then integrate them to complete the design. Transactions fulfill specific user requirements, are composed of actions along with an invocation context, and operate over an arbitrary collection of objects. A graphical representation called behaviour schemes is developed in which nodes are object names and edges are operations. Brodie and Ridjanovic make an analogy between the structure of objects and the control structures of operations upon the objects. Briefly, they relate aggregation, association and generalization to the control abstractions of sequencing, repetition and choice. To explain further, an operation over an aggregate presumably required individual operations over each component object in the aggregate. An operation over a type hierarchy, ie. resulting from generalization, requires choice for each category in the hierarchy. Finally, an operation over an association involves operating over a set of similar objects, ie. iteration. This relationship between structure and behaviour is an analogy only but is claimed to give insight into the relationship between structural and behavioural modelling. The authors claim that since the three forms of control abstraction above can be used to define all computable functions, this suggests the completeness of SHM-(- with respect to database transactions. Appendix F. Semantic Data Bases 291 They further note the intuitive appeal in how the "deep structure" of complex objects described in terms of association, generalization, and aggregation hierarchies is reflected in a "deep structure" of the operations over these objects. F.2.3 Methodology The A C M / P C M methodology is characterized by three principles: (1) abstraction of object structure and behaviour; (2) localization; and (3) refinement. Since both structure and behaviour are integrated, designers can start with either structure or behaviour first. In fact, it should be easy to iterate between the two. Localization helps to control the complexity of design. Several levels are offered, resulting in incremental design and different levels of precision as appropriate. For example, object and behaviour schemes are useful for gross, overall design. Scheme diagrams can be expressed in terms of SHM+, resulting in descriptions which are abstract and should be easy to use since they are expressed in application terms. However, they are not precise. Formal techniques to support analysis and verification are precise but not easy to use. An intermediate specification language is described as a compromise. However, the authors note that where critical operations are concerned, more formal and precise mathematical techniques will be necessary. The point is that A C M / P C M accommodates various levels of analysis, providing for smooth transitions between these levels and thus facilitating incremental design. F.3 Prototype Activity Modelling System Flint [1986] and Flint and Leveson [1985] present a modelling system which integrates both objects and operations in a consistent and homogeneous fashion. They note the large number of modelling constructs and complexity of most semantic data models. Their goal, therefore, is to develop a modelling system with both good representation power and an easy to understand, intuitive interpretation (such as the table abstraction of Codd's original Relational Model). In addition to integrating objects and operations, their Prototype Activity Modelling System (PAMS) attempts to integrate design, specification and implementation into a single modelling system in order to facilitate evolutionary growth of the IS. F.3.1 Containment Flint notes that the concept of object types is found under a variety of different names in all data modelling approaches. Data models, however, differ considerably in how the types of relationships among object types are supported. PAMS offers only one form of data aggregation, the bundle, defined as: ..a homogeneous cover aggregation of Cartesian aggregations of objects. The cover aggregation may be ordered by one or more total ordering functions and may be constrained to any particular number of cardinalities. The objects contained in the Cartesian aggregation may be simple instances of data values or may be other bundles of objects [Flint, 1986, p. 250]. For example, aggregation hierarchies can be developed as Appendix F. Semantic Data Bases 292 US GOVERNMENT {(branch)} BRANCH {(name, department)} DEPARTMENT {(name, agency)} A G E N C Y {(name, division)}, etc. (Upper case denotes bundle names, parentheses surround Cartesian aggregates, braces surround cover aggregations. In the examples above, each bundle is a cover aggregation of a single Cartesian aggrega-tion.) Such nested bundle descriptions constitute the PAMS model. Object hierarchies are open-ended. Hence, the model is dynamic in the sense that one can extend the upper and lower limits of the hierarchy as appropriate to the level of modelling desired. Further, a change can be made to the definition of a bundle by ordinary insertion/deletion/update operations on the contents of a bundle. This, according to Flint, forms the basis for PAMS to serve both as a database description and implementation simulta-neously. Design evolution (by updating bundles) and database manipulation (presumably by updating object instances) are treated homogeneously. F.3.2 Conditional Abstraction In PAMS, the definition or structure of one object may depend on the value of another. This is consistent with its open-ended and dynamic nature. For example, the structure of a seemingly simple object such as TELEPHONE number is a Cartesian aggregate of AREA CODE, EXCHANGE, and NUMBER in the US and Canada. In some other countries, telephone numbers are aggregates of COUNTY CODE, ROUTING CODE, and NUMBER. Still other countries omit ROUTING CODE. Therefore, the structure of TELEPHONE will vary depending upon other objects (eg. COUNTRY) with which TELEPHONE is associated. Flint calls this conditionally defined abstraction. Flint notes that some semantic modelling systems include limited support for conditional abstrac-tion (eg. Codd's R M / T ) . PAMS implements conditional abstraction by augmenting the aggregation (bundling) notation with a specification for operations. Eg. TELEPHONE: SELECT FROM structure bundle VIA country. Flint calls this the principle of non-procedural thunk.2 Pre- and post-conditions can also be implemented as thunks. Flint also considers the possibility of including scripts as an object type in the model. F.3.3 Abstraction Support Aggregation and classification abstraction support is provided as a consequence of the definition of bundles. Generalization is not directly supported. However, Flints suggests that generalization is not necessarily orthogonal to aggregation as is the usual claim. Basically, PAMS sees generalization from the specialization point of view. An entity can be special-ized from a more general counterpart by specifying an operation which results in the specialized object. 2In programming, a thunk is a procedure passed within parameters [Ralston, 1976]. Appendix F. Semantic Data Bases 293 Flint suggests that the usual notion of generalization is overly permissive, since (1) it applies to all instances of the generalized object type and (2) it encourages false generalizations (eg. all birds can fly). By focusing upon specialization as a specific object-operation pair, PAMS supports what Flint calls a pessimistic form of generalization, since no instance of an object can be generalized unless the original object-operation pair is known. A p p e n d i x G Figures 294 NUMBER NAME CAMPUS-ADDKESS^ PHONE CHAIRPERSON TOTAL-STUDENTS COLLEGE PROFESSOR IMV STUDENT 'MV Figure 2.2: Object diagram. 295 0 Figure 3.1: Semilattice generated by < S, o, • , o >. In the diagram, W is o and 0 is Q. F 2 Figure 3.2: Trajectory of a thing undergoing change. 296 REALITY INFORMATION SYSTEM Figure 4.1: Relationships between the Reality being represented and the Information System. Figure 4.2: Different forms of composition. See Section 4.5.3. 297 REALITY INFORMATION SYSTEM JOHN 'JOHN' Surrogate Models CUSTOMER PERSON Objects Figure 4.3: Two views of the (real) thing JOHN. Figure 4.4: A visual notation for objects. The rounded rectangles represent objects, the circles labeled c,- represent change functions, / , represent state functions, and rectangles labeled /,• represent law statements. 298 Figure 4.5: A specific object x0. Note that q2 C x2, qi C x-y, and q2 c x0. Figure 4.6: A simple notation depicting change. 299 lAComp Figure 4.7: The vehicle example in the visual notation of Chapter 4. CUSTOMERS M PRODUCTS Figure 4.8: Typical Entity-Relationship diagram. 300 INVENTORY PAYROLL OBIS Figure 5.1: OBIS as composition of three objects of type I N V E N T O R Y , P A Y R O L L and O R D E R . Object User Technology Figure 5.2: Display of objects via a technology. 301 Figure 5.3: OrderSystem as composition of orders, customers, and products. 302 OrderSystem<an OrderEntry) 1©Q 0/E States Changes Laus FComp FAComp FPartOF FSurrogates Scan A-Comp Scan Part-OF debug A B D SI L i s t Objects 7 b<a Product) bob<a Customer) c<a Product) OrderSgstera<an OrderEntry) john<a Customer) a<a Product) E oFKind compOF partOF stateValue Figure 6.1: A Srnalltalk-based OBIS implementation. Class Hierarchy Browser OBIS OBISForm OBISInterFace ModelObj Logic Brouser Prolog CustomerLaws OrderLaus Product Laus L Figure 6.2: The Smalltalk Prototype Shell. 303 O r d e r S g s t e m < a n O r d e r E n t r g > I OS) C h a n g e s Laws f Cotnp FACottip F P a r t O F F S u r r o g a t e s S c a n A-Comp S c a n P a r t - O F d e b u g FAComp FComp i F F o r m FGForm F H i s t o r g F K i n d s F L a u s FName F P a r t O F FSizeACorop F S i z e C o m p B cACompCustomer c A C o m p O r d e r c A C o m p P r o d u c t c F o r m c K i n d s Figure 6.3: A window onto a Smalltalk implementation of the object OrderSystem. State functions common to all objects (eg. fComp, fPartOf, etc.) are redundantly listed in a separate service menu for user convenience. S t a t e s • C h a n g e s Laws FComp FAComp F P a r t O F a F S u r r o g a t e s y S c a n A - C o m p -S c a n P a r t - O F d e b u g \ SI L i s t O b j e c t s j o h n < a C u s t o m e r > H o . K a n O r d e r > a<a P r o d u c t > s O r d e r S g s t e m < a n O r d e r E n t r g > No. K a n O r d e r > System<a System> Figure 6.4: Scanning fAComp and fPartOf. 304 L i s t Objects b<a Product) bob<a Customer) c<a Product) jo)ln<a Customer) OrderSystem<an OrderEntry) Mo. K a n Order) a<a Product) oFKind compOf partOf stateValue B OrderEntry Customer Product — . Order [SS] L i s t Objects [QISJ] b<a Product) c<a Product) a<a Product) Figure 6.5: Scanning all objects of kind P R O D U C T in the composition of OrderEntry. Figure 6.6: Adding customer and product to an order. 305 SI No. K a n Or der > . i is) a 02All^ 9B 02 as 41 <rNane ' No . 1' > B2/\ll/'98 Q2 06 15 (FKinds Set(Ord«p C u s t o M P Pro<iuot >J -02 07 14 CfAConp a C u s t o H e P ) 02 07 47 <fACOHP a Pro duo t> B2/M1/-90 02 08 25 (fSUcdConp 3) B2 ea 25 <fUaluo 50> QZ/1XS9B 2 08 25 ( r u » s * Done' > aasxxs9B B2 08 25 < f f l C O N P SetCa Custonep an Order- a Fpodi B2/XXS9B 03 B8 26 (fPartOI SetCan OrdepEntpy an Order a $ B2S11./9B 02 B8 26 (fCOMV S stCan Order* a CustoMsv a Ppoduc BZSXXS9B 2 B8 26 (rsizoCo MP 3) Figure 6.7: History of an object. 306 Figure 7.2: Visual notation of P R O G R A M C O M M I T T E E . 307 SI objecKan IFIP> l@El cACom'pConF erence cACompPerson f -, UCttKa Conference) . MB SI L i s t Objects UCttKa Conference) object<an OrgCom) Object I SIX a Session) object<a ProgCom) n> ^ — S c a n A-Comp I b Scan P a r t - O f l 4^ ' I Figure 7.3: Smalltalk implementation of IFIP. imp I - O f I L i s t Objects l@£Q Ken<an Invitation) Marg<an Invitation) John<an Invitation) Mary<an Intent) John<an Intent) 0bjects<a Paper) Bunge<a Paper) 0bjects<a RefereeReport) Scan A-Comp |- c \ Scan Pari — - = ^ IfS) P l i object<a Text) — JoJln<an Author) SI object<a Text) II In t h i s paperj ue discuss applications of Bunge's [1 system of Ontology to Info t i o n s Systems. Figure 7.4: Accessing a paper and its text submitted to the Program Committee. 308 Figure 7.5: Two views of the real world thing JOHN, as A U T H O R and as P E R S O N . 309 

Cite

Citation Scheme:

        

Citations by CSL (citeproc-js)

Usage Statistics

Share

Embed

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

Comment

Related Items