Thinking Ontologically: Conceptual vs. Design Models in UML

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— that is, 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 that 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. IDEA GROUP PUBLISHING 701 E. Chocolate Avenue, Suite 200, Hershey PA 17033-1240, USA Tel: 717/533-8845; Fax 717/533-8661; URL-http://www.idea-group.com ITB11168 This chapter appears in the book, Business Systems Analysis with Ontologies, edited by Peter Green and Michael Rosemann. © 2005, Idea Group Inc. Thinking Ontologically 83 Copyright © 2005, Idea Group Inc. Copying or distributing in print or electronic forms without written permission of Idea Group Inc. is prohibited. 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 21 more pages are available in the full version of this document, which may be purchased using the "Add to Cart" button on the