This content was uploaded by our users and we assume good faith they have the permission to share this book. If you own the copyright to this book and it is wrongfully on our website, we offer a simple DMCA procedure to remove your content from our site. Start by pressing the button below!
Business Systems Analysis with Ontologies Peter Green University of Queensland, Australia Michael Rosemann Queensland University of Technology, Australia
IDEA GROUP PUBLISHING Hershey • London • Melbourne • Singapore
Business Systems Analysis with Ontologies Table of Contents Preface ............................................................................................................. vi Peter Green, University of Queensland, Australia Michael Rosemann, Queensland University of Technology, Australia Introduction: Setting the Scene ................................................................. xii Yair Wand, The University of British Columbia, Canada Ron Weber, Monash University, Australia Chapter I Ontological Analysis of Business Systems Analysis Techniques: Experiences and Proposals for an Enhanced Methodology .................... 1 Peter Green, University of Queensland, Australia Michael Rosemann, Queensland University of Technology, Australia Chapter II Evaluating Conceptual Modelling Practices: Composites, Things, Properties ...................................................................................................... 28 Graeme Shanks, Monash University, Australia Jasmina Nuredini, Monash University, Australia Ron Weber, Monash University, Australia Chapter III Ontological Analysis of Reference Models .............................................. 56 Peter Fettke, Johannes Gutenberg University Mainz, Germany Peter Loos, Johannes Gutenberg University Mainz, Germany
Chapter IV Thinking Ontologically: Conceptual vs. Design Models in UML ........ 82 Jörg Evermann, Victoria University of Wellington, New Zealand Chapter V Template-Based Definition of Information Systems and Enterprise Modelling Constructs ............................................................................... 105 Andreas Opdahl, University of Bergen, Norway Brian Henderson-Sellers, University of Technology, Sydney, Australia Chapter VI A Reflective Meta-Model of Object-Process Methodology: The System Modeling Building Blocks ................................................. 130 Iris Reinhartz-Berger, University of Haifa, Israel Dov Dori, Technion, Israel Institute of Technology, Israel Chapter VII Ontology-Driven Method Engineering for Information Systems Development .............................................................................................. 174 Roland Holten, University of Frankfurt, Germany Alexander Dreiling, Queensland University of Technology, Australia Jörg Becker, European Research Center for Information Systems, Germany Chapter VIII Using a Common-Sense Realistic Ontology: Making Data Models Better Map the World .............................................................................. 218 Ed Kazmierczak, The University of Melbourne, Australia Simon Milton, The University of Melbourne, Australia Chapter IX Applying the ONTOMETRIC Method to Measure the Suitability of Ontologies .............................................................................................. 249 Asunción Gómez-Pérez, Politécnica University of Madrid, Spain Adolfo Lozano-Tello, Extremadura University, Spain
Chapter X A Twofold Approach for Evaluating Inter-Organizational Workflow Modeling Formalisms ............................................................................... 270 Benoit A. Aubert, HEC Montreal and CIRANO, Canada Aymeric Dussart, Robichaud Conseil and CIRANO, Canada Michel Patry, HEC Montreal and CIRANO, Canada Chapter XI Methodological Issues in the Evaluation of System Analysis and Design Techniques .................................................................................... 305 Andrew Gemino, Simon Fraser University, Canada Chapter XII Ontological Foundations of Information Systems Analysis and Design: Extending the Scope of the Discussion ................................... 322 Boris Wyssusek, Queensland University of Technology, Australia Helmut Klaus, Queensland University of Technology, Australia Chapter XIII Some Applications of a Unified Foundational Ontology in Business Modeling ..................................................................................................... 345 Giancarlo Guizzardi, University of Twente, The Netherlands Gerd Wagner, Brandenburg University of Technology, Cottbus, Germany About the Authors ..................................................................................... 368 Index ............................................................................................................ 377
vi
Preface
Ontologies are not a philosophical topic only anymore. For more than 10 years now, researchers in different streams related to information technology have been interested in applying sound ontological foundations to their work. An increasing number of special issues of journals, conference sessions and workshops have been dedicated to the application of ontologies in information systems (IS) and computer science. The best paper at the International Conference of Information Systems (ICIS) 2002 applied an ontology to UML and established academic events such as CAiSE and the ER-Conference include a significant number of papers related to ontologies now. This immense popularity of ontologies hopefully will further contribute to the theoretical foundations of the disciplines of information systems and computer science. However, the popularity also means that we have to be even more careful with our references to ontologies. Already, the type of research work that is conducted under the umbrella term “ontologies” varies significantly. Academics working on the semantic Web, knowledge management, E-business or natural language processing develop, compare, and apply ontologies. However, the understanding of the characteristics of ontology in terms of its scope, details or purpose varies significantly. In 2004, we guest-edited a special issue of the Journal of Database Management titled, Ontological Analysis, Evaluation and Engineering of Business Systems Analysis Methods. It covered the applications of ontologies in the context of methods, techniques and grammars for the purposes of business and systems engineering. Business systems analysis (BSA) grammars were deemed to include data modelling, process modelling and object-oriented modelling techniques. Ontologies are seen as a promising theoretical platform that might be able to provide a valuable reference for the evaluation of the tremendous number of grammars that have been already developed. In that special issue, we were very interested in new results of ontological analyses of different BSA
vii
grammars. Other areas of interest were further theoretical guidance for the process of ontological evaluations of BSA grammars, documentation of ontologies with relevance to the BSA community, or the selection of appropriate ontologies in the first place. Our call for chapters for that special issue received in excess of 15 full chapters from authors in nine different countries. Because of the obvious interest and sound, diverse work in the area, we decided to extend the concept of the special issue and approach Idea Group Publishing about producing an edited research book pulling together more fully the excellent work that is being done by colleagues worldwide in the areas of ontological comparison, evaluation and analysis. We have titled this book Business Systems Analysis With Ontologies. This title reflects the profound influence that the science of ontological analysis and evaluation is having on the development of the grammars, techniques and tools being used by academics and practitioners alike in business systems analysis. We are excited that two of the thought leaders in the development and application of an IS-related ontology provided insights into their current perspective on this topic in the introduction of the book. Yair Wand and Ron Weber outline in Setting the Scene how and why they see theories of ontology being important to the information systems field generally, and particularly, to the area of modelling. Moreover, Wand and Weber are enthused by the work in the area when they maintain, in the introduction of this book, “Conceptual modelling is not a defunct, arcane activity. Rather, in our view it remains a vibrant, central element of information systems development and implementation work.” In Chapter 1, Green and Rosemann reflect on their experiences with the application of the BWW models. Their chapter discusses typical problems in the use of any ontology in the context of business systems analysis. Furthermore, it expands particularly on the problems involved in the process of ontological analysis. The authors propose an enhanced procedural model for the ontological analysis based on the use of meta-models, the involvement of more than one coder and metrics. An overview about previous ontological evaluations of BSA grammars also demonstrates the scope of the related research. Chapter 2 by Shanks, Nuredini, and Weber provides an excellent summary of three years worth of experimental work into how alternative conceptual modelling representations affect end-user understanding of these representations. The researchers find evidence to support better end-user understanding when part-whole relations, things, and properties of things are represented in an ontologically-sound manner. Furthermore, they use a process-tracing technique to explain why the ontologically-sound representation of things and properties is more easily understood. Fettke and Loos, in Chapter 3, begin demonstrating how widely ontological analysis can be applied in the general area of business systems analysis. These authors turn their minds to the analysis of reference models. Reference models
viii
are commonly provided, for example, in enterprise resource package software to provide a starting point by which businesses can understand the business processes that are presumed in the software. Accordingly, their chapter focuses on evaluation of reference models based on a sound theory, namely the ontology proposed by the BWW model. They apply their approach to some parts of Scheer’s reference model for production planning and control. The results demonstrate that the modelling grammar used to represent the reference models has ontological deficiencies. These deficiencies lead to several problems in the reference model, for example the meaning of some modelling constructs is vague and some aspects of a reference model are redundant. In Chapter 4, Evermann explores the idea that languages such as UML currently used for conceptual modelling possess no real-world business or organizational meaning. His chapter discusses how such meaning can be assigned to languages like UML. It provides an example that demonstrates the differences between a software design model and a conceptual model in UML. He demonstrates how ontology can assist the modeller to not confuse software aspects with aspects of the real world being modelled. Opdahl and Henderson-Sellers have used an ontology, the BWW representational model, as a basis for developing a template for defining enterprise and IS modelling constructs in a way that facilitates language integration. In their Chapter 5, they have clarified the template further by formalising the meta-model through semi-formal constraints expressed in the object constraint language (OCL) and by populating the meta-model with definitions of example constructs from the UML version 1.4. The purpose was to make the template easier to understand, to validate the template, to pave the way for stronger tool support for the template, and to further our work on providing a complete, template-based definition of the UML. The authors of Chapter 6 focus on the ontologically complete object process model (OPM) for conceptual modelling. A comprehensive reflective meta-model of OPM is presented, using a bimodal representation of object-process diagrams and object-process language paragraphs. The meta-model of the UML industry standard depicts only the language part, leaving the (software or any other) system development processes informally defined as a “unified process”. In sharp contrast to this, OPM, being an object-process approach, enables reflective meta-modelling of the complete methodology, including its language (with both its conceptual-semantic and notational-syntactic aspects) and the OPM-based system development process. This ability to create a reflective meta-model of OPM is indicative of OPM’s expressive power, which goes hand in hand with OPM’s ontological completeness according to the Bunge-WandWeber (BWW) evaluation framework. Holton, Dreiling, and Becker, in Chapter 7, have used several philosophical and linguistic foundations, such as Kamlah and Lorenzen’s language critique approach, Morris’ findings on semiotics, de Saussure’s findings on signs, and
ix
Bunge’s research in ontology to produce an ontology-driven method for information system development. The authors show that ontologies are created and maintained by language communities using linguistic actions and how new concepts can be created to handle new situations. Furthermore, they demonstrate their ontology-driven method to information systems development by introducing an ontology for the domain of management information systems. Chapter 8 begins work on the vexed question of which ontology to use as a basis for the analytical and evaluative work on business systems analysis grammars. Only a few ontologies that tend to be more general in nature are popular in the analysis of business systems analysis grammars. One of these ontologies comes originally from the work by Chisholm and it forms the reference for the study by Kazmierczak and Milton. Their chapter and the work reported in it are driven by an interest in the fundamental nature of data modelling languages. In this research, the ontology helps us to understand, compare, evaluate, and strengthen data modelling languages. This work on which ontology to use is continued in Chapter 9 by Gómez-Pérez and Lozano-Tello. Many researchers tend to select a familiar ontology rather than carefully evaluating different ontologies. ONTOMETRIC is an adaptation of the AHP method to help knowledge engineers to choose the appropriate ontology for a new project; in order to do this, the engineer must compare the importance of the objectives, and study carefully the characteristics of ontologies. The framework provides a useful schema to carry out complex multicriteria decision-making. However, the evaluators need to specify in detail the aims of their analysis. Aubert, Dussart, and Paltry, in Chapter 10, demonstrate another area of application of ontology within business systems analysis: the semantic specification of inter-organizational workflow. Moreover, their chapter aims at determining if the ontological validity of available formalisms is sufficient to represent workflows crossing organizational boundaries. A review of several formalisms reveals that the UML fulfils essential representation criteria related to B2B workflows. Moreover, it possesses several extension possibilities that make it a powerful — and popular — language for business modelling. Andrew Gemino, in Chapter 11, provides a refreshing and contrasting point-ofview on the question of the effectiveness of the ontology selected and used as the analytical basis. He reverts to tried and tested economic theory espoused by Friedman to advocate that the first test of any ontology or meta-model is logical completeness and consistency. This should be a relatively objective exercise. Once an ontology or meta-model has passed this logical test, it can then be used to identify differences among modelling techniques. The impact that these differences have on participants can then be hypothesized using cognitive theory and eventually tested empirically. The ontology (meta-model) that is “better” is the ontology that provides us with differences that lead to “useful” empirical results.
x
The researchers in Chapter 12, Wyssusek and Klaus, take a very philosophical reflection on the process of using an ontology as a basis for analysis, evaluation and development of information systems. The authors try to establish that when dealing with fundamental issues of theory and practice it is advisable to create an awareness of the potential and limitations of our knowing and doing. This entails considering marginalised positions in a critical discussion of approaches toward information systems analysis and design. Finally, in Chapter 13, Guizzardi and Wagner attempt to draw on all the previous research in the area of ontological foundations to produce a unified foundational ontology UFO 0.2. They have stratified UFO into three ontological layers in order to distinguish its core, UFO-A, from the perdurant extension layer UFO-B and from the agent extension layer UFO-C. The researchers claim that, although there is not much consensus yet in the literature regarding the ontology of agents, such an ontology is needed for building the foundation of conceptual business process modelling. We hope that you will enjoy this research book as much as we have enjoyed the work involved in preparing it. May this book and the work reported in it be of guidance and stimulation for your own research.
Peter Green UQ Business School, University of Queensland, Australia Michael Rosemann Queensland University of Technology, Australia
xi
Acknowledgments
The fact that this book is able to provide a comprehensive, detailed, and current overview about the utilization of ontologies in the context of Business Systems Analysis is due to the excellent contributions we received by academics who are globally perceived as the thought-leaders in this area. We are very grateful to those authors who were willing to revise, update, and extend their papers as they were published originally in our Special Issue (Vol. 15, Nr. 2, 2004) for the Journal of Database Management. Moreover, we are thankful to those authors who followed our invitation and submitted a book chapter. Each chapter in this book has been evaluated by at least two experienced reviewers and carefully revised based on these comments. We are indebted to our international and national colleagues who selflessly provided comprehensive and insightful reviews through which the contributing authors could improve their chapters. We acknowledge the related workloads of all concerned and we believe that this rigorous process contributed significantly to the overall quality of this publication. A particular note of thanks must go to Ron Weber and Yair Wand. Without their original ideas, unflagging support, and exemplary academic professionalism, we would not have been inspired to start and complete this project. Furthermore, we like to express our appreciation for the excellent support we received from IDEA Publishers. It has been a well-managed process that kept the entire endeavor on track at all times. Finally, we like to take the opportunity to dedicate this book to our families, to Barbara, Brendan and Daniel, to Louise, Noah and Sophie, who carry too often the burden of two easily over-committed academics. Peter Green & Michael Rosemann
xii
Introduction:
Setting the Scene
Ontology is the branch of philosophy that deals with theories about the structure and behaviour of the worlds that humans perceive. Ontologists seek to articulate the fundamental types of phenomena that exist in the world and the relationships that can arise among these different types of phenomena. Ontologies can be proposed at various levels of abstraction. At the most-general level, an ontology articulates the fundamental constructs we need to be able to describe any phenomenon in the world. At any intermediate level, an ontology articulates the constructs needed to describe particular types of phenomena that occur in some domain — for example, architecture, law, nursing, and carpentry. At lower levels, ontologies articulate the constructs needed to describe specific worlds — for example, the world faced by a particular business as it attempts to survive in a particular context. Why are theories of ontology relevant to the information systems field? The answer is that the essence of an information system is that it is intended to be a faithful representation of a world that a human or group of humans perceives. Theories of ontology provide us with an artifice for describing a perceived world. Our descriptions will only be as good as our ontologies. Accordingly, our information systems will only be as good as our ontologies. In the mid-1980s, we happened on the field of ontology by chance. We were seeking to identify the core — the essence — of an information system and to determine whether we had any theories of this core (whatever the core might be). After substantial discernment, we had concluded the core pertained to “representation” of some world. Thus, we began to seek theories that would account for the nature of good and poor representations. In part, work that had been done by semantic modelling researchers seemed relevant. We found this work inherently unsatisfying, however, because it was not grounded in rigorous theory, nor did it seem complete. One of us (Weber) was visiting the University of British Columbia on sabbatical leave at the time. I (Weber) had been allocated an office next to professor Richard Mattesich, who is both an eminent
xiii
accounting researcher and philosopher of science. During a conversation with Mattesich where I explained the fundamental problem that Wand and I were addressing, he simply went to his bookshelf, selected the two volumes of Mario Bunge’s Treatise on Basic Philosophy that deal with ontology, handed them to me, and suggested I read them. A new world began to unfold for us. We first tried to apply Bunge’s ontological model to the formal analysis of control and audit procedures in information systems. As our work progressed, we realised ontological theories could be used in several ways. First, ontology provides a set of “benchmark” concepts to evaluate models used in systems development — notably, conceptual models of some application domain. Second, ontology provides a set of concepts to model systems and reason about their characteristics (this was our first use of Bunge’s ontology). Third, a specialised ontology can be used to define the meaning of information that will be available in an information system. In this latter role, ontologies often have been used in the artificial intelligence and (recently) semantic Web contexts. Since the early 1990s, we are delighted to see that a growing number of researchers have started to use ontological theories as a basis for their work on conceptual modelling. Much has been done. In our view, however, much still remains to be done. For instance, witness the problems currently being faced by researchers who are trying to find ways to model the world that will allow information systems interoperability to be achieved. Indeed, we are convinced that we have only commenced to scrape the surface of an immense, difficult research area. In terms of theory, for example, it is clear that even well-developed ontologies like Bunge’s need considerable extension and refinement to address the needs of information systems scholars and practitioners. For instance, Bunge’s ontology provides only a small number of constructs to describe processes — albeit fundamental constructs. In contrast, information systems scholars have devised much more-extensive ontologies to describe process phenomena. Unfortunately, these latter ontologies are not always rooted in a sound foundation of more fundamental constructs like things and properties. In short, we see substantial opportunities for philosophers interested in ontology and information systems scholars to work together to develop high-quality, comprehensive ontological theories. In this regard, information technology and its applications have taken the development of ontological theories from an abstruse, esoteric pursuit to an activity with important, high-value practical applications. Theories of ontology also have a curious status. Conventionally, theories provide a means to explain or predict some phenomena. For the most part, however, theories of ontology provide a means of describing rather than explaining or predicting some phenomena. In this light, they function more like a taxonomy than a conventional theory because they provide a set of constructs for classifying and relating phenomena in the world rather than predicting or explaining them. Nonetheless, they still have predictive and explanatory overtones. They
xiv
imply that describing phenomena in the world via the constructs they provide somehow has value. Presumably, if phenomena are classified correctly according to the theory, humans will be better able to understand and predict the phenomena and thus work more effectively and efficiently with the phenomena. This assumption underlies the work we have undertaken to map between ontological constructs and the constructs provided in different conceptual modelling grammars. Our motivation was the recognition that most modelling methods have emerged (and continue to emerge!) without much theoretical grounding. We believe this situation has been a major reason for the proliferation of modelling methods (a phenomenon given the pejorative nickname YAMA — yet another modelling method). To the extent a one/one mapping exists between ontological constructs and grammatical constructs, the implication is that conceptual models will somehow be better. For instance, users of conceptual models will be better able to understand them and work more effectively and efficiently with them. In the interests of parsimony, for the most part we have eschewed employing sophisticated psychological and social theories to provide an account of why a one/one mapping between ontological constructs and grammatical constructs is desirable. Like many economic theories, we simply employ broad assumptions about human behaviour in the hope that detailed, complex accounts of why ontological theories are useful can be avoided. Thus, it is an empirical question whether the explanations and predictions we make based on the (usually implicit) assumption that a given ontology reflects the way humans perceive reality are valid. In terms of practice, we have barely begun to explore the implications of ontological theories for how we undertake conceptual modelling work. In this regard, the chapters of this research book provide excellent examples of the sorts of work that might be done. Ultimately, our concern is to build better conceptual models and devise better tools to assist our conceptual modelling work. In our view, to date ontological theories have shown the most potential for informing practice and the design of conceptual modelling tools. For too long, we have proceeded without the benefit of theory. We have designed and built conceptual modelling tools and undertaken conceptual modelling work using too much of a “pure” engineering strategy — construct the artifact and, if we have time, test the artifact. In the absence of good theory, however, we have been unable to predict the likely strengths and weaknesses of our conceptual modelling tools and practices. As a result, we have a mishmash of views of what constitutes good conceptual modelling tools and practice. We also have a large number of different conceptual modelling grammars that have been devised, and the relationships among these grammars are unclear. For instance, if UML is a comprehensive modelling grammar, why is the W3C® developing the Web ontology language called OWL? Is UML deficient in some way? If so, how is it deficient? Long ago, many scholars in the conceptual modelling area deplored this
xv
state of affairs and underscored the need for good theory to inform our work. We believe that finally we are starting to see theory-driven conceptual modelling work, primarily via the articulation of ontological theories. Recently, we have encountered colleagues who argue that work on conceptual modelling (and thus ontologies) is no longer important. With the development of and widespread deployment of enterprise systems and their embedded “bestpractice” business models, why, they ask, would we bother to build conceptual models of some domain? These arguments are reminiscent of those made about the principles of good programming when fourth-generation languages first appeared. Structured programming precepts, for instance, allegedly were no longer important when fourth-generation languages were used to develop programs. Of course, the disasters that ensued with fourth-generation languages when good programming principles were ignored were an acid reminder that good theory transcends technologies. So it is, we believe, with good conceptual modelling principles, especially in the complex environments of enterprise systems. In such environments, conceptual models enable us to represent both the business and the software in a common way and to compare them. The extent to which misfits arise between the business models employed by an organization and the business models engaged within an enterprise system seems to be a good predictor of the likely success that an organization will enjoy when it implements an enterprise system. Conceptual modelling is not a defunct, arcane activity. Rather, in our view it remains a vibrant, central element of information systems development and implementation work.
Yair Wand The University of British Columbia, Canada Ron Weber Monash University, Australia
Ontological Analysis of Business Systems Analysis Techniques
1
Chapter I
Ontological Analysis of Business Systems Analysis Techniques: Experiences and Proposals for an Enhanced Methodology Peter Green, University of Queensland, Australia Michael Rosemann, Queensland University of Technology, Australia
are reasonably mature, it is the actual process of an ontological analysis that still lacks rigour. The current procedure leaves room for individual interpretations and is one reason for criticism of the entire ontological analysis. This chapter proposes an enhanced procedural model for the ontological analysis based on the use of meta-models, the involvement of more than one coder and metrics. This model is explained with examples from various ontological analyses.
Ontological Analysis of Business Systems Analysis Techniques
3
Accordingly, this chapter has two main objectives (Rosemann, Green, & Indulska, 2004). First, we aim to identify comprehensively the shortcomings in the current practice of ontological analysis. The identification of such shortcomings will provide a basis upon which the practice of ontological analysis can be improved. Second, we want to develop several propositions and methodology extensions that enhance the ontological analysis process by making it more objective and structured. There are several contributions that this chapter aims to make. They are based on previous experiences with ontological analyses as well as observations derived from published analyses. First, the work presents a detailed analysis of the actual process of performing an ontological evaluation. The presented work identifies eight shortcomings of the current ontological analysis process — that is, lack of understandability, lack of comparability, lack of completeness, lack of guidance, lack of objectivity, lack of adequate result representation, lack of result classification and lack of relevance. Each of the identified shortcomings is classified then as belonging to one of three phases of analysis — that is, input, process and output. Second, the chapter presents recommendations on how each of the shortcomings in the three phases can be overcome. The recommendations, among other things, include an extended methodology for the improvement of the objectivity of the analysis, as well as a weighting model that aims to improve the classification of the results of any ontological analysis. This chapter unfolds in the following manner. The next section provides an overview about the basic concepts of applying ontologies for the purposes of evaluating modelling techniques and the related work. The third section identifies eight current shortcomings of ontological analyses of modelling techniques that are classified with respect to the three phases of analysis — that is, input, process and output. The fourth section provides recommendations concerning how to overcome the identified shortcomings in each of the three phases. The final section provides a brief summary of this work and outlines future research in this area.
Weber (1997) distinguishes the following two major situations that may occur when a modelling technique is analysed in such a way. After a particular modelling technique has been analysed, predictions on the modelling strengths and weaknesses of the technique can be made according to whether some or any of these situations arise out of the analysis. 1.
Ontological completeness exists if there is at least one modelling grammatical construct for each ontological construct.
2.
Ontological clarity is determined by the extent to which the modelling technique does not exhibit one or more of the following deficiencies:
•
Construct overload exists in a modelling technique if one grammatical construct represents more than one ontological construct.
•
Construct redundancy exists if more than one grammatical construct represents the same ontological construct.
•
Construct excess exists in a modelling technique when a grammatical construct is present that does not map into any ontological construct.
The popularity of using ontologies as a basis for the analysis of Business Systems Analysis techniques has been growing steadily. The Bunge-Wand-Weber (BWW) ontological models (Weber, 1997), for example, have been applied extensively in the context of the analysis of various modelling techniques. Wand and Weber (1989, 1990b, 1993, 1995) and Weber (1997) have applied the BWW representation model to the “classical” descriptions of entity-relationship (ER) modelling and logical data flow diagramming (LDFD). Weber and Zhang (1996) also examined the Nijssen Information Analysis Method (NIAM) using the ontology. Green (1997) extended the work of Weber and Zhang (1996) and Wand and Weber (1993, 1995) by analysing various modelling techniques as they have been extended and implemented in upper CASE tools. Furthermore, Parsons, and Wand (1997) proposed a formal model of objects and they use the ontological models to identify representation-oriented characteristics of objects. Along similar lines, Opdahl and Henderson-Sellers (2001) have used the BWW representation model to examine the individual modelling constructs within the OPEN Modeling Language (OML) version 1.1 based on “conventional” objectoriented constructs. Green and Rosemann (2000) have extended the analytical work into the area of integrated process modelling based on the techniques presented in Scheer (2000a). The BWW models also have been applied in the context of Enterprise Resource Planning (ERP) Systems. Sia and Soh (2002) utilise the BWW models to propose
Ontological Analysis of Business Systems Analysis Techniques
5
a theoretically grounded framework for assessing the severity of ERP misalignment in organisations. The authors demonstrate the application of the proposed framework by applying it to a hospital case study, in which significant ERP misalignment is identified as a result. Shanks, Tansley, and Weber (2003) utilise the application of the BWW model in order to investigate the representation of part-whole relationships in conceptual modelling grammars. The authors use the BWW model to support their argument for representation of part-whole relationships as entities as opposed to relationships or associations. Their argument is further supported by an empirical study that concludes that using entities to represent part-whole relationships leads to an improvement in the level of the user’s understanding of the domain. Davies, Green, and Rosemann (2002) demonstrate the potential usefulness of meta-models for comparing and evaluating ontologies.1 The authors focus on the analysis of the meta-models of the BWW representation model and Chisolm’s Ontology, concentrating on ontological equivalence, depth of structure, and comprehensiveness of scope of the models. The findings of the work revealed that the two models were not completely ontologically equivalent, with the BWW model being more comprehensive in scope and Chisolm’s Ontology having a deeper structure than that of the BWW model. Davies, Green, Milton, and Rosemann (2004) extend the work to include a detailed discussion of the benefits of the use of meta-models for evaluating ontologies. Fettke and Loos (2003) discuss the process of BWW ontological evaluation of reference models and identify a number of possible application areas. The authors suggest that the proposed method may be used for evaluation of reference models, comparison of two or more reference models, representation of reference models in model repositories, and describing the key characteristics of reference models in order to facilitate selection of appropriate models in specific situations Most recently, Green, Rosemann, Indulska, and Manning (2004) have extended the use of this evaluative base into the area of enterprise systems interoperability using business process modelling languages like ebXML, BPML, BPEL4WS and WSCI. Table 1 provides an overview of the related work performed to date involving the Bunge-Wand-Weber models. Indeed, much of this work has involved evaluations based on Weber’s (1997) two situations. A mismatch between ontological and modelling constructs however does not necessarily indicate weaknesses of the target modelling technique. Rather, as Rosemann and Green (2002) point out, it could indicate misspecification in the ontology used for the evaluation.
Ontological Analysis of Business Systems Analysis Techniques
7
•
It could be that the ontology is over-engineered. The ontology may include constructs that are not relevant. The ontological analyses of various modelling techniques to date have consistently identified certain ontological constructs that do not have representations in the grammars examined, for example, conceivable state space, conceivable event space and lawful event space. The ontological analyses to date in themselves form an empirical study around this possibility of over-engineering. One conclusion then could be the identification of the need for a reduction in the number of constructs thought to be sufficient and necessary in the ontology.
•
Even if the ontology is not over-engineered, most modelling techniques usually focus on modelling particular aspects of the real-world, for example, statics, dynamics, processes, data, actors, actions, goals and the like. Apparently, the objectives of the modelling grammar need to be taken into account during the ontological analysis. Such work suggests a need for individualization of the ontology by means of not only designing subsets but also specializations of the ontology — a focused ontology.
•
Finally, there may be a need for extending the ontology. Weber (1997), for example, has already extended the understanding of the ontological construct, property, by explaining the various types of property, for example, property in general, property in particular. The growing importance of strategic enterprise modelling might lead to the explication of the BWW model to incorporate for example business objectives, strategies, goals or knowledge.
While there may be misspecification in ontologies, such a problem cannot be verified without substantial empirical research based on the theory being performed. In any case, ontology is seen as a potential fruitful theoretical basis on which to perform analyses of modelling techniques. However, while ontological analyses are frequently utilised, particularly in the area of analysing conceptual modelling techniques, the actual process of performing the analysis remains problematic. The current process of ontological analysis is open to the individual interpretations of the researchers who undertake the analysis. Consequently, such analyses are criticised as being subjective, ad hoc, and lacking in relevance. There is a need, therefore, for the systematic identification of shortcomings of the current ontological analysis process. The identification of such weaknesses, and their subsequent mitigation, will lead to a more rigorous, objective and replicable analytical process.
Shortcomings of Current Ontological Analyses An ontological analysis is in principle the evaluation of a selected modelling grammar from the viewpoint of a defined and well-established ontology. The current focus of ontological analyses is on the bi-directional comparison of ontological constructs with the elements of the modelling technique that is under analysis. Weber (1997) defines ontological clarity and completeness as the two main perspectives of an ontological analysis. Though this type of ontological analysis is widely established, it still has a range of issues. These issues can be categorised into the three main phases of an ontological analysis — that is, preparation of the input data, the process of conducting the analysis and the evaluation and interpretation of the results. The first two identified shortcomings refer to the quality of the input data.
Lack of Understandability Several ontologies that are currently used for analysis of modelling grammars have been specified in formal languages. While such a formalisation is beneficial for a complete and precise specification of the ontology, it is not a very intuitive specification. An ontology that is not clear and intuitive can lead to misinterpretations as the involved stakeholders might have problems with the specifications. Furthermore, it forms a hurdle for the application of the ontology as it requires a deep understanding of the formal language in which it is specified. Moreover, it is not only the meta-model and the notation that is used for the specification of the ontology, but also the selected terminology. In our own applications, for example, we realised that elements of the BWW model such as “conceivable state space” are not self-explanatory to members of the modelling community.
Ontological Analysis of Business Systems Analysis Techniques
9
coder to “mentally convert” the two specifications into each other, which adds a subjective element to the analysis. Different languages can also lead easily to different levels of detail and further complicate the analysis. In any case, they make a more automated comparison practically impossible. This situation is typical in many previous analyses. The further three shortcomings identified below are related to the process of the ontological analysis and refer to what should be analysed, how it should be analysed, and who should conduct the analysis.
Lack of Completeness The first decision that has to be made in the process of an ontological analysis is the scope and depth of the analysis. Even if most ontologies have been discussed for many decades, they still undergo modifications and extensions. It is up to the researcher to clearly specify the selected version of the ontology and the scope and level of detail of the analysis. In our work in the area of Web services standards, for example, it was often not clear what constructs form the core of the selected Web services standard. Two researchers, who conducted independent analyses of the same Web services standard, selected consequently a different number of constructs. Moreover, many ontological analyses solely focus on the constructs of the ontology and the constructs of the grammar, but do not sufficiently consider the relationships between these constructs. The difficulty in clearly specifying the boundaries of the analysis, as well as the limited consideration of relationships between the ontological constructs, lead to a potential lack of completeness.
Lack of Guidance After the scope and the level of detail of the analysis have been specified, it is typically up to the coder to decide on the procedure of the analysis — that is, in what sequence the ontological constructs and relationships will be analysed? Currently, there are hardly any recommendations on where to start the analysis. This lack of procedural clarity underlies most analyses and it has two consequences. First, a novice analyst lacks guidance in the process of conducting the ontological evaluation. Thus, the application of ontological analyses is potentially limited to experts in both the selected ontology and the modelling technique. Second, the procedure of the analysis can potentially have an impact on the results of the analysis. Consequently, it is possible that two analyses that follow a different process may lead to different outcomes.
Lack of Objectivity An ontological analysis of a modelling technique requires not only detailed knowledge of the selected ontology and technique, but also a good understanding of the languages in which the ontology and the grammar are specified. This requirement explains why most analyses are carried out by single researchers as opposed to research teams. Consequently, these analyses are based on the individual interpretations of the involved researcher, which adds significant subjectivity to the results. This problem is further compounded by the fact that, unlike other qualitative research projects, ontological analyses typically do not include attempts to further increase the validity of the results. The five shortcomings identified above have a common flavour in that they heavily depend on the researcher conducting the ontological evaluation. Three further shortcomings have been identified — that is, lack of result representation, lack of result classification and lack of relevance. These shortcomings are detailed below and refer to the outcomes of the analysis.
Lack of Adequate Result Representation The results of a complete ontological analysis — that is, representation mapping and interpretation mapping, are typically summarised in two tables. These tables list all ontological constructs (first table) and all grammatical constructs (second table) and the corresponding constructs. Such tables can become quite lengthy and are typically not sorted in any particular order. They do not provide any insights into the relative importance of identified deficiencies. Furthermore, the findings are not clustered typically allowing related deficiencies to appear more apparent. In doing such clustering, the relative importance of the related deficiencies is made clearer as well.
Ontological Analysis of Business Systems Analysis Techniques
11
significance of the results. It is expected, however, that the missing support for a core construct of an ontology can be rated higher than a missing corresponding construct for a minor ontological construct or a relationship. This lack of a more detailed statement regarding the significance of a potential shortcoming makes it difficult to judge quickly the outcomes of the results of two different sets of analyses, for example, an ontological analysis of ARIS in comparison with an ontological analysis of UML.
Lack of Relevance Finally, the results of an ontological analysis should be perceived as relevant by the related stakeholders. However, if an ontological analysis leads, for example, to the outcome that entity relationship models do not support the description of behaviour, then such an outcome needs a clarification. It seems that an ontological analysis has to consider the purpose of the grammar as well as the background of the modeller who is applying this grammar. The application of a high-level and generic ontology does not consider this individual context and there is a danger that the outcomes can be perceived as trivial or non-relevant.
A Reference Methodology for Conducting Ontological Analyses The shortcomings identified above motivated the development of an enhanced methodology for ontological analyses. The main purpose of this methodology is to increase the rigour, the overall objectivity and the level of detail of the analysis. The proposed methodology for ontological analyses is structured in three phases — that is, input, process and output.
motivations for converting current specifications of ontologies into meta-modelbased specifications. First, the development of a meta-model that describes and clarifies the current understanding of the ontological constructs facilitates the use of ontologies in other related areas such as information systems education. Second, a formal meta-model that clearly describes the elements and relationships within an ontology can help to identify inconsistencies and anomalies in an ontology itself. Third, it can be used for the ontological analysis of modelling techniques (grammars) that are specified in the same metalanguage. In this case, the analysis turns into a pattern matching exercise. Fourth, a meta-model can be used to improve existing techniques and derive new modelling techniques (i.e., ontology-based method engineering). Fifth, it can also be applied for the comparison of different ontologies, if they are specified in the same metalanguage (Davies et al., 2002). Finally, based on the outcomes of the evaluation and comparison of ontologies, a meta-model can be used to develop and specify a new ontology. Figure 1 outlines these application areas for a meta-model of ontological constructs. In order to overcome the lack of understandability and comparability, the first step is to convert the ontology, as well as the selected modelling grammar, to meta-models using the same language (e.g., ER models or UML class diagram). This conversion facilitates a pattern-matching approach towards the ontological analyses of completeness and clarity of a grammar. We converted the BungeWand-Weber ontology into an ER-based meta-model. This meta-model includes 50 entity types and 92 relationship types. It has clusters such as system, property or class/kind. Such a meta-model explains, in a language familiar to the information systems community, the core constructs of the ontology. It also highlights the underlying focus of the ontology. In the case of the BWW model, for example, the visual inspection of the meta-model indicates that the ontology is centred around the existence of a thing, which is the central entity type in the meta-model. Figure 2 provides, as an example, an impression of the size and complexity of the meta-model for the BWW ontology. We used a modern version of the entity relationship (ER) language as the metamodelling language. The version of the ER approach used in our work is based on the original ER specification from Chen (1976) with extensions made by Scheer (2000a). This version is called the extended ER model. This selection was made for the following reasons: 1.
Since Chen (1976) introduced the original ER approach, it has undergone intensive discussions and further developments. It is realistic therefore to expect that solutions for special methodological problems that could occur during the process of designing the meta-model are already available in most cases.
Ontological Analysis of Business Systems Analysis Techniques
13
Figure 1. Application areas of a meta-model for ontological constructs
1a) Facilitates communication about the ontology 2) Clarifies inconsistencies and anomalies
1b) Simplifies teaching the ontology 5) Streamlines the comparison of ontologies
Q
Ontology B
Meta Model for ontological constructs
3) Streamlines the ontological analysis of grammars
Ontology C Grammar A
Grammar B
4) Enables ontology-based method engineering
6) Enables ontology
engineering
New Grammar
New Ontology
Figure 2. The BWW meta-model R eal W o r ld
B W W m eta m o de l v e r4 - 2 3 /9 /20 0 2
1,n
A ut ho r : Is la y D a v ie s m ade up of
P R O P ER TY
T H I N G / C L A S S / K IN D
SYS TE M
S y s te m S t r u c tu r e
0,n
2,n
as s o c i a te d i n to
0,n
has
C o m p o s i te Th i n g
0,n
d,t
1,n has
1,n d,t
S im p l e Th i n g
1,n
P r op e r ty i n general
0,n
P r op e r ty i n p a r t ic u la r
0,1
0,n obs erv ed as is subset of
ca u s e s
c on t ain s
in h e re n t ly p o s se s s e s
1,n
i nit ia t e d by
1,n
is n o t i n c lu d e d in 0,n
has
S y s te m E n vi ro n m e n t
1,n
has
1,n 1,n
I n tr in si c P r op e r ty
n,p 1,n a ffe c t e d by
2,n 2,n
0,n
s hares
1,n
0,n
d,t
1,n
B in d in g M u tu a l P r op e r ty
2,n
H e r e d it a r y P r op e r ty
1,n
1,n
N o n - b in d in g M u tu a l P r op e r ty
1,n
U n s ta b l e S ta t e
1,n
0,n
1,n
E x te r n a l E ve n t
M u tu a l P r op e r ty
not a ffe c t e d by
i n te r a c ts w it h
is subset of
oc c urs on
1,n
E mer gent P r op e r ty
bel ongs to
i n h e ri te d by
d,t 1,n 0,n is subset of
d oe s n o t o c cu r o n
bel ongs to
x2,n
remai ns
S ta b l e S ta t e
d,t x1 + x 2 = 1 ; x1 , 2 i s e le m e n t o f { 0 , 1 }
1,n
x1,n
produc es
2,n 0,n x6,n
1,n
I n te r n a l E ve n t
0,n generat es
S y s te m C o m p o s i ti o n
x5,n
0,n
0,n
oc c urs on
has
2,n
m akes up
assum es
C la s s
1,n
1,n 0,n
2,n
x5 + x 6 = 1 ; x5 , 6 i s e le m e n t o f { 0 , 1 }
is i n c lu d e d in
1,n
1,n
K in d
1,n
0,1 0,n 0,n has
2,n
m akes up
i nit ia t e d by
1,n
2,n c h ar a c te r iz e d by
c on t ain s
di s p la y s
assum es
is subset of c h ar a c te r iz e d by
x3 + x 4 = 1 ; x3 , 4 i s e le m e n t o f { 0 , 1 }
1,1 S y s te m
0,n 0,n 2,n
1,1
0,1 1,1 1,n
1,1
x4,n x3,n
0,n
i s d e fin e d as
0,n
1,1
p a r t ia l o r d e r d e f in e d in
1,n
C o u p li n g
I n te r n a l C o u p li n g
L e ve l S t r u c tu r e
d,t
1,n
di s p la y s
0,n
0,n
0,n Th i n g
0,n
0,n 0,n
0,n
0,n
0,n
1,n
1,n
1,1
0,n
0,n
0,n
0,n
f o rm e d by
1,n 1,n
P r op e r ty 0,n
1,n
1,n
1,1 0,1
0,n
0,n
2,n 1,n 0,1
0,n
0,n
0,n
decom posed i n to
E x te r n a l C o u p li n g
1,n S ub s y s t e m
1,1
m o d e ll e d as
E V E N T / T R A N S F O R M A T IO N
1,n
E ve n t
oc c urs on
1,1
1,n
ST A TE
p o s se s s e s
1,n 1,n
1,1
0,n
0,n
r e p r e s e n te d by
A tt ri b u te
0,n
2,2
can occur on 1,1
C ro s s P ro d u c t
1,1
c o n t a in e d in
f orms c o n t a in e d in
'h a s ' r e la t io n s h i p = 'se t o f in d i vid u a l s t a te f u n c ti o n s '
0,n
0,n 1,n L a w fu l E ve n t S pace
K EY :
is subset of
1,1
C o n c e iva b le E ve n t S pace
0,1
1,n
com posed of
0,n
0,n
has
V a lu e
f orms
M o d el o b je c ts :
c o n s is ts of
c o n s is ts of
'a s s u m e s ' r e la t io n s h ip = 't o t al s t a t e f un c t io n ' 0,n
1,n
1,n
0,n
1,n
0,n 0,n
assum es
1,n
oc c urs at
1,1
Ti me I n s ta n t
0,1 1,1
0,1
T r a n s fo r m a t io n 1,1
c o n t a in e d in
can assum e 0,n
rec orded in
is
= B W W co re co n s tr uct s
0,n
0,n 1,n
1,n 0,n
prec edes
0,n
a f fe c t s
K now n S ta t e
S ta t e
= o th e r B W W c o ns tru c t s
has
1,n n,p H is t o ry
P re d i c ta b l e S ta t e
0,n
o rd e r e d by
s uc c e e d s 0,n 0,n
= no n -B W W - co ns t ru c t e nt ity ty p es W e l l- d e fi n e d E ve n t
1,n
0,n
0,n
is c o n t a in e d in
d,t
= n o n - BW W -co n st r uc t r e la t io ns h ip t y p es P o o rl y -d e fin e d E ve n t
1,n
is not 1,n
0,n
c o n t a in e d in
is a
= int r o du c e d c o n ce p ts o r ter m s n o t e x plic it ly s t a te d in W e be r ( 1 9 9 7) o r G r e en & R o se m a n n ( 2 0 0 0 ) , w h ic h h a v e be e n a d d ed in o r d er to fu lly de sc ri b e th e B W W c o n s tr u c ts w ith in th e c o n s tr a in ts o f eE R m o de lling
0,n
L a w fu l S ta t e S pace
1,1 0,n
is subset of
0,n
C o n c e iva b le S ta t e S pace
1,n
1,n
r e q u ir e s
C ro s s P ro d u c t
G e ne r a liza tio n /Sp e c ia liza t io n: d = d is jo in t (X O R ) n = n o n -d is jo in t (in clus iv e O R ) t = to t a l (a ll s ub ty p es w h ic h e x is t a r e dip ic t ed ) p = p a rtia l (fu rt he r su b t y p es n o t de p ict e d in th e m o d el e x is t)
Ontological Analysis of Business Systems Analysis Techniques
15
Table 2. Core ontological constructs in the BWW representation model Ontological Construct
Explanation
THING*
A thing is the elementary unit in the BWW ontological model. The real world is made up of things. Two or more things (composite or simple) can be associated into a composite thing.
PROPERTY*: IN GENERAL IN PARTICULAR HEREDITARY EMERGENT INTRINSIC NON-BINDING MUTUAL BINDING MUTUAL ATTRIBUTES
Things possess properties. A property is modelled via a function that maps the thing into some value. For example, the attribute “weight” represents a property that all humans possess. In this regard, weight is an attribute standing for a property in general. If we focus on the weight of a specific individual, however, we would be concerned with a property in particular. A property of a composite thing that belongs to a component thing is called an hereditary property. Otherwise it is called an emergent property. Some properties are inherent properties of individual things. Such properties are called intrinsic. Other properties are properties of pairs or many things. Such properties are called mutual. Non-binding mutual properties are those properties shared by two or more things that do not “make a difference” to the things involved; for example, order relations or equivalence relations. By contrast, binding mutual properties are those properties shared by two or more things that do “make a difference” to the things involved. Attributes are the names that we use to represent properties of things.
STATE*
The vector of values for all property functions of a thing is the state of the thing.
TRANSFORMATION*
A transformation is a mapping from one state to another state.
STABLE STATE*
A stable state is a state in which a thing, subsystem, or system will remain unless forced to change by virtue of the action of a thing in the environment (an external event).
Figure 4. Comparison of the BWW meta-model and the ARIS meta-model BWW Model 0,n
precedes
Transformation 0,n
0,n 0,n
State
succeeds
ARIS 0,1
Function
precedes
0,1
0,1 0,1
Event
succeeds
Figure 4 depicts an example that shows how meta-models can facilitate the ontological analysis of a modelling grammar. The excerpt of the BWW metamodel depicts the dynamic part that constitutes a process in which states and transformations are strictly alternate. Both constructs together form, in the terminology of the BWW models, an event. The bottom portion of Figure 4 includes the corresponding part of the meta-model of the Architecture of Integrated Information Systems (ARIS). In the modelling technique, eventdriven process chains (EPC), of ARIS, each process consists of an alternate sequence of events and functions. Thus, functions (events) of the EPC modelling technique can be mapped to the transformations (states) of the BWW models. Corresponding mappings are possible for the relationship types. Such a model comparison allows an objective ontological analysis and easily facilitates the identification of weaknesses such as ontological overlap, excess or redundancy (Green & Rosemann, 2000). Furthermore, this approach helps to identify synonyms (e.g., function and transformation) as well as homonyms (e.g., event).
Process Issues related to the process of conducting an ontological analysis have been described as lack of completeness, lack of guidance and lack of objectivity. Based on the assumption that corresponding meta-models for the ontology and the analysed grammar are available, it is possible to clearly specify the scope of an analysis using those meta-models. Such a selection of clusters, entity types and relationship types would define all elements that are to be perceived of relevance for a complete analysis. An analysis of an ER-based notation, for example, could be focused on the BWW clusters thing, system, and property
Ontological Analysis of Business Systems Analysis Techniques
17
and could exclude the more behavioural-oriented clusters event and state. Such boundaries of an analysis could be easily visualised in the meta-model and would provide a clear description of the comprehensiveness of the analysis — thus, mitigating the completeness criticism. The existence of two corresponding meta-models and a clear definition of the scope of the analysis are necessary, but not sufficient, criteria for a well-guided process. Further guidelines are required regarding the starting point of such a process and the actual sequence of activities. Based on our experiences, we recommend starting with the representation mapping — that is, selecting the meta-model of the ontology and subsequently identifying the corresponding elements in the modelling grammar. The first construct to be analysed should be the most central entity type — that is, in the case of the BWW models the entity type thing. Our previous work provides a strong argument that this analysis should be followed by a cluster-by-cluster approach. Starting with the core constructs in a cluster, this approach allows a more structured and focused analysis of the completeness of a modelling grammar. The analysis of the entity types is followed by the relationship types and the cardinalities. Constructs in the meta-model that only have been introduced for the correctness of the metamodel, but that do not reflect ontological constructs are excluded from the analysis. The representation mapping is followed by an analysis of the clarity — that is, the interpretation mapping. In this case the meta-model of the grammar under analysis is the starting point. The general procedure is similar. A main advantage of a cluster-based analysis is that the structure of the two metamodels provides valuable input for the ontological analysis. In addition to the cluster-based analysis, a further guideline in the process relates to generalisation-specialisation relationships in the meta-model of the grammar. We propose to classify ontologically the super-type first and then to inherit this ontological classification to all sub-types. These guidelines streamline the process of the analyses and increase the consistency. The lack of objectivity issue, on the other hand, stems frequently from the analysis being performed by a single researcher. The situation results in an analysis that is almost certainly biased by the researcher’s background as well as their interpretation of the specification of the grammar. In order to improve the validity of the analysis, a research methodology can be adopted that undertakes individual analyses of a particular grammar by at least two members of a research team, followed by consensus as to the final analysis by the entire team of researchers. The methodology consists of three steps: 1.
Using the specification of the grammar in question, at least two researchers separately read the specification and interpret, select and map the ontological constructs to candidate grammatical constructs to create individual first drafts of the analysis.
The researchers involved in step 1 of the methodology meet to discuss and defend their interpretations of the modelling technique analysis. A concurrence score is determined then from their initial analyses. This meeting leads to an agreed second draft version of the analysis that incorporates elements of each of the researchers’ first draft analyses. The overlap in the selection of the constructs and in the actual ontological analysis can be quantified by concurrence/agreement scores that are used in content analysis and other more qualitative research.
3.
The second draft version of the analysis of the modelling technique is used as a basis for defence and discussion in a meeting involving the entire research team. The outcome of this meeting forms the final analysis of the grammar in question.
Such a methodology was employed in a project that sought to apply the BWW representation model analysis to a number of the leading potential Web service standards — that is, ebXML, BPML, BPEL4WS, and WSCI. The project team was composed of four researchers and the standards were analysed in the order: ebXML → BPML → BPEL4WS → WSCI. Two researchers were involved in steps 1 and 2 of the methodology — that is, the individual analysis of a standard followed by a meeting of the two researchers in order to obtain an agreed mapping. This phase was followed by a meeting of the entire team in order to discuss the mapping and arrive at the final analysis. The process was performed for each of the four standards. Table 3 shows the recorded agreement statistics at the second step of the applied methodology, while Table 4 shows the recorded agreement statistics at the third step of the methodology. Meta data of the ontological analysis such as the mapping ratio provides valuable information in addition to the actual outcomes of the analysis. In the case of the analysis of the Web services standards, for example, these figures give insight into how difficult or easy these standards are to understand. The adoption of such a methodology is seen to have improved significantly the objectiveness of the analyses.
Table 3. Summary of step 2 mapping agreement between both researchers Web Service Language ebXML BPML BPEL4WS WSCI
Representation Mapping agreed upon by both researchers 43 36 30 39
Total number of specification constructs identified 51 46 47 49
Ontological Analysis of Business Systems Analysis Techniques
19
Table 4. Summary of step 3 mapping agreement Web Service Language ebXML BPML BPEL4WS WSCI
Representation Mapping agreed upon by the team 49 41 42 46
Total number of specification constructs identified 51 46 47 49
Mapping ratio
96% 89% 89% 94%
Output The three main shortcomings related to the outcome of an ontological analysis have been characterised as the lack of adequate result representation, lack of result classification and the lack of relevance. The meta-models that have been used as input for the ontological analyses are also an appropriate medium to visualise the outcomes of the entire analysis process. In our work on the analysis of ARIS, we derived a meta-model of the BWW model that highlighted all constructs of the ontology that do not have a corresponding construct in the grammar under analysis — that is, we visualised incompleteness in the model using simple colour coding. In a similar way, we derived three ARIS meta-models that highlighted excess, overload and redundancy in ARIS. Such models form a very intuitive way of representing the identified ontological shortcomings. The underlying clustering of the models also helps to quickly comprehend the main areas of shortcomings. At the present time, the process of an ontological analysis results in the identification of ontological incompleteness and ontological clarity through the identification of missing, overloaded or redundant grammatical constructs. While the end result identifies such problems, it fails to account for their relative importance. For example, thing is one of the fundamental constructs of the BWW model. The lack of mapping for the construct should, therefore, be considered more important than the lack of mapping for the well-defined event construct for example. There is a need for the development of a scoring model that enables the calculation of the ‘goodness’ of a grammar with respect to the ontology. In such a scoring model, each of the ontological constructs has a value assigned to it that reflects the relative importance of the construct in the ontology. Core constructs would therefore have high weightings whereas less important constructs would attract lower values of weightings. Following an ontological analysis of a particular grammar, the weighting of all missing constructs would be calculated to arrive at one value that generally reflects the outcome of the analysis.
An example for such a classification could have for example the following structure. All core constructs of an ontology (and the modelling grammar) would get the value 1. All other constructs represented as an entity type in the metamodel of the ontology would receive the value 0.7, and all remaining constructs get the value 0.3. Such a weighting would then be applied to the outcomes of the ontological analysis. The scores would be aggregated across the ontology and modelling grammar. They also would be calculated separately for completeness, excess, overload and redundancy. Furthermore, they could be aggregated per cluster that allows a more differentiated view on the particular strengths of a modelling grammar. Though the consolidated score of such an evaluation should not be overrated, it provides better insights into the characteristics of the ontological deficiencies and provides a first rating of the significance and importance of the identified shortcomings. It can also be used for the design of the subsequent empirical studies. Apart from the lack of result classification that is addressed by the scoring model, another problem with the outcome of the analyses has been the perceived lack of relevance. The merit of a foundational ontology — that is, its generic nature and its completeness, can also be seen as a shortcoming — the ontology might cover more than what one single modelling technique can support and its level of abstraction is too high in order to form a specific benchmark. Thus, three activities seem to be required in order to convert foundational ontologies into focused ontologies.
•
First, since most modelling grammars concentrate on modelling a sub-set of the phenomena that occurs in the real world, it would follow that not all constructs of an ontology are necessary in order to analyse such a grammar. If the full ontology is used in the analysis, the result may identify potential problems that would not, in reality, occur, because the modelling grammar is not used to model any phenomena described by the missing constructs. Consequently, a focused ontology can be derived by deleting constructs from the selected ontology. Indeed, the outcomes of the ontological analyses of different modelling grammars to date appear to support the need for a focused ontology that consists of different subsets of the ontological constructs for different domains. The analyses of process modelling grammars consistently show that the constructs conceivable state space, conceivable event space and lawful event space, for example, have no representation constructs in the grammars. Such missing constructs, if identified to be unnecessary for the particular domain, can be ignored leading to a simpler analysis that does not consider phenomena that are deemed to be outside of the scope of the domain.
Ontological Analysis of Business Systems Analysis Techniques
21
•
Second, there may also be a need for specialisation of some of the ontological constructs in order to enhance analysis of a grammar pertaining to a particular domain. For example, our analyses of Web services standards such as ebXML, BPEL4WS or BPML included the mapping of various activity types to the ontological construct transformation. Such findings could motivate the derivation of relevant sub-types of transformation when it comes to the context of business process management.
•
Third, the derivation of a focused ontology will require adapting the terminology of the analysed domain for two reasons. On the one side, the terms of the ontology might not be intuitive (e.g., conceivable state space within the BWW ontology). On the other side, the analysed domain might have its own established terminology. An example is the area of workflow modelling techniques, in which the Workflow Management Coalition had a significant impact with its glossary.
The argument for a focused ontology might be quite convincing and even seen as trivial. However, the development of focused ontologies faces a major challenge. The decisions about deleting constructs, adding sub-types and renaming constructs have to be based on a substantial number of ontological analyses before they can be justified. Thus, such focused ontologies are not readily available. In general, current ontological analyses focus on the selection of an adequate ontology and the evaluation of modelling grammars against that ontology. Ontological weaknesses are often interpreted as a weakness of the ontology or a weakness of the analysed grammar. It might be however a weakness of the comparison as the ontology and the analysed grammar do not fit. This situation can be explained by the highly interdisciplinary history of most ontologies and it has motivated our extension of the process of ontological analysis by adding a dimension that expresses the relevance of the results. The main advantages of this kind of analysis are that the identified weaknesses are relevant weaknesses and that the focused ontology is based on a well-discussed ontology with philosophical foundations. This use of the focused ontology in an analysis integrates the type of user and his/her relevant purpose. The purpose describes the objectives of the modelling tasks and is used to focus the modelling process at an early stage. For example, many workflow management systems include their own approach to describing the workflows. They are designed for exactly one purpose — the design and support of the execution of workflows. Nevertheless, a traditional ontological analysis would identify certain weaknesses. Possibly however, the developer and the ensuing users of this particular workflow modelling language
Figure 5. An extension of ontological analysis through the use of focused ontologies Chosen Ontology
Focused Ontology
Elimination and Specialization
Modeling Grammar
Focused Ontological Analysis
do not care about such weaknesses, and never intended to provide a language that covers all constructs of the ontology. Besides the purpose, the type of user impacts the requirements of a situation. The user can be classified principally by their role within a modelling project, their role within the modeled domain, their knowledge of the domain, their experience with modelling, and/or their position in the organization. So far, we have only focused on the relevant purpose aspect. To this end, we have examined activity-based costing (ABC) (Rosemann & Green, 2000) and interoperability standards (Green & Rosemann, 2002; Green et al., 2004). We have used ABC (in its classical specification) first to develop a focused ontology because it is now well known and well specified in the business costing literature. One of our near-future directions for research is to test this focused ontology with ABC users to determine if the focused ontology better explains the constructs really required in the target technique.
Ontological Analysis of Business Systems Analysis Techniques
23
2004). Over the last five years, our understanding of ontologies and the contribution that they can make to requirements modelling and conceptual modelling has increased greatly. We have learned a number of important lessons. 1.
The understandability and the applicability of the selected ontology must be clear for IS professionals otherwise they will find it difficult to see the net benefits in the use of the analytical work. Accordingly, we have focused our efforts on developing a more intuitive meta-model for our preferred ontology and using this meta-model as the basis for explaining and applying the constructs of the ontology.
2.
Hypothesized weaknesses in a particular target modelling technique may not be in fact weaknesses of the technique but rather a misspecification in the adaptation of the preferred ontology to the IS modelling discipline. The adapted ontology may be over-engineered, under-engineered, and/or misspecified. In our work over the last five years in using our preferred ontology to analyse a range of techniques, we have noted on several occasions a core of ontological constructs whose representations in the target techniques have been absent. It would appear that our preferred ontology might be over-engineered in some respects. That is, the benefits of having representations in the target techniques for these particular ontological constructs do not appear to outweigh the costs of providing those representations irrespective of the type of user or business purpose of the modelling.
3.
We have perceived the need for a focusing of the ontology dependent on the type of user and the relevant business purpose. Accordingly, as an initial attempt in this direction, we have selected activity-based costing as a relatively well-defined business purpose and we are developing a focused ontology for this technique.
In general, selected ontologies and their interpretations, from an information systems viewpoint, are reasonably advanced. However, the actual process of conducting an ontological analysis is still rather premature. At this stage, the process is focused on the identification of the cardinality of the relationships between corresponding elements in the ontology and the modelling grammar under analysis. In total, eight shortcomings of the current process of ontological analysis have been identified and categorised into issues related to the input, process and output of the analysis. This chapter proposed to enhance further the current methodology of ontological analyses. The objectives of such a methodology are:
To provide guidance for researchers who are interested in conducting ontological analyses.
•
To add rigour to the entire process and reduce the dependence on the subjective interpretations of the involved researcher.
•
To increase overall the credibility of the ontological analysis.
Examples from our ontological analyses of ARIS and various Web services standards have been used to exemplify this methodology. As a consequence, we hope that the presented more rigorous process will increase the overall acceptance of using ontologies for the analysis, comparison and engineering of various grammars. Our future work is continuing and developing in four principal directions. First, we are converting our meta-model to a UML-based definition. In this way, where there are UML-based meta-models for other grammars, we can make our analyses more objective. Second, we are using our meta-model work to provide a basis on which to compare ontologies. In this way, we can provide some theoretical guidance for the selection of an ontology for an evaluative/analytical task. Third, we continue to investigate different business purposes for the production of relevant focused ontologies for the evaluation/engineering of modelling methods that are popularly used in that area. For example, we are currently working on a focused ontology for business process management that will be derived from the BWW ontology. Finally, we continue to empirically test the predictions of our ontologically based evaluations. In this way, we can contribute to the development of the BWW theoretical foundation for business and information systems modelling techniques.
Guarino, N., & Welty, C. (2002). Evaluating ontological decisions with OntoClean. Communications of the ACM, 45(2), 61-65. Karam, G. M., & Casselman, R. S. (1993). A cataloging framework for software development methods. IEEE Computer, 34-46. Olle, T. W., Hagelstein, J., Macdonald, I. G., Rolland, G., Sol, H. G., Van Assche, F. J. M., & Verrijn-Stuart, A. A. (1991). Information systems methodologies: A framework for understanding. Wokingham, England: AddisonWesley. Opdahl, A. L., & Henderson-Sellers, B. (2001). Grounding the OML metamodel in ontology. Journal of Systems and Software, 57(2), 119-143. Opdahl, A. L., & Henderson-Sellers, B. (2002). Ontological evaluation of the UML using the Bunge-Wand-Weber model. Software and Systems Modeling Journal, 1(1), 43-67. Parsons, J., & Wand, W. (1997). Using objects in systems analysis. Communications of the ACM, 40(12), 104-110. Rosemann, M., & Green, P. F. (2000). Integrating multi-perspective views into ontological analysis. In W. Orlikowski, S. Ang, P. Weill, H. Krcmar, & J. deGross (Eds.), Proceedings of the 21st International Conference on Information Systems, Brisbane, 10-13 December, (pp. 618-627). Rosemann, M., & Green, P. F. (2002). Developing a meta model for the BungeWand-Weber ontological constructs. Information Systems, 27(2), 75-91. Rosemann, M., Green, P. F., & Indulska, M. (2004). Towards an enhanced methodology for ontological analyses. In J. Grabis, A. Perrson, & J. Stirna (Eds.), Proceedings of the CAiSE ’04 Forum, Riga, June, (pp. 112-121). Scheer, A. W. (2000a). ARIS – Business process modeling. Springer: Berlin. Scheer, A. W. (2000b). ARIS – Business process frameworks (3rd ed.). Berlin: Springer. Shanks, G., Tansley, E., & Weber, R. (2003). Using ontology to validate conceptual models. Communications of the ACM, 46(10), 85-89. Sia, S. K., & Soh, C. (2002). Severity assessment of ERP-organization misalignment: Honing in on ontological structure and context specificity. In L. Applegate et al. (Eds.), Proceedings of 23rd International Conference on Information Systems (ICIS2002), Barcelona, December. (pp. 723729). van der Aalst, W. M. P., Dumas, M., ter Hofstede, A. H. M., & Wohed, P. (2002). Pattern based analysis of BPML (and WSCI) (Technical report No. FIT-TR-2002-050). Brisbane, Australia: Queensland University of Technology.
Ontological Analysis of Business Systems Analysis Techniques
27
Wand, Y., & Weber, R. (1989). An ontological evaluation of systems analysis and design methods. In E. D. Falkenberg & P. Lindgreen (Eds.), Information system concepts: An in-depth analysis (pp. 79-107). Amsterdam, Netherlands: North-Holland. Wand, Y., & Weber, R. (1990a). Mario Bunge’s ontology as a formal foundation for information systems concepts. In P. Weingartner & G. J. W. Dorn (Eds.), Studies on Mario Bunge’s Treatise (pp. 123-149). Atlanta: Rodopi. Wand, Y., & Weber, R. (1990b). An ontological model of an information system. IEEE Transactions on Software Engineering, 16(11), 1281-1291. Wand, Y., & Weber, R. (1993). On the ontological expressiveness of information systems analysis and design grammars. Journal of Information Systems, 3(4), 217-237. Wand, Y., & Weber, R. (1995). On the deep structure of information systems. Information Systems Journal, 5, 203-223. Wand, Y., & Weber, R. (2002). Information systems and conceptual modelling: A research agenda. Information Systems Research, 13(4), 363-376. Weber, R. (1997). Ontological Foundations of Information Systems (Monograph No. 4). Melbourne, Australia: Melbourne, Vic., Coopers & Lybrand and the Accounting Association of Australia and New Zealand. Weber, R., & Zhang, Y. (1996). An analytical evaluation of NIAM’s grammar for conceptual schema diagrams. Information Systems Journal, 6(2), 147-170. Wohed, P., van der Aalst, W.M.P., Dumas, M., & ter Hofstede, A. (2003). Analysis of Web service composition languages: The case of BPEL4WS. Proceedings of 22 nd International Conference on Conceptual Modelling (ER) (pp. 200-215), Chicago, October.
Endnote 1
In [5] a meta-model can be distinguished from a grammar, for the purposes of this work, as a model of how the constructs of a grammar are related.
understood. In essence, our empirical research provides evidence to support the use of ontology as a theoretical basis to guide conceptual modelling practices.
about how phenomena should be represented in an information system (Hischheim, Klein & Lyytinen, 1995) rather than being driven by database design considerations (Simsion & Witt, 2001, p. 101). For this reason, we argue that the representation of part-whole relations and things and properties in conceptual models should be based on a sound underlying theory of how the world is structured. To the best of our knowledge, however, no rigorous empirical evaluation of alternative representations of part-whole relations and things and properties has been undertaken. In the absence of such research, we undertook to empirically evaluate alternative representations. Our research had several motivations. First, the cost of fixing errors increases the later they are discovered in the system development process (e.g., Boehm, 1981). Because, conceptual modelling work is undertaken early in the system development process, improvements in conceptual modelling practice potentially will lead to high payoffs (Moody & Shanks, 1998). Second, we sought to test prior theoretical work undertaken to predict how well different types of representations facilitate or inhibit human understanding of real-world phenomena. If accurate predictions about the types of conceptual modelling practices that are likely to be effective can be made, the high cost of learning the strengths and weaknesses of different practices through experience can be avoided. Third, we seek to improve user understanding of conceptual models. When conceptual models are prepared initially (e.g., by systems analysts), the users of an information system are asked to validate them to determine how accurately and completely the models represent their perceptual worlds. Finally, we sought to contribute to improved conceptual modelling practice. Numerous varying and sometimes ambiguous guidelines for representation of part-whole relations and things and properties exist in the literature. These guidelines tend to confuse rather than assist practitioners (Simsion & Witt, 2001). We aim to help practitioners by developing improved conceptual modelling rules for part-whole relations and things and properties. In this chapter we report the results of three empirical studies we undertook to examine user understanding of conceptual models. We used ontological theory to predict how part-whole relations and things and properties are best represented to enable user understanding of these phenomena. We also discuss the research and practical implications of our findings as well as future work that might be undertaken.
users. Furthermore, there is no empirical evidence to explain which representation of part-whole relations and things and properties is better. In this light, we relied on Wand et al.’s (1999) arguments about which representation is better. They use Bunge’s (1977) ontological theory as the basis for their analysis. In brief, their arguments run as follows: 1.
“The world is made of things that possess properties” (p. 497). Things and properties are the two atomic constructs needed to describe the world.
2.
Every thing in the world possesses one or more properties (there are no bare things).
3.
Properties themselves cannot have properties. Moreover, properties cannot exist by themselves. They must attach to some thing.
4.
Two types of properties that exist in the world are intrinsic properties, which depend on one thing only, and mutual properties, which depend on two or more things.
5.
Two things interact (are coupled) when a history of one thing (manifested as a sequence of the thing’s states) would be different if the other thing did not exist.
6.
The existence of a mutual property between two things can indicate that they interact with each other. Mutual properties that manifest interactions between two things are called binding mutual properties.
7.
“Two things may associate to form another thing.” A thing is a composite if and only if it is formed from the combination of at least two other things. Otherwise, it is a simple thing. (p. 504).
8.
Every composite thing possesses emergent properties — properties that are not possessed by the components of the composite. (p. 504).
Figure 1. UML association class Student Student 1..1
Enrollment Enrolment
1..1
Subject Subject
1..*
Subject Subject
1..1
Term Term
Figure 2. UML entity class Student 1..* 0..*
Enrollment Enrolment
0..*
0..* 1..*
Term Term
employ tacit knowledge to determine whether the relationship represents a composite thing or a mutual property of two or more things. For example, in Figure 1, enrollment could be interpreted as a mutual property or relationship (association) between student, term, and subject classes. If intrinsic and/or mutual properties were attached to the relationship, it would be unclear whether the properties were intended as properties of the relationship or properties of the composite. Also, in the context of Bunge’s (1977) ontological theory, a property cannot be represented as an entity type because construct (semantic) overload will arise. This outcome occurs when the same grammatical construct (entity type symbol) is used to represent two ontological constructs (things and their properties). Figures 3 and 4 demonstrate how entities and properties may be represented in ER models. Figure 3 shows things represented as entity types (student, address) and properties as entity types (student address). Figure 4 shows an alternative representation that we propose where things are represented as entities and properties are represented as attributes. If the ontological principles are contra-
vened and properties are represented as entities, the conceptual schema model becomes limited. Users will resort to tacit knowledge to determine whether the entity type represents a thing or a property. For example, in Figure 3, student address may be interpreted as a thing when instead it is a mutual property of student and address. In addition to Bunge’s theory, this research relies on theoretical work on cognition. Extensive research reveals that humans cognitively cluster phenomena that they perceive to be related (e.g., Bousfield, 1953). Clustering appears to provide a means for humans to deal with the complexity they often encounter in their perceptual worlds (Miller, 1956). By focussing on clusters, they reduce cognitive load and enhance their abilities to understand the world. Properties of things naturally cluster with the things to which they belong. Perceiving the world in terms of things and their properties, therefore, helps humans to mitigate the cognitive problems they experience when they perceive phenomena to be complex. To maximise our contribution to conceptual modelling practices, we based our empirical studies on the widely used UML and ER modelling notations. Part-
Figure 3. Practice student address ER model
Student
has
has
Student Number Student Name Student DOB Student Address
Address Address Number Street Number Street Name Suburb Country Post Code
Student Number Address Number From Date To Date
Figure 4. Ontologically sound student address ER model
Student Student Number Student Name Student DOB {Address Number From Date To Date}*
has
Address Address Number Street Number Street Name Suburb Country Post Code {Student Number From Date To Date}*
whole relations feature in object-oriented conceptual modelling approaches (e.g., Rumbaugh et al., 1999); therefore, we used UML to test the representation of part-whole relations (Appendices A and B). Part-whole relations also feature in the ER modelling notation (Simsion & Witt, 2001). Entity and attribute types are fundamental constructs in ER modelling approaches; therefore, we used ER modelling to test the representation of things and properties (Appendices C, D, E, and F). Things and properties also appear in the UML modelling notation. We contend that the choice of representation in conceptual modelling is important in terms of users’ ability to elicit the meaning of the phenomena described via the representation. Hence, the following propositions motivate the two experiments we undertook:
•
Proposition 1: Conceptual models that use entity class constructs to represent composites will enable users to better understand the semantics associated with the composite than conceptual models that use a relationship class construct.
•
Proposition 2: Conceptual models that use an attribute construct to represent properties will enable users to better understand the semantics associated with the model than conceptual models that use an entity class construct.
In order to better understand the outcomes of our second experiment, we undertook an exploratory cognitive process tracing study motivated by the following proposition:
•
Proposition 3: Cognitive behavior patterns of users explain the differences in their ability to understand conceptual models with different representations of things and properties.
Representing Part-Whole Relations The first experiment investigated user understanding of the representation of part-whole relations and was reported in detail in Shanks, Tansley, Nuredini, Tobin, and Weber (2002). A summary of the design and outcomes follows.
Research Method and Design Design and Measures The experiment was conducted in a laboratory setting to allow for control of external factors that might confound the results. One between-groups factor was used. This factor, “type of representation”, had two levels: the ontologically sound level which had both composites and components in part-whole relations represented as entity classes, and the ontologically unsound level which had composites represented as relationship classes. Both levels were represented in a UML class diagram. The dependent variable was the performance of on problem-solving questions. This variable was selected to evaluate how well participants in the experiment understood the project-planning domain represented in the UML class diagram. It is deemed to provide a better indicator of “deep” understanding (Mayer, 1989; Bloom, 1956), and it has been used before in the information systems field (Geminio, 1999; Bodart, Sim, Patel, & Weber, 2001). Performance on problem-solving questions was measured according to solution accuracy and time taken.
Materials Four sets of materials were used in the experiment — namely, a summary of the UML symbols with definitions, two UML class diagrams, eleven problemsolving questions, and a personal profile questionnaire. The symbol summary was designed to inform participants of the meaning of each symbol used in the experimental diagrams. One model, the ontologically sound model (Appendix A), had both components and composites represented explicitly as entity classes and were linked via associations. The other model, the ontologically unsound model (Appendix B), showed components as classes whereas composites were implied via the links between component classes. A set of problem-solving questions was also developed to encourage participants to use the UML class diagrams and to avoid use of tacit knowledge. Finally, participant demographic data was collected using a personal profile questionnaire.
Participants Participants were selected based on their ability and experience to act as surrogate end users. Thirty took part in the study, all of whom were working in non-technical roles and had little or no modelling experience.
Procedures Participants were run individually through the experiment to enable detailed observation of their problem-solving behavior. They were assigned randomly to one of the two treatments. They also signed a consent form and provided demographic and experiential information about themselves. Next, they were given symbol summary of UML notation that they retained and could refer to during the experiment. They were then given either the ontologically sound or ontologically unsound UML class diagram together with the problem-solving questions. Participants were asked to speak aloud as they worked through each question so that their utterances could be audio recorded and documented. The time taken to answer each question was recorded, and we made notes on their reactions and queries in relation to each problem-solving question.
Outcomes To evaluate the results of the experiment, we analysed both the scores for problem-solving questions and the transcriptions of the audio recordings.
Quantitative Analysis The scoring of the problem-solving task was calculated as follows:
•
Answer where one mark was given if the answer (“possible” or “not possible”) was correct; zero was given if the answer was incorrect.
•
Explanation where a judgment was made based on the participant’s explanations, researchers’ notes, and the audio recording. Clear explanations supporting an answer were awarded one mark, and moderately clear explanations were awarded a half mark. If explanations were unclear, zero marks were awarded.
•
Interpretation where a judgment was made using participant explanations, notes, and audio recordings. Clear interpretations of the domain received one mark, while moderately clear interpretations received a half mark. Any unclear interpretations were awarded zero marks.
Table 1 presents the statistics for the total accuracy, total time and t-tests. These figures suggest that participants who received the ontologically sound model scored much higher in terms of accuracy than those who received the ontologically
Time taken (minutes) t=-1.166, df= 28, p=0.253 Mean Std. Dev. 33.24 11.46 38.99 15.26
unsound model. Although they also managed to take less time on average, the difference was not as significant.
Qualitative Data Analysis To obtain a deeper understanding of participants thought processes as they answered the problem-solving questions, a qualitative analysis was undertaken. Participants’ protocols were selected randomly for analysis until we were no longer learning anything new. Saturation occurred after analysing data from 10 participants (five with the ontologically sound treatment and five with the ontologically unsound treatment). A set of problem-solving phases that we thought participants would most likely traverse was derived iteratively. The seven phases were:
• • •
Phase 1: Can I understand the problem posed?
•
Phase 4: Can I identify clearly the subset of the model on which I should focus to answer the question asked?
•
Phase 5: Can I articulate the semantics of the subset of the model that is the focus?
•
Phase 6: In the context of the model semantics, can I solve the problem asked?
•
Phase 7: Phase change — this represents the sequence and iteration undertaken by participants between phases 1 and 6.
Phase 2: What are the key real-world concepts in the problem posed? Phase 3: Can representations for key real-world concepts be found in the diagram?
The two of us who were present at each experiment examined each participant’s utterances for statements of concern that indicated the participant was having difficulty answering the question. Participants’ statements were then coded
according to the phase we believed they were traversing. For each participant and each problem-solving question, the statements of concern were then classified into phases and recorded in a table. Table 2 shows a summary of the number of different statements of concern. Participants who received the ontologically sound treatment had sparse entries with no statements of concern for phase 2 and questions 1 and 5. Additionally, one participant completed the entire problem-solving task without uttering a single statement of concern. Across all questions and phases, the average number of statements made by each participant with the ontologically sound model was 5.8. For phase 5 alone (our primary focus), participants made an average of 1.4 statements. These results suggest that participants who used the sound model found the problem-solving tasks to be relatively straightforward. They progressed somewhat effortlessly through all phases. By comparison, participants who received the ontologically unsound treatment had more difficulties progressing through the questions. They made significantly more statements of concern. The least number of statements made was in phase 4, whereas the largest number of statements made was in phase 5 (total of 65). The average number of statements of concern per participant was 29.6, and every question and phase had at least one statement of concern. One participant in particular made nine statements for phase 5 in relation to a single question. These results suggest that participants with the ontologically unsound treatment had greater difficulty responding to the problem-solving questions.
Table 2. Summary of the number statements of concern Question / Phase 1 2 3 4 5 6 7 Question / Phase 1 2 3 4 5 6 7
Representing Things and Properties The second experiment investigated user understanding of the representation of things and properties and was reported in detail in Shanks, Nuredini, Tobin, Moody, and Weber (2003). A summary of the design and outcomes follows.
Research Method and Design Design and Measures This experiment was conducted in a laboratory setting to allow for control of extraneous factors. A four-group, post-test only experiment was designed with one active between-groups factor, “type of representation”. It had four levels. The first was the entity only, similar to object-role modelling (Halpin, 1995), representing both things and properties as entity types. The second level represented mutual and intrinsic properties as entity types. It was termed the practice level as it is commonly used by practitioners (Simsion & Witt, 2001). The third was the partially ontologically sound level where things and mutual properties (properties of n-tuples of things) were represented as entity types. All the intrinsic properties (properties inherent to individual things) were represented as attribute types. Finally, the ontologically sound level represented things as entity types and properties as attribute types in an ER diagram. Participants’ performance was evaluated using a series of comprehension and problem-solving questions. The comprehension task aimed at determining how well users understood “surface-level” features of a domain. The problemsolving task challenged users’ “deeper” understanding of the domain (Mayer, 1989). Both comprehension and problem-solving performance were measured using accuracy, time taken, and normalised accuracy. Accuracy was expressed as the percentage of questions correctly answered by each participant. One mark (accuracy) was awarded for each comprehension question and three marks (one for accuracy and two for explanation) were awarded for each problem-solving question. Time was the total time expressed in minutes, taken by each participant to answer each question for each task. Normalised accuracy was defined as the number of questions answered correctly per hour (calculated by dividing the number of correctly answered questions by the time taken to complete each task in hours).
Materials Materials consisted of a symbol summary, four models representing a sales order domain, comprehension questions, problem-solving questions, and a personal profile questionnaire. The symbol summary defined and explained with examples the ER symbols used in the experiment. The four models were ER instantiations of the four levels of the type-of-representation factor (Appendices C to F). In addition to the symbol summary and models, ten comprehension and ten problemsolving questions were prepared. The comprehension questions tested participants’ ability to access and navigate the model for simple tasks, requiring responses of either “yes”, “no”, or “not sure” (to minimise guessing). The problem-solving questions encouraged participants to use the ER diagrams and to provide explanations on how they worked out their answers. This ensured answers were derived from the model and allowed further examination of areas prone to difficulty. Question responses were “possible”, “not possible”, or “not sure” (to minimise guessing) with a brief explanation. Finally, a personal profile questionnaire solicited information on a participant’s qualifications and experience.
Participants Eighty participants acted as surrogate end users in the experiment. Each either worked in industry or was studying a postgraduate course. The former did not play information technology roles and had no information systems/technology qualifications. All had at least a bachelor’s degree, and a few had minimal exposure to data models.
Outcomes Comprehension and problem-solving questions were scored and analysed statistically. The scoring for the comprehension task was as follows:
•
Answer where one mark was given if the answer (“possible” or “not possible”) was correct, and zero was given if the answer was incorrect or “not sure” was selected.
For the problem-solving task, marks were awarded in two parts:
•
Answer where one mark was given if the answer (“possible” or “not possible”) was correct, and zero was given if the answer was incorrect or “not sure” was selected.
•
Explanation where two marks were given based on the participant’s written explanations. Clear explanations supporting an answer were awarded one mark, and moderately clear explanations were awarded a half mark. Unclear explanations were awarded zero marks.
Comprehension Task Table 3 presents statistics for the comprehension task. The accuracy scores are reasonable (50.5 percent to 74.5 percent), while the time ranged from 6.7 minutes to 12.88 minutes. The ontologically sound model scored best out of the four models for all three measures as participants were able to score higher in less time, averaging 97.2 correct answers per hour. Participants who received the entity only model on the other hand appeared to have the most trouble with accuracy (50.5 percent), whilst those that received the ER required the longest period of time (12.88 minutes). Table 4 shows the results of significance testing between the four groups using a one-way analysis-of-variance test. The ontologically sound group significantly outperformed the entity only (all p values <0.005). It also outperformed the practice ER group in terms of both time and normalised accuracy and the partially sound group in terms of time. In essence, we found that the ontologically sound representation significantly improved comprehension performance.
Entity-only model Practice ER model Partially sound model Ontologically sound model
Std. Dev. 23.70 19.80 15.55 16.40
Mean 11.40 12.88 8.11 6.70
Normalised Accuracy
(minutes)
Std. Dev. 4.71 5.24 3.53 2.89
(correct answers per hour)
Mean 29.4 37.2 55.2 97.2
Std. Dev. 17.4 19.2 27.0 99.6
Table 4. Comprehension: Differences between groups Accuracy
Model ER Part Entity 0.059 0.204 0.938 ER Part
Sound 0.001 0.501 0.204
Time
Model ER Part Entity 0.683 0.71 ER 0.003 Part
Sound 0.004 0.000 0.003
Normalised Accuracy
Model ER Part Entity 0.970 0.426 0.700 ER Part
Sound 0.001 0.003 0.071
Problem-Solving Task Table 5 shows the mean and standard deviation for each type of model for problem-solving scores. Overall, the accuracy scores were lower than the comprehension scores, ranging from 58.67 percent to 68.17 percent. The time taken is also considerably longer, indicating that problem solving is a more cognitively difficult task. Again, the ontologically sound group scored best on almost all three measures, with higher average accuracy scores (68.17 percent) and less time taken (29.27 minutes). Table 6 shows the results of significance testing. The ontologically sound group significantly outperformed the practice ER group for normalised accuracy. Table 5. Problem solving: Descriptive statistics Accuracy
Group / Measure
Time taken
(percentage)
Entity-only model Practice ER model Partially sound model Ontologically sound model
Mean 58.67 60.00 60.17 68.17
Std. Dev. 13.83 15.27 12.3 14.73
Mean 31.92 36.40 28.05 29.27
Normalised Accuracy
(minutes)
Std. Dev. 11.46 13.10 8.17 13.87
(correct answers per hour)
Mean 36.0 32.4 41.4 51.6
Std. Dev. 13.2 10.2 13.2 33.6
Table 6. Problem solving: differences between groups Accuracy Model ER Part Entity 0.991 0.987 1.000 ER Part
Therefore, taking into account the compromise in accuracy for speed, participants using the ontologically sound model answered more questions correctly per hour than those using the practice ER model.
Cognitive Process Tracing The cognitive process tracing study investigated the cognitive behaviour patterns of users’ understanding of conceptual models with different representations of things and properties and was reported in Shanks, Nuredini, Tobin, and Weber (2003).
Research Method and Design Design and Measures A verbal protocol technique, which requires participants to verbalise their thoughts (Ericsson & Simon, 1984), was used to collect the thought processes of participants performing comprehension and problem-solving questions. We used two of the representations described above: the ontologically sound level and the practice ontologically unsound level. Verbal protocols are a recognised data gathering method used in cognitive psychology. Inherent to defining a problem is the supposition that participants faced with problem solving do not function automatically but consciously construct a representation of the problem and detailed solution strategies. With this foundation, it is possible to access these strategies to the extent that they are partly explicit and under the individual control of the participant. A frequently-used procedure is concurrent verbal reports, where participants are asked to think aloud during the course of the task, therefore allowing direct access “to their thought processes” (Newell & Simon, 1972; Ericsson & Simon, 1980, 1984). Using thinking-aloud protocols provides a means to trace cognitive processes step by step, instead of relying solely on information about outcomes or querying participants retrospectively about their cognitive processes. In this study, we examined cognitive processes using comprehension “surface level” questions and complex problem-solving “deeper analysis” questions (Mayer, 1989). The focus was on obtaining an understanding of the cognitive behaviour of participants during these tasks to explain why the outcomes in the second experiment occurred. The coded protocols were used to analyse the behaviour of participants.
Materials Four sets of materials were prepared for the study: a symbol summary, two ER diagrams, five comprehension questions, five problem-solving questions and a personal profile questionnaire. The symbol summary explained the ER notation. The diagrams consisted of two ER models of a sales order domain. One was the ontologically unsound practice model, and the other was the ontologically sound model. Five comprehension questions from the thing-property study detailed previously were used with a new set of complex problem-solving questions. Finally, a personal profile was created to obtain demographic data on their backgrounds.
Participants Twelve participants took part in the study, all of whom had at least three years industry experience. Participants were selected on the basis that they would act as surrogate end users. They did not play an information technology role in their organisation, and they had no previous data modelling experience.
Procedure Participants were assigned randomly to one of the two models and alternating task sequences (comprehension task followed by problem-solving task or vice versa). All participants completed a consent form and the personal profile questionnaire when they arrived. They were then run singly through the experiment. The nature of the experiment and the necessity to verbalise was first explained to them. A camcorder mounted on a tripod was positioned so that the model and any hand movements were visually recorded in conjunction with all the verbalisations. Next, participants were given the symbol summary, which they discussed with the researchers. Once they were comfortable with the symbols and notation, they were presented with either the ontologically sound or the ontologically unsound model. They were then given either the comprehension task or the problem-solving task and prompted to speak out loud as they read the questions and attempted each task. Where periods of silence occurred, participants were asked to explain their cognitive behaviour as best they could. Once the first task was completed, the second task (either comprehension or problem solving) was given. Finally, when both tasks were completed, the participants were thanked and given $30 for their time.
Outcome All the verbal data on the videotapes was transcribed and analysed based on a coding scheme that was established using the problem-solving literature (e.g., Newell & Simon, 1972) and similar previous studies of data modelling (e.g., Batra & Davis, 1992; Chaiyasut, 1994; Shanks et al., 2002). This coding scheme comprised five cognitive categories:
•
Understanding Question: includes reading the question, seeking clarification, identifying assumptions and constraints, and recognizing the problem posed.
•
Identifying Model Segment: includes locating appropriate parts of the model and matching them against key concepts in the question.
•
Articulating Model Semantics: includes verifying semantics of symbols in the model and rereading the symbol summary.
•
Preparing Solution: includes developing solutions and simulating and revising solutions against the question.
•
Evaluation: includes selection of alternative answers and developing justifications.
Episodes in the transcribed data were independently assigned to the above categories with start and end times (using video data) by two of us. Differences between the two of us who undertook the coding were later reconciled.
Comprehension Task Figure 5 shows the average time that participants spent in each category. Participants who received the sound model on average took 6.61 minutes to complete all five comprehension questions, while those who received the unsound model on average took 7.68 minutes to complete all five comprehension questions. For both models, participants spent the same average time preparing the answer. The unsound model participants spent more time identifying the model segments and articulating the semantics than the sound model participants. Time spent understanding, identifying, and evaluating was also better balanced for the sound model participants. It was more scattered for the unsound model participants who devoted more time to identifying areas, which suggests that they experienced navigation difficulties.
Figure 5. Comprehension average time for the sound and unsound model A ve ra g e Ti m e S p e n t i n E a ch Ca te g o ry- S o un d M od e l
Av e ra ge T i m e S pe nt in Ea c h C a te g ory - Un sou nd M o d e l
22.4 9%
Ev a luating
32.65% 5.3 2% 19.69%
Identif y ing
Under s tan ding
19.84%
Unders tan ding
5.00%
10.00 %
15.00 % 20.0 0% T im e ( % )
25.0 0%
30.00%
7.2 1%
A rtic ulating
Identif y ing
0.00%
3 2.6 5%
Prepar ing Cat eg o ry
Cat e go ry
Preparing
A r tic ulating
14 .02%
Ev a luating
35.00%
31.30% 1 4.83 %
0.00%
5.00%
10.00 %
15.00 % 20.0 0% T im e ( % )
25.0 0%
30.00%
35.00%
Figure 6 shows the proportion of time spent in each behaviour category for each of the 10 time segments. Participants who used the sound model had more linear behavioural patterns than those who used the unsound model. The sequence was also more logical for participants who used the sound model. They first peaked with understanding, then identifying, then articulating, then preparing, and finally evaluating. Participants who used the sound models also performed these categories at earlier times than those who received the unsound model. Unsound model participants had more of an overlap in categories with later peaks. Figure 7 shows sequential dependencies between the five behaviour categories. The numbers above the dependency arrows are the total number of transitions between two categories. The thickness of the arrows indicates the intensity of the dependency. For both models, the most common sequence for participants was to understand the question and to either identify the area in the model or directly prepare the solution before their final evaluation of the answer. Overall, unsound-model participants had fewer phase changes (a total of 99 instances) than sound-model participants (a total of 105 instances).
Figure 6. Comprehension behaviour categories for the sound and unsound model U nde rs ta nding
A rtic u la ti ng P repa ri ng
A rtic ulat ing
90%
E val uati ng
P repari ng
80%
80%
E valuat in g
70%
70%
60%
60% T im e ( % )
T im e ( % )
Ide ntify ing
100%
Iden tify in g 90%
U nd ers tand ing
C T C ate g o ry B e h av io ur o v e r T ime - U n so un d
C T C a te go ry B e h av iou r o v er T im e - S o u n d 100 %
Figure 7. Comprehension sequential dependencies for the sound and unsound model Comprehension Sound Phase Changes 2
Under standing
19.84%
Comprehension Unsound Phase Changes
19 1
Identifying
5
8
Articulating 5.32%
19.69%
21
Under standing
3
6
3
5
14.83%
16
Articulating 7.21%
1
3
12
9 5
12
Preparing
2
32.65%
5 1
31.30%
1
Preparing
Identifying
4 3
32.65%
21 Evaluating 2
16 1
22.49%
Evaluating
1
14.02%
11
7
Problem-Solving Task Figure 8 shows the average time spent in each behaviour category for the problem-solving task. Sound-model participants averaged 37.13 minutes to complete all five problem-solving questions, while unsound-model participants averaged 39.23 minutes to complete all five problem-solving questions. Almost a quarter of both groups’ time was spent understanding the question, with most of their time spent in solution preparation. The unsound-model participants spent more time identifying model semantics, while the sound-model participants focused more on articulating the semantics. Figure 9 shows the behaviour categories traversed over time for the problemsolving task. The time spent understanding was similar for both models. In the identifying category, however, the unsound-model participants had additional peaks. Although the sound-model participants appeared to spend more time articulating, they only peaked once when they were halfway through their Figure 8. Problem-solving average time for the sound and the unsound model PS
22.96% 34.90%
8.87%
Ide ntify ing
23.2 4% 5%
10%
6.34 %
A r tic ulating
13 .4 2%
Identif y ing
Und ers tanding
0%
39 .5 2%
Pr epar ing Cat eg o ry
10.02%
A rtic ulating
17 .8 3%
Ev a luating
Prep aring Cat ego ry
P S A ve r a g e T i m e P e r C a te g ory - Un sou nd M od e l
A ve r a g e T im e S p e n t P e r C a te g o r y - S o u n d M o d e l
Figure 9. Problem-solving behaviour categories for the sound and the unsound model U nde rs ta nding
P S C a teg o ry ov e r Tim e - S o u nd
Un derst an din g
P S C a tego ry o ver T im e - U n s o un d
Iden tify in g A rtic ulat ing
1 00%
Id ent ifying A rtic ulat ing
10 0%
P reparing
P rep arin g 9 0%
E valuat in g
80%
8 0%
70%
7 0%
60%
6 0% T im e ( % )
Tim e (% )
90%
50% 40%
E va lua ting
5 0% 4 0% 3 0%
30%
2 0%
20%
1 0%
10%
0%
0%
1
1
2
3
4
5
6
7
8
9
2
3
4
10
5
6
7
8
9
10
T im e S e g m e n t
Tim e Se g m e n t
problem solving. Unsound-model participants peaked twice during the fourth and seventh segments. The preparing category was similar for both models. In the evaluating category, however, the sound-model participants became confident in their solutions earlier than the unsound-model participants. Figure 10 shows sequential dependencies between the behaviour categories. Sound-model participants began with understanding, then moved to identifying, then moved to preparing solutions, then moved back to understanding and solution preparation before moving to evaluating. Unsound-model participants followed a similar pattern with fewer transitions to and from understanding and preparing. The high number of transitions around understanding the question reflects the complexity of the problem-solving questions. Overall, the soundmodel participants had more phase changes (261 instances) than the unsoundmodel participants (231 instances).
Figure 10. Problem-solving sequential dependencies for the sound and unsound model Problem Solving Sound Phase Changes
Discussion The empirical studies conducted supported the use of ontology as a theory to explain and predict how end-user understanding can be enhanced with both partwhole relation and thing-property representations. We believe we have strong support for our proposition that composites should be modelled explicitly as entity classes and not implicitly as association classes or relationships. If composites are modelled explicitly, the model becomes syntactically more complex because it contains more elements. In the context of problem-solving performance, however, our results suggest that the additional semantics contained in an ontologically sound diagram overcome the disadvantages associated with its higher syntactic complexity. These results are consistent with those obtained by Gemino (1999) and Bodart et al. (2001) on the efficacy of problem-solving tasks as a means of testing how well conceptual models communicate the semantics of a domain to users. With respect to distinguishing between things and properties, the “chunking” mechanism that humans appear to use to deal with complexity (e.g., Miller, 1956; Cofer, 1965; Baddeley, 1994) explains why the ontologically sound model improves comprehension performance more than problem-solving performance compared to the other representations. Problem-solving tasks require deepstructure understanding. Thus, humans have to engage long-term memory. Long-term memory is less affected by complexity and is not subject to the information processing limitations of short-term memory. On the other hand, comprehension tasks rely more on users’ perceptions of the model and processing in short-term memory. Unlike the problem-solving task, no reasoning occurs in long-term memory. Thus, complexity affects comprehension performance more. The cognitive process tracing study sought to explain the outcomes of the thingproperty study. Analysis of the comprehension task clearly identified the difficulties participants had with the unsound representation. Their cognitive processes overlapped and forced them to spend more time identifying and articulating specific areas of the model. Participants using the ontologically sound representation had more linear cognitive processes because they were able to identify and grasp the semantics quicker and focus on preparing the solution. Although similar patterns occurred with the problem-solving task, the distinction was not as clear. The major limitation of our three studies is the laboratory context and materials that are limited in scope and somewhat artificial. Nonetheless, our tasks have enough realism that our results should be robust in other settings involving thingproperty and part-whole relation representations.
Future Work Ontological theory can be used to predict the strengths and weaknesses of other conceptual modelling practices. For example, various approaches to modelling the dynamics of a domain can be evaluated to determine how well they enhance or inhibit user understanding. Additional studies could also include in-depth field research on various uses of conceptual models. In this respect, much scope exists to establish links between ontological theory and practice. Further work is also required to develop better measures of users’ understanding of the semantics of a domain. As described above, our research used comprehension and problem-solving measures to test our propositions. Although these measures seem valid and reliable, it is unclear whether the results hold generally or reflect the idiosyncrasies of our research. Furthermore, it would be of great benefit if the measures took into account that users create their worlds (Hirschheim, Klein, & Lyytinen, 1995) and have different interpretations and meanings.
Conclusion In acknowledging the need for better representation of conceptual models, this research adopted Bunge’s (1977) theory to predict the strengths and weaknesses of several conceptual modelling practices. Our research produced the following results:
•
Part-whole relations are more easily understood when a composite is represented as an entity class, rather than an association or relationship.
•
Distinguishing between things and properties has a significant impact on user comprehension of conceptual models. The distinction appears to have less impact, however, on user problem solving based on conceptual models.
References Baddeley, A. (1994). The magical number seven: Still magic after all these years? Psychological Review, 101(2), 353-356.
Batra, D., & Davis, J. (1992). Conceptual data modelling in database design: Similarities and differences between novice and expert designers. International Journal of Man-Machine Studies, 37, 83-101. Bloom, B. S. (Ed.). (1956). Taxonomy of educational objectives: The classification of educational goals: Handbook I: Cognitive domain. New York: Longmans. Bodart, F. M., Sim, M. Patel, A., & Weber, R. (2001). Should optional properties be used in conceptual modelling? A theory and three empirical tests. Information Systems Research, 12(4), 384-405. Boehm, B. (1981). Software engineering economics. Upper Saddle River, NJ: Prentice Hall. Bousfield, W. A. (October 1953). The occurrence of clustering in the recall of randomly arranged associates. Journal of General Psychology, 49, 229240. Bunge, M. (1977). Treatise on basic philosophy: Volume 3: Ontology I: The furniture of the world. Boston: Reidel. Chaiyasut, P., & Shanks, G. (1994). Conceptual data modelling process: A study of novice and expert data modellers. Proceedings of the First International Conference on Object-Role Modelling, Magnetic Island, Australia, July, (pp. 310-333). Chen, P. P. S. (1976). The entity-relationship model: Toward a unified view of data. ACM Transactions on Database Systems, 1(1), 9-36. Cofer, C. N. (April 1965). On some factors in the organisational characteristics of free recall. American Psychologist, (pp. 261-272). Ericsson, K. A., & Simon, H. A. (1980). Verbal report as data. Psychological Review, 87(3), 215-51. Ericsson, K. A., & Simon, H. A. (1984). Protocol Analysis: Verbal Report as Data. Cambridge, MA: MIT PRESS. Gemino, A. (1999). Empirical methods for comparing system analysis modelling techniques. Unpublished PhD thesis, University of British Columbia. Halpin, T. A. (1995). Conceptual schema and relational database design: A fact-oriented approach (2nd ed.). Sydney, Australia: Prentice-Hall. Hirschheim, R., Klein, H., & Lyytinen, K. (1995). Information systems development and data modelling: Conceptual foundations and philosophical foundations. Cambridge, MA: Cambridge University Press. Kilov, H., & Ross, J. (1994). Information modelling: An object-oriented approach. Upper Saddle River, NJ: Prentice Hall.
Mayer, R. E. (1989). Models for understanding. Review of Educational Research, 59, 43-64. Miller, G. A. (1956). The magical number seven, plus or minus two: Some limits on our capacity for processing information. Psychological Review, 63, 8197. Newell, A. C., & Simon, H. A. (1972). Human problem solving. Englewood Cliffs, N.J.: Prentice Hall. Rumbaugh, J., Jacobson, I., & Booch, G. (1999). The Unified Modelling Language reference manual. Reading, MA: Addison-Wesley. Shanks, G., Nuredini, J., Tobin, D., Moody, D., & Weber, R. (2003). Representing things and properties in conceptual modeling: An empirical evaluation. Proceedings of the European Conference on Information Systems, Naples, Italy, June. Shanks, G., Nuredini, J., Tobin, D., & Weber, R. (2003). Representing things and properties in conceptual modeling: Understanding the impact of task type. Proceedings of the International Conference on Information Systems, Seattle, December, (pp. 909-913). Shanks, G., Tansley, E., Nuredini, J., Tobin, D., & Weber, R. (2002). Representing part-whole relationships in conceptual modelling: An empirical evaluation. Proceedings of the International Conference on Information Systems, Barcelona, Spain, December, (pp. 89-100). Simsion, G., & Witt, G. (2001). Data modelling essentials: Analysis, design and innovation (2nd ed.). Arizona: Coriolis. Wand, Y., Storey, V., & Weber, R. (1999). An ontological analysis of the relationship construct in conceptual modeling. ACM Transactions on Database Systems, 24, 494-528. Winston, M.E., Chaffin, R., & Herrman, D. (1987). A taxonomy of part-whole relations. Cognitive Science, 11, 417-444.
Sales Order Number Customer Number Sales Order Date Accepted Sales Order Confirmation * Employee Number Accept Address Code
Has
Categorise Customer / Employee Assignment
Be
Customer Number Customer/Employee Assignment Start Date Customer/Employee Assignment End Date * Employee Number
Include
Employee
Employee Qualification
Sales Order Item
Belong
Sales Order Number Product Number Sales Order Item Quantity Requested Sales Order Item Sale Selling Price Sales Order Item Sale Cost Price
Product
Group
Contain
Product Category
Employee Qualification Code Product Category Code Employee Number Product Category Name Employee Qualification Year Product Category Description Has
Employee Number Employee Name Employee Telephone Extension Employee Position Title Employee Start Date
Product Number Product Name Product Description Product Category Code Product Current Cost Price Product Quantity on Hand Product Re Order Level
Product Price History
Employee Qualification Code Product Number Employee Employee Qualification Description Product Price History Termination Date Qualification Type Product Price History Minimum Quantity Product Price History Selling Price
Appendix E. “Partially ontologically sound” ER model Supplier
Supplier Number Supplier Name { Supplier Contact Person Supplier Contact Number } *
Have
Customer Location
Belong To
Address
Address Code Customer Number Address Type Name Has
Request Delivery
Customer
Place Customer Number Customer Name Customer Date Registered Customer Credit Limit Customer Segment Description Customer Credit Terms Description { Customer Contact Name Customer Contact Number Customer Contact Type Code Customer Contact Type Description } * { Customer Industry Type Code Customer Industry Type Description } *
Manage
Customer / Employee Assignment
Sales Order
Include Sales Order Number Customer Number Sales Order Date Accepted Sales Order Confirmation * Employee Number Address Code
Accept
Be
Customer Number Customer/Employee Assignment Start Date Customer/Employee Assignment End Date * Employee Number
Actual Delivery Address Code Address Occupancy Number Address Street Name Postal Area Code Postal Area Suburb Postal Area City Postal Area State Postal Area Country Region Name Region Description
Delivery
Distribute
Product Source
Delivery Number Delivery Date Delivery Instructions Delivery Quantity Delivered Sales Order Number Address Code
Sales Order Item
Belong
Sales Order Number Product Number Sales Order Item Quantity Requested Sales Order Item Sale Selling Price Sales Order Item Sale Cost Price
Employee
Produce
Product Number Supplier Number Product Source Start Date Product Source End Date *
Product
Product Number Product Name Product Description Product Current Cost Price Product Quantity on Hand Product Re Order Level Product Category Name Product Category Description { Product Price History Termination Date Product Price History Minimum Quantity Product Price History Selling Price } *
Employee Number Employee Name Employee Telephone Extension Employee Position Title Employee Start Date { Employee Qualification Code Employee Qualification Description Employee Qualification Year } * Level 2
Appendix F. “Ontologically sound” ER model Has
Address
Request Delivery
Actual Delivery Address Code Address Occupancy Number Address Street Name Postal Area Code Postal Area Suburb Postal Area City Postal Area State Postal Area Country Region Name Region Description { Customer Number Address Type Name } *
Supplier
Delivery Delivery Number Delivery Date Delivery Instructions Delivery Quantity Delivered Sales Order Number Address Code
Supplier Number Supplier Name { Supplier Contact Person Supplier Contact Number } * { Product Number Product Source Start Date Product Source End Date } * Produce
Distribute Customer
Place Customer Number Customer Name Date Registered Customer Credit Limit Customer Segment Description Customer Credit Terms Description { Customer Contact Name Customer Contact Number Customer Contact Type Code Customer Contact Type Description } * { Customer Industry Code Customer Industry Type Description } * { Address Code Address Type Name } * { Customer/ Employee Assignment Start Date Customer/ Employee Assignment End Date * Employee Number } *
Manage
Sales Order
Accept
Employee
Belong Sales Order Number Customer Number Sales Order Date Accepted Sales Order Confirmation * Employee Number Address Code { Product Number Sales Order Item Quantity Requested Sales Order Item Sale Selling Price Sales Order Item Sale Cost Price }
Employee Number Employee Name Employee Telephone Extension Employee Position Title Employment Start Date { Employee Qualification Code Employee Qualification Description Employee Qualification Year } * { Customer Number Customer/ Employee Assignment Start Date Customer/ Employee Assignment End Date *} *
Product Product Number Product Name Product Description Product Current Cost Price Product Quantity on Hand Product Re Order Level Product Category Name Product Category Description { Product Price History Termination Date Product Price History Minimum Quantity Product Price History Selling Price } * { Sales Order Number Sales Order Item Quantity Requested Sales Order Item Sale Selling Price Sales Order Item Sale Cost Price } * { Supplier Number Product/Supplier Start Date * } *
Ontological Analysis of Reference Models Peter Fettke, Johannes Gutenberg University Mainz, Germany Peter Loos, Johannes Gutenberg University Mainz, Germany
Abstract Within the information systems field, reference models have been known for many years. A reference model is a conceptual framework and may be used as a blueprint for information systems development. Despite the relevance of reference model quality, little research has been undertaken on their systematical analysis and evaluation. In this chapter, we describe how reference models can be analyzed from an ontological point of view. Such an analysis consists of four steps: 1) developing a transformation mapping, 2) identifying ontological modeling deficiencies, 3) transforming the reference model, and 4) assessing the results. The usefulness of our method will be demonstrated by analyzing Scheer’s reference model for production planning and control. Although our approach is based on sound theory, we argue that this approach is not inherently superior to other approaches of reference model analysis and evaluation.
Introduction Within the information systems field, information modeling is a vital instrument to develop information systems (Frank, 1999; Mylopoulos, 1998; Scheer & Hars, 1992; Wand & Weber, 2002). However, the modeling process is often resource consuming and faulty. As a way to overcome this failures and to improve and accelerate the development of enterprise-specific models, the concept of reference modeling has been introduced (Mertins & Bernus, 1998; Mišic & Zhao, 2000; Scheer & Nüttgens, 2000). We assume the empirical thesis that the effectiveness and efficiency of the application of a reference model is strongly determined by the quality of the model. However, the quality of a reference model comprises several aspects, for example from a user-oriented point of view, a reference model should be flexible and adaptable, so the fitness for its application is very high. From an enterpriseoriented point of view, the purchase and usage of a reference model should make the development of enterprise systems more efficient and so forth (Fettke & Loos, 2003b). In other words, there exist some trade-offs between different quality dimensions. This research addresses the question of how the quality of reference models can be determined. The main objective of this chapter is to describe a method for analyzing reference models from an ontological point of view. Furthermore, we will show an application of this method by analyzing Scheer’s reference model for production planning and control systems (PPC) (Scheer, 1994). Right at the beginning, we point out that an ontological analysis is not able to capture all quality characteristics of a reference model but some necessary characteristics. Further quality criteria are needed, for example, additional criteria may be derived from theories in the area of economic or cognitive psychology. The research method of this study is construction-oriented: after analyzing the fragment of knowledge that is relevant for our research question, we construct a method for the analysis and evaluation of reference models. To justify this method, some application examples are presented. The main contributions of this chapter are a new method for analyzing and evaluating reference models. Furthermore, we elaborate on some quality aspects of Scheer’s reference models. The chapter unfolds as follows. After this introduction, the study’s theoretical background is discussed. The third section introduces the method for the ontological analysis of reference models. Some examples of this method are explored in the following section. Finally, conclusions and limitations of this study are discussed. Also, we point to some further research directions.
Theoretical Background Terminology There is a great deal of terminological confusion in the modeling literature. For example, the term “model” is often used for different purposes. To avoid confusion, we use the following definitions: a grammar “provides a set of constructs and rules that show how to combine the constructs to model realworld domains” (Wand & Weber, 2002, p. 364). In the remainder of this chapter, we always refer to analysis grammars, for example the Entity-Relationship Model (ERM) or the Unified Modeling Language (UML). And while modeling method “provides procedures by which a grammar can be used” (Wand & Weber, 2002, p. 364), scripts are the product of the modeling process. “Each script is a statement in the language generated by the grammar” (Wand & Weber, 2002, p. 364). A script is a representation of a real-world domain using a particular grammar. A reference model is a script representing a class of domains. It is a conceptual framework which could be used as the blueprint for information system development (Kruse, Hars, Heib, & Scheer, 1993, pp. 48f.). Reference models are also called universal models, generic models, or model patterns. To use reference models, they must be adapted to the requirements of a specific enterprise. We refer to such an adapted model as an application model. Concrete instances of reference models are, for example, Scheer’s reference model for PPC (1994), Hay’s data model patterns (1996) or Fowler’s analysis patterns (1997). An overview of reference models is given by Fettke and Loos (2003a) and van Belle (2003).
Bunge-Wand-Weber Model In this subsection we introduce some concepts that are useful for the remainder of our analysis and justify the chosen ontology. Green and Rosemann give a solid overview of the BWW model at the beginning of this book (see also Wand & Weber, 1990a, 1993, 1995; Weber, 1997, for the original introduction of the BWW model). The term “ontology” always refers to the ontology defined by the BWW model. In the following, for reasons of clarity, each term of the vocabulary of the BWW model is used with a BWW prefix. Every BWW term refers to a construct of the ontology. In addition, we use the terms “ontological model” and “construct of an ontological model”. An “ontological model” is a set of constructs of an ontology that represents reality as perceived by an observer. The term “construct of an ontological model” refers to a specific construct of the ontology used in the ontological model.
We chose the BWW model as a basis for analysis for a number of reasons:
• • •
It is well formalized in terms of set theory. It has been successfully adapted to information systems modeling (Table 1). Empirical studies show the usefulness of this ontology (see Table 1).
Prior Work An in-depth discussion of prior work on analyzing and evaluating reference models is presented by Fettke and Loos (2003b). There exists several approaches to conceptual (data) model’s quality in general, for example (Krogstie, 1995; Lindland, Sindre, & Sølvberg, 1994; Moody & Shanks, 2003). However, the reference models’ quality in particular is just discussed by some work: Schütte (1998) proposes six so-called “principles for reference modeling”.1 Each principle can also be used to conduct an ex-ante analysis of a reference model. However, we are not aware of such investigations. An alternative framework for reference modeling evaluation is proposed by Mišic and Zhao (2000). Their framework is influenced by Lindland et al. (1994) and founded in semiotic theory. The usefulness of this framework is demonstrated by the analysis of reference models for electronic commerce. Several criteria for the analysis and evaluation of reference models are introduced by Fettke and Loos (2003a). Using these criteria, the authors characterize several reference models. However, usefulness and purpose of the criteria proposed are not discussed in detail. Van Belle (2003), constructs a framework for the analysis and evaluation of reference models (a prior version of his framework is discussed by van Belle & Price, 2000). This framework is applied to several reference models. One characteristic of this framework is that the proposed metrics are to a large operationalized. The interpretation and meaning of specific metrics is sometimes unclear, for example both SAP’s and Baan’s reference models genericity is measured as “16” (van Belle, 2003, p. 258). For the user, the practical meaning and consequences of this measurement are not straightforward.
ization of a reference model. An ontological normalization is comparable with the normalization of a database schema. The objective of both techniques is to represent the domain of interest in a normalized way by applying specific transformation patterns. Normalization of a database schema aims at eliminating problems of information representation and processing in database management systems (e.g., avoiding data redundancies, update anomalies, etc.). In contrast, the ontological normalization aims to achieve a unified representation of facts represented by a reference model with respect to the structure of reality. Compared to other representations such as UML or ERM, an ontological representation of a reference model has the advantage that it is more general and not influenced by technical aspects. The ontological normalization of a reference model consists of four steps: 1.
Developing a transformation mapping.
2.
Identifying ontological modeling deficiencies.
3.
Transforming the reference model.
4.
Assessing the results.
The following subsections discuss each step in more detail. Applications of an ontological analysis are discussed in the last subsection.
Developing a Transformation Mapping Until now, various grammars have been used to represent reference models. For instance, Scheer (1994) uses the Architecture of Integrated Information Systems (ARIS) (Scheer, 1998a, 1998b), Hay (1996) employs some kind of an ERM, and Fowler (1997) uses an object-oriented approach. In the first step of our method, it is necessary to develop a transformation mapping for the grammar used for representing the reference model. This transformation mapping allows us to map the constructs of the used grammar onto the constructs of the BWW model. The term “construct of a grammar” refers to for example a relationship type — when using the ERM — or a class — when using the UML. The first step is based on the method for ontological evaluation of grammars proposed by Wand and Weber (1993). The transformation mapping introduces an ontological meaning for each construct of the grammar used by the reference model. The explicitly ontological definition of the transformation mapping has a beneficial effect on the objectivity of the evaluation. Without this definition it would be impossible to criticize — in an intersubjective way — a particular evaluation of a reference model conducted.
The transformation mapping consists of two mathematical mappings: first, a representation mapping describes whether and how the constructs of the BWW model are mapped onto the grammatical constructs. Second, the interpretation mapping describes whether and how the grammatical constructs are mapped onto the constructs of the BWW model. With respect to both mappings, four ontological deficiencies can be distinguished (Figure 1):2
•
Incompleteness: Can each ontological construct be mapped onto a construct of the grammar? A grammar is incomplete if the representation mapping is not defined in total. Otherwise a grammar is complete.
•
Redundancy: Can each ontological construct be mapped onto exactly one or onto more than one grammatical construct? A grammar is redundant if the representation mapping is ambiguous.
•
Excess: Can each grammatical construct be mapped onto an ontological construct? A grammatical construct is excessive if it cannot be mapped onto an ontological construct. A grammar is excessive if at least one of its constructs is excessive.
•
Overload: Can each grammatical construct be mapped onto exactly one or onto more than one ontological construct? A grammatical construct is overloaded if it can be mapped on more than one ontological construct. A grammar is overloaded if at least one of its constructs is overloaded.
Identifying Ontological Modeling Deficiencies To prepare the ontological normalization of the reference model, all ontological deficiencies of the reference models have to be identified. This is the objective of the second step. The second step is based on the previously constructed general transformation mapping. It is possible that one ontological deficiency is resolvable in various ways or even not resolvable at all. Hence, it is useful to separate the identification of ontological modeling deficiencies from the transforming step of the reference model (the next step). To identify the ontological deficiencies of the reference model all constructs of the reference model must be reviewed. Each construct of the reference model must be examined with respect to whether the construct is used correctly regarding the interpretation mapping. One of the following situations can arise:
•
Adequacy: the grammatical construct is ontologically adequate. Nevertheless an ontological deficiency can emerge by applying the grammatical construct to build the reference model. Therefore it must be examined whether the construct of the reference model is used correctly with respect to the interpretation mapping. The construct of the reference model is used adequately if it is used correctly with respect to the interpretation mapping.
Otherwise it should be marked as inadequate. For instance, a reference model contains an entity-type “color”. Furthermore, using the ERM, an entity-type should be mapped onto a BWW class regarding to an appropriate interpretation mapping. So, the entity-type “color” has to be mapped onto a BWW class. But this mapping is inadequate because the entity-type “color” represents a BWW property and not a BWW class. So, the entitytype “color” is not used correctly with respect to the interpretation mapping.
•
Excess: construct excess is a modeling deficiency in general and needs a special handling in the transformation step. So, this construct should be marked as excessive in the reference model. Construct excess occurs if implementation specific aspects are represented in the reference model, for example the technical concepts of message passing or polymorphism cannot be represented with ontological constructs.
•
Overload: construct overload is a modeling deficiency in general and needs a special handling in the transformation step. So, this construct should be marked as overloaded in the reference model. For instance, using UML, a UML object can represent a BWW thing (UML object “Mr. Miller” is an instance of the UML class customer) or a BWW class (UML objects “aclass journal”, “b-class journal”, etc., are instances of the UML class
“journal categories”). So, the construct UML object is ontological overloaded. The described step of identification of modeling deficiencies relies on the interpretation mapping. In addition, the representation mapping supports an indirect means to identify modeling deficiencies. Based on the representation mapping it can be decided whether the used grammar is incomplete or redundant. An incomplete grammar leads to inadequate representation of specific facts of reality in the reference model. This deficiency appears in models as representation of facts that cannot be adequately represented, by a grammatical construct, which is inadequate. This case will be illustrated by an example (Wand & Weber, 1993, p. 227): BWW events cannot be represented by grammatical constructs of the ERM. So, persons applying the ERM grammar tend to represent BWW events by using entity-types. This leads to the situation where entity-types are not used adequately with respect to the interpretation mapping.
Transforming the Reference Model In the third step, the reference model will be transformed to an ontological model. The outcome of this step is an ontologically normalized reference model. More formally, an ontologically normalized reference model is a mapping from the constructs of the reference model to the constructs of an ontological model. While mapping a construct of the reference model onto an ontological construct, four cases can arise:
•
Adequacy: the construct of the reference model is marked as adequate. It is possible to map this construct in a straightforward way onto a construct of the ontological model.
•
Inadequacy: the construct of the reference model is marked as inadequate. It is necessary to interpret the representation in the reference model in a sensible manner. The result of this interpretation may be that it is possible to represent this construct by a specific construct of the ontological model.
•
Excess: the construct of the reference model cannot be mapped onto a construct of the ontological model with respect to the interpretation mapping. Nevertheless it should be examined whether it is possible to represent this construct by a specific construct of the ontological model in particular.
Overload: the construct of the reference model can be mapped onto several constructs of the ontological model with respect to interpretation mapping. It is necessary to decide which interpretation mapping is preferable regarding to the interpretation of the representation in the reference model. The result of this decision may be that it is possible to represent this construct by exactly one construct of the ontological model.
The resolution of the ontological deficiencies of constructs should be guided by the intension of these constructs. This step relies on the subject’s interpretation performing the evaluation. The result of this transformation is an ontological model representing the reference model in an ontologically normalized way. The ontologically normalized model is assessed with respect to different aspects in the next step.
Assessing the Results In the last step, the reference model can be evaluated with respect to the results of the three steps mentioned previously: 1.
Assessing the transformation mapping in general.
2.
Assessing the ontological deficiencies of constructs in particular.
3.
Assessing the ontologically normalized reference model.
Isolated assessment: different metrics can be used for an isolated assessment of the ontological model. Individual and comparative metrics can be distinguished. For reasons of brevity, we give just two examples. First example: the number of BWW things can be used to measure the size of the reference model (individual metric). Second example: the complexity of events can be defined as the number of BWW events in relation to the number of theoretically possible BWW events represented in the reference model (comparative metric). The number of theoretically possible BWW events can be calculated as the square of the number of BWW states represented in the reference model. Formally:
complexity of events =
def
b.
number of BWW − events (number of BWW − states ) 2
Comparative assessment: comparative evaluations of reference models can be undertaken if further ontological models of the application domain are given. In this manner, it is possible to evaluate a reference model with respect to its completeness. Such an evaluation is possible only with respect to another ontological model.
Overview of Application Areas The proposed method can be used for several application areas:
•
Model analysis and evaluation: the method proposed could be used for the ontological analysis and evaluation of reference models. Furthermore, it can be used for evaluating application models in general. For reasons of economic efficiency, we believe this application area is limited because an ontological evaluation is expensive and application models are very specific by definition.
•
Model comparison: two or more models can be compared based on their ontologically normalized models. The compared models can be represented with the same grammar. In addition, the application of the proposed model allows comparison of models that are represented with different grammars. Results of a comparison will be that the compared models are either equivalent, complementary or in conflict. Furthermore, it is possible to introduce a measure of distance that defines the similarity of two models based on ontological constructs. Such a distance measure allows definition of ontological identity of models.
Representation of reference models in model repositories: a reference model library is a software library (Mili, Mili, & Mittermeier, 1998) containing several reference model for reuse. Nowadays modeling tools such as the ARIS toolset (Davis, 2000) use grammatical constructs or some kind of key words to represent models in a library. We propose that the constructs of an ontologically normalized reference model can be used for representing reference models. The advantage of this design is the equivalent representation of reference models independent of the grammar used.
•
Selection of an appropriate reference model: there is a lack of systematical approaches for selecting an appropriate reference model for application. We propose that a user can describe key characteristics of a reference model using the BWW model. For instance, a user is looking for a reference model comprising the BWW event “customer placed an order”. With this information all ontologically normalized reference models can be analyzed. In a second step, all relevant reference models can be further evaluated.
The next section describes an application of an ontological analysis.
Example In this section we demonstrate the usefulness of an ontological analysis by applying the method introduced above to Scheer’s reference model for production planning and control systems (PPC) (Scheer, 1994). We select this reference model as an example for several reasons:
•
The model is — compared to other models — detailed and extensive (Scheer & Hars, 1992).
• •
Scheer uses different perspectives to describe an enterprise.
•
As all reference models, the model does not cover a particular enterprise but a class of similar enterprises.
It can be assumed that the model has a wide national and international distribution. The model is first published in a German book that is in its seventh edition (Scheer, 1997). The English translation of the original book is in its second edition. Numerous courses on information systems application at German Universities teach this model. In addition, according to Scheer (2004), the model has also found many applications in industry.
According to the knowledge of the authors, this is the first analysis of Scheer’s reference model.
Scheer’s description of the reference model is based on the Architecture of Integrated Information Systems (ARIS) (Scheer, 1998a, 1998b). The modeling grammars used in ARIS have already been ontologically evaluated by Green and Rosemann (2000). Their study primarily focuses on the representation but not on the interpretation mapping. Nevertheless, we use their work as an input for defining an interpretation mapping for those modeling constructs used in Scheer’s reference model. Scheer uses different modeling languages for each view, namely the entityrelationship model (ERM) for the data view, event-driven process chains (EPC) and process chain diagrams for the control view, function trees for the function view, and organizational unit diagrams for the organization view. First, we will analyze each individual view. Finally, our analysis will focus on some intergrammar issues. For brevity, we cannot provide an in-depth ontological analysis of Scheer’s reference model, but present some interesting results analyzing the areas “primary requirements management” and “requirements planning” (Scheer, 1994, pp. 90-197) which constitute one major part of a PPC. Primary requirements are requirements figures for end products, independently salable intermediate products and spare parts. The objective of the requirements planning is to determine the in-house and outsourced parts needed to satisfy the primary requirements, to manage the inventories and to procure the outsourced parts.
Data View Figure 2 depicts a reference data model for primary requirements planning. First, an interpretation mapping has to be introduced. We propose to map an ERM entity onto a BWW thing (Wand et al., 1999, p. 506). But we do not follow to map an ERM entity type onto a BWW class as proposed by Wand et al. (1999, p. 506). Instead we apply the interpretation mapping for UML classes proposed by Evermann and Wand (2001b, p. 359) to ERM entity types. According to this argumentation, an ERM entity type is mapped onto a BWW functional schema. We do not discuss interpretation mappings for further constructs of the ERM because our analysis just focuses on entities and entity types. According to the reference model, articles are identified by article numbers (attribute PNO). Note, these article numbers should not be confused with serial numbers or something like that: a serial number allows one to unambiguously identify a single, specific article, for example the CPU with the serial number
1000 that is bought by customer X. Instead, the entity type article describes a set of articles of a specific type. Possible entities of this type are for example “CPU 1GHz”, “CPU 2GHz”, and so forth. Figure 3 depicts this interrelation between the entity type “article”, its possible instances and substantial articles. In other words instances of the entity type “article” cannot be interpreted as BWW things, but as sets of BWW things. Hence, instances of this entity type represent specific types of articles. These leads to several implications:
•
The reference model implies that articles are discrete or at least made in discrete quantities. This assumption may be problematic in process industries (Hay, 1996, p. 187).
•
Specific articles must be grouped into types or classes. This assumption is not problematic in mass production, but may be problematic in customeroriented manufacturing.
•
Specific articles cannot hold specific attributes that must be represented in the information system (e.g., inventory place of a specific article).
Possible entities of the entity type “organizational unit” are sales planning or production planning. One possible ontological interpretation of the representation chosen is that these entities represent a specific BWW thing of a specific enterprise. For instance, the organizational unit “production planning” of a specific enterprise may consists of a set of employees, specific machines and other substantial working resources. If this interpretation is agreed upon, then the user of the reference model has to define which things of the enterprise refer to specific entities of this type during the application of the reference model. On the other hand, it can be argued, that these entities do not have a factual reference, but have just a formal character. The ontological ambiguity of the reference model cannot be resolved here in general, but it has important methodological consequences in particular: following the first interpretation, it is possible to conduct empirical investigations (“Does the organizational unit ‘production planning’ consist of machine X, employee Y, etc.?”). Such verifications are meaningless if the second interpretation is followed. Possible entities of the entity type “time” are date stamps which can represent both concrete dates such as “2003-05-20” or specific periods (period 1, period 2, etc.). The entities are not BWW things. Instead, temporal aspects address a different ontological category. We argue that Scheer’s conceptualization of time is caused by the fact that the ERM grammar does not provide sufficient concepts to represent temporal aspects explicitly. Hence, it may be problematic.
Figure 3. Possible ERM entities and possible BWW things CPU 2GHz #1001
CPU 2GHz #1000
CPU 2GHz
CPU 2GHz #1002
Article type n
Legend:
CPU 1GHz
Article
Entity type Entity (example)
PNO
BWW-thing (example)
Organization View Scheer’s reference model for organizational units involved in requirements planning is depicted in Figure 4. Each oval in the model represents an organizational unit. The ontological interpretation of an organizational unit is ambiguous (Green & Rosemann, 2000, p. 81). On the one hand, an organizational unit can be mapped onto a BWW thing of a specific enterprise, for example the
organizational unit “production planning” of a specific enterprise may consists of a set of employees, specific machines and other substantial working resources (cf. the analysis of the data view previously shown). On the other hand, it can be argued that an organizational unit represents a class of BWW things and, therefore, represents a BWW class. Following the second interpretation, the organizational unit “production planning” represents all organizational units of an enterprise that are responsible for the planning of the production, for example production planning in plant 1, plant 2, and so forth. These different ways of interpretations have following consequences: organizational charts in conjunction with EPC are used to assign responsibilities to organizational units. So, if the second interpretation is followed, it is not possible to exactly assign some responsibilities to a specific organizational unit, for example the responsibility of the function “estimate gross requirements” cannot be assigned to the organizational unit “production planning in plant 1” because the organizational chart represents classes of organizational units, but not specific instances. We admit that such assignments can be made in further textual descriptions or annotations of the model. But it is not possible to express such assignments using this modeling grammar. Scheer is aware of this interpretation ambiguity and distinguishes organizational diagrams on the type level and on the instance level (Scheer, 1998b, pp. 53f). However, the intended interpretation is not stated explicitly in the reference model and may result in confusion.
Figure 5. Part of the reference function model for requirements planning (Scheer, 1994, p. 160) Requirements planning
Bill of materials management
Primary requirements management
ABC analysis
Consumptionbased requirements planning
Time series analysis
Requirements explosion
Forecast evaluation
Requirements tracking
Lot sizing
Inventory management
Management of forecast models
portion of the semantic of BWW transformations: The domain and co-domain of the BWW transformation, the mapping between domain and co-domain, and the BWW thing to which the BWW transformation belongs are not deducible from the function tree. So, the function model has only a vague ontological meaning. Furthermore, the interrelations between the functions represented in one function tree are unclear. Do the sub-functions of one function complement each other? Or are they substitutable? For example, the functions “ABC analysis” and “time series analysis” seem to be substitutable, but the functions “primary requirements management” and “inventory management” are clearly not substitutes. For a user of the reference model, this information is quite important because, in a specific implementation environment, it is not necessary to implement all functions of a reference model but rather those functions that are essential for the application intended. This information is not represented in the function tree.
Control View The control view describes the relationships between the data, function and organization view. Figure 6 depicts an EPC for the requirements explosion process (Scheer omits the relationships to the data and organization view for reasons of clarity). Events of an EPC can be ontologically interpreted as BWW states and functions as BWW transformations (see previous discussion). An ontological analysis of the reference model considered reveals the following deficiencies:
According to the interpretation mapping, events are mapped onto BWW states. By definition, each BWW state consists of a set of values that represent a BWW thing. But a BWW thing is not defined by the EPC, so the ontological meaning of the events defined is unclear. Furthermore, the system and system environment respectively the system boundaries are not clear.
•
Events, which can be interpreted as a BWW stable event, do not exist. So, there is no clear-cut condition when or whether the depicted process terminates.
•
Obviously, some functions require some user interaction, for instance the functions “Lot sizing” or “Forward Scheduling” can run interactively (Scheer, 1994, pp. 190f). However, these BWW couplings are not stated in the reference model.
Summary In this section an ontological analysis is demonstrated by applying this method to parts of Scheer’s reference model for production planning and control. Our analysis focuses on the identification of ontological deficiencies, on possible ways to transform the reference model to an ontological model, and on explicating assumptions of the reference model that are implicitly made by its developer. Because of several ontological deficiencies it is obvious, that it is not possible — without making a number of further assumptions — to transform the reference model to an ontological model which is Bunge-complete. Furthermore, we did not explicitly introduce an ontological model of the reference model, hence we cannot define some sensible model metrics. Also, we do not compare several ontological models.
company producing large quantities of specific product types, where each product is made in discrete quantities. An ontological analysis is not an objective procedure or an algorithm that can be codified in some program language and processed automatically. Instead, it relies on the reference model analyst’s interpretation of modeling constructs. This interpretation is to a certain degree subjective. So, it is necessary that the interpretation’s rationale is made explicit and justified by specific reasons. Because reference models are representations of empirical systems that are not formalized by principle, we believe this limitation is tenable. An ontological evaluation assumes that constructs of a modeling language primarily represent things or properties of things. According to Lyytinen (1985, p. 63), this language view is strongly influenced by the Fregean theory of language. However, there exists other language theories founded on quite different assumptions. For instance, speech act theory assumes that sentences represent specific speech acts such as beliefs, requests, explanations and so forth. This view leads to a different understanding of a conceptual model (Hirschheim, Klein, & Lyytinen, 1995, pp. 154-170; Klein & Lyytinen, 1992). From the speech act theory point of view, an ontological analysis and evaluation does not make sense. Further critiques can be directed to the ontological and epistemological assumptions of this approach (Schütte & Zelewski, 2001, p. 3). This study takes the view that the external world exists autonomously (Bunge, 1977, pp. 16f) and scientific research — in particular, reference modeling — aims at representing reality. Furthermore, observer’s perception of the world is limited and can be deceptive, so complete truth is hard to archive (Bunge, 1983, pp. 264-271). This world view (“Weltanschauung”) can be called scientific realism (Bunge, 1993, pp. 231-232). There exists other world views which can be used as an foundation for conceptual modeling (Schütte, 1999). From other worldviews, an ontological evaluation may be not reasonable. However, the basic steps of an ontological analysis can be performed using other ontological assumptions, for example, the analysis in Milton (2000) uses Chisholm’s ontology. So, it would be interesting to use different ontological and epistemological assumptions to conduct ontological analysis of reference models and to compare their results. Furthermore, we point out that an ontological evaluation is not inherently superior to other evaluation approaches. This approach implies that the reference model is represented in a (semi-)formal grammar. In addition, there are other evaluation criteria that are not addressed by an ontological evaluation (Frank, 1998, pp. 68). For instance, from a teach- and learn-oriented point of view, facts about enterprises represented in reference models should be understandable, or, from an enterprise-oriented point of view, the purchase and usage of a reference model should make the development of enterprise systems more efficient.
Instead an ontological evaluation focuses on criteria such as completeness, precision, and consistency. So, we believe that reference models should be analyzed and evaluated from different perspectives. We see several areas for further research: first, the proposed method should be applied to analyze and evaluate further reference models. By doing so, model’s quality can be studied and guaranteed. Second, our approach is based on the BWW model. Further investigations should examine the usefulness of other ontological assumptions. Third, in this chapter we only outline some application areas of an ontological evaluation. These and further areas should be examined in more detail. Fourth, ontological evaluations of reference models should be complemented with evaluation from other perspectives (for established examples see Fettke & Loos, 2003b). To conclude, we believe that this chapter and suggested further research provide a better understanding of reference model quality and insights that lead, in the long-term, to a theory of enterprise modeling.
References Bodart, F., Patel, A., Sim, M., & Weber, R. (2001). Should optional properties be used in conceptual modelling? A theory and three empirical tests. Information Systems Research, 12(4), 384-405. Bunge, M. (1977). Ontology I: The furniture of the world. Dordrecht, Holland: Reidel. Bunge, M. (1983). Epistemology and methodology II: Understanding the world. Dordrecht, Holland: Reidel. Bunge, M. (1993). Realism and antirealism in social science. Theory and Decision, 35, 207-235. Davis, R. (2000). Business process modelling with ARIS: A practical guide. Berlin: Springer. Evermann, J., & Wand, Y. (2001a). An ontological examination of object interaction in conceptual modeling. Proceedings of the 11th Workshop on Information Technologies and Systems (WITS 2001), New Orleans, December 15-16. Evermann, J., & Wand, Y. (2001b). Towards ontologically based semantics for UML constructs. In H. S. Kunii, S. Jajodia, & A. Sølvberg (Eds.), Conceptual modeling — ER 2001 — 20th International Conference on Conceptual Modeling, Yokohama, Japan, 27-30 November 2001, (pp. 354-367). Berlin, Heidelberg: Springer.
Krogstie, J. (1995). Conceptual modeling for computerized information systems support in organizations. Unpublished PhD thesis, University of Trondheim. Kruse, C., Hars, A., Heib, R., & Scheer, A. W. (1993). Ways of utilizing reference models for data engineering in CIM. International Journal of Flexible Automation and Integrated Manufacturing, 1(1), 47-58. Lindland, O. I., Sindre, G., & Sølvberg, A. (March 1994). Understanding quality in conceptual modeling. IEEE Software, 42-49. Lyytinen, K. (1985). Implications of theories of language for information systems. MIS Quarterly, 9(1), 61-74. Mertins, K. & Bernus, P. (1998). Reference models. In P. Bernus, K. Mertins, & G. Schmidt (Eds.), Handbook on architectures of information systems (pp. 615-617). Berlin, Heidelberg: Springer. Mili, A., Mili, R., & Mittermeier, R. T. (1998). A survey of software reuse libraries. Annals of Software Engineering, 5, 349-414. Milton, S. (2000). An ontological comparison and evaluation of data modelling frameworks. Unpublished PhD thesis, University of Tasmania, Hobart, Australia. Mišic, V. B., & Zhao, J. L. (2000). Evaluating the quality of reference models. In A. H. F. Laender, S. W. Liddle, & V. C. Storey (Eds.), Conceptual modeling — ER 2000 — 19th International Conference on Conceptual Modeling, Salt Lake City, Utah, 9-12 October 2000, (pp. 484-498). Berlin, Heidelberg: Springer. Moody, D. L. & Shanks, G. G. (2003). Improving the quality of data models: Empirical validation of a quality management framework. Information Systems, 28, 619-650. Mylopoulos, J. (1998). Information modeling in the time of the revolution. Information Systems, 23(3/4), 127-155. Opdahl, A. L. & Henderson-Sellers, B. (2001). Grounding the OML metamodel in ontology. The Journal of Systems and Software, 57(2), 119-143. Opdahl, A. L. & Henderson-Sellers, B. (2002). Ontological evaluation of the UML using the Bunge-Wand-Weber model. Software and Systems Modeling, 1(1), 43-67. Rohde, F. (1995). An ontological evaluation of Jackson’s system development model. Australian Journal of Information Systems, 2(2), 77-87. Scheer, A. W. (1994). Business process engineering – Reference models for industrial enterprises (2 nd ed.). Berlin, Heidelberg: Springer. Scheer, A. W. (1997). Information systems – Reference models for industrial business processes (7th ed.). Berlin, Heidelberg: Springer (in German).
Scheer, A. W. (1998a). ARIS — Business process frameworks (2 nd ed.). Berlin, Heidelberg: Springer. Scheer, A. W. (1998b). ARIS — Business process modeling (2nd ed.). Berlin, Heidelberg: Springer. Scheer, A. W. (2004). 20 years designing industrial business processes (in German). Industrie Management, 20(1), 11-18. Scheer, A. W. & Hars, A. (1992). Extending data modeling to cover the whole enterprise. Communications of the ACM, 35(9), 166-172. Scheer, A. W. & Nüttgens, M. (2000). ARIS architecture and reference models for business process management. In W. van de Aalst, J. Desel, & A. Oberweis (Eds.), Business process management — Models, techniques, and empirical studies (pp. 376-389). Berlin, Heidelberg: Springer. Schuette, R. & Rotthowe, T. (1998). The guidelines of modeling — An approach to enhance the quality in information models. In T. W. Ling, S. Ram, & M. L. Lee (Eds.), Conceptual modeling — ER ’98 — 17th International Conference on Conceptual Modeling, Singapore, 16-19 November 1998, (pp. 240-254). Berlin, Heidelberg: Springer. Schütte, R. (1998). Guidelines of reference modeling — Constructing configurative and adaptable models. Wiesbaden: Gabler, (in German). Schütte, R. (1999). Architectures for evaluating the quality of information models — A meta and object level comparison. In J. Akoka, M. Bouzeghoub, I. Comyn-Wattiau, & E. Métais (Eds.), Conceptual modeling — ER ’99 — 18th International Conference on Conceptual Modeling, Paris, 1518 November 1999, (pp. 490-505). Berlin, Heidelberg: Springer. Schütte, R. & Zelewski, S. (2001). Epistemological problems in working with ontologies (Working paper No. 13). Essen: Universität Essen, Institut für Produktion und Industrielles Informationsmanagement. van Belle, J. P. & Price, B. (2000). A proposed framework for evaluating generic enterprise models. South African Computer Journal, 26, 69-76. van Belle, J. P. W. G. D. (2003). A framework for the analysis and evaluation of enterprise models. Unpublished PhD thesis, University of Cape Town, Cape Town, South Africa. Wand, Y., Storey, V. C., & Weber, R. (1999). An ontological analysis of the relationship construct in conceptual modeling. ACM Transactions on Database Systems, 24(4), 494-528. Wand, Y. & Weber, R. (1989). An ontological evaluation of systems analysis and design methods. In E. D. Falkenberg & P. Lindgreen (Eds.), Information systems concepts: An in-depth analysis (pp. 79-107). North-Holland: Elsevier Science Publishers.
Wand, Y. & Weber, R. (1990a). An ontological model of an information system. IEEE Transactions on Software Engineering, 16(11), 1282-1292. Wand, Y. & Weber, R. (1990b). Toward a theory of the deep structure of information systems. Paper presented at the International Conference on Information Systems, Copenhagen, Denmark, December 16-19, (pp. 61-71). Wand, Y. & Weber, R. (1993). On the ontological expressiveness of information systems analysis and design grammars. Journal of Information Systems, 3(4), 217-237. Wand, Y. & Weber, R. (1995). On the deep structure of information systems. Information Systems Journal, 5, 203-223. Wand, Y. & Weber, R. (2002). Research commentary: Information systems and conceptual modeling — A research agenda. Information Systems Research, 13(4), 363-377. Weber, R. (1996). Are attributes entities? A study of database designer’s memory structures. Information Systems Research, 7(2), 137-162. Weber, R. (1997). Ontological foundations of information systems. Melbourne: Coopers & Lybrand. Weber, R. & Zhang, Y. (1991). An ontological evaluation of NIAM’s grammar for conceptual schema diagrams. Paper presented at the International Conference on Information Systems, New York, New York, 16-18 December, 1991. Weber, R. & Zhang, Y. (1996). An analytical evaluation of NIAM’s grammar for conceptual schema diagrams. Information Systems Journal, 6, 147170.
Endnotes 1
This PhD thesis is written in German. An overview of this approach in English is given in Schuette and Rotthowe (1998).
2
For systematical reasons, we introduce these terms in a slightly different manner than in Wand and Weber (1993).
Introduction Information systems (IS) are representations of a real world domain. For example, the software and database structures of an inventory IS should reflect the layout of the warehouses with their aisles, shelves and bins. Changes in the data managed by the inventory IS should mirror actual changes of inventory in the warehouse. The structures of a production planning and control (PPC) system should reflect the type of equipment and material on the factory floor. Changes in the data in the PPC system should mirror actual changes of work items and equipment. Information systems are also situated in and affect the real world domain. The inventory system is used for making decisions about stock levels, purchasing and so forth. It is embedded in and affects the business. The production planning and control system is used to make decisions about production schedules, equipment changes and so forth. It also is embedded in and affects the business. For these reasons it is essential that any IS development project begin by examining the real-world domain represented and affected by the IS. Hence, the first phase of IS development, the analysis phase, is concerned with describing this real world domain through conceptual models. These models are descriptions of the real world independent of any information system or information technology aspect. Their purpose is two-fold: 1) to serve as communication medium for understanding of the domain, and 2) to serve as a guide for IS design (Kung & Solvberg, 1986). The next phase of IS development — IS design — is concerned with describing the information system through design models. Design models are intended to model the software system. Thus, one of the primary differences between conceptual and design models is the object of modelling. For the former, the object of modelling is the real world, for the latter it is the software system. While this difference is widely recognized, the lack of languages specific to conceptual modelling, combined with the availability of widely used IS design languages has a number of detrimental effects: 1.
Many IS development projects begin without explicitly modelling the real world domain that the IS is intended to represent. Instead, different stakeholders and developers may hold implicit assumptions about the domain.
2.
Even when the real world organization is explicated, the use of IS design languages for this task without specific guidance can lead analysts to confuse aspects of the IS and the real world. For example, an analyst may talk about jobs in the organization as objects, with the implicit understanding
that they will be represented by a specific class in the object-oriented software system. 3.
The translation between conceptual and design model is not explicated. This lack of explicit translation can again lead to hidden assumptions made by different stakeholders and developers.
languages are able to express real-world business domains, initial research by Evermann and Wand (2001b); Evermann and Wand (2001a) tells us how they should be used, by providing guidelines to the modelling of business and organizations using IS design languages. What has been missing is a demonstration of how this research and these guidelines may be applied, and the differences that can arise by rigorously maintaining a real-world focus, rather than a software focus, in modelling. Such a demonstration can serve to highlight two important results: 1.
It shows a clear difference between two very different types of models. On the one hand are models generated with an implicit but not articulated background of IS development. These models are often termed analysis or conceptual models by their developers, but are produced before the implicit background of IS design and implementation. On the other hand are models developed by specifically excluding any IS considerations and critically examining the real world.
2.
It shows that proposed ontological semantics and rules are applicable in practice and that they can lead to useful outcomes. Thus, practitioners are able to immediately put this research into practice.
The purpose of this chapter is to provide an introduction to the process of developing modelling rules and to show their application, without burdening the reader with the technical intricacies of ontological language analysis. Consequently, a number of modelling rules are provided for the reader in the appendix to the chapter, while the remainder of the chapter begins with an introduction to using ontologies for deriving modelling rules. This is followed by an example showing how a focus on the business can be achieved by the application of ontologically derived modelling rules. The example emphasizes the differences between models developed with and without applying ontologically derived rules. The chapter closes with a general discussion.
Assigning Real-World Semantics In order to describe the real world system in a model, we must specify what exists in this world. This is done by employing ontologies (Sowa, 2000). The term “ontology” in its original philosophical sense is understood as meta-physics or the philosophy of existence (Angeles, 1981). Adoption of a specific ontology is a fundamental philosophical commitment to the belief in the existence of certain entities in the world, including those in business and organizational domains.
In this philosophical interpretation, the choice of any specific ontology is a most fundamental philosophical choice. As such, it cannot be theoretically justified or debated a-priori. The chosen ontology is the framework and foundation that enables one to carry out science and research (Kuhn, 1996) and can only be assessed based on the results of that research. In other words, if the results of the science conducted on the basis of the ontological foundation “make sense”, the ontological foundation is justified. For example, assuming an ontology in which the business consists of actors with goals and intentions allows one to build models or theories with these concepts. Another ontology of the business may specify it as comprising work patterns, functional units and processes. Which ontology is “true” is undecidable. Both may be tenable as a matter of their suitability for the purpose of inquiry. This depends on the success of the models built on them. It may turn out that theories built on top of one ontology, for example actors, goals and intentions, are able to explain more phenomena than a competing ontology, for example work patterns, functional units and processes. In this case, there would be good reason to adopt one over the other. However, this can only be decided in light of the research results based on the two ontologies. (It may also be the case that the two ontologies turn out to be a higherlevel and a lower-level one, which can be reconciled and integrated.) This philosophical understanding of ontology contrasts with that in artificial intelligence (AI), knowledge engineering (KE) and computer science research where ontologies are understood in a subjective or constructivist nature (Uschold & Gruninger, 1996; Noy & Hafner, 1997). Ontologies are constructed as needed (Gruninger & Lee, 2002; Holsaple & Joshi, 2002). They are not universal, but can be changed, adapted and customized to fit a specific purpose or domain (Gruninger & Lee, 2002). Specifically, the relation to what might be called real world has been severed: Most of AI chose not to consider the work of the much older overlapping field of philosophical ontology, preferring instead to use the term “ontology” as an exotic name for what they’d been doing all along in knowledge engineering ... It became correspondingly more remote from anything which might stand in a direct relation to existence or reality. (Smith & Welty, 2001, p. 5) A return to philosophical ontology has been argued for, for example in Guarino and Welty, (2002, p. 61): The computer science use of the term “ontology” ... is taken as nearly synonymous with knowledge engineering in AI, conceptual
modelling in databases, and domain modelling in OO design. We believe it is important ... to maintain that “ontology” is not simply a new word for something computer scientists have been doing for 20 to 30 years; ontology is hundreds, if not thousands, of years old, and there are many lessons learned in those centuries that we may borrow from philosophy along with the terms. Conceptual modelling research (Wand, 1989; Wand & Weber, 1993) has taken up this call and focussed on the use of a particular ontology by Bunge (1977, 1979) and introduced to IS research by Wand and Weber (1990) (called the BWW ontology). This ontology “is in line with an old and noble if maligned tradition: that of pre-Socratic philosophers, Aristotle, Thomas Aquinas, Descartes, ... Pierce, Russell, and Whitehead” and based on “the ontological presuppositions of contemporary scientific research, topped with new hypotheses compatible with the science of the day” (Bunge, 1977, p. 13). For lack of possible a-priori justification, we advance pragmatic reasons for the adoption of this ontology for the modelling of business and organizational domains. The BWW ontology has been applied in a number of studies related to modelling in IS (Evermann & Wand, 2001a; , 2001b; Opdahl & HendersonSellers, 1999; Opdahl et al., 1999; Opdahl & Henderson-Sellers, 2001, 2002; Parsons & Wand, 1991, 1997; Wand & Weber, 1989, 1990, 1993; Wand, Storey, & Weber, 1999). These studies have successfully examined and evaluated modeling languages and the object-oriented modeling approach. More importantly, empirical studies conducted by Bodart and Weber (1996), Bodart, Sim, Patel, and Weber (2001), Cockroft and Rowles (2003), Evermann (2003), Gemino (1999), Gemino and Wand (2001), and Weber and Zhang (1996) have led to useful, sensible, and relevant outcomes. They have validated this ontology in a variety of business domains. The concepts of the BWW ontology are discussed in the introductory chapter to this book and are therefore not repeated here.
Mapping Assigning ontological or real-world meaning to a language amounts to answering two questions (Wand & Weber, 1993): 1.
How can an element of the real-world domain (ontological concept) be represented in the chosen language?
To answer this question we propose a representation mapping from the set of ontological concepts into the set of language constructs, which assigns each ontological concept a language construct with which to represent it. 2.
How can a construct of the language be interpreted in terms of a realworld domain (ontologically)?
To answer this question we propose an interpretation mapping from the set of language constructs into the set of ontological concepts, which assigns each language construct an ontological interpretation. Together, these mappings assign real world, ontological semantics to a modelling language. Constructing a model, they inform us how the domain should be represented. Reading a model, they tell us how the model should be interpreted. Mappings of the BWW ontology to UML can be found in Dussart et al. (2002), Evermann and Wand (2001b, 2001a), and Opdahl and Henderson-Sellers (2002). Generally, these works agree on a common mapping of the basic concepts. For example, BWW things are mapped to BWW objects, BWW properties to UML attributes, and BWW states to UML states. This research shows that overall, UML is a very expressive language that is capable of expressing any type of realworld domain.
Transfer of Assumptions Once the ontological semantics are assigned — that is, language constructs are mapped to ontological concepts, the mappings can be used to transfer ontological assumptions to the language. An ontology may suggest that certain situations are possible in the real world while others are not. By virtue of the mappings, some combinations of language elements may therefore describe possible real world situations while others may describe impossible ones. Thus, if there are rules or constraints that relate ontological concepts, then, in order for the model to describe only possible real worlds, these same rules or constraints must also hold between the mapped language constructs. Hence, the ontological mapping can lead to modelling rules on how to use the language for conceptual modelling. An analysis of UML in this way has begun (Evermann & Wand, 2001b, 2001a) and is being extended to cover all of UML. A number of proposed rules are shown in the appendix to this chapter. For the sake of brevity, the technical intricacies of the analysis are omitted, here we discuss briefly two example rules.
The application of this method has led to two types of rules. Rule 1 is an example of mapping rules, formalizing the mapping of ontological concepts to UML constructs. These rules relate ontological concepts and language constructs. Corollary 2 is an example of language rules. These rules relate two or more language constructs. They are the result of transferring ontological assumptions. For example, an association class is interpreted as a bundle of ontological mutual properties (mapping). Ontological mutual properties cannot effect change, only the things that they are properties of can effect change (ontological assumption). Ontological change is represented by UML methods or operations (mapping). Hence, association classes must not possess methods or operations (transfer of assumption). The remainder of the rules and corollaries in the appendix are derived in a similar fashion. As UML is a multi-perspectival language, each complete UML model consists of a number of diagrams, for example a class diagram and a number of state charts. UML constructs of various diagrams might map into related ontological constructs. Hence, language rules may be intra- as well as inter-diagram rules; the latter ensure the integrity of the different modelling perspectives. The derivation of the rules depends critically on the mapping. This research is based on the mappings proposed in (Dussart et al., 2002; Evermann, 2003; Opdahl & Henderson-Sellers, 2002) which agree for most important concepts. However, once a mapping is assumed as correct, the rules follow directly from it. The mapping itself may be tested by applying the rules and determining their benefits empirically. Hence, this chapter can serve to support the assumed mapping. There are two important things to note. First, the suggested rules and guidelines can serve to reduce semantic ambiguity in conceptual modelling (Wand et al., 1999), but might not be obvious or applicable when the language is used for IS or software design purposes only. They are intended for the business modeller, the software modeller is not constrained by them. Second, it is important to note that such rules do not necessarily guide us how to perceive the world. They will not tell us how to go about identifying entities and features of the business or the organization. However, once they are identified, the rules can tell us how to properly model them.
Scope of Mappings The mapping of a language to an ontology is arbitrary to a certain degree. Think of natural languages: the French word “chien” represents the same ontological concept as the English word “dog”, yet both mappings must be considered
equally correct. One pragmatic criterion that may be applied is the commonly accepted use of the language or language construct. If the word “dog” were assigned a different meaning, the use of that word would no longer follow generally accepted principles. Similarly, mapping UML states to BWW things is a possible mapping, but not a good one, according to this criterion. When analysts talk about states, they have different concepts in mind than when they talk about things. Hence, any assignment of semantics to language constructs should not be done individually for each construct. Instead, it should be done for the whole language as an interconnected set of constructs, not as a loose set of symbols. Moreover, the interpretation and representation mappings should attempt to preserve the relationships among language constructs, whether they are formal syntactic constraints or exhibited in common usage. For example, consider the UML construct “object”. UML suggests that each object may have a UML construct “state” associated with it. Any mapping of “object” and “state” should attempt to preserve this relationship between the concepts to which “object” and “state” are mapped in the ontology. If necessary, different mapping must be suggested for “objects” and “states” in different contexts. The alternative, individual mapping of constructs, disregarding any relationships between them, may lead to simpler representation and interpretation mappings. However, the relationships between the language constructs may not match the relationships between the ontological concepts they are mapped to. Hence, the language must be modified by dropping or altering the relationships between the language constructs. However, a different mapping may exist which preserves the relationships within the language and also matches them with relationships in the ontology. Hence, care must be taken to examine all implications of the mapping, to ensure that the language is not altered more than necessary. It must still retain the original characteristics that IS designers require for software modelling and with which they are familiar with. In summary, ontological semantics may modify the language slightly, not change it beyond recognition. Figures 1 through 4 show a summary of the process of ontological analysis and derivation of rules. First, the relevant ontological concepts and language constructs are identified (Figure 1). As a second step, both representation and interpretation mappings are proposed (Figure 2). Third, relationships between ontological concepts are identified (Figure 3). Fourth and last, these are then transferred to those language constructs that are mapped to the ontological concepts for which these relationships hold (Figure 4), thereby generating modelling rules. These rules constrain the use of the language in such a way as to allow only the modelling of possible real-world situations.
Figure 4. Step 4: Transfer ontological relationships by virtue of mappings, thereby deriving modelling rules
Ontology
UML
Example This section demonstrates the proposed ontological semantics of UML using an example taken from a popular systems analysis textbook. The next paragraph provides the description given in Hoffer, George, and Valacich (2002), followed by an analysis of the given model with respect to the proposed rules. The case is then re-analyzed to derive a conceptual model conforming to the proposed rules and thus possessing ontological semantics and real world meaning.
Description The following is the description of the case given in Hoffer et al. (2002), leaving room for interpretation: An auto rental company wants to develop an automated system that would handle car reservations, customer billing, and car auctions. Usually a customer reserves a car, picks it up, and then returns it after a certain period of time. At the time of pick up, the customer has the option to buy or waive collision insurance on the car. When the car is returned, the customer receives a bill and pays the specified amount. In addition to renting out cars, every six months or so, the auto rental company auctions the cars that have accumulated over 20,000 miles. (p. 702f)
Figure 5. Car rental example class diagram (Miller, 2002) Car Customer name address
*
vin make mode l typ e miles
1..*
Auction Sale 1
0 ..1
sellingPrice
Reservation pickupDate returnDate locatio n insurance milesTraveled corpCustomer?
Invoice
1
invoiceNumber invoiceDate 0..1 invoiceAmount
createBill()
The suggested class diagram for this case, taken from Miller (2002) is shown in Figure 5.
Analysis of Rule Conformance Since “invoice” and “auction sale” do not represent substantial things, they violate rule 1. While an actual invoice on paper may be a substantial thing in the sense that it can be physically handled and manipulated, invoices are conveyed by electronic mail, as records in EDI communications, or are conveyed by telephone or fax. In all of these cases, invoicing is an interaction as the result of which money is owed to one party by another. Invoicing and auction sales are therefore events or interactions, not objects, even though there may exist documentation about invoices or auction sales. While the “reservation” class is a bundle of mutual properties between two things and thus correctly modelled according to rule 3, it violates corollaries 2 and 4 and the method “createBill()” should be modelled with the class representing the thing that actually does the invoicing, probably an employee or, more general, the rental company (rule 4). From the fact that the attribute “corpCustomer?” is modelled, it may be assumed that reservations for corporate customers are different from reservations for other — that is, non-corporate, customers. Hence, according to rule 6, the corporate customers should be modelled explicitly. The associations between “auction sale” and “car” and between “invoice” and “reservation” violate rule 13 because they are not association classes.
that car cannot be returned again, therefore it must not inherit that operation from the rented car. We have also renamed the renting customer to “RentalCustomer” in anticipation of a purchasing customer later in the analysis. The next interaction occurs when an employee provides an invoice to the customer, giving rise to mutual properties such as “amount due” and so forth. These are captured by the association class “invoice” as shown in Figure 9. Cars are also sold at auction to customers. Every such sale gives rise to mutual properties between the car rental company (or an employee thereof), the car and the purchasing customer. We model purchasing customers as a different subclass of customers as they have different (mutual) properties. We also include an operation with all customers by which change of classification (qualitative change) can occur. Similarly, an operation is included with all returned cars that expresses the qualitative change of a car when it is sold. Figure 8. Car rental example: Class diagram, returning a car Car Custome r Name Addres s ReserveCar PickUpCar
RentalCustome r Name Address
ReturnedCar 1..n
1
MilesIn
ReturnCar CarReturn
VIN Make Mode l Typ e Miles BeScheduled
Date Locatio n MilesTravelled
Figure 9. Car rental example: Class diagram, billing the customer Reservatio n P\ickupDate ReturnDate PickupLocatio n ReturnLocatio n
Discussion The final class diagram in Figure 10 reflects the focus on the real world that was the basis of our analysis. Instead of being guided or influenced by IS requirements, we have examined real world things and real world interactions. The resultant model shows more detail than the initial one in Figure 5. This may be due to the fact that IS models generally abstract away aspects that are not relevant to the purpose of the IS. However, often these abstractions are made implicitly. For example, in our model it is possible to identify the status of a car or the employees responsible for certain actions. The modeller of the original model may or may not have intended to abstract away this information. If intended, such an abstraction should be made explicit. Our analysis of the case also shows that the proposed rules can serve as a rough guide to the analysis of the business or organization, but they do not constitute a process. They constrain, but do not determine, the ontologically valid models for a particular real-world domain. By following these guidelines, the modeller or analyst is forced to discover and explicate certain aspects of the real world and to question his or her understanding of the business or organization: Are certain entities really objects (e.g., is “rental” really an object? ) or are they interactions? Are certain entities really attributes (is the employee handing over the car really an attribute of “rental contract”? ), and so forth.
General Discussion This chapter has shown how languages originally developed for IS design can be applied to the modelling of business and organizational domains. By providing real-world semantics to constructs of such languages, a number of relationships and constraints can be transferred from an ontology to the language, leading to usage rules specific to modelling real-world domains. These rules force the modeller to think ontologically — that is, focus on the business and specifically exclude any IS considerations. The rules presented in this chapter only constrain the modelling language, they do not extend it. Consequently, the modelling language, together with the modelling rules, is still fundamentally the familiar UML and retains all objectoriented characteristics. Hence, any model that conforms to the proposed rules remains a valid UML model. This is an important property as it enables assignment of software as well as real-world semantics.
While the language constructs retain their usual implementation related meaning, they acquire additional real-world semantics. Thus, the same model becomes interpretable by two different audiences: business analysts and management can interpret the model ontologically, while programming staff can interpret the model to derive a suitable software system representing the described business. Improved communication between business and technical staff was one of the main motivations for this research. A conceptual model conforming to ontological rules can further this by being the means for this communication. Business staff and technical analysts can both talk about “objects” and “attributes” and “associations” but with different meaning associated with these terms. To the business person, these mean physical things and their properties, while to the technical analyst they mean certain software or database structures. The example in this chapter shows that different questions need to be asked by the modeller (and answers found) when modelling business domains. The proposed guidelines can encourage this critical examination of the domain and the model. The example in this chapter shows that modelling according to the proposed rules leads to a substantially different model which explicates the often implicit assumptions made by IS development staff. A number of extensions to this research are possible. The proposed rules may be formalized to make them suitable for formal support in CASE (computer aided software engineering) tools. Most modern CASE tools are built on a model repository, which can be thought of as a formal meta-model of the language in question. Rules can be built into such a repository to ensure conformance during the analysis process. Moreover, if it was possible to describe the ontology in the same meta-modelling language used for the formal language meta-model, formal techniques from schema-matching research (Batini, Lenzerini, & Navathe, 1986; Rahm & Bernstein, 2001) could then be applied to identify commonalities and differences and provide a more formal underpinning of the mapping and rule derivation. Finally, the rules proposed here have proven useful for the limited example presented in this chapter. Future research must examine the following two issues: first, it must be ensured that rules are applicable in realistic settings. To this effect, case study research in organizations and system development projects can help to further our understanding about real-world conceptual modelling. Second, the benefit of such modelling rules in terms of the specific advantages of the models must be determined. In the introduction we suggested that one of the purposes of conceptual models is to further domain understanding. This may be examined by controlled experimental studies measuring this specific effect. The ultimate benefit will be the construction of better information systems —
systems that reflect the organization and integrate well with their organizational environment.
References Angeles, P. (1981). Dictionary of philosophy. New York: Harper Perennial. Batini, C., Lenzerini, M., & Navathe, S. (1986). A comparative analysis of methodologies for database schema integration. ACM Computer Surveys, 18(4). Bodart, F., Sim, M., Patel, A., & Weber, R. (2001). Should optional properties be used in conceptual modelling? A theory and three empirical tests. Information Systems Research, 12(4), 384-405. Bodart, F. & Weber, R. (1996). Optional properties versus subtyping in conceptual modeling: A theory and empirical test. Proceedings of the International Conference on Information Systems, 16-18 December 1996, (p. 450). Bunge, M. A. (1977). Ontology I: The furniture of the world: Volume 3: Treatise on Basic Philosophy. Dordrecht, Holland: Reidel. Bunge, M. A. (1979). Ontology II: A world of systems: Volume 4: Treatise on basic philosophy. Dordrecht, Holland: Reidel. Cockroft, S. & Rowles, S. (2003). Ontological evaluation of health models: Some early findings. Proceedings of the 7th Pacific Asia Conference on Information Systems, Adelaide, Australia, 10-13 July, (pp. 611-625). Dussart, A., Aubert, B. A., & Patry, M. (2002). An evaluation of interorganizational workflow modeling formalisms. Working paper, Ecole des Haute Etudes Commercials, Montreal. Evermann, J. (2003). Using design languages for conceptual modelling: The UML case. PhD thesis, University of British Columbia, Canada. Evermann, J. & Wand, Y. (2001a). An ontological examination of object interaction in conceptual modeling. Proceedings of the Workshop on Information Technologies and Systems WITS’01, New Orleans, December 15-16, 2001, (pp. 91-96). Evermann, J. & Wand, Y. (2001b). Towards ontologically based semantics for UML constructs. In H. Kunii, S. Jajodia, & A. Solvberg (Eds.), Proceedings of the 20th International Conference on Conceptual Modeling ER2001, Yokohama, Japan, 27-30 November 2001, (pp. 354-367).
Parsons, J. & Wand, Y. (1997). Using objects for systems analysis. Communications of the ACM, 40(12), 104-110. Rahm, E. & Bernstein, P. A. (2001). A survey of approaches to automatic schema matching. The VLDB Journal — The International Journal on Very Large Databases, 10(4), 334-350. Smith, B. & Welty, C. (2001). Ontology: Towards a new synthesis. Proceedings of the Second International Conference on Formal Ontology and Information Systems, FOIS’01, Qgunquit, Maine, 17-19 October (pp. 34). Sowa, J. F. (2000). Knowledge representation: Logical, philosophical, and computational foundations. Pacific Grove, CA: Brooks Cole. Uschold, M. & Gruninger, M. (1996). Ontologies: Principles, methods and applications. Knowledge Engineering Review, 11(2), 93-155. Wand, Y. (1989). A proposal for a formal model of objects. In W. Kim & F. Lchovsky (Eds.), Object-oriented concepts, languages, applications and databases (pp. 537-559). Boston, MA: ACM Press/AddisonWesley. Wand, Y., Storey, V. C., & Weber, R. (1999). An ontological analysis of the relationship construct in conceptual modeling. ACM Transactions on Database Systems, 24(4), 494-528. Wand, Y. & Weber, R. (1989). An ontological evaluation of systems analysis and design methods. In E. Falkenberg & P. Lingreen (Eds.), Information system concepts: An in-depth analysis. North-Holland: Elsevier Science Publishers. Wand, Y. & Weber, R. (1990). Mario Bunge’s ontology as a formal foundation for information systems concepts. In P. Weingartner & G. Dorn (Eds.), Studies on Mario Bunge’s Treatise. Atlanta: Rodopi. Wand, Y. & Weber, R. (1993). On the ontological expressiveness of information systems analysis and design grammars. Journal of Information Systems, 3, 217-237. Wand, Y. & Woo, C. (1999). Ontology-based rules for object-oriented enterprise modelling. Working paper No. 99-MIS-001, Faculty of Commerce and Business Administration, University of British Columbia, Canada. Weber, R. & Zhang, Y. (1996). An analytical evaluation of NIAM’s grammar for conceptual schema diagrams. Information Systems Journal, 6(2), 147-170.
Appendix Proposed Modelling Rules This appendix proposes modelling rules for the use of UML for conceptual modelling of real world domains. The work described here is based on Evermann and Wand, 2001b, 2001a) and Evermann (2003). We cannot provide a complete analysis of UML in this chapter, but instead list the fundamental rules relevant to the example: Rule 1: Only substantial entities in the world are modelled as objects. Rule 2: Ontological properties of things must be modelled as UML attributes. Corollary 1: Attributes in a UML description of the real world cannot refer to substantial things. Rule 3: Sets of mutual properties must be represented as attributes of association classes. Corollary 2: An association class must not possess methods or operations. Rule 4: If mutual properties can change quantitatively, methods and operations that change the values of attributes of the association class must be modelled for one or more of the classes participating in the association, objects of which can effect the change, not for the associations class. Corollary 3: An association class must possess at least one attribute. Corollary 4: An association class must not be associated with another class. Corollary 5: An association class must not participate in generalization relationships. Rule 5: An association class represents a set of mutual properties arising out of the same interaction. Rule 6: Classes of objects that exhibit additional behavior, additional attributes, or additional association classes with respect to other objects of the same class, must be modelled as specialized sub-classes. Rule 7: Every UML aggregate object must consist of at least two parts. Rule 8: Every UML aggregate must possess at least one attribute or participate in an association. Rule 9: All UML classes must possess at least one attribute or participate in an association.
Rule 10: Object ID’s must not be modelled as attributes. Rule 11: The set of attribute values (representing mutual and intrinsic properties) must uniquely identify an object. Rule 12: A specialized class must define more attributes, more operations, or participate in more associations than the general class. Rule 13: Every ordinary association must be an association class. Corollary 6: Every object must have at least one operation. Rule 14: An object must exhibit additional operations expressing qualitative changes, if a super- or sub-class is defined and instances can undergo changes of class to the super- or sub-class.
Template-Based Definition of Information Systems and Enterprise Modelling Constructs Andreas Opdahl, University of Bergen, Norway Brian Henderson-Sellers, University of Technology, Sydney, Australia
formal constraints expressed in the object constraint language (OCL) and by populating the meta-model with definitions of example constructs from the UML version 1.4. The purpose is to make the template easier to understand, to validate it, to pave the way for stronger tool support for the template and to further our work on providing a complete template-based definition of the UML.
This chapter companions an earlier paper (Opdahl & Henderson-Sellers, 2004), which has used the BWW model as a common ground for defining enterprise and IS modelling constructs in a way that facilitates language integration. The earlier paper proposes a standardised template for defining enterprise and IS modelling constructs. Specifically, each modelling construct is defined by the filling in of a fixed set of “entries”, of which some are complex, some are interrelated and some can be repeated. The template offers several advantages. The standardised definitions become more cohesive and, thus, more learnable, more understandable and more directly comparable to one another. In consequence, they also potentially facilitate language integration. The template is also a contribution to making the BWW model more easy to use for comparing, defining and integrating modelling languages. The standardised definitions become grounded in the BWW model and Bunge’s ontological model not only generally — in terms of whether they represent “classes”, “properties”, or other ontological categories — but also specifically in terms of which classes and/or properties they represent. The clarity and precision of the definitions is thereby enhanced. By taking constructs from the unified modeling language (UML) as examples, Opdahl and Henderson-Sellers (2004) also contributes to making the UML more clearly and precisely defined. The template has been developed based on practical experience from analysing, suggesting improvements to and providing precise definitions of several fullscale integrated modelling languages and frameworks, as reviewed in Opdahl and Henderson-Sellers (2004). Opdahl and Henderson-Sellers also illustrate the template with a meta-model expressed as a UML class diagram. The objective of this chapter is to clarify the template further by:
•
Formalizing the meta-model through constraints expressed in the object constraint language (OCL) (OMG, 2001).
•
Populating the meta-model with definitions of example constructs from the UML version 1.4.
The next section will introduce the template along with the most relevant concepts from the BWW model. We will then present results of formalising the template and of populating it. Finally, we will point to some future trends and conclude the chapter.
Background This section will review the template presented in Opdahl and Henderson-Sellers (2004). Along the way, we will also introduce the most relevant concepts from the BWW model. Table 1 defines all the BWW concepts used. Figure 1 shows the meta-model of the template (slightly revised from Opdahl & HendersonSellers, 2004). The template has four top-level entries, some of them have sub-entries and some of them can be repeated. Together, the top-level entries make up a construct definition.
The Instantiation Level Entry The instantiation level top-level entry type is used to define whether the modelling construct represents the enterprise at the type level, at the instance level or at either level. This is the simplest type of top-level entry. In relation to the BWW model, the instantiation level defines whether a modelling construct represents BWW things and their particular properties, laws, states, events, processes and histories at the instance level and/or BWW classes and their general properties and laws at the type level. For example, UML objects belong to the instance level and UML types to the type level. In some dialects of traditional dataflow diagrams (DFDs), processes can represent either logical processes at the type level or physical processes at the instance level. Figure 1 shows that a “ConstructDefinition” has an “instLevel” as an attribute.
The Class Entry The class top-level entry type is used to define which class of things (or classes of things) in the enterprise that the modelling construct may represent. Although not all modeling constructs are primarily intended for representing classes, this entry is important because, even when a modeling construct is primarily intended to represent a property, state, event, process or other ontological construct, it may only be intended to represent that property, state, event, process or similar for specific classes. In relation to the BWW model, for a modelling construct at the type level, this entry indicates that the construct may only represent (possibly improper)
Table 1. Basic concepts in the BWW model that are used in this chapter BWW concept
Concept definition
BWW thing
“The elementary unit in our ontological model. The real world is made up of things.” (Wand & Weber, 1995, p.210)
BWW property of a thing
“Things possess properties” (Wand & Weber, 1995, p.210). “We know about things in the world via their properties” (Weber, 1997, p.34).
Property precedence
One property precedes another if all the things that possess the latter property also possess the former. (Bunge, 1977, p.80).
BWW complex property
A complex BWW property consists of other properties, which may themselves be complex (Bunge, 1977, pp.82-83).
BWW property co-domain
“The set of values into which the function that stands for the property of a thing maps the thing” (Weber & Zhang, 1996, p.150).
BWW class of things
“A set of things that can be defined by their possessing a particular set of properties” (Weber & Zhang, 1996, p.151). 1) A BWW class is defined by a “characteristic set” of properties. 2) All groups of BWW properties that are possessed by at least one BWW thing define a BWW class.
BWW subclass of things
“A set of things that can be defined via their possessing the set of properties in a class plus an additional set of properties” (Weber & Zhang, 1996, p.151). (Hence, a BWW subclass is itself a BWW class.)
BWW intrinsic property of a thing
“A property that is inherently a property of an individual thing” (Wand & Weber, 1995, p.210).
BWW mutual property of two or more things
“A property that is meaningful only in the context of two or more things” (Wand & Weber, 1995, p.210).
BWW state of a thing
“The vector of values for all property functions of a thing” (Wand & Weber, 1995, p.210).
BWW state law of a thing
A property that “[r]estricts the values of the property functions of a thing to a subset that is deemed lawful because of natural laws or human laws” (Wand & Weber, 1995, p.210).
BWW event in a thing
“A change of state of a thing. It is effected via a transformation” (Wand & Weber, 1995, p.210).
BWW process in a thing
“An intrinsically-ordered sequence of events on, or states of, a thing” (Green, 1996). Processes may be either chains or trees of events (Bunge, 1977, p.243).
BWW transformation of a thing
“A mapping from a domain comprising states to a co-domain comprising states” (Wand & Weber, 1995, p.210).
BWW transformation law of a thing
“Events are governed by transformation laws that define the allowed changes of state” (Parsons & Wand, 1997, p.105). Wand and Weber (1995, p.210) and other papers on the BWW model instead introduce BWW lawful transformations, which define “which events in a thing that are lawful”. The term “transformation law” instead of “lawful transformation” is chosen here to emphasise that a transformation law — like a state law — is a property of a particular thing.
BWW law property of a thing
“Properties can be restricted by laws relating to one or several properties” (Parsons & Wand, 1997, p.105). A law is either a state law or a transformation law of a particular thing.
BWW composite thing
“A composite thing may be made up of other things (composite or primitive)” (Wand & Weber, 1995, p.210). “Things can be combined to form a composite thing” (Parsons & Wand, 1997, p.105).
BWW component thing
Any BWW thing that is in the composition of a composite thing.
BWW part-whole relation
The property of being in the composition of another thing or, complementary, of having another thing as a component (according to Bunge, 1977, p.43).
BWW resultant property of a composite thing
“A property of a composite thing that belongs to a component thing” (Wand & Weber, 1995, p.210).
BWW emergent property of a composite thing
A property of a composite thing that does not belong to a component thing (adapted from Wand & Weber, 1995, p.26).
BWW history of a thing
“The chronologically ordered states that a thing traverses in time” (Weber & Zhang, 1996, p.150).
BWW acting on another thing, BWW coupling of things
“A thing acts on another thing if its existence affects the history of the other thing. The two things are said to be coupled” (Wand & Weber, 1995, p.210).
BWW direct acting on, BWW binding mutual property
A thing acts directly on one or more other things when the former thing changes a BWW binding mutual property they all possess. Changing the binding mutual property is an internal event in the former thing and an external event in each of the latter things.
Figure 1. A UML class diagram of the template (the top of the diagram represents individual “ConstructDefinitions” and their entries and subentries, whereas the bottom part represents a common taxonomy of “Classes”, “Properties”, “States” and “Events” that can be used and reused in the “ConstructDefinitions”)
subclasses of the specified BWW class. For a modelling construct at the instance level, this entry indicates that the construct may only represent BWW things that belong to the specified class. For example, from the BWW model we can deduce the existence of a BWW class of “ActiveThings”, defined by the characteristic property of acting on other things. In the UML, the active object and active class constructs are both intended to represent this BWW class. At the instance level, a UML active object can represent only BWW things in the class of “ActiveThings”, whereas at the type level, a UML active class can represent only BWW subclasses of “ActiveThings”. Figure 1 shows that a “ConstructDefinition” contains a “RepresentedClass”. Because several modelling constructs can be defined in terms of the same BWW class, “RepresentedClass” is associated with a “Class”. The idea is that, in a software tool for template-based construct definition, every “Class” used to
define a construct is stored in a common taxonomy so that it can be reused to define other constructs later. When a new modelling construct is defined using the template, the tool should let the user browse the already defined “Classes” in the taxonomy. When reuse is impossible and defining a new modelling constructs necessitates defining a new “Class”, that “Class” should be added to the taxonomy. The class entry type can be repeated for modelling constructs that may represent BWW things of several different classes (at the instance level) or subclasses of several different BWW classes (at the type level). For example, although we usually think of a UML aggregation relationship (at the type level) as representing a BWW property (specifically a BWW whole-part relation), the relationship also presupposes the existence of two BWW classes, a “composite (or whole) class” and a “component (or part) class”. Whenever a construct definition has more than one class entry, they must have distinct “roleNames”. Even when the class entry is not repeated, a modelling construct may represent several things (at the instance level) or several subclasses (at the type level) of the same class in the same role. “RepresentedClass” therefore has minimum and maximum cardinalities, “minCard” and “maxCard”, which default to 1. For example, from the BWW model we can deduce the existence of a BWW class of “AssociativeThings”, defined by the characteristic property of being able to associate.1 In the UML, the link construct is intended to represent two or more things (at the instance level) in this class.2 A UML link is therefore defined by a single “RepresentedClass” with “minCard”=2 (because the link connects at least two things) and “maxCard”= ∞ (indicating no upper limit on the number of things).
The Property Entry The property top-level entry type is used to define which property (or properties) in the enterprise that the construct may represent. Again, although not all modelling constructs are primarily intended for representing properties, this entry is important because, even when a modelling construct is primarily intended to represent a state, event, process or other ontological construct, it may only be intended to represent states, events, processes or similar that involve specific properties. The property entry is also important because, sometimes, different modelling constructs may represent the same class of things but not the same properties of those things. For example, the BWW class of “ActiveThings” can be represented by UML operations, UML preconditions and UML postconditions, but with each construct representing different (but interrelated) “Properties” of active BWW things.
Figure 1 shows that a “ConstructDefinition” also contains zero or more “RepresentedProperties”. Again, “RepresentedProperties” are associated with the “Properties” that characterise “Classes” in the taxonomy and, like “Classes”, “Properties” are stored in a common taxonomy so they can be reused later. In the taxonomy, each “Class” has one or more “characteristic Properties”. “ConstructDefinitions” can have zero “RepresentedProperties” because there may be modelling constructs that do not represent properties at all. As for classes, the property entry type can be repeated for modelling constructs that may represent several properties of BWW things (at the instance level) or several characteristic properties of BWW classes (at the type level). Whenever a construct definition has more than one property entry, they must have distinct “roleNames”. Because the class entry may also be repeated, each “RepresentedProperty” has one or more “RepresentedClasses” to specify exactly to which class each property belongs. Even when the property entry is not repeated, a modelling construct may represent the same property several times in the same role. Each “RepresentedProperty” therefore has a minimum and maximum cardinality, “minCard” and “maxCard”, which default to 1. Together, the class and property entries constitute the core of the template. The two types of entries fit nicely with Bunge’s view of the world as composed fundamentally of things and properties around which the other BWW concepts are defined.
The Ontological Descriptions of Properties The BWW model has concepts that describe properties in even greater detail and that are also used in the template. Some of these describe the details of “RepresentedProperties” in a particular “ConstructDefinition”. Others describe the details of “Properties” in the taxonomy. Others still describe the details of “Properties” or “RepresentedProperties” in relation to a particular “Class” or “RepresentedClass”, and Figure 1 introduces two association classes for such details. In Bunge’s ontology, one property precedes another if and only if all things that possess the latter property also possess the former. For example, the property of being a mammal precedes that of being a human. In the common taxonomy, “Properties” are therefore related by a “preceding/precedes” association. There are also associations to represent sets of and compositions of “Properties”. The ontological descriptions of properties are explained in more detail in Table 1 and in Opdahl and Henderson-Sellers (2004).
Lifetimes The lifetime top-level entry type is used to define whether the modelling construct represents an event, a state, a process or the whole lifetime of things. In relation to the BWW model, this entry is important because, sometimes, different modelling constructs may represent the same BWW class of things and the same properties of those things but different segments of the lifetimes of those things. For example, one construct may represent an event, another a state, and a third a process although the event, state and process involve the same properties of the same thing. Constructs like UML state and UML event have identical instantiation level, class, and property entries. Both constructs represent the type level, may represent any subclass of the class of “ChangingThings”, and may represent any non-law properties of those subclasses. However, they have distinct lifetime entries. Figure 1 shows “RepresentedSegments” of the lifetimes of things and classes. A “ConstructDefinition” has exactly one “RepresentedSegment”, which is either the whole lifetime of the thing or class, a process, a state, or an event. “RepresentedSegments” that are “states” or “events” must also have a “RepresentedState” and/or a “RepresentedEvent” as parts. A “RepresentedState” can be expressed as an “OclExpression” that involve “RepresentedProperties”. A “RepresentedEvent” is defined in terms of its “from” and “to states”. A “RepresentedSegment” can also be a chain of alternating “States” or “Events”, and that is how to define modelling constructs that represent BWW processes. Figure 1 also shows that “States” and “Events” are also stored in a common taxonomy so that they can be reused later.
Formalising the Template The entries and sub-entries that make up the template have been designed to be as independent of one another as possible, but they are not completely orthogonal. In this section, the meta-model from Opdahl and Henderson-Sellers (2004) is therefore extended with constraints that show how the entries depend on one another. Each constraint is first explained in natural language and then expressed semi-formally3 using the OMG’s object constraint language (OCL) (OMG, 2001). The purpose is to validate the template and to pave the way for stronger tool support for the template. The formalisation aids validation by ensuring that the meta-model is adequate for representing all the relevant constraints. It aids
tool development by making the meta-model clearer and providing integrity constraints for a future construct definition database.
Constraints on “Names” The first group of constraints is small and simple and ensures that names are unique.
•
Two distinct “ConstructDefinitions” cannot have the same “constructName”.
context cd : ConstructDefinition inv: ConstructDefinition->forAll(cd2 | cd.constructName=cd2.constructName implies cd=cd2) The next two constraints are similar, and we do not write them out in OCL.
• •
Two “Classes” cannot have the same “className”. Two “Properties” cannot have the same “propertyName”.
In the meta-model, “States” and “Events” do not have to be named because a “State” is fully defined by its “invariant” and because an “Event” is fully defined by its “from-” and “toStates”. When “state-” and “eventNames” are present, however, they must be unique in the same sense as “class-” and “propertyNames”.
•
Two “States” with non-empty “stateNames” cannot have the same “stateName”.
context s : State inv: State->forAll(s2 | s.stateName<>”” and s.stateName=s2.stateName implies s=s2) The next constraint is again similar and we do not write it out in OCL.
Two “Events” with non-empty “eventNames” cannot have the same “eventName”.
Constraints on “Classes” and “RepresentedClasses” The three constraints in this group deal with the uniqueness of “Class roleNames” within “ConstructDefinitions”, with the uniqueness of the set4 of “characteristic Properties” of a “Class” and with “Class” specialisation/generalisation.
•
If a “ConstructDefinition” contains more than one “RepresentedClass”, each of them must have a “roleName” that is unique to the “ConstructDefinition .
context ConstructDefinition inv: representedClass->forAll(rc | representedClass->forAll(rc2 | rc<>rc2 implies rc.roleName<>”” and rc2.roleName<>”” and rc.roleName<>rc2.roleName))
•
Two different “Classes” cannot be associated with the same sets of characteristic “Properties”.
context c : Class inv: Class->forAll(c2 | c <> c2 implies c.representedProperty <> c2.representedProperty)
•
If the set of “characteristic Properties” of one “Class” is a subset of that of another “Class”, the first “Class” must generalise the second.
context c : Class inv: Class->forAll(c2 | c.characteristic->includesAll(c2.characteristic) implies c.generalisation->includes(c2))
Hence, at the conceptual level described in the meta-model, generalisations are used as an aid to validate partially the sets of “characteristic Properties” that are associated with each “Class”. At the implementation level, when managing the taxonomy of “Classes”, “Properties”, “Events”, and “States”, generalisations can instead be used to limit the number of “Properties” that have to be explicitly associated with each “Class”, that is, by not explicitly associating a “characteristic Property” with a “Class” whose “generalisation” already possesses that “Property”. Otherwise, adding new “Classes” to the taxonomy would quickly become cumbersome because each new “Class” would have to be explicitly associated with an unfeasibly large number of “characteristic Properties”.
Constraints on “Properties” and “RepresentedProperties” The first four constraints in this group ensure that the “RepresentedClasses” and “RepresentedProperties” contained in a “ConstructDefinition” match one another, that is, that all the necessary “Classes” and “Properties” are contained in the “ConstructDefinition” and that the “Properties” belong to the “Classes” and vice versa.
•
If a “ConstructDefinition” contains a “RepresentedClass” that has a “RepresentedProperty”, the “ConstructDefinition” must also contain the “RepresentedProperty”.
Conversely, if a “ConstructDefinition” contains a “RepresentedProperty” that has a “RepresentedClass”, the “ConstructDefinition” must also contain the “RepresentedClass”.
Conversely, if a “RepresentedProperty” has a “RepresentedClass”, the corresponding “Property” must be “characteristic” of the corresponding “Class”.
context rp : RepresentedProperty inv: representedClass->forAll(rc | rp.property.class->includes(rc.class)) The next constraint deals with the uniqueness of “roleNames” of “RepresentedProperties”.
•
If a “RepresentedClass” has more than one “RepresentedProperty”, each of them must have a “roleName” that is unique relative to the “RepresentedClass”.
context RepresentedClass inv: representedProperty->forAll(rp | representedProperty->forAll(rp2 | rp<>rp2 implies rp.roleName<>”” and rp2.roleName<>”” and rp.roleName<>rp2.roleName)) The next constraint defines precedence between “Properties”.
•
If a “Class” has a “characteristic Property” that is “preceded” by another “Property”, then the “Class” must also have the second “Property” as “characteristic”.
context Class inv: characteristic->forAll(cp | characteristic.includesAll(cp.preceded)) Like “Class” generalisations, at the conceptual level described in the metamodel, precedence associations are used as an aid to validate partially the sets of “characteristic Properties” that are associated with each “Class”. At the implementation level, when managing the taxonomy of “Classes” and “Properties”, precedence associations can instead be used to limit the number of “Properties” that have to be explicitly associated with each “Class”, that is, by not associating a “characteristic Property” with a “Class” when the “Class” is already associated with another “characteristic Property” that is preceded the first one.5 The final two constraints in this group together ensure that precedence associations between “Properties” are acyclic. This first constraint reflects that the precede/preceding association is transitive the second that it is irreflexive.
•
If a “Property” is “preceded” by a second “Property” and the second “Property” is “preceded” by a third, then the first “Property” must also be “preceded” by the third “Property”.
context p : Property inv: Property->forAll(p2 | Property->forAll(p3 | p.preceded->includes(p2) and p2.preceded->includes(p3) implies p.preceded->includes(p3)))
•
A “Property” cannot be “preceded” by itself.
context Property inv: preceded->excludes(self) Together, the two constraints ensure that precedence associations are acyclic because, if there were a cycle of associations, each “Property” in the cycle would be “preceded” by itself by the first constraint, thereby violating the second constraint.
Constraints on “RepresentedSegments”, “States”, and “Events” The final and most complex group of constraints deal with “RepresentedSegments” and the (“Represented-”)“States” and “Events” they contain. The first constraint reflects that every BWW state must be a state in a particular thing or class.
•
If a “State” has a set of “Properties”, there must be a “Class” whose set of “characteristic Properties” is a (possibly improper) superset of the first set.
context s : State inv: Class->exists(c | c.characteristic->includesAll(s.Property)) The following two constraints ensure that “ConstructDefinitions” that represent “States” also contain matching “Classes” and “Properties”.
•
If 1) a “ConstructDefinition” contains a “RepresentedSegment” and 2) the “RepresentedSegment” contains a “RepresentedState” and 3) the corresponding “State” has a set of “Properties”, then there must be a “Class” whose set of “characteristic Properties” is a (possibly improper) superset of the first set and the “ConstructDefinition” must contain the corresponding “RepresentedClass”.
If 1) a “ConstructDefinition” contains a “RepresentedSegment” and 2) the “RepresentedSegment” contains a “RepresentedState” and 3) the corresponding “State” has a “Property”, then the “ConstructDefinition” must also contain a corresponding “RepresentedProperty”.
context ConstructDefinition inv: representedSegment.representedState->forAll(rs | rs.state.property->forAll(rsp | representedProperty->exists(rp | rp.property=rsp))) The next two constraints ensure that all “States” and “Events” in the common taxonomy are unique.
•
Two distinct “States” cannot have the same “invariant”.
context s : State inv: State ->forAll(s2 | s.invariant=s2.invariant implies s=s2)
•
Two distinct “Events” cannot have identical “from-” and “toStates”.
context e : Event inv: Event ->forAll(e2 | e.fromState=e2.fromState and e.toState=e2.toState implies e=e2) The next four constraints restrict which “RepresentedStates” and “-Events” that a “RepresentedSegment” can contain.
•
If a “RepresentedSegment” has “segmentType”=lifetime it cannot contain a “RepresentedState” or a “RepresentedEvent”.
context RepresentedSegment inv: segmentType=lifetime implies representedState->isEmpty() and representedEvent->isEmpty() The three other constraints are so similar to this one that we do not write them out in OCL:
•
If a “RepresentedSegment” has “segmentType”=state it must contain one “RepresentedState” and it cannot contain a “RepresentedEvent”.
If a “RepresentedSegment” has “segmentType”=event it must contain one “RepresentedEvent” and two “RepresentedStates”.
•
If a “RepresentedSegment” has “segmentType”=process it must contain at least three “RepresentedStates” and at least two “RepresentedEvents”.
The next constraint ensures that the “States” and “Events” in a “RepresentedSegment” match.
•
If a “RepresentedSegment” contains a “RepresentedEvent”, then the “RepresentedSegment” must also contain a “RepresentedState” so that the corresponding “State” has the corresponding “Event” as “exitEvent”.
If a “RepresentedSegment” contains a “RepresentedEvent”, then the “RepresentedSegment” must also contain a “RepresentedState” so that the corresponding “State” has the corresponding “Event” as “entryEvent”.
We do not write out this analogous constraint in OCL. The converse of the two previous constraints is not a constraint. Although an “Event” cannot be specified without its “from-” and “toStates”, a “State” can be specified without its “entry-” and “exitEvents”, as indicated by the cardinality constraints. The reason is that whereas a “State” is fully defined by its association with one or more “Properties” and by its invariant over those “Properties”, an “Event” is defined by its “from-” and “toStates”.6 The final constraint in this group cannot be expressed using OCL, because it is a constraint about the OclExpression that defines a “State invariant”. OCL expressions currently cannot constrain other OCL expressions.
•
The invariant of a “State” can only refer to “Properties” that are associated with the “State” and it must refer non-trivially to all such “Properties”. In other words, the invariant of a “State” 1) can only constrain and 2) must constrain all the “Properties” that determine the “State”.
By non-trivially we mean that, for each “Property” of a “State”, the invariant must disallow at least one potential value for the “Property” for at least one combination of values of the other “Properties” of the “State”.
Populating the Template Opdahl and Henderson-Sellers (2004) use modelling constructs from the unified modeling language (UML) (OMG, 2001) as examples and present in table form initial template-based definitions of 58 UML construct. The examples and the table are based on Opdahl, Henderson-Sellers, and Barbier (1999) and Opdahl and Henderson-Sellers, (2001, 2002), which have analysed and evaluated the UML and a related language in terms of the BWW model. They have also been inspired by Evermann and Wand’s (2001a, 2001b) related work. In addition, Opdahl and Henderson-Sellers (2001) have compared the underlying ontological assumptions of the BWW model with those of object-oriented modelling in general. This section presents more detailed definitions of selected UML construct using the template. The constructs have been selected either because they are central to the UML or because they illustrate important ideas behind the template. The purpose is to make the template easier to understand by providing concrete examples, to validate the meta-model by instantiating it, and to further our work on providing a complete template-based definition of the UML by investigating selected UML construct in more detail. Because the UML has weak semantics in relation to concrete problem domains today, some of the definitions are interpretations and proposals that must be evaluated in further work. Figure 2 shows a UML object diagram of the definition of the UML’s object construct using the template. A UML object is at the instance level and may represent any instance of the class of “AssociativeThings”, a very general class defined by the characteristic property of being able to associate (Bunge, 1977).7 A few other UML construct have very similar definitions. For example, UML active objects differ from objects only in that they represent instances of the class of “ActiveThings”. In turn, UML swimlanes differ from UML active objects only in that they represent processes instead of lifetimes, that is, they do not represent active objects from creation all the way to destruction. UML types differ from objects only in that they belong to the type level. Figure 3 shows a UML object diagram of the definition of the UML’s property construct using the template. Even this definition is very similar to the definition of UML objects, but in addition a UML property may represent “anyRegularProperty”, that is, any intrinsic property that is not a law or a
Figure 2. A UML object diagram of the template-based definition of UML objects
Figure 3. A UML object diagram of the template-based definition of UML properties
whole-part relation. Whereas all the “Properties” we have encountered so far have been real properties, that is, properties that belong to real things, “anyRegularProperty” is abstract in the sense that it is represented in the common taxonomy as a “propertySet” of “setMember Properties”. Moreover, “anyRegularProperty” is not itself “characteristic” of any “Class”, it has no precedence associations and it does not determine a “State”. (Only real “Properties” can play these three roles in a definition.) The definition of UML properties reuses the “Class” “AssociativeThings” and its “characteristic
Figure 4. A UML object diagram of the template-based definition of UML multiplicities
Property” “abilityToAssociate” from Figure 2. UML attributes differ from properties only in that they belong to the type level. Figure 4 shows a UML object diagram of the definition of the UML’s multiplicity construct using the template. UML multiplicities differ from UML attributes only in that they may represent different “Properties”. A “multiplicityStateLaw” contains three “Properties” : a “minimumCardinality”, a “maximumCardinality”, and “anyRegularProperty”, indicating that the number of regular properties must be between the minimum and maximum cardinalities. The “multiplicityConstraint” “Property” also has a law attribute (left out of Figure 4 for space reasons), which is an OclExpression describing the constraint in detail: minimumCardinality.size()=1 and maximumCardinality.size()=1 and minimumCardinality.value()>=0 and maximumCardinality.value()>=minimumCardinality.value() and
anyRegularProperty.size()>=minimumCardinality.value() and anyRegularProperty.size()<=maximumCardinality.value() Although the constraint is expressed using the formal OCL syntax, it is used informally here. The reason is that the OCL expresses constraints on UML class diagrams, whereas it is used here to express constraints on UML object instances.
Conclusion The chapter has reviewed and augmented a template for defining enterprise and information systems (IS) modelling constructs in a way that facilitates language integration. Specifically, integration is aided by breaking down each modelling construct into its smallest parts, detailing each of the classes, properties, states and events the construct is intended to represent and, at the same time, organising these classes, properties, states and events in a common taxonomy. In consequence, for every pair of constructs that are defined using the template, it becomes clear exactly how the two constructs overlap with one another. The template was based on the Bunge-Wand-Weber (BWW) model of information systems and has been used on several existing modelling languages and frameworks. It was defined by a meta-model expressed as a class diagram from the Unified Modeling Language (UML). This chapter has clarified the template further by formalising the meta-model through semi-formal constraints expressed in the Object Constraint Language (OCL) and by populating the metamodel with definitions of example constructs from the UML version 1.4. The purpose was to make the template easier to understand, to validate the template, to pave the way for stronger tool support for the template and to further our work on providing a complete template-based definition of the UML. As a result, the chapter has furthered our work on providing a complete templatebased definition of the UML. Because the UML has weak semantics in relation to concrete problem domains today, some of the definitions are interpretations and proposals that must be evaluated in further work. As another result, the template and associated meta-model as presented in Opdahl and Henderson-Sellers (2004) has been improved in several respects. Cardinality constrains have been corrected and new attributes added. However, each change is minor and the formalisation and population in this chapter confirms the correctness and usefulness of the main ideas behind the template.
IS modelling languages. The template also makes the BWW model more applicable and useful in practice, complementing other work that uses the BWW model, for example, Rosemann and Green’s (2002) meta-model for the BWW model. Although their model has been developed with slightly different aims than the template meta-model presented here, integrating or unifying the two remains an interesting research topic. These points are elaborated on and paths for further work are suggested in Opdahl and Henderson-Sellers (2004).
Acknowledgments This is contribution number 03/28 of the Centre for Object Technology Applications and Research.
OMG. (2001). OMG Unified Modeling Language specification, version 1.4. Object Management Group. OMG. (2002). OMG model driven architecture — The architecture of choice for a changing world. Retrieved from http://www.omg.org/mda Opdahl, A. L. & Henderson-Sellers, B. (2001). Grounding the OML metamodel in ontology. Journal of Systems and Software, 57(2), 119-143. Opdahl, A. L. & Henderson-Sellers, B. (2002). Understanding and improving the UML metamodel through ontological analysis. Journal of Software and Systems Modeling (SoSyM), 1(1), 43-67. Opdahl, A. L. & Henderson-Sellers, B. (2004). A template for defining enterprise modeling constructs. Journal of Database Management, 15(2), 39-73. Opdahl, A. L., Henderson-Sellers, B., & Barbier, F. (1999). An ontological evaluation of the OML metamodel. In E. D. Falkenberg, K. Lyytinen, & A. A. Verrijn-Stuart (Eds.), Information system concepts: An integrated discipline emerging (pp. 217-232). Kluwer: IFIP 8.1. Opdahl, A. L. & Sindre, G. (1997). Facet modeling: An approach to flexible and integrated conceptual modeling. Information Systems, 22(5), 291-323. Parsons, J. & Wand, Y. (1997). Using objects for systems analysis. Communications of the ACM, 40(12), 104-110. Rosemann, M. & Green, P. (2002). Developing a meta-model for the BungeWand-Weber ontological constructs. Information Systems, 27, 75-91. Spanoudakis, G. & Finkelstein, A. (1998). A semi-automatic process of identifying overlaps and inconsistencies between requirement specifications. Proceedings of the 5th International Conference on Object-Oriented Information Systems OOIS 98, (pp. 405-424). Spanoudakis, G., Finkelstein, A., & Till, D. (1999). Overlaps in requirements engineering. Automated Software Engineering Journal, 6(2), 171-198. Wand, Y. & Weber, R. (1988). An ontological analysis of some fundamental information systems concepts. In J. I. DeGross & M. H. Olson (Eds.), Proceedings of the Ninth International Conference on Information Systems, Minneapolis, 30 November to 3 December 1988, (pp. 213-225). Wand, Y. & Weber, R. (1993). On the ontological expressiveness of information systems analysis and design grammars. Journal of Information Systems, 3, 217-237. Wand, Y. & Weber, R. (1995). On the deep structure of information systems. Information Systems Journal, 5, 203-223.
Weber, R. & Zhang, Y. (1996). An analytical evaluation of NIAM’s grammar for conceptual schema diagrams. Information Systems Journal, 6, 147170. Weber, R. (1997). Ontological foundations of information systems: Number 4 in accounting research methodology monograph series. Melbourne, Australia: Coopers & Lybrand.
Endnotes 1
In fact, in Bunge’s ontology, this is the most general of all classes.
2
Again, as for UML aggregation, although we usually think of a UML link relationship as representing a BWW property (specifically a BWW mutual property), the relationship also presupposes the existence of two or more BWW things.
3
Although the OCL resembles a formal constraint language in most ways, it does not have all the characteristics we expect from a full formal language, like decidability. We therefore refer to it as a “semi-formal” language.
4
In a strict OCL sense, the “sets” in this section will all be OCL bags, that is, unordered collections possibly with duplicate elements.
5
Otherwise, adding new “Classes” to the taxonomy would quickly become cumbersome because of the large number of “characteristic” “Properties” that each new “Class” must explicitly be associated with.
6
To an extent this choice is arbitrary: it would have been possible to define “States” by their “entry-” and “exitEvents” and “Events” by their associations with one or more “Properties” and by its operation on them (in which case the operation would again be an OclExpression). The chosen solution is simpler because invariants in the OCL tend to be simpler than pre- and postconditions.
7
Bunge (1977) states that all things are able to associate, so the class of “AssociativeThings” may also be called “AllThings”, as in Opdahl and Henderson-Sellers (2004). Also, this property is described as a BWW state law in Figure 2, because it determines how things associate with one another according to the ontological model, that is, it manifests the three axioms of association from Bunge (1977).
A Reflective Meta-Model of Object-Process Methodology 131
which is a combination of a language for expressing the universal (or domain) ontology and an approach for developing systems that uses this language, can be expressed in OPM using objects, processes and links among them. Through the reflective OPM meta-model, we demonstrate the expressive power of OPM and its applicability as a universal tool for architecting systems that involve structure and dynamics in a highly, intertwined manner.
language and notation parts of OPM, namely its semantics and syntax. The other part of the reflective OPM meta-model, which specifies OPM-based system development and evolution processes, can be found in Dori (2002, pp. 289-309) and Dori and Reinhartz-Berger (2003). A major significance of this work is that it lays out a comprehensive, generic, and formal definition of OPM that enables domain-independent modeling of complex systems, in which structure and behavior are intertwined and hard to separate. Indeed, real-life systems of interest can almost always be characterized as such. The chapter is structured as follows. First, the main meta-modeling concepts are defined and existing meta-modeling approaches are reviewed. Then, the main concepts of OPM are introduced and exemplified through a business enterprise model that handles customer orders and retailer requests. The main part of the chapter is the OPM reflective meta-model, including all its elements, entities, and structural, procedural, and event links. Finally, the contribution of OPM as a universal business modeling methodology is summarized, emphasizing its role in defining new methodologies.
Reflective Methodologies and Reflective Meta-Modeling System analysis and design activities can be divided into three types with increasing abstraction levels: real world, model, and meta-model (Van Gigch, 1991). The real world is what system analysts perceive as reality or what system architects wish to create as reality. A model is an abstraction of this perceived or contemplated reality that enables its expression using some approach, language, or methodology. A meta-model is a model of a model, or, more accurately, a model of the modeling methodology (Meta-Model, 2003). Metamodels help understand the deep semantics of a methodology as well as relationships among concepts in different languages or methods. They can therefore serve as devices for methods development, also referred to as methods engineering (Nuseibeh, Finkelstein, & Kramer, 1996; Rossi, Tolvanen, Ramesh, Lyytinen, & Kaipala, 2000), and as conceptual schemas for repositories of software engineering and CASE tools. Meta-modeling is the process that creates meta-models. The level of abstraction at which meta-modeling is carried out is higher than the level at which modeling is normally done for the purpose of generating a model of a system (HendersonSellers & Bulthuis, 1998).
A Reflective Meta-Model of Object-Process Methodology 133
The proliferation of object-oriented methods has given rise to a special type of meta-modeling — reflective meta-modeling, that is, modeling a methodology using its own means alone. While meta-modeling is a formal definition of the methodology, reflective meta-modeling can serve as a common way to check and demonstrate the methodology’s expressive power. Existing object-oriented languages, notably the standard unified modeling language (UML), have partial reflective meta-models. The reflective UML metamodel in Object Management Group (2001), for example, includes class diagrams; OCL (object constraint language) (Warmer & Kleppe, 1999) constraints, which are added on top of the UML graphics as a textual means to express constraints; and natural language explanations for describing the main elements in UML and the static relations among them. This meta-model is incomplete in more than one way. First, UML is only a notation and not a methodology, so only the language elements are meta-modeled, but not any (object-oriented or other) development process. Second, class diagrams are used to model all 10 UML views (diagram types) and the meta-model does not enforce complete consistency requirements among the various views of a UML system model. Third, most of the meta-model (structural) constraints are expressed in OCL, which is a programming-language-like add-on to UML. The meta object facility (MOF) (Object Management Group, 2003) is a standard metadata architecture whose main theme is extensibility and support of metadata. MOF defines four layers of metadata: information (i.e., real world concepts, labeled M0), model (M1), meta-model (M2), and meta-meta-model (M3). The meta-meta-model layer describes the structure and semantics of meta-metadata. In other words, it is an “abstract language” for defining different kinds of metadata (e.g., meta-classes and meta-attributes). The meta modeling facility (MMF) (Clark, Evans, & Kent, 2002) provides a modular and extensible method for defining and using modeling languages. It comprises a static, object-oriented language (MML) to write language definitions, a tool (MMT) to interpret those definitions, and a method (MMM), which provides guidelines and patterns encoded as packages that can be specialized to particular language definitions. MOF and MMF have been applied to meta-model UML. Since both are objectoriented, they emphasize UML elements, while the procedural aspects are suppressed. Since OPM combines the object- and process-oriented approaches in a single framework, it can specify system structure and dynamics in a balanced way. In particular, meta-models expressed in OPM capture both the language and the system development approach parts of the modeled methodology.
Object-Process Methodology in a Nutshell Object-process methodology (OPM) (Dori, 2002) is a holistic approach to the modeling, study, development, and evolution of systems. Structure and behavior coexist in the same OPM model to enhance the comprehension of the system as a whole. Contrary to UML with its ten diagram types, OPM shows the system’s structure and behavior in the same and single diagram type, enabling direct expression of relations, interactions, and effects. This trait reinforces the users’ ability to construct, grasp, and comprehend the system as a whole and at any level of detail. Moreover, Soffer, Golany, Dori, and Wand (2001) concluded that OPM is ontologically complete according to the Bunge-Wand-Weber (BWW) evaluation framework (Wand & Weber, 1993). The BWW framework aims to be a theoretical foundation for understanding the modeling of information systems. Any modeling language (or grammar) must be able to represent all things in the real world that might be of interest to users of information systems, otherwise, the resultant model is incomplete (Rosemann & Green, 2002). Hence, OPM completeness according to the BWW framework is indicative of OPM’s expressive power. Appendix A lists the ontological constructs of information systems, their BWW explanations, and their OPM representation as indicted in Soffer, Golany, Dori, and Wand (2001). Due to its structure-behavior integration, OPM provides a solid basis for modeling complex systems. Indeed, OPM has been extended to support the modeling of common types of systems, including real-time systems (Peleg & Dori, 1999), ERP (Soffer, Golany, & Dori, 2003), and Web applications (ReinhartzBerger, Dori, & Katz, 2002a, 2002b). Three independent experiments showed that OPM is more comprehensible than object-oriented techniques in modeling the dynamic and reactive aspects of real time systems (Peleg & Dori, 2000), Web applications (Reinhartz-Berger & Dori, 2005), and discrete event simulation systems.
A Reflective Meta-Model of Object-Process Methodology 135
tion, generalization, characterization, and instantiation are the four fundamental structural relations. In addition, general structural relations can take on any semantics, which is expressed textually by their user-defined tags. The behavior of a system is manifested in three major ways: 1) processes can transform (generate, consume, or change) things, 2) things can enable processes without being transformed by them, and 3) things can trigger events that (at least potentially, if some conditions are met) invoke processes. Accordingly, a procedural link can be a transformation link, an enabling link, or an event link. The complexity of an OPM model is controlled through three scaling (refinement/abstraction) processes: in-zooming/out-zooming, in which the entity being refined is shown enclosing its constituent elements; unfolding/folding, in which the entity being refined is shown as the root of a directed graph; and state expressing/suppressing, which allows for showing or hiding the possible states of an object. These mechanisms enable OPM to recursively specify and refine the system under development to any desired level of detail without losing legibility and comprehension of the complete system. Each time a diagram is about to get too cluttered, a new diagram can be spawned. The new diagram is linked to and elaborates upon the ancestor diagram.
OPCAT (Dori, Reinhartz-Berger, & Sturm, 2003), a Java-based object-process CASE tool, automatically translates each OPD into its equivalent OPL paragraph (collection of OPL sentences) and vice versa.
OPM Concepts Demonstrated by an Inventory System Model Before presenting the OPM reflective meta-model, in this section we explain and demonstrate OPM concepts through an OPM model of a simple business enterprise inventory system that handles orders. This enterprise can get requests for products from individual customers or from retailers. The OPM model of this enterprise, which includes information modeling as well as business process specification, is presented in Figures 1-7 using both OPDs and their corresponding OPL paragraphs. This dual representation increases the model clarity and accessibility, as readers who are familiar with OPM and its graphical notation can use the OPDs, while readers who are new with OPM will probably prefer to start with the OPL paragraphs. Since the graphical and textual notations of OPM are equivalent, and, from a cognitive viewpoint, complementary, the reader can choose the modality (text or graphics) with which he/she is most comfortable and switch between the two at will. Furthermore, the OPL paragraphs are selfdocumented and hence need no further explanations.
A Reflective Meta-Model of Object-Process Methodology 137
Figure 1. Top level, System Diagram (SD) of the ordering system Product Catalog is environmental. Receipt is physical. Ordering lasts 1 minute to 5 minutes. Ordering requires 2 Product Catalogs. Ordering yields Order and Receipt. Customer is environmental and physical. Retailer is environmental and physical. Either Retailer or Customer handles Ordering.
Figure 2. SD1, in which Order is structurally unfolded
Order exhibits Order Number, Order Status, Order Date, and Order Price, as well as Printing. Order Number is of type integer. Order Status can be created, which is the default, paid, supplied, or completed. Created is initial. Created lasts 2 seconds to 30 seconds. Paid can be advance paid, which is the default, or completely paid. Advance paid is initial. Completed is final. Order Date is of type date. Order Price is of type float. Order consists of optional Order Lines. Order Line exhibits Product ID and Quantity. Order is placed by either Person or Cooperation. Supplied Order is an Order, the Order Status of which is supplied. Order 123 is an instance of Order, the Order Status of which is paid.
Links are denoted in an OPD by lines with different types of arrowheads or triangles, as summarized in Appendix B. In Figure 1, for example, Ordering, which is triggered (activated) by either Customer or Retailer, uses Product Catalog as an input, and creates Order and Receipt as outputs. Any OPM element can be either systemic or environmental. A systemic element is internal to the system and has to be completely specified, while an environmental element is external to the system model and may therefore be specified only partially. The OPD symbol of an environmental element differs from its systemic counterpart in that its borderline is dashed. The Product Catalog in Figure 1, for example, is an environmental object; it is external to the system but should be used as an unchangeable input for the Ordering process. In an orthogonal fashion, an OPM element can also be either physical or informatical. A physical element is tangible in the broad sense, while an informatical element relates to information. A physical entity is symbolized in an OPD as a shadowed closed shape — rectangle, ellipse, or rounded corner rectangle for a physical object, a physical process, or a physical state, respectively. The Receipt in Figure 1, resulting from the Ordering process, is a systemic and physical object, while the Customer and the Retailer are environmental and physical objects.
OPM Things As noted, a thing is a generalization of an object and a process. A thing can be simple or complex. A thing is simple if it has no parts, features (attributes or operations), or specializations, and is complex otherwise. An object is a thing that exists, at least potentially, and represents a class of instances that have the same structure and can exhibit the same behavior. The Order in Figure 2, for example, is a complex object which exhibits four simple attributes (each of which is an object in its own right): Order Number, which is of type integer, Order Status, which is of an enumeration type, Order Date, which is of type date, and Order Price, which is of type float. A process is a class of occurrences (or instances) of a behavior pattern, which transforms at least one thing. Transformation can be creation, consumption, or effect (state change) of a thing (usually an object). To carry out the transformation, the process may need to be enabled by one or more things of different types of classes, which are considered instruments (enablers) for that process. An instrument is a non-human object that is not transformed by the process it enables. Analogous to an object instance, a process instance is an occurrence (one-time execution) of the specific process. The execution time of a process can be
A Reflective Meta-Model of Object-Process Methodology 139
Figure 3. SD2, in which Ordering is in-zoomed
Order exhibits Order Status. Order Status can be paid, supplied, or completed. Paid is initial. Completed is final. Product Catalog is environmental. Receipt is physical. Ordering lasts 1 minute to 5 minutes. Ordering requires 2 Product Catalog. Ordering zooms into Order Creation, Order Verification, Retailer Order Handling, Customer Order Handling, and Receipt Generating, as well as Product Request and Order Type. Order Type can be customer or retailer. Order Creation yields Product Request. Following path individual, Order Creation yields customer Order Type. Following path retail, Order Creation yields retailer Order Type. Order Verification consumes Product Request. Order Verification yields Order. Retailer Order Handling occurs if Order Type is retailer. Retailer Order Handling affects Order. Customer Order Handling occurs if Order Type is customer. Customer Order Handling affects Order. Receipt Generating changes Order Status from either supplied or paid to completed. Receipt Generating yields Receipt. Customer is environmental and physical. Following path individual, Customer handles Order Creation. Retailer is environmental and physical. Following path retail, Retailer handles Order Creation.
constrained by minimal and maximal limits, implying that any process execution can only take a time interval that falls within these time limits. The time limits appear in the OPD as (minimal time constraint, maximal time constraint) within the ellipse representing the process. For example, the specification of the minimal and maximal time limits of the Ordering process in Figure 1 and Figure 3 implies that it must take at least 1 minute and at most 5 minutes. The corresponding OPL sentence is “Ordering lasts 1 minute to 5 minutes.” Following the UML notation of classes and objects, a thing instance is denoted in OPM by a rectangle or an ellipse within which the class name is written as “:ClassName”. The identifier of the instance can optionally precede the colon. The OPL syntax for an instance makes use of the reserved word “the” in an
instance phrase, which is “The ClassName InstanceName”. For example, suppose in Figure 3 we replace Retailer by Storex, an instance of Retailer. In the object instance box in the OPD we would write “Storex: Retailer”, and instead of the OPL sentence “Following path retail, Retailer handles Order Creation.” we would write “Following path retail, the Retailer Storex handles Order Creation.” If the instance identifier is not explicitly specified, the OPL instance phrase would be “The ClassName instance.” In our example the sentence would be “The Retailer instance handles Order Creation.” A process can be atomic, sequential, or parallel. An atomic process is a lowestlevel, elementary action that is not divided into sub-processes, while sequential and parallel processes are refined (usually through in-zooming) into several sequential or parallel sub-processes. The time line in an OPD flows from the top Figure 4. SD2.1, in which Retailer Order Handling is in-zoomed
Order exhibits Order Status. Order Status can be supplied or paid. Paid is initial. Product Catalog is environmental. Order Type can be customer or retailer. Retailer Order Handling occurs if Order Type is retailer. Retailer Order Handling requires 2 Product Catalogs. Retailer Order Handling zooms into Paying and Supplying, which are executed in parallel. Paying changes Order Status to paid. Supplying changes Order Status to supplied.
Figure 5. SD2.2, in which Customer Order Handling is in-zoomed Order exhibits Order Status. Order Status can be created, which is the default, supplied, or paid. Created is initial. Created lasts 2 seconds to 30 seconds. Paid is initial. Product Catalog is environmental. Order Type can be customer or retailer. Customer Order Handling occurs if Order Type is customer. Customer Order Handling requires 2 Product Catalogs. Customer Order Handling zooms into Paying and Supplying. Paying changes Order Status from created to paid. Supplying changes Order Status from paid to supplied.
A Reflective Meta-Model of Object-Process Methodology 141
of the diagram downwards. Hence, the vertical axis within an in-zoomed process defines the execution order: The sub-processes of a sequential process are depicted in the in-zoomed frame of the process stacked on top of each other with the earlier process on top of a later one. Analogously, sub-processes of a parallel process appear in the OPD side by side, at the same height. In Figure 4 and Figure 5, Retailer Order Handling and Customer Order Handling are respectively in-zoomed, to show their two sub-processes, Paying And Supplying. In the in-zoomed version of Customer Order Handling (Figure 5), Paying And Supplying are executed in a serial order: first, the Customer pays and only afterwards Order is supplied. In the in-zoomed version of Retailer Order Handling (Figure 4), on the other hand, Paying And Supplying are executed independently and may occur in parallel. The default execution order is the sequential one, so only the parallel execution order is specified in OPL using the reserved phrase “which are executed in parallel”. For example, the in-zooming sentence in Figure 4 is “Retailer Order Handling zooms into Paying And Supplying, which are executed in parallel.”
OPM States A state is a situation in which an object can be for some period of time. At any point in time an object is in exactly one of its states. A state can be a value from a continuous or discrete value range, or a finite enumerated set of named states. Order Status in Figure 2, for example, has four possible, top-level states: created, paid, supplied, and completed. A state can be initial, final, or default. Both created and paid are initial states, as denoted by the thick borderline rounded corner rectangle. This implies that Order Status can be generated in either its created or paid states, but not at both, since at any point in time an object is in exactly one of its states. If not otherwise specified, Order will be generated in its created state as denoted by the default mark (the small downward diagonal arrow that points towards the created state). The completed state is the final state of Order Status, as denoted in Figure 2 by the double line rounded corner rectangle. When entering this final state, Order can be consumed (i.e., destroyed or deleted). The reserved OPL phrases that describe initial, final, and default states are “is initial”, “is final”, and “which is the default”, respectively (see Figure 2). Like process durations, state durations can also be limited on one or both sides. For example, the created state of Order Status in Figure 2 has a minimal time limit of 2 seconds and a maximal time limit of 30 seconds, implying that between
Figure 6. SD2.2.1, in which Paying of Customer Order Handling is inzoomed
Product Catalog is environmental. Order Status can be created, which is the default, or paid. Created is initial. Created lasts 2 seconds to 30 seconds. Paid is initial. Paid can be advance paid, which is the default, or completely paid. Advance paid is initial. Paying requires 2 Product Catalogs. Paying zooms into Advance Paying and Complete Paying. Advance Paying changes Order Status from created to advance paid. Complete Paying changes Order Status from advance paid to completely paid.
2 to 30 seconds must pass from the moment Order Status enters its created state until it exits this state. Like objects and processes, states can be simple or complex. Complex states recursively contain nested states, and the inner composition of a complex state can be exposed by zooming into it. In Figure 2, for example, in its paid state, Order Status can be at one of two sub-states: advance paid, which is the default of a paid Order, or completely paid. The in-zoomed diagram of Paying (of Customer Order Handling) in Figure 6 shows that Advance Paying first changes Order Status from created to advance paid, and then Balance Paying changes Order Status from advance paid to completely paid.
OPM Links Links are the “glue” that holds entities (processes and objects with their states) together and enables the construction of system modules of ever growing complexity. OPM links are classified into two types: structural links and
A Reflective Meta-Model of Object-Process Methodology 143
procedural links, with the latter specializing into enabling, transformation, and event links.
OPM Structural Links A structural link denotes a structural, that is, a static, time-independent relation between two elements. It usually connects two objects, but it can also connect two processes. Structural links further specialize into general (tagged) structural links, and four fundamental structural links. A tagged structural link can be unidirectional, graphically symbolized by , or bi-directional, graphically sym. It is usually labeled by a textual forward tag (for the unidirecbolized by tional link) or a pair of forward and backward tags (for the bidirectional link). These tags are set by the system architect to convey a meaningful relation between the two linked entities. In Figure 2, for example, the two objects Order and Person are linked with a general unidirectional, structural link tagged “is placed by”, connecting an Order with the Person who placed it. Similarly, Order and Cooperation are linked with a tagged unidirectional, structural link that is also labeled “is placed by”. The four most prevalent and useful OPM structural relations are termed fundamental structural relations and are assigned various triangular symbols placed along the line linking the two things. These symbols are graphically more distinct and appealing to the eye than their text tag counterparts. The fundamental structural links are: 1.
Aggregation-Participation denotes the fact that a thing aggregates (i.e., consists of, or comprises) one or more (lower-level) things, each of which is a part of the whole. It is denoted by , an equilateral triangle whose tip is linked to the whole and whose base is linked to the parts. To achieve the same semantics, we could use “consists of” and “is part of” as the forward and backward tags of a tagged bi-directional, structural link, respectively, but, as noted, using the black triangle symbol helps distinguish this relation from any other tagged structural relation (and the other three fundamental structural relations). In Figure 2, Order consists of optional (0 or more) Order Lines, as the multiplicity constraint * denotes.
2.
Exhibition-Characterization denotes the fact that a link or a thing exhibits, or is characterized by, another lower-level thing. The exhibitioncharacterization symbol is . The exhibitor is linked to the tip of the triangle, while the features (which can be attributes or operations) are connected to its base. In Figure 2, Order exhibits (i.e., is characterized by) the attributes Order Number, Order Status, Order Date, and Order
Price and the operation Printing, while Order Line exhibits Product and Quantity. 3.
Generalization-Specialization (Gen-Spec) is a fundamental structural relation between two entities, denoting the fact that the specialized entities share common features, states, and structural and procedural links with the generalizing entity. The symbol of the gen-spec relation is , a blank triangle whose tip is linked to the generalizing entity and its base — to the specialized entities. In Figure 2, Supplied Order defines a subclass of Orders whose status is supplied. Like Order, Supplied Order has its Order Number, Order Status (which is always supplied), Order Date, Order Price, Order Lines, and an owning Person or Cooperation. It can also execute the operation Printing.
4.
Classification-Instantiation represents a fundamental structural relation between a class of things and an instance of that class. This type of link , a triangle enclosing a solid circle, the tip of which is linked is denoted by to the class, while its base — to the instances. Order 123 in Figure 2 is an instance of an Order whose status is paid.
Structural links of the same type can be connected by “OR” and “XOR” logical relations to specify alternative structures. An “OR” relation is symbolized by a double dashed arc connecting the relevant structural links, while a “XOR” relation is denoted by a single line, dashed arc. In Figure 2, for example, an Order is placed by either a Person or Cooperation, but not by both. If there were no arcs in that specification, a specific Order would have an owning Person and an owning Cooperation.
OPM Procedural Links A procedural link represents a dynamic relation between a process and an entity. Procedural links are divided into enabling links, transformation links, and event links. An instrument link is an enabling link that connects a process with an enabler of that process. The enabler is an entity that must be present in order for that process to occur, but it is not transformed as a result of the process occurrence. The instrument link can originate from an object, a process, or a state, denoting that the object existence, the process existence, or the object in the specific state is the enabler, respectively. Graphically, an instrument link is , while textually it is represented by the reserved word symbolized by “requires”. In Figure 1, for example, Product Catalog is required for the Ordering process. However, the occurrence of Ordering does not affect Product Catalog in any way. Therefore, Product Catalog is an instrument
A Reflective Meta-Model of Object-Process Methodology 145
of the process Ordering. It is, however, possible that for another process, such as Catalog Updating, Product Catalog would be an affectee, that is, an object affected by Catalog Updating. Hence, being an instrument for a certain process class can be though of as a “role” of a thing class with respect to that particular process class. A transformation link denotes that a thing is transformed by the occurrence of a process. Transformation is a generalization of consumption, result, and effect. A consumption link is a transformation link that connects an entity to a process from the consumed entity that consumes it. A consumption link is denoted by to the process, while the reserved word “consumes” represents it in OPL. In Figure 3, for example, Product Request is an object that is internal to Ordering (in object-oriented programming terms it can be thought of as a local variable of the method Ordering) and hence it appears in the in-zoomed frame of Ordering. Product Request is consumed by the process Order Verification. In other words, Product Request, which had existed before an occurrence of Order Verification, was consumed (destroyed or destructed) by the execution of that process, and it no longer exists after Order Verification is over. A consumption link originating from a state of an object means that the process consumes that object only when the object is in that specific state. The corresponding state-specified consumption OPL sentence is “Process consumes state Object.” A result link is a transformation link that denotes a creation of a process, an from object, or an object at a specific state. It is symbolized in an OPD by the process to the resultant entity, while the reserved word “yields” denotes it in OPL. In Figure 3, for example, Order Verification, which consumed Product Request, creates an Order. The Order had not existed before the beginning of Order Verification. Rather, it was created during this execution, and it exists as soon as Order Verification is finished. Since a process is a pattern of behavior or execution, it is also possible for a process to generate or consume not just an object but also a process (e.g., when a process generates a computer program that represents a process). To avoid , namely solid confusion, the arrowhead pointing at the consuming process is (black) rather than blank. Hence, means that the right process means that the left process yields the consumes the left one, while right one. An effect link connects a process with a thing that is affected, that is, undergoes where a change, during that process. The effect link, denoted in an OPD by the black arrowhead pointes towards the process and the blank arrowhead points towards the affectee (the affected thing), means that the affectee of the process had existed before the process occurred and it continues to exist after the process was finished, but at least one of its states or features has changed.
A Reflective Meta-Model of Object-Process Methodology 147
Any type of procedural link (except for the result link) can be made conditional. Graphically, this is done by adding the letter ‘c’ to the link symbol, as shown in Appendix B. In OPL, a conditional procedural link is specified by two sentences: one for its procedural aspect (e.g., an enabling sentence: “Process requires Object.”) and the other is a condition sentence. The two possible condition sentences are a thing condition sentence: “Process occurs if Thing exists.” and a state condition sentence: “Process occurs if Object is state.”
OPM Event Links An event is a significant happening in the system that takes place during a particular moment in the system’s lifecycle, and it often triggers some process in the system. An event is represented by an event link, which is a procedural link that connects a source entity with a destination process. Following the EventCondition-Action paradigm, the semantics of an event link is that the source entity attempts to trigger the destination process. The process does not start unless the event link is enabled, that is, the event occurs, and all the process’ preconditions, represented by the regular (conditional or non-conditional) procedural links, are satisfied. There are five types of event links: 1.
Agent link: an agent is an intelligent object, a human or a group of humans, such as a department in an organization, who initiates a process by supplying an input signal (e.g., pushing a button or operating a machine) or supplying control data. An agent link is an event link that connects an agent with the process it triggers. The Ordering process in Figure 1 starts only when one of its agents, the physical and environmental (external) Customer or Retailer, enables its occurrence. The OPD symbol of an agent link is from the agent to the triggered process. In the OPL paragraph, this link is represented by the reserved word “handles”.
2.
State change event links: the fact that an object is at some state is a possible trigger for an event. In a state change event, the actual event can happen at any point in time between entrance to the state and exit from it. A state change event link connects an object state with the process it triggers when entering or exiting the state. An enabling state change link is e . symbolized by e , while a consumption state change link by A state change event has a timing attribute that determines at what point in time the event occurs along the stay of the object at the state. The possible values of the timing attribute are any, entrance, exit, and switch. The any state change event is an event that can occur at any point in time
during the stay of the object at the state. The state entrance event occurs upon the object entering the state, while the state exit event means that the event occurs upon the object exiting (leaving) the state. The state switch event means that the event occurs upon the object either entering the state or exiting it. The timing of the event is denoted graphically by the timing bar — a small bar perpendicular to the event link, whose location along the link from the triggering state to the triggered process symbolizes the point in time at which the event occurs. Thus, an enabling state entrance event link is symbolized by e , while a consumption state entrance event link is e . An enabling state exit event link is symbolized by e symbolized by e and a consumption state exit event link is symbolized by . Timing bars at both ends of the link denote a switch (entrance or exit) state event link, while no bar at all means a state change event link, where the event can take place at any point in time during the object’s stay at the state. In OPL, a triggering sentence is added to the OPL sentence representing the procedural aspect of the link. Archive Updating in Figure 7, for example, is triggered whenever Order Status enters its completed state. Two OPL sentences describe this link: the enabling sentence “Archive Updating requires completed Order Status.” and the triggering sentence “Order Status triggers Archive Updating when it enters completed.” For a state exit event link, the OPL sentence would be “Order Status triggers Archive Updating when it exits completed.” For a state change event link that does not specify whether the event occurs upon entry to or exit from the state, the corresponding sentence would be “Order Status triggers Archive Updating when it is completed.” For a state switch event link, which specifies that the event occurs either upon entry to or upon exit from the state, the corresponding sentence would be “Order Status triggers Archive Updating when it either enters or exits completed.” 3.
General event links: a general event can be an external stimulus, a change in an object state or value, and so forth. The source of a general event link is a thing (object or process). In Figure 7, for example, a general event link specifies a requirement that the Log Recording process is triggered any time Order Status changes its state. This single link could be replaced by five state entrance event links from each one of the bottom level states of Order Status, but the notation in Figure 7 is more compact. The Log Recording process does not change Order Status, as the enabling aspect (the circle) of the event link, e , denotes. A general event link can e also be of type consumption, symbolized by , or effect, symbolized by e , denoting that the source object or process is respectively consumed or affected by the triggered process. The OPL sentence that specifies the
A Reflective Meta-Model of Object-Process Methodology 149
triggering aspect of a general event link is “Thing triggers Object.” (for example, “Order Status triggers Log Recording.”). 4.
Invocation link: an invocation link is a time-delimited event link between two processes — an invoking process and an invoked one. As noted, the vertical axis in an OPD denotes the time line within an in-zoomed process. The invocation link is used when this default process sequencing needs to be overridden, as in loops or jumping instructions. Using the timing bar symbol, an invocation link can trigger the invoked process when the , ends, denoted by , starts or invoking process starts, denoted by ends, represented by , or at any time during its execution, represented . Figure 7 specifies that Log Recording is triggered any time by Printing terminates. All the possible OPL invocation sentences are specified in Table 5 in Appendix B.
5.
Timeout event link: a timeout event link is a time-delimited link that connects a timed element, which can be a process, a state, or an event link, with a process that is triggered when the element violates its time
Figure 7. SD3, in which Order is unfolded, showing its operations and event triggers
Order exhibits Order Status, as well as Timeout Reporting, Printing, Log Recording, and Archive Updating. Order Status can be created, which is the default, paid, supplied, or completed. Created is initial. Created lasts 2 seconds to 30 seconds. Paid is initial. Paid can be advance paid, which is the default, or completely paid. Advance paid is initial. Completed is final. Order Status triggers Log Recording. Order Status triggers Archive Updating when it enters completed, with a reaction time of 2 seconds to 5 minutes. This link triggers Timeout Reporting when its reaction time lasts more than 5 minutes. Order Status triggers Timeout Reporting when created lasts more than 30 seconds. Timeout Reporting yields Timeout Message. Printing triggers Log Recording when it ends. Log Recording requires Order Status. Log Recording yields Log Record. Archive Updating requires completed Order Status. Archive Updating affects Archive.
constraints. The timed element is constrained by minimal and/or maximal time limits. These constraints limit process execution, state duration, or the reaction time between triggering a process by an event link and the actual beginning of the triggered process. The timing bar denotes whether reference is made to the violation minimal, maximal, or either one of the two time constraints. When the timed element (timed process, timed state, or timed event link) violates its minimal time constraint, the minimal timeout event link, denoted by , is followed. When the element violates its maximal time constraint, the maximal timeout event link, denoted by , is followed. The symbol represents a timeout event link which is followed whenever an extreme time constraints is violated, while represents an unspecified timeout violation event. The square head of the timeout event link points towards the triggered process. The created state of Order Status in Figure 7, for example, is specified to last 2 to 30 seconds. If it lasts more than 30 seconds, it triggers the Timeout Reporting process, announcing the occurrence of a timeout error. All the possible OPL timeout sentences are specified in Table 5 in Appendix B. As noted, an event link can have minimal and maximal reaction timeout constraints: if the triggered process does not start within the interval (minimal time constraint, maximal time constraint) after a stimulus occurred, a timeout event occurs. In Figure 7, for example, Archive Updating should be triggered within 2 seconds to 5 minutes after Order Status enters its completed state. If Archive Updating is not triggered within 5 minutes from that event, Timeout Reporting is triggered, announcing the reaction timeout error.
OPM Reflective Meta-Model Up until now we have presented OPM in a rather informal way and accompanied the introduction with a running example. We devote the second part of this chapter to a formal reflective model of OPM. OPM is itself a complex system that combines language constructs and an approach to use that language. As such, it is amenable to modeling with any modeling language that is sufficiently expressive. In particular, it can be modeled in terms of OPM itself, yielding the OPM reflective meta-model. The rest of this chapter presents the language and notation parts of the OPM meta-model. As noted, the development part of OPM is the focus of Dori and Reinhartz-Berger (2003) and, hence, is not described here.
A Reflective Meta-Model of Object-Process Methodology 151
The Top Level Specification The system diagram (SD), which is the top-level, most abstract specification of the OPM meta-model, is presented in Figure 8. SD contains OPM and its features, which are the attributes Language and Notation, and the operation System Developing. System Developing, which represents the entire OPM-based set of processes, is handled by the User, who is the agent of System Developing. This User can be the system architect, developer, or any other stakeholder who uses OPM to architect, develop, and evolve a System, as well as a team consisting of these stakeholders. The System Developing process requires OPM’s Language and Notation as instruments (unchangeable inputs) to create a new System. OPM’s Language encompasses OPM elements, their features, and the structural and procedural links among them, but it does not specify anything about the symbols used to denote them. The Notation represents the Language both visually, through interconnected OPD symbols, and textually, through OPL paragraphs and sentences. Unfolding Notation, SD1 (shown in Figure 9) exposes the detailed relationships between Language and Notation. Notation is characterized by Modality, which has two possible states: graphical and textual. An OPD Symbol is a Notation the Modality of which is graphical, while an OPL Sentence is a Notation the Modality of which is textual. An OPD Symbol graphically represents an OPM Element, the building blocks of the Language, while an OPL Sentence textually represents several Elements. An OPL Figure 8. SD, the top level specification, of the OPM reflective meta-model
OPM exhibits Language and Notation, as well as System Developing. Notation represents Language. System Developing requires Language and Notation. System Developing yields System. User is environmental and physical. User handles System Developing.
Language consists of Elements. Notation exhibits Modality. Modality can be graphical or textual. Notation represents Language. OPD Symbol is a Notation, the Modality of which is graphical. OPD Symbol graphically represents an Element. OPL Sentence is a Notation, the Modality of which is textual. OPL Sentence consists of at least one OPL Phrase. OPL Phrase consists of optional OPL Phrases and optional Atomic OPL Phrases. Atomic OPL Phrase textually represents an Element. OPL Sentence textually represents at least one Element.
Sentence may consist of several OPL Phrases, each of which can be an Atomic OPL Phrase or a complex OPL Phrase, that is, one that consists of other OPL Phrases. An Atomic OPL Phrase textually represents a single OPM Element.
A Reflective Meta-Model of Object-Process Methodology 153
Figure 10. SD2, in which Language of OPM is unfolded
Element exhibits Affiliation, Essence, and Scope. Affiliation can be systemic, which is the default, or environmental. Essence can be informatical, which is the default, or physical. Scope can be public, which is the default, protected, or private Language consists of Entity and Link. Entity is an Element. Entity exhibits Name. Thing is an Entity. Object is a Thing. Object owns optional States. Process is a Thing. State is an Entity. State specifies the status of an Object. Link is an Element. Link exhibits Homogeneity. Homogeneity can be homogeneous or non-homogeneous. Structural Link is a Link, the Homogeneity of which is homogeneous. Procedural Link is a Link, the Homogeneity of which is non-homogeneous. Event Link is a Procedural Link.
1.
Affiliation, which can be systemic (the default) or environmental. An environmental Element is an Element, the Affiliation of which is environmental. An environmental Element is external to the system or only partially specified, while a systemic Element is internal to the system and completely specified.
2.
Essence, which can be informatical (the default) or physical. A physical Element consists of matter and/or energy. It can be a physical Object (e.g., a Machine), a physical Process (e.g., Manufacturing), a physical State (e.g., tested), or a physical Link (e.g., a communication line between two remote computers). An informatical Element relates to information.
3.
Scope, which can be public (the default), protected, or private. As in object-oriented programming languages, the Scope of an Element can be private (i.e., it can be accessed only by itself), protected (accessible only by itself and its sub-elements), or public (accessible by any element in the system). Unlike the object-oriented paradigm, where a method can
affect or access only the attributes of the same class, the default Scope in OPM is public, which implies that any OPM process can use or change all the objects in the model. While seemingly violating the object-oriented encapsulation principle, this provision increases the flexibility of modeling patterns of behavior as OPM processes that involve and cut across several object classes.
Thing Meta-Model Unfolding Thing of the OPM meta-model, SD2.1 (Figure 11) shows its Perseverance attribute, which can be static or dynamic. An Object is a Thing with static Perseverance, while a Process is a Thing with dynamic Perseverance. In addition to Perseverance, a Thing also exhibits the Concreteness attribute, which determines whether the thing is a class (the default) or an instance. The difference between an Object class Figure 11. SD2.1, in which Thing of OPM Language is unfolded
Timed Element exhibits Minim al Tim e Constraint, Maximal Tim e C onstraint, and an optional D uration Distribution Function. Minim al Tim e C onstraint is 0 by default. Maximal Tim e C onstraint is infinity by default. Duration Distribution Function exhibits Function N ame and optional Param eters. Thing exhibits C oncreteness and Perseverance. Concreteness can be class, which is the default, or instance. Perseverance can be static or dynam ic. Object is a Thing, the Perseverance of which is static. Object exhibits Persistent, Key, optional Indices, and an optional Type. Persistent is of type Boolean. Key is of type Boolean. Index relates to an ordered set of at least one Object. Type can be integer, unsigned integer, short, long, float, double, boolean, char, string, date, or tim e. Process is a Thing, the Perseverance of which is dynam ic. Process is a Timed Element. Process exhibits Execution Order. Execution Order can be atom ic, which is the default, sequential, or parallel.
A Reflective Meta-Model of Object-Process Methodology 155
and an Object instance is similar to the difference between these concepts in the object-oriented approach. A Process instance is an occurrence of the process class, which, as noted, is a behavior pattern that the process instances follow. In programming terms, a Process instance can be thought of as an executable version of code, which can be executed a specified finite number of times, while a Process class is the complete code that can be (re)compiled and executed unboundedly. An Object can optionally exhibit Type (e.g., integer, float, or string), whether it is Persistent (i.e., stored in a database), whether it is Key, and optional Indices. Each Index is an ordered tuple of Objects. Process, which is a Thing with a dynamic Perseverance, is also a Timed Element and as such it inherits Minimal Time Constraint (0 by default) and Maximal Time Constraint (infinity by default). As noted, these constraints limit the Process execution time within the specific bounds. Process also inherits from Timed Element a Duration Distribution Function, which is characterized by Function Name and Parameters. This function specifies the distribution of the process duration that determines how long a process execution lasts and it is most useful for simulation purposes. In addition, Process exhibits Execution Order, which can be atomic, sequential, or parallel. Since a process can be either sequential or parallel (but not both), a zoomed-in process will have sub-processes that are all depicted either stacked or in a row, but not as a mixture of these two modes.
State Meta-Model A State, which describes a situation at which an Object can be, cannot stand alone, but is rather “owned” by an object. At any given point in time, an Object can be at exactly one of the States it owns, or in transition between two states. Like a Process, a State is a Timed Element, and as such it exhibits Minimal Time Constraint and Maximal Time Constraint, that is, the minimal and maximal bounds for a continuous stay of the owning Object in that State. As a Timed Element, State also exhibits Duration Distribution Function for simulation purposes. The OPD labeled SD2.2 (Figure 12) specifies that a State has three additional Boolean attributes: Initial, Final, and Default. Initial determines whether the object can be initially (i.e., upon its creation) at this state. Final determines whether the object can be consumed (destroyed) when it is at that state. Default determines whether this state is the default state (or value) of the owning object, that is, the state into which the object enters when there is no specified initial state or more than one initial state. The self aggregation attached to State indicates
Figure 12. SD2.2, in which State of OPM Language is unfolded
State is a Timed Element. State exhibits Initial, Final, and Default. Initial is of type Boolean and is false by default. Final is of type Boolean and is false by default. Default is of type Boolean and is false by default. State consists of optional States.
that a state may recursively consist of lower-level States, which are nested substates.
Link Meta-Model As SD2.3 (Figure 13) shows, a Link exhibits two link ends: Source End and Destination End. Both are specializations of Link End, which is characterized by Participation Constraint (also known as multiplicity). Participation Constraint defines the Minimal Cardinality (with 1 as its default value) and the Maximal Cardinality (also 1 by default). These specify the minimal and maximal number of instances that can be connected by the link at the corresponding (source or destination) Link End. In addition a Link exhibits the Figure 13. SD2.3, in which Link of OPM Language is unfolded
Link End exhibits Participation Constraint. Participation Constraint exhibits Minimal Cardinality and Maximal Cardinality. Minimal Cardinality is 1 by default. Maximal Cardinality is 1 by default. Link End is linked to an Element. Link exhibits Source End, Destination End, and Homogeneity. Source End is a Link End. Destination End is a Link End. Homogeneity can be homogeneous or nonhomogeneous. Structural Link is a Link, the Homogeneity of which is homogeneous. 2 Link Ends of Structural Link are either linked to 2 Objects or 2 Processes. Procedural Link is a Link, the Homogeneity of which is non-homogeneous. Source End of Procedural Link is linked to an Entity. Destination End of Procedural Link is linked to a Process. Event Link is a Procedural Link.
A Reflective Meta-Model of Object-Process Methodology 157
Homogeneity attribute, which has two states: homogeneous and nonhomogeneous. A Link is homogeneous if both its Link Ends, that is, its Source End and Destination End, are linked to Things whose Perseverance value are the same. In other words, a homogeneous Link connects either two Objects or two Processes, while a non-homogeneous Link usually connects an Object to a Process. Structural Links, which denote static, non-temporal relations between the linked Entities, are usually homogeneous Links. Procedural Links, which model the behavior of the system along time and represent flows of data, material, energy, or control between the linked entities, are non-homogeneous Links by default.
Determining Link Attribute Values The values of the Essence, Affiliation, and Scope link attributes, inherited from Element, are determined according to the corresponding values of the entities the link connects. If the entities have different values, a conflict arises that mandates a decision process based on three rules: the link essence, the link affiliation, and the link scope rules. The link essence rule defines that the Essence value of a link is physical if the Essence of the two Elements it connects is physical. Hence, a physical Link can connect only two physical Elements, as described in Figure 14. The link affiliation rule determines that the Affiliation value of a link is environmental if the Affiliation of the two Elements it connects is Figure 14. SD2.3.1, in which the Link Essence rule is specified
Element exhibits Essence. Essence can be informatical, which is the default, or physical. Physical Element is an Element, the Essence of which is physical. Physical Link is a Link, the Essence of which is physical. Source End of Physical Link is linked to Physical Element. Destination End of Physical Link is linked to Physical Element.
Figure 15. SD2.3.2, in which the Link Affiliation rule is specified
Element exhibits Affiliation. Affiliation can be systemic, which is the default, or environmental. Environmental Element is an Element, the Affiliation of which is environmental. Environmental Link is a Link, the Affiliation of which is environmental. Source End of Environmental Link is linked to Environmental Element. Destination End of Environmental Link is linked to Environmental Element.
Figure 16. SD2.3.3, in which the Link Scope is specified
Source Element is an Element. Destination Element is an Element. Link exhibits Source End and Destination End, as well as Link Scope Declaring. Source End is linked to Source Element. Destination End is linked to Destination Element. Following path a, Link Scope Declaring occurs if Scope of Source Element is private and Scope of Destination Element is private. Following path a, Link Scope Declaring yields private Scope of Link. Following path b, Link Scope Declaring occurs if Scope of Source Element is private and Scope of Destination Element is protected. Following path b, Link Scope Declaring yields protected Scope of Link. Following path c, Link Scope Declaring occurs if Scope of Source Element is private and Scope of Destination Element is public. Following path c, Link Scope Declaring yields public Scope of Link. Following path d, Link Scope Declaring occurs if Scope of Source Element is protected and Scope of Destination Element is private. Following path d, Link Scope Declaring yields protected Scope of Link. Following path e, Link Scope Declaring occurs if Scope of Source Element is protected and Scope of Destination Element is protected. Following path e, Link Scope Declaring yields protected Scope of Link. Following path f, Link Scope Declaring occurs if Scope of Source Element is protected and Scope of Destination Element is public. Following path f, Link Scope Declaring yields public Scope of Link. Following path g, Link Scope Declaring occurs if Scope of Source Element is public and Scope of Destination Element is private. Following path g, Link Scope Declaring yields public Scope of Link. Following path h, Link Scope Declaring occurs if Scope of Source Element is public and Scope of Destination Element is protected. Following path h, Link Scope Declaring yields public Scope of Link. Following path i, Link Scope Declaring occurs if Scope of Source Element is public and Scope of Destination Element is public. Following path i, Link Scope Declaring yields public Scope of Link.
A Reflective Meta-Model of Object-Process Methodology 159
environmental. Hence, an environmental Link can connect only two environmental Elements, as specified in Figure 15. The link scope rule determines the Scope value of a Link as the widest of the Scope values of the two connected Elements, where public, protected, and private are the widest, intermediate, and most narrow Scope values, respectively. Figure 16 specifies a process, Link Scope Declaring, that enforces this rule.
Structural Link Meta-Model SD2.4 (Figure 17) unfolds OPM Structural Links. A Structural Link is characterized by Orderability, which can be ordered (e.g., an array) or Figure 17. SD2.4, in which Structural Link of OPM Language is unfolded
Structural Link exhibits Orderability. Orderability can be unordered, which is the default, or ordered. Tagged Structural Link is a Structural Link. Tagged Structural Link exhibits Forward Tag and Directionality. Forward Tag is “relates to” by default. Directionality can be uni-directional or bi-directional. Tagged Structural Link is xor-connected to optional Tagged Structural Links. Tagged Structural Link is or-connected to optional Tagged Structural Links. Bi-Directional Tagged Structural Link is a Tagged Structural Link, the Directionality of which is bi-directional. Bi-Directional Tagged Structural Link exhibits Backward Tag. Backward Tag is null by default. Forward Tag of Bi-Directional Tagged Structural Link is “are equivalent” by default. Fundamental Structural Link is a Structural Link. Aggregation-Participation Link is a Fundamental Structural Link. Aggregation-Participation Link is xor-connected to optional Aggregation-Participation Links. Aggregation-Participation Link is or-connected to optional Aggregation-Participation Links. Exhibition-Characterization Link is a Fundamental Structural Link. Exhibition-Characterization Link is xor-connected to optional Exhibition-Characterization Links. Exhibition-Characterization Link is or-connected to optional Exhibition-Characterization Links. Generalization-Specialization Link is a Fundamental Structural Link. Generalization-Specialization Link is xor-connected to optional Generalization-Specialization Links. Generalization-Specialization Link is or-connected to optional Generalization-Specialization Links. Classification-Initialization Link is a Fundamental Structural Link. Classification-Initialization Link is xor-connected to optional Classification-Initialization Links. Classification-Initialization Link is or-connected to optional Classification-Initialization Links.
unordered (e.g., a set) by default. An ordered Structural Link adds the reserved label {ordered} next to the Structural Link symbol. In Figure 11, for example, Object is characterized by optional Indices, each of which is an ordered set of Objects. SD2.4 also unfolds the two types of Structural Links: Tagged Structural Links and Fundamental Structural Links. A Tagged Structural Link exhibits Forward Tag, whose default value is the string “relates to”, and Directionality. A Bi-Directional Tagged Structural Link, which is a Tagged Structural Link whose Directionality is bi-directional, exhibits in addition Backward Tag, whose default value is null, and the default value of its (inherited) Forward Tag is “are equivalent”. Fundamental Structural Links specialize into Aggregation-Participation Link, Exhibition-Characterization Link, Generalization-Specialization Link, and Classification-Instantiation Link. Structural Links of the same type can be connected by “OR” and/or “XOR” relations. This is specified by the self tagged structural links labeled “is or-connected to” and “is xor-connected to”, respectively. SD2.4.1 (Figure 18), which unfolds the Fundamental Structural Links, specifies constraints on the Elements that can be connected by this type of links. Being Structural Links, Fundamental Structural Links connects two Objects or two Processes. There are two exceptions to this simple rule. These exceptions, which override the Homogeneity attribute of Structural Links, are explicitly specified in SD2.4.1: Figure 18. SD2.4.1, in which Fundamental Structural Link of OPM Language is unfolded
Aggregation-Participation Link is a Fundamental Structural Link. Exhibition-Characterization Link is a Fundamental Structural Link. Source End of Exhibition-Characterization Link is linked to either Link or T Destination End of Exhibition-Characterization Link is linked to Entity. Generalization-Specialization Link is a Fundamental Structural Link. State Generalization-Specialization Link is a Generalization-Specialization Link. Source End of State Generalization-Specialization Link is linked to State. Destination End of State Generalization-Specialization Link is linked to St Classification-Instatiation Link is a Fundamental Structural Link.
A Reflective Meta-Model of Object-Process Methodology 161
Table 1. Possible structural relations between OPM elements. S and D denote the link source and destination, respectively. + denotes a legal link
D
S
Tagged Structural Link / Aggregation-Participation Link Object Process State Link
Exhibition-Characterization Link D
S
Object
Process
State
Link
Object + Process + State Link Generalization-Specialization Link S Object Process State Link
Object + + + Process + + + State + + + Link Classification-Instantiation Link S Object Process State Link
Object Process State Link
Object Process State Link
D
+ -
+ -
+ -
-
D
+ -
+ -
-
-
1.
An Exhibition-Characterization Link connects a Thing or a Link (as its Source End) and an Entity (as its Destination End). For example, the communication link between remote computers, which is modeled as a Tagged Structural Link, can be characterized by the object Transfer Rate and/or the process Encrypting.
2.
A Generalization-Specialization Link can connect, in addition to two Objects or two Processes, two States of different Objects to represent state inheritance. In this type of link, which is called State Generalization-Specialization Link, the inherited state has at least the same structural and procedural links as the inheriting state.
Table 1 summarizes the possible structural relations between OPM elements in a tabular way.
Figure 19. SD2.5, in which Procdural Link of OPM Language is unfolded
Procedural Link exhibits Link Type, Conditionality, and optional Path Labels. Link Type can be enabling or transforming. Transforming can be consuming, resulting, or affecting. Conditionality can be conditional or unconditional. Source End of Procedural Link is linked to Entity. Destination End of Procedural Link is linked to Process. Instrument Link is a Procedural Link, the Link Type of which is enabling. Instrument Link is xor-connected to optional Instrument Links. Instrument Link is or-connected to optional Instrument Links. Consumption Link is a Procedural Link, the Link Type of which is consuming. Consumption Link is xor-connected to optional Consumption Links. Consumption Link is or-connected to optional Consumption Links. Result Link is a Procedural Link, the Link Type of which is resulting. Result Link is xor-connected to optional Result Links. Result Link is or-connected to optional Result Links. Effect Link is a Procedural Link, the Link Type of which is affecting. Effect Link is xor-connected to optional Effect Links. Effect Link is or-connected to optional Effect Links.
process in turn is examined for possible execution. With the exception of Result Link, each type of procedural link can be either a conditional Procedural Link or an unconditional Procedural Link. A Result Link cannot be a conditional Procedural Link simply because the Entity which the Process generated upon its completion cannot be a condition for the Process that generated it. Like a Structural Link, a Procedural Link can be connected by “XOR” and “OR” relations to other Procedural Links of the same type, as shown by the self tagged structural links labeled “is xor-connected to” and “is orconnected to” in SD2.5.
A Reflective Meta-Model of Object-Process Methodology 163
Figure 20. SD2.6, in which Event Link of OPM Language is unfolded Event Link is a Timed Element. Timeout Event Link is an Event Link. Timeout Event Link can be minimum, maximum, extreme, or any. Source End of Timeout Event Link is linked to a Timed Element. Timeout Event Link is xor-connected to optional Timeout Event Links. Timeout Event Link is or-connected to optional Timeout Event Links. Invocation Link is an Event Link. Invocation Link can be process start, process end, process bordered, or any. Source End of Invocation Link is linked to a Process. Invocation Link is xor-connected to optional Invocation Links. Invocation Link is or-connected to optional Invocation Links. General Event Link is an Event Link. Source End of General Event Link is linked to a Thing. General Event Link is xor-connected to optional General Event Links. General Event Link is or-connected to optional General Event Links. State Change Event Link is an Event Link. State Change Event Link can be entrance, exit, switch, or any. Source End of State Change Event Link is linked to a State. State Change Event Link is xor-connected to optional State Event Links. State Change Event Link is or-connected to optional State Event Links. Agent Link is an Event Link. Source End of Agent Link is linked to an Object. Agent Link is xor-connected to optional Agent Links. Agent Link is or-connected to optional Agent Links.
attributes. The Duration Distribution Function of an Event can be used for system simulation to define the distribution of the time that passes from the event occurrence to the start of the corresponding triggered process. SD2.6 also specifies the five types of Event Links: Agent Link; State Change Event Link, which can be entrance State Change Event Link, exit State Change Event Link, switch State Change Event Link, or any State Change Event Link; General Event Link; Invocation Link, which can be process start Invocation Link, process end Invocation Link, process border Invocation Link, or any Invocation Link; and Timeout Event Link, which can be minimum Timeout Event Link, maximum Timeout Event Link, extreme Timeout Event Link, or any Timeout Event Link. An Event Link can be any Procedural Link, except for a Result Link, since the source Entity of a Result Link is created during the Process and, hence, cannot trigger it. An Event Link cannot be a conditional procedural link, since it triggers the process rather than just specifying an execution requirement on it.
Complexity Management in OPM As noted, OPM is a comprehensive systems evolution methodology. As such, it comprises not only a modeling language, but also an approach for developing and evolving systems. Enabling both top-down and bottom-up development processes through its built-in complexity management mechanisms, OPM supports middle-out development. Complexity management aims at balancing the tradeoff between two conflicting requirements: completeness and clarity. Completeness requires that the system details be stipulated to the fullest extent possible, while the need for clarity imposes an upper limit on the level of complexity and does not allow for an OPD that is too cluttered or overloaded with entities and links among them. The seamless, recursive, and selective OPM scaling, that is, refinement-abstraction, enables presenting the system at various detail levels without losing the “big picture” and the comprehension of the system as a whole.
A Reflective Meta-Model of Object-Process Methodology 165
which conceals a set of states inside an object. For example, the order status in the inventory system is fully state-expressed in Figures 2 and 7 and only partially state-expressed in Figures 3, 4, 5, and 6. This object is state-suppressed in Figure 1. Two entities in an OPD can be connected by at most one procedural link. While abstracting, a conflict between two competing links arises when an entity in the OPD is abstracted. A typical example is a process with two sub-processes, each of which is linked to the same object by a different procedural link, (e.g. an instrument and a consumption link). When this process is out-zoomed, only one of these links needs to remain, and the question is which one prevails. The link needs to be at least as abstract as the more abstract link of the two competing links, so it may be one of these two procedural links or a third link which is more abstract than either one of them. In Figure 3, for example, the object Order is connected to the three sub-processes of Ordering through three links: a result link (to Order Verification) and two effect links (to Customer Order Handling and to Retailer Order Handling). When out-zooming of Ordering, the result link and the two effect links are replaced by a single result link, as shown in Figure 1. Figure 3 shows that Order Status, which is an Order attribute, is connected to Receipt Generating by two input (consumption) links and one output (result) link. After suppressing the states of Order Status, this object remains connected to Receipt Generating with an effect link. Appendix C summarizes the abstraction order of procedural link by a table. This table defines for each two procedural links a third procedural link which replaces the two when abstracting (folding, out-zooming, or state-suppressing) the two procedural links. This table is the basis for defining the procedural aspects of OPM, which are also essential parts of the OPM reflective meta-model (Dori, 2002, pp. 289-309; Dori & Reinhartz-Berger, 2003).
complete methodology, including its language (with both its conceptual-semantic and notational-syntactic aspects) and the OPM-based system development process. This ability to create a reflective meta-model of OPM is indicative of OPM’s expressive power, which goes hand in hand with OPM’s ontological completeness according to the Bunge-Wand-Weber (BWW) evaluation framework (Soffer, Golany, Dori, & Wand, 2001). Besides being the source for OPM’s definition, the reflective meta-model of OPM can serve other important goals. It can be used as a basis for a theoretical comparison between OPM and various object-oriented methods. COMMA (the common object-oriented methodology meta-model architecture) project (Henderson-Sellers & Bulthuis, 1998) used meta-modeling to construct metamodels of popular object-oriented methodologies and identify a core that was later used as a basis for OPEN, object process, environment and notation (OPEN, 2003). The OPM meta-model can be compared to these meta-models and an automatic transformation generator can be made between popular objectoriented methodologies, such as UML, and OPM. Indeed, OPCAT, objectprocess CASE tool (Dori, Reinhartz-Berger, & Strurm, 2003), can automatically generate a set of UML views, including use case, class, sequence, activity, Statecharts, and deployment diagrams, from the single OPM model. The reflective OPM meta-model helps also define an implementation generator, which automatically transforms the OPM model resulting from the system’s analysis and design into a database scheme and executable code. The benefits of this implementation generation include increasing productivity and quality; enabling mechanical and repetitive operations to be done quickly, reliably and uniformly; and relieving designers from mundane tasks so they can focus on creative tasks that require human intelligence. OPM-GCG (Reinhartz-Berger & Dori, 2004), the generic code generator of OPM, handles dynamic repositories of translation rules from an XML syntax of object-process language to various target programming languages. These translation rules are defined in a separate offline tool and are used by the implementation generator at will. Being based on OPM, OPM-GCG enables the generation of potentially complete application logic rather than just skeleton code. The different OPM system development and evolution processes, as well as the refinement and abstraction mechanisms, provide a theoretical foundation for improving OPCAT to make it a fully Integrated System Engineering Environment (I SEE). OPCAT already supports system simulation during the design phase, OPD generation from an OPL script, OPL generation from an OPD-set, and implementation generation.
A Reflective Meta-Model of Object-Process Methodology 167
References Clark, T., Evans, A., & Kent, S. (2002). Engineering modeling languages: A precise meta-modeling approach. Proceedings of the 5 th International Conference on Fundamental Approaches to Software Engineering (FASE’2002), (pp. 159-173). Dori, D. (2002). Object-process methodology — A holistic systems paradigm. Berlin and New York: Springer Verlag Press. Dori, D. & Reinhartz-Berger, I. (2003). Reflective meta-model of OPM — An OPM-based system development process. Proceedings of the 22 nd International Conference on Conceptual Modeling (ER’2003), (pp. 105-117). Dori, D., Reinhartz-Berger, I., & Sturm, A. (2003). OPCAT — A bimodal case tool for object-process based system development. Proceedings of the IEEE/ACM 5 th International Conference on Enterprise Information Systems (ICEIS 2003), (pp. 286-291). Harel, D. (1987). Statecharts: A visual formalism for complex systems. Science of Computer Programming, 8, 231-274. Henderson-Sellers, B. & Bulthuis, A. (1998). Object-oriented metamethods. New York: Springer Verlag Press. Mayer, R. E. (2001). Multimedia learning. New York: Cambridge University Press. Meta-Model Web site. (2003). What is meta-modelling, and what is a metamodel good for? Retrieved from http://www.meta-model.com Nuseibeh, B., Finkelstein, A., & Kramer, J. (1996). Method engineering for multi-perspective software development. Information and Software Technology Journal, 38(4), 267-272. Object Management Group (OMG). (2001). UML 1.4 - UML semantics (OMG document formal/01-09-73). Retrieved from http://cgi.omg.org/docs/ formal/01-09-73.pdf Object Management Group (OMG). (2003). Meta object facility (MOF) specification (OMG document formal/02-04-03). Retrieved from http:// cgi.omg.org/docs/formal/02-04-03.pdf OPEN Web site. (2003). Retrieved from http://www.open.org.au Peleg, M. & Dori, D. (1999). Extending the object-process methodology to handle real-time systems. Journal of Object-Oriented Programming, 11(8), 53-58.
Peleg, M. & Dori, D. (2000). The model multiplicity problem: Experimenting with real-time specification methods. IEEE Transaction on Software Engineering, 26(8), 742-759. Reinhartz-Berger, I. & Dori, D. (2004). Object-process methodology (OPM) vs. UML: A code generation perspective. Proceedings of CAiSE’04 Workshops in connection with the 16th Conference on Advanced Information Systems Engineering (CAiSE2004), vol. 1 (pp.275-286). Reinhartz-Berger, I. & Dori, D. (2005). OPM vs. UML — Experimenting with comprehension and construction of Web application models. Accepted to Emprical Software Engineering Journal, 10(1), 57-79. Reinhartz-Berger, I., Dori, D., & Katz S. (2002a). OPM/Web — Objectprocess methodology for developing Web applications. Annals of Software Engineering — Special Issue on Object-Oriented Web-based Software Engineering, 141-161. Reinhartz-Berger, I., Dori, D., & Katz S. (2002b). Open reuse of component designs in OPM/Web. Proceeding of Computer Software and Application Conference (COMPSAC’2002), (pp. 19-24). Rosemann, M. & Green, P. (2002). Developing a meta model for the BungeWand-Weber ontological constructs. Information Systems, 27, 75-91. Rossi, M., Tolvanen, J. P., Ramesh, B., Lyytinen, K., & Kaipala, J. (2000). Method rationale in method engineering. Proceedings of the 33rd Hawaii International Conference on System Sciences — Volume 2, (pp. 20362045). Retrieved from http://www.computer.org/proceedings/hicss/ 0493/04932/04932036.pdf Soffer, P., Golany, B., & Dori, D. (2003). ERP modeling: A comprehensive approach. Information Systems, 28(6), 673-690. Soffer, P., Golany, B., Dori, D., & Wand, Y. (2001). Modelling off-the-shelf information systems requirements: An ontological approach. Requirements Engineering, 6(3), 183-199. Van Gigch, J. P. (1991). System design modeling and meta-modeling. New York: Kluwer Academic Publishers. Wand, Y. & Weber, R. (1993). On the ontological expressiveness of information systems analysis and design grammars. Journal of Information Systems, 3, 217-237. Warmer, J. & Kleppe, A. (1999). The object constraint language — Precise modeling with UML. Reading, MA: Addison-Wesley.
A Reflective Meta-Model of Object-Process Methodology 169
Appendices Appendix A: BWW Ontological Constructs and Their OPM Representation Table 2. BWW ontological constructs and their mapping to OPM concepts Ontological Construct Thing Property Class State State law
BWW Explanation A thing is the elementary unit in the ontological model. The real world is made up of things. A composite thing may be made up of other things Things possess properties. A property is modeled via an attribute function that maps the thing into some value A class is a set of things that possess common properties The vector of values for all attribute functions of a thing is the state of the thing A state law restricts the values of the properties of a thing to a subset defined by natural or human laws
Event
An event is a change of state of a thing, effected via a transformation (see below)
Transformation
A transformation is a mapping from one state to another one A lawful transformation defines which events in a thing are lawful
Lawful transformation
External event Internal event Stable State
Unstable state
Subclass Composition Decomposition
An event that arises in a thing, subsystem or system by virtue of the action of some thing in the environment on the thing, subsystem or system An event that arises in a thing, subsystem or system by virtue of lawful transformations in the thing A state in which a thing, subsystem or a system will remain unless forced to change by virtue of the action of a thing in the environment (an external event) A state that will be changed into another state by virtue of the action of transformations in the system
A subset of a class, defined by a conjunction of properties The things in a composite thing are its composition A decomposition of a composite thing is a set of things such that every component of the composite thing is either a member of this set or is included in the composition of one of the members
OPM Representation An instance An attribute is an object related to another object by a characterization link An object class A state (separately modeled for each attribute) A state law is a specification of the possible states of an object, including distinction of transient and persistent states The event of changing state A to state B is represented by the sequence <State A → consumption link → process → result link → state B> A process (class) A set of objects / states linked to a process by a condition / event / effect / consumption / instrument link. The process is linked to another set of objects / states by an effect / result link Object / state → event link → process Process → effect / result link → object / state A persistent state, or any other state, which is not unstable (see below)
State A in the sequence <state A → condition / event / consumption link → process → result link → state B> is an unstable state An object class, which is related to another class by a specialization link Composition and decomposition are given by the sequence
