Thinking Ontologically Conceptual versus Design Models in UML

Thinking Ontologically Conceptual versus Design Models in UML Joerg Evermann School of Information Management Victoria University of Wellington Wellington, New Zealand Tel +
of 28
All materials on our website are shared by users. If you have any questions about copyright issues, please report us to resolve them. We are always happy to assist you.
Related Documents
Thinking Ontologically Conceptual versus Design Models in UML Joerg Evermann School of Information Management Victoria University of Wellington Wellington, New Zealand Tel Fax Keywords: Ontology, UML, Conceptual Modelling, Systems Analysis, Business Analysis, Business Modelling, Information system development. Thinking Ontologically Conceptual versus Design Models in UML Abstract Information Systems (IS) are situated in and representations of business and organizational domains. Conceptual models of the real world serve as tools for understanding the business domain. Conceptual modelling is thus an important first step in any IS development project. As no language has been generally accepted for conceptual modelling, researchers have proposed extending the use of widely accepted object-oriented software design languages such as UML for this purpose. A major problem with this is the fact that such languages possess no real-world business or organizational meaning, i.e. it is unclear what the constructs of such languages mean in terms of the business. This chapter discusses how such meaning can be assigned to languages like UML. It provides an example which demonstrates the differences between a software design model and a conceptual model in UML. This chapter shows that UML is suitable for conceptual modelling but that the modeller must take special care not to confuse software aspects with aspects of the real world being modelled. 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, etc. It is embedded in and affects the business. The production planning and control system is used to make decisions about production schedules, equipment changes, etc. 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 twofold: (1) To serve as communication medium for understanding of the domain, and (2) to serve as a guide for IS design (Kung and 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 objectoriented 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. For the IS design phase, the use of object-oriented techniques is well accepted, while no language for real-world conceptual modelling has been generally accepted. Recent work (Evermann and Wand, 2001a,b; Dussart et al., 2002; Opdahl and Henderson- Sellers, 1999; Opdahl et al., 1999; Opdahl and Henderson-Sellers, 2001, 2002; Parsons and Wand, 1991, 1997; Wand, 1989; Wand and Woo, 1999) has therefore examined the suitability of object-oriented languages for conceptual modelling. The main problem to overcome is the lack of clear business or organizational meaning for language constructs such as object, class, attribute, operation. As the resulting conceptual models should be usable as input to software design, it is desirable that they also possess meaning in terms of software. Rather than constructing a new language for which both the business and the software meaning must be defined, it appears more economical to use a wide-spread and widely used software design language such as UML and define business meaning for it, in addition to the software meaning it already possesses. In order to assign such business meaning to a language and its elements, we must first specify what exists in the real-world business domain. To that effect, researchers have employed ontology, the branch of philosophy that deals with what exists in the real world. By interpreting object-oriented constructs in terms of a particular ontology they can be assigned business or organizational meaning. From that, modelling rules and guidelines on the use of such languages for the purpose of real-world conceptual modelling can be derived. This allows the use of a well known and widely accepted language to explicitly model the business or organization in the first step of an IS project. Such models are understandable both to business staff, as they possess ontological semantics, as well as to IS developers, as they retain their design or implementation meaning. Previous research has examined a number of IS design languages using ontology (Green and Rosemann, 2000; Opdahl and Henderson-Sellers, 1999; Opdahl et al., 1999; Opdahl and Henderson-Sellers, 2001, 2002; Wand and Weber, 1993). This research has focussed on providing a mapping from ontology to various language such as DFD, UML, OML, and EPC. It has identified specific strengths and weaknesses of these languages for conceptual modelling, by pointing out missing or unnecessary language elements. In general this past research that object-oriented languages such as UML and OML are expressive enough to model a real-world business domain. While this research tells us that these languages are able to express real-world business domains, initial research by Evermann and Wand (2001b,a) 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 realworld 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 makes 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, e.g. actors, goals, and intentions, are able to explain more phenomena than a competing ontology, e.g. 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 higher-level 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 and Gruninger, 1996; Noy and Hafner, 1997). Ontologies are constructed as needed (Gruninger and Lee, 2002; Holsaple and Joshi, 2002). They are not universal, but can be changed, adapted and customized to fit a specific purpose or domain (Gruninger and 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 and Welty, 2001), p. v). A return to philosophical ontology has been argued for, e.g. 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 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 and Weber, 1993) has taken up this call and focussed on the use of a particular ontology by Bunge (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 (Bunge, 1977) and based on the ontological presuppositions of contemporary scientific research, topped with new hypotheses compatible with the science of the day (Bunge, 1977). 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 modeling in IS (Evermann and Wand, 2001a,b; Opdahl and Henderson-Sellers, 1999; Opdahl et al., 1999; Opdahl and Henderson-Sellers, 2001, 2002; Parsons and Wand, 1991, 1997; Wand and Weber, 1989, 1990, 1993; Wand et al., 1999). These studies have successfully examined and evaluated modelling languages and the object-oriented modelling approach. More importantly, empirical studies conducted by Bodart and Weber (1996); Bodart et al. (2001); Cockroft and Rowles (2003); Evermann (2003); Gemino (1999); Gemino and Wand (2001); 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 and 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 real-world 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,a; 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 real-world domain. Transfer of Assumptions Once the ontological semantics are assigned, i.e. 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 modeling rules on how to use the language for conceptual modelling. An analysis of UML in this way has begun (Evermann and Wand, 2001b,a) 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 repre- sented 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, e.g. 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 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 and 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 emprically. Hence, this chapter can serve to support the assumed mapping. Two important notes. 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,
Related Search
We Need Your Support
Thank you for visiting our website and your interest in our free products and services. We are nonprofit website to share and download documents. To the running of this website, we need your help to support us.

Thanks to everyone for your continued support.

No, Thanks