Optimal Information Modeling Techniques

Optimal Information Modeling Techniques Kees van Slooten IRM PRESS Optimal Information Modeling Techniques Kees van ...

Author: Keys Van Slooten

41 downloads 8646 Views 2MB Size Report

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!
Report copyright / DMCA form

DOWNLOAD PDF

Optimal Information Modeling Techniques

Kees van Slooten

IRM PRESS

Optimal Information Modeling Techniques Kees van Slooten, Ph.D. University of Twente, The Netherlands

IRM Press

Publisher of innovative scholarly and professional information technology titles in the cyberage

Hershey • London • Melbourne • Singapore • Beijing

Acquisitions Editor: Mehdi Khosrow-Pour Managing Editor: Jan Travers Assistant Managing Editor: Amanda Appicello Copy Editor: Amanda Appicello Cover Design: Tedi Wingard Printed at: Integrated Book Technology

Published in the United States of America by IRM Press 1331 E. Chocolate Avenue Hershey PA 17033-1117 Tel: 717-533-8845 Fax: 717-533-8661 E-mail: [email protected] Web site: http://www.irm-press.com and in the United Kingdom by IRM Press 3 Henrietta Street Covent Garden London WC2E 8LU Tel: 44 20 7240 0856 Fax: 44 20 7379 3313 Web site: http://www.eurospan.co.uk Copyright © 2002 by IRM Press. All rights reserved. No part of this book may be reproduced in any form or by any means, electronic or mechanical, including photocopying, without written permission from the publisher. Library of Congress Cataloguing-in-Publication Data Optimal information modeling techniques / [edited by] Kees van Slooten. p. cm. Includes bibliographical references and index. ISBN 1-931777-09-8 (paper) 1. Database design. I. Slooten, Kees van, 1943QA76.9.D26 O68 2002 005.74--dc21

2002017335

eISBN: 1-931777-30-6 British Cataloguing-in-Publication Data A Cataloguing-in-Publication record for this book is available from the British Library.

Other New Releases from IRM Press • • • • • • • • • • • • • • • • • •

Effective Healthcare Information Systems, Adi Armoni (Ed.) ISBN: 1-931777-01-2 / eISBN: 1-931777-20-9 / approx. 340 pages / US$59.95 / © 2002 Human Computer Interaction Development and Management, Tonya Barrier (Ed.) ISBN: 1-931777-13-6 / eISBN: 1-931777-35-7 / approx. 336 pages / US$59.95 / © 2002 Data Warehousing and Web Engineering, Shirley Becker (Ed.) ISBN: 1-931777-02-0 / eISBN: 1-931777-21-7 / approx. 334 pages / US$59.95 / © 2002 Information Technology Education in the New Millennium, Mohammad Dadashzadeh, Al Saber and Sherry Saber (Eds.) / ISBN: 1-931777-05-5 / eISBN: 1-931777-24-1 / approx. 308 pages / US$59.95 / © 2002 Information Technology Management in Developing Countries, Mohammad Dadashzadeh (Ed.) / ISBN: 1-931-777-03-9 / eISBN: 1-931777-23-3 / approx. 348 pages / US$59.95 / © 2002 Strategies for eCommerce Success, Bijan Fazlollahi (Ed.) ISBN: 1-931777-08-7 / eISBN: 1-931777-29-2 / approx. 352 pages / US$59.95 / © 2002 Collaborative Information Technologies, Mehdi Khosrow-Pour (Ed.) ISBN: 1-931777-14-4 / eISBN: 1-931777-25-X / approx. 308 pages / US$59.95 / © 2002 Web-Based Instructional Learning, Mehdi Khosrow-Pour (Ed.) ISBN: 1-931777-04-7 / eISBN: 1-931777-22-5 / approx. 322 pages / US$59.95 / © 2002 Modern Organizations in Virtual Communities, Jerzy Kisielnicki (Ed.) ISBN: 1-931777-16-0 / eISBN: 1-931777-36-5 / approx. 326 pages / US$59.95 / © 2002 Enterprise Resource Planning Solutions and Management, Fiona Fui-Hoon Nah (Ed.) ISBN: 1-931777-06-3 / eISBN: 1-931777-26-8 / approx. 306 pages / US$59.95 / © 2002 Interactive Multimedia Systems, Syed M. Rahman (Ed.) ISBN: 1-931777-07-1 / eISBN: 1-931777-28-4 / approx. 316 pages / US$59.95 / © 2002 Ethical Issues of Information Systems, Ali Salehnia (Ed.) ISBN: 1-931777-15-2 / eISBN: 1-931777-27-6 / approx. 318 pages / US$59.95 / © 2002 Intelligent Support Systems: Knowledge Management, Vijay Sugumaran (Ed.) ISBN: 1-931777-00-4 / eISBN: 1-931777-19-5 / approx. 318 pages / US$59.95 / © 2002 Human Factors in Information Systems, Edward Szewczak and Coral Snodgrass (Eds.) ISBN: 1-931777-10-1 / eISBN: 1-931777-31-4 / approx. 340 pages / US$59.95 / © 2002 Global Perspective of Information Technology Management, Felix B. Tan (Ed.) ISBN: 1-931777-11-4 / eISBN: 1-931777-32-2 / approx. 334 pages / US$59.95 / © 2002 Successful Software Reengineering, Sal Valenti (Ed.) ISBN: 1-931777-12-8 / eISBN: 1-931777-33-0 / approx. 330 pages / US$59.95 / © 2002 Information Systems Evaluation Management, Wim van Grembergen (Ed.) ISBN: 1-931777-18-7 / eISBN: 1-931777-37-3 / approx. 336 pages / US$59.95 / © 2002 Knowledge Mapping and Management, Don White (Ed.) ISBN: 1-931777-17-9 / eISBN: 1-931777-34-9 / approx. 348 pages / US$59.95 / © 2002

Excellent additions to your institution’s library! Recommend these titles to your Librarian! To receive a copy of the IRM Press catalog, please contact (toll free) 1/800-345-4332, fax 1/717-533-8661, or visit the IRM Press Online Bookstore at: [http://www.irm-press.com]! Note: All IRM Press books are also available as ebooks on netlibrary.com as well as other ebook sources. Contact Ms. Carrie Stull at [[email protected]] to receive a complete list of sources where you can obtain ebook information or IRM Press titles.

Optimal Information Modeling Techniques Table of Contents Foreword ....................................................................................................... vii Kees van Slooten University of Twente, The Netherlands Preface ........................................................................................................... xii Chapter 1. Evaluating an ISD Methodology for Software Packages ......................................................................................................... 1 Kees van Slooten and Marcel Bruins University of Twente, The Netherlands Chapter 2. Modelling Molecular Biological Information: Ontologies and Ontological Design Patterns .......................................... 16 Jacqueline Renée Reich, University of Manchester, UK Chapter 3. Concept Acquisition Modeling for E-commerce Ontology ........................................................................................................ 30 Maria Lee, Shih Chien University, Taiwan Kwang Mong Sim, Chinese University of Hong Kong, China Paul Kwok, The Open University of Hong Kong, Hong Kong Chapter 4. An Object-Oriented Approach to Conceptual Hypermedia Modeling ................................................................................ 41 Wilfried Lemahieu, Katholieke Universiteit Leuven, Belgium Chapter 5. Conceptual Modeling of Large Web Sites ........................... 55 Bernhard Strauch and Robert Winter University of St. Gallen, Switzerland Chapter 6. A Method to Ease Schema Evolution .................................. 69 Lex Wedemeijer, ABP, The Netherlands

Chapter 7. A Three Layered Approach for General Image Retrieval ....................................................................................................... 78 Richard Chbeir, Youssef Amghar and Andre Flory LISI - INSA, France Chapter 8. Is There A Life After Objects? ............................................. 84 Jean Bézivin, University of Nantes, France Chapter 9. A Systemic Approach to Define Agents ............................... 95 Andy Y. Cheung and Stephen L. Chan Hong Kong Baptist University, Hong Kong Chapter 10. Modeling of Coordinated Planning and Allocation of Resources ................................................................................................... 108 Alexey Bulatov, University of Houston-Victoria, USA Atakan Kurt, Fatih University, Turkey Chapter 11. Tacit Knowledge Acquisition and Processing Within the Computing Domain: An Exploratory Study .................................... 121 Peter Anthony Busch, Macquarie University, Australia C. N. G. ‘Kit’ Dampney, University of Newcastle, Australia Chapter 12. Modelling Business Rules Using Defeasible Logic ........................................................................................ 128 G. Antoniou, University of Bremen, Germany M. Arief, Griffith University, Australia Chapter 13. EE-Cat: Extended Electronic Catalog for Dynamic and Flexible Electronic Commerce ........................................................ 137 Jihye Jung, Dongkyu Kim, Sang-goo Lee, Chisu Wu, and Kapsoo Kim, Seoul National University, Korea Chapter 14. Enforcing Modeling Guidelines in an ORDBMSbased UML-Repository ............................................................................ 150 N. Ritter and H.-P. Steiert, University of Kaiserslautern, Germany Chapter 15. Simulation for Business Engineering of Electronic Markets ....................................................................................................... 163 Marijn Janssen and Henk G. Sol Delft University of Technology, The Netherlands Chapter 16. Representing and Reasoning with Scenarios within Information Systems Modeling ............................................................... 170 Choong-ho Yi, Karlstad University, Sweden

Chapter 17. From Object-Oriented Modeling to Agent-Oriented Modeling: An Electronic Commerce Application ................................ 176 Sooyong Park, Sogang University, Korea Vijayan Sugumaran, Oakland University, USA Chapter 18. Web-Based Cooperative Information Systems Modeling ..................................................................................................... 193 Youcef Baghdadi, United Arab Emirates University Chapter 19. EMC – A Modeling Method for Developing Web-based Applications ........................................................................... 207 Peter Rittgen, University Koblenz-Landau, Germany Chapter 20. A UML Representation of U.S. Mutual Fund Servicing as an Iconic Model for Servicing the New EU Equivalent – UCITS .................................................................................. 221 Patrick Leamy, Offshore Fund Consultant, Boston, USA George Ballester, Mellon Trust, Boston, USA Thomas Wright, Data Modeling Consultant, Cape Maine, USA Chapter 21. Relationships Between Relationships: An Empirical Study .................................................................................... 229 C. Calero, Universidad de Castilla-La Mancha, Spain E. Marcos, Universidad Rey Juan Carlos, Spain M. Piattini, Universidad de Castilla-La Mancha, Spain Chapter 22. Informationbase – A New Information System Layer 239 Dragan Kovach, SUPER-KING, Inc., Croatia Kresimir Fertalj, University of Zagreb, Croatia Chapter 23. A Comparison of Stochastic Models for the Interarrival Times of Packets in a Computer Network ....................... 248 Dennis Guster, St. Cloud State University, USA Semyon Litvinov, Penn State - Hazelton, USA Mary Richardson, Grand Valley State University, USA David Robinson, St. Cloud State University, USA Chapter 24. A Methodology for Adaptive Workflows ......................... 258 Liu Shuzhou and Angela Goh Eck Soong Nanyang Technological University, Singapore About the Editor ........................................................................................ 272 Index ........................................................................................................... 273

vii

Foreword Information Modeling Techniques are used during information systems analysis and design, and are important kinds of techniques, which are part of Information Systems Development Methodologies. An optimal information modeling technique may be defined as an information modeling technique that is most appropriate to be applied in a specific situation indicated by certain contingency factors. After the early experiences with relatively primitive methods and techniques during the fifties and sixties of the last century, more successful methods and techniques were further developed and became information systems development methods, or so-called methodologies, during the seventies. During the eighties, many information systems development methodologies have been improved and newly developed, which shifted the attention to the selection, evaluation, and comparison of methods. It was concluded that there is no method best in all situations (Malouin and Landry, 1983). In the meantime, different approaches trying to solve this problem have been proposed: •

Tool-Kit Approaches. A number of “complementary” methods are combined into a single tool-kit. The set of methods and techniques is available to the analyst, who then chooses the set needed for the particular circumstances. One example is the Multi-View method of Woodharper, Antill, and Avison (1985). Another example is the Unified Modeling Language initiated by Booch, Jacobson, and Rumbaugh, and further defined by the Object Management Group. The last set of techniques, collected under the umbrella of UML, is very popular in the field of object-oriented analysis and design. However, the nature of contingencies influencing the selection of techniques and tools is not addressed, and the adequacy or necessity of the set of aspects of modeling, covered by the tool-kit, is not guaranteed. Furthermore, to strengthen the semantics of UML information modeling, other techniques may be necessary (Halpin, 2001).

•

Software Factory. The term Software Factory refers to an approach to software development, which aims to improve the productivity of the

viii development process and the quality of the software product. The introduction of the software factory was successful in Japan contrary to the United States (Cusumano, 1989). It is based on the standardization of procedures for design and implementation, and the availability of an integrated set of tools, but it does not address the situation-specific nature of the development process. However it may be not excluded that future research in situated method engineering (Van Slooten, 1996) and the application of principles from logistics will enforce a new incentive for designing a more flexible software factory. •

Context-Based Selection of a Method. An appropriate method is selected from a repertoire of available methods based on an analysis of the context. This means that methods are not divided into method fragments, which may be selected from different methods. Always a complete method will be selected based on some context factors. Kumar and Welke (1992) mention two fundamental problems with this approach. It is unlikely that a single method will match all relevant aspects of the problem situation, and the adoption of this approach could be expensive in terms of money and time.

•

Determining a Foundation of Information Systems Concepts. Another approach to solving the problems of information systems development, is the development of a sound and widely accepted foundation of basic information systems concepts and methods and techniques based on these concepts (Falkenberg et al., 1989, 1992, 1998). Research on methods and basic concepts is very important and will support all approaches to information systems development, because improved and better techniques will become available through this kind of research. The outcome of this research so far is available for research and educational purposes on the Internet: ftp:// ftp.leidenuniv.nl/pub/rul/fri-full.zip and is called the FRISCO report, which means a Framework of Information System Concepts. This research was started, because there was a growing concern within IFIP WG 8.1 about the situation, where too many fuzzy or ill-defined concepts are used in the information system area.

•

Situated Method Engineering. Olle et al. (1983) said already: “ Design of methodologies and of application systems are very comparable exercises in human endeavour.” Designing methodologies may be supported by a metamethod. Situated method engineering is a meta-method for designing Information Systems Development Methodologies. The assumption is that organizations have to change their information systems development methods due to changing situations. Kumar and Welke (1992) state that method engineering must

ix happen situation-specific and rely on the accumulated wisdom of the past, which emphasizes the situatedness and the evolutionary nature of the process. Van Slooten and Brinkkemper (1993) define method engineering as follows: “The process of configuring a project scenario for information systems development using existing methods, or fragments thereof, to satisfy the factors that define the project context.” Scenario configuration consists of the following stages: 1) The project characterization is determined by assigning values and weights to contingency factors; 2) Based on the project characterization, the method engineer determines the relevant modeling aspects (e.g. information modeling), relevant abstraction levels, relevant development strategy, and existing constraints; 3) A first project scenario is composed by selecting appropriate fragments (e.g., information modeling techniques); and 4) The actual project performance is started using the scenario as guideline. The scenario may change during project performance in case of unforeseen contingencies. All knowledge related to a project scenario is stored in a method base, which may be used by other projects. •

Web-enabled Methodologies. The web may be a perfect facilitator for situated method engineering, the web in the role of the method base. Problems with paper versions of information systems development methods are: the extremely bulky task of maintenance; methods are dynamic and become often extensive; access to methods becomes more and more complicated; and paper versions rarely fit the situation of a specific project. A web-based method could be electronically available to everyone connected to the Intranet or the Extranet and could facilitate situation-specific navigation through the recorded method including guidelines and decision rules, selecting those method fragments relevant for the particular situation depending on the project-specific contingency factors. Configuration management and version management could be realized more easily.

Situation-specific information modeling may be appropriate for most application areas, e.g., modeling aiming at the implementation of enterprise-wide systems, modeling organizational memory information systems, business modeling for electronic commerce applications, etc. There is much work to do to elicit the specific organizational situations, and to know what are appropriate methods and techniques for analyzing and modeling these situations. Contingency theory is a theoretical and rational approach to organizations. Nowadays, contingency theory has also been applied at the level of subsystems of organizations, e.g., projects preparing the implementation of enterprise-wide information systems. Several contingency factors have been proposed (Van Slooten and Hodes, 1996). Applying reference models of enterprise-wide systems, e.g., SAP, may affect these

x factors in a positive or negative way. Several instruments supporting the way of business analysis and modeling have been published (Essink, 1986; Wijers, 1989; Kumar and Welke, 1992; Van Slooten and Brinkkemper, 1993).

REFERENCES Cusumano, M.A. (1989), The Software Factory: A Historical Interpretation. In: IEEE Software, March. Essink, L.J.B. (1986), A Modeling Approach to Information System Development. In Olle, T.W. et al., Information Systems Design Methodologies: Improving the Practice, IFIP WG 8.1, North-Holland. Falkenberg, E.D., and Lindgreen, P. (Eds.) (1989). Information System Concepts: An In-Depth Analysis. IFIP WG 8.1, Task Group FRISCO, Elsevier Science Publishers (North-Holland). Falkenberg, E.D., Rolland, C., and El-Sayed, E.N. (Eds.) (1992). Information System Concepts: Improving the Understanding. IFIP WG 8.1, Task Group FRISCO, Elsevier Science Publishers (North-Holland). Falkenberg, E.D. et al. (1998). A Framework of Information System Concepts (Web edition). International Federation for Information Processing, ISBN 3901882-01-4. Halpin, T. (2001). Integrating Fact-oriented Modeling with Object-oriented Modeling. In Rossi, M. and Siau, K. (Eds.), Information Modeling in the New Millennium, Idea Group Publishing. Kumar, K., and Welke, R.J. (1992). Methodology Engineering: A Proposal for Situation-Specific Methodology Construction. In: Challengies and Strategies for Research in Systems Development, Wiley & Sons Ltd. Malouin, J.L., and Landry, M. (1983). The Mirage of Universal Methods in Systems Design. In: Journal of Applied Systems Analysis, 10, 47-62. Olle, T.W. et al. (Eds.) (1983). Information System Design Methodologies: A Feature Analysis, Elsevier Science Publishers (North-Holland). Van Slooten, C. (1996). Situated Method Engineering. In: Information Resources Management Journal, Summer, Idea Group Publishing. Van Slooten, C., and Brinkkemper, S. (1993). A Method Engineering Approach to Information Systems Development. In Prakash, N. et al. (Eds.), Information System Development Process, IFIP WG 8.1, Elsevier Science Publishers (North-Holland). Van Slooten, C., and Hodes, B. (1996). Characterizing IS Development Projects. In Brinkkemper, S. et al. (Eds.), Method Engineering, Principles of Method Construction and Tool Support, IFIP WG 8.1/8.2, Chapman &Hall.

xi Wijers, G.M. et al. (1989). Analyzing the Structure of IS Development Methods: A Framework for Understanding. In Proceedings of the First Dutch Conference on Information Systems, November. Wood-Harper, A.T. et al. (1985). Information Systems Definition: The MultiView Approach, Backwell, Oxford. Dr. Kees van Slooten Technology & Management Department of Business Information Systems University of Twente The Netherlands

xii

Preface As information modeling takes a more prominent role in organizations and the implications become more widespread, researchers, practitioners and academicians alike will need to have access to the most up-to-date research and practice in information modeling techniques and applications. The chapters in this book address the timely topics of unified modeling language, enterprise resource planning and ontological design and other relevant applications and technologies related to modern information modeling techniques. The authors represent a wide variety of perspectives and provide insights from many different cultures and organizational and industry backgrounds. Chapter 1 entitled, “Evaluating an ISD Methodology for Software Packages” by Kees van Slooten and Marcel Bruins of the University of Twente (Netherlands) compares the Software Package Development Methodology (SPDM) to a method engineering framework, which is a discipline used to construct new methods from parts of existing methods by considering situational factors. The chapter also reports the results of a questionnaire which asked users of SPDM their opinions on the problems and quality of SPDM Chapter 2 entitled, “Modelling Molecular Biological Information: Ontologies and Ontological Design Patterns” by Jacqueline Renee Reich of the University of Manchester (United Kingdom) describes the use of ontologies and ontological design patterns to model molecular biological information. The chapter describes the useful features of ODPs and provides a concrete example of one, namely the Terminological Hierarchy ODP which is related to the informal ontology of immunology. Chapter 3 entitled, “Concept Acquisition Modeling for E-commerce Ontology” by Maria Lee of CSIRO Mathematical and Information Science (Australia), Kwang Mong Sim of Hong Kong Polytechnic University and Paul Kwok of The Open University of Hong Kong presents a concept acquisition modeling approach to facilitate the acquisition, classification and representation of e-commerce concepts. The authors propose a systematic way to make comparisons between concepts based upon an understanding of their semantics. Chapter 4 entitled, “An Object-Oriented Approach to Conceptual Hypermedia Modeling” by Wilfried Lemahieu of Katholieke Universiteit Leuven (Belgium) introduces the Maintainable, End user Friendly, Structured Hypermedia (MESH) approach to hypermedia modeling and navigation. This approach avoids the typical

xiii problems of poor maintainability and user disorientation. The chapter focuses on the data model, which combines established entity-relationship and object-oriented abstractions with proprietary concepts into a formal hypermedia model. Additionally, the chapter briefly discusses the data model’s support for a context-based navigation paradigm and a platform-independent implementation framework. Chapter 5 entitled, “Conceptual Modeling of Large Web Sites” by Bernhard Strauch and Robert Winter of the University of St. Gallen (Switzerland) proposes a Meta model comprising several classes of information objects, various types of associations, design rules and quality checks. The model is applied to an existing Web site. The authors analyze commercial Web site development tools with regard to the extent to which they support conceptual Web site modeling. Chapter 6 entitled, “A Method to Ease Schema Evolution” by Lex Wedemeijer of ABP (Netherlands) proposes a method to address the problem of Conceptual Schema evolution in an early phase and introduces the notion of Majorant Schema to support the application of the method. The authors discuss the advantages of the approach, namely a more graceful schema evolution is ensured because a broader range of deign alternatives is investigated. The chapter concludes that this method is primarily suited to minor changes. Chapter 7 entitled, “A Three Layered Approach for General Image Retrieval” by Richard Chbeir, Youssef Amghar and André Flory of LISI – INSA (France) addresses the problem of having no global approach to resolve retrieving images in complex domains (such as medical ones) when the content is multifaceted. The chapter presents a framework to retrieve medical images through a three-dimensional approach. The authors further present the required elements for both the knowledge base and the retrieval process. The proposed approach offers all possibilities to describe an image within a multifaceted content (context, physical and semantic). Chapter 8 entitled, “Is There A Life After Objects?” by Jean Bezivin of the University of Nantes (France) discusses aspects of the emerging field, model engineering. The chapter looks specifically at meta-modeling and uniform representation of meta-models. Through a discussion of the history of classes and objects from the early eighties to the current languages like CORBA and associated IDL language, the chapter outlines the history of modeling and looks at the need for an evolving framework to deal with the increasing complexity of models. Chapter 9 entitled, “A Systemic Approach to Define Agents” by Andy Y. Cheung and Stephen L. Chan of Hong Kong Baptist University surveys the definitions of software agents and proposes a definition which is based upon the Soft Systems Methodology (SSM) used to understand, define and model agents systematically. The chapter first reviews 12 definitions from current literature and then applies SSM to define agents by structuring the involved problem to cover the central characteristics of agents. Chapter 10 entitled, “Modeling of Coordinated Planning and Allocation of Resources” by Alexey Bulatov and Atakan Kurt of Faith University (Turkey)

xiv proposes a method for the formal description of enterprises as complex humantechnical systems The method proposed is aimed at the analysis of parallel planning and allocation of resources from different points of view and is valid for every hierarchical level of enterprise subdivision. The method allows for the design of decision-making systems for various tasks of coordinated planning and allocation of resources. Chapter 11 entitled, “Tacit Knowledge Acquisition and Processing Within the Computing Domain: An Exploratory Study” by Peter Anthony Busch of Macquarie University and C.N.G. Kit Dampney of the University of Newcastle (Australia) discusses the codification of tacit knowledge as a reality. The authors argue that codification is more prevalent today due to the need for organizations to be more accountable. According to the chapter, accountability requires accurate reporting and quantitative interpretations of information which demands codified knowledge not tacit ambiguities. Chapter 12 entitled, “Modelling Business Rules Using Defeasible Logic” by G. Antoniou and M. Arief of Griffith University (Australia) describes problems with modeling regulations and business rules. The authors then outline what defeasible logic is and explain the advantages of it in solving the problems with modeling regulations and business rules. The chapter concludes with a discussion of current research and future directions. Chapter 13 entitled, “EE-Cat: Extended Electronic Catalog for Dynamic and Flexible Electronic Commerce” by Jihye Jung, Dongkyu Kim, Sang-goo Lee, Chisu Wu and Kapsoo Kim of Seoul National University (Korea) proposes data and query models for electronic catalogs which offer effective search and management facilities to customize the electronic catalog system. The proposed model separates the management of product information and the visual presentation and extends the range of electronic catalogs from product information to Web documents. Chapter 14 entitled, “Enforcing Modeling Guidelines in an ORDBMS-based UML Repository” by N. Ritter and H.-P. Steiert of the University of Kaiserslautern (Germany) presents an approach used to enforce guidelines in Unified Modeling Language (UML)-based software development processes. The authors discuss their implementation of a UML repository on top of an object-relational database management system (ORDBMS). The chapter discusses the advantages of using ORDMBS query facilities of rechecking guidelines by automated mapping. Chapter 15 entitled, “Simulation for Business Engineering of Electronic Markets” by Marijn Janssen and Henk G. Sol of Delft University of Technology (Netherlands) presents and evaluates the concept of an interactive, discrete-event, agent-based simulation approach for the analyses and design of electronic markets. This chapter presents the information needed to derive and evaluate a business engineering approach for electronic markets. Chapter 16 entitled, “Representing and Reasoning with Scenarios within Information Systems Modeling” by Choong-ho Yi of Karlstad University (Sweden)

xv addresses the need for a formal approach within information systems modeling (ISM) that is designed not only for representation but is also connected to the phase of reasoning. The authors show how reasoning, though strait in the form of a prediction for a given scenario, can become connected in the proposed framework based on the semantics introduced. Chapter 17 entitled, “From Object-Oriented Modeling to Agent-Oriented Modeling: An Electronic Commerce Application” by Sooyong Park of Sogang University (Korea) and Vijayan Sugumaran of Oakland University (USA) focuses on the modeling phase of agent-oriented software lifecycle and presents an approach for agent modeling consisting of Agent Elicitation, Intra and Inter Agent modeling methods. The chapter discusses agent characteristics and modeling methods and describes the first two phases of the lifecycle modeling. Finally, the authors apply their approach to a simple agent-based application. Chapter 18 entitled, “Web-Based Cooperative Information Systems Modeling” by Youcef Baghdadi of the United Arab Emirates University presents an example of modeling for Web-Based Cooperative Information Systems (WBCIS). The model presented considers WBIS as an artifact that must mainly allow information exchange, coordination and cooperation as well as a mechanism which allows data restructuring and reengineering. The author discusses the interactions based upon metadata that describes all the components of WBCIS architecture. Chapter 19 entitled, “EMC – A Modeling Method for Developing WebBased Applications” by Peter Rittgen of the University Koblenz-Landau (Germany) suggests a modeling method for the IS layer, the Event-driven method Chain (EMC). The method is based on the Event-driven Process Chain (EPC) by Scheer. The authors adapt this method to fit the Multi-perspective Enterprise Modeling (MEMO) methodology and the object-oriented paradigm thus making it suitable for the development of Web-based applications. The model is then applied to a software trading company. Chapter 20 entitled, “A UML Representation of U.S. Mutual Fund Servicing as an Iconic Model for Servicing the New EU Equivalent – UCITS” by Patrick Leamy, an Offshore Fund Consultant, George Ballester of Mellon Trust and Thomas Wright, a Data Modeling Consultant, (USA) presents a unified modeling language (UML) representation of United States mutual fund servicing. This model is a practical, iconic model for beginning the design of a service model for the new European Union equivalent known as Undertakings for Collective Investment in Transferable Securities of UCITS. Chapter 21 entitled, “Relationships Between Relationships: An Empirical Study” by C. Calero and M. Piattini of the Universidad de Castilla-La Mancha and E. Marcos of the Universidad Rey Juan Carlos uses a modeling example and discusses the benefits of this approach as a model to a simple conceptual schemata. The chapter also presents an empirical study used to determine if modeling with relationships between relationships is more difficult than not for novice designers.

xvi Chapter 22 entitled, “Informationbase – A New Information System Layer” by Dragan Kovach of SUPER-KING, Inc. and Kresimir Fertalj of the University of Zagreb (Croatia) describes the concept of an informationbase. The informationbase is a top layer of the information system and uses information systems databases as existing application programs to provide a structured set of reports and graphs making them directly and permanently available to the user. The described informationbase acts as an intelligent and agile information manager. Chapter 23 entitled, “A Comparison of Stochastic Models for the Interarrival Times of Packets in a Computer Network” by Dennis Guster, Semyon Litvinov, Mary Richardson and David Robinson of St. Cloud University (USA) compares two modeling techniques, the power law process and Markov chains, to the exponential and actual data taken from a ten minute segment. The results reveal that the exponential and power law models are a poor match to the actual data, but the Markov model yielded some promising results. Chapter 24 entitled, “A Methodology for Adaptive Workflows” by Liu Shuzhou and Angela Goh Eck Soong of Nanyang Technological University (Singapore) proposes a methodology to unify business process modeling and workflow automation. The chapter further identifies the information system and organization perspectives of workflow within each development phase. Finally, the authors provide an analysis of the domain and an object notation in the methodology with the goal of building a stable system. The chapters of this book provide insightful theoretical discussion as well as practical examples and case studies illustrating the concepts discussed. Researchers, academicians and students will find the information contained herein invaluable as a starting point or supplement to further their research and discussions related to modern information modeling techniques. The theoretical discussions will enrich understanding of the complex concepts discussed and the practical information will improve even the best practices in information systems modeling. This book is a musthave for all those interested in understanding information modeling and better applying and utilizing it within their organization. IRM Press January 2002

van Slooten & Bruins • 1

Chapter 1

Evaluating an ISD Methodology for Software Packages Kees van Slooten and Marcel Bruins University of Twente, The Netherlands

The Software Package Development Methodology (SPDM) is a methodology for developing complex and customizable software packages supporting business processes, especially Enterprise Resource Planning (ERP) software. Two approaches are applied by this chapter. First SPDM will be compared to a method engineering framework. Method engineering is a discipline to construct new methods from parts of existing methods taking into account situational factors. The second approach is the analysis of the results of a questionnaire, asking users of SPDM their opinion on several issues concerning problems and quality of SPDM. The conclusions, after applying both approaches, are quite similar and some recommendations are made for future research.

INTRODUCTION As competition in the software market increases, the quality of the software becomes increasingly important. One important factor in the quality of the software is the development method used. The evaluated method is called the Software Package Development Method (SPDM). Currently the considered Software Package Manufacturing Company (SPMC) is working on a new version of the SPDM (SPMC and SPDM are not the real names). To be able to improve something its strengths and weaknesses must be found. Previously Published in Challenges of Information Technology Management in the 21st Century, edited by Mehdi Khosrow-Pour, Copyright © 2000, Idea Group Publishing.

2 • Evaluating an ISD Methodology for Software Packages

The design documents are an important part of SPDM. These standards can be divided in Definition Study, Functional Design and Technical Design. The goal of the research described in this paper is to find the strengths and weaknesses of the design standards in SPDM. In this research, two methods are used to get information on the strengths and weaknesses of the existing design standards. The first method is a comparison with design methodology. In this comparison, the design standards are compared to a framework of Method Engineering (Van Slooten, 1993). This framework prescribes the aspects that may be covered by a method. Comparing the design standards in SPDM with this framework should therefore lead to an indication of the quality and completeness of the standards. The concept Method Engineering was introduced by Kumar and Welke (1992) under the name Methodology Engineering. Harmsen, Brinkkemper and Oei (1994) used the term Situational Method Engineering to emphasize the situation-specific character of the process. Van Slooten (1995, 1996) has written that organizations have to change their systems development methods due to changing situations and introduces Situated Method Engineering. The second method used is a questionnaire that was sent to 120 users of the design standards in SPDM. In this questionnaire, the users are asked for their experiences with the design standards. This should also lead to an indication of the quality and completeness of the standards. This chapter is structured as follows. The next chapter will contain a short description of the current situation within SPMC and the current SPDM including the design standards. In the third chapter, the design standards will be compared to a Method Engineering framework. The fourth chapter contains the results of the questionnaire. The final chapter will contain the conclusions of this research and some recommendations for SPMC.

PROBLEM SITUATION SPMC The information in this paragraph is based on internal documents of SPMC. SPMC is a software package development company. The development of SPMC packages takes place in SPMC Development departments. SPMC Development departments can be found in several countries. The culture of an organization determines the way the organization functions. SPMC does not have a very deep-rooted culture. This can be explained by the fact that SPMC is a relatively young organization and the high growth-rate of SPMC. The most important cultural aims of SPMC are Initiative, Innovation and Integrity (three times I). Criticism on each others work is accepted and stimulated.


Software Package Development Method To be able to understand the Software Package Development method, two terms must first be explained, namely work products and project models. Work products are deliverables in the form of documents describing plans or designs. The definition study, the functional design and the technical design are examples of work products. Work products can be in several states. Common states are initial, draft, preliminary and actual. These states are important in the project models. Project models describe a specific process in terms of work products and their required state. The project models in the Software Package Development Method are Process Improvement, Release Management, Software Development, Integration Test and System Test. The work products Definition Study, Functional Design and Technical Design are deliverables in the Software Development project model. The development process consists of the following phases. The first phase is the version definition. In the version definition, all changes and improvements in the upcoming version of SPMC software are described. The second phase is the Definition Study. In this phase, the requirements of the software are specified per package. For every SPMC package, a Definition Study is written. This document describes the relations between different packages. This explains what the function of a specific package is within all SPMC packages. The components (modules) of a specific package are also described in the Definition Study. The third phase is the Functional Design. In this phase, the requirements of a certain part of software are described in detail. The fourth phase is the Technical Realization. In this phase, the designs are actually implemented into code. Three sub-phases can be identified. During Technical Design the requirements of the functional design are translated into information, needed by programmers to construct the software. After the software is actually constructed the programmer tests it (Technical Unit Test) and after that, a colleague (Functional Unit Test) tests the program. The next phase is the Integration Test. This test takes place in a simulated environment. The inter-working of packages is tested and the functionality is compared to what was specified in the Functional Design. Version Definity

Definition Study

Functional Design

Technical Realization Technical Design

Integration Test Technical Unit Test

System test

Functional Unit Test

Acceptation


How the packages function in a real environment is tested in the final phase, the System Test. Here end-users and consultants will work with and test the package. When this phase is over the software is accepted and ready to be sold. Beside project models and work products, SPDM consists of templates and work instructions. A template prescribes the structure of a work product. Its explanation (standard) indicates the kind of information and level of detail to be presented in each part of that structure. A work instruction is a document that prescribes in detail how to use a certain tool or how to apply a certain technique, in order to perform a given task or activity. In short, SPDM consists of project models. Work products with their state are used to monitor the progress of these project models. Templates are used to define the structure of the work products. Work instructions describe how tools and techniques must be applied in order to perform a given task or activity. The Design Standards Software structure Before describing the actual design standards the structure defined in SPMC packages must be clarified. The structure of SPMC packages is shown in the following figure. The highest level in SPMC software is the package. These are the commercially available packages of SPMC. A package consists of several modules. A module is a part of an application package that implements a functionally logical part of the application. Modules are built from several business objects. Business objects are a logical part of a module. Business objects on their turn consist of several functionally or technically related sessions. The following example should clarify this structure. A package could be compared to a package like MS Office. A module of this package can be MS Word. The software that controls the printer within Word would then be a business object. A session might be a printer setup screen.

Package Module Business Session


Definition study The definition study is a phase in the software development process. The document that is written in this phase is also titled definition study. The definition study document specifies the requirements for software on the level of application packages or other explicitly related software products. Typically included are the relations with other software products, the internal architecture, and the global conceptual data model. The Definition Study provides the following: • Rough description of the functionality • Input for the functional design • Base for internal and/or external review • Description of the terminology used The standard does not restrict the use of methods and techniques. Every author is free to determine whether he uses existing techniques and what kind of techniques he uses. Previously written definition study documents show that existing techniques are hardly used. With the exception of the architecture model, the definition study contains very few (graphical) models. Functional design The functional design is a phase in the software development process that results into a functional design document. This document describes the software on a Business Object level. In the functional design, the requirements of the Business Object are described in detail. The relations among different Business Objects and the underlying sessions are also described in the functional design document. The functional design standard does not give restrictions for the use of specific method fragments and techniques. The use of techniques is left to the author. An important feature of the functional designs within SPMC is that they include many technical details. Many technical details are embedded in the functional design, which means that often a technical design does not have to be written. Technical design Because the functional design often already contains many details, a technical design is not always written. The technical design contains a description of how the functionality described in the functional design can be converted into source code. The standard for technical design does not restrict the author in using method fragments and techniques.


EVALUATING BY APPLYING A THEORETICAL FRAMEWORK The Method Engineering Framework In this section, SPDM will be compared to the Method Engineering framework (Van Slooten, 1993). With this framework, one is able to develop a situational method, by using method fragments of existing methods. This framework provides guidelines on the components that are to be described in an appropriate and complete method. The Method Engineering framework consists of two dimensions. The first dimension consists of two levels, called Object Systems Analysis and Design (OSAD on the business analysis level) and Information Systems Analysis and Design (ISAD on the information systems analysis level). An object system is usually an organization or a part of an organization. In the OSAD layer, a new object system is designed by analyzing and solving problems with the old object system. The ISAD layer aims at designing a new computer-based information system that supports part of the object system selected in the OSAD layer. The second dimension consists of a number of aspects. Aspects are specific views on the object system. In the table below, the five aspects used in the Method Engineering framework in Slooten (1993) are presented. Representative terms for every aspect are shown by the second row. Process Function Activity

Information Message Data

Behaviour Event Time

Organization Structure Culture

Problem Definition Solution

By analyzing every aspect on the OSAD and ISAD level, one should get a complete view on the information system required. Not every aspect has to be described in the same detail. A detailed information analysis is for example less important on the OSAD than on the ISAD level. The characteristics of the object system also highly determine the required detail for a specific aspect. Comparison of SPDM with Method Engineering General Before it is possible to compare SPDM with the Method Engineering framework, it is necessary that SPDM specific features must be addressed. The first is that the SPMC packages developed with SPDM are not designed for a specific company, but for a complete market. Therefore the OSAD layer is aimed at an entire market instead of a single (part of an) organization. A second point of attention is the fact that SPDM is an extremely open standard. This leads to differences in quality of the design documents written by different authors.


Because SPMC packages must be useful within an entire target market, the analysis of aspects on the OSAD layer is very global. Mainly in the version definition and definition study the scope and the purpose of the packages are described. An important source of information for the OSAD layer is the experience and knowledge of SPMC employees. The process aspect The process-oriented aspect describes the information flows between business functions or processes and the environment. In SPDM, the definition study contains a description of the package and the modules it is built from. In addition, the definition study describes the relations between modules in a package and between the modules of different packages. The functional design contains a similar analysis but on the business object level. Often an architecture scheme is created to clarify the relations between the different components. Usually SPMC’s design document authors do not use existing (proven) techniques, like data flow diagrams, to analyze the process aspect. The description of the process aspect as prescribed in SPDM is an adequate analysis of the process-oriented aspect. The information aspect When analyzing the information aspect on the ISAD level, user-orienteddata-classes are described. User-oriented-data-classes are linked to the most elementary processes that can be defined in an automated information system. All these data-classes can be converted into an information structure. Together these data-classes form the information architecture of the information system. The different data-classes are joined together by looking at the joint elements in the information structures. If the information structure was set up correctly, it should be a complete view of the information flowing within and out of the automated information system. SPDM does prescribe the creation of data models. The data model is however only prescribed in the functional design phase. There is no high-level data model prescribed in SPDM. A conceptual data model is nevertheless a very important model. Another problem with the current standard is that the data model is not structured enough. This is mainly caused by the fact that no existing (proven) techniques are used to create it and that no conceptual data model was created in the definition study phase. The behavior aspect In behavior oriented modeling the order of processes, their pre- and post conditions and their duration are described. To do this, concepts like event and time are introduced. The analysis of this aspect becomes more important when time-related concepts are important in the process to be analyzed.


SPDM does not contain any guidelines about analyzing the behavior-oriented aspect. When this aspect is important it is left to the author to write about it. Informal agreements exist about the creation of a behavior-oriented model in the form of a Petri-net, which will be included in future versions of SPDM. Adding new techniques in the standard does require attention for education. The organization aspect When analyzing the organization-oriented aspect, one has to specify the features of the object system that influences the information system. Within SPMC the object system is a market. SPMC specifically aims its products at larger organizations in the process and automotive industries. A lot of knowledge about the market is already available within SPMC as a result of years of experience with the existing package software. The new software features are mainly documented in the version definition and definition study document. Important are: • Market developments in the markets for the SPMC packages. These developments can be very important for the organization aspect. By describing the developments, proposed changes in the packages can be backed up. • Technological developments are also important in the organization aspect. When new technologies become available, it is often possible to add functionality to a package or change the way the functionality was previously implemented. • The comments of customers are also interesting to use in the analysis of this aspect. The experiences customers have with the packages are an important source of information for adding functionality and changing the software. The standard does not contain clear guidelines for what is to be done concerning this aspect. Only a few vague statements are given, like “summary of software to be developed, for which countries, lines of business, etc” The analysis of this aspect is left to the author. The problem aspect In the analysis of the problem aspect, the problems of the existing system are analyzed and solved. It is very important here that the problem is adequately defined. When the problem definition is good, the solution can often be easily found. For the analysis of this aspect a lot of the knowledge gained by experience with package software is used. The analysis of this aspect can mainly be found in the version definition and the definition study document. Important elements in this analysis are: • Market developments can cause a revision in the problem definition used for the market. • Technological developments lead to new insights. With these insights it is possible that new problems are found or that ideas on existing problems have changed.


• Remarks of customers can also lead to improved insights in the problem aspect. This makes the communication with customers extremely important for Baan. Like in the organizational aspect, the standard is vague on this subject. Conclusions of Comparing with Framework A first conclusion that can be drawn is that the SPDM standards are very open. This leaves the quality of the design documentation in the hands of the authors of the documents. From the comparison of the standard with the framework for Method Engineering, many conclusions can be drawn about the standard. Important for the comparison was that the OSAD layer is not aimed at a specific organization but instead at a market. What affects the “fit” of the SPMC packages to one specific organization in a negative way compared to non-packaged software. In the analysis of the problem and organization-oriented aspects, the goal and the scope of the packages are defined. Important in the analysis of these two aspects are the market developments, the technological developments and the customer’s feedback. Another conclusion is that the standard is focused on functional aspects (i.e., requirement analysis). Therefore, the process aspect is adequately handled in the standards. No existing techniques are prescribed in the analysis of the process aspect. There is however, a graphical representation made of the architecture. The focus on functional aspects causes the information aspect analysis to be neglected. There are guidelines for writing a data model, but they are not included in the actual design documentation. The quality of the data model is therefore very dependent on the author. At higher levels, however, there is no attention for data models. In addition, no existing technique is used to create the data model. This causes the low-level data model to be unstructured. The use of an existing technique, like entity relationship diagrams, also at a high level should improve the quality of the information-oriented aspect analysis. The behavior-oriented aspect is not mentioned in SPDM even when it plays an important role in many of the SPMC Packages. There do exist some informal agreements on the usage of dynamic models in the design documents. These agreements must however be formally implemented in the standards. In general, SPDM is not sufficiently structured. The explanation of what must be covered in what chapter is often very brief. The freedom in using techniques makes the method very flexible. The problem is however that the quality of the design documentation is very hard to control and depends highly on the author. Implementing a minimal amount of existing techniques in SPDM, like a data flow diagram and an entity relation diagram at various decomposition levels, should


improve the structure of the method and the quality of the designs that result from the method, without taking away too much flexibility.

EVALUATING BY QUESTIONING General To back up the findings of the comparison with the Method Engineering framework a questionnaire was sent through the organization asking the employees about their experiences with SPDM. The questions that will be covered in this paper are only the relevant questions about problems employees experienced with SPDM, and about the quality of SPDM. The response rate on the questionnaire was 80%. An important factor in this high response rate is the culture of openness in SPMC. Problems with SPDM In this section of the questionnaire, employees were asked to specify whether they fully agreed (1), agreed (2), were neutral (3), disagreed (4) or fully disagreed (5) with the statements on problems with the design standards. In the rest of this section, a figure is shown with the results of the question. Beside the figure, a description will be given of what the question was and what can be concluded from the results. Communication between locations 35 30 25 20 15 10 5 0 1

2

3

4

5

The question: ‘The current design standards are not adequate for communication with SPMC developers at other locations’ Conclusion: An important function of the design documents is its communication function. It is therefore very important that the documents are perceived to be complete and clear by their target audience. Especially the foreign departments, where communication through the design documentation is most important, find that the design documents are not an adequate means of communication. To improve the quality of the designs it is important that SPDM is improved. Question: ‘Most functional documentation includes too many technical details’


Technical Detai 30 25 20 15 10 5 0 1

2

3

4

5

Conclusions: The results indicate that a majority thinks the functional designs contain too much technical detail. Employees in functions that are only interested in the functional information are less happy with the integrated functional and technical design document as for example the programmers are. It must be researched if it is necessary for the two documents to be separated. If not, the functional information should be clearly separated from the technical information so that people can easily skip sections they are not interested in. Missing Aspects 35 30 25 20 15 10 5 0 1

2

3

4

5

Question: ‘I miss many aspects in the current design standards for my type of function’ Conclusion: It is clear that most people find the design standard incomplete. The employees have given many examples of what is missing. These missing features should be evaluated, and if necessary added to the standard. Don't apply standards 60 50 40 30 20 10 0 1

2

3

4

5


Question: ‘It is not a problem if some Development departments do not apply standards’ Conclusion: SPMC should continue to use standards in creating design documents. It is however essential that SPDM is continually maintained and improved. Quality of SPDM In this section of the questionnaire, employees were asked to specify whether they fully agreed (1), agreed (2), were neutral (3), disagreed (4) or fully disagreed (5) with the statements on quality of the design standards. In the rest of this section, a figure is shown with the results on every question. Beside the figure, a description will be given of what the question was and what can be concluded from the results. Understanding 50 45 40 35 30 25 20 15 10 5 0 1

2

3

4

5

Question: ‘Usually I can understand the design documents fairly easily.’ Conclusion: The result shows that most employees do understand the design documents fairly easy. There is also a large group has more problems understanding the design documents. This group consists mostly of people with a nontechnical background that have a hard time understanding the integrated functional / technical design documents. Completeness 45 40 35 30 25 20 15 10 5 0 1

2

3

4

5

Question: ‘The SPMC design documents give a complete view of the SPMC product.’


Conclusion: The results clearly indicate that a lot is still missing in the standard. A reason for the incompleteness is the openness of SPDM that causes design documents of different authors to differ in quality. Level of detail 40 35 30 25 20 15 10 5 0 1

2

3

4

5

Question: ‘The level of detail in the functional design documents is sufficient.’ Conclusion: The result indicates that the level of detail in the functional designs is insufficient. Better guidelines must be given for the contents of the functional design. A better distinction between functional and technical information is also essential to keep an overview. Language 70 60 50 40 30 20 10 0 1

2

3

4

5

Question: ‘The use of text only (no graphic) is adequate for design documentation.’ Conclusion: The result of this statement indicates clearly that people find text-only design inadequate. It is therefore very important to create guidelines for using graphics (techniques) in the design documentation.

CONCLUSIONS AND RECOMMENDATIONS Conclusion Both comparing with the Method Engineering framework as the questionnaire showed that text-only design documents are not optimal. It is therefore very important that guidelines are added to the standards for the use of graphics and


techniques. This would make the designs easier to understand and in the end better structured. What techniques should be implemented should also be based on the background knowledge of the employees. Another conclusion is that it is better to separate the technical and functional information. Technical information from the existing integrated functional / technical design document should be placed in an obligatory technical design. The functional design should only contain functional information on the product. The standard should be changed in such a way that it is easy for people who are not interested in technical information to find the information they need. The third conclusion is that not all aspects are covered sufficiently in the standard. Many employees mention the information-oriented aspect, but also the lack of guidelines for the behavioral-oriented aspect is mentioned. The use of techniques would make the design more structured. By creating more structured designs, it will be easier to find the aspects missing. Recommendations Important things for the Software Process Improvement group of SPMC to do in the future are: • Research in the implementation of techniques and models in the standard. • Review of the available tools to support creating design documents including the techniques. • Develop sharper guidelines for handling the information aspect in the standard. • Add guidelines for the behavioral-oriented aspect in the standard. • When the standard is altered, education is an important issue to be considered. • Procedures concerning responsibilities must be added to SPDM. • Functional and technical information must be separated. The advantages and disadvantages of creating a separate technical design document must be evaluated.

REFERENCES Harmsen, F., Brinkkemper, S. and Oei, H. (1994). Situational Method Engineering for Information System Project Approaches, In Proceedings of IFIP WG 8.1, North-Holland: Elsevier Science Publishers. Kumar, K., and Welke, R.J. (1992). Methodology Engineering: A Proposal for Situation-Specific Methodology Construction, In Challenges and Strategies for Research in Systems Development, Wiley & Sons Ltd. Slooten, C. van (1995). Situated Methods for Systems Development, thesis University of Twente. Slooten, C. van (1996). Situated Method Engineering, In Information Resources Management Journal, Summer, 9(3), Hershey, PA: Idea Group Publishing.


Slooten, C. van, and Brinkkemper, S. (1993). A Method Engineering Approach to Information Systems Development, In Proceedings of IFIP WG 8.1, NorthHolland: Elsevier Science Publishers.

16 • Modelling Molecular Biological Information

Chapter 2

Modelling Molecular Biological Information: Ontologies and Ontological Design Patterns Jacqueline Renée Reich University of Manchester, United Kingdom The amount of available information in molecular biology is vast due to genome sequencing and gene expression chips. Nowadays, the challenge is to represent and manage the static and dynamic properties of DNA sequence data or annotated information to decipher the structural, functional and evolutionary clues encoded in biological sequences. Therefore, molecular biologists build and use ontologies to represent parts of the molecular biological terminology and to provide a model of biological concepts. Ontological Design Patterns (ODPs) provide a technique to increase the flexibility and reusability of these biological ontologies. There are many useful features of ODPs: 1) they describe simple, flexible and reusable solutions to specific design problems, 2) they can be defined and applied within informal or formal ontologies, 3) they make design approaches transferable, clarify the architecture, and improve the documentation of ontology-based knowledge systems, and 4) they form a framework to deal with different bioinformatics tasks, such as accessing and managing heterogeneous molecular biological databases, analysing scientific texts, or annotating sequence databases. Most of the ODPs are informally described in (Reich, 1999). All ODPs with code examples are available from the author.

Previously Published in Challenges of Information Technology Management in the 21st Century, edited by Mehdi Khosrow-Pour, Copyright © 2000, Idea Group Publishing.

Reich • 17

INTRODUCTION Molecular biology encompasses many disciplines each with their own terminology and nomenclature. It has a vast range of information sources and uses various analysis tools with specific semantics. Genome sequencing and gene expression chips are producing a large amount of information, causing the challenge to represent and manage the static and dynamic properties of DNA sequence data or annotated information. Nowadays, the structural, functional and evolutionary clues encoded in biological sequences are still to be deciphered. Parts of the content of molecular biological knowledge have to be specified and formalised to become machine-readable and be represented on the computer. To organise the molecular biological vocabulary and to provide a model of biological concepts and semantic relationships, molecular biologists build and use hierarchical ontologies (Altman et al. 1998). Ontologies may constitute knowledge bases and semantic frameworks to improve 1) the specification of existing or new database schemata, 2) the matching of data within heterogeneous databases, and 3) the sharing and reuse of knowledge. The matching of heterogeneous data presupposes the collaboration of software components in which, for instance, queries and assertions can be exchanged. Assembling reusable components of precisely specified knowledge can prevent the rebuilding of future knowledge segments from scratch. To increase the adaptability of an ontology to future demands and to avoid time consuming and expensive redesign, abstractions that emerge during design must be incorporated into the ontology (Guarino, 1997). This situation is comparable to software design, where the application of object-oriented design patterns is emphasised (Coad, 1992; Gamma et al., 1994). At this high level of abstraction Table 1: Ontological Design Patterns (ODPs) (Reich 1999) TerminologicalHierarchy ODP UpdateDependencies ODP DefinitionEncapsulation ODP ExpressionComposer ODP ChainOfExpressions ODP InteractionHider ODP TerminologyOrganizer ODP Mask-ODP UnspecificTerm-ODP AddDynamicInfo-ODP

to compose concepts and instances into part-whole hierarchies to notify interdependent concepts and instances if one concept is changed to define a family of definitions, and encapsulate each one same construction process for different concepts multiple concepts can fulfil a context concept encapsulates interaction of concepts and instances interface creates and organises concepts or instances, realised by sub-concepts to represent complete sub-concepts as instances to manage unspecific instances at fine granularities to add information and meaning dynamically


in ontology design, and also at lower levels of its specification and implementation, Ontological Design Patterns (ODPs) are useful (Reich, 1999). For instance, ODPs can be used to compose concepts and instances into part-whole hierarchies, to notify interdependent concepts and instances if one concept is changed, or to add information and meaning dynamically. So far, ten different ODPs are defined (Table 1), and most of them are informally described in (Reich, 1999). For general illustration, one ODP example, the TerminologicalHierarchy ODP, will be applied within the context of immunology and represented in C++ code.

ONTOLOGY DESIGN The term “ontology” is used by knowledge engineers to describe the representation of a precise domain of the real world. Such a description should be concise and non-ambiguous (Gomez-Perez et al., 1996). Ontologies make fundamental concepts, meanings, structures and relationships of information explicit and describe their constraints in an application area (Gruber, 1995). Generally, an ontology includes 1) concepts (e.g. human being), which are described by a definition and a set of attributes, 2) instances (e.g., Jacqueline), which are described by values or objects, and grouped into concepts, 3) attributes (e.g., eye-colour), which are described by a definition and semantic properties, and 4) relationships (e.g., “is a member of,” “is part of”). The definitions of concepts and attributes have to include information about the context and well-formed use of the terms. The construction of an ontological model system out of unlimited and unstructured information involves spatial, temporal, and functional limits and choices. Such a model organises, summarises, and generalises terminological knowledge to classify diverse information. The instances of concepts share some general features or properties according to their degree of distinction, similarity, or functionality, and the way they are mutually organised and related. The definition of concepts during the modelling of an ontology produces a dichotomy which imposes binary all or none classification decisions: either accept or reject an object as belonging to a given collection or category. Ontology design is an incremental and iterative process. An ontology has to be designed in a repetitive fountain-like and not in a non-repetitive waterfall-like approach (Booch, 1994). The design of non-trivial ontologies repeats the cycle of specification, classification and implementation several times, adjusting and improving properties, elements, behaviour, structures, and tasks. The capability to adjust ontologies is a precondition to enable them to follow the development and changes in on-going research and science. Temporal objectives of a specific ontology can influence how tightly sub-ontologies are designed, how they are factored into concepts and at which degree of granularity, which concept-interfaces and inheritance-hierarchies are defined, and which key-relationships are established among them.

Reich • 19

An ontology can be formal or informal (Cocchiarella, 1996; Uschold, 1996). A formal ontology uses, for instance, the restricted and structured notation of a model-specific formalism, such as Enhanced Entity Relationship (EER) (Booch, 1994; Rumbaugh et al., 1991), Unified Modelling Language (UML) (Larman, 1997), or a logical language, such as Description Logics (DL) (Horrocks, 1998). The formalism is chosen according to the final objective, such as EER for building a conceptual database schema or DL for automated reasoning. An informal ontology uses natural language and a free-text style to define a glossary. An example of some general ontologies is MicroKosmos (Mahesh et al., 1996) built for automatic text translation. GALEN is a more specific architecture for the language and knowledge of medicine (Rector et al., 1993, 1997). TAMBIS is a system for the transparent access to diverse biological information resources based on its own ontology (Baker et al., 1999). RIBOWEB is a specific information system for ribosomes (Altman, 1997).

ONTOLOGICAL DESIGN PATTERNS The task of modelling an ontology will be more straightforward if it can be jump-started with a set of Ontological Design Patterns (ODPs) to organise the terms and their relationships of a specific vocabulary. ODPs are designed to structure the most important phenomena of molecular biological information in many different contexts. ODPs are a formalisation to ensure that an ontology can be changed and reused in specific ways. ODPs name, abstract, and identify ontological design structures, individual terms, composed expressions, and related contexts. ODPs encapsulate changing semantic and scientific concepts either by concentrating or delegating information and meaning. Even though ODPs vary in their granularity and level of abstraction, they can still collaborate. The advantages of ODPs are that they 1) make it easier to reuse successful ontology designs and architectures, 2) help to make the best choice among design alternatives, and 3) improve the documentation and maintenance of existing ontologies by explicitly specifying the interactions between concepts or instances. ODPs provide an abstraction level to implement parts of an ontology less tightly and support its combination. The combination of ontologies means the integration of their concepts, relationships, attributes and instances (Neches et al., 1991; Gruber, 1993). Integration is more likely to occur if it takes place within a larger context, which is structured by specific ODPs, because ODPs can reduce the difficulties caused by contradictions and opposing views (Beys et al., 1996). Integration and reuse of ontologies should not only occur at the implementation level, e.g. by mixing Lisp or C++ functions from different applications (Calvanese et al., 1998), but also at the specification or design level. Therefore, ODPs support the integration and reuse of ontologies at the specification and implementation level.


TERMINOLOGICAL-HIERARCHY ODP The example of the TerminologicalHierarchy ODP is related to the informal ontology of immunology IMGT-ONTOLOGY (Giudicelli, 1998; Giudicelli and Lefranc, 1999) defined for the IMGT/LIGM-DB, the international ImMunoGeneTics database created by Marie-Paule Lefranc, Montpellier, France (http://imgt.cines.fr:8104) (Lefranc et al., 1999). Please note that only a very small fragment of the original ontology is realised in this ODP example. The objective is to illustrate one ODP from its informal context down to example code without forgetting the complexity of immunological information challenging the design. Immunological Background and Concepts of IMGT The immune system recognises and eliminates foreign molecules, such as pathogenic viruses, micro-organisms and parasites. Proteins called immunoglobulins (Ig) play important roles in immune responses (Honjo and Alt, 1995). The basic structural unit of an immunoglobulin consists of light (L) chains and heavy (H) chains. These chains are made up of a variable sequence at their aminoterminal ends (V-REGION), and of a constant sequence at their carboxyl-terminal ends (C-REGION). A single constant C-GENE encodes the C-REGION of an immunoglobulin chain. Two or more genes are rearranged and joined combined to encode each V-REGION. Each light-chain V-REGION is encoded by a DNA sequence assembled from two genes: a long variable V-GENE and a short joining or J-SEGMENT, which are or originally separated on the chromosome. Each heavy chain V-REGION is encoded by a DNA sequence assembled from three genes: a V-GENE, a J-SEGMENT, and a diversity segment, or D-SEGMENT. The informal ontology designed for IMGT/LIGM-DB (Giudicelli 1998, Giudicelli and Lefranc 1999) defines the nested concepts of Cluster, Entity, and Core among many others (Figure 1). Figure 1: Concepts and instances grouping the vocabulary and rules, which describe the state, the organisation and the composition of Ig and TcR sequences. concept level

instance level

cluster

cluster

entity

gene segment

core

region

Reich • 21

The concept Entity describes the characteristics of an Ig or T-cell receptor (TcR) gene as being genomic DNA or complementary DNA (cDNA). Genomic DNA includes non-coding introns, cDNA is complementary of the messenger RNA and, for mature spliced cDNA, without introns. A V-GENE, a D-SEGMENT, and a J-SEGMENT can be in a germline or rearranged configuration. The C-GENE has no defined configuration. The concept Entity is made by coding regions forming the concept called Core. An instance of Core is part of an instance of Entity. An Entity instance knows about its gene type, DNA nature, and its configuration. The coding regions of Core are found in the peptide chain of an Ig or TcR and in a set of motifs. The instances of the Core concept are called VREGION, D-REGION, J-REGION, and C-REGION. The motifs can be related to 1) a peptide signal, such as L-PART1, L-PART2, L-REGION, 2) splicing, 3) signals of recombination, such as 5’RS and 3’RS, and 4) sequences for regulation, such as promoters and enhancers (Figure 2). V-D-J-GENE is a genomic DNA. On its left side the coding motifs are mentioned, on its right side the non-coding concepts. PeptideSignal L_PART2 and the different Core regions V, D, and J form a composed motif, called the V-D-JEXON (adapted from Giudicelli 1998). At least two Entities in a DNA sequence define the concept and type of a Cluster. For instance, the Cluster V-(VDJ)-CLUSTER includes the two types of Entities V-GENE and V-D-J-GENE (Figure 3). The Cluster instance knows about its DNA nature, and its configuration. Figure 2: Components of the V-D-J-GENE coding

non-coding

PeptideSignal:L-PART1

PeptideSignal:L-PART2 Core:V-REGION Core:D-REGION Core:J-REGION

is-part-of

Promoter DONOR_SPLICE V-D-J-GENE is-part-of V-INTRON ACCEPTOR-SPLICE

is-part-of

Figure 3: V-(VDJ)-CLUSTER in a rearranged configuration, composed by several V-GENEs and a rearranged VDJ-GENE which form distinguished entities (adapted from Giudicelli 1998).

5'

V-GENE

V-GENE

V-GENE

V-D-J-GENE

V-REGION

V-REGION

V-REGION

V-REGION 3'


In Giudicelli (1998), a V-J-CLUSTER is informally defined as a genomic region in a germline configuration including at least one V-GENE, and one JSEGMENT. These clusters show a high degree of nesting and repetition. Using the TerminologicalHierarchy ODP, these immunological Clusters are organised into part-whole hierarchies describing recursive composition. Terminological Hierarchy ODP for an Immunological Example The Terminological Hierarchy ODP composes immunological information units and their concepts and attributes into unrestricted tree structures to represent part-whole hierarchies. This ODP was chosen for the part-whole concept-relationships of Clusters and Entities, or Entities and Cores (Figure 1). Generally, the

Figure 4: The concept of CDR3 and JUNCTION. Organization of the CDR3 in rearranged configuration with several rearranged D-REGIONs. The JUNCTION includes the CDR3 and the limiting codons at its 5’ and 3’ ends (dots) (adapted from Giudicelli, 1998). D-REGION J-REGION

V-REGION N-REGION CDR3 JUNCTION

Figure 5: TerminologicalHierarchy ODP user

DescriptionUnit GetConfiguration() GetDNAsequence() GetChild(DescUnit) Add(DescUnit) Remove(DescUnit) CreateIterator() children

CDR

Cluster

LengthAminoAcid()

NrOfEntities()

V-(VDJ)-CLUSTER

Reich • 23

TerminologicalHierarchy ODP can be applied in almost all hierarchy-based ontologies including nested part-whole components. A simple implementation of an ontology would define concepts for terminological primitives plus other concepts that act as containers for these primitives. According to the informal ontology for immunology (Giudicelli, 1998; Giudicelli and Lefranc, 1999), the concepts of Cluster and Entity are examples of containers, whereas the concept of Framework (FR) or ComplementarityDeterminingRegion (CDR) are examples of primitives. FR and CDR form variable V-REGIONs (Figure 4). The concept of Core could be understood as a container or as a primitive, because not all its instances have subelements, such as FR and CDR. The problem with the container-primitive approach is that on the implementation level of the ontology, the fundamental code referencing these concepts has to treat primitives and containers differently even if the final user of the ontology will treat them identically. Having to distinguish primitives and containers makes the ontology more complex. The TerminologicalHierarchy ODP describes how to recursively compose primitive instances or concepts into more complex expressions. The distinction of containers and primitives will become unnecessary, and users can treat primitive and composed information uniformly. The key to the TerminologicalHierarchy ODP is an abstract concept, called DescriptionUnit that represents both primitives and their containers. It declares meanings that all composed concepts and instances share. The primitive concepts of FR or CDR, defined as sub-concepts of DescriptionUnit, will have primitive instances, but no child DescriptionUnits. They implement their own version of getConfiguration or getDNAsequence. The nonprimitive concepts of Cluster and Entity define an aggregate of DescriptionUnit instances. Entity and Cluster implement getConfiguration or getDNAsequence to get this information from all their children and they implement child-related information and meaning accordingly. Because the Entity and Cluster interfaces conform to the DescriptionUnit interface, Entity and Cluster instances can compose other Entities and Clusters recursively. Algorithms To illustrate the TerminologicalHierarchy ODP, the example is partially coded in C++ code. This does not mean that ODPs are specific for the C++ language. ODPs are thought to be neutral to any implementation language presupposing that the chosen language is powerful enough to represent and code ODPs. The DescriptionUnit class defines an interface for all DescriptionUnit in the part-whole hierarchy:


class DescriptionUnit { public: virtual ~DescriptionUnit(); const char* Name() {return name;} virtual int GetDNAsequence(); virtual char* GetConfiguration(); virtual void Add(DescriptionUnit*); virtual void Remove(DescriptionUnit*); virtual void GetChild(DescriptionUnit*); virtual Iterator* CreateIterator(); protected: DescriptionUnit (const *char); private: const char* name; }; The DescriptionUnit class declares operations that return the attributes of a DescriptionUnit instance, such as its DNA sequence or configuration. Sub-classes will implement their own version of these operations. The DescriptionUnit class also declares a CreateIterator operation that returns an Iterator for accessing its parts. Sub-classes of DescriptionUnit might include leaf classes that represent primitives, such as Framework (FR) or ComplementarityDeterminingRegion (CDR). For instance, the CDR class has its own version of GetDNAsequence() and GetConfiguration(), and is extended by an operation to calculate the length of its amino acid. class CDR : public DescriptionUnit { public: virtual CDR(const char*); virtual ~CDR(); const char* Name() {return name;} virtual int GetDNAsequence(); virtual char* GetConfiguration(); virtual int LengthAminoAcid(); }; The class of Cluster and Entity are sub-classes of DescriptionUnit and form the basic class for clusters and entities that contain other clusters or entities. The class Entity can be implemented in an analogous way as shown for Cluster with an additional operation to get its gene type.

Reich • 25

class Cluster : public DescriptionUnit { public: virtual ~Cluster(); const char* Name() {return name;} virtual int GetDNAsequence(); virtual char* GetConfiguration(); virtual int NrOfEntities(); virtual void Add(Cluster*); virtual void Remove(Cluster*); virtual Iterator* CreateIterator(); protected: Cluster (const *char); private: List descriptionUnit; }; The Cluster class defines the operations for accessing and managing subclusters. The operations Add() and Remove() insert and delete clusters from the list of DescriptionUnit stored in the descriptionUnit variable. The operation CreateIterator() returns an iterator that will traverse this list. A default implementation of GetDNAsequence() might use CreateIterator to sum the DNA sequences of the sub-DescriptionUnit. In a similar way, NrOfEntities() would use the iterator to sum the number of entities integrated in the cluster instance. int Cluster::GetDNAsequence() { Iterator* i = CreateIterator(); DNAsequence = empty; (for i->First(); !i->isDone(); i->Next()) { DNAsequence += i->CurrentItem()>GetDNAsequence(); } delete i; return DNAsequence; } Now, a V-(VDJ)Cluster can be represented as a sub-class of Cluster called V-(VDJ)Cluster. The V-(VDJ)Cluster inherits the child-related operations from Cluster. class V-(VDJ)Cluster : public Cluster { public: V-(VDJ)Cluster(const char*); virtual ~V-(VDJ)Cluster();


virtual int GetDNAsequence(); virtual char* GetConfiguration(); virtual int NrOfEntities(); }; Assuming that other related concepts were defined, such as Entity, Core, or Framework(FR), then different clusters and entities could be assembled. Entity* entity = new Entity(“J-Segment”); Core* core = new Core(“J-Region”); entity->Add(core); cout ns ∈ Dom(L) If Lc is a sub link type resulting from a specialization over Lp, the set of (ns, nd) tuples defined by Lc is a subset of the one defined by Lp. As a consequence, Lc’s domain should be the same as or define a subset of (i.e. a sub node type or an aspect type) of Lp’s domain: Lc ⊂ Lp => ((ns, nd) ∈ Lc => (ns, nd) ∈ Lp) Dom(Lc) ⊆ Dom(Lp) If the domains are the same, we speak of a sub link type resulting from a horizontal specialization. If the sub link type is inherited in a sub node type or aspect type, we speak of a vertical specialization. A vertical link specialization is the consequence of a parallel classification over

Lemahieu • 47 Dom(Lp)

E.g.:

Lp

Dom(Lc)

Employee

Is-member-of

Manager Lc

Is-manager-of

Lc ⊂ Lp, Dom(Lc) ⊂ Dom(Lp) Lp

E.g.:

Dom(Lp)

Is-member-of

Employee Is-manager-of

Lc

Lc ⊂ Lp, Dom(Lc) = Dom(Lp)

the links’ source nodes, in either node subtypes or aspect types. The term denotes that each sub link type is attributed at a “lower,” more specific level in the node typing hierarchy than its parent; since Lc’s domain is a subset of Lp’s domain and they both model similar semantics, the respective associated sets of tuples will be subsets too. If Lc and Lp share the same domain, Lc can still define a subtype of Lp in the case where Lc models a more restricted, more specific kind of relationship than Lp, independently of any node specialization. Both parent and child link type are attributed at the same level in the node type hierarchy, hence the term horizontal specialization. Cardinalities of a sub link type A link type’s cardinalities determine the minimum and maximum number of link instances allowed for a given source node. If the domain is an aspect type, the cardinalities pertain to a node’s corresponding aspect. MinCard(L) = 1 ∀ns ∈Dom(L): ∃ (ns, nd) ∈ L MaxCard(L) = 1 [∀ ns ∈ Dom(L): (ns, nd1) ∈ L & (ns, nd2) ∈ L nd1 = nd2]

Parent link type cardinality

Upon overriding link type cardinalities, care should be taken so as not to violate the parent’s constraints, particularly in case of a non-disjoint classification. The following

(0,n) (0,n) (0,1) (1,n) (0,n) (0,1) (1,n) (1,1) (0,1) (0,1) (1,1) (0,1)

Horizontal link specialization

Parent link type cardinality

Aspect descriptor cardinality (0,n) (1,n) (0,n) - (0,n) (1,n) (0,1) (1,1) - (0,n) (1,n) (0,1) (1,1) (1,n) (1,n) (1,1) (0,1) - (0,1) (1,1) - (0,1) (1,1)

(1,1)

(0,1) - (0,n) (1,n) (0,1) (1,1) - (0,1) (1,1)

(1,1)

Vertical link specialization

(1,1) - (0,n) (1,n) (0,1) (1,1) (1,n) (1,1) - (0,1) (1,1)

(1,1)

48 • An Object-Oriented Approach to Conceptual Hypermedia Modeling

tables present feasible combinations, respectively in function of a horizontal and a vertical specialization over a given parent link type. Only the results are shown, for further details we refer to Lemahieu (1999). Note that a “-” sign stands for “not inherited.” Moreover, the mechanism for link type inheritance in a “real” node subtype is similar to delegation to a (1,1) aspect descriptor, as represented in the rightmost column. Inverse of a sub link type The inverse link type is the most specific link type that encompasses all of the original link type’s tuples, with reversed source and destination. There are two possibilities. If the “inverse-of” relationship is mutual, we speak of a particular inverse, notation: L ↔ Inv(L). If this is not the case, we speak of a general inverse, notation: L −> Inv(L). A particular inverse models a situation where two link types are each other’s inverse. Not counting source and destination’s sequence, the two link types represent the same set of tuples. The term particular inverse is used because no two link types can share the same particular inverse. L ↔ Inv(L) [(ns, nd) ∈ L (nd, ns) ∈ Inv(L)] L = Inv(Inv(L)) E.g. employee.is-member-of ↔ department.members A child link type can override its parent’s inverse with its own particular inverse, which is to be a subtype of the parent’s inverse. E.g. employee.is-manager-of ↔ department.manager However, if no suitable particular inverse exists for a given child link type, it has to inherit its parent’s inverse as a general inverse, without overriding. Hence a general inverse can be shared by multiple link types with a common ancestor. As to a general inverse, the set of tuples represented by L is a subset of the one represented by Inv(L). This is equal to stating that L ℘ Inv(Inv(L)). L − > Inv(L)[((ns, nd) ∈ L = > (nd, ns)∈ Inv(L)), ∃ (nd’, ns’) ∈ Inv(L): (ns’, nd’) ∈ L] ⁄ L ⊂ Inv(Inv(L)) The general inverse of a child link type must be the particular inverse of one of this child’s ancestors. E.g. employee.is-manager-of ↔ department.members Summarizing, a child link type either inherits its parent’s inverse as a general inverse, or the inverse property is overridden with a subtype of the parent’s inverse becoming the particular inverse of the child link type: Lc ⊂ Lp [(∃ Kc: Lc ↔ Kc, Kc ⊂ Inv(Lp)) or (Lc Inv(Lp))]

Lemahieu • 49

Link type specialization properties Properties for node type specialization determined whether the latter was total and/or disjoint. On the other hand, no such properties are attributed to a link type classification itself. Without a concession to generality, we can force each specialization to be total by defining an additional child link type LcRest where necessary, to collect instances of the parent that could not be classified into any of the other children. Each (ns, nd) tuple that belongs to the parent link type Lp, also belongs to at least one of its subtypes Lci. Lp := Lc1 U Lc2 ULc3U Lc4U … U LcRest [(∀ Lci: Lci ⊂ Lp) & (∀(ns, nd) ∈ Lp: ∃ Lci: (ns, nd) ∈ Lci)] Whether overlapping subtypes are allowed is not enforced at the specialization level, but as a property of each subtype separately, leaving space for a finer granularity. This is accomplished by a child link type’s singularity property, which denotes whether its instances are allowed to also belong to sibling child types. E.g. we can force LcRest to be disjoint to any other child link type by denoting it as a singular link type. Just like node types can have multiple aspect descriptors, multiple classifications can be defined over a link type. Since each classification should be total, the union of all sub link types described by one such specialization returns the full parent link type. Conversely, each instance of the parent link type should also belong to at least one subtype for each specialization defined. E.g., department.members can be subclassed according to either a person’s function (worker, clerk or manager), or his mode of employment (full-time or part-time). Two sets of sub link types result, any instance of department.members will have to be classified according to both criteria: department.members := department.workers » department.clerks » department.manager := department.full-time-members » department.part-time-members Whereas the data model introduced in this paper could stand on its own to support the analysis and design of hypermedia applications, its full potential only becomes apparent in the light of its role as a foundation to the context-based navigation paradigm, briefly discussed in the next section.

MESH’S CONTEXT-BASED NAVIGATION PARADIGM The navigation paradigm as presented in MESH combines set-based navigation principles with the advantages of typed links and a structured data model. The typed links allow for a generalization of the guided tour construct. The latter is defined as a linear structure that eases the burden placed on the reader, hence reducing disorientation. As opposed to conventional static guided tour implementations, MESH allows for complex structures of nested tours among related nodes to be generated at run-time,


depending upon the context of a user’s navigation. Such context is derived from abstract navigational actions, defined as link type selections. Indeed, apart from selecting a single link instance, similarly to the practice in conventional hypermedia, a navigational action may also consist of selecting an entire link type. Selection of a link type L from a given source node ns results in a guided tour along a set of nodes being generated. This tour includes all nodes that are linked to the given node by the selected link type: ns.L := {nd∧(ns, nd) ∈ L}. Navigation is defined in two orthogonal dimensions: on the one hand, navigation within the current tour yields linear access to complex webs of nodes related to the user’s current focus of interest. On the other hand, navigation orthogonal to a current guided tour, changing the context of the user’s information requirements, offers the navigational freedom that is the trademark of hypertext systems. In addition, the abstract navigational actions and tour definitions sustain the generation of very compact overviews and maps of complete navigation sessions. This information can also be bookmarked, i.e., bookmarks not just refer to a single node but to a complete navigational situation, which can be resumed at a later date.

A GENERIC APPLICATION FRAMEWORK The information content and navigation structure of the nodes are separated and stored independently. The resulting system consists of three types of components: the nodes, the linkbase/repository and the hyperbase engine. Although a platformindependent implementation framework is provided, all actual prototyping is explicitly targeted at a Web environment. A node can be defined as a static page or a dynamic object, using e.g. HTML or XML. Its internal content is shielded from the outside world by the indirection of link types playing the role of a node’s interface. Optionally, it can be endowed with the intelligence to tune its reaction to the context in which it is accessed. Indeed, by integrating a node type’s set of attributed link types as a parameter in its layout template’s presentation routines, the multimedia objects that are most relevant to this particular link type can be made current upon node access, hence the so-called context-sensitive visualization principle. Since a node is not specified as a necessarily searchable object, linkage information cannot be embedded within a node’s body. Links, as well as meta data about node types, link types, aspect descriptors and aspects are captured within a searchable linkbase/repository to provide the necessary information pertaining to the underlying hypermedia model, both at design time and at run-time. This repository is implemented in a relational database environment. Only here, references to physical node addresses are stored, these are never to be embedded in a node’s body. All external references

Lemahieu • 51

are to be made through location independent node ID’s. The hyperbase engine is conceived as a server-side script that accepts link (type) selections from the current node, retrieves the correct destination node, keeps track of session information and provides facilities for generating maps and overviews. Since all relevant linkage and meta information is stored in the relational DBMS, the hyperbase engine can access this information by means of simple, pre-defined and parameterized database queries, i.e., without the need for searching through node content.

CONCLUSIONS Other hypermedia approaches such as EORM, RMM, HDM and OOHDM are also based on conceptual modeling abstractions, either through E.R. or O.O techniques. Among these, OOHDM is the only other methodology to explicitly incorporate a subtyping and inheritance/overriding mechanism. However, subtyping modalities are not explicitly stipulated. Rather, they are borrowed from OMT (Rumbaugh et al., 1991), a general-purpose object-oriented design methodology. MESH2 deploys a proprietary approach, specifically tailored to hypermedia modeling, where structure and relationships prevail over behavior as important modeling factors. Its full O.O. based data modeling paradigm should allow for hypermedia maintenance capabilities equaling their database counterpart; with unique object identifiers, monitoring of integrity, consistency and completeness checking, efficient querying and a clean separation between authoring content and physical hyperbase maintenance. MESH is the only approach to formulate specific rules for inheriting and overriding layout and link type properties, taking into account the added complexity of plural (possibly overlapping and/or temporal) node classifications. Links are treated as first-class objects, with link types being able to be subject to multiple specializations themselves, not necessarily in parallel with node subtyping. Authoring is greatly facilitated by O.O. features such as inheritance and overriding, class properties and layout templates that allow for high-level specification and lower-level refinement of node properties. Also, the meta information present in the hyperbase enables the automated suggestion of appropriate links. Finally, it is clear that a model-based approach in general facilitates information sharing, reuse, development in parallel, etc. Another benefit of these abstractions is that navigational actions are specified and anchored on an abstract level as link type selections, independent of actual node and link instances, which again facilitates authoring and improves maintainability. The context-based navigation paradigm supports a completely automated generation of guided tours, maps and indices, in contrast to, e.g., RMM, HDM and OOHDM, where these are conceived as explicit design components, requiring extensive authoring efforts. In MESH, the author is not even engaged in their realization. As to the end user, apart from the obvious benefit of a well-maintained hyperbase,


typed links should permit a better comprehension of the semantic relations between information objects. The use of higher-order information units and the representation of collections of nodes as (source node, link type) combinations, induces a stronger sense of structure. A node typing hierarchy with consistent layout and user interface features, reflecting similarities between nodes, is to further increase the user’s ability to grasp this underlying data structure. The abundance of meta-information as node, aspect and link types allows for enriching maps and overviews with concepts of varying granularity. Obviously, orientation is also improved by the data model supporting the context-based navigation paradigm and context-sensitive node visualization.

NOTES 1

2

We deliberately opted for a single inheritance structure however, aspects can provide an elegant solution in many situations that would otherwise call for multiple inheritance, much like interfaces in the Java language. See Lemahieu, (1999) for further details. This evaluation mainly focuses MESH’s data modeling side. For a thorough discussion of the entire framework, we refer to Lemahieu (1999).

REFERENCES Ashman, H., Garrido, A., and Oinas-Kukkonen, H. (1997). Hand-made and Computed Links, Precomputed and Dynamic Links, Proceedings of Hypertext - Information Retrieval - Multimedia (HIM ’97), Dortmund, September. Bapat, A., Wäsch, J., Aberer, K. and Haake, J. (1996). An Extensible ObjectOriented Hypermedia Engine, Proceedings of the seventh ACM Conference on Hypertext (Hypertext ’96), Washington D.C., March. Beitner, N., Goble, C., and Hall, W. (1995). Putting the Media into Hypermedia, Proceedings of the SPIE Multimedia Computing and Networking 1995 Conference, San Jose, February. Botafogo, A., and Shneiderman, B. (1991). Identifying Aggregates in Hypertext Structure, Proceedings of the third ACM Conference on Hypertext (Hypertext ’91), San Antonio, November. Chen, P. (1976). The entity-relationship approach: Toward a unified view of data, ACM Trans. Database Syst. 1(1), January. Davis, H., Hall, W., Heath, I., Hill, G., and Wilkins, R. (1992). MICROCOSM: An Open Hypermedia Environment for Information Integration, Computer Science Technical Report CSTR 92-15. Duval, E., Olivié, H., Hanlon, P., and Jameson, D. (1995). HOME: An Environment for Hypermedia Objects, Journal of Universal Computer Science 1(5), May.

Lemahieu • 53

Garg, P. (1988). Abstraction mechanisms in hypertext, Commun. ACM, 31(7), July. Garzotto, F., Mainetti, L., and Paolini, P. (1995). Hypermedia Design, Analysis, and Evaluation Issues, Commun. ACM 38(8), August. Garzotto, F., Paolini, P., and Schwabe, D. (1993). HDM - A Model-Based Approach to Hypertext Application Design, ACM Trans. Inf. Syst., 11(1), January. Ginige, A., Lowe, D. and Robertson, J. (1995). Hypermedia Authoring, IEEE Multimedia 2(4), Winter. Haan, B., Kahn, P., Riley, V., Coombs, J., and Meyrowitz, N. (1991). IRIS hypermedia services, Commun. ACM 35(1), January. Halasz, F. (1988). Reflections on NoteCards: Seven Issues for Next Generation Hypermedia Systems, Commun. ACM 31(7), July. Hall, W., Heath, I., Hill, G., Davis, H., and Wilkins, R. (1992). The Design and Implementation of an Open Hypermedia System, Computer Science Technical Report CSTR 92-19, University of Southampton. Isakowitz, T., Kamis, A. and Koufaris, M. (1998). The Extended RMM Methodology for Web Publishing, Working Paper IS-98-18, Center for Research on Information Systems, (Currently under review at ACM Trans. Inf. Syst.) Isakowitz, T., Stohr, E. and Balasubramanian, P. (1995). RMM, A methodology for structured hypermedia design, Commun. ACM 38(8), August. Jacobson, I., Christerson, M., Jonsson, P., and Övergaard, G. (1992). ObjectOriented Software Engineering, Addison-Wesley, New York. Knopik, T., and Bapat, A. (1994). The Role of Node and Link Types in Open Hypermedia Systems, Proceedings of the sixth ACM European Conference on Hypermedia Technology (ECHT ‘94), Edinburgh, September. Lange, D. (1994). An Object-Oriented design method for hypermedia information systems, Proceedings of the twenty-seventh Hawaii International Conference on System Sciences (HICSS-27), Hawaii, January. Lemahieu, W. (1999). Improved Navigation and Maintenance through an Object-Oriented Approach to Hypermedia Modeling, Doctoral dissertation (unpublished), Leuven, July. Meyer, B. (1997). Object-Oriented Software Construction (2nd ed.), Prentice Hall Professional Technical Reference, Santa Barbara. Meyrowitz, N. (1986). Intermedia: The Architecture and Construction of an Object-Oriented Hypermedia System and Applications Framework, Proceedings of the Conference on Object-oriented Programming Systems, Languages and Applications (OOPSLA ’86), Portland, September. Nanard, J., and Nanard, M. (1995). Hypertext Design Environments and the Hypertext Design Process, Commun. ACM 38(8), August.


Rivlin, E., Botafogo, R., and Shneiderman, B. (1994). Navigating in hyperspace: designing a structure-based toolbox, Commun. ACM 37(2), February. Rumbaugh, J., Blaha, M., Premerlani, W., Eddy, F., and Lorensen, W. (1991). Object Oriented Modeling and Design, Prentice Hall, Englewood Cliffs. Schwabe, D., and Rossi, G. (1998). An O.O. approach to web-based application design, Draft. Schwabe, D., and Rossi, G. (1998). Developing Hypermedia Applications using OOHDM, Proceedings of the ninth ACM Conference on Hypertext (Hypertext ’98), Pittsburgh, June. Schwabe, D., Rossi, G., and Barbosa, S. (1996). Systematic Hypermedia Application Design with OOHDM, Proceedings of the seventh ACM conference on hypertext (Hypertext ’96), Washington DC, March. Snoeck, M., Dedene, G., Verhelst, M., and Depuydt, A. (1999). Object-Oriented Enterprise modeling with MERODE, Universitaire Pers Leuven, Leuven. Thüring, M., Haake, J., and Hannemann, J. (1991). What’s ELIZA doing in the Chinese Room - Incoherent Hyperdocuments and how to Avoid them, Proceedings of the third ACM Conference on Hypertext (Hypertext ’91), San Antonio, November. Thüring, M., Hannemann, J., and Haake, J. (1995). Hypermedia and Cognition: Designing for comprehension, Commun. ACM 38(8), August. Wiil, U., and Leggett, J. (1992). Hyperform: Using Extensibility to Develop Dynamic, Open and Distributed Hypertext Systems, Proceedings of the fourth ACM European Conference on Hypermedia Technology (ECHT ‘92), Milan, December. Wiil, U., and Leggett, J. (1997). Hyperform: a hypermedia system development environment, ACM Trans. Inf. Syst. 15(1), January.

Strauch & Winter • 55

Chapter 5

Conceptual Modeling of Large Web Sites Bernhard Strauch and Robert Winter University of St. Gallen, Switzerland

Current web site development is still dominated by technical issues. In order to enable efficient communication between developers and to provide a stable foundation for adopting new technologies, web sites should be derived from conceptual models. Based on the state-of-the-art of conceptual modeling as implemented in current CASE environments as well as web site development tools, the “essence” of a web site is identified, and an adequate conceptual meta model is proposed. Appropriate web site models are intended to capture not only hierarchical document structure and hypertext semantics, but also dynamical page generation from databases as well as explicit and implicit navigation. It becomes evident that web sites can be regarded as supersets of traditional information systems, thereby requiring conceptual modeling to include various additional features. The proposed meta model comprises several classes of information objects, various types of associations, design rules, and quality checks. For illustration purposes, the model is applied to an existing web site. Commercial web site development tools are analyzed with regard to the extent to which they support conceptual web site modeling.

INTRODUCTION Early systems development was dominated by using authoring tools (“editors”) to manually edit procedural program code. As a consequence, hand-writPreviously Published in Challenges of Information Technology Management in the 21st Century, edited by Mehdi Khosrow-Pour, Copyright © 2000, Idea Group Publishing.

56 • Conceptual Modeling of Large Web Sites

ten code mixing up data usage and functional aspects was difficult to maintain (Martin, 1982). Besides of expensive quality control and communication problems among developers, the resulting code suffered from various implementation dependencies, thereby forcing developers to re-do large portions of the development process when technical details (e.g., file structures, access paths) change. A rather similar approach can be observed when looking at today’s web site development practice (Rosenfeld & Morville, 1998). By creating web sites using HTML authoring tools, complex code is created that does not only mix up appearance and contents, but also depends widely on implementation details. Moreover, the utilization of different authoring tools complicates communication between developers. As an example, the following problems usually occur with regard to navigation when different web sites have to be integrated: • Navigation is interpreted and implemented in different ways depending on the authoring tool in use. Different tools use identical terms for different concepts or different terms for identical concepts. • Navigation is not based on user requirements for optimal access to information objects or associations between information objects (see e.g., Morville & Rosenfeld, 1998; Richmond, 1999). Instead, implementation details like various frame variants dominate design. • As a consequence, similar navigational concepts are implemented (and specified) in different ways so that explicit integration efforts are necessary to identify common structures and implement them consistently. In order to enable efficient communication between developers and to provide a stable foundation for adopting new technologies, conceptual modeling of web sites is essential. We understand web sites as server components of distributed applications which use the HTTP protocol to exchange data between servers and clients (“browsers”). By this definition, the principal problem of web site development becomes apparent: Even the relevant class of application components is defined by technical attributes (HTTP protocol, server functionality) instead of conceptual differences. Conceptual modeling should be independent of all technical and application dependent details. Before analyzing conceptual issues in web site design, proposing an appropriate conceptual model, and checking support potentials of current web site development tools, therefore, we should discuss whether our initial definition is appropriate, i.e., to what extent web sites conceptually differ from traditional information systems. Web Sites vs. Traditional Information Systems Traditional business applications support business processes by implementing data entry and data manipulation of business transactions. Web applications go beyond this functionality by integrating different media for information repre-


sentation and by hypertext functionality, thereby supporting not only the handling of business transactions, but also the storage and transfer of knowledge. As a consequence, not only organizational, functional, and data views of business processes have to be specified during conceptual modeling. In addition, complex knowledge components and their associations should be specified to enable flexible access and efficient navigation. As an example, the data view of traditional information systems development and web site development is compared: A traditional data model comprises types of structured information objects (e.g., order, customer, product) along with their attributes, types of relationships between information object types (e.g., generalization dependencies, existential dependencies), and consistency constraints. All modeling is done on a type level. Of course, all of these elements types can be found in the data model of a web site. But a web site representing complex knowledge may also comprise the following additional element types: • various one-of-a-kind information objects (i.e., single object instances not belonging to any object type, e.g., a mission statement) • various types of unstructured information objects (e.g., documents), and • additional types of associations between information objects (e.g., “part-of” relationships used for structuring a knowledge domain and “association ” relationships used for navigation within a knowledge domain). Related Work and Overview The lack of conceptual structures in hypertext documents has been addressed long before the World Wide Web emerged: “Without additional structuring mechanisms often very large, global and flat hypermedia networks (or hyperdocuments) are created which are hard to understand for readers. Users often become disoriented and a carefully directed search for a particular information object is more complicated in such networks” (Marmann & Schlageter, 1992). The HYDESIGN model (Marmann et al., 1992) proposes classes of (hypermedia) objects comprising “atomic nodes,” “SBL nodes,” and links between those nodes. Atomic nodes inherit general class properties and represent content. SBL (Structure Behavior Locality) nodes represent additional information: Structure defines how nodes and links can be connected, behavior defines the dynamics of nodes and links, and locality defines a “local” environment, i.e., a sub-module of the hypermedia network. By this approach, important conceptual constructs like navigation paths or aggregate objects (= sub-networks) are introduced into hypermedia design. When hypermedia design approaches (e.g., De Bra & Houben, 1992; Diaz, Iskowitz, Maiorana & Gilabert, 1995; Isakowitz, Stohr & Balasubramanian, 1995; Marmann et al., 1992) are used for the conceptual design of web sites,


however, important aspects like common standards of web navigation, interface design, conceptual differences between links, and overall site design are not taken into account. Since many problems addressed by hypermedia design like “disorientation” or “cognitive overhead” are also prevailing in large web sites, however, the basic approach of a hierarchical, recursive model of node classes and link classes is useful for web site design. But in addition to static links between particular documents, common standards of web navigation imply dynamic links: “Dynamic nodelink binding has greater potential for increasing the flexibility and maintainability of a hypermedia network” (Chen, 1997). In De Bra et al. (1992), nodes (“information chunks”) are complemented by “anchors” that define which components of a node are linked to other nodes. With the widespread use of the World Wide Web, many dedicated approaches to conceptual design of web sites have been proposed (e.g., Lyardet, Mercerat & Miaton, 1999; Lynch & Horton, 1999). Most approaches, however, either do not cover dynamic generation of web sites from databases and experience from traditional information systems design which are crucial for engineering very large web sites, or do not separate technical issues from conceptual modeling. According to W3DT (initially called SHDT) (Bichler & Nusser, 1996; W3DTTEAM, 1996), the development process comprises seven steps, guiding the designer from requirements analysis to implementation of the web site. For the first phase (requirements analysis), a collection of methods to determine user requirements is provided. The design phase is divided into information structuring, navigational design, organizational design, and interface design. Information structuring and navigational design is understood as an iterative mental process where a large knowledge domain has to be organized and structured into information objects, which are then linked and evaluated. Organizational design assigns information on maintenance and organizational integration to the information objects. When the design phase is completed, the information objects are implemented by HTML pages and gateway scripts, and the access structures of the model are implemented by links within the WWW site. The W3DT research group has shown that it is possible to capture the navigational structure of real-world web sites. In W3DT’s meta model, a web site is composed of pages, links, and layouts. While layout is not further specified, two different types of links and four different types of pages are differentiated. This simple classification, however, is not sufficient to capture the increased complexity of current HTML pages. Moreover, it is not differentiated between page templates and page contents. Following this introduction, we try to identify the implementation independent specification (“essence” (McMenamin & Palmer, 1984)) of a complex web site.


Then an appropriate meta model is proposed that captures not only hierarchical document structure and hypertext semantics, but also allows for an implementation by dynamical page generation from databases and using various approaches to explicit and implicit navigation. Basic design rules for the proposed conceptual model are presented and current web site development tools are analyzed with regard to extent to which conceptual web site modeling is supported.

THE “ESSENCE” OF A WEB SITE The benefits of conceptual modeling result from creating stability: Often contents change, but the general page structure remains unchanged. At other occasions, templates change, but contents remain stable. For conceptual modeling of web sites, therefore, content should be separated from navigational structure, navigational structure should be separated from layout (i.e., general page structure), and layout should be separated from content. But if all implementation-related specifications are to be neglected, what is then the essence of a web site? As for traditional applications, organizational, functional, and data aspects of business transactions have to be specified. In addition, representation and access aspects of complex information areas have to be specified by means of • (structured and non-structured) information objects, • “part-of” (i.e., hierarchical) relationships between information objects, and • “associative” (i.e., non-hierarchical) relationships between information objects. Information objects may be one-of-a-kind instances that do not match any type definition, or may be instances of some type of information objects. They may be administrated internally (i.e., within the same organizational context as the web site) or externally. They may be implemented by operating system files, file records, tuples of relational tables, or mail accounts. Hierarchical relationships may be implemented by file system structure, HTML navigation, or by applets. Non-hierarchical relationships may be implemented by hyperlinks, mailtos, or downloads. Information objects may be complex, i.e., may comprise several components. As a consequence, we have to represent • components of information objects (e.g., character strings, pictures, textual tables) and • hierarchical relationships between information objects and their components. Information object components are usually implemented by operating system files or tuples of relational tables. Hierarchical component links may be implemented by physical inclusion, as reference using frame or border techniques, or using style sheets.


Why Should Information Objects and Their Components Be Differentiated? The easiest conceptual interpretation of a web site is a multi-stage “assembly” of elementary information objects. However, information objects should be differentiated from their components: Information object contents change often. Since conceptual models should provide some basic amount of stability, it is necessary to differentiate a stable and a volatile part in the “assembly” structure of a web site. Information objects denote the borderline between the volatile and the stable portion of the network: While their contents change often (which has to be reflected in updating components and/or updating hierarchical component structure), their conceptual representation is stable so that the “upstream” portion of the web site remains unchanged. Status, employee assignments, schedule, available documents, and other attribute-like properties of a project change quite often, while its organizational embedding and its links to other projects remain quite stable. As a consequence, project documents should be regarded as information object components, while the project itself should be regarded as an information object. In systems implementation, the differentiation of information objects from their components is reflected making the former accessible by hyperlinks, while the latter can not be separately accessed. Information object components are the building block of every web site. Information objects can be identified as simplest information component aggregates that guarantee some degree of stability. Navigation areas are those portions of a web site which are so tightly coupled that some degree of navigation traffic is to be expected. Web sites are those portions of the World Wide Web whose contents can be updated in some organizational context. The resulting conceptual structure of the World Wide Web can be interpreted as a five level hierarchy. The web site level, the navigation area level, and the component level may comprise several sub-levels to reflect organizational responsibilities (web site level), relationships between information objects (navigation area level), and information object structure (component level).

CONCEPTUAL MODEL Based on the previous discussion, the various types of elements of the conceptual model are presented in this section. • Components of information objects • Structured classifiable components This class of components represents information that can be regarded as an instance of some generalized class of information with certain attributes. For example, data about a person’s publications are structured because every pub-


•

•

•

• • •

•

lication has certain attributes and are classifiable because each data is an instance of a common class “publication.” For structured classifiable components, structure and contents can be separated. Unstructured classifiable components This class of components represents information that can be regarded as an instance of some generalized class of information, but has no common attributes within that class. E.g., job descriptions may not follow some formal structure, but are nevertheless classifiable because each job description is an instance of a common class “job description.” For unstructured classifiable components, structure cannot be separated from contents. Structured, one-of-a-kind components This class of components represents information that does not belong to some generalized class of information, but comprises certain attributes. E.g., a form is a structured, one-of-a-kind component because every form has certain attributes (layout, boilerplate texts, field names, etc.), but cannot be assigned to some common meaningful class. For structured one-of-a-kind components, structure and contents can be separated. Unstructured, one-of-a-kind components This class of components represents information that neither belongs to some generalized class of information nor has certain attributes. E.g., a mission statement is an unstructured, one-of-a-kind component because only one such text exists within a web site, and no general statement structure is available. For unstructured one-of-a-kind components, structure cannot be separated from contents. Information objects (Internal) Informational objects Information objects are the simplest information component aggregates that guarantee some degree of stability. Navigators Navigators are application components that allow users to efficiently navigate within some portion of the web site. In contrast to ordinary information objects, navigators represent informational structure instead of the information itself. However, navigators are composed of several components so that they represent a subclass of information objects. External information objects External information objects are not part of a web site, but can be accessed from that web site, e.g. by hyperlinks. In contrast to internal information objects, the structure of external information objects is unknown. At most, some basic structural information can be generated from the URL extension (HTML,


• • • •

•

IDC; HTX, ASP, NSF, CGI, etc.). Relationships Hierarchical relationships Hierarchical relationships represent “part-of” links between internal information objects. Navigators usually are based on hierarchical relationships. Associative relationships Associative relationships represent associations between information objects that are not related hierarchically or by navigators. Navigational relationships Navigational relationships represent associations between (internal and external) information objects and navigators. In contrast to hierarchical and associative relationships that are used to represent information semantics, navigational relationships represent the application interface are and used to support the browsing process (Morville & Rosenfeld, 1998). Component relationships Component relationships represent the structure of internal information objects. In contrast to hierarchical and associative relationships, component relationships do not imply any hypertext functionality.

Notation We denote the element types of the conceptual model as follows: • Components of information objects Classifiable Structured Unstructured

• Information objects (Internal) information object Navigator

N

External information object

X

One-of-a-kind


Figure 1. Example conceptual web site schema Level 0

Level 1 N ews

Index

X

N1 N2

Level 2a

X Inform ation

O verview

C urriculum

P ersonal F acts

C hair 2

X

Level 3

S taff O verview

C hair 3 S tart Im age S earch F orm

R esearch O verview

O verview

Introduction

O verview

X X

C ourses

P ublications

O verview

C C/P roject

Level 2b

E xternal courses

C ourse description

O verview

X

O pen P ositions

M ailto:

C C W ebsite

O verview M ailto: Intranet O verview

C ourses held by IW I1

...

▼ ▼

▼ ▼

• Relationships Hierarchical relationship Associative relationship ••••••••••••••••••••••••••• Navigational relationship –••–••–••–••–••–••–••–••– Component relationship Figure 1 illustrates the application of the proposed model to an existing web site of an university workgroup. The levels are related to hierarchical relationships within the information objects of the web site.

• • • •

Quality The proposed conceptual model implies the following quality controls: Within the web site All hierarchical relationships must link an internal information object to one or more internal information objects All associative relationships must link an internal information objects to one or more internal or external information objects All navigational relationships must link a navigator to one or more internal or external information objects All component relationships must link an internal information object to one or more components


Within the World Wide Web • All URLs referenced by associative or navigational relationships must exist

DESIGN RULES For conceptual modeling of a web site, model elements, graphic notation, and quality controls have to be complemented by some basic methodology, i.e. at least by basic design rules and a recommendation of a certain sequence of design phases. Based on our experience with web site design and the discussion of essential web site elements, we propose the following task sequence: 1) Identification of information objects Whether an information representation is an information object or should be regarded as a component of an information object should be decided by analyzing its update behavior: If frequent updates can be expected not only for its contents, but also for its relationships, it should be represented as a component. If updates will mostly be restricted to contents, it may be represented as an information object. 2) Creation of hierarchical structure In contrast to associative relationships, hierarchical relationships create a consistent directed graph of information objects. Based on the hierarchy, levels of the conceptual web site schema can be identified (see figure 1). All hierarchical relationships link an information objects on level n to one or more information objects on level n+1. Since hierarchical relationships help to structure the knowledge domain to be modeled, conceptual modeling should start with building hierarchical relationships. 3) Creation of associative structure All semantic links that do not represent “part-of” relationships are represented by associative relationships in the next step. Associative relationships are bound to certain levels of the schema. External information objects are always linked to internal information objects by associative relationships. They should be modeled on the same schema level as the internal information objects they are linked to. 4) Design of navigators Although usually being based on hierarchical or associative relationships, navigators and navigational relationships represent separate concepts. While the navigator itself represents application interface properties, navigational relationships represent its behavior. Using navigators, application users can easily navigate in a knowledge domain without having to follow hierarchical or associative relationships.


One or more navigators can be directly linked to an information object. If more than one navigator is linked to an information objects, an index number is introduced. A navigator is linked to that information object whose browsing shall initially create the navigation menu. A navigator it “inherited” by a set of other information objects on the respective schema level and on the next schema level. By separating schema levels according to information object sets related to navigators, elements of complex web site schemas can be arranged. 5) Representation of components For every information object, component relationships and components can be represented in the web site schema or (for complex schemas) in a detail subschema for each information object. Since relationships (including navigational relationships) are defined between information objects only, modifications of component structure do not affect the overall schema. Components may be reused by more than one information object.

TOOL SUPPORT In this section, commercial end-user development tools for web sites are discussed with regard to conceptual modeling. Unlike most tools that do not support for conceptual modeling at all, Microsoft’s Frontpage 98 and Macromedia’s Dreamweaver have appropriate features and are discussed in the following. Since Microsoft Visual Interdev 6.0’s features are very similar to Frontpage 98, this tool is not being discussed separately. Adobe PageMill 2.0 for Windows is basically a HTML editor with WYSIWIG capabilities, i.e. without an explicit conceptual model. However, Adobe claims (Adobe Systems, Inc., 1997) that the Macintosh version has some modeling features like a “site view” and an “external reference view.” Interleaf’s Jamba is a generator for web pages that include multimedia objects implemented by Java code. Applets can be generated without any knowledge of the Java syntax by using a graphical interface for the assembly of multimedia objects to pages. As building blocks, a large number of buttons, graphics, menus, text fields, and links are provided. However, Jamba is restricted to the development of single pages (not complete sites) without extended procedural features and without support for requirements specification, analysis, or design. Microsoft FrontPage 98 Frontpage 98 provides only one type of information object which is directly corresponding to HTML files stored on the web server. Component structure cannot be modeled. Neither navigators nor external information objects can be differentiated. Navigators, however, are automatically generated. But these structures depend on Frontpage’s navigational model and properties that have to be coded without any conceptual representation. For each web site, the designer has to decide globally whether borders should appear or not.


Figure 2: Web site schema in Frontpage 98

Hierarchical relationships between information objects can be modeled as “navigational model” (see Figure 2). Associative relationships, however, as well as navigational relationships in our definition and component relationships are unknown. When updating hierarchical relationships, the deletion of a single relationship may trigger the deletion of an entire sub-tree including the respective information objects. Only a few basic concepts of conceptual web site design are currently supported by Frontpage 98. It is necessary to extensively re-code web sites generated by Frontpage 98 to allow for features like associative links, external links, component reuse, non-standard navigators, etc. Obviously, respective web sites are not really based on a stable conceptual schema so that technical innovation will require significant development efforts. Macromedia Dreamweaver 2.0 In Dreamweaver’s conceptual model, two classes of information objects exist. On the one hand, there are information objects which represent a physical HTML file on the web server. On the other hand, there are information objects like external links, mailto tags, and images. To some extent, these two classes correspond to information objects (files) and components (links, images) in our model (see Figure 3). However, the latter group of objects is not differentiated so that meaningful quality checks or design rules cannot be applied. Between information objects, hierarchical relationships as well as associative relationships can be modeled. However, Dreamweaver does not provide a differ-


Figure 3: Web site schema in Dreamweaver 2.0

ent notation for these two classes of relationships. Although associative links can be modeled, web sites can only be displayed as expandable trees (based on hierarchical relationships) and not as networks that also include associative relationships. Dreamweaver does not support the design of navigators and navigational relationships. The generator directly creates HTML hyperlinks from associative relationships.

CONCLUSIONS Based on a short discussion of related work and an analysis of the essence of a web site, a conceptual model is proposed that allows for the specification of useful quality checks, design rules, schema arrangement rules, and schema documentation for web sites. Most of the proposed features, however, are currently not supported by commercial web site design tools. In order to prevent current web site development to create the legacy systems of the future, it is necessary to derive web-based information systems from a stable conceptual foundation. In order to provide a dependable specification for web design software vendors, approaches to conceptual modeling from scientists and practitioners have to be integrated, thereby taking into account findings from hypertext design as well as experience from traditional CASE practice. Hopefully, specific discussion of web site modeling issues will help such specifications to emerge.

REFERENCES Adobe Systems Inc. (1997). Adobe PageMill Details - SiteMill for Macintosh. http://www.adobe.com/ prodindex/pagemill/siteben.html (27 Nov.).


Bichler, M. and Nusser, S. (1996). SHDT-The Structured Way of Developing WWW-Sites, Proceedings of the 4th European Conference on Information Systems, Dias Coelho, J. et al. (Eds.), pp. 1093-1101. Chen, C. (1997). Structuring and Visualising the WWW by Generalised Similarity Analysis. In Proceedings of the eighth ACM conference on Hypertext HYPERTEXT’97, pp. 177-186. De Bra, P. and Houben, G. J. (1992). An Extensible Data Model for Hyperdocuments. Proceedings of the ACM conference on Hypertext ECHT’92, pp. 222-231. Diaz, A., Iskowitz, T., Maiorana, V., and Gilabert, G. (1995). RMC: A Tool To Design WWW Applications. http://www.stern.nyu.edu/~tisakowi/ papers/www95/rmcase/187.html (27 Nov.). Isakowitz, T., Stohr, E. A., and Balasubramanian, P. (1995). RMM: A Methodology for Structured Hypertext Design. Communications of the ACM 38 (8), pp. 34-44. Lyardet, F. D., Mercerat, B., and Miaton, L. (1999) Putting Hypermedia Patterns to Work: a Case Study. http://pelican.info.unlp.edu.ar/ht992/ patternsAtWork.html (10 May). Lynch, P. J. and Horton, S. (1999). Web Style Guide: Basic Design Principles for Creating Web Sites. http://info.med.yale.edu/caim/manual/contents.html (10 May). Marmann, M. and Schlageter, G. (1992). Towards a Better Support for Hypermedia Structuring: The HYDESIGN Model. Proceedings of the ACM conference on Hypertext ECHT’92, pp. 232-241. Martin, J. (1982). Application development without programmers, Englewood Cliffs: Prentice-Hall. McMenamin, S. M. and Palmer, J. F. (1984). Essential Systems Analysis, New York: Yourdon Inc. Morville, P. and Rosenfeld, L. (1998). Designing Navigation Systems http:// webreview.com/wr/pub/98/02/20/arch/index.html (29 April). Richmond, A. (1999). Navigation Architecture of The WDVL, http:// www.stars.com/WebRef/Navigation/WDVL.html (28 April). Rosenfeld, L. and Morville, P. (1998). Information Architecture for the World Wide Web - Designing Large-scale Web Sites, O’Reilly & Associates. Schranz, M. (1998). Engineering Flexible World Wide Web Services. In Proceedings of the Symposium on Applied Computing 1998, Carroll, J. et al. (Eds.), pp. 712-718. W3DT-TEAM (1996). W3DT – WWW Design Technique http://wwwi.wuwien.ac.at/ w3dt/ (26 Nov).

Wedemeijer • 69

Chapter 6

A Method to Ease Schema Evolution Lex Wedemeijer ABP, The Netherlands

Maintenance on the Conceptual Schema of a database is necessary when the current data structure can’t meet changed functional requirements. An additional requirement, not expressed in the demand for change, is to minimize the impact of change. The problem of minimizing impact of change on the data is often postponed to the implementation phase when data have to be migrated into the new structure. We propose a method to address the problem of Conceptual Schema evolution in an earlier phase, and introduce the notion of Majorant Schema to support the application of the method. The advantage of the approach is that a more graceful schema evolution is ensured because a broader range of design alternatives is investigated. Other benefits are the early attention for the impact of change, and a better preparation of the data migration effort. Experiences show that the method is primarily suited to minor changes.

INTRODUCTION Operational database applications in a dynamic business environment will be subject to continuous change. When faced with structurally new requirements, most maintenance practitioners start with determining a new Internal Schema (IS) that meets the new functional requirements. The issue of migrating the current set of data into the new schema is not often addressed at this time. Even less attention is paid to formulating the change demands on the level of the Conceptual Schema Previously Published in Challenges of Information Technology Management in the 21st Century, edited by Mehdi Khosrow-Pour, Copyright © 2000, Idea Group Publishing.

70 • A Method to Ease Schema Evolution

(CS), and to deciding on the best possible way to incorporate the change into the CS, thereby ensuring a graceful schema evolution. At best, a quick sketch is made that outlines the major differences between the old and new CS, indicating which entities and relationships are affected to some extend. Going directly from old to new IS has several disadvantages. Design choices that are conceptual in nature are made on the wrong level of abstraction. Design alternatives may be overlooked. It will quickly lead to a deterioration of conceptual documentation. Minimal impact of change on the IS level doesn’t necessarily mean a small impact of change on the business level. In section 2 we will propose a method that lets the designer decide on the changes to be made on the CS, before proceeding with the Internal Schema design. In section 3 we introduce a new type of schema called the Majorant Schema (MS). This schema can be used as the centre-piece in the method. To establish the MS, schema integration techniques are applied in a new way. Section 4 illustrates the benefits of our approach by showing a simplified example, derived from an actual business case. Some related work is discussed in section 5.

THE MAJORANT-SCHEMA METHOD Many maintenance approaches take the current database structure as starting point. It is our opinion that this is inadequate, because the coherence between the current CS and the new one will be lost, and too little use is made of flexible design solutions that are present in the old schema. We propose to solve this problem by augmenting the common approaches with a number of design steps in order to ensure coherence. Our approach is depicted in Figure 1. The starting point of our method is placed at the point where structurally new requirements are put to the maintenance engineers. The method then proceeds to establish a sound CS that meets the new requirements, then to design a new database structure. 1. The first step in applying the method is establishing what has to be changed, i.e., the current CS. This requires more than just taking out a copy of the original CS design (if available) because in many business situations, the IS will have deviated from the CS. While each deviation will be small, their number can add up. To retrieve the current CS from available database information, Reverse-Engineering techniques are called for (Henrard, Englebert, Hick, Roland, and Hainaut, 1998). 2. Step 2 is the creation of a Conceptual Schema that meets all new and existing functional requirements. To a large extend, execution of this step can and will be independent of the first one. 3. In Step 3 several preliminary activities are executed before we can proceed with the conflict analysis:

Wedemeijer • 71

Figure 1: The Majorant Schema approach 1. (re)document current Conceptual Schema

2. create new CS

3. prepare schema integration

4. conflict analysis

5. document conflict descriptions

4a. detect structural conflicts 4b. weigh impacts of change 4c. adjust new CS

6. design new IS

7. prepare data migration

8. migrate data to new Internal Schema

- translate either or both schemas into the same data model. This issue is not a trivial one. As a constant flow of new theories, techniques and tools find their way into the business environment, new designs are often drawn up using a different data model than the old one. - If a rich data model is used, a semantic feature in the Universe of Discourse can be expressed in multiple ways in the CS. Choosing among the alternatives depends on personal preferences of the designer. Such differences in “the art of” data modeling must be eliminated as they confuse integration. - resolve name conflicts. Synonyms are easy to find, but spotting homonyms can be a real problem. This is because designers will often retain the familiar names in the new schema while making subtle changes in their definition. An example will be shown in section 4. 4. Step 4 is conflict analysis. It is made up of three substeps. Several iterations may be necessary to arrive at a satisfactory result: - The first substep is to detect structural conflicts between the new CS and the old one. This requires matching the entities, relationships, attributes, or whatever other constructions are in the two schemas. - The second substep is to determine the business consequences of each conflict, and weigh them against the importance of the change drivers. All business consequences should be considered such as necessary user training, new administrative procedures, interruption of customer services etc.


- Once there is a clear understanding of the conflicts and their business consequences, one will want to minimize their number and size. This means adjusting the new schema, as obviously the old one can’t be altered. The adjusted schema must still satisfy all requirements to the full, but the structural conflicts with the old schema should be lessened or even eliminated. 5. Step 5 is to document which structural conflicts remain. Management should be aware of these, as they must accept the consequences of the change for business operations. Quality assurance should verify that the documentation is sufficient for the next steps. 6. Step 6 proceeds to create a new IS. The CS, being the outcome of requirements analysis, now serves as the starting-point for design. Because of the coherence between old and new schema, it is clear which features in the schema haven’t changed and the maintenance engineer can stick to the same implementation choices for them. 7. Step 7 prepares the migration of data to the new Internal Schema. It includes updating and testing data access routines, software applications, screen layouts etc. Also data acquisition procedures must be adjusted, and perhaps most important: the users need to be informed of the new ways of handling the data. 8. Step 8 is the final one in which the data are exported from the old storage structure and migrated into the new Internal Schema.

USE OF THE MAJORANT-SCHEMA The previous section outlined the Majorant Schema method, but it did not refer to the notion of Majorant-Schema (MS) at all. This is done in this section. The simple idea is to have a single schema that integrates the CS before and after the change. But notice how the Universes of Discourse before and after the change do not overlap! In a more formal sense, the Majorant Schema could be defined as “the result of integrating schemas that model disjoint Universes of Discourse.” The MS concept can be used at several points in our method: In Step 3, a preliminary MS can be drawn up. Of course, in a normal business situation only a few concepts will change while most features remain the same. This means that integration will be easy, except for a few knotty problems. Some of these problems will be only superficial, e.g., different names or constructions that are used to model the same feature in the Universe of Discourse. Step 3 amends these apparent differences. But structural conflicts can’t be easily mended. It is the subject of our Step 4, and it brings out the benefit of the MS approach. The ideal situation is when there are no structural conflicts between old and new schema. This means that the old CS is flexible enough to accommodate the new requirements, and integrating the schemas will yield no new insights. But assuming there is a real need to change, Step 4 aims to lessen or even eliminate the structural

Wedemeijer • 73

conflicts by adjusting the new CS design. It is a well-known fact that there is not a single perfect CS design, almost always several alternative conceptual schemas can be drawn up that meet the same requirements. Drawing from the preliminary MS, design alternatives for the new CS can be created that have a better fit with the MS, and thus with the old schema. Looking at this from another perspective, we can say that our method attempts to reuse the design solutions from the old CS, thereby easing Conceptual Schema evolution. In Step 5, describing the remaining structural conflicts amounts to documenting the final version of the MS. Complete and consistent documentation is a prerequisite in the subsequent steps. It can also be used in the future evolution of the schema. In our opinion, the MS is the most important tool for understanding the changes made on the conceptual level. In Step 7, the data migration is prepared. The largest impact of change on the level of data instances is caused by change on the conceptual level. With no structural conflicts at the conceptual level, any problems in data migration can only be caused by differences in internal implementation choices (also called data-dependencies). Such problems can often be resolved automatically. But for every structural conflict, human intervention is called for. This is why it is important to minimize structural conflicts as early as possible. It will counter the invalidation of data in the old schema, and decrease the data conversion efforts. And if new data interpretations must be retrieved from the Universe of Discourse, it must be considered how this is to be done as it can take quite some time to acquire the missing information.

AN EXAMPLE APPLICATION OF THE METHOD An example taken from an actual business case, much simplified, will highlight the benefits of both our method, and the use of the MS. The example concerns an organization that was hierarchically structured into geographical units. Each unit has a name and address, and can have several component units. Most, but not all units provide customer service, and these are called outlets. After some digging into legacy documentation, our example was found to have a very simple schema shown in Figure 2. The dotted line marks an is-a specialization; the crows-foot marks a has-a relationship with 1-to-many cardinality. Figure 2: The initial schema

has-a unit

is-a outlet


Figure 3: The new schema proposal

Figure 4: The new schema after name change has-a department

has-a unit

has-a outlet

has-a outlet

Figure 5: The Majorant Schema has-a unit

is-a outlet

is-a department

A reorganization is undertaken that, among other goals, aims to distinguish between organizational roles and customer–service responsibilities of units. The proposal for the new Conceptual Schema shown in Figure 3 looks very similar to the old one, in Figure 2. We will now apply the method proceeding from Step 3. In Step 3, the one interesting activity is spotting the homonyms. It is immediately clear that the term unit is suspect. Indeed, before the change it included the outlets whereas after the change, the same name is used to designate only nonoutlets. In Figure 4, we introduce the term department to stand for a unit that doesn’t provide customer service. Step 4 is conflict analysis. Although the term unit has disappeared from the new schema, this is not a conflict: units can be considered to be the disjoint union of outlets and departments. We can identify two structural conflicts between the schemas. First, the new structure disallows outlets to have component units. This reflects the explicit business rule to “distinguish between organizational roles and customer–service responsibilities of units.” The second is that after the schema change, an outlet can no longer switch to being a non-outlet or vice versa. We finish our example with Step 5. The Majorant Schema after integration of the two schemata is shown in Figure 5. The AX marker conveys that the is-a relationships concern (A)ll units, and are mutually e(X)clusive. Not depicted are the two constraints that will start to hold from the time the schema change is implemented: the static data constraint that outlets aren’t allowed to have component units, and the dynamic constraint that outlets can’t change into departments

Wedemeijer • 75

or the other way around. They reflect the new business rules that are being enforced in the Universe of Discourse, i.e., in the organizational hierarchy. The data conversion effort in Step 8 will amount to recording those organizational changes. This example, although simplified, demonstrates several benefits of our approach: - by taking the conceptual view, a broad range of design alternatives will be considered, and design choices that are conceptual in nature are made on the right level of abstraction - the method increases the coherence between the old schema and the new one. This enhances the (re)use of flexible design solutions present in the old schema and increases the system lifetime - documentation on the Conceptual Schema is more consistent and better up to date - decisions on the best design alternative will be based on an assessment of the impact of change for the ongoing business - the new Internal Schema is created from the new CS that has been validated by management, not from scratch - a good knowledge of the required migration effort is gained in an early stage, and the data migration effort can be planned better than in conventional approaches. A disadvantage of the methodical approach we propose is that preliminary work must be done, and precious time appears to be lost, before the maintenance engineer can actually start adapting the data storage structures and migrating the data.

RELATED WORK Our work is motivated by the need to understand and ease the schema evolution in operational database systems. Theoretical work on schema evolution describes the taxonomy of changes that might occur in a schema, given the construction elements of the data model (Roddick, Craske & Richards, 1993). While this work contributes to an understanding of modeling concepts, it doesn’t give direction to maintenance efforts when new requirements must be incorporated in an operational database environment. Another approach is the use of a new type of data model that can manage variable parts in the CS (Sekine, Kitai, Ooshima, & Oohara, 1997). This approach allows a CS to be expressed in multiple ways, in a somewhat similar fashion as our Majorant Schema can be expressed as two different conceptual schemas. The Majorant Schema approach is a variant of the schema integration approaches. These have been extensively studied (Batini, Ceri, & Navathe, 1992; Santucci, Batini, & Di Battista, 1993; Bonjour & Falquet, 1994). While our ap-


proach uses the techniques, our method differs significantly from ordinary schema integration. We don’t need to resolve all schema conflicts, nor do we want to adjust an existing schema to enhance compliance with the integrated schema. The Extra-temporal Schema as introduced in Proper (1994) is defined as the union of consecutive schemas. The Majorant-Schema concept goes one step further and also requires the integration of schemas. The integration is important because it brings out naming and structural conflicts. The integration is also necessary to make the lifecycle of data instances span across the schema-change barrier. This means that queries accessing data from before and after the change can be answered. Updates are more difficult. Temporal database models (Ariav, 1991) are designed to handle transactions while accounting for their valid-time and transaction-time. But there remains a real problem if an event takes place prior to the schema change, while the information only reaches the database afterwards. The concept of Majorant Schema can provide the framework to deal with this kind of retroactive events.

CONCLUSIONS AND FURTHER RESEARCH This chapter has described a method to minimize impact when the information structure of an operational database has to be changed. The method is restricted to minimizing change at the level of the Conceptual Schema only. We do not address other problem areas where improvements might be possible such as the maintenance process itself, the training of personnel etc. It is our experience that the method can successfully be applied to minor changes in the Conceptual Schema, viz. the information structure and requirements remain relatively stable over time. The method is less suitable when fundamental concepts in the real world are radically altered and major CS restructuring is undertaken. In such cases the focus will be on the quality of the new CS with respect to the Universe of Discourse, more than on reuse of the old schema or its data. Also, much of the old data will become virtually useless and an effort to salvage that data is not worthwhile. Ongoing work is being done on schema evolution in operational databases using the Majorant Schema approach. To this end, the MS approach is used to span across a sequence of CS changes, providing a long-term view of the schema evolution. We believe that such a Majorant Schema will clearly show the most stable way of modeling the Universe of Discourse as it continues to evolve over time. From that, the research aims to describe the semantic change patterns that can be observed in operational databases (Wedemeijer, 1999). The practical knowledge contained in such change patterns will augment the theoretical taxonomies of change in a way that maintenance engineers can quickly determine the impact of change on the level of database content, but also on the level of the Conceptual Schema.

Wedemeijer • 77

REFERENCES Ariav, G. (1991). Temporally oriented data definitions: Managing schema evolution in temporally oriented databases, Data & Knowledge Engineering, 6(6), pp 451-467. Batini, C., Ceri, S., & Navathe, S.B. (1992). Conceptual Database Design: an Entity-Relationship Approach, Benjamin/Cummings, isbn 0-8053-0244-1. Bonjour, M., & Falquet, G. Concept bases: a support to information systems integration, in CAiSE ’94 Advanced Information Systems Engineering, Wijers, Brinkkemper, & Wasserman (Eds.), Springer Verlag LNCS 811 [06] pp 242-255. Henrard, J., Englebert, J., Hick, J.-M., Roland, D., & Hainaut, J.-L. Program understanding in Databases Reverse Engineering, in DEXT’98 Database and Expert Systems Applications, Springer Verlag [08] pp. 70-79. Proper, H.A. (1994). A theory for Conceptual Modelling of Evolving Application Domains, thesis K.U.N. Nijmegen (the Netherlands) isbn 90-9006849X Roddick, J.F., Craske, N.G., & Richards, T.J. (1993). A taxonomy for Schema Versioning Based on the Relational and Entity Relationship Models, in EntityRelationship Approach ER’93, Elmasri, Kouramajian, & Thalheim (Eds.), Springer Verlag LNCS 823, pp. 137-18. Santucci, G., Batini, C., & Di Battista, G. (1993). Multilevel Schema Integration, in Entity-Relationship Approach ER’93, Elmasri, Kouramajian, & Thalheim (Eds.), Springer Verlag LNCS 823, pp. 327-338. Sekine, J., Kitai, A., Ooshima,Y., & Oohara, Y. (1997). Data Model for Customizing DB Schemas Based on Business Policies, in Conceptual Modeling – ER’97, Embley & Goldstein (Eds.), Springer Verlag LNCS 1331, pp. 198214. Wedemeijer, L. (1999). Semantic Change Patterns in the Conceptual Schema, in Advances in Conceptual Modeling, Chen, Embley, Kouloumdjian, Liddle & Roddick (Eds.), Springer Verlag LNCS 1727, pp. 122-133.

78 • A Three Layered Approach for General Image Retrieval

Chapter 7

A Three Layered Approach for General Image Retrieval Richard Chbeir, Youssef Amghar and André Flory LISI - INSA, France

Several approaches are proposed for retrieving images. Each of them describes image according to application domain requirements. No global approach exists to resolve retrieving image in complex domains (as medical one), in which content is multifaceted. A framework to retrieve medical images is presented. In this paper, we expose our three-dimensional approach applied to medical domain, and required elements for both knowledge base and retrieval process. The proposed approach, built on multifaceted aspect, offers all possibilities to describe image within multifaceted content (context, physical and semantic). Conceptual relations are presented for designing knowledge base for coherent and efficient indexing and retrieval processes. Required spatial relations of processes are also exposed.

INTRODUCTION The major problem of retrieving images is the lack of the content description. Several descriptions are possible and each person may describe the image differently. Each description presents a particular view and corresponds to a specific need of the application domain. Kennedy’s photo, for instance, when he was young could be described as the image of a child, or as the image of the future president of the USA. Current proposed multimedia systems are built on retrieval mechanism using either factual image information (Ligier, Ratib & Girard, 1994; Shakir & Sabri, 1996) (such as identifier, name or image date acquisition), sePreviously Published in Challenges of Information Technology Management in the 21st Century, edited by Mehdi Khosrow-Pour, Copyright © 2000, Idea Group Publishing.

Chbeir, Amghar & Flory • 79

mantic data (Yang & Wu, 1997; Gudivada & Raghavan, 1995; Mechkour, 1995) (image objects as defined in real world), or physical information (Bach, Santanu & Ramesh, 1993; Huet & Vailaya, 1998; Bertino & Catania, 1998; Gelgon & Bouthemy, 1998; Ikonomakis, Plataniotis & Venetsanopoulos, 1999) (as colors, textures, brightness and boundaries). Since subjectivity and imprecision are usually associated to the specification and the interpretation of the content, the image description constitutes a painful task. For that reason, an appropriate method must be applied to provide coherent image description. This is the principal of indexing that consists of taking into account only main objects, their relative positions, and the context of image are considered. However, a waste of data can be observed when describing an image by a set of poor semantic descriptors. For instance, the description of a satellite image of the loon might ignore the other stars because they are not relevant to the domain. Such waste of information could be minimized by introducing a set of connotations taking simultaneously into consideration several aspects of the image. An image interpretation is usually associated to one or several facets. These facets could be directly related, or indirectly related to the image content as ones found in the context (image date, number, author, scene, etc.). These interpretations differ in terms of image abstraction and correspond to the domains needs and images complexity. Each application domain interests certain facets of image. For instance, in historical museum, contextual and semantical aspects are used because images retrieval necessitates the reference of the semantical content linked to objects and the scene relating them. In monitoring applications, only graphical (shapes, colors, etc.) and contextual (date) aspects are used. In certain medical domains, such as cytology, current approaches are unable to satisfy searches needs because they do not describe all image facets. This paper presents a general data model able to describe the image as a complex object with multiple facets. Our application domains are basically the medical ones. We expose our three dimensional model able to describe the multifaceted image content. Also, necessary relations for both knowledge base and retrieval process are exposed. To demonstrate the viability of our approach, we have implemented a system called Medical Image Management System (MIMS) written in Java programming language to develop a platform-independent database–independent application. MIMS is accessible on the Internet on http:// www.mims.cemep.asso.fr, and consulted by physicians each day. The next section details the conceptual model of our approach. At section 3, we conclude our work.

PROPOSED APPROACH The proposed model assures an adequate general approach where the medical image is viewed within three-dimensional plan (Figure 1). The first dimension


Figure 1: Medical image dimensions

Physical

Semantic

Contextual

presents the context in which the image is placed, the second one describes the graphical and physical contents, and the third one occupies of the real and semantical content description. Both, physical and semantic dimensions observe content within image objects, while contextual one occupies of global and external data. In medical universe, three types of objects are identified: • Anatomic Organ (AO): presents the medical organ occupied by the image such as brain, hand, lungs, etc. It regroups a set of medical regions. The set of medical regions could be one element, which is the AO itself. This is exactly what we see when looking at images in several medical domains as epidermis, urology, hematology, and cytology ones. In such domains, no internal structure is defined. • Medical Region (MR): describes the internal structure of the AO. For example, the left ventricle, the right lobe, etc. It allows to powerfully locating each anomaly using several kinds of graphical (spatial and topological) and semantic relations. A set of polygons determines the MR form. • Medial Sign (MS): is a medical anomaly (such as tumor, fracture, etc.) identified and detected by physicians. The image representation model is built upon three classes: Anatomic Organ Class (AOC) gathers all anatomic organs, Medical Region Class (MRC) groups medical regions and Medical Sign Class (MSC) assembles all medical signs. These classes inherit from a root class identified as Medical Image Class (MIS). On the one hand, medical classes possess different types of semantic relations. These relations can exist between either medical signs (MS/MS) or, Medical Region and Medical Sign (MR/MS). We denote that knowledge base (or thesaurus) exists, and is built upon these objects (MS, MR and AO) and their semantic


relations. It is used, firstly to normalize indexing process, and secondly during both indexing and retrieval processes to help the user. Proposed types of semantic relation are mentioned below: • The synonymy relation: relates a secondary medical entity (semantically near) to a primary one. The medical vocabulary is so complex that some equivalent concepts may be different from domain to another. For instance, a tumor is a synonym to a cancer. • The hierarchy relation: defines partial order relation between medical entities in order to classify medical terms and extend queries. It groups generalization / specialization relation (anomaly and tumor) and/or composition relation (head and brain). • The compatibility relation: connects Medical Region to Medical Sign. This relation is used essentially to sort Medical Sign according to compatible Medical Region. For instance, at the left ventricle, only tumor could be found. • The multi-linguistic relation: to assure an international compatibility between entities. On the other hand, each instance of medical object is graphically and geometrically presented by a shape. A set of graphical characteristics is attached to each shape in terms of texture, brightness and colors. The concept of shape is firstly attached to at least one pattern in order to associate a cure image to the Anatomic Organ, and an icon to Medical Sign, and secondly to a set of polygons in order to define the Medical Region geometrical form. The shape is used to calculate two types of spatial relations: directional and topological ones: • Spatial relations: permit, within the coordinates, to locate an entity and to determine its position to another entity. This could be the case between both Figure 2: topologic relations between Medical Signs

Figure 3:Topologic relations between Medical Region and Medical Sign MR1

MR1 Contains X

MR1

X Overflow MR1

MR1

X Externally Touches MR1

MR1

X Internally Touches MR1


• Medical Region and Medical Sign (MR/MS) such as West, Oust, North, East, • Medical Signs (MS/MS) such as Higher, Lower, at Right, at Left. • Topological relations: allow, within the form, to locate objects position. Several kinds of topological relations might exist between: • Medical Region and Medical Sign: Contain, Internally Touch, Externally Touch, Overflow, • Medical Signs: Touch, Disjoint, Cover, Mix, Contain, Internally Touch, and Externally Touch. Computing spatial (topologic and directional) relations between medical entities is obtained by Euclidean space. We denote that only validated relations (and distance) are stored in database and not object coordinates. This means that scale modification can be done easily as it affects only coordinates and not relations. However, when dealing with complex domain applications (such as medical ones), where object relations are primordial but absolutely impossible to be calculated automatically, human intervention becomes necessary and another type of relation must exists. This is why semantic relation is also integrated. It is pertinent and practical for physicians to be able to describe several medical image content (as semantic relations) by their own terms. In essence, it permits to have a flexible, portable and efficient approach.

CONCLUSION In this paper, we presented our approach for retrieving image in complex domains. Medical domain is chosen as application domain. The main contributions of this chapter can be summarized as follows: 1. Global solution integrating all medical image content into three-dimensional plan. 2. Conceptual relations in knowledge base to respond to all image queries. 3. Efficient modules and implementation for global image management (storage and retrieval). Our future interest concerns evolution content of medical image. To study maturity development, disease progression, medical therapeutic, traumatic event, etc., the image content evolution must be integrated into the database. Finally, providing a global approach needs to be validated in several domains (including non-medical ones). Our future work intends to integrate pictorial databases.

REFERENCES Bach, J. R., Santanu, P., & Ramesh J. (1993). A Visual Information Management System for the Interactive Retrieval of Faces, IEEE transactions on Knowledge and data engineering, 5(4), August.


Bertino, E. and Catania, B. (1998). A constraint-based approach to shape management in multimedia databases, Multimedia Systems, p. 2-16. Chbeir, R., Amghar, Y., & Flory, A. (1999). System for medical image retrieval: the MIMS model, Third International Conference, Visual’99, Amsterdam, June, Proceedings. p. 37-42. Gelgon, M. & Bouthemy, P. (1999). A Region Tracking Method with Failure Detection for an Interactive Video Indexing Environment, Third International Conference, Visual’99, Amsterdam, June, Proceedings. p. 261-268. Gudivada, V.N. & Raghavan, V.V. (1995). Design and evaluation of algorithms for image retrieval by spatial similarity, ACM Transaction Information system 13, April, p. 115-144. Huet, B. & Vailaya, A. (1998). Relational Histograms for shape indexing, IEEE ICCV’98, January, p. 563-569. Ikonomakis, N., Plataniotis, K.N., & Venetsanopoulos, A.N. (1999). A Regionbased Color Image Segmentation Scheme, Proc. Of the SPIE: Visual Communications and Image Processing, 3653, p. 1202-1209. Laforest, L., Frénot, S., & Flory, A. (1996). A new approach for Hypermedia Medical Records Management, 13th International Congress Medical Informatics Europe (MIE’96), Copenhagen. Ligier, Y., Ratib, O., & Girard, C. (1994). OSIRIS: A medical manipulation system, M.D. Computing Journal, Juin, 11(4), p.212-218. Mechkour, M. (1995). EMIR2. An Extended Model for Image Representation and Retrieval, Database and EXpert system Applications (DEXA), September, p. 395-404. Shakir, H. & Sabri (1996). Context-Sensitive Processing of Semantic Queries in an Image Database System, Information Processing & Management, 32(5), p. 573-600. Yang, L. and Wu, J. (1997). Towards a Semantic Image Database System, Data & Knowledge Engineering, 22(3), pp. 207-227, May.

84 • Is There A Life After Objects?

Chapter 8

Is There A Life After Objects? Jean Bézivin University of Nantes, France

We are presently witnessing a rapid paradigm change in software engineering: from objects to models. This chapter discusses some aspects of the emerging domain of model engineering, mainly those related to meta-modelling and uniform representation of models and meta-models. This much recalls the discussions on classes and objects that were taking place in the early eighties. In the last period, the issue of code interoperability has been dealt with such acceptable solutions as CORBA or the associated IDL language. But we are now witnessing the multiplication of non-executable models, as part of the evolving software development practice. In order to cope with this increasing complexity, a general and regular framework has to be defined. This is being achieved, in environments like the OMG, where all the new models are based on a precise meta-model and where all the meta-models are based on a common and unique meta-meta-model called the MOF. The MOF is rapidly gaining practical importance, between UML and XML, in the industrial strategy of several important companies. It is playing the role of a knowledge bus for all kind of models, object models or legacy models, product models or process models, existing models or yet to be defined models. In particular it is helping to provide a smooth transition from objects and components models to the business processes, workflows and service models that are becoming key elements in the area of Web services. Previously Published in Challenges of Information Technology Management in the 21st Century, edited by Mehdi Khosrow-Pour, Copyright © 2000, Idea Group Publishing.

Bézivin • 85

FROM OBJECTS TO MODELS Procedural technology had some recognized weaknesses and this led to the move, in the eighties, to object and component technology. While some of the problems have been fixed, other difficulties are still there. One of the additional drawbacks brought by objects was the lost of functional roots in applications. This problem was only very partially addressed by the introduction of the “use case” concept in analysis and design methods. Today many see the return of the associated concept of “service” as an important turn in the information system landscape, while object and component models are more and more viewed as pertaining to the implementation side. The most common expression of these models of service appears in the design of Web services. Among the reasons for this is the fact that the concept of service may help to conciliate much more easily functional and non-functional requirements (e.g. QoS properties). Also services are more easily combined with business processes and workflows. Other examples of facets that the object models were not able to readily capture were architecture and know-how information. It was necessary to invent the “design pattern” and other concepts to cope with these. Similarly to services or use cases, design patterns are not usually considered as first class objects in current practices. Many other limitations of object organization of software were subsequently noticed, some of them tentatively expressed in aspect-oriented programming. Most of these views can only be taken into account in a general framework that is based on regular handling of multiple models like the one currently suggested in the Model-Driven Architecture (MDA) initiative (Soley, 2000). The Semantic Web (Berners-Lee, Hendler & Lassila, 2001) and the MDA are probably among the most significant industrial evolutions in computer science at the beginning of this century and there are some points of similarity between them, even if they apply to different contexts. This chapter discusses the main characteristics of the MDA, concretizing the practical transition from objects to models. The arrival to maturity of object technologies has allowed the idea of modelbased software development to find its way to practicality. The OMG (Object Management Group) is no more centering its activities on a unique interoperability bus, but on two different ones: the classical CORBA software bus (for code interoperability) and the emerging MOF (Meta-Object Facility (OMG/MOF, 1997)) knowledge bus (for model interoperability). The consensus on UML (Unified Modelling Language (Kobryn, 1999)) has been instrumental in this transition from code-oriented to model-oriented software production techniques. A key role is now played by the concept of meta-model in new software organizations like the OMG meta-model stack architecture or the MDC OIM (Open Informa-


tion Model defined by the Meta-Data Coalition (MDC, 1999)). The notion of a meta-model is strongly related to the notion of ontology, used in knowledge representation communities. The concept of a MOF has progressively emerged in the last ten years from the work of different communities like CDIF, IRDS, etc., as a framework to define and use meta-models (Bézivin, Ernst & Pidcock, 1998).

ON META-MODELS AND ONTOLOGIES Within many environments like the OMG, meta-model technologies are now becoming ready for prime time. The move from procedural technology to object technology may have triggered a more radical change in our way of considering information systems and of conducting software engineering operations. One of the possible evolution paths is called model engineering. It consists in giving a firstclass status to models and model elements, similarly to the first class status that was given to objects and classes in the 80’s, at the beginning of the object technology era. As previously mentioned, we face today a multiplicity of models. The information engineer or the software engineer are usually working with several different ones at the same time, i.e., with models of different semantics. The executable source code is no more the main and central reference. Product models are arranged in complex organization networks. They are produced and used within precise methodological frameworks sometimes themselves defined by other models (process models). One view of Computer Science is that we are now achieving the first historical paradigm shift, namely from procedural refinement to object composition and that we are, at the same time, starting the second paradigm shift, from object composition to model transformation. Obviously to make this last scheme workable, we need to start with some basic models, mainly the domain model, the resource model and the requirement model. Each model is itself structured in a number of sub-models, allowing for example to define, within the domain model, different entities like business objects, business processes and business rules. The need is clearly expressed for a framework allowing managing a regularly organized set of low granularity models and transformation operations. The importance of model engineering in the information system and software development process is rapidly growing (Atkinson, 1998; Raymond, 1997). Models are defined (constrained) by meta-models that we shall call synonymously here ontologies. In the present paper, the word “ontology” (Kayser, 1998) will thus be used in an interchangeable way with “meta-model” for defining a set of concepts and relations between these concepts. An ontology is used as an abstraction filter in a particular modelling activity. From a given system, we can extract a particular model with the help of a specific ontology. If, as an example, the system is a University department, the ontology could have {Teacher; Student; Course} as

Bézivin • 87

its set of concepts and {takes [Student, Course]; teaches [Teacher, Course]} as its set of relations. The model extracted from a given department, with the help of this ontology, may serve to know the students that take more than one course given by the same teacher. The question of how many students in the department play basketball in the same team cannot be answered with the given ontology: a model is being built for a specific purpose; this purpose is usually implicit in the corresponding ontology. Therefore, the basic use of an ontology, is that it facilitates the separation of concerns. When dealing with a given system, you can observe and work with different models of this same system, each one characterized by a given ontology. Obviously when several models have been extracted from the same system with different ontologies, these systems remain related and to some extent the reverse operation may apply, namely combination of concerns. What we need for that is a regular organization of composite models, including also the corresponding metamodels. An ontology may contain elements of different natures. Usually there are three kinds of information (layers) inside a given ontology: · Terminological. This is the basic set of concepts and relations constituting the ontology. It is sometimes called the “definition layer” of the ontology. · Assertional. This part is sometimes called the “axioms layer” of an ontology. It is a set of assertions applying to the basic concepts and relations, e.g.: context GeneralizableElement self.isRoot = yes implies self.supertypes->isEmpty context GeneralizableElement self.allSupertypes->forAll(s | s self) · Pragmatical. This is the so-called toolbox layer. It contains a lot of pragmatical information that could not fit in a) or b). For example, if there is a concept of Class defined in part a), then part c) could contain the way to draw this concept on screen or paper, as a rounded square for example. A number of pragmatical data may be found in an ontology, for example the way to serialize or to pretty print the different concepts and relations of the ontology or an API expressed in IDL. It is of paramount importance that this pragmatic information could be kept packaged and close to the basic concepts it is related to. Of course the UML practitioner has already recognized above the UML basic entity level, the OCL statement level and the graphical display level.

THE IMPORTANCE OF THE META-OBJECT FACILITY After the definition of UML (Kobryn, 1999), we may observe now a new wave of proposals at OMG, characteristics of a new period and of a new reac-


Figure 1: Conceptual representation of a meta-model stack meta

Entity

M3

meta

Relation meta

meta

StkInstance

source

instanceOf

meta

aCat

meta destination

StkClass

M2

meta instanceOf

Cat

M1

tion. At the centre of this evolution, we find the MOF, unique and self-defined meta-meta-model. The MOF has emerged from the recognition that UML was one possible meta-model in the software development landscape, but that it was not the only one. Facing the danger of having a variety of different meta-models emerging and independently evolving (data warehouse (CWM, 1998), workflow (Schulze, Böhm & Meyer-Wegener, 1996), software process, etc.), there was an urgent need for an integration framework for all meta-models in the software development scene. The answer was thus to provide a language for defining metamodels, i.e., a meta-meta-model. This is the purpose of the MOF. As a consequence, a layered architecture has emerged, with the following levels: · M3: the meta-meta-model level (contains only the MOF) · M2: the meta-model level (contain any kind of meta-model, including the UML meta-model) · M1: the model level (any model with a corresponding meta-model in M2). Some also add a fourth layer called M0, for terminal instances, but this will not be considered here. A parallel may be drawn with the domain of formal programming languages. Level M2 corresponds to the grammar level. Level M1 correspond to the program level. Level M3 corresponds to the meta-grammar (like the EBNF notation for example). If we wanted to consider level M0, this would be made to correspond to one given dynamic execution of a program. The example of Figure 1 may serve to illustrate the basic notions present in a meta-model stack. It represents the fact that the Smalltalk object aCat is an instance of the Smalltalk class Cat. This is part of a Smalltalk model (M1), itself defined by the Smalltalk meta-model (M2), itself defined by the MOF meta-

Bézivin • 89

meta-model (M3). As we can see, any entity at one level finds its definition at the upper level. The definition relation is called meta here, but is usually kept implicit in practical frameworks. In the very simple described situation, what we see is that there are three notions (meta-classes) at the meta-model level called StkInstance, StkClass and instanceOf. At the upper level, we find two notions called here Entity and Relation, but usually called Class and Association. This self-defined upper level corresponds to the MOF and represents the fixed-point of the organisation. One essential notion that is missing from the simplified diagram of Figure 1 is the concept of Package, defined also at level M3.

SOME EXAMPLES OF META-OBJECT FACILITY SYSTEMS We have mentioned the MOF, the unique meta-meta model of OMG. However, in order to be fair and complete, we should mention that similar meta-model architectures have also been used outside OMG. Other important efforts in the same domain have been conducted for example by Microsoft and then transferred to the Meta-Data Coalition (MDC). This section rapidly describes it and shows that the abstract concepts are similar, within a different industrial strategy. The OIM (Open Information Model (MDC, 1999)) officially aims to support tool interoperability via a shared information model, across technologies. It is designed to encompass all phases of a project’s development lifecycle, from analysis through deployment. The MDC architecture is also based on a meta-meta-model. It was initially called RTIM (for Repository Type Information Model) playing conceptually the same role as the OMG MOF. Like the MOF, this level defining the global modelling language, has been aligned on the core elements of UML 1.3. The OIM entities represent meta-models and the links between them defines dependencies. Each meta-model is composed of interfaces and classes. A dependency link from meta-model A to meta-model B means here that interfaces in A may inherit interfaces in B or that classes in B may support interfaces in A. The collection of meta-models defined by the OIM covers the whole spectrum of information systems: Analysis and Design model, Object and Component Model, Database and Warehousing Model, Business Engineering Model and Knowledge Management Model. Each of these contains in turn the essential packages to deal with the concerned topic. The Business Engineering Model has for example submodels dealing with Business Goals, Business rules and Business Processes. In a very rapidly moving context, the OIM MDC meta-models are now being merged with the MDA meta-models at OMG, mainly within the CWM metamodel (Common Warehouse Meta-Data).


UML AND MOF RELATIONS REVISITED UML has served as a trigger to introduce the MOF at OMG, in addition to CORBA (Figure 2). Officially, the Unified Modelling Language is a graphical language for visualizing, specifying, constructing and documenting the artefacts of a software-intensive system. For many, UML is much more than that and symbolizes the transition from code-centred to model-centred software production techniques. It is very likely that, in a historical perspective, UML will be given credit for the new perspectives opened as well as for the direct achievements realized as a modelling notation. On very practical grounds, UML is considered, at level M3, as a drawing tool by MOF practitioners, i.e., by designers of meta-models. More precisely, the MOF is also structurally similar to the kernel of UML, the CORE package. There is no theoretical reason for this. It is just more convenient since there is no need to define new tools to draw meta-models: the UML tools, mainly intended to support the design of UML models could as well be used in support of MOF metamodels. Note however that the design of meta-models is an activity much less frequent than the design of UML models. Furthermore it is an activity performed by a more limited and specialized population. The MOF uses UML in various ways, for example for graphical presentations. However, the main difference is that the MOF and UML are not at the same level in the OMG architecture model. The MOF is a meta-meta-model and is at the level M3 while UML is a meta-model and stands at level M2. The MOF is a language for defining meta-models and UML is just one of these meta-models. Other meta-models that are being defined at the level M2 are for example related to common warehouse, workflow, software process, etc. Figure 2: Evolution of meta-model architecture (a)

(b)

UML

MOF

(c)

MOF

UML aModel

UML aModel

aModel

SPE

Workflow Common Warehouse Metadata

Bézivin • 91

Many ideas have been successfully tested on UML and then transferred to the MOF because they were found to be of broader applicability. The first one is the OCL (Object Constraint Language (Warmer & Kleppe, 1998)). OCL is an expression language that enables one to describe constraints on object-oriented models and other artefacts. The word constraint is used here with the meaning of a precisely identified restriction on one or more values of a model. We see here a pleasant property of the global OMG modelling architecture. Since a meta-metamodel is structurally similar to a meta-model, features applied to one may also be applied to the other one. Therefore, OCL, which could be applied to meta-models to give more precise semantics to models, could also be applied to meta-metamodels to give more precise semantics to meta-models. This is exactly what happens when OCL is used at the M3 level. Another example is the answer to the SMIF RFP (Serial Model Interchange Format) of the OMG (XMI Partners, 1998). Initially the purpose of the Streambased Model Interchange Format was mainly to exchange UML models. As it has finally been issued, answered and approved, the proposal is being known as XMI (XML Model Interchange), a new standard for Meta-data Interchange based on XML and on the MOF. Once again, there is nothing to loose, if by providing a technical solution to a specific UML problem, it is possible to provide a more general solution that could be applied to the UML meta-model, as well as to other MOF-compliant meta-models already defined or yet to be proposed. Many more examples could be given of this trend. There are for example several demands to provide structured extension mechanisms for UML, going beyond single stereotypes, tagged values and constraints. Requests are being submitted for specialized UML-based meta-models on subjects like real-time or business objects. A possible answer to this would be some notion of profiles. In the case where this improvement is allowed to the UML meta-model, there is no reason that the other MOF-compliant meta-models should not also benefit from the added modular modelling mechanisms. A UML profile may be defined as a subset or a superset of the basic meta-model. There is however no agreement yet on the way this notion of a profile could be precisely defined. When a general solution to this problem will be found in UML 2.0, then we may envision important hierarchies of meta-models, allowing a good compromise between standardization and openness. In Figure 3, we may observe three meta-models used in practical software development. They are the UML for defining abstract software artefacts, the EJB (Enterprise Java Beans) for defining concrete software artefacts and the SPE (Software Process Engineering) for defining software processes. A SPE model could define the method (who is doing what, when and how) for transforming a UML model into a Java application. This description provides only a simplified view, but shows nevertheless how various models are going to play together.


Figure 3: Developing an application, the global view M3

MOF

UML

EJB

UML::App

EJB::App

SPE

SPE::App

M2

M1

CONCLUSION One of the recognized contributions of UML is that it has allowed the separation of the debate on the product notation from the debate on the process notation. This was a decision that was not easy to take and that will probably be considered as one of the main contribution of the UML creators. As a consequence UML is not a method like OMT, it is just a notation for describing software artefacts that could be used in different methods. The work on the notation can now progress and the work on the process can start integrating known research results and experience knowledge. Nevertheless, for this to happen, we needed a stable and robust meta-modelling framework, which was able to support software product and process modelling in an integrated way. The next big challenge to solve after objects was to deal with the emerging and multifaceted notion of software component. Here again, the critical question is how to cope with all new aspects that constitute the notion of component models vs. the plain old-fashioned object models. For example, the CMC (Corba Model of Component) is partially defined as a MOF-compliant meta-model. Therefore, here again it is very likely that UML and the MOF will have to play again together. To conclude this presentation, we may observe the tremendous progresses that have been made in the domain of meta-modelling techniques applied to software engineering and information system engineering in the last ten years. There seems to be a general agreement on the global layered architecture of models, meta-models and meta-meta-models. The recognition of multiple, co-existing metamodels is an important step forward. That means that, as illustrated by Figure 3,

Bézivin • 93

an engineer may be developing a given application and dealing with several models (i.e., a UML model and an Enterprise JavaBeans model), all of them defined by a precise meta-model, and all of these meta-models being based on the same meta-meta-model. A similar software process meta-model may also describe the method followed by this engineer. As a consequence, model engineering may become a transition as important as object technology for the software industry. However we are far from having solved all the problems in this area. The main bottleneck is not the development of tools, but probably the clear definition of modular architecture of models and meta-models. We see today the coexistence of several notions like models, meta-models, views (e.g., the diagram views of UML), packages and profiles of meta-models. More generally, the quest for simplicity and minimality seems essential if we want model technology to be rapidly adopted and to provide a valuable alternative to object technology.

REFERENCES Atkinson, C. (1998). Supporting and Applying the UML Conceptual Framework. in ’98, Beyond the Notation, J. Bézivin & P.A. Muller (Eds.), Springer Verlag LNCS #1618. Berners-Lee, Hendler, & Lassila (2001). The Semantic Web, Scientific American, May. Bézivin, J., Ernst, J. & Pidcock, W. (1998). Model Engineering with CDIF OOPSLA’98, Vancouver, post-proceedings, Summary of the workshop, October. Bézivin, J. Lanneluc, J. & Lemesle, R. (1995). sNets: The Core Formalism for an Object-Oriented CASE Tool, in Object-Oriented Technology for Database and Software Systems, V.S. Alagar & R. Missaoui (Eds.), World Scientific Publishers, p. 224-239. Bézivin, J. & Lemesle, R. (1997). Ontology-based Layered Semantics for Precise OA&D Modelling , ECOOP’97 Workshop on Precise Semantics for Object-Oriented Techniques. Cook, S., Kleppe, A., Mitchell, R., Rumpe, B., Warmer, J., & Wills, A. (1999). Defining UML Family Members Using Prefaces, TOOLS Pacific 1999, Melbourne, November. CWM Common Warehouse Metadata Interchange Request For Proposal, (1998). OMG Document ad/98-09-02, September 18. Iyengar, S. (1998). A Universal Repository Architecture Using OMG UML and MOF, EDOC’98, La Jolla, CA, 2-5 November. Kayser D. (1998). Ontologically Yours Invited Talk, ICCS’98, Montpellier, France, LNAI #1453, M.L. Mugnier & M. Chein (Eds.), August.


Kobryn, C. (1999). UML 2001: A Standardization Odyssey. Communications of the ACM, 42(10). Kruchten, Ph. (1999). The Rational Unified Process: An Introduction, Addison Wesley. MDC (1999). Open Information Model Version 1.1, August, Meta Data Coalition. OMG/MOF (1997). Meta Object Facility (MOF) Specification. AD/97-08-14, Object Management Group, Framingham, Mass., September. Raymond, K. (1997). Meta-Meta is Better-Better. IFIP WG 6.1 International Working Conference on Distributed Applications and Interoperable Systems, September/October. Schulze, W., Böhm, M., & Meyer-Wegener, K. (1996). Services of Workflow Objects and Workflow Meta-Objects in OMG-compliant Environments, OOPSLA 96, Workshop on Business Object Design and Implementation, San José, CA. Soley, R. and the OMG staff (2000). Model-Driven Architecture. OMG document available at www.omg.org November. Warmer, J., & Kleppe, A. (1998). The Object Constraint Language Precise Modelling with UML, Addison Wesley, October. XMI Partners (1998). XML MetaData Interchange (XMI) Document OMG ad/ 98-10-05, October 20.

Cheung & Chan • 95

Chapter 9

A Systemic Approach to Define Agents Andy Y. Cheung and Stephen L. Chan Hong Kong Baptist University, Hong Kong

Software agent is a very popular topic in computer science in the past few years. One of the promising applications of agent technology is shown in web applications. A tool for understanding, structuring, and defining agents becomes very important in order to release the power of this revolutionizing concept. This article surveys the definitions of agents and proposes an agent definition framework in the light of the Soft Systems Methodology to understand, define and model agents systematically.

INTRODUCTION Software agent is a rapidly developing area of research and the term ‘agent’ has become a popular buzzword in computer science in recent few years. On the other hand, Internet undoubtedly changes enormously the way of living for many of us. In business, it transforms radically the ways of doing business. In the near future, it is anticipated that many businesses would benefit from this new technology. For example, according to eMarketer (http://www.e-land.com/estats/ 100499_jupiter.html), the online brokerage sector will see tremendous growth in assets, from $415 billion in 1998 to over $3 trillion by the end of 2003. More recently, there are some attempts to apply agent technology to various areas including those involved in electronic commerce. (For further information, a survey can be found in Guttman, Moukas and Maes (1998). Particularly, we observe that agents are being defined to act as buyers and sellers and to commuPreviously Published in Challenges of Information Technology Management in the 21st Century, edited by Mehdi Khosrow-Pour, Copyright © 2000, Idea Group Publishing.

96 • A Systemic Approach to Define Agents

nicate and negotiate with each other autonomously or semi-autonomously, as in Moukas, Guttman, Zacharia and Maes (1999), Guttman et. al. (1998), Guttman and Maes (1998), Terpsidis, Moukas, Pergioudakis, Doukidis and Maes (1997), and Chavez and Maes (1996). In essence, agents are defined to represent electronic commerce components. As such, it is important to research into the definition of agents. Our view is that what is required is a systematic approach of defining an agent structurally in a problem situation, particularly within an electronic commerce environment. More specifically, in the process of defining an agent, we need to have an understanding of what we mean by “agent.” Unfortunately, “there is no real agreement even on the core question of exactly what an agent is” (Jennings, Sycara & Wooldridge, 1998). Many researchers discuss about their definitions, for example, see Wooldridge and Jennings (1995), Russell and Norvig (1995), Fagin, Halpern, Moses and Vardi (1995), Franklin and Graesser (1996), Gilbert (1997), Huhns & Singh (1998), Jennings and Wooldridge (1998), and Jennings et. al. (1998). We therefore suggest that a good understanding on agent concepts provides a powerful repertoire of concepts and tools to improve the way in which people conceptualize many types of software. We claim that the SSM is a good tool to understand and hence define agents. One of the most common attempts to understand agent concepts is by borrowing object oriented (OO) concepts. A further discussion can be found in Jennings et. al. (1998). The use of this approach shows a conceptual misunderstanding. Agent developers misunderstand that an agent is simply a specific type of objects. As a result, some key characteristics, such as autonomy, adaptability, etc. of agents are not captured. Wooldridge et. al. (1999) commented similarly that “there is a fundamental mismatch between the concepts used by object-oriented developers ... and the agent-oriented view.” Our aim in this chapter is to establish a methodological framework for the defining agents. We propose the adoption of the well-known Soft Systems Methodology (SSM) as a tool for understanding and defining agents that sufficiently delineates the major characteristics of agents by analyzing and structuring the problem situation, naming and defining the problem, and then eventually specifying the system. We first investigate and identify the central characteristics of agents by reviewing 12 definitions from the literature. Then we apply SSM to define agents by structuring the involved problem to cover the central characteristics of agents. Using this approach, we may avoid such fundamental mismatch between agent and the borrowed object oriented concepts (Jennings et al., 1998).

WHAT IS AN AGENT? The development of agent technology is ongoing, and thus there are many answers to the question “what is an agent?” We reviewed 12 definitions of agents


extracted from journal papers and project reports (The MuBot Agent; Russell & Norvig, 1995; Wooldridge & Jennings, 1995; Franklin & Graesser, 1996; Nwana, 1996; Maes, 1997; Gilbert, 1997; Brown, 1998; Gustavsson, 1998; Hodine & Unruh, 1998; Jennings et al., 1998; Iglesias, Garijo & Gonzalez, 1999). The survey results show that there are five essential characteristics to define an agent. Throughout this paper, we define, with these five essential characteristics, an agent as an autonomous and adaptive entity that is situated in some environment and performs purposefully in collaboration with other agents or human beings. The remaining part of this section will define, explain and elaborate concisely the central concepts, including autonomy, adaptability, situatedness, purposefulness, and collaboration, involved in the given definition. Autonomy Jennings et al. (1998) suggested autonomy is one of the key concepts of agent. Gilbert (1997) presented a stronger proposition that “all agents are autonomous, or it is able to control over its own actions.” Most of the reviewed definitions comprise autonomy as a characteristic of an agent (Wooldridge & Jennings, 1995; Franklin & Graesser, 1996; The MuBot Agent; Russell & Norvig, 1995; Maes, 1997; Iglesias et al., 1999). We observe that being autonomous implies that there are two logical subsequent actions for an agent: (1) Distinguishing and capturing relevant features in the environment without human and other intervention; and (2) Performing some activities in a self-directed manner in response to certain changes found of the environment. In other words, this feature focuses on the ability to take action without any intervention. This ability exemplifies one of the major differences between object and agent. An object is capable of handling messages with defined methods when it receives a message from other object. However, it is never a characteristic for an object to act without being triggered by any message. Therefore, we argue that the analogy between object and agent is not valid since one of the core characteristics, autonomy, of agents is not present under this analogy. In this chapter, we define autonomy as the ability to perceive, act, and react over time within an environment without direct intervention. Adaptability Brown (1998) pointed out that there are two basic capabilities defined under adaptability – action selection and learning from experience. He also reasoned that adaptability implies a number of sub-requirements, including being perceptive, reactive, and rational. These features manifest the intelligence of an agent. Before an agent makes any change to adapt, it has to extract information from the environment. In other words, it would act and its actions are based on information (Fagin et al., 1995).


In the light of the above studies, we define adaptability as the ability of learning to incorporate external changes as a result of sensing of the environment in order to act appropriately. Situatedness Maes (1997) claimed that agents inhabit some complex dynamic environment, while Gustavsson (1998) explained in more detail that every agent is in a society. In this sense, we may formulate the definition of situatedness into three propositions. First, an agent inhabits some environment; second, an agent is social, or it is able to behave socially (Wooldridge & Jennings, 1995); and third, behaviors of an agent are restricted by environmental constraints. Therefore, in defining an agent, it is necessary to figure out the environment that surrounds the agent to be defined, or to declare the environmental constraints imposed on the agent. We therefore use situatedness to mean the characteristic that an agent is always stationed and behaves in some kind of environment with constraints. Purposefulness As Gadomski suggested (http://wwwerg.casaccia.enea.it/ing/tispi/gadomski/ gad-agen.html), an agent performs “the tasks of humans.” In stronger and more solid words of Gilbert (1997), all agents are necessary to be goal-driven. Jennings, Sycara and Wooldridge (1998) explored this feature and argued that an agent should be capable of meeting some objectives, or simply accomplishing some purposes (Nwana, 1996). In our definition, being purposeful implies that there should be a goal defined for an agent, and all activities the agent performs would proceed towards the goal eventually. Most likely, we present the goal or purpose of an agent in terms of a transformation process. Throughout this paper, we relate purposefulness to the ability of acting in accordance with the entity’s will. Collaboration Being collaborative implies the ability to convey messages to other agent(s) in the system or users and to delegate the tasks they cannot achieve (Hodine & Unruh, 1998), as well as to receive and react to the messages initiated by other agents and users. In this sense, a dialog mechanism among agents is critical in an agent definition, particularly true for multi-agent systems. Many researches deal with this issue, such as the blackboard architecture for agent communication by Cohen et al. (1998). The above analysis comprises two aspects on collaboration of agents, including “receiving-reacting” and “sending.” The “receiving-reacting”


aspect relates to the operations that the agent has to perform while messages were received from other agents and users. The “sending” aspect deals with passing messages to other agents. Hence it is very important to structure the collaborative relationships among agents. In this chapter, we define collaboration as the ability to communicate and work with other agents.

THE SOFT SYSTEMS METHODOLOGY We suggest that the well-known problem solving technique SSM provides a solution to define an agent through analyzing problem situations, defining the problem, identifying and considering essential issues in the problem defined, and thus defining the agent(s) involved structurally. As suggested by Jennings, et al. (1998), it is important to conceptualize the problem in terms of agent(s) and then structure and define the agent(s). In this section, we first review SSM very briefly and then discuss how we can apply it as a methodology for agent definition. Checkland’s soft systems methodology The central theme of SSM is to define a structured, complete and thorough way in analyzing human activities. It focuses on defining the problem with extensive and detailed consideration in the relevant problem situation, particularly for ill-defined and unstructured circumstances. It provides a guideline with a set of conceptual tools to analyze the problem situation and define the problem(s). Good references can be found in Checkland (1981), Checkland & Scholes (1990), Patching (1990), and Lewis (1994). We will discuss briefly the seven stages of the methodology (Checkland & Holwell, 1998) as illustrated in Figure 1. A presumption to solve a problem is that we have already known what the problem is. However, under certain situation, it may not be the case. Some problem situations were ill defined and unstructured, such as most non-routinized huFigure 1: The Seven Stages of SSM 1. Enter Problem Situation Considered Problematic

2. Express problem situation

7. Develop actions to improve problem situation

5. Compare models and real world

6. Identify systemically desirable and culturally feasible changes

Real world

3. Establish root definitions of relevant purposeful activity systems

4. Develop conceptual models of the systems (holons) named in the root definitions

Systems thinking about real world


Figure 2: The CATWOE Analysis for the Root Definition (Adapted from [Chan & Choi, 1997]) Mnemonic Description C Clients or customer who benefit from or affected by the outputs from the system A Actors who carry out the activities within the system T Transformation taken place which convert the input to output within or by the system W Worldview perceived of the system, or the assumptions made about the system O Owner of the system who could determine the system to cease to exist E

Environment is the world that surrounds and influences the system, but has no control over the system

man activities (Chan & Choi, 1997). Therefore they require some guidelines and tools to investigate the ill-defined and unstructured problem situations and thus define the problem concretely. As shown in Figure 1, SSM comprises seven linked stages. The first stage requires information collection about an unstructured problem situation. Then, the information is presented visually by rich picture in the next stage. At stage three, after considerations of all relevant information in the expressed problem situation, the root definition of the identified relevant system to the problem is stated with the assistance of CATWOE analysis as defined in Figure 2 (Checkland & Scholes, 1990). A root definition mainly states the core purpose of a purposeful activity system (Checkland & Scholes, 1990). The core purpose is always expressed as a transformation process with the assistance of the elements Customer, Actor, Worldview, Owner, and Environmental constraint. The root definition is special because it is stated from a particular point of view. Different root definitions can be formulated in accordance with different point of views of relevant problem solver(s). Next, a conceptual model is built with reference to the root definition at stage four. This model describes a whole picture of necessary interconnected activities for carrying out the transformation process stated in the root definition. Measures of performance are also developed for monitoring activities. The constructed model will be compared with the real world situation at stage five. The differences between the conceptual model built and the real world lead to desirable changes. Hence, at stage six, we need to determine whether the identified desirable changes were implementable, or feasible to be implemented. Feasibility test is based on analysis of social, political and cultural streams. At the last stage, appropriate action(s) will be taken to accomplish the desirable and feasible changes.


Using SSM in agents definition The first three stages can be applied to define agents. We first understand the problem situation in which an agent inhabits by walking through stage one and two. The rich picture is used to summarize all relevant information collected from the real world analysis and represent it visually and comprehensively. It helps to understand the environment the agent inhabits, and may help also to figure out the constraint(s) imposed on the agent to be defined. Then, by performing the CATWOE analysis, the core purpose of the agent is expressed clearly, and the other components define the necessary structural features. A root definition defined at stage three will be used to express the agent’s structural characteristics. Furthermore, the conceptual model constructed at stage four expresses the minimum set of necessary activities the agent should perform in order to achieve the defined purpose. It presents the behavioral model of the agent.

SSM FOR AGENT DEFINITION We consider that an agent can be defined with five major characteristics, including autonomy, adaptability, situatedness, purposefulness, and collaboration. In this section, we discuss how SSM can be applied as a framework to define an agent based on the five core characteristics of agents. Autonomy As discussed above, being autonomous is the capability of performing some activities without external intervention. To define an agent, we need to define the one responsible for carrying out the activities of an agent. For this autonomy property, the agent is the actor itself. As an autonomous agent, it can accomplish its defined purpose by itself without external intervention. Adaptability As discussed above, adaptability manifests an agent’s intelligence in dealing with external changes. While defining an agent, we are dealing with the structural aspect of an agent. Unfortunately the capability of being adaptive cannot be shown in an agent definition since the feature is not structural, but behavioral. Fortunately, SSM never stops here. At stage 4 of SSM, the conceptual model depicts the necessary activities and their logical relationships. In our context, it can be used to model the necessary activities that an agent needs to perform to achieve its goal. And this behavioral investigation provides a good picture to explore the adaptability of an agent. We can use this tool to illustrate how an agent extracts information from its situated environment, what information it extracts, and how it acts to incorporate external changes.


Situatedness To define an agent, it is required to deal with the environment it inhabits and thus the environmental constraints imposed on it. This characteristic is called situatedness. CATWOE analysis of SSM argues that for completeness of defining a system, the E (environmental constraints) declaration is a must. According to Patching (1990), environment is the world that surrounds and influences the system. In agent context, environment is the world that surrounds and affects the agent to be defined. The environment imposes certain constraints on the agent to restrict its possible activities. In addition, SSM provides the W (worldview) declaration to state clearly the underlying assumptions made about the agent. The worldview affects the perception of the environment in which the agent situates. Different worldviews might generate different perceptions to the agent to be defined, and SSM helps searching for a better, if not the best, solution to construct the “desirable and feasible” agent. Purposefulness SSM defines an abstract concept purpose by using a less abstract method – expressing it as a transformation process T in CATWOE analysis. The process, in our context, transforms the input into output by the agent to be defined, and it is used to express the goal or purpose of the agent. As suggested in this paper, being purposeful is a central feature of being an agent. In the real world, a purpose is identified based on some underlying assumptions. SSM meets this requirement well. It provides the W declaration to depict the underlying point of view of the purpose made. Different perceptions will be equally valid under different assumptions. Therefore the T and W components of CATWOE declarations complement each other to provide a complete and logical consideration on defining the purpose of an agent. Collaboration Collaboration among agents and between agents and users is another critical concern in defining an agent. Therefore, in order to define an agent, we must state clearly with whom the agent works. More precisely, a collaborator in our context is defined as one who is affected by the outputs from the agent. In SSM, the C (customers) declaration of CATWOE analysis defines the collaborators it works with in environment and for its purpose. For a multi-agent system, if all agents involved were defined in this way, then a clear picture of the inter-relationships between agents are depicted, and thus acts as a good operational specification for determining the right changes and implementing the right agent to improve the relevant problem situation. (In SSM, this is depicted in the conceptual model of stage 4.)


Summary In summary, we observe that SSM can be fitted as a methodology to define agents in an organized way. The first 3 stages are applied to identify the structural components of an agent, or the “what” aspect of an agent. It covers the five core characteristics of which an agent should have. SSM provides also a thorough way to consider both technical and social issues involved while defining an agent. Additionally, the conceptual model at stage 4 acts as a tool to express the behavioral aspect, or the “how” aspect of which an agent should perform to accomplish its purpose within the world view and environmental constraints. It turns out to give a fuller model of the agent. Furthermore, without going into details, we point out that the remaining O (owner) declaration in SSM is the one who could determine the system to cease to exist (Patching, 1990). In our context, it is defined as the one who could modify or demolish the agent’s activities. This declaration identifies the basic control structure on the agent to be defined, while the detailed control mechanism can be explored in stage 4 based on the measures of performance and the monitoring activities of the conceptual model.

WEB ROBOT – A CASE STUDY We now apply SSM for the definition of the Web robot (Webbot) that was discussed in chapter 3 of the renowned text about agents (Caglayan & Harrison, 1997). We use this case to demonstrate the usefulness and powerfulness of employing SSM in defining agents. Problem situation A search engine such as Yahoo!, Alta Vista, Infoseek and Lycos, maintains a database to provide search services over the Internet. Users may submit a keyword and have a list of URL’s returned from the search engine. In order to maintain the database which contains the URL’s, ranking information, categorical information, keyword(s), content information of the corresponding page the URL points to, and so on, the Webbot is employed. The Webbot is a software agent communicating with Web servers using the HTTP protocol to extract information from the Web with some planned algorithm to rank the incoming new URL’s. To define the Webbot using SSM, it is necessary for us to structure and express the problem situation, and then identify the problem by considering the human intervention to the agent, and other possible collaboration among agents. We use the rich picture as a visual tool to elaborate the relationships between human and agents, as well as among agents, and highlight significant information for reference through the later stages in SSM.


Figure 3: A Rich Picture Using User Case Model from Booch et. al. (1999) For a Web Robot Initiate ODBC database Input initial URL, keywords and depth > Retrieve information from the web > User (from Use Case View)

> Store retrieval to database Extract information

> > Drop retrieval

Close the ODBC database

The Webbot traverses the Web starting from a given Web site. It follows hyperlinks on every page and retrieve documents along the way (Caglayan & Harrison, 1997). Mostly, the extracted document title and headings, keywords, summary, etc. are stored into the database of the search engine after indexing. Figure 3 applies the use case model from UML (Booch et al., 1999) to express the problem situation graphically. Root definition with CATWOE declaration After the definition of the elements of CATWOE, we state the root definition of the Webbot: “The search engine owned agent which, under the environmental constraints such as the tree structure of Web sites, components of Web pages written by HyperText Markup Language, and the restriction imposed by the HTTP protocol on information retrieval, transforms the input of uncategorised URL and associated information to categorised URL with supplementary information, which is being carried out by the actor such as the Webbot itself and the user, and directly affect the user from the view of the search engine.” The above root definition defines the agent and hence helps the developer to clarify the scope and objectives of building the Webbot, and to generate the detailed specification for the agent to implement.


CONCLUSIONS In working out this case, we observe that SSM provides a step-by-step structured guidance for defining agents. Moreover, SSM is an analytical framework for us to explore, understand and structure the problem situation, and thus conceptualize agent(s) involved and finally define it/them with the assistance of rich pictures, CATWOE analysis and root definition. By applying SSM in agent definition, we can also deal with abstract characteristics that an agent has, as discussed before. The six elements of CATWOE provide capability to determine fundamentally what characteristics the agent has, what environment it is situated in, and how to perform its operations in the environment. This works also in the system which contains more than one agent, and the iterative application of SSM to define all agents in the system would probably clarify the complex situation and thus draw a clear infrastructure of the agentbased system for analysts. It helps to resolve the problem of the lacking of an operational definition for an agent. After developing the rich picture, CATWOE analysis, and a root definition for the agent to be defined, SSM suggests to construct a conceptual model to model the behavioral perspective of the agent defined. The holistic view from the agent’s structural and behavioral perspectives can assist analysts and developers in analysing agent(s) involved in the desired system, and thus the development of the system per se.

REFERENCES Booch G., Rumbaugh, J. and Jacobson, I. (1999). The Unified Modeling Language User Guide. Addison-Wesley. Brown, S. M. (1998). A Decision Theoretic Approach for Interface Agent Development. Ph. D. Dissertation, Air Force Institute of Technology, Air University. Caglayan, A. & Harrison, C. (1997). Agent sourcebook. New York: John Wiley. Cameron, S. (1983). Module 8: Systems Approaches. Open University Press. Chan, S. L. & Choi, C. F. (1997). A conceptual and analytical framework for business process reengineering. International Journal of Production Economics, 50, pp. 211-223. Chavez, A. & Maes, P. (1996). Kasbah: An agent marketplace for buying and selling goods. In Proceedings of the First International Conference on the Practical Application of Intelligent Agents and Multi-Agent Technology (PAAM’96). London, UK, February. Checkland, P. (1981). Systems Thinking, Systems Practice. Chichester: Wiley.


Checkland, P. & Holwell, S. (1998). Information, Systems and Information Systems: Making Sense of the Field. Chichester: Wiley. Checkland, P. B. & Scholes, J. (1990). Soft Systems Methodology in Action. Chichester: Wiley. Cohen, P. R., Cheyer, A., Wang, M. and Baeg, S. C. (1998). An open agent architecture. In Huhns, M. and Singh, M. P., editors. Readings in Agents. San Mateo, CA: Morgan Kaufmann Publishers. Fagin, R., Halpern, J. Y., Moses, Y. and Vardi., M. Y., et al. (1995). Reasoning about Knowledge. Cambridge, MA: MIT Press. Franklin, S. & Graesser, A. (1996). Is it an agent, or just a program? A taxonomy for autonomous agents. In Proceedings of the Third International Workshop on Agent Theories, Architectures and Languages, Budapest, Hungary. Gilbert, D. (1997). Intelligent agents: The right information at the right time, IBM Corporation. See http://www.networking.ibm.com/iag/iagwp1.html. Gustavsson, R. E. (1998). Multi agent systems as open societies – A design framework. In Intelligent Agents IV – Agent Theories, Architectures, and Languages: Proceedings of the Fourth International Workshop (ATAL ’97), Providence, Rhode Island, July 24-26. Guttman, R. & Maes, P. (1998). Cooperative vs. competitive multi-agent negotiations in retail electronic commerce. In Proceedings of the Second International Workshop on Cooperative Information Agents (CIA’ 98). Paris, France, July. Guttman, R., Moukas A., and Maes, P. (1998). Agent-mediated electronic commerce: A survey. Knowledge Engineering Review, 13(2), pp. 147-160, June. Hayes-Roth, B. (1995). An architecture for adaptive intelligent systems, Artificial Intelligence: Special Issue on Agents and Interactivity, 2, pp. 329365. Hodine, M. & Unruh, A. (1998). Facilitating Open Communication in Agent Systems: the InfoSleuth Infrastructure. In Intelligent Agents IV – Agent Theories, Architectures, and Languages: Proceedings of the Fourth International Workshop (ATAL ’97), Providence, Rhode Island, July 24-26. Huhns, M. & Singh, M. P., (Eds.) (1998). Readings in Agents. San Mateo, CA: Morgan Kaufmann Publishers. Iglesias, C. A., Garijo, M. and Gonzalez, J. C. (1999). A survey of agent-oriented methodologies. In Intelligence Agents V – Proceedings of the Fifth International Workshop on Agent Theories, Architectures, and Languages (ATAL-98), Lecture Notes in Artificial intelligence. Springer-Verlag, Heidelberg. Jennings, N. R., Sycara, K. and Wooldridge, M. (1998). A roadmap of agent research and development. Autonomous Agents and Multi-Agent Systems, 1, pp. 7-38.


Jennings, N. R. & Wooldridge, M. (1998). Applications of agent technology. In Agent Technology: Foundations, Applications, and Markets, SpringerVerlag, March. Lewis, P. J. (1994). Information-Systems Development: Systems Thinking in the Field of Information-Systems. Pitman, London. Maes, P. (1997). Agents that reduce work and information overload. In Bradshaw, J. Software Agents, Menlo Park, CA: AAAI Press/MIT Press. Moukas, A., Guttman, R., Zacharia, G. and Maes, P. (1999). Agent-mediated electronic commerce: An MIT Media Laboratory perspective. To appear in International Journal of Electronic Commerce. Nwana, H. S. (1996). Software agents: An overview, The Knowledge Engineering Review, 11(3), pp. 205-244. Patching, D. (1990). Practical Soft Systems Analysis. London: Pitman. Russell, S. & Norvig P. (1995). Artificial Intelligence: A Modern Approach. Prentice-Hall. Smith, D. C., Cypher, A. and Spohrer, J. (1994). KidSim: Programming agents without a programming language, Communications of the ACM, 37(7), pp. 55-67. Terpsidis, J., Moukas, A., Pergioudakis, B., Doukidis, G. and Maes, P. (1997). The potential of electronic commerce in re-engineering consumer-retailer relationships. In Proceedings of the European Conference on MM & E-Commerce, Florence, Italy, November. The MuBot Agent. Mobile unstructured business object (MuBot) Technology. See http://www.crystaliz.com/papers/mubot.htm. The SodaBot Agent. See http://www.ai.mit.edu/people/sodabot/slideshow/total/ P001.html. Wooldridge, M. & Jennings, N. R. (1995). Intelligent Agents: Theory and Practice. Knowledge Engineering Review, 10(2), pp. 115-152. Wooldridge, M., Jennings, N. R. and Kinny, D. (1999). A methodology for agentoriented analysis and design. In Agents ’99: Proceedings of the Third International Conference on Autonomous Agents, Seattle, WA, May.

108

• Modeling of Coordinated Planning and Allocation of Resources

Chapter 10

Modeling of Coordinated Planning and Allocation of Resources Alexey Bulatov University of Houston-Victoria, USA Atakan Kurt Fatih University, Istanbul, Turkey The chapter proposes a method for the formal description of enterprises as complex human-technical systems. In distinction from other methods this approach is aimed at the analysis of parallel planning and allocation of resources from different points of view. The method is valid for every hierarchical level of enterprise subdivision. It allows the design of decision making systems for various tasks of coordinated planning and allocation of resources. The optimal decisions are made in parallel for different subdivisions and subsystems, then the generalised decision for the global task is determined.

INTRODUCTION Control of enterprise functioning lies in optimal planning and allocation of resources with regard to the whole set of performance tasks. Difficulties in the optimal coordinated resources allocation are caused by the problems, such as the interdependency of systems, resources and application tasks, a lack of resources and time, contradictory criteria for the decision of resource-consumption tasks, insufficient information about the current state of enterprise subsystems, and also the tendency towards reduced staff size under increasing complexity of application tasks (Boulatov, Shaposhnikov et al., 1997; Petrov, 1998). Previously Published in Challenges of Information Technology Management in the 21st Century, edited by Mehdi Khosrow-Pour, Copyright © 2000, Idea Group Publishing.

Bulatov & Kurt • 109

Computer support for resources allocation is therefore vital. Automation of resource control makes it possible to make control decisions quicker, more precisely, provide a full overview of data and all desirable explanations. Unfortunately existing information systems can not satisfy modern requirements completely and can not provide the coordinated resource control (Boulatov et al., 1997; Petrov, 1998). Most of these systems are only database systems without reasoning capabilities. Intelligent systems can solve just a limited set of control tasks. This is due to the difficulties in developing a unified formal representation of enterprises for solving a variety of particular resources allocation tasks. At present, no complete methods are elaborated for the design of decision support systems based on system approach. It means that no decision making system are able to support the coordinated control the whole set of resources-consumption processes based on unified methodological position. This problem determinate the aim and tasks of the research. The purpose consists in the elaboration of method of the design of resources allocation control system based on system approach. To achieve the purpose the following tasks have been set: 1. Formal description of enterprises, their structures and resource consumption processes. 2. Decision support in planning and allocation of resources. 3. Design of decision control systems for resources allocation. Lets look how these tasks were solved.

FORMAL DESCRIPTION OF ENTERPRISE PERFORMANCE Decision support system for planning and allocation of resources must be able to analyze the whole set of resource consumption processes from different points of view but based on unified methodological approach. To design such systems it is necessary to work out a general model for a formal description of an enterprise as a unified object. This approach should formally reflect internal structures and various resource consumption processes as well as a decision making process for control of resources allocation. Before discussing the generalized model it is necessary to say a few words about enterprises as objects of performance. Enterprises are considered as complex, multifunction, closed, autonomous objects. In general, they can be represented as a totality of three interdependent components: organizational, technical and resource structures (Petrov, 1998; Gegov, 1997). The technical structure reflects the structure of technical systems of the enterprise, their distribution, physical and functional interconnections and the techno-

110


logical processes. The organizational structure regulates the process of performance by the staff. It consists of instructions on technical system application and maintenance, staff structure and rules of human interaction, rules of staff life and actions, ordering of human competence in technical facility control, and so on. The third structure describes available resources: fuel, oil, spare parts, tools and so on. All of these structures have a hierarchical character. All the people involved, heads of every subdivisions as well as workers, have their own levels of control and management of enterprise systems. The higher the man’s status, the higher the level of systems he controls. For this reason, the analysis of an enterprise must be based upon decomposition. In this case we can represent an enterprise as a hierarchical model of interconnected systems and subsystems. The organizational structure should be the dominant one for this decomposition process. The following postulates about enterprises constitute the basis of the proposed approach. The enterprise is able to carry out the appointed tasks if all its systems are able to carry out their particular functions and the coordinate control of these is provided. The main principle of coordinated control of object performance is to coordinate the functioning of the lower hierarchical levels in subordination to requirements and restrictions of higher levels. For hierarchical structures the principle of criteria coagulation becomes apparent. The principle is: the higher the level of human-technical subsystem, the more «organizational» and less «technical» are the criteria and restrictions involved. Depending on the decomposition analysis of enterprises and based on the above-mentioned postulates, the generalized model must correspond to the following requirements: 1. The method must be able to describe the hierarchical character of enterprises. 2. The formalism must be easily interpreted for every level of the hierarchical systems. 3. The primitive objects of the method (the simplest elements of decomposition) should be distinguished. These objects (Simplexes) must be functionally closed and specialized. 4. It must be possible to represent the composition of simplexes as a simplex. 5. The two levels needed to describe the formalism are: • the abstract level, for decomposing an enterprise to a hierarchical structure of congruous control of simplexes; • the concrete level, to represent the internal functioning of each simplex and the decision making process of governing the internal control of its functioning. The internal hierarchical structure of an enterprise explains the first requirement. The second is necessary for providing a unified character to the formalism independently of the level to be described. The third requirement means that all


Figure 1: Simplex aF

xW

gM

gF

aM

gIn

D x’ϕW

xM

F

M

ϕ’

xAd A

xIn R

ϕW

xW W

ϕ”

I xW

xW

systems and subsystems of this hierarchical structure can be represented as primitive blocks, and, to satisfy the second restriction, these blocks must have a similar internal structure. The forth point is easily understood, because the composition of simplexes is a system of higher hierarchical level, which should be described as a normal simplex according to the second restriction. This provides the opportunity to begin and to complete the analysis at every level of detail of enterprises. The fifth one requires two levels of the formalism: the first - for decomposing a complex enterprise into a hierarchical system of similar simplexes irrespective of their specialization, and the second - to represent the appointment, internal structure and rules of functioning of every simplex by unified means. So the analysis of resource control processes of enterprises is reduced to the multilevel aggregate of formalisms. And a model of highest levels specifies restrictions for lower levels. The formalism, which corresponds to these requirements, is called the Combined Formal Technique. It is named «Combined» because it has two levels of description: abstract and concrete. The abstract level of the technique assumes that every control system and subsystem can be presented as the block shown in Figure 1 irrespective of their specialization. For this figure: W is controlled object; F is the decision making model, that is reasoning algorithm as a set of control procedures; M is the model of the controlled object, that is a knowledge base containing knowledge on the structure and the current state of objects, and rules for how it functions and consumes resources;

112


A is the adapter, that is the means for choosing a set of procedures from the decision making model F on the basis of situation analysis in controlled object W. I is an interpreter, that is the means for reorganizing M on the basis of the state interpretation (information obtained from F and W) D,R - simplex interfaces; xiii- information signals about corresponding blocks states; ϕiii- control information. The following describe how a simplex functions. Information about the controlled object state and information about actions of control come to the interpreter I, which produces the signal xi to bring the model M to the state corresponding to the present situation. The decision-making model F receives information about states M and W and instructions from A to choose the set of control rules, analyzes it and produces the control action. The object of control W arrives at a new state, and the control process repeats. A simplex at a lower level is both a control and controlled system at the same time. It receives control signals from the higher-level simplex. In Figure 1: aF - the present aim of the simplex function, guided by the highest level; aM - information about the purpose and changes in the environment and in the whole controlled system; gI,gF,gM - signals for the rigid control of corresponding blocks guided by the highest level. Figure 2: Complex of coordinated control


Considered the coordinated control of planning and allocation of resources, controlled object W can be represented as an aggregate of subsystems. And each subsystem has its own control system submitted to the simplex-coordinator and controlled object. In this way we receive two-level hierarchical system of simplexes. It forms the Complex of Coordinated Control structure (Figure 2). The structure consists of a simplex-coordinator and controlled simplexes. Simplex-coordinator provides the coordinated control of subordinated simplexes, and they control their controlled objects and their resources. Such complex is considered as the main unit of every enterprise. The higher the level of a simplex, the more generalized are its models F and M and more strategical and organizational are its decisions. The lower level simplex produces more tactical and technical solutions. It directly corresponds to the postulates about enterprises as objects of performance. What is significant in this structure is that all the feedbacks arrive at a simplexcoordinator from controlled simplexes, not from the final controlled objects W1 and W2. This is because Simplex 0 has Simplex 1 and Simplex 2 as controlled objects (not W1 and W2). To illustrate we provide a simple example. A worker (W1or W2) should not render an account about the state of his resources to the director (Sim0). The director does not need to control every worker’s actions. He produces global generalized decisions and needs generalized information about division’s states and availability of resources from persons who control the divisions. These persons (Sim1 and Sim2) provide him with their generalized view about their staffs and other resources states (xM1 and xM2) and about their control actions (ϕ1 and ϕ2). So, the Combined Formal Technique is universal, multipurpose. It lets us to decompose structures of enterprises as well as resource consumption and decision making processes into hierarchical models of similar units. It guarantees the system approach for the analysis of planning and allocation of resources. And coordinated resources allocation of the lover hierarchical levels in subordination to the restrictions and requirements of higher levels is provided. The Technique lets to create hierarchical models with every detailed elaboration. The only condition is required: we need to provide a conjugated formal language of simplexes of different levels. Now, the concrete level of Combined Formal Technique, the unified formal description method of M,F,A and I blocks representation, is required. The concrete level of Combined Formal Technique must be able to represent all the object structures, all the resource consumption processes of different nature as well as decision making process for planning the resource allocation (Meyer, 1993), and also provide a conjunction of internal blocks of any simplex as well as a conjunction of simplexes.

114


To satisfy these requirements, the principle of imitation models has been chosen (Kemper, 1996). These models are based on modified Petri Nets. Petri nets are the integration of graph and discrete dynamic system. So they can represent static and dynamic models of analyzed object. Potentials of the classic Petri Net approach are limited by asynchronous discrete systems applications. For the solving of real life tasks many modifications of Petri Nets have been proposed. But the existing modifications don’t satisfy these requirements completely (Feldbrugge, 1999). That’s why new Petri Net modification is offered for the concrete level of the formal technique. The modified Petri net is defined as. PN’ = {P,T,I,O,µ,U,F,H,R,CL}, where: P = {p1,p2,...,pn} - places (conditions); T = {t1,t2,...,tm} - transitions (events); I -input function: P∅T; Ooutput function: T∅P; m = {m1,m2,...,mk} - tokens: P∅N; A = {A1,A2,...,Al} - vector of token attributes, Ai=[ai1,ai2,...,air], m∅A; U = {u1,u2,...,um} - conditions of transition firing dependent on the presence of tokens in the input places and on their attribute values, T∅U; F = {f1,f2,...,fm} - functions which change the state of input and output places at transition firing, T∅F; H = {h1,h2,...,hm} - delays in transition firing, T∅N. R = {r1,r2,...,rm} - priorities of transitions, T∅N; CL - Petri-net clock. The main idea of the modification consists of the following. Tokens can have a vector of attributes containing information, which is necessary for representing the system state and decision making. For example, it may hold data about the present quantity and quality of recourses or something else. Transitions associates with priorities, and also with conditions of their firing. Firing take place dependent on token presence in the input places and dependent on their attribute values. During transition firing the following procedures can be executed: 1. deleting some input tokens and changing attribute values for other input tokens; 2. delaying the process with the corresponding time; 3. placing tokens in some output places, forming values of their attributes dependent on the obtained information. Also Petri-net clock are introduced for the representation of time intervals. The proposed modification of Petri nets lets us to design models of structures enterprises as well as models of resource consumption and decision making processes and let us to find the control decisions analyzing alternative operations.


Therefore this modification is the universal language for the conjugation of internal blocks of every simplex as well as the conjugation of simplexes of different levels. Therefore we apply the Combined Formal Technique for the description of enterprises, their structures and resource consumption and planning processes. And we use modified Petri nets for the representation of the concrete level. Now decision-making approach for coordinated planning and allocation of resources must be discussed.

DECISION SUPPORT IN PLANNING AND ALLOCATION OF RESOURCES The task of decision making can be formulated in such way: to a known state of the object X is necessary to put in correspondence control action U. This control action is a physical implementation of decision Si, which is a member of the set of valid solutions S. This decision is recognized as optimal on the basis of decision quality criteria. This is a model of multicriteria task of decision making. At decomposition on subsystems the decision making can be represented as follows (Figure 3). The general task of coordinated planning and allocation of resources is divided into a number of independent subtasks. The solution of each separate subtask is assigned to special procedures, which are named as DecisionMaking Units (DMU). For the providing of coordinated operation of various Decision-Making Units it is necessary to use a hierarchical principle of information support systems construction. The basis of this hierarchical construction is the uniform purpose. For multilevel system the process of decision making is divided into the following stages: • Setting of the global (general) task of decision making on planning and allocation of resources; • Splitting of the global task into subtasks and definition of a part of each subtask in the global task; • Making of decisions within the limits of separate subtasks; Figure 3: The decision making process DMU -Coordinator

DMU -1 U1 V

X1

DMU -2 U2

X2

DMU -N

. . . . UN

Controlled object - the process of planning and allocation of resources allocation of resources

XN X

116


• The coordination of these particular decisions; • Developing of the uniform generalized decision of the global task. Such method of decision making corresponds to the Combined Formal Technique. Every Decision-Making Unit can be presented by a simplex with the model M of object and model F of decision making. And the simplex-coordinator develops uniform solution of the general task on the basis of composition of particular decisions made by subordinated simplexes. All the decision-making is based on the analysis of the data about the controlled object. For information representation about enterprises and their resource processes it is advisable to use relational data model. So, the models and methods for coordinated solving of resources planning and allocation tasks are proposed. These results let us to syntheses them in the method for the design of decision support systems for resource control.

DESIGN OF DECISION CONTROL SYSTEMS FOR RESOURCES ALLOCATION. The design procedure consists of the following stages: 1. The organizational, technical and resource structure of the enterprise is analyzed. The rules of performance and resource consumption are studied, the set of resources planning and allocation tasks is determined. Also the rules of people interaction and departments cooperation are studied, their roles in resource control and in decision developing are determined. Then directions and forms of document circulation are analyzed too. 2. The organizational structure is represented as a hierarchical tree. Each node represents a department of the stuff. The model describes the system of subordination, directions of information flows. The model also describes the distribution of resource control tasks and subtasks between departments according to hierarchy. The organizational and technical processes taking place in each division are analyzed. Their verbal description is developing. 3. The formal description of resource consumption, allocation and planning processes is making for each department. The information necessary for the decision making is determining for each department. 4. The abstract level of the Combined Formal Technique is applied. The complex of coordinated control is developing on the basis of the hierarchical tree. Every department (every node of the tree) is represented by a simplex. 5. The concrete level of the Combined Formal Technique is applied to each of simplexes. On the basis of the modified Petri nets imitation models of resource consumption processes taking place in simplexes are created. Decision making models for resource allocation and planning control are developing using the same approach.


Figure 4: The complex of maintenance and resource allocation coordinated control

6. Information arrays and data interrelations are analyzing. The database is designing and filling by information. 7. The user interface and applied software are developing. 8. Methodical documentation is developing. The approach was applied to designing a vessel decision-making system for planning the maintenance of power generation and distribution system. It is extremely difficult to make the optimal plan coordinated between subdivisions and adjusted with all kinds of resources (time, human and various material resources). The concrete technical and organizational structures were considered. Based on this organization structure we can represent the maintenance actions control system as the coordinated control complex. Commanders assign maintenance tacks and coordinate resource consumption, allocation and planning activities of subordinated groups. Model of coordinated maintenance control of power generation and distribution system is represented as a complex shown in the Figure 4. Every simplex contains the models of organization, technical and resource structures, as well as decision-making models detailed up to required degrees. The simplex - coordinator is based on the generalized models, and subordinated simplexes - on more detailed models describing operation of particular divisions The concrete level of the Combined Formal Technique is realized on the modified Petri net language. Initial data and results of simulation are initial and finitary net marking and coloring of tokens. In the following figures some simplified models used in this system are shown. The Figure 5 represents the modified Petri net model for resource distributing between maintenance actions.

118


Figure 5: Model of resource distributing between maintenance actions

Figure 6: Model of maintenance plan optimization by means of resources redistribution

P1

t1

P2

t2

P3

t3 P t P t5 P6 t6 P7 t7 P8 t8 4 4 5

P9 t9

P10

For this figure: P1,P2,P3,P4,P5,P6 - applying actions 1,2,3,4,5 and 6. P21,P22,P23 - places containing resources (materials, spare parts) P24 - place containing tools; P31,P32,P33,P34 - places describing members of crew; P11,P12,P13,P14,P15,P16 - actions 1,2,3,4,5,6 are planned; t1,t2,t3,t4 - modelling the execution of actions 1,2,3,4,5,6. Necessary resources characterize every maintenance action: tools, materials, spare parts, members of the crew who can perform this action and time of executing the action. For example, the fist action here needs one tool and one spare part and can be executed by one of two members of the crew. Action is planned if the correspondent position get a token. If there are insufficient resources or manpower, some applied actions can not be planned and the commanders are notified about it. In this case commander tries to redistribute material resources and executors between groups. The Figure 6 shows the decision making model for the optimization of maintenance actions plan. As the result of this modeling we have the plan which contains the maximal number of actions under the limited resources.


For this figure: P1 - assignment for the maintenance actions planning; P2 - set of maintenance action applications is assigned; P3 - the preliminary plan of actions is developed; P4 - the set of non-planned applications is not empty; P5 - applications which are not initially provided for resources are removed. But the set of non-planned applications is not empty yet; P6 - non-planned applications which were initially provided for resources are removed. But the set of non-planned applications is not empty yet; P7 - the set of scarce resources is developed; P8 - optimization of actions plan is needed; P9 - lack of human; P10 - planning is completed; t1 - developing of the set of actions; t2 - developing of the preliminary plan of actions; t3 - checking if all applications are provided for resources. t4 - removing the applications which are not initially provided for resources; t5 - determining the applications which were not planned because of the lack of time; t6 - determining the set of scarce resources; t7 - attempt of resource coordination; t8 - improving of the plan; t9 - changing of executor’s priorities. For the determining of compatibility of maintenance operations as well as for the simulation of technical processes in the system the model of technical structure was used. Based upon the developed algorithms and models the vessel decision-making system for planning maintenance was designed. It shows that it satisfies to the stated requirements. It can develop coordinated decisions with required detailed elaboration. The realization of the proposed approach confirms the appropriateness of its application for the design of decision support systems for resource control.

CONCLUSIONS The proposed approach to solving tasks of coordinated planning and allocation of resources has shown advantages compared to other techniques. In distinction from other methods it is based on the unified formal description of an enterprise. It guarantees parallel optimization and coordinated decision making for a large number of resource control tasks. This approach can be applied to various complex human and human-technical systems such as plants, enterprises, and so on.

120


REFERENCES Boulatov, A., Shaposhnikov, S. et al. (1997). Intelligent System for Vessel Performance and Control, Proc. of the Tenth International Symposium on Methodologies for Intelligent Systems. Charlotte, NC, Oct.15-18, Charlotte, NC, p.187-196. Feldbrugge, A. (1999). Petri Net Tool Overview 1998, Lecture Notes in Computer Science.- Springer Verlag, 674, p. 92-122. Gegov (1997). Multilayer Fuzzy Control of Multivariable Systems by Active Decomposition, International Journal of Intelligent Systems, January, 12(1), p.66-78. Kemper, P. (1996). Reachability Analysis Based on Structured Representations, Lecture Notes in Computer Science, 1091, p.23-45. Meyer, W. (1993). Specification and construction of performability models, 2nd Int. Workshop on Performability Modelling of Computer and Communication Systems, Le Mont Saint-Michel, France, June, Saint-Michel. Petrov, A. (1998). System Analysis and designing of automation systems for organizational control, Proc. of Moscow State Technical University, 2, p. 2736.

Busch & Dampney • 121

Chapter 11

Tacit Knowledge Acquisition and Processing Within the Computing Domain: An Exploratory Study Peter Anthony Busch Macquarie University, Australia C.N.G. ‘Kit’ Dampney University of Newcastle, Australia Given that Articulate Knowledge has long been codified and substantiated for daily usage, the role of articulable Tacit knowledge needs to be examined in greater detail with an emphasis on its usage in the public sector. What needs to be born in mind however is that the codification of Tacit Knowledge is a reality and that eventually almost all Tacit Knowledge becomes so. This process is not necessarily immediate but takes place in a stepwise format passing through partial to full codification. The authors also argue that codification is more prevalent today due to the need for organisations to be more accountable. Accountability requires accurate reporting and quantitative interpretations of information which in turn demand codified knowledge, not tacit ambiguities.

INTRODUCTION Almost certainly a great deal of effort and expense has been placed into the articulation of knowledge, particularly in Western societies (Nonaka, 1991; Nonaka & Takeuchi, 1996). The Japanese approach for example has long been recognised to make greater use of the Tacit component when undertaking day to day tasks or even important business deals. In order for such success to take place however, Previously Published in Challenges of Information Technology Management in the 21st Century, edited by Mehdi Khosrow-Pour, Copyright © 2000, Idea Group Publishing.

122

• Tacit Knowledge Acquisition and Processing Within the Computing Domain

a significant amount of Tacit Knowledge is drawn upon. It has been noted that the influence of Tacit Knowledge in the Health sector for example, is significant (Goldman, 1990; Scott, 1990; Meerabeau, 1992). The authors present a few models by which it is hoped they may be tested within the public and private sector domains, although there is at least sound evidence to suggest that Tacit Knowledge can be measured (Sternberg, Wagner & Okagaki, 1993; Wagner, 1987; Wagner and Sternberg, 1985, 1991; Williams and Sternberg, in press in Sternberg, Wagner, Williams & Horvath, 1995; Horvath, Forsythe, Bullis, Sweeney, Williams, McNally, Wattendorf & Sternberg, 1999; Wagner, Sujan, Sujan, Rashotte & Sternberg, 1999). We would like to point out that we consider only “articulable” Tacit Knowledge able to be codified, tacit knowledge sensu latu encompasses more as one would expect. Finally, throughout the article AK is used to indicate Articulate or Codified Knowledge, and TK is used to indicate Tacit Knowledge.

TACIT KNOWLEDGE VERSUS ARTICULATE KNOWLEDGE There is evidence to suggest that a sliding scale exists between data, information and knowledge. “Data consists of raw facts … Information is a collection of facts organised in such a way that they have additional value beyond the value of the facts themselves ……. Knowledge is the body of rules, guidelines, and procedures used to select, organise and manipulate data to make it suitable for a specific task …..” (Stair & Reynolds, 1998 :5 [italics added]). This is fine as a generalisation, however it should be acknowledged that an extension to this should note that knowledge itself may be divided into a further two categories, namely that of Tacit and Articulate knowledge, the former for example being a favourite with the Japanese (Takeuchi, 1998). It was Polanyi (1959 in Greeno, 1987) who was instrumental in first ……. distinguish[ing] between explicit [or articulate] knowledge, “what is usually described as knowledge, as set out in written words or maps, or mathematical formulae,” and Tacit knowledge, “such as we have of something we are in the act of doing” (:12) Tacit knowledge is thus that component of knowledge that is widely held by individuals but not able to be readily expressed. It is expertise, skill, “know how,” as opposed to codified knowledge. Articulate Knowledge is typically acquired through formal education, writings, books, rule sets, legal code to name but a few examples. Tacit Knowledge on the other hand is acquired through a more “intimate” relationship between a “master” and an “apprentice.” It is transferred more orally, more by way of example, more by sight. The writers would like to note that “apprenticeship” within the article


Model 1: The Tacit Knowledge codification cycle

refers to knowledge transfer (typically by an expert or senior person) and acquisition (typically by a novice or junior person) within an organisation. In other words not just the term apprenticeship in its “blue collar” sense.

MODEL 1: THE CONVERSION PROCESS While it has been shown “…….. that new tacit knowledge is generated as former tacit knowledge becomes codified” (Senker, 1995 :104), if we examine this process more closely, we feel in actual fact the transition to codified knowledge is not so sudden. What begins as an initial process of socialisation as pointed out by Nonaka (1991, 1996), characteristic of experts showing novices ‘the ropes’, turns into a gradual codification process. Before this “dark” codification phase takes place however Tacit Knowledge becomes formalised by systems of rules, typically “unspoken rules,” that nevertheless exist within the organisational sphere. We may term these “etiquette sets,” over time however, even etiquette becomes codified. The partial codification phase characterises an environment where notes are available but not in any “official capacity.” Examples would include “research in progress,” “draft documents,” material which is “not to be quoted” and so on. Such material is far from being tacit, however fully codified it is not. Full codification is widespread, most knowledge is codified. This includes all manner of printed and electronic material. Tacit Knowledge transference between individuals is thought to take place whereby TK becomes codified over time, this process is thought by the authors to be cyclical, but not necessarily symmetrical. In other words although Tacit Knowledge becomes chronologically codified, the transference from one individual to another does not take place equally. Senior people generally tend to teach junior people TK, or experts tend to teach novices. A novice may however be senior and the expert junior (especially in the sciences and technology).

124


Model 2: Model illustrating the adoption of TK by an individual over a career

MODEL 2: TACIT INFORMATION MODEL An examination of Model 2 reveals that several spirals comprise the model. The inner dashed spiral could be said to represent the AK learning “adoption” of the individual over a career lifetime, significant when first employed, gradually becoming less important as one becomes more senior within the organisation. For instance, we have shown in Model 2, and this is supported by significant evidence (Wagner et al., 1985; Sternberg et al., 1995), that senior/more experienced people tend to score “higher” on a TK scale, while making less use of more formalised rule sets, algorithms or procedures (Polya, 1973, Michener, 1978, Soloway et al., 1982; Scriber, 1983 in Wagner et al., 1985). The medium - grey spiral represents TK, which is not entirely “non-existent” as the “apprentice” enters the workforce, however is likely to increase significantly over the years. In actual fact it is highly likely that the pattern is not likely to be a simplistic outward branching spiral, but rather a waveform like spiral that will continually oscillate with an individuals career. The light-grey “cone” represents the external interface with which an individual interacts with “knowledge” or


“people.” In other words, the overwhelming access to forms of knowledge stem from either AK, which is characteristically represented by written (i.e., electronic or non – electronic, in other words traditional) forms of information, and TK which is represented by expertise which over time becomes codified and is typically passed on in an “apprenticeship” situation. The inner “volume” of the cone represents the individual for whom AK and TK is “stored” over time, and able to be transferred to other individuals. The external surface of the cone represents contact with “reality” or the outside world, whatever that happens to be for the individual. The inward curving light-grey lines serve to indicate the relationship between TK and the size of an organisation. It has been noted (Caves et al., 1976 and Imai, 1980 in Hedlund, 1994), for example that Japanese firms are generally smaller than western ones and that this is likely to influence TK adoption, this in turn would seem to indicate that the smaller the firm, the more likely the firm is to make use of TK. Finally the inner ring’s represent work Nonaka (1991, 1996) and colleagues have undertaken into the association between TK and AK. In essence 4 stages have been identified: 1. Tacit knowledge to Tacit knowledge, Socialisation 2. Tacit knowledge to Explicit knowledge, Externalisation; 3. Explicit knowledge to Explicit knowledge, Combination 4. Explicit knowledge to Tacit knowledge, Internalisation (Nonaka et al., 1996 :835, italics added) It is argued however for the purposes of this paper that the cycle first mentioned by Nonaka (1991) may actually be taken further and that there is likely, it is thought by the authors, to be a difference in the extent to which any of the above 4 stages are likely to occur throughout an individuals working lifetime. For instance, it is anticipated that at a junior level there is likely to be a fairly even amount of each of the 4 stages being utilised. However the more senior/experienced/ older one becomes, it is hypothesised that a consequently greater amount of internalisation may be made use of.

DISCUSSION AK + TK → AK → AK + TK

So Hedlund (1994 :80) states in his paper dealing with knowledge conveyance in Japanese and Western organisations. Is the formula proposed by Hedlund (1994) likely to necessarily differ between the public and private sectors? For example, we argue that much of the information transfer that takes place between

126


individuals and departments in the public sector involves meetings, indeed the task of management typically encompasses up to 85% (including phone calls) of a working day being taken up in such activity (Olson, 1981 in Laudon & Laudon, 1998), does this then mean that what we have taking place particularly in the aforementioned sector is rather: AK + TK → TK (+ ak) → AK + TK

?

Insofar as much information is transmitted directly, person to person? The sole transmission of AK is essentially not possible. For example “ …..technology recipients in [this case] industrialising countries usually need more than just blue – prints, manuals, and patent rights or copyrights in order to assimilate and utilise effectively the technology being transferred. The transfer of tacit knowledge requires, almost by definition, face to face contact” (Arora, 1996 :235). Body language, facial expression, gender, age and ethnicity all play an active role in the tacit communication process. In other words, it is not what is said (AK), but who says it (status, gender, age, ethnicity), and how it is said (facial expression, body language, speech intonation (i.e., TK affected)).

CONCLUSION We may gather from examples presented in this paper, that the role of TK has been much underestimated in Western spheres as noted by Nonaka (1991; 1996), insofar as we have tended to have an “accountable” atmosphere within organisations which demand quantitative accounting in order to “measure” effectiveness. Nevertheless the significance of TK is extensive and as is now being realised more influential in knowledge management and information modelling circles than previously realised. What remains to be answered is how TK is best transferred from one individual to the next and by what means this is able to be achieved. Is information modelling an appropriate such tool?

REFERENCES Arora, A. (1996). Contracting for tacit knowledge: The provision of technical services in technology licensing contracts, Journal of Development Economics 50(2), August: 233-256. Goldman, G. (1990). The tacit dimension of clinical judgement, The Yale Journal of Biology and Medicine 63(1), January/February: 47-61. Greeno, J. (1987). Instructional representations based on research about understanding, in Cognitive science and mathematics education Schoenfeld, A., (Ed.), Hillsdale, NJ: Lawrence Erlbaum Associates: 61-88.


Hedlund, G. (1994). A model of knowledge management and the N – form corporation, Strategic management journal 15, Special Summer issue: 73-90. Horvath, J., Forsythe, G., Bullis, R., Sweeney, P., Williams, W., McNally, J., Wattendorf, J., and Sternberg, R. (1999). Experience, knowledge and military leadership, in Tacit knowledge in professional practice: Researcher and practitioner perspectives, Sternberg, R. and Horvath, J. (Eds.), Mahwah, NJ: Lawrence Erlbaum Associates: 39-57. Laudon, K., and Laudon, J. (1998). Information systems and the internet: A problem solving approach, Fort Worth: Dryden Press. Meerabeau, L. (1992). Tacit nursing knowledge: An untapped resource or a methodological headache? Journal of advanced nursing 17(1), January: 108112. Nonaka, I. (1991). The knowledge creating company, Harvard Business Review 69(6), November-December: 96-104. Nonaka, I., and Takeuchi, H. (1996). A theory of organisational knowledge creation, International Journal of Technology Management 11(7/8): 833845. Scott, D. (1990). Practice wisdom: The neglected source of practice research, Social work 35(6): 564-568. Senker, J. (1995). Networks and tacit knowledge in innovation, Economies et societes 29(9), September: 99-118. Stair, R., and Reynolds, G. (1998). Principles of information systems: A managerial approach, Cambridge, MA: International Thompson Publishing. Sternberg, R., Wagner, R., Williams, W., and Horvath, J. (1995). Testing common sense, American psychologist 50(11), November: 912-927. Takeuchi, H. (1998). Beyond knowledge management: Lessons from Japan, Monash Mt. Eliza Business Review 1(1): 21-29. Wagner, R., and Sternberg, R. (1985). Practical intelligence in real – world pursuits: The role of tacit knowledge, Journal of personality and social psychology 49(2), August: 436-458. Wagner, R., Sujan, H., Sujan, M., Rashotte, C., and Sternberg, R. (1999). Tacit knowledge in sales, in Tacit knowledge in professional practice: Researcher and practitioner perspectives, Sternberg, R. and Horvath, J. (Eds.), Mahwah, NJ: Lawrence Erlbaum Associates: 155-182.

128

• Modelling Business Rules Using Defeasible Logic

Chapter 12

Modelling Business Rules Using Defeasible Logic G. Antoniou University of Bremen, Germany M. Arief Griffith University, Australia

INTRODUCTION We can define business rules as statements that are used by a body or an organization to run their activities. Some of these rules are drafted by the body itself, others are rules that have been drafted by external body but it will have an effect on the organization. Some business rules are documented explicitly, others are used implicitly. Globalization of business and increased competition cause frequent changes in business rules. New rules are added, old rules are modified or retracted. For example, to compete with its rivals, a bank should adjust its interest rate, launch new services etc. In this situation that is very hard to keep the rules consistency, there is the chance that some rule violate the other. Dealing with conflicting business rules is an important aim of our work. In addition there are also situations where a manager should take a decision although not all relevant information is known. He/she must be able to draw conclusions even if the available evidence is insufficient to guarantee their correctness. Obviously, such conclusions are risky and may be invalidated in the light of new, more accurate information. This situation is referred to as reasoning with incomplete information. The aim of our work is to support the modelling, analysis and evolution of business rules using a formal language. Advantages of modeling business rules Previously Published in Challenges of Information Technology Management in the 21st Century, edited by Mehdi Khosrow-Pour, Copyright © 2000, Idea Group Publishing.

Antoniou & Arief • 129

include: (1) executable sets of business rules (or prototypes) become available; (2) maintainability; and (3) formal validation of desirable properties and discovery of errors. The foundation of our work is nonmonotonic reasoning which provides formal techniques for reasoning with conflicting and incomplete information. Some applications of nonmonotonic reasoning to regulations have already been reported (Morgenstern, 1997; Prakken, 1997; Ong & Lee, 1993). But so far the success has been rather limited, mainly due to computational limitations and lack of support for natural representation of business rules. In our work we have chosen to use defeasible logic (Nute, 1988), a nonmonotonic reasoning system based on rules and priorities. One of the main reasons for our choice of defeasible logic is its low computational complexity. We intend to implement a decision support system based on business rules to support decision makers. Aside from that, this intelligent system can help the policy modifier to find possible conflicts between rules if he tries to add new regulation or to modify existing regulations or business rules. This chapter is organized as follows. The next section describes problems we have identified with modeling regulations and business rules. The third section outlines defeasible logic. The fourth section explains advantages of defeasible logic in solving the problems outlined in the second section. Finally, the fifth section discusses current and future work.

ON THE FORMALIZATION OF BUSINESS RULES At this stage of our project, we have collected a comprehensive list of problems that are could be encountered when one tries to formalize business rules. These are (1) the problems in representing business rules into formal, precise and implementable language and (2) the problems in formalizing the conflict resolution mechanism or how to mimic people capability in taking decision. Representation Problem In the effort to formalize a rule system in the machine-readable form, the first step men should be to gather the knowledge and to analyze the rules. This step is very important, because we should expressed the knowledge explicitly in the form that can be understand by the system. Some problems have been identified in the effort to represent business rules are: • Vagueness • Open-ended / Incomplete List • Syntactic Complexity • Expressiveness / Naturalness of Expression • Reference Rules • Inheritance

130


Vagueness Vagueness refers to some terms that are not obviously defined. Every person can have different interpretation of these sentences, such as “have a satisfactory command of the English language,” “little formality and technicality” etc. Objective interpretation of the terms above will help us in designing a good program. In the case that that is not possible to get a clear interpretation about these terms, we should give attention to the capability of the logic to formalize the vagueness and to solve this problem. Or to use other methodology, for example by giving the possibility to the user to give decision what is the meaning of some term or adding fuzzy logic to the system. Open-ended list / Incomplete lists Problems in discovering what is the person that drafting the rules (the condition) actually intended. It can be happen if the policy maker avoid to define the rules completely into detail or because he expect that someone else will make the detail of it. Analyzing this rule and trying to declare it by writing extra rules will increase the number of rules in the formalization. Example: Trading (Allowable Hours) 1990: 26. In relation to making an order under section 21 the Industrial Commission must have regard to – …… (f) the alleviation of traffic congestion (g) such other matters as the Industrial Commission considers relevant. In this case, it is not apparent what “such other matters” mean, until we discuss it with people from the Industrial Commission. Syntactic Complexity Some rules are very complex and it is difficult for us to formalize the rules directly, in this case we should try to divide the rules into some pieces of rules without dismissing the whole implication. This step should be done carefully under supervision of an expert to prevent that we alter the meaning unconsciously. As a result of this step, the number of the rules will be increase substantially. Naturalness of expression/ Expressiveness One of the most important aspects in formalizing business rules is naturalness of expression, where it should be possible to represent the business rules and the commonsense knowledge in a transparent and natural way. If we can translate


these business rules into an application environment that is maintainable and connected to the rule structures, it will help rule developers to write the rules easily and for business analysts to read the rules and validate them. Reference Rules If the business rules refer to other rule (at the same level, different level or previously enacted rule), these referred rules should also be integrated in the system. The effect of this is that the system will expand more than original documented rule, sometimes the effect is to decide whether to alter the rules or not because the rule contradict the referred rules. The decision to which referred rules are relevant to the system, should be taken carefully, otherwise the system will become very big. Inheritance Some business rules have a taxonomic structure where the rules have inherit some properties from other rules. These types of rules discovered frequently. But usually in this case we analyze the rules as one product group not as separate rule. For example in banking industry, a bank has product such as: Account, Insurance etc. Each product has several “child” product, e.g., child of Account are National FlexiAccount, National FlexiDirect, National Tertiary Students Package Account. Every child inherits some common properties from Account. Conflict Resolution In this chapter we will discuss some conflict resolution has been detected to solve conflict between the rules. • Superiority a. Superiority from the same level b. Higher Level Regulations. • Posteriority • Specificity • Priority • Exception/Exclusion Superiority Superiority is a condition where one rule overrules the other. The reason are first because the first rule has been placed superior than the second rule although they are both produced by the same body, second because the winning rule is produced by a body that hierarchically higher than the second one.

132


a) Superiority from the same level. BCC Business and Procedure Act 1939: (1A) Nothing in this Act shall prejudice any provision of the city of Brisbane Financial Emergency Act 1939, but any provision of the City of Brisbane Act 1924, shall, so far as may be necessary to give full operation and effect to this Act, be read and construed subject to this Act. Brisbane Financial Emergency Act 1939 is superior to Business and Procedure Act 1939. And the City of Brisbane Act 1924 is superior to Business and Procedure Act 1939. We note that “the City of Brisbane Act 1924” is older than “BCC Business and Procedure Act 1939,” so posteriority is not applied in this case. Residential Tenancies Act 1997 (2) If a standard term of a residential tenancy agreement is inconsistent with a special term of the agreement, the standard term prevails and the special term is void to the extent of the inconsistency. Standard term is superior to special term, this is not specificity because the more general agreement overrule the more special agreement. b) Higher Level Regulations If there is a conflict between rules, rule that has been issued by higher body defeat rule that has been produced by lower body. Example: Residential Tenancies Act 1997 37.(1) If a provision of this Act is inconsistent with a term of a residential tenancy agreements, the provision prevails and the term is void to the extent of the inconsistency. This Act is superior to residential tenancy agreement. Posteriority Posteriority is another form of conflict resolution commonly use in business. It means that if there is a conflict between rules, the rule that has been commenced on the later date will be fire. Thus that is very important to include the commencement date in the system. For example, after commencement of Residential Tenancies Amendment Act 1999, the Residential Tenancies Amendment Act 1998 has become obsolete. Specificity More specific rules defeat a more general one; it means that a rule that covers more facts of the case defeats a general rule.


Example Trading (Allowable Hours) 1990 33.(1) An employee in a factory or shop must be given a holiday for the whole of Anzac Day. (2) However, subsection (1) does not apply to employment – (b) at a racing venue where a meeting is held under the Racing and Betting Act 1980; or… (2) is more specific than (1), in the case that we just have the fact that someone is an employee then she must be given a holiday on Anzac Day, but if later a new fact is added that she works at racing venue, then the conclusion is retracted. Priority In our daily live that is typical if we give preference for doing something. For example, if a building is hit by fire, who should be evacuate to save place first? First is children then old people then women and last are men. This priority is also can be observe in the business rule system, where some rules have higher priority than the other does. Example Residential Tenancies Act 1994 Where rent to be paid 48. (1) If the place for payment of rent is stated in an agreement, the tenant must pay the rent at the place stated (2) However, if, after signing the agreement, the lessor gives the tenant a written notice stating a place, or different place, as the place at which rent is required to be paid and the place is reasonable, the tenant must pay the rent at the place stated in the notice while the notice is in force. In this case, if both rule is fulfilled with other word that a place is stated in the agreement and then the lessor send a written notice consist of a new place then rule (2) has higher priority than rule (1). Exception/exclusion Exception means making the second rule an exception to the first and thus capable of defeating the first, more general rule. Also we can say that exception is a special form of specificity, the different between this two is that in specificity new predicate is added into condition but in the exception the predicates are exactly similar but it has exceptional situation. Example Trading (Allowable Hours) Act 1990 17.(2) The occupier of an independent retail shop, other than one used predominantly for the sale of food or groceries or both, is to cause the shop to be closed –

134


DEFEASIBLE LOGIC Defeasible logic is based on rules and priorities among rules. There are two kinds of rules: (1) strict rules which represent irrefutable truths, and (2) defeasible rules whose conclusions may be overturned by other rules. Simple examples of the latter are rules with exceptions, which are found in regulations and business rules quite often. Rules fire based on facts: statements/input about the case for which a decision needs to be made. A main feature of defeasible logic, that makes it non-monotonic, is its conflict resolution strategy: if two rules r and r’ can be applied but have contradictory conclusions, then none of them is applied, unless there is priority information declaring a rule stronger than the other. Most nonmonotonic logics have high computational complexity that makes them unsuitable for big, real-world applications. But defeasible logic has low complexity, therefore it can be implemented efficiently. In fact, in our group we have developed a powerful implementation (http://www.cit.gu.edu.au/~arock/defeasible/ Defeasible.cgi) which is capable of reasoning with sufficiently large rule sets (100,000s of defeasible rules).

WHY DEFEASIBLE LOGIC IS SUITABLE? We believe that defeasible logic is suitable and has the capabilities to solve most key problems. In the following, we briefly discuss advantages from both a system and a technical point of view. From a system point of view • Rule base: defeasible logic works based on the rule-based reasoning principle by separating the rule base from reasoning mechanism and other parts of the system. This is appropriate to represent business rules and provide a computational platform for their application. • Manageability: using defeasible logic, we can represent business rules in a natural way close to their description in natural language. By this representation we can translate the business rules into an application environment that is maintainable and connected to the rule structures. • Scalability: since defeasible logic works based on rules, scalability is not a serious problem. Developing an enterprise wide application from a prototype is easy, by adding new rules to the rule base. • Flexibility: the architecture of this system is very flexible, creating new applications becomes quick and easy by changing the business rule knowledge base. • Cost effectiveness: in the present situation where cost and easiness in developing a system is an important aspect, developing a rule-base system with non-


•

•

•

•

monotonic capability will cut off the development time and also the development cost. Knowledge elicitation: the knowledge elicitation problem is almost entirely absent in the formalization of business rule, because the business rules are usually well documented; their provision are written down, and where it is not, decisions in previous cases are already recorded for future reference. From a technical point of view Reasoning with incomplete information: human reasoning is non-monotonic. It means that people can make conclusions even though the available information is incomplete and the decision can be invalidated if there is new relevant information added. This behaviour is mirrored in the non-monotonic nature of defeasible logic: new evidence may change the set of conclusions/decisions supported. Naturalness of expression: the capability to express the business rules statement in a natural way is one of the most important requirements to guarantee the success of the system. Defeasible logic can represent business rules naturally in a way resembling their formulation in natural language.5 Conflict resolution: as the conflict resolution mechanism, superiority relation is very powerful. We can model the conflict resolution naturally using this facility. In posteriority, we can consider the rule that has been commenced on the later date superior than the other. So do in specificity, higher level hierarchy etc.

CONCLUSION This chapter describes the current situation of our research project in Griffith University. The aim of this project is to develop a reasoning assistant that will support the modelling, analysis, maintenance, and application of business rules and regulations. Until now our project delivered the following results: • We have made an initial study on university regulations with promising results (Antoniou, Billington & Maher, 1999). • Identifying the problems should be encountered in formalizing business result. • Designing the system as three-tier architecture plus the possibility to connect to the external corporate database. • We have developed a Web-based implementation of defeasible logic. In the next phase of the project, we will address the following points: • Consistencies check mechanism to be used in modifying business rules. • Adding necessary missing capabilities to defeasible logic, such as the capability for doing arithmetic calculation, the capability to describe information with inheritance characteristic etc. • Build a user-friendly reasoning assistant for regulations and business rules on top of the existing defeasible logic implementation.

136


• Study life cycle of regulations and business rules modeling. • Develop concrete application. Our initial case studies include university regulations, bank regulations, and marketing rules in an electronic commerce context.

REFERENCES Antoniou, G., Billington, D., & Maher, M.J. (1999). On the Analysis of Regulations Using Defeasible Rules, Proceedings of the 32nd Hawaii International Conference on Systems Sciences. Causey, R.L. (1994). EVID: A System for Interactive Defeasible Reasoning, Decision Support Systems 11, North Holland. Dhar, V., & Stein, R. (1997). Seven Methods for Transforming Corporate Data into Business Intelligence, Prentice Hall. Knowledge Partner, Inc. (1999). Business Rules Today: A KPI Position Paper. Morgenstern, L. (1997). Inheritance Comes of Age: Applying Nonmonotonic Techniques to Problems in Industry. Nute, D. (1988). Defeasible Reasoning and Decision Support Systems, Decision Support Systems 4, North Holland. Ong, K.L., & Lee, R.M. (1993). A Formal Model for Maintaining Consistency of Evolving Bureaucratic Policies: A Logical and Abductive Approach, EURIDIS Research Monograph. Prakken, H. (1997). Logical Tools for Modeling Legal Argument: A Study of Defeasible Reasoning in Law, Kluwer Academic Publisher. Prerau, D.S. (1990). Developing and Managing Expert Systems: Proven Techniques for Business and Industry, Addison-Wesley Publishing Co.

Jung, Kim, Lee, Wu & Kim • 137

Chapter 13

EE-Cat: Extended Electronic Catalog for Dynamic and Flexible Electronic Commerce Jihye Jung, Dongkyu Kim, Sang-goo Lee, Chisu Wu and Kapsoo Kim Seoul National University, Korea

Providing quick and easy access to electronic catalogs of products is one of the most essential parts in the electronic catalog environment. Proposed in this paper are data and query model for electronic catalogs which offer effective searching and management facilities to customize the electronic catalog system. The proposed model separates the management of product information and the visual presentation. Product information is represented as a graph. The model extends the range of electronic catalogs from product information to the whole web documents and their structure. The proposed query language makes the extended catalog more dynamic, flexible, and easy to maintain.

INTRODUCTION There are many different ways for consumers to buy products that they need, such as in-store shopping, mail orders, phone orders, etc. Nowadays, the newest and most notable purchasing method is through electronic commerce, in which goods or services are purchased over the Internet. The electronic commerce encompasses a broad range of interaction processes between market participants in various roles, including ordering, transport and delivery, invoicing and payment cycle, and customer services. The first stage Previously Published in Challenges of Information Technology Management in the 21st Century, edited by Mehdi Khosrow-Pour, Copyright © 2000, Idea Group Publishing.

138 • EE-Cat: Extended Electronic Catalog

of these interactions is gathering information about goods and services, called products (Schmid & Lindemann, 1998). This information is provided in the form of electronic catalogs. In such electronic shopping malls, customers cannot examine products directly but can only view the electronic catalog of the products. So it is important that the electronic catalogs contain sufficient information for customers to decide on their purchases. In addition, since there’s no salesclerk in electronic shopping malls, the shopping malls should provide easy and efficient searching methods for customers to access electronic catalogs of products that best match his or her requirements. To help users to find proper products, electronic shopping malls usually provide three methods of search - hierarchical search, keyword search, and field search. Hierarchical search is performed based on product hierarchies, and the others are based on the product descriptions and attributes. We have seen a considerable amount of research with remarkable progress concentrated on keyword search and field search to improve the processing speed and quality of results. But, as we are faced with exploding amounts of documents, the results of the field or keyword search are too numerous that we are seldom satisfied with their precision. We propose to improve this situation by combining the methods with hierarchical search which can narrow the search space with product hierarchies. Furthermore, as the product category names can give some clues of the search, hierarchical search is the most effective way when users are not exactly sure what they want. So, it is important to maintain a good product hierarchy and be able to easily adapt to changes. In addition, as the product hierarchy can be the skeleton of the web site of the shopping mall, the site management and customization efforts can be facilitated if the product hierarchy is dynamic and flexible. We propose an electronic catalog model and a product hierarchy model that are sufficiently expressive and, at the same time, flexible, and easy to modify. One of the biggest part of the startup cost of internet malls is building electronic catalogs. As multiple sites carry the same product, it makes sense to share some of the burden by use of a shared repository of electronic catalogs for Internet malls to reduce the cost of building electronic catalogs (Lee, Wu, Kim, Kim & Shin, 1998). With the shared repository, the manufacturer will upload the core catalogs that include the basic information about her products, and the shop can download these core catalogs and well defined product hierarchies of the shared repository. The shared repository may have electronic catalogs for a wide range of products and product hierarchies covering them, while individual shops need only subsets of them. So it is essential that there is a method to get a subset of electronic catalogs with a focused view of the product hierarchies. If we combine the electronic catalogs and product hierarchy and treat it as a searchable object,


the customization can be done in more simple and systematic way. So we extend the range of electronic catalogs from information of products to combination of information and product hierarchies, and define a query language on the extended electronic catalogs, which we named EE-Cat. The query language makes the extended catalog more dynamic, flexible, and easy to maintain. In the next section, we propose an electronic catalog model describing product information. In the third section, the product hierarchy and the extended catalog are presented. And, in the fourth section, we define four types of queries on the extended catalog. The fifth section shows our Digital Catalog Library system that implements the proposed model, and the sixth section shows related works. Finally, we conclude our chapter in the last section.

MODELING CONTENT OF ELECTRONIC CATALOGS To explain one product on Internet, we need a main page to describe the important characteristics and some linked pages for big images or detailed information of the essential and distinguishable functionality. So, an electronic catalog is a set of web documents containing data describing a product. Since an electronic catalog is a set of web documents, we can use some web technologies to model electronic catalogs. But the proposed model separates the content and presentation information and defines the content by itself, because the content has a normalized structure and it can be shared among multiple catalogs. The content of an electronic catalog is information pertaining to the product itself. Some of this information is attribute based and some are less structured like images and free texts – all of them are called attributes. And users need different kinds of information for different kinds of products. For example, users want to know the size and the color for a skirt, but they want to know the power consumption and the capacity for a refrigerator. Therefore, we have been grouped products that share common sets of attributes and have same characteristics into a product family, such as TV, refrigerator, skirts, etc. Although different product families have different attributes, there are some attributes that are common to all product families, such as product name, brand name, model number, supplier, etc. Hence, we have classified the attributes into two groups, core attributes and product dependent attributes. The core attributes includes Dublin core and commerce core that are suggested for the catalog interoperability in PIX (1998). To facilitate comparisons between products across different views, the proposed model categorizes products by dimensions, such as time, places, occasions, type of users, and product families, similar with dimensional analysis in Data Warehousing. The dimensions are additional information, but very essential to


Figure 1: Relationship between attributes P ro duc t F am ily

T im e C or e A ttribu tes P lac e

U se r P rod -D ep. A ttribu tes

O c casion P rod uct

Figure 2: A sample electronic catalog graph

dim ension core

co m m erce co re

du b lin co re

pro duct depend ent H ard -disk C PU M em ory

ho m e

title creator

price m an ufactu rer m an ufactu rer

M agic -statio n 1 01

sam sun g

sam su ng

p lace

user

adults

capacity 6 4M

compare products. So, the dimension information is most frequently used to build the product hierarchy and most frequently accessed in the searching process. Figure 1 shows the relationship among core attributes, product dependent attributes, and dimensions. Now, an electronic catalog can be defined as a set of attribute-value pairs, which is normal approach to describe the content of electronic catalogs – Internet Commerce Server, LiveCommerce, etc are using this approach. But it is not so powerful to describe compound products composed of other products. For example, the catalog for a personal computer must include the information of motherboard, memory, CPU, Hard-disk drives, etc, and the information of each component has its own attributes. In addition, some attributes are composite attributes, such as the size of a refrigerator consisting of width, depth, and height. We propose to improve this situation by viewing the content of an electronic catalog as a directed graph, a variation of the semi-structured data model


(Papakonstantinou, Garcia-Molina & Widom, 1995). Figure 2 shows a sample electronic catalog graph for a personal computer. The graph’s edges are labeled with attribute names and leaves are labeled with values. Since the graph has a structure itself, we can describe structured information easily. When the catalog is presented in Web, it is shown as a set of web pages connected with links. For example, the catalog in Figure 2 can be shown as a root page containing core information and linked pages containing information of its components. And, it is done with specifying presentation information. The structure of the catalog graph is exactly same as that of the XML-graph (1998), so the content of catalogs can be described using XML format and the presentation information of catalogs can be described using XSL format.

EXTENDING THE ELECTRONIC CATALOG The most common search types are product hierarchy based, keyword based, and field-value searches in shopping malls. In order to provide hierarchical search, we need to construct a product hierarchy. The product hierarchy is also used in managing the products in inventory as well as the catalogs in the database. In the proposed model, the product hierarchy is supported by the categorization, and the nodes of the product hierarchy are called categories. First of all, the hierarchy of categories and its operations will be explained. And then, we will define the EECat, the extended electronic catalog model, which is an extension of electronic catalogs from information of products to combination of information and product hierarchies for more systematic management and customization. The Product Hierarchy A category is a set of products that share a common property. Products can belong to several different categories, and categories may contain other categories, all of which can be arranged in multiple hierarchies. The multiple hierarchies allow the users to search for products in several different ways. For example, to find athletic shoes, the user can drill down first from manufacturer, then purpose of shoes, then size a) Nike/Reebok Æ jogging/Tennis Æ 10/11/12 or first for size, then purpose of shoes, then manufacturer b) 10/11/12 Æ jogging/Tennis Æ Nike/Reebok Since products and categories are arranged in multiple hierarchies, the hierarchies are represented as a DAG that the nodes are categories and edges are the relationships between categories. There are two kinds of relationships between categories. The first type is a relationship between a category and its subcategory that is called the hierarchical relationship. And the second one is a relationship that can be used to link any two categories that is called the related-to relationship.


Related-to relationships are used to represent relationships such as matching products, similar products, and cheaper brand. To specify the relationship among products and categories, two common approaches are used in commercial products. The first one is that a category has pointers to its products, and the second one is that a product has a category or a set of categories that it belongs. They are simple, but hard to modify the product hierarchy and insert/delete product because we must specify all links among products and categories. Instead of pointers, the proposed model uses rules to specify the relationship. There are many criteria to categorize products, such as size, manufacturer, type of users, time, etc. And each product is categorized to some categories by the values of attributes corresponding to the criterion. Therefore, the common property shared by products in the same category can be represented as a combination of condition, which is called a rule, over the attributes of the products. For example, the rule of the category, Nike tennis shoes, is represented as Product_Family(p1) = “Athletic Shoes” AND Manufacturer(p1) = “Nike” AND Purpose(p1) = “Tennis”• p1 belongs to Nike tennis shoes. As a result, a product doesn’t need to have the information about categories that it is included in. Instead, the category has the condition of products that it includes. It makes the hierarchies more flexible and the modification of the hierarchies easier. We build the hierarchies as following. The product families, such as “Formal dress,” “Rice cooker,” and “Gas fittings” are the base categories, and we make a super category by merging base categories or merged categories, and then, make sub categories of each category by specifying dimensions or the condition of attributes if needed. The rule of a category is generated automatically during this process. Eight groups of operations have been defined for the process; create category, delete category, modify category, define subcategory, generalize categories, merge categories, add/delete related-to edge and copy/paste part/all of graph. The EE-Cat Generally, the contents of electronic catalogs and product hierarchies are managed independently, and the hierarchies are not target of search. But, when we share product hierarchies and electronic catalogs with repository, we need to get a subset of them and integrate the subset with ours. If we combine the electronic catalogs and product hierarchy and treat it as a searchable object, the process will be done simply and more systematically. And there are web documents corresponding to categories that are called category catalogs, and we can also share the category catalogs with repository by the combination. Therefore, we extend the range of electronic catalogs to whole web documents and their structure corresponding to the product hierarchies, which is called the EE-Cat.


Figure 3: Sample EE-Cat H ierarch ical

A ll

A pp arel M en ’s

W om en ’s

F o rm al dress fo r m en

F o rm a l dress

R e late d -to

H om e A p p lian ce S m all ap plian ce

K itch en u te nsils

F o rm a l d ress R ice fo r w o m en co ok er

K itch en/ H o m e fashio n In terio r

G as fitting s ca teg ory pro du ct

M on ac o M 32

C C c lu b M 10 1

The EE-Cat is described as a directed graph whose nodes are electronic catalogs for categories or products and whose edges are the relationships between catalogs. And the nodes are defined as a tuple of (ID, Condition, Content). The condition represents the rule of category if the node is the category catalog, otherwise the content of the product catalog makes the implicit condition. Figure 3 shows a sample EE-Cat. Definition 3.1 An Extended Catalog is a Directed Acyclic Graph G = (CV, HE, RE) CV is a set of Catalog vertices s.t. CV = {cvi | cvi Product Catalog vertices ¦ cvi Category Catalog vertices} And cvi = (ID, Condition, Content) HE is a set of hierarchical relationship edges s.t. HE = { hek | hek = (cvi, cvj), s.t. cvi CV, cvj CV, Condition(cvi) is necessary condition of Condition(cvj)} RE is a set of related-to relationship edges s.t. RE = { rek | rek = (cvi, cvj), s.t. cvi CV, cvj CV, cvi is a related category of cvj }

THE EE-CAT QUERY LANGUAGE Now we define the EE-Cat Query Language on EE-Cat. The EE-Cat Query Language is a SQL-like query language and it uses some syntax of XML-QL (1998). A first task we consider is that of formulating queries for retrieving certain electronic catalogs that are based on the content of the desired electronic catalogs. To describe the compound products and composite attributes, the model in the second section views the content of an electronic catalog as a directed graph. Although the directed graph is effective to describe the structured information, it is


difficult for users to query on them. So, the external functions for the field-value search are defined, such as brand(c1), manufacturer(c1), product_family(c1), name(c1), etc – c1 is an electronic catalog. When we want to find all electronic catalogs for “Personal Computer” made of “Samsung,” we can obtain this information using the following query: Select Catalogs p From p in all_catalogs(E1) Where manufacturer(p) =“Samsung” AND product_family(p) = “Personal Computer” In this query, E1 is an EE-Cat, all_catalogs means search for all CV of E1, and manufacturer and product_family are external functions. And the external functions are defined as follows: define product_family for all as select $a where content_as $a And, also, queries to get a view or a sub-graph of the EE-Cat based on the user’s request are needed. The first type is to get a sub graph of the EE-Cat starting from a specified node. The sub graph consists of nodes that have at least one path composed of only hierarchical links from the specified node, and edges whose sources and targets are the nodes in the sub graph. For example, the Figure 4 (a) shows the sub graph starting from the “Apparel” node. If ID(Apparel) is 101, we can get the sub graph using the following query: Select Subgraph E2 From Graph E1 Figure 4: Getting a sub-graph or view

Apparel M en’s W om en’s Fo rm al d ress for men

F ormal dress

Housekeeping

Hom e Appliance

K itchen Form al dress Sm all for women appliance utensils

M onaco M 32 CC clu b M 101

(a) A sub graph of F igure 3

Rice cook er

K itchen/ H om e fashion Interior

Gas fittings

(b) Catalog about housekeeping


Figure 5: Consistency P

Q

consistent

P

Q

consistent

Q

P

consistent

P

Q

Not consistent

Start 101 The second one is queries to get a view of the extended catalog. For example, the Figure 4 (b) shows a view of the EE-Cat that is related with house keeping. The following query makes the view about house keeping: Select Subgraph E3 From Graph E1 Consistent place = “House” The condition to get a view is used to check the consistency between the condition of nodes. We consider that a condition q is not consistent with the condition p of nodes only when the set of products satisfying the condition q and the set of products belonging to the category are exclusive. This kind of queries is possible only in our model because we use rules to specify the relationship among categories and products. And the integration of the sub-graph with the existing EE-Cat is done as follows: Insert Graph E3 below E1(1) The above query inserts the sub-graph E3 as a child of the node of E1 whose ID is 1. Finally, queries to extract information from each electronic catalog and reconstruct it are needed. The following query extracts the title and memory information from electronic catalogs of personal computers whose memory capacity is more than 64M and then, restructures the extracted information. Select $t, $m From p in product_catalogs(E1) Where Element_As $t < product dependent> <memory> $c Element_As $m


Figure 6: DCL system architecture Catalog Browser/Editor Client SDK

Other Client A pplications

Other Client A pplications

CORBA interface

CORBA interface

Catalog Exchange Protocol

CORBA DCL Server

Category Manager

ODBC

IN p, $c > 64M and product_family(p) = “Personal Computer” Construct $t $m Extracting and restructuring information can be used to build the content of a category catalog that contains subset of its typical product or best-seller information. And it will reduce the duplicated costs to manage the same information.

DIGITAL CATALOG LIBRARY1 In January of 1998, we have launched a two year project to build a digital catalog library (DCL) (Lee et al., 1998) jointly with Daehong Communications, Inc.2 , and CommerceNet Korea3 . The primary objective of the system is to provide a shared repository of digital product catalogs for Internet shops to reduce the cost of catalog management. And it will greatly reduce the catalog building cost for the shops and streamline the manufacturer’s efforts to distribute new and updated product information. As a side benefit, the DCL can be a valuable source of information about products and companies. We already implemented a first prototype of the DCL that is supporting the feature of the EE-Cat data model and query language partially. The content model of the first prototype is supporting three groups of attributes, which are core attributes, product dependent attributes, and dimensions, but it defines an electronic catalog as a set of attribute-value pairs instead of a directed graph. And it provides all functionalities of product hierarchies with the category manager in Figure 6. Moreover we can retrieve certain electronic catalogs and get a sub graph or a view of the EE-Cat with the DCL server in Figure 6. The DCL server communicates with its clients through CORBA interfaces.


We provide a default client tool (in Windows 95) for electronic catalog browsing and editing. Also, provided is a C++ library as a client SDK (software development kit) for customized client application development. The user also has the option to access the server functions directly through CORBA IDL. The client/ server interactions are defined in the Catalog Exchange Protocol (CEP). The server is built on a UNIX platform (Solaris 2.6) with an Oracle 8.0 DBMS. Currently we are implementing a second version of the DCL that will support all features of the EE-Cat data model and query language. And it will be put to practical use in 2000.

RELATED WORKS There exist many web data models, such as WebSQL (Mendelzon, Mihaila & Milo, 1996), YAT (Cluet, Deloble, Simeon & Smaga, 1998), WebDB (Li, Shim, Candan & Hara, 1998), WebOQL (Arocena & Mendelzon, 1998), StruQL (Fernandez, Florescu, Kang & Levy, 1998), Ulixes and Peneloper (Atzeni, Mecca & Merialdo, 1997), etc., to manage and query web information. These models view the web as a directed graph whose nodes are web pages and whose edges are the links between pages. And the queries can be based on the content of the desired pages and on the link structure connecting the pages. In addition, they suggest methods to retrieve specific web pages, to extract and integrate information from web pages, and to construct and restructure the web site. These models are used to search or integrate existing web documents, and the proposed model is used to manage, search and construct electronic catalogs. So our model and query language include all the benefits of web data models and have additional functionalities such as getting a view of the EE-Cat based on the rules. And there are catalog systems, such as the catalog clearing house (Royappa, 1999), and some commercial products, such as ICS, LiveCommerce, etc. These systems also have data models and query models, but the data model doesn’t support complex objects, and the query model doesn’t support extracting information and getting a view because they does not treat the whole hierarchy as a searchable object.

CONCLUSION The proposed model define three groups of attributes - core attributes, product dependent attributes, and dimensions - for the content of electronic catalogs. And it views the content of an electronic catalog as a directed graph. Furthermore, it defines categories with rules, relationships between categories, and operations to modify the product hierarchies. And it extend the range of electronic catalogs form a product to the whole search paths for the hierarchical search, which is


called EE-Cat. The extension enables the users or shop managers to treat the whole catalog structure as an object, so that the customization and management of the catalog structure can be done in more simple, flexible, and systematic way. The EE-Cat query language makes the EE-Cat as a searchable object. It retrieves certain electronic catalogs that are based on the content of the desired electronic catalogs. And it gets a sub graph starting from a specified node or a view of the EE-Cat with the condition describing the user’s need, then integrates the sub graph with existing EE-Cat. Furthermore, it extracts and restructures information from the retrieved catalogs. The query language is very useful for users or shop managers to build the customized EE-Cat. Compared with the systems reviewed in the sixth section, the EE-Cat is more suitable and powerful to manage the catalog systems, and it is dynamic and flexible to adopt the change of requirements on catalog systems.

REFERENCES Arocena, G. O., and Mendelzon, A. O. (1998). WebOQL: Restructuring Documents, Databases and Webs, Int. Conf. on Database Engineering. Atzeni, P., Mecca, G., and Merialdo, P. (1997). To Weave the Web, VLDB 97. Barta, A. (1998). WebCat: Information Integration for Web Catalogs, Master Thesis, Computer Science Department University of Toronto. Catalog interoperability study, CommerceNet research report 27-Feb-1998, available via NK “http://www.commerce.net/research/pw/bulletin/98_05_r/ 98_05_r.pdhttp://www.commerce.net/research/pw/bulletin/98_05_r/ 98_05_r.pdf. Cluet, S., Deloble, C., Simeon, J. and Smaga, K. (1998). Your Mediator Need Data Conversion! SIGMOD 98. Fernandez, M., Florescu, D., Kang, J., and Levy, A. (1998). Catching the Boat with Strudel: Experiences with a Web-Site Management System, SIGMOD 98. Internet Commerce Server User’s Guide, available via http://technet.oracle.com/ doc/ics.11/ics11_ug.pdf. Lee, S., Wu, C., Kim, K., Kim, D., and Shin, W. (1998). Digital Catalog Library: A Shared Repository of Online Catalogs for Electronic Commerce, WECWIS 98. Li, W.-S., Shim, J., Candan, K. S., and Hara, U. (1998). WebDB: A Web Query System and its Modeling, Languages, and Implementation, Proc. of the Advances in Digital Libraries Conference. Mendelzon, A. O., Mihaila, G. A., and Milo, T. (1996). Querying the World Wide Web, First Int. Conf. On Parallel and Distributed Information Systems.


Open Market, “LiveCommerce Technical Architecture”, Open Market Technical White Paper, available via http://www.openmarket.com. Papakonstantinou, U., Garcia-Molina, H., and Widom, J. (1995). Object Exchange Across Heterogeneous Information Sources, Int. Conf. on Database Engineering. Royappa, A. V. (1999). Implementing Catalog Clearinghouses with XML and XSL, Proceedings of the 1999 ACM symposium on Applied computing. Schmid, B. F., and Lindemann, M. A. (1998). Elements of a Reference Model for Electronic Markets, Proceedings of the 31st Annual Hawaii International Conference on Systems Science HICCS’98, Vol. IV, Hawaii, January 6-9. XML-QL: A Query Language for XML, Submission to the W3C 19-August1998, available via http://www.w3.org/TR/NOTE-xml-ql/.

ENDNOTES 1

2

3

This work has been supported by the Ministry of Information & Communications, Korea, under research grant number A2-98-106-00. Daehong Communications, Inc., is the operator of the largest (in terms of revenue) Internet shop in Korea. CommerceNet Korea is the Korean Chapter of the CommerceNet Global Partners.

150

• Enforcing Modeling Guidelines in an ORDBMS-based UML-Repository

Chapter 14

Enforcing Modeling Guidelines in an ORDBMS-based UML-Repository N. Ritter and H.-P. Steiert University of Kaiserslautern, Germany Due to its rich set of modeling concepts and its broad application spectrum the Unified Modeling Language (UML) has become widely accepted for modeling many aspects of software systems. Since UML is not related to any particular design method, each software development project has to establish its own modeling guidelines. Hence, tool support is needed for guiding the developer throughout the modeling process and for enforcing project-related integrity of UML models. In this chapter, we present our approach for enforcing guidelines in UML-based software development processes. For managing UML models, we implemented a UML repository on top of an object-relational database management system (ORDBMS). Guidelines are expressed as OCL constraints and are enforced either automatically, i. e., by the UML repository, or on user demand. For this purpose, we take advantage of ORDBMS query facilities for checking guidelines by automated mapping of OCL constraints to SQL expressions.

INTRODUCTION In our SENSOR project (Subproject A3 Supporting Software Engineering Processes by Object-Relational Database Technology of the Sonderforschungsbereich 501 Development of Large Systems by Generic Methods funded by the German Science Foundation) we consider new object-relational database technology for software systems which have to support data manPreviously Published in Challenges of Information Technology Management in the 21st Century, edited by Mehdi Khosrow-Pour, Copyright © 2000, Idea Group Publishing.

Ritter & Steiert • 151

agement tasks in software engineering projects. In detail we aim at two goals. First, we are developing a shared UML repository (UML, Unified Modeling Language, (OMG, 1997a, 1997b; UML Specification)) based on an object-relational database management system (ORDBMS) (Stonebraker & Brown, 1999) in order to support cooperation of developers and reuse of design. Second, we want to generate database schemas and object-oriented database application programming interfaces (API) for engineering applications from a graphically specified UML model. This paper deals with some important aspects of our UML repository: exploiting OCL constraints for preserving consistency of UML models and for enforcing guidelines during the modeling process. UML is becoming a de-facto standard for object-oriented modeling. The Object Management Group (OMG) has adopted the UML into its Object Management Architecture (OMA). Furthermore, UML has become broadly supported by the vendors of graphical modeling tools. In comparison to other information models, e.g., the Entity-Relationship-model (Chen, 1976), UML has lots of advantages. It is object-oriented and object-orientation has become the leading software development technology. Also, UML offers a large set of structural modeling elements including class structures and several options to define the semantics of relationships. In addition, it comes along with modeling elements for describing the behaviour of a system and for state-oriented aspects. The OCL (Object Constraint Language, (OMG, 1997c; Warner & Kleppe, 1999)) enables developers to specify constraints in a descriptive manner. Unfortunately, OCL is only weakly represented in many descriptions of UML (Linington, 1999). In this chapter, we will focus on the use of OCL for our purposes. Our implementation of a UML repository is based on the UML meta-model and is implemented by exploiting an ORDBMS. The enhanced type system, the powerful SQL facilities and the extensibility features of ORDBMSs have proven to be very helpful for our purposes, because we were able to overcome some limitations of relational database management systems (Demuth & Hussmann, 1999). The implementation of the UML repository, i.e., the mapping of the UML metamodel to an object-relational database schema, is described in the next section. In this section, we also outline how OCL constraints can be mapped to SQL constraints. The usage of OCL in our project is not limited to global integrity constraints. We also exploit OCL for enforcing project-related design guidelines. A short classification of guidelines with examples and their implementation as SQL constraints is given in the third section. The sample constraints illustrated in the second and third sections are manually mapped from OCL to SQL. In order to provide adequate tool support for our approach we developed an OCL-to-SQL compiler for automatic mapping of OCL constraints to SQL. This compiler is outlined in the fourth section. The final section concludes the chapter.

152


THE UML REPOSITORY As mentioned before, one of our research goals is to find out whether or not ORDBMSs provide adequate mechanisms for managing engineering data. As a sample application we are developing a UML repository based on an ORDBMS. Managing UML models designed as part of the software development process within a UML repository has several advantages. First, a shared database eases cooperation of developers involved in the development process. Second, the repository serves as a basis for the reuse of design decisions documented as UML models. Third, higher software quality can be achieved by analyzing UML models. This way design errors can be detected early and design guidelines can be enforced. Query facilities provided by ORDBMSs seem to be helpful for this (analyzing) task. Fourth, UML models can be used to generate database schemas and APIs (Mahnke, Ritter & Steiert, 1998). In OMG (1997b), UML itself is used to describe the UML meta-model. Since the graphical modeling elements are not powerful enough to completely determine the semantics of UML, additional invariants are used. These invariants are expressed in OCL, which is a descriptive object-oriented constraint language. A textual comment in a natural language completes the specification of UML in OMG (1997b). Our UML repository is based on the UML meta-model (OMG, 1997b) and is implemented by exploiting an ORDBMS (Stonebraker et al., 1999). We have mapped the UML meta-model to an object-relational database schema. In order to enforce data integrity in the UML repository we have implemented the invariants as SQL constraints. The powerful SQL facilities and the extensibility features of ORDBMS have proven to be very helpful for these purposes. The current implementation only supports manipulating UML models via the SQL interface, but we intend to additionally provide an API which is compliant to the UML CORBAfacility Interface Definition (OMG, 1997d). Mapping the Meta-Model Due to space restrictions, we cannot describe the features of ORDBMS in detail in this chapter. Nethertheless, a short introduction into the object-relational data model and the extensibility features of ORDBMSs is essential for a deeper understanding. Stonebraker et al. (1999) reclaims an ORDBMS to provide at least user-defined types (UDT), user-defined routines (UDR), a rule system and inheritance hierarchies for types and tables. The implementation of our UML repository exploits all these features. Figure 1 shows a simplified excerpt of the UML meta-model, which will serve us as an example for demonstrating the principles of our approach (throughout this chapter we use the SQL dialect of the ORDBMS “Informix Dynamic


Figure 1: UML class diagram: ‘Generalization Hierarchy’ ModelElement

+subtype

+generalization

1..1

*

GeneralizableElement

Generalization 1..1

+supertype

* +specialization

Server”). Instances of the class “GeneralizableElement” represent modeling elements which are able to participate in generalization relationships. The relationships themselves are represented by instances of the class “Generalization.” In the following we outline how these structures can be mapped to an object-relational database schema. In a first step, each class of the UML meta-model is mapped to a userdefined type. We exploit the type hierarchies provided by the ORDBMS in order to implement the inheritance relationships in the UML model. This results in the following ROW TYPEs: CREATE ROW TYPE model_element_ty ( id oid_ty, name name_ty ); CREATE ROW TYPE generalizable_element_ty ( is_root BOOLEAN, is_leaf BOOLEAN, is_abstract BOOLEAN ) UNDER model_element_ty; CREATE ROW TYPE generalization_ty ( discriminator name_ty, subtype oid_ty, supertype oid_ty ) UNDER model_element_ty;

Each ROW TYPE has an additional attribute “id,” which does not stem from the UML meta-model. Values of this attribute uniquely identify instances in the database. Its type, “oid_ty,” is not a build-in type, but a user-defined OPAQUE TYPE. In contrast to ROW TYPEs, the internal representation of an OPAQUE TYPE is hidden. A value of this type is not only unique in the database, it also contains additional information. User defined functions provide access to the name of the table used for storing the instance and the name of the type “oid_ty.” Although references are included in the standard SQL:1999 (ISO Final Committee Draft, 1999), the commercial ORDBMS used does not support references. Hence, the relationships between the classes are implemented by foreign keys, i.e., the attributes “subtype” and “supertype” of “generalization_ty.”

154


In an ORDBMS an instance of a ROW TYPE can not live for itself. It has to be stored in a table. Therefore, each ROW TYPE is associated with a corresponding database table. ORDBMSs also support inheritance relationships among tables. Hence, the type hierarchy is reflected by the following table hierarchy: CREATE TABLE model_element_ta OF TYPE model_element_ty ( PRIMARY KEY( id ) ); CREATE TABLE generalizable_element_ta OF TYPE generalizable_element_ty ( PRIMARY KEY( id ) ) UNDER model_element_ta; CREATE TABLE generalization_ta OF TYPE generalization_ty ( PRIMARY KEY ( id ), FOREIGN KEY ( subtype ) REFERENCES generalizable_element_ta ( id ), FOREIGN KEY ( supertype ) REFERENCES generalizable_element_ta ( id ) ) UNDER model_element_ta;

The attribute “id” is used as a primary key. In order to assign a correct value to this attribute for each row, we exploit the rule system of the ORDBMS. If a new instance is inserted or an existing instance is modified, then a trigger is executed. This trigger assigns a new identifier to attribute “id” if its value is NULL, otherwise it checks whether or not the value is correct. Additionally, the foreign key constraints enforce referential integrity. Mapping the Invariants In addition, the OCL (OMG, 1997c) invariants defined in the UML metamodel are mapped to SQL constraints (more precisely, we map OCL constraints to SQL predicates, which can be used in SQL constraints, triggers, and WHERE clauses). Hence, we preserve the consistency of UML models managed by the repository. In the following, the mapping of OCL constraints is demonstrated by two examples. In OMG (1997b), an OCL constraint is given defining the semantics of the attribute “isRoot” of class “GeneralizableElement.” If the value of this attribute is “true” for any instance of “GeneralizableElement,” the instance must not have any relationship to an instance of “GeneralizableElement” in role “generalization.” These semantics is precisely represented by the following OCL constraint: context GeneralizableElement inv: self.isRoot implies self.generalization->isEmpty; Using an ORDBMS for storing UML models enables us to exploit its query facilities for the evaluation of OCL constraints. The OCL constraint above results in the following SQL check-constraint: CHECK NOT EXISTS ( SELECT * FROM generalizable_element_ta AS t1 WHERE NOT ( 0 = ( SELECT count(*) FROM generalization_ta AS t2 WHERE t1.id = t2.subtype ) ) );


Unfortunately, not all constraints are as simple as this one. Often, OCL constraints include complex computations. For example, the operation “allSupertypes” of class “GeneralizableElement” computes the transitive closure of all supertypes of a given instance of “GeneralizableElement.” In order to map the following OCL constraint to an SQL constraint, it is required to previously map the operation “allSupertypes” to a UDR. context GeneralizableElement inv: not self.allSupertypes->includes(self);

The UDR “allSupertypes” (signature see below) can be implemented either in Java, C, or a proprietary stored-procedure language and registered in the database. CREATE PROCEDURE all_supertypes ( generalizable_element ge ) RETURNING SET( generalizable_element_ty NOT NULL );

In order to map the previous OCL constraint given above ‘all_supertypes’ can be used as follows: CHECK NOT EXISTS ( SELECT * FROM generalizable_element_ta AS t1 WHERE NOT ( t1 IN all_supertypes( t1 ) );

The discussions of this section clarify that in order to capture the semantics of the UML meta-model completely, OCL constraints can be mapped to SQL. In the following sections, we will see that these mapping mechanisms can also be used to exploit the UML repository for other purposes further supporting the modeling process with UML.

ENFORCING DESIGN GUIDELINES In the previous section, we outlined how we map the well-formedness rules to SQL. Now we want to detail this discussion by considering the objectives OCL can contribute to achieve. Exploitation of constraints in the UML repository is not limited to enforcing the class invariants specified in OMG (1997b). Furthermore, constraints are a helpful support for guiding developers through the process of modeling (Ritter, 1997). We intend to exploit OCL constraints for the following purposes: • Design Guidelines Design guidelines are additional constraints on UML models. Hence, the repository enforces that only valid UML models are stored, i.e., UML models which fulfil both, the invariants and the guidelines. We distinguish two kinds of design guidelines: Global Design Guidelines Global design guidelines hold throughout the entire process of modeling. In contrast to the invariants specified in OMG (1997b), they are strongly related to a

156


particular project. As an example, assume that your team is using Java which does not support multiple inheritance. Thus, a global design guideline is supposed to control those UML models which, mapped to Java, do not exploit multiple inheritance. Such a guideline is strongly related to Java projects. It may be directly expressed as an OCL constraint, restricting the number of superclasses for each specified class to at most one: context: GeneralizableElement inv: self.generalization->size = ( SELECT count(*) FROM generalization_ta g WHERE ge.id = g.subtype ) ) )

Temporary Design Guidelines The use of global design guidelines may be too restrictive in some cases. Often, in early modeling phases the guidelines should be less restrictive than in the later phases. For example, object-oriented programming languages (OOPL) like Java and Smalltalk do not directly support n-ary associations, because relationships are expressed through references or collections of references. Usually, such associations are implemented by an additional class connecting the associated classes. In early analysis phases, such n-ary associations may be helpful. In later phases of the development process, however, it is more reasonable to have classes allowing a straight implementation. The following constraint can be added to the invariants and design guidelines if avoidance of any n-ary associations is wanted: context Association inv: self.connection->size = 2

This constraint restricts the number of instances of ‘AssociationEnd’ being connected to one instance of “Association” to exactly two. In the UML repository it may be implemented by a check constraint: CHECK NOT EXISTS ( SELECT * FROM association_ta a WHERE NOT( 2 = ( SELECT count(*) FROM association_end_ta ae WHERE ae.association = a.id

)))

• Process-related Design Rules While design guidelines are strongly related to the UML models stored in the UML repository, process-related design rules are used to control the modeling process itself. We intend to exploit OCL for design rules in the following ways:


Pre- & Postconditions These rules are related to operations. Preconditions describe the states of a system, in which the execution of an operation is allowed. By the same token, postconditions describe correct states after execution. OCL supports pre- and postconditions for operations. Unfortunately, it is not possible to refer to the before-state of any operation in an SQL constraint. Beside this restriction checking pre- and postconditions in the repository is similar to checking guidelines. Preconditions may involve the parameters of the operation and postconditions may involve the result. This is reflected in the SQL constraints by parameters. A sample mapping is given below. context GeneralizableElement::remove_generalization( Generalization gen ) pre: self->generalization->includes( gen ) CHECK NOT EXISTS ( SELECT * FROM generalizable_element_ta AS ge WHERE ?gen IN ( SELECT subtype FROM generalization_ta AS g WHERE g.subtype = ?id) )

This precondition is associated with the operation “Generalizable Element::remove_generalization” which removes an generalization relationship for a given instance of class “GeneralizableElement.” It checks whether or not the relationship exists. The term “?id” in the SQL statement is a variable which needs to be bound to the value of the identifier of the object the operation is applied to. Additionally, the variable “?gen” has to be bound to the identifier of the generalization relationship to be removed. Design Goals Design goals are related to long-term activities. They are used to describe the intended final state of a design activity. In contrast to guidelines and pre- and postconditions, which are enforced by the system, the developer itself may decide when to examine a design goal. Thus, checking constraints on demand is supported in our approach. Following our approach, OCL can serve as a powerful tool for enforcing the preciseness of UML models in general, for enforcing design guidelines and for guiding the developer through the process of modeling.

MAPPING OCL CONSTRAINTS In order to exploit OCL constraints as described so far it is not suitable to convert the constraints to SQL manually. Especially regarding that guidelines evolve over time, which is reflected by the temporary design guidelines, and that developers may want to check design goals in an ad-hoc manner, manual mapping is

158


Figure 2: UML object diagram: “Sample Translation Tree” ForAll : ForAll

set : set

predicate : predicate

SetGE : AllInstances

Predicate : GreaterEqual para1 : parameter2 para2 : parameter1 1: Integer

class : class iterator : variable GeneralizableElement : UmlClass

Size : Size set : set SetG : ProjectionCollectionByAssociationEndNode object : object associationEnd : target Self : VariableNode

Supertype : UmlAssociationEnd

Figure 3: UML class diagram “Translation Graph Nodes” 1

SetNode

1

0..*

ForAll

set

1

predicate

1

0..1 variable AllInstances

class

ProjectionCollectionNode

PredicateNode

variable 0..*

0..* 1

1

ProjectionCollectionByAssociationEndNode

UmlClass

0..*

1

GreaterEqual

parameter2

parameter1 0..* ProjectionCollectionByAttributeNode

target 1 UmlAttribute

1

ValueNode

variable

target

0..*

1 UmlAssociationEnd

0..*

ObjectNode

1

1 1

0..* ProjectionObjectNode

VariableNode Integer

1 0..*

target

ProjectionObjectByAssicioationEndNode

ProjectionObjectByAttribute

Size

0..* target

0..*

set

not acceptable, because the work of translating the constraints is exhausting and error-prone. Additionally, developers would need to be experts not only in UML and OCL but also for SQL and ORDBMS functionality. In order to avoid these complexities we want to support automatic mapping of OCL constraints (expressing invariants, design guidelines, etc.) by an OCL-to-SQL compiler. This compiler works as follows. After parsing the OCL constraint, the compiler generates an intermediate representation, called translation graph. The UML object diagram shown in Figure 2 illustrates a sample translation graph. It results from parsing the design guideline introduced earlier, which restricts the upper bound of superclasses for


each class in a UML model to at most one. The translation graph consists of two kinds of nodes, translation nodes and meta-data nodes. In our example, the objects “ForAll,” “SetGE,” “Size,” “SetG,” “Self” and “1” are translation nodes (dark coloured). Translation nodes implement the code generation algorithm, which depends on information about the UML model and its mapping to the database schema. Meta-data nodes (“GeneralizableElement” and “Supertype” (light coloured)) provide this information. These nodes represent instances of the classes of the UML meta-model. The classes for building and representing this translation graph are illustrated by the UML class diagram shown in Figure 3. Of course, this is not the entire UML model for translation graphs but it suffices for explanation. For example, an instance of class “ForAll” has to be connected to instances of “SetNode,” “VariableNode” and “PredicateNode.” In the sample translation graph (see UML object diagram (Figure 2)) the node “ForAll” is an instance of class “ForAll.” It is connected to an instance of class “AllInstances,” named “SetGE.” This relationship is valid because class “AllInstances” is subclass of abstract class “SetNode.” For the same reasons, the objects “Predicate” and “Self,” instances of the classes “GreaterEqual” and “Variable,” are connected to object “ForAll.” Also, the node “SetGE” has to be connected with an instance of class “UmlClass.” This is reflected by the relationship to “GeneralizableElement,” an instance of class “UmlClass,” representing class “GeneralizableElement” in the UML meta-model. This instance provides the meta-data needed by “SetGE” in the translation process. The translation process is based on SQL templates and construction rules, implemented by the classes associated with the translation nodes. The following SQL template is associated with the “ForAll” node: NOT EXISTS( SELECT * FROM ( $SetNode$ ) AS $VariableNode$ WHERE NOT ( $PredicateNode$ ) )

SQL templates may contain generic parameters, enclosed by “$.” As part of the translation process, each node asks its subnodes to provide an appropriate SQL fragment in order to replace the generic parameters. In the sample translation graph above, the object “ForAll” receives three SQL fragments from its subnodes “SetGE,” “Self” and “Predicate.” The “SetGE” node depends on meta-data in order to deliver an appropriate SQL fragment. It needs the name of the database table in which the tuples representing instances of the class are stored. In our example, this name is provided by an instance of meta-class “UmlClass” representing the meta-data of the class named “GeneralizableElement.” Hence, parameter $tablename$ in the SQL template below is replaced by “generalizable_element_ta.” The resulting SQL fragment is used to replace parameter $SetNode$ in the SQL template above.

160


SELECT * FROM $tablename$

Other interesting kinds of nodes are the projection nodes. We have identified four kinds of projection nodes, “ProjectObjectByAttribute,” “ProjectObjectByAssociationEnd,” “ProjectCollectionByAttribute” and “ProjectCollectionByAssoziationEnd.” These nodes are related to the two different ways of accessing structural features in OCL (either by accessing an attribute or by navigating along an association) and the two different kinds of results (either a single object or a collection of objects). The translation graph in our example contains an instance of class “ProjectCollectionByAssociationEnd,” because the evaluation of the sample constraints needs to navigate from class “GeneralizableElement” to the class “Generalization” and the expected result is a collection of instances of class “Generalization.” If asked by node “Size” to provide an SQL fragment it has to complete one of the following templates: SELECT T2.* FROM $sourcetablename AS T1, $targettablename$ AS T2 WHERE T1.$foreignkey$ = T2.id AND T1.id = $object$.id SELECT T2.* FROM $sourcetablename$ AS T1, $targettablename$ AS T2 WHERE T1.id = T2.$foreignkey$ AND T1.id = $object$.id SELECT T3.* FROM $sourcetablename$ AS T1, $relationtablename$ AS T2, $targettablename$ AS T2 WHERE T1.id = T2.$sourceforeignkey$ AND T2.$targetforeignkey$ = T3.id AND T1.id = $object$.id

The first template is related to a (1:1)-relationship, the second to a (1:n)relationship and the last is related to an (n:m)-relationship. The projection node chooses the template by evaluating the meta-data provided by object “supertype.” In our example, “SetG” chooses the second template. Parameter $sourcetablename$ is replaced by “generalization_element_ta,” $targettablename$ by “generalization_ta,” $foreignkey$ by “subtype” and $object$ by “self.” After processing all translation graph nodes as outlined in this section we obtain the following SQL search expression: NOT EXISTS ( SELECT * FROM generalizable_element_ta AS self WHERE NOT ( 1

Optimal Information Modeling Techniques

Optimal inventory modeling of systems: multi-echelon techniques, Second Edition

Building Information Modeling

Optimal Reliability Modeling : Principles and Applications

Optimal reliability modeling: principles and applications

Information Modeling the EXPRESS Way

Grafting-Characterization Techniques-Kinetic Modeling

Information Modeling Methods and Methodologies

Information Modeling for Internet Applications

Information Criteria and Statistical Modeling

Conceptual Modeling of Information Systems

Innovative Information Systems Modelling Techniques

Scale Modeling Tips and Techniques (Scale Modeling Handbook, No. 12)

Character Modeling with Maya and ZBrush: Professional polygonal modeling techniques

Character Modeling with Maya and ZBrush: Professional polygonal modeling techniques

Optimal Nutrition for Optimal Health

Optimal Nutrition for Optimal Health

Optimal Nutrition for Optimal Health

Compact Modeling: Principles, Techniques and Applications

Modeling Decisions: Information Fusion and Aggregation Operators

Groundwater Modeling Using Geographical Information Systems

VLSI Fault Modeling and Testing Techniques:

Modeling Materials: Continuum, Atomistic and Multiscale Techniques

Data modeling techniques for data mining IBM

Modeling Materials: Continuum, Atomistic and Multiscale Techniques

Structural Modeling and Experimental Techniques, Second Edition

Data Modeling Techniques for Data Warehousing

Underwater acoustic modeling: principles, techniques and applications

Solar Energy Fundamentals and Modeling Techniques

Spatial Evolutionary Modeling (Spatial Information Systems)

Optimal Information Modeling Techniques

Optimal inventory modeling of systems: multi-echelon techniques, Second Edition

Building Information Modeling

Optimal Reliability Modeling : Principles and Applications

Optimal reliability modeling: principles and applications

Information Modeling the EXPRESS Way

Grafting-Characterization Techniques-Kinetic Modeling

Information Modeling Methods and Methodologies

Information Modeling for Internet Applications

Information Criteria and Statistical Modeling

Conceptual Modeling of Information Systems

Innovative Information Systems Modelling Techniques

Scale Modeling Tips and Techniques (Scale Modeling Handbook, No. 12)

Character Modeling with Maya and ZBrush: Professional polygonal modeling techniques

Character Modeling with Maya and ZBrush: Professional polygonal modeling techniques

Optimal Nutrition for Optimal Health

Optimal Nutrition for Optimal Health

Optimal Nutrition for Optimal Health

Compact Modeling: Principles, Techniques and Applications

Modeling Decisions: Information Fusion and Aggregation Operators

Groundwater Modeling Using Geographical Information Systems

VLSI Fault Modeling and Testing Techniques:

Modeling Materials: Continuum, Atomistic and Multiscale Techniques

Data modeling techniques for data mining IBM

Modeling Materials: Continuum, Atomistic and Multiscale Techniques

Structural Modeling and Experimental Techniques, Second Edition

Data Modeling Techniques for Data Warehousing

Underwater acoustic modeling: principles, techniques and applications

Solar Energy Fundamentals and Modeling Techniques

Spatial Evolutionary Modeling (Spatial Information Systems)

Recommend Documents