Optimal Information Modeling Techniques

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

Author: Keys Van Slooten

42 downloads 8772 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.

van Slooten & Bruins • 3

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

4 • Evaluating an ISD Methodology for Software Packages

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

van Slooten & Bruins • 5

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.

6 • Evaluating an ISD Methodology for Software Packages

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.

van Slooten & Bruins • 7

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.

8 • Evaluating an ISD Methodology for Software Packages

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.

van Slooten & Bruins • 9

• 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

10 • Evaluating an ISD Methodology for Software Packages

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’

van Slooten & Bruins • 11

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

12 • Evaluating an ISD Methodology for Software Packages

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.’

van Slooten & Bruins • 13

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

14 • Evaluating an ISD Methodology for Software Packages

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.

van Slooten & Bruins • 15

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

18 • Modelling Molecular Biological Information

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.

20 • Modelling Molecular Biological Information

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'

22 • Modelling Molecular Biological Information

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:

24 • Modelling Molecular Biological Information

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();

26 • Modelling Molecular Biological Information

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 << “The DNA sequence is ” << entity-> GetDNAsequence() << endl;

EXPERIMENTAL RESULTS AND CONCLUSION Applying the TerminologicalHierarchy ODP to a small part of the immunology ontology (Giudicelli, 1998; Giudicelli and Lefranc, 1999), many issues were found worthy of consideration: 1. The explicit reference from child DescriptionUnits to their parent can simplify the traversal and management of a Cluster structure. The parent reference simplifies moving up the structure and deleting a DescriptionUnit. Parent references also help support the ChainOfExpression ODP (Reich in press). The parent reference is defined in the DescriptionUnit concept. Primitive and complex concepts inherit the reference and operations that manage it. 2. DescriptionUnits can be shared if they have more than one parent. When children store multiple parents, a context propagating up the structure can become ambiguous. The UnspecificTerm ODP (Reich in press) shows how to rework a design to avoid storing parent altogether. It works in cases where children can avoid sending parent contexts by externalising information. 3. The TerminologicalHierarchy ODP wants to make users unaware of the specific primitive or complex concepts they are using. Therefore, the interface of the DescriptionUnit concept is maximised defining as many common operations for primitive and complex concepts as possible. The sub-concepts will implement them appropriately for their own needs. This can conflict with the design that a concept should only define operations, which are meaningful to its sub-concepts. 4. The declaration and implementation of the child management operations is a trade-off between safety and transparency. Defining the child management interface in the DescriptionUnit concept gives transparency because all components can be treated uniformly. It costs safety, because users may try to do

Reich • 27

meaningless things, such as “add” or “remove” non-existing sub-concepts from primitive concepts. Defining child management in the complex concept is safe, but transparency will be lost, because primitive and complex concepts will have different interfaces. In our example of a TerminologicalHierarchy ODP transparency is emphasised over safety. 5. If some complex concepts need their children being ordered, then a careful design of their access and management is necessary.

ACKNOWLEDGMENTS This work was done at the Department of Computer Science of the University of Manchester. Many thanks to Daniel Buchholz, Veronique Giudicelli and Marie-Paule Lefranc for reviewing the manuscript.

REFERENCES Altman, R. B., Abernethy, N. F., and Chen, R. O. (1997). Standardized Representations of the Literature: Combining Diverse Sources of Ribosomal Data. In Proceedings of the Fifth International Conference on Intelligent Systems for Molecular Biology (ISMB-97). Altman, R.B, Karp, P.D., Musen, M.A, and Schulze-Kremer, S. (1998). Tutorial: Ontologies for Molecular Biology. The Sixth International Conference on Intelligent Systems for Molecular Biology. Montréal, Canada. Baker, P. G., Goble, C. A., Bechhofer, S., Paton, N. W., Stevens, R., and Brass, A. (1999). An Ontology for Bioinformatics Applications. In Bioinformatics,15(6), p.510-520. Beys, P., Benjamins, R., and Van Heijst, G. (1996). Remedying the reusabilityusability trade-off for problem-solving methods. In Proceedings of the Tenth Knowledge Acquisition Workshop (KAW96). Booch, G. (1994). Object-Oriented Analysis and Design with Applications (2nd ed.). Redwood City, CA: Benjamin / Cummings. Calvanese, D., De Giacomo, G., Lenzerini, M., Nardi, D., and Rosati, R. (1998). Description logic framework for information integration. In Proceedings of the sixth International Conference on the Principles of Knowledge Representation and Reasoning (KR-98), p.2-13. Coad, P. (1992). Object-oriented Patterns. In Communications of the ACM. 35(9). p.152-159, September. Cocchiarella, N. B. (1996). Conceptual Realism as a Formal Ontology. In Poli, R. and Simons, P. (Eds), Formal Ontology. The Netherlands: Kluwer Academic Publishers, p.27-60. Gamma, E., Helm, R., Johnson, R., and Vlissides, J. (1994). Design Patterns Elements of Reusable Object-Oriented Software. Addison-Wesley.

28 • Modelling Molecular Biological Information

Giudicelli, V. (1998). Conception d’une ontologie en immunogenetique et development d’un module de coherence pour le controle de qualite de IMGT/LIGMDB. PhD. University of Montpellier II. Sciences et Techniques du Languedoc. Giudicelli, V., and Lefranc, M.-P. (1999). Ontology for Immunogenetics: IMGTONTOLOGY. Bioinformatics, in press. Gomez-Perez, A., Fernandez, M., and De Vicente, A. J. (1996). Towards a method to conceptualise domain ontologies. In Workshop on Ontological Engineering (ECAI’96), p.41-51. Gruber, T. R. (1993). A translation approach to portable ontology specifications. In Knowledge Acquisition, 5, p.199-220. Gruber, T. R. (1995). Toward principles for the design of ontologies used for knowledge sharing. In International Journal Human-Computer Studies 43, p.907-928. Guarino, N.(1997). Some organizing principles for a unified top-level ontology. In Proceedings of the AAAI Spring Symposium on Ontological Engineering, Stanford, CA. Honjo, T., and Alt, F. W. (Eds.) (1995). Immunoglobulin genes. London: Academic Press, Harcourt Brace and Company Publishers. Horrocks, I. R. (1998). Using an expressive description logic: FaCT or Fiction? In Proceedings of the sixth International Conference on the Principles of Knowledge Representation and Reasoning (KR-98). Larman, C. (1997). Applying UML and Introduction to Object-Oriented Analysis and Design. Prentice Hall. Lefranc, M.-P., Giudicelli, V., Ginestoux, C., Bodmer, J., Müller, W., Bontrop, R., Lemaitre, M., Malik, A., Barbié, V., and Chaume, D. (1999). IMGT, the international ImMunoGeneTics database. Nucleic Acids Res., 27, 209-212. Mahesh, K., and Nirenburg, S. (1996). Track on Information Interchange. In Proceedings of the FLAIRS-96, Florida AI Research Symposium. Neches, R., Fikes, R. Finin, T., Gruber, T., Patil, R., Senator, T., and Swartout, W. (1991). Enabling technology for knowledge sharing. In AI Magazine, p.3656. Rector, A.L., Bechhofer, S., Goble, C. A, Horrocks, I.R., and Solomon, W. D. (1997). The GALEN modelling language for medical terminology. Artificial Intelligence in Medicine, 9, 139-171. Rector, A.L., Nowlan, W. A., and Glowinski, A. (1993). Goals for concept representation in the GALEN project. In Proceedings of the 17th Annual Symposium on Computer Applications in Medical Care (SCAMC’93), p.414418, Washington DC, USA.

Reich • 29

Reich, J. R. (1999). Ontological Design Patterns for the Integration of Molecular Biological Information. Proceedings of the German Conference on Bioinformatics (GCB’99), p.156-165, Hannover, Germany, http:// www.bioinfo.de/isb/gcb99/talks/reich. Reich, J. R. (2000). Ontological Design Patterns for the Management of Molecular Biological Knowledge. In Proceedings of the AAAI Spring Symposium on Bringing Knowledge to Business Processes, Stanford, CA., in press. Rumbaugh, J., Blaha, M., Premerlani, W., Eddy, F., and Lorensen, W. (1991). Object-Oriented Modelling and Design. Prentice Hall Inc. Uschold, M. (1996). Converting an informal ontology into Ontolingua: Some experiences. In Proceedings of the Workshop on Ontological Engineering, ECAI 96, Budapest.

30 • Concept Acquisition Modeling for E-Commerce Ontology

Chapter 3

Concept Acquisition Modeling for E-commerce Ontology 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

To bolster the interoperability of agent-based commerce systems, trading agents are expected to adopt a set of common ontologies. Although there are extant general-purpose ontologies and approaches of engineering them, there seem to be no ontology that is specific for e-commerce or the methodologies for constructing e-commerce ontology. This chapter presents a concept acquisition modeling approach to facilitate the acquisition, classification and representation of e-commerce concepts. It proposes a systematic way to make comparisons between concepts based upon some understanding of their semantics. The process is comprised of classification criteria, questions scheme, rules for classifying relations and optimization, and concept representation for the e-commerce based ontology. Of particular interest is the use of context-dependent and language-independent classification knowledge. The explicit representation nature of the approach enables the development of shared ontologies and its reuse in other ontologies and applications. Previously Published in Challenges of Information Technology Management in the 21st Century, edited by Mehdi Khosrow-Pour, Copyright © 2000, Idea Group Publishing.

Lee, Sim & Kwok • 31

INTRODUCTION The phenomenal growth in Internet computing over the past decade has created enormous business opportunities for many modern enterprises selling or advertising their products on the WWW. Although there are extant electronic payment, information brokering and automated negotiation systems for bolstering ecommerce, the heterogeneous systems deployed by business organizations may impede the development of common standards that facilitate systems interoperability (Chandrasekaran et al., 1999; Glushko et al., 1999; Smith and Poulter, 1999). The challenges related to the proliferation of standards include (1) How to support the representation of business information? (2) How should the ontological relations of e-commerce concepts be defined and organized? (3) How to acquire e-commerce concepts? Like knowledge-based system (KBS) development, ontology development faces a concept-acquisition bottleneck. Unlike KBS developers, ontology developers lack sufficient methodologies to recommend what task activities should be performed and at what stage of ontology development (Lopez et al., 1999). This paper presents an ontology-based concept acquisition method to facilitate the acquisition and classification of e-commerce concepts. It proposes a systematic way to make comparisons between concepts based upon some understanding of their semantics. An inference mechanism is developed for understanding concepts and how the concepts are related semantically; for example, to make a connection between the price of US dollars and the price of HK dollars. While a conventional dictionary is not very helpful in this situation, it is desirable to characterize a concept using a set of properties from an ontology that can be used as a surrogate for a concept’s meaning and provide gradation, dependency or association relationships to other concepts. This chapter describes an e-commerce relation ontology to provide semantic relationships among concepts. An e-commerce concept acquisition process is introduced to acquire and classify concepts based on the e-commerce relation ontology. The approach can be applied to several applications, for example, information retrieval or negotiation with other agents. This chapter is to capitalize the experience in the concept acquisition and representation for e-commerce systems.

E-COMMERCE CONCEPT RELATION ONTOLOGY Ontology represents an explicit specification of a domain conceptualization (Gruber, 1993). The classes and relations of the e-commerce concept relation ontology are shown in figure 1, which supports gradation, dependence and association classes among concepts. The hierarchical graph illustrates inheritance,

32 • Concept Acquisition Modeling for E-Commerce Ontology

Figure 1: E-C Concept Relation Ontology Relation

Gradation

Strength

Dependence

Correlation

Association

Equivalence

Contradictory

Hierarchy Synonym Super-concept

Antonym Sub-Concept

Figure 1. E-C Concept Relation Ontology

where each class on the lower level inherits properties from the preceding level. The class gradation can be expressed by ordered strength of a concept, which represent a semantic relation for organizing lexical memory for adjectives (Fellbaum, 1998). The class dependence models the semantic dependence relations between concepts, that is correlation. The class association consists of three sub-classes: equivalence, hierarchy and contradictory. The equivalence association exists between or among concepts that represents the same concept. The hierarchical association represents the broader and narrower concept relations. The contradictory association expresses opposing values of an attribute. The six ontological relations identified in Figure 1 are used to facilitate the effective application of electronic lexicons for e-commerce. On this account, six operations are given as follows: Super-concept. If a concept has a broader meaning than another concept, then the concept is called super-concept. For example, “Shares” is a super-concept for “Preferential Shares” and “Warrant.” Sub-concept. If a concept has a narrower meaning than another concept, then the concept is called sub-concept. For example, «call option» and «put option» are sub-concepts of «option» whereas «option» is the super-concept. Synonym. If two concepts share similar properties, then they are synonym. For example, “Strike Price” and “Exercise Price” are synonym. Antonym. If two concepts have opposite properties, then they are antonym. For example, “Short Position” and “Long Position” are antonym. Strength. If a concept is associated with a scale (such as short, square, and long) representing degree and grades, then the concept has strength. For instance, “decline,” “plummet” and “nosedive” are concepts that are similar in meaning but differ in their strengths. Correlation. If a concept is dependent on another concept, then they have correlation. For instance, the decline in interest rate will lead to the rise of share prices. The interest rate and share prices have correlation relationships.

Lee, Sim & Kwok • 33

Figure 2: Concept Acquisition Process C la s s if ic a tio n C rite r ia

O p tim iz a tio n R u le s C oncept R e p re s e n ta tio n R u le s fo r C la s s ify in g R e la tio n s

Q u e s tio n S chem e Fi

2 C

A

i i i

P

E-COMMERCE CONCEPT ACQUISITION PROCESS Recent e-commerce application activity has led to proliferation of standardization and markup language proposals. However, the challenge is how to extract and define foundation ontologies (from which higher-level content is composed) from domain experts. From the e-commerce concept acquisition viewpoint, domain experts and human end users find it difficult to understand abstract definition of concepts, relations, and slots. They may have trouble formalizing their knowledge properly by using the ontological language (Lopez et al., 1999). Figure 2 shows an e-commerce concept acquisition process, which recommends activity tasks to facilitate the acquisition, classification and representation of concepts. The activity tasks include classification criteria, question scheme, optimization of questions, rules for classifying relations and concept representation. Classification Criteria Ontology classifies the categories or concepts in a domain. Classificatory knowledge is used to organize concepts into groups that share many properties. Organizing concepts into groups is important because understanding a concept mentioned by a user consists of determining the group to which it belongs (Storey et al., 1998). The classification criteria activity task produces higher level properties for the e-commerce ontology. Figure 3 shows the classification of property. E-commerce concepts have one or more of the following properties: obligation, exercise price, rate, position, preFigure 3: Classification of Property Property

Risk

Obligation Exercise Price

Rate

Coupon Rate Interest Rate

Position

Exchange Rate

Transaction Premium Type Buy/Sell

Potential Profitability Interest Exchange Rate Risk Rate

Risk Lend/Borrow Call/Put

34 • Concept Acquisition Modeling for E-Commerce Ontology

mium, transaction type, risk, and potential profitability. Each property has a description, for example, the exercise price is the predetermined level at which an option’s underlying instrument is priced upon its exercise. The exercise price is also called the strike price. Questioning Scheme Manually classifying concepts into categories or groups may lead to inconsistent results because different experts have different opinions. To resolve the inconsistency classification, the concept properties are used as a surrogate for the meaning of words, which provide some understanding of their semantics. The classification decision is made by users to answer a series of questions about the concept properties. Simple and unambiguous «yes» or «no» questions are designed to enable users to provide objective answers. The generation of question scheme is based on the e-commerce property ontology shown in Figure 3. Figure 4 shows an example of the question scheme for a concept «call option». Users will be prompted with the following questions: • Does «call option» have obligation? If the answer is «no» then, • Does «call option» have exercise price? If the answer is «yes» then, • Does «call option» have transaction type (call)? If the answer is «yes», then • Does «call option» have premium? If the answer is «yes», then The conclusion of the classification of «call option» is «option» group. The questions are asked in an intelligent order that is context-dependent. For example, if the answer to the question “does it have coupon rate” is “yes,” then a user would not be asked whether the concept refers to a “transaction type.”

Figure 4: A Question Scheme Example Obligation yes Rate

T

T

no Exercise Price

T

T

T

Risk

yes Transaction Type (call) no yes Position Premium yes Option T

no

T

Lee, Sim & Kwok • 35

Figure 5: Classification for Investment Investment Bond Foreign Exchange

Money Market

Lend

Deposit

Capital Market

Futures

Option

Call Option

Put Option

Optimization of Questions To optimize the generation of question scheme, a set of rules is designed to minimize the number of questions asked and to provide dynamic ordering of the sequence of questions asked. For example: R1: If exchange rate = «yes» then Group_type = «Foreign Exchange» End if R2: If interest rate = «yes» then Group_type = «Money Market» End if Figure 5 shows classification of investment concepts. The hierarchical graph categorizes investment concepts into groups. The higher levels in the hierarchy represent super-group concepts, for example, foreign exchange and money market. The lower levels in the hierarchy represent sub-concept of that group, for example call option and put option. Rules for Classifying Relations Once the concept has been classified into groups, then the concept relation ontology shown in Figure 1 is used to establish the relations between concepts. Six sets of rules are developed to enable systematic classification of the six ontological relations, for example: Super_Concept: For all group_concept_x and concept_x. Rule Sup: If concept_x belongs to group_concept_x, then group_concept_x is a super_concept of concept_x. End if For example, “option” is a super_concept of “call option.”

36 • Concept Acquisition Modeling for E-Commerce Ontology

Sub_concept: For all group_concept_x and concept_x. Rule Sub: If concept_x is within group_concept_x, then Concept_x is a sub_concept of group_concept_x. End if For example, “call option” is a sub_concept of “option.” Synonym: For all concept_x and concept_y Rule Syn: If concept_x and concept_y have the same classification criteria (same property) then concept_x and concept_y are synonym. End if For example, “strike price” and “exercise price” are synonym because both of them have derivative and obligation to exercise. Antonym: For all concept_x and concept_y Rule Ant: If classification criteria of concept_x and concept_y are opposite, then concept_x and concept_y are antonym. End if For example, “buy” and “sell,” the “transaction type” property shown in Figure 2, have opposite meaning, then “buy foreign exchange spot” and “sell foreign exchange spot” are antonym because one transaction type criteria is “buy” whereas the other is “sell.” Correlation: For all concept_x and concept_y Rule Cor: If property of concept_x depends on property of concept_y, then property of concept_x is correlation to property of concept_x End if For example, price of “call_option” is correlated to “exercise_price = premium < market_price (financial-asset).”

Lee, Sim & Kwok • 37

Figure 6: Classification for Strength Strength

Buy/Sell

Volume Large

Discount Par

Descending Rate Decline

Short

Medium Premium

Position/Time

Square Small

Plummet Long

Nosedive

Strength: Figure 6 shows the concept of strength along the dimensions of buy/sell, volume, position/time and descending rate. Each dimension is associated with a scale (such as large, medium and small) representing degree and grades. For all concept_x and strength_x Rule: If concept_x associates with strength_x then concept_x has strength_x (grade) End if For example, the strength of the share price can be represented in ascending order as “decline,” “plummet” and “nosedive.” Concept Representation A frame-based approach is used to codify the e-commerce concept ontology, which represents the gradation, dependence and relation of e-commerce concept. Figure 7 shows an example of a frame and various slots to represent a concept. Figure 7: An example of the concept representation. name : call_option property : {buy } sub-concept : { } super-concept: {options} synonym: { } antonym: {put_option} correlation : { exercise_price + premium < market_price (financial_asset) } strenght : { } <end_concept>

38 • Concept Acquisition Modeling for E-Commerce Ontology

While the name slot is self-explanatory, both sub-concept and super-concept facilitate categorization, sub-sumption and inheritance. The synonym and antonym slots define the (inter-) relations between (and among) concepts in the usual way (that is, concepts with similar and opposite meanings respectively). The property slot captures the features, attributes and characteristics of concepts. It has the same interpretation as the notion of property of objects in an object-oriented paradigm (OOP). In an OOP, a class of objects inherits properties from an ancestor class; in the above formalism, a concept inherits the features (attributes or properties) from concepts that subsume it. The correlation slot models dependence between concepts. Correlation differs from property because it models the reliance of some attributes of a concept C1 on the corresponding attributes of another concept C2. However, correlation does not necessarily imply that C1 is a sub-class of C2, hence C1 does not necessarily inherit every attribute from C2. The strength slot enables e-commerce adjectives of different grades to be compared.

APPLICATIONS Based on the proposed concept acquisition method, the constructed e-commerce ontology may be used to support retrieving relevant information from different sources in agent-based trading systems. For example, in an information brokering scenario, an investor may wish to search all web sites for a bid price of IBM stocks at US$70 per share. Information retrieval of this nature would require the identification and integration of relevant sources of information based on the ontology. In automated negotiation, trading parties need to operate on terms that are understood by all. However, information originating from different sources and different parties may not necessarily coincide and a commonly agreed upon and sharable repository of terms is desirable. To this end, this research is designing and engineering an ontology (unifying models of knowledge) specific for e-commerce applications. Nevertheless, the processes of constructing (e-commerce) ontology can be difficult and lengthy. Hence, it seems prudent to advice a method for (partially) automating the process of constructing the ontology.

DISCUSSIONS While the CYC project (Lenet, 1995) and WordNet (Fellbaum, 1998) concentrated on providing commonsense knowledge associated with words, this research is concerned with the representation and uses of “context-dependent” classification knowledge. The classification knowledge is to organize words into groups that share many properties. The context is dependent on e-commerce concepts. In addition, traditional ontology tools focus on implementation issues, which the ontology developers may have difficulty understanding implemented ontology

Lee, Sim & Kwok • 39

or even building new ontologies. Moreover, direct coding of the resulting concepts is too abrupt a step, especially for complex ontologies. In this paper, the proposed approach focus on design questions. This is language-independent since ontologists do not need to know the ontology’s implementation language. The research provides a user-friendly approach to concept acquisition and a consistent, generally applicable method for constructing ontologies. Most of ontology building is an art rather than a science. Each development team usually follows its own set of principles, design criteria and guidelines. The absence of structured methods hinders the development of shared ontologies between teams and its reuse in other ontologies. The source of these problems is the absence of an explicit conceptual model upon which to formalize the ontology (Lopez et al., 1999). The research presented in this paper provides explicit representations of e-commerce concept relation ontology, classification of property model, classification of investment concepts, question scheme, rules of optimization and classification, and concept representation frame. Experts and end users can gain full understanding of and formalize their knowledge with greater ease.

CONCLUSION An ontology-based concept acquisition approach has been presented to acquire, classify and represent e-commerce concepts. The systematic approach is used to organize similar concepts into groups that share many properties. Such grouping is important because it provides some understanding of the concept semantics. The constructed ontology can be used to store and provide the meaning of the concepts and to support gradation, dependence and association relations between concepts. The generation of e-commerce concept ontology is context dependent and language independent. The knowledge base of classified concepts can easily be expanded through use. Future research will involve the integration of the ontology into agent-based trading and brokering agents to facilitate e-commerce transactions. Testing of the ontology will be carrying out on various concepts from different application domains such as used-car trading. In addition, future research will focus on allowing a concept to have multiple classifications to capture different meanings.

ACKNOWLEDGMENT The work reported in this paper has been funded in part by the Department of Electrical and Electronics Engineering, University of Hong Kong. Research facilities were provided by the Department of Computing, Hong Kong Polytechnic University. The authors would like to thank Gabriel Chau and David PT Wong for insightful discussions.

40 • Concept Acquisition Modeling for E-Commerce Ontology

REFERENCES Chandrasekaran, B., Josephson, J., and Benjamins, V. (1999). What Are Ontologies, and Why Do We Need Them, IEEE Intelligent Systems, January/ February, 22-26. Fellbaum, C. (Ed.) (1998). Wordnet: An Electronic Lexical Database, The MIT Press. Glushko, R., Tenenbaum, J. and Meltzer, B. (1999). An XML Framework for Agent-based E-commerce, Communication of the ACM, March, 42(3), 106114. Gruber, T. A (1993). Translation Approach to Portable Ontology Specifications, Knowledge Acqusition, 5 (9) 199-220. Lenat, D. (1995). CYC: A Large-Scale Investment in Knowledge Infrastructure, Communication ACM 38 (100), November, 33-41. Lopes, M., Gomez-Perz, and Sierra, J. (1999). Building a Chemical Ontology Using Methodology and the Ontology Design Environment, IEEE Intelligent Systems, January/February, 37-46. Smith, P. and Poulter, K. (1999). Share the Ontology in XML-based Trading Architectures, Communication of ACM, March, 42(3), 110-111. Storey, V., Dey, D., Ullrich, H. and Sundaresan, S. (1998). An Ontology-based Expert System for Database Design, Data & Knowledge Engineering, 28, 31-46.

Lemahieu • 41

Chapter 4

An Object-Oriented Approach to Conceptual Hypermedia Modeling Wilfried Lemahieu Katholieke Universiteit Leuven, Belgium

This chapter introduces the MESH approach to hypermedia modeling and navigation, which aims at relieving the typical drawbacks of poor maintainability and user disorientation. The main focus is upon the data model, which combines established entity-relationship and object-oriented abstractions with proprietary concepts into a formal hypermedia data model. Uniform layout and link typing specifications can be attributed and inherited in a static node typing hierarchy, whereas both nodes and links can be submitted dynamically to multiple complementary classifications. In addition, the data model’s support for a context-based navigation paradigm, as well as a platform-independent implementation framework, are briefly discussed.

INTRODUCTION The hypermedia paradigm looks upon data as a network of nodes, interconnected by links. Whereas each node symbolizes a concept, a link not only stands for a relation between two items, but also explicitly assumes the semantics of a navigation path, hence the quintessential property of navigational data access. Their inherent flexibility and freedom of navigation raises hypermedia systems as utterly suitable to support user-driven exploration and learning. Unfortunately, due to inadequacy of the underlying data models, most hypermedia technologies suffer from severely limited maintain-

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

42 • An Object-Oriented Approach to Conceptual Hypermedia Modeling

ability. Moreover, the downside of complete navigational freedom is the so-called lost in hyperspace phenomenon, which denotes a disoriented user’s inability to assess his current position and sort out his navigational options. The MESH hypermedia framework as deployed in Lemahieu (1999] proposes a structured approach to both data modeling and navigation, so as to overcome said maintainability and user disorientation problems. MESH is an acronym for Maintainable, End user friendly, Structured Hypermedia. Its fundaments are a solid underlying data model and a context-based navigation paradigm. The data model is based on concepts and experiences in the related field of database modeling, taking into account the particularities inherent to the hypermedia approach to data storage and retrieval. Established entity-relationship (Chen, 1976) and object-oriented (Rumbaugh et al., 1991; Jacobson et al., 1992; Meyer, 1997; Snoeck et al., 1999) modeling abstractions are coupled to proprietary concepts to provide for a formal hypermedia data model. While uniform layout and link typing specifications are attributed and inherited in a static node typing hierarchy, both nodes and links can be submitted dynamically to multiple complementary classifications. The MESH data model provides for a firm hyperbase structure and an abundance of meta-information that facilitates implementation of an enhanced navigation paradigm. This context-based navigation paradigm builds upon the data model to reconcile navigational freedom with nested, dynamically created guided tours. Indeed, the intended navigation mechanism is that of an “intelligent book”, which is to provide a disoriented end user with a sequential path as a guidance. Such guided tour is not static, but is adapted dynamically to the navigation context. In addition, a node is able to tune its visualization to the context in which it is accessed, hence providing the user with the most relevant subset of its embedded multimedia objects. These blueprints are translated into a high-level implementation framework, specified in an abstract and platform independent manner. The body of this paper is dedicated to the MESH data model. Thereafter, the context-based navigation paradigm and the implementation framework are briefly discussed. A last section makes comparisons to related work and formulates conclusions.

MESH’S OBJECT-ORIENTED HYPERMEDIA DATA MODEL Introduction The benefits of data modeling abstractions to both orientation and maintainability were already acknowledged in Halasz (1988), Garg (1988), Botafogo et al. (1991), and Rivlin et al. (1994). They yield richer domain knowledge specifications and more expressive querying. Typed nodes and links offer increased consistency in both node layout and link structure (Thüring et al., 1991; Knopik & Bapat, 1994). Higher-order information units and perceivable equivalencies (both on a conceptual and a layout

Lemahieu • 43

level) greatly improve orientation (Thüring et al., 1995; Ginige et al., 1995). Moreover, the separation of node content from data structure along with the introduction of a dedicated link storage facility, allows for improved maintainability (Garzotto et al., 1993; Duval et al., 1995). Semantic constraints and consistency can be enforced (Garzotto et al., 1995; Ashman et al., 1997), tool-based development is facilitated and reuse is encouraged (Nanard & Nanard, 1995). The first conceptual hypermedia modeling approaches such as HDM (Garzotto et al., 1993) and RMM (Isakowitz et al., 1995; Isakowitz et al., 1998) were based on the entity-relationship paradigm. Object-oriented techniques were mainly applied in hypermedia engines, to model functional behavior of an application’s components, e.g., Intermedia (Meyrowitz, 1986; Haan et al., 1991), Microcosm (Davis et al., 1992; Hall et al., 1992; Beitner et al., 1995), Hyperform (Wiil & Leggett, 1992; Wiil & Leggett, 1997) and Hyperstorm (Bapat et al., 1996). Along with EORM (Lange, 1994) and OOHDM (Schwabe et al., 1996; Schwabe & Rossi, 1998a; Schwabe & Rossi, 1998b), MESH is the first approach where modeling of the application domain is fully accomplished through the object-oriented paradigm. The Basic Concepts: Node and Link Types On a conceptual level, a node is considered a black box, which communicates with the outside world by means of its links. External references are always made to the node as a whole. True to the O.O. information-hiding concept, no direct calls can be made to its multimedia content. However, internally, a node may encode the intelligence to adapt its visualization to the navigation context, as discussed in section 4. Nodes are assorted in an inheritance hierarchy of node types. Each child node type should be compliant with its parent’s definition, but may fine-tune inherited features and add new ones. These features comprise both node layout and node interrelations, abstracted in layout templates and link types respectively. A layout template is associated with each level in the node typing hierarchy, every template being a refinement of its predecessor. Its exact specifications depend upon the implementation environment, e.g. as to the Web it may be HTML or XML based. Node typing as a basis for layout design allows for uniform behavior, onscreen appearance and link anchors for nodes representing similar real world objects. A link represents a one-to-one association between two nodes, with both a semantic and a navigational connotation. A directed link offers an access path from its source to its destination node. Links representing similar semantic relationships are assembled into types. Link types are attributed to node types and can be inherited and refined throughout the hierarchy. Link type properties allow for enforcing constraints upon their instances and can be overridden to provide for stronger restrictions upon inheritance. This mechanism is discussed in full in the next section.

44 • An Object-Oriented Approach to Conceptual Hypermedia Modeling Artist

Has-made

Artwork

Has-painted

Painter

Painting

E.g., whereas an artist node can be linked to any artwork through a has-made link type, an instance of the child node type painter can only be linked to a painting, by means of the more specific child link type has-painted. The Use of Aspects to Overcome Limitations of a Rigid Node Typing Structure Definition of aspect descriptor and aspect type The above model is based on a node typing strategy where node classification is total, disjoint and constant. The aspect construct allows for defining additional classification criteria, which are not necessarily subject to these restrictions. Apart from a single “most specific node type,” they allow a node to take part in other secondary classifications that are allowed to change over time1. An aspect descriptor is defined as an attribute whose (discrete) values classify nodes of a given type into respective additional subclasses. In contrast to a node’s “main” subtyping criterion, such aspect descriptor should not necessarily be singlevalued or constant over time. Aspect descriptor properties denote whether the classification is optional/mandatory, overlapping/disjoint and temporary/ permanent. Each aspect type is associated with a single value of an aspect descriptor. An aspect type defines the properties that are attributed to the class of nodes that carry the corresponding aspect descriptor value. An aspect type’s instances, aspects, implement these type-level specifications. Each aspect is inextricably associated with a single node, adding characteristics that describe a specific “aspect” of that node. A node instance may carry multiple aspects and can be described by as many aspect descriptors as there are additional classifications for its node type. If multiple classifications exist, each aspect descriptor has as many values as there are subclasses to the corresponding specialization. Its cardinalities determine whether the classification is total and/or disjoint. As opposed to node types, aspects are allowed to be volatile. Hence, dynamic classification can be accomplished by manipulating aspect descriptor values, thus adding or removing aspects at run-time. Aspect types attribute the same properties as nodes: link types and layout. However, their instances differ from nodes in that they are not directly referable. An aspect represents the same realworld object as its associated node and can only be visualized as a subordinate of the latter.

Lemahieu • 45 Aspect type

Painter

Node type

Artist

Aspect type

Sculptor

Aspect descriptor

Discipline Michelangelo Van Gogh

(Painting, Sculpting)

M.asPainter

Rodin …

M.asSculptor

…

R.asSculptor

…

…

VG.asPainter

…

…

E.g., to model an artist that can be skilled in multiple disciplines, a non-disjoint aspect descriptor discipline defines the painter and sculptor aspect types. Discipline-specific node properties are modeled in these aspect types, such that e.g. the Michelangelo node features the combined properties of its Michelangelo.asPainter and Michelangelo.asSculptor aspects. Delegation of node properties to aspect descriptors Node type properties (i.e., layout and link types) can be delegated to aspect descriptors, such that they can be inherited and overridden in each aspect type that is associated with one of the descriptor’s values. An aspect type’s layout template refines layout properties that are delegated to the corresponding aspect descriptor. Link types delegated to an aspect descriptor can be inherited and overridden as well. In addition, each aspect type can define its own supplementary link types. The inheritance/overriding mechanism is similar to the mechanism for supertypes/subtypes, but because an aspect descriptor can be multi-valued, particular care was taken so as to preclude any inconsistencies. Further details are provided in the next section. Inheritance of aspect types throughout the classification hierarchy Aspect types themselves are node type properties that can be inherited and overridden across the node type hierarchy. The aspect descriptor is used as a vehicle for the inheritance of aspect types. This ability yields the opportunity to use aspects as real building blocks for nodes. Link types and layout definitions pertaining to a single “role” a node may have to play, can now be captured into one aspect type. If the corresponding aspect descriptor is attributed at a generic level in the node hierarchy, the aspect type can be inherited where necessary by more specific node types. This allows for the modeling of a similar “aspect” in otherwise completely unrelated node types. E.g. the aspect type art-collector could be defined at root level and inherited by both museum and private-collector, modeling the fact that both node types can behave as owners of artwork. Node types can be “assembled” by inheriting the proper aspect types, complemented by their own particular features. Hereby, different aspects associated with the same node instance can have different editing privileges, such that updating multimedia content can be delegated to different parties.

46 • An Object-Oriented Approach to Conceptual Hypermedia Modeling

Root

Art-collector

Museum

Art-collector

Private-collector

Art-collector

Link Typing and Subtyping Introduction In common data modeling literature, subtyping is invariably applied to objects, never to object interrelations. If additional classification of a relationship type is called for, it is instantiated to become an object type, which can of course be the subject of specialization. However, as for a hypermedia environment, node types and link types are two separate components of the data model with very different purposes. It would not be useful to instantiate a link type into a node type, since such nodes would have no content to go along with them and thus each instance would become an “empty” stop during navigation. This section demonstrates how specialization semantics can be enforced not only upon node types, but also upon the link types. A sub link type will model a type whose set of instances constitutes a subset of its parent’s, and which models a relation that is more specific than the one modeled by the parent. Definition and domain of a sub link type A link instance is defined as a source node - destination node tuple (ns, nd). Tuples for which this association represents a similar semantic meaning are grouped into link types. A link type defines instances that comply with the properties of the type and is constrained by its domain, its cardinalities and its inverse link type. The domain of the link type is the data type to which the link type is attributed. This can be either a node type or an aspect type. The domain casts a restriction upon which nodes are valid as source nodes of the tuples represented by the link type: (ns, nd) ∈ L => 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,

50 • An Object-Oriented Approach to Conceptual Hypermedia Modeling

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,

52 • An Object-Oriented Approach to Conceptual Hypermedia Modeling

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.

54 • An Object-Oriented Approach to Conceptual Hypermedia Modeling

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-

Strauch & Winter • 57

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,

58 • Conceptual Modeling of Large 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.

Strauch & Winter • 59

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.

60 • Conceptual Modeling of Large Web Sites

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-

Strauch & Winter • 61

•

•

•

• • •

•

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,

62 • Conceptual Modeling of Large Web Sites

• • • •

•

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

Strauch & Winter • 63

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

64 • Conceptual Modeling of Large Web Sites

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.

Strauch & Winter • 65

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.

66 • Conceptual Modeling of Large Web Sites

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-

Strauch & Winter • 67

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.).

68 • Conceptual Modeling of Large Web Sites

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.

72 • A Method to Ease Schema Evolution

- 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

74 • A Method to Ease Schema Evolution

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-

76 • A Method to Ease Schema Evolution

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

80 • A Three Layered Approach for General Image Retrieval

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

Chbeir, Amghar & Flory • 81

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

82 • A Three Layered Approach for General Image Retrieval

• 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.

Chbeir, Amghar & Flory • 83

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-

86 • Is There A Life After Objects?

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-

88 • Is There A Life After Objects?

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).

90 • Is There A Life After Objects?

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.

92 • Is There A Life After Objects?

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.

94 • Is There A Life After Objects?

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

Cheung & Chan • 97

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).

98 • A Systemic Approach to Define Agents

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”

Cheung & Chan • 99

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

100 • A Systemic Approach to Define Agents

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.

Cheung & Chan • 101

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.

102 • A Systemic Approach to Define Agents

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.)

Cheung & Chan • 103

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.

104 • A Systemic Approach to Define Agents

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 <<users>> Retrieve information from the web <<users>> User (from Use Case View)

<<users>> Store retrieval to database Extract information

<<users>> <<users>> 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.

Cheung & Chan • 105

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.

106 • A Systemic Approach to Define Agents

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.

Cheung & Chan • 107

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

• Modeling of Coordinated Planning and Allocation of Resources

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

Bulatov & Kurt • 111

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

• Modeling of Coordinated Planning and Allocation of Resources

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

Bulatov & Kurt • 113

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

• Modeling of Coordinated Planning and Allocation of Resources

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.

Bulatov & Kurt • 115

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

• Modeling of Coordinated Planning and Allocation of Resources

• 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.

Bulatov & Kurt • 117

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

• Modeling of Coordinated Planning and Allocation of Resources

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.

Bulatov & Kurt • 119

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

• Modeling of Coordinated Planning and Allocation of Resources

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

Busch & Dampney • 123

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

• Tacit Knowledge Acquisition and Processing Within the Computing Domain

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

Busch & Dampney • 125

“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

• Tacit Knowledge Acquisition and Processing Within the Computing Domain

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.

Busch & Dampney • 127

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

• Modelling Business Rules Using Defeasible Logic

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

Antoniou & Arief • 131

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

• Modelling Business Rules Using Defeasible Logic

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.

Antoniou & Arief • 133

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

• Modelling Business Rules Using Defeasible Logic

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-

Antoniou & Arief • 135

•

•

•

•

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

• Modelling Business Rules Using Defeasible Logic

• 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,

Jung, Kim, Lee, Wu & Kim • 139

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

140 • EE-Cat: Extended Electronic Catalog

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

Jung, Kim, Lee, Wu & Kim • 141

(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.

142 • EE-Cat: Extended Electronic Catalog

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.

Jung, Kim, Lee, Wu & Kim • 143

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

144 • EE-Cat: Extended Electronic Catalog

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

Jung, Kim, Lee, Wu & Kim • 145

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> <capacity>$c</> </> Element_As $m </><br /> <br /> 146 • EE-Cat: Extended Electronic Catalog<br /> <br /> Figure 6: DCL system architecture Catalog Browser/Editor Client SDK<br /> <br /> Other Client A pplications<br /> <br /> Other Client A pplications<br /> <br /> CORBA interface<br /> <br /> CORBA interface<br /> <br /> Catalog Exchange Protocol<br /> <br /> CORBA DCL Server<br /> <br /> Category Manager<br /> <br /> ODBC<br /> <br /> IN p, $c > 64M and product_family(p) = “Personal Computer” Construct <result> $t $m</result> 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.<br /> <br /> 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.<br /> <br /> Jung, Kim, Lee, Wu & Kim • 147<br /> <br /> 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.<br /> <br /> 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.<br /> <br /> 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<br /> <br /> 148 • EE-Cat: Extended Electronic Catalog<br /> <br /> 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.<br /> <br /> 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.<br /> <br /> Jung, Kim, Lee, Wu & Kim • 149<br /> <br /> 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/.<br /> <br /> ENDNOTES 1<br /> <br /> 2<br /> <br /> 3<br /> <br /> 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.<br /> <br /> 150<br /> <br /> • Enforcing Modeling Guidelines in an ORDBMS-based UML-Repository<br /> <br /> Chapter 14<br /> <br /> 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.<br /> <br /> 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.<br /> <br /> Ritter & Steiert • 151<br /> <br /> 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.<br /> <br /> 152<br /> <br /> • Enforcing Modeling Guidelines in an ORDBMS-based UML-Repository<br /> <br /> 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<br /> <br /> Ritter & Steiert • 153<br /> <br /> Figure 1: UML class diagram: ‘Generalization Hierarchy’ ModelElement<br /> <br /> +subtype<br /> <br /> +generalization<br /> <br /> 1..1<br /> <br /> *<br /> <br /> GeneralizableElement<br /> <br /> Generalization 1..1<br /> <br /> +supertype<br /> <br /> * +specialization<br /> <br /> 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;<br /> <br /> 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.”<br /> <br /> 154<br /> <br /> • Enforcing Modeling Guidelines in an ORDBMS-based UML-Repository<br /> <br /> 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;<br /> <br /> 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 ) ) );<br /> <br /> Ritter & Steiert • 155<br /> <br /> 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);<br /> <br /> 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 );<br /> <br /> 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 ) );<br /> <br /> 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.<br /> <br /> 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<br /> <br /> 156<br /> <br /> • Enforcing Modeling Guidelines in an ORDBMS-based UML-Repository<br /> <br /> 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 <= 1 The resulting SQL constraint is given below: CHECK NOT EXISTS ( SELECT * FROM generalizable_element_ta ge WHERE NOT ( 1 >= ( SELECT count(*) FROM generalization_ta g WHERE ge.id = g.subtype ) ) )<br /> <br /> 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<br /> <br /> 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<br /> <br /> )))<br /> <br /> • 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:<br /> <br /> Ritter & Steiert • 157<br /> <br /> 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) )<br /> <br /> 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.<br /> <br /> 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<br /> <br /> 158<br /> <br /> • Enforcing Modeling Guidelines in an ORDBMS-based UML-Repository<br /> <br /> Figure 2: UML object diagram: “Sample Translation Tree” ForAll : ForAll<br /> <br /> set : set<br /> <br /> predicate : predicate<br /> <br /> SetGE : AllInstances<br /> <br /> Predicate : GreaterEqual para1 : parameter2 para2 : parameter1 1: Integer<br /> <br /> class : class iterator : variable GeneralizableElement : UmlClass<br /> <br /> Size : Size set : set SetG : ProjectionCollectionByAssociationEndNode object : object associationEnd : target Self : VariableNode<br /> <br /> Supertype : UmlAssociationEnd<br /> <br /> Figure 3: UML class diagram “Translation Graph Nodes” 1<br /> <br /> SetNode<br /> <br /> 1<br /> <br /> 0..*<br /> <br /> ForAll<br /> <br /> set<br /> <br /> 1<br /> <br /> predicate<br /> <br /> 1<br /> <br /> 0..1 variable AllInstances<br /> <br /> class<br /> <br /> ProjectionCollectionNode<br /> <br /> PredicateNode<br /> <br /> variable 0..*<br /> <br /> 0..* 1<br /> <br /> 1<br /> <br /> ProjectionCollectionByAssociationEndNode<br /> <br /> UmlClass<br /> <br /> 0..*<br /> <br /> 1<br /> <br /> GreaterEqual<br /> <br /> parameter2<br /> <br /> parameter1 0..* ProjectionCollectionByAttributeNode<br /> <br /> target 1 UmlAttribute<br /> <br /> 1<br /> <br /> ValueNode<br /> <br /> variable<br /> <br /> target<br /> <br /> 0..*<br /> <br /> 1 UmlAssociationEnd<br /> <br /> 0..*<br /> <br /> ObjectNode<br /> <br /> 1<br /> <br /> 1 1<br /> <br /> 0..* ProjectionObjectNode<br /> <br /> VariableNode Integer<br /> <br /> 1 0..*<br /> <br /> target<br /> <br /> ProjectionObjectByAssicioationEndNode<br /> <br /> ProjectionObjectByAttribute<br /> <br /> Size<br /> <br /> 0..* target<br /> <br /> 0..*<br /> <br /> set<br /> <br /> 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<br /> <br /> Ritter & Steiert • 159<br /> <br /> 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$ ) )<br /> <br /> 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.<br /> <br /> 160<br /> <br /> • Enforcing Modeling Guidelines in an ORDBMS-based UML-Repository<br /> <br /> SELECT * FROM $tablename$<br /> <br /> 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<br /> <br /> 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 <= ( SELECT COUNT(*) FROM TABLE ( MULTISET ( SELECT T2.* FROM generalizable_element_ta AS T1, generalization AS T2 WHERE T1.id = T2.subtype AND T1.id = self.id ) ) ) ) )<br /> <br /> Ritter & Steiert • 161<br /> <br /> Compared to the SQL constraint presented in the third section which resulted from a manual mapping of the same OCL constraint, the SQL expression resulting from the algorithm discussed in this section is much more complex. So far, we did not consider any optimization and performance issues, but the SQL constraints created by our compiler seem to be a challenge for every DBMS optimizer. Thus, generation of more efficient SQL constraints will be a major issue of future work. We have to admit that there are some OCL constructs which are difficult to map, e.g., the generic iterator operator. So far, we do not allow to use such operators in OCL constraints. However, we think that the extensibility features of ORDBMS will help us to fix this problem.<br /> <br /> CONCLUSIONS In this chapter, we have reported on our UML repository, which is based on the UML meta-model and manages UML models. The UML repository is implemented by using an ORDBMS. We have taken advantage of the enhanced type system in order to map the UML meta-model to a database schema. Additionally, the examples presented throughout the paper show that the powerful query facilities of an ORDBMS are very helpful for the mapping of OCL constraints to SQL constraints. In contrast to a hard-coded implementation of the class invariants in modeling tools, our approach is much more flexible. It allows to adapt the invariants to the needs of a particular project and its development phases. Some tools offer an extensibility interface and a scripting language, which may be used for this purpose, forcing the modeler to be an expert in yet another programming language. We prefer to use a single language (OCL) for both, tailoring the modeling tools and the modeling itself. In addition, we can take advantage from the ORDBMS optimizer, in order to achieve efficient evaluation of constraints. To the best of our knowledge our approach is the first one taking advantage of the new database technology for the purposes of checking several kinds of constraints. Our approach allows us to use OCL for both checking validity of UML models (invariants specified in OMG (1997b)) and maintaining consistency regarding design guidelines. We have introduced two kinds of design guidelines, global design guidelines and temporary guidelines. In addition, two kinds of OCL constraints related to the modeling process have been examined (pre- and postconditions, design goals). Currently, a compiler which maps OCL constraints to SQL constraints is under development. We have explained the translation algorithm by an example. It is based on a translation graph consisting of translation nodes and meta-data nodes. Each translation node in the graph represents a building block of the algorithm. An SQL constraint is recursively aggregated by expanding SQL templates, whereas<br /> <br /> 162<br /> <br /> • Enforcing Modeling Guidelines in an ORDBMS-based UML-Repository<br /> <br /> the parameters in the template are substituted by SQL fragments provided by subnodes. Choosing the appropriate SQL template and expanding the parameters depends on meta-data, which is provided by meta-data nodes. So far the compiler is limited to class invariants. The next version will also accept pre- and postconditions. Finally, we want to mention that our efforts in mapping UML/OCL to an ORDBMS interface a semantic-preserving way has given us the opportunity to gain lots of experience about UML/ OCL and to learn much about its deficiencies and weaknesses. In addition we expect our approach to provide a foundation for automated model analysis.<br /> <br /> REFERENCES Chen, P. P. (1976). The Entity-Relationship-Model – Towards a Unified View of Data, ACM Transactions on Database Systems, 1(1). Demuth, B., and Hussmann, H. (1999). Using OCL Constraints for Relational Database Design, Proceedings <<UML>>’99, Fort Collins, Colorado. ISO Final Commitee Draft (1999). Database Language SQL, ftp://jerry.ece.umassd.edu/isowg3/ dbl/BASEdocs/public. Linington, P. F. (1999). Options for Expressing ODP Enterprise Communities and Their Policies by Using UML, Proceedings Third International Enterprise Distributed Object Computing Conference (EDOC), Mannheim, Germany, September. Mahnke, W., Ritter, N., and Steiert, H.-P. (1998). Towards Generating Object-Relational Software Engineering Repositories, 8. Fachtagung Datenbanken in Büro, Technik und Wissenschaft, Freiburg, Germany, March. OMG (1997a). UML Notation Guide, Version 1.1, OMG Document ad/97-08-05, September. OMG (1997b). UML Semantics,Version 1.1, OMG Document ad/97-08-04, September. OMG (1997c). Object Constraint Language Specification, Version 1.1, OMG Document ad/ 97-08-08, September. OMG (1997d). OA&D CORBAfacility Interface Definition, Version 1.1, OMG Document ad/ 97-08-09, September. Ritter, N. (1997). DB-based Cooperation Services for Engineering Applications, Ph. D. thesis (in german), ‘infix’-Verlag, Germany. Ritter, N., Steiert, H.-P., Mahnke, W. and Feldmann, R. (1999). An Object-Relational SERepository with Generated Services, Proc. Managing Information Technology Resources in Organizations in the Next Millenium (Computer-Aided Software Engineering Track of IRMA’99), IDEA Group Publ., May. Stonebraker, M., and Brown, P. (1999). Object-Relational DBMSs - Tracking the Next Great Wave, Morgan Kaufmann Publishers Inc., San Francisco. UML Specification (draft), version 1.3 beta R7, ‘http://www.rational.com/uml/resources/documentation/’. Warner, J. and Kleppe, A. (1999). The Object Constraint Language – Precise Modeling with UML, Reading, MA: Addison Wesley Longman, Inc.<br /> <br /> Janssen & Sol • 163<br /> <br /> Chapter 15<br /> <br /> Simulation for Business Engineering of Electronic Markets Marijn Janssen and Henk G. Sol Delft University of Technology, The Netherlands<br /> <br /> Developments in Information and Communication Technology (ICT) enable information systems to intermediate between sellers and buyers in electronic markets (e-markets). A business engineering methodology can be of help to design and develop e-markets by providing insight into current market and potential e-market structures, matching mechanisms and processes, and by evaluating the implications of e-markets. In this chapter, a first concept of an interactive, discrete-event, agent-based simulation approach for the analyses and design of e-markets is presented and evaluated.<br /> <br /> INTRODUCTION As a result of technological developments in the field of ICT e-markets are emerging as the new way of doing business. E-markets can be characterized by the exchange of data, between information systems of buying, selling and other facilitating organizations, over telecommunication networks to accomplish and execute market transactions. The core of e-markets is the coordination of the various interdependent activities performed by autonomous organizations during the information, agreement and settlement phases (Lindemann and Schmid, 1999). Coordination theory provides a multi-disciplinary approach to the study of process (Malone & Crowston, 1994). In a coordination approach the design of processes is dependent on the coordination mechanisms that manages the dependencies between tasks. Previously Published in Challenges of Information Technology Management in the 21st Century, edited by Mehdi Khosrow-Pour, Copyright © 2000, Idea Group Publishing.<br /> <br /> 164<br /> <br /> • Simulation for Business Engineering of Electronic Markets<br /> <br /> Figure 1: Examples of market structures<br /> <br /> E-markets can use a large variety of coordination mechanisms and market structures to coordinate demand and supply, often categorized as cooperative or competitive (Guttman & Maes, 1998). A taxonomy of market structures based on how traders search out their counterparts is shown in Figure 1 (Garbade, 1982). The design and development of e-markets meet with a number of pitfalls and bottlenecks (Janssen, 1998), including: • which mechanisms and structures are most beneficial for which situations is unclear, • lack of insight into the processes of organizations, • unclear implications of coordination mechanisms • uncertainty about the added value of e-markets, • a lack of trust, and • different goals and interests of stakeholders. As a result there is a need for a business engineering methodology that can support the decisions-making processes of organizations by providing insight into, and by evaluating the implications of possible structures and mechanisms. The goal of this chapter is to derive and evaluate a business engineering approach for e-markets.<br /> <br /> Janssen & Sol • 165<br /> <br /> Figure 2: The problem solving process<br /> <br /> BUSINESS ENGINEERING AND SIMULATION A business engineering methodology is a set of guidelines and techniques to design and develop a particular structure. Lee & Clark (1997) conclude that an analysis of e-markets needs to begin with understanding of traditional market processes and should investigate how conventional transaction methods are changed as a result of e-market adoption. Consequently, the approach starts by analyzing the current situation. The approach is based on the problem solving process, that is already used in a number of business engineering studies (Sol, 1992), to handle the design of organizational change that consists of five activities shown in Figure 2 (Sol, 1982). The goals of the business engineering methodology are to give stakeholders insight into current and potential new situations and to evaluate the added value of these situations. As a consequence, a key element in our business engineering process are models, abstractions from and simplifications of reality, that can be used to provide insight into and experiment with, before the actual system is implemented. In this way the performance of the current and possible ‘to be’ situations can be compared. Simulation is an suitable approach for our purposes and can be described as the process of designing a model of a concrete system and conducting experiments with this model to understand the behavior of a concrete system, to evaluate various strategies (within the limits imposed by a criterion or set of criteria) for the operation of the system, and/or to study the impact of scenarios<br /> <br /> 166<br /> <br /> • Simulation for Business Engineering of Electronic Markets<br /> <br /> representing a particular path to a hypothetic future situation (Shannon, 1975). A number of requirements on simulation can be derived based on the distinguished characteristics of e-markets. A large number of autonomous actors commit business with each other in e-markets. These actors can have opposing aims, have their own strategies, can be deliberative or reactive. Furthermore, new actors can enter and existing can leave the market. It, therefore, is necessary to include dynamics and discrete-events, and model the actors as autonomous entities with their own interest and goals. Autonomous, goal driven entities, which are able to communicate with other entities and whose behavior is the consequence of its observations, knowledge and interactions with other entities are often called software agents (Bradshaw, 1997). The situation with more than one agent, each interacting with each other, is often called a Multi-Agent System (MAS) (Nwana, 1996). Many MAS exhibit characteristics of organizations, and sometimes of intentional organization design (Carley, 1999). The implications of actors’ behavior on the performance indicators are a key element in choosing alternative forms of e-markets. The implications on the behavior of the total system are largely dependent on the strategies of the actors and the protocols of the matching mechanisms. The purpose of a model is to reduce the complexity of understanding or interacting with a phenomenon by eliminating the detail that does not influence its relevant behavior (Curtis , Kellner & Over 1992). However, it is necessary to model matching mechanisms as in reality with all their intelligence and behavior to evaluate the implications. In short, actors, coordination structures, and communication networks can be simulated, thus being modeled only as necessary, whereas the matching mechanisms should be emulated. Emulation means that actual software should be written to execute the coordination mechanisms. When roles and processes of actors are difficult to model or when it is important to evaluate the behavior of human decision-makers, humans should be able to play these roles, this is often referred to as interactive simulation. In an interactive simulation environment the players determine the outcomes of the simulation model and can gain experience with the potential situations by interacting with the model. The goal of providing insight requires that animation shows what happened and is happening. In the field of e-markets the participants consider it as a prerequisite to communicate and interact by means of a web-based environment. Each participant has access to the web and most of the participants are only interested when there is a fast interaction from their workplace with the simulation environment.<br /> <br /> CASE STUDY:TRANSPORTATION MARKET To test the before mentioned concepts in a case study, a prototype was imple-<br /> <br /> Janssen & Sol • 167<br /> <br /> mented in the Java programming language. The transportation industry was chosen for the empirical testing of the concepts, because transportation providers and requesters were willing to cooperate, and there was much discussion about the usefulness of e-markets. The core of this case is the interaction between the demand of transport requesters for and supply of providers of transportation capacity. Intermediaries, shippers or consignees, can take care of transportation on behalf of a transport requester. In a general sense, this sector can be characterized by a large number of small transport providers, a small number of large transport providers, heterogeneous demand, untransparency of demand and supply, and competition mainly based on price. The matching of demand and supply of transport capacity is a cumbersome and labor intensive process. Due to the untransparency of demand and supply, the utilization of the transport capacity is low; there are many runs with a limited capacity utilization and most of the runs back are without any load. Price-competition force organizations to cut their expenses. Especially small organizations are forced to cooperate with each other. First the conceptual and empirical “as is” models were build. On the basis of these models, two alternatives were identified: a centralized allocation broker using the contract-net protocol, and an auctioneer to sell and buy capacity. In the first alternative the organizations represent themselves as one entity to the outside world with the help of a central intermediary. Transport requesters send their requests to this intermediary. The intermediary advertises the capacity request to the transport providers, who in turn determine bids, based on the expected future utilization of their capacity. The intermediary sends the best bid to the transport requester, who can decide to accept or reject the bid. The second alternative is based on the introduction of an electronic auction to match supply and demand. Within this alternative a number of auction protocols were evaluated. Both alternatives were modeled and the interactive simulation aspect made it possible for the involved actors to gain experience with the various auction protocols. The auctioneer was rejected, because the simulation showed that coalitions of buyers, trading alliances, came into existence that decreased the price of transportation capacity. The insight provided by the model resulted in the generation of a third alternative, shown in Figure 3: an auctioneer to sell only the remaining capacity and an allocation broker to allocate the demand. The actors decided that the allocation broker and transport providers were only allowed to make use of one uniform bidding strategy, because of the danger of allocating capacity unfairly over the market participants.<br /> <br /> 168<br /> <br /> • Simulation for Business Engineering of Electronic Markets<br /> <br /> CONCLUSIONS AND FURTHER RESEARCH A preliminary report of ongoing research to come to a business engineering methodology for the design of e-markets has been presented in this paper. Based on the distinguished characteristics of e-markets requirements on modeling were identified. Based on these requirements a prototype was implemented. This prototype was tested in a case study as part of a business engineering methodology. The derived modeling approach can be considered as useful to increase the insight into current and potential markets and to evaluate the added value. Emarkets can be modeled with the help of a discrete-event, interactive, agentbased simulation environment that makes use of emulated mechanisms. The emulation of market mechanisms and interactive aspects can be seen as essential to evaluate the effects of matching mechanisms. The simulation approach provides a tool to support the business engineering of e-markets. Further research will focus on the incorporation of a larger variety of roles for e-markets, such as trusted third parties and payment services, and on the adding of more advanced matching mechanisms. These concepts will be further tested in a number of case studies.<br /> <br /> REFERENCES Bradshaw, J.M. (1997). Software Agents, AAAI Press/The MIT Press, Menlo Park, CA. Carley, K.M. & Gasser, L. (1999). Computational Organization Theory. In Weiss, G. (Ed.), Multiagent Systems: a modern approach to distributed artificial intelligence. Massachusetts Institute of Technology. Curtis, B., Kellner, M.I. & Over, J. (1992). Process Modeling. Communications of the ACM, 35(9), pp. 75-90. Garbade, K. (1982). Securities Markets, New York: McGraw-Hill. Guttman, R. and Maes, P. (1998). Cooperative vs. Competitive Multi-Agent Negotiations in Retail Electronic Commerce. Proceedings of the Second International Workshop on Cooperative Information Agents (CIA’98). Paris, France, July. Janssen, M. (1998). Towards a Business Systems Engineering Methodology for E-commerce. In Doukidis, G.J., Grièar, J. & Novak, J (Eds.), Proceedings of the eleventh international Bled electronic commerce conference “Electronic Commerce in the Information Society,” Bled, Slovenia, June 8-10, pp. 610-623. Lee, H.G. & Clark, T.H. (1997). Market Process Reengineering through Electronic Market Systems: Opportunities and Challenges, Journal of Management Information Systems, 3, pp. 113-136. Lindemann, M.A. & Schmid, B.F. (1998). Framework for Specifying, Building,<br /> <br /> Janssen & Sol • 169<br /> <br /> and Operating Electronic Markets. International Journal of Electronic Commerce, 3(2), pp. 7-21. Malone, T.W. & Crowston, K. (1994). The Interdisciplinary Study of Coordination, ACM Computing Surveys, 26, pp. 87-119. Nwana, H.S. (1996). Software Agents: An Overview. Knowledge Engineering Review. 11(3), pp. 205-244. Shannon, R.E. (1975). Systems Simulation: The art and science. Englewood Cliffs: Prentice Hall. Sol, H.G. (1982). Simulation in Information Systems Development. Doctoral Dissertation, University of Groningen, Groningen, The Netherlands. Sol, H.G. (1992). Shifting Boundaries in Systems Engineering and Policy Analysis. Inaugural address, Delft University of Technology, Delft, The Netherlands.<br /> <br /> 170<br /> <br /> • Scenarios within Information Systems Modeling<br /> <br /> Chapter 16<br /> <br /> Representing and Reasoning with Scenarios within Information Systems Modeling Choong-ho Yi Swedish Defence Research Agency (FOI), Sweden<br /> <br /> INTRODUCTION Recent research in systems engineering shows the community’s interest in scenarios. Advantages of using scenarios have been reported in wide range of contexts within the area. Recalling that any systematic, and eventually, automated management of scenarios presupposes firm formal ground, research on formal theories for scenarios is highly motivated. However, only little work has been reported for that purpose, e.g. Hsia, Samuel, Gao, Kung, Toyoshina and Chen (1994). This chapter presents a formal approach to managing scenarios, using first order temporal logic extended with basic set theory, in the context of information systems modelling (ISM). In our framework scenarios are dealt with from two formal points of view, namely representation and reasoning. Representation of scenarios: An information system (IS) is defined as a structure of object schema, actions, time and scenarios where each component of the structure is motivated to capture different aspects of the system, i.e., the static, the dynamic and the temporal aspect respectively, and scenarios are, roughly, “compounded” of the three components. Then formal semantics has been given to the components and other concepts associated with them, e.g., state and change. The in-built semantics of usual relationship diagrams, e.g., Entity-Relationship diagram (Chen, 1976), have been strengthened and formalised into basic predicates Previously Published in Challenges of Information Technology Management in the 21st Century, edited by Mehdi Khosrow-Pour, Copyright © 2000, Idea Group Publishing.<br /> <br /> Yi • 171<br /> <br /> and functions which are used to express relationships between object types in logical formulae. The set of these formulae constitute an object schema. A state is defined on the basis of object schema, i.e., as an instance of object schema, and it describes the “snapshot” of the system at a moment of time. The static aspects, however, will not be presented in the paper for space reason. We approach scenarios mainly in terms of actions, and so semantics of actions is of immediate importance in discussing scenarios. Actions describe the dynamic part of an IS such that system state is changed by the effects of actions. In order to represent action duration with varying length effectively we use time explicitly and associate each action occurrence with start and end time. Further each action is provided with, in addition to the objects that are involved in the action, two categories of agents participating in the action, i.e., the initiator and the receiver. The agents pair is used to represent communications between multiple agents, and to trace capabilities and responsibilities of the agents concerning the action. A scenario is then defined as a pair of action occurrences set (describing what to do) and constraints set (how to do these actions). Some constraints are imposed on individual actions concerning, e.g., possible duration of the actions, or agents and other kinds of objects involved in the actions (e.g., when ordering a product, certain supplier is preferred to other suppliers and the price of the product should not be higher than certain level), and so on. At the same time constraints may be related to over several actions as well, e.g., performance order of the actions. Scenarios represented as such, using the whole expressive power of actions in combination with constraints, enjoy rich expressiveness and flexibility, and are suitable for, e.g., modelling various kinds of business processes or business policies (e.g., if a product is ordered by a special customer, then deliver a product within X time units after the order) in realistic environments. Reasoning with scenarios: One of major benefits of formally representing scenarios is that it serves as base for formal reasoning with scenarios in various ways, e.g., prediction of future, simulation and evaluation of possible trajectories of the scenarios. Though several formal approaches have been proposed within ISM, they were mainly designed for representation and the connection to the phase of reasoning has not been studied enough. Consequently, reasoning is still, more or less, unfamiliar in that area. This chapter proposes “such a connection” and shows how reasoning, though straight, in the form of prediction for a given scenario, can be made in our framework based on the semantics introduced for the representation part.<br /> <br /> ACTIONS: THE DYNAMIC PART Actions describe the dynamic part of the system. Each action is provided with, in addition to the objects which are involved in the action, two categories of<br /> <br /> 172<br /> <br /> • Scenarios within Information Systems Modeling<br /> <br /> agents participating in the action, i.e., the initiator and the receiver. For example, the action statement ordering((c1, s5), p1) is intended to express that customer c1 orders product p1 from supplier s5. The agents pair is used to represent communications between multiple agents, and to trace capabilities and responsibilities of the agents concerning the action. In case both agents are not necessary, we use the constant “none,” e.g., eat ((peter, none), cake). Three more actions to be used are as follows with different variable symbols for different object types, i.e. Cu is used for customer; Su supplier; P product; I item, and A for amount: supplying((Su, Cu), I): Su supplies Cu with an I; invoicing((Su, Cu), I, A): Su sends an invoice to Cu concerning the supplied I with A; paying((Cu, Su), I, A): Cu pays A for I to Su. The predicates precond(A, C1) and postcond(A, C2) express that the precondition and the postcondition, i.e., effects, of the action A is C1 respectively C2. For example, the precondition of ordering((Cu, Su), P) is: Cu is a customer; Su is a supplier; P is a product; ÿ((Cu, Su, P)Œorder), where (Cu, Su, P)Œorder means that P has been ordered from Su by Cu and that this order is in the process of being completed. ∀ Cu∀ Su∀ P precond(ordering((Cu, Su), P), { CuŒcustomer, Su∈supplier, P∈product, ¬((Cu, Su, P) ∈order) }) ∀Cu∀ Su∀ P postcond(ordering((Cu, Su), P), {(Cu, Su, P) ∈order})<br /> <br /> TIME, ACTION DURATION, STATE UPDATES AND HISTORY The predicate occur(A, T1, T2) expresses that the action A, e.g. ordering((c1, s5), p1), occurs over the period T1 (start time point) to T2 (end time point) where T1<T2. If an action is evoked in a state which satisfies its precondition, then the action will be performed successfully, and this results in changing the state of the system. On the other hand, if the precondition does not hold in the start state, the action can not be completed and the system state is not changed. Definition: Let S be a state and let postcond(A, C) be given for an arbitrary action A, then the state update function (S  C) returns a new state which results from updating S by C such that the property for an object to belong to a set is changed according to C if it is defined there, but remains as in S otherwise. n<br /> <br /> Yi • 173<br /> <br /> Definition: Let T be time domain {0, 1, 2, 3, …}, and let S be an initial state. As time passes, the now time n advances from 0 with one unit successively and, accordingly, the history H is defined for every n such that H(n)= S if n =0; =(H(T) ÷ C) if, for some 0<=T< n, occur(A, T, n), precond(A, C’), C’ ⊆ H(T), and postcond(A, C); = H(n-1) otherwise. Therefore, H is a function from {0, …, n} to states domain S. n So, as time elapses, history of an IS is extended for successive time points according to what happens in the system. The state of a system at now time will be called the current state.<br /> <br /> SCENARIOS<br /> <br /> U<br /> <br /> A scenarios is “compounded” of states, actions and time. Scenarios are motivated to represent some aspects of a system, e.g. business processes or goals, which are of importance and need to be formulated separately, but can not be expressed merely by some action or by a series of actions in a fixed order. A scenario consists of a set of action occurrences occur(A, T, T’) which addresses what to do, and a set of static and/or temporal constraints on the action occurrences which describes how to do these actions. For example, the scenario satisfy_customer({ occur(ordering((Cu, Su), P), T1, T1’), occur(supplying((Su, Cu), I), T2, T2’)}, { T1’<T2, H(T1’) (Cu privileged_customer) → T2’<=T1’+7 }) is intended to state that two actions, ordering and supplying, occur in such a way that ordering precedes supplying (the end time T1’ of ordering is less than start time T2 of supplying), and that if Cu is a privileged customer when the order is completed, then the ordered product is to be delivered within 7 time units after order. So the scenario satisfy_customer can be understood as a goal of a company to satisfy its special customers by minimum delivery time 7. A set of action occurrences of a scenario which satisfies the constraints on it is an instance of the scenario. The following set of action occurrences {occur(ordering((c2, s6), p1), 1, 3), occur(supplying((s6, c2), i2), 5, 9)} is an instance of the scenario satisfy_customer, provided that c2Œprivileged_customer holds in the state H(3). Given a scenario and an initial state for it, none, one or many scenario instances may exist for the scenario. Scenarios represented as such, using the whole expressive power of actions in combination with constraints, provide rich expressiveness and flexibility. Moreover, scenarios contribute to the modularity of a system as subprograms do in a pro-<br /> <br /> 174<br /> <br /> • Scenarios within Information Systems Modeling<br /> <br /> gram. For example, instead of enumerating action occurrence statements and constraints of the scenario satisfy_customer as individual axioms, they have been formulated into a separate meaningful unit, and the scenario can be “evoked” repeatedly at need for different purposes, e.g. for representing some (part of) complicated processes or goals in realistic environments.<br /> <br /> REASONING WITH SCENARIOS It may be argued that one of ultimate goals of computerising ISs is automation. Several kinds of formal reasoning play an important role in this context. Formal reasoning in its turn presupposes formal representation as a ground for it. Though several formal approaches, e.g. Dubois, Hagelstein and Rifaut (1988) and Hartel, Denker, Kowsari, Krone and Ehrich (1997), have been proposed within ISM, they were mainly designed for representation and the connection to the phase of reasoning has not been studied enough. Consequently, reasoning with ISs is still, more or less, unfamiliar in that area. In this section we show “such a connection,” i.e., how reasoning, though straight, in the form of prediction for a given scenario, can be made in our framework based on the semantics introduced for the representation part. For space reason, only the main ideas are outlined. Given a scenario, e.g., basic_transaction( {occur(ordering((Cu, Su), P), T1, T1’), occur(supplying((Su, Cu), I), T2, T2’), occur(invoicing((Su, Cu), I, A), T3, T3’), occur(paying((Cu, Su), I, A), T4, T4’) }, { T1’<T2, T1’<T3, T2’<T4, T3’<T4, T4’-T3’+30} ).<br /> <br /> an initial state S, i.e. H(0)= S, e.g. {product = {p1, p2, p3}, item = {i1, …, i6}, Item_ product = {(i1, p3), (i2, p1), (i3, p2), (i4, p3), (i5, p1), (i6, p1)}, product_price = {(p1, $7), ..}, customer = {c2, c5}, supplier = {s3, s6}, customer_item = {(c5, i4)}, supplier_item = {(s3, i3), (s3, i6), (s6, i1), (s6, i2), (s6, i5)}, order = ∠, supply = ∠, invoice = ∠, payment = ∠ }<br /> <br /> U<br /> <br /> S<br /> <br /> and an instance of the scenario { occur(ordering((c2, s6), p1), 1, 3), occur(supplying((s6, c2), i2), 5, 9), occur(invoicing((s6, c2), i2, $7), 10, 11), occur(paying((c2, s6), i2, $7), 12, 13) }.<br /> <br /> Using previous definitions this scenario instance may be reasoned, extending the history accordingly. We simply establish that all of the actions scheduled in the scenario instance will be performed successfully, and the initial state S has been updated accordingly into the final state at time point 13. In this state order, supply and invoice are reset to empty set as in the initial state S, which implies that there is no unfinished or ongoing activity. On the other hand, the item i2 has changed ownership to c2 and a new payment (c2, s6, i2, $7) is registered in payment.<br /> <br /> Yi • 175<br /> <br /> REFERENCES Chen, P. P. (1976). The Entity-Relationship Model – Toward a Unified View of Data. ACM Trans. Database Sys., 1(1), pp. 9-38. Dubois, E., Hagelstein, J., and Rifaut, A. (1988). Formal requirements Engineering with ERAE. Philips Journal of Research, 43, pp. 393-414. Hartel, P., Denker, G., Kowsari, M., Krone, M. and Ehrich, H. (1997). Information Systems Modelling with Troll Formal Methods at Work. Information Systems, 22, pp. 79-99. Hsia, P., Samuel, J., Gao, J., Kung, D., Toyoshima, Y., and Chen, C. (1994). Formal Approach to Scenario Analysis. IEEE Software, 11(2), pp. 33-41. Martin, J., and Odell, J. J. (1996). Object-Oriented Methods: Pragmatic Considerations. New Jersey: Prentice-Hall. Sandewall, E. (1994). Features and Fluents, A Systematic Approach to the Representation of Knowledge about Dynamical Systems, Oxford University Press. Yi, C. (1995). Towards the Assessment of Logics for Concurrent Action. AAAI Spring Symposium: Extending Theories of Action, Stanford University, March.<br /> <br /> 176 • From Object-Oriented Modeling to Agent-Oriented Modeling<br /> <br /> Chapter 17<br /> <br /> From Object-Oriented Modeling to Agent-Oriented Modeling: An Electronic Commerce Application Sooyong Park Sogang University, Korea Vijayan Sugumaran Oakland University, USA<br /> <br /> The use of intelligent agents is on the rise, fueled by the unprecedented growth in the internet and web based applications. Consequently, agent-oriented software is becoming large and complex. To support a systematic development of such software, an agent-oriented software development methodology is necessary. This chapter focuses on the modeling phase of agent-oriented software life cycle and, presents an approach for agent modeling consisting of Agent Elicitation, Intra, and Inter Agent modeling methods. Agent Elicitation deals with identifying and extracting agents from “classes” in the real world. Intra Agent Modeling involves expressing agent characteristics æ Goal, Belief, Plan and Capability æ whereas, Inter Agent modeling incorporates agent mobility and communication in a multi- agent system.<br /> <br /> INTRODUCTION As software applications get large and complex, very sophisticated environments are needed to support and execute heterogeneous and distributed real-time Previously Published in Challenges of Information Technology Management in the 21st Century, edited by Mehdi Khosrow-Pour, Copyright © 2000, Idea Group Publishing.<br /> <br /> Park & Sugumaran • 177<br /> <br /> applications. To manage this complexity, intelligent agent technology is beginning to be employed as part of the solution in various software environments (Woolridge, Jennings and Kinny, 1999). Since its introduction in the AI community, agent technology has permeated to various other applications such as e-mail filtering, Airtraffic Control etc (Jennings, Sycara and Wooldridge, 1998). Moreover, in distributed and heterogeneous environments such as Electronic Commerce (EC) applications, intelligent agents are increasingly utilized to perform various tasks. Since agents are used in many application areas, a systematic approach that is grounded within the software engineering paradigm is highly important for the development of agent-oriented software. However, there has not been enough research on this subject in the Software Engineering Community. To develop agent-oriented software, we introduce a process model, which is an adaptation of the traditional Waterfall model and contains the following major activities: a) domain analysis - problem domain understanding and modeling, and agent identification, b) agent modeling - intra-agent and inter-agent modeling, c) agent design - agent architecture and componentization, d) agent implementation – implementing the agents using appropriate agent building tools and agent communication languages, e) agent integration – integration of multi-agents and other components, and f) verification and validation – testing and simulation of the agent functionalities. Based on our agent-oriented software process model, this paper focuses on the initial phases of the model, namely, domain analysis which includes problem domain modeling and agent identification, and agent modeling which includes intra and inter agent modeling. We believe that the real world consists of agents and objects, and an agent is similar to an Active object (Jennings et al., 1998) or a distributed object (Schroeder, 1999). In our agent-oriented process model, we obtain objects from problem domain analysis using UML (Unified Modeling Language) (Rao and Georgeff, 1991; Wooldridge, 1997), then, extract and create agents from these objects using agent selection rules. Typically, the agent modeling activity consists of two parts: intra agent modeling and inter agent modeling. The former focuses on agent’s attributes and behaviors resulting in an “Intra Agent Model”, whereas the latter concentrates on agent communication (message exchanges) and mobility, yielding an “Inter Agent Model.” The remainder of the chapter is organized as follows. The next section briefly discusses agent characteristics and modeling methods. The third section describes the first two phases of our lifecycle model, namely, domain analysis and agent modeling. Specifically, the UML based problem domain analysis, as well as the<br /> <br /> 178 • From Object-Oriented Modeling to Agent-Oriented Modeling<br /> <br /> agent elicitation process based on Agent Selection Rules is described. This section also discusses the intra-agent and inter-agent modeling. As a proof of concept, we have applied our approach to a simple agent based application in the electronic commerce domain, which is presented in the fourth section. The final section provides summary and future research.<br /> <br /> AGENT PROPERTIES AND AGENT MODELING METHODS The concept of agent was introduced by John McCarthy in the mid-1950’s and established by Oliver G. Selfridge several years later (Thomas, 1993; IMBC Lab for Advanced Information Technology). In the early years, though many researchers investigated different aspects of the agent technology, it was still not considered as main stream research within the AI community. However, since the late 80’s, there has been a resurgence of interest in agent technology, and currently we are seeing a proliferation of agent-based applications, particularly on the Web. Though several characteristics of agents have been discussed in the literature (Jennings et al., 1998; Nwana, 1996), we assume that agents exhibit the following three important properties in our modeling approach. Autonomy – an agent can make decisions about what to do based on its own state, without the direct intervention of humans. Adaptation – an agent can perceive its environment, and respond to changes in the environment in a timely fashion. Cooperation – an agent can interact with other agents through a particular agentcommunication language, and typically has the ability to engage in collaborative activities to achieve its goal. Much of the agent modeling work reported in the literature has been in the context of conceptualization of complex systems that make use of Agents. RaoGeorgeff’s BDI (Belief-Desire-Intention) model (1991) is regarded as one of the relatively successful Agent models. Based on this DBI model, Kinney proposed a design methodology to develop MAS (Multi Agent System) extending OMT (Kinny, Georgeff and Rao, 1996). He proposed two main views of BDI agent modeling: internal and external view. These views incorporate typical ObjectOriented (OO) concepts such as Abstraction, Inheritance and Modularity. Burmeister (1996) describes an Agent-Oriented (AO) methodology, which also extends OO techniques and generates an agent model, an organizational model and a cooperation model. Recently, Falchuk and Karmouch proposed a modeling methodology called Visual Agent Modeling (Falchuk and Karmouch, 1998), which incorporates the mobility and communication between agents. They define various elements of an agent’s active environment, such as agent, server, data, document, etc., with 26 icons. With the help of their Iconic Modeling Tool (IMT), users<br /> <br /> Park & Sugumaran • 179<br /> <br /> can visualize and model mobile agents and their itineraries. While their visual modeling approach focuses on the agent environment and the interaction between agents, it fails to adequately support the modeling of the internal aspects and behavior of the agents. Some of the agent modeling methods mentioned above use object-oriented analysis and design techniques for modeling agents. While the OO techniques may be a good starting point, they are incapable of distinguishing between objects and agents. Consequently, there is lack of definite classification scheme for agent artifacts and object artifacts in the system analysis procedure. To model static agents and mobile agents in a multi agent environment, a unified modeling method is needed (Woolridge et al., 1999). Therefore, our research suggests a new agent oriented modeling methodology to provide an integrated and unified modeling approach.<br /> <br /> AGENT - ORIENTED MODELING METHOD In proposing an agent-oriented approach to modeling a real world application domain, we assume that agents in that domain have the following characteristics: • Objects and agents can co-exist, and have mutual relationships. • An active object can be regarded as an agent (Jennings et al., 1998). • Agents act asynchronously. • Interactions among agents take place through message exchanging. Based on the above assumptions, we propose an agent-oriented modeling process, as depicted in Figure 1. This modeling process consists of the following four steps: (a) UML based Problem Domain Analysis, (b) Agent Elicitation, (c) Intra Agent Modeling, and (d) Inter Agent Modeling. UML based Object-Oriented Analysis Method is used for the problem domain analysis. UML facilitates deep understanding of the problem domain with static and dynamic aspects of the Figure 1: Agent – Oriented Modeling Process • €Use Case Diagram • €Sequence Diagram • €Class Diagram<br /> <br /> Problem Domain Analysis Analysis with UML With UML Agent Selection Agent Selection Rules Rules<br /> <br /> • €Agent – Class Diagram<br /> <br /> Agent Elicitation Intra-Agent Elicitation<br /> <br /> • €Goal Hierarchy Diagram • €Belief Ontology • €Plan Diagram<br /> <br /> Inter-Agent Elicitation<br /> <br /> • €Agent Mobility Model • €Agent Communication Model<br /> <br /> 180 • From Object-Oriented Modeling to Agent-Oriented Modeling<br /> <br /> Table 1: Agent Selection Rules 1.Autonomy 1.1 Does it need internal knowledge? 1.2 Does it make decision by itself? 1.3 Can it be tolerant of unexpected, or wrong inputs? 2.Adaptation 2.1 Does it need internal knowledge? 2.2 Is its knowledge updated continuously? 2.3 Does it interact with external entities? 3.Cooperation 3.1 Does it interact with external entities? 3.1.1 Does it operate cooperatively? 3.1.2 Is it operated in multi-threaded style?<br /> <br /> system. After analyzing the problem domain, objects that can be “agentified,” as well as the agents that need to be added are determined by agent selection rules, shown in Table 1. These objects and agents derived from the domain analysis are assimilated and represented in an Agent-Class Diagram, which depicts the relationships between the various objects and agents. Once agents are identified, their internal characteristics are captured in the intra-agent modeling step. The interagent modeling step involves developing agent mobility model, and agent communication model. Problem Domain Analysis with UML For the problem domain analysis, UML based approach is used. With UML (Rao et al., 1991; Wooldridge, 1997), not only static, but also dynamic aspects of system can be analyzed and agent elicitation can be conducted. Diagrams used in problem domain analysis are given below. 1. UseCase Diagram: A UseCase diagram shows a set of use cases and actors and their relationships. It supports the behavior of a system by modeling static aspects of a system. 2. Sequence Diagram: Sequence diagram shows interaction, consisting of a set of objects and their relationships, emphasizing time ordering of messages. It models dynamic aspects of a system. 3. Class Diagram: It shows a set of classes, interfaces, collaborations and their relationships. It addresses the static design view of a system, showing a collection of declarative elements. 4. Activity Diagram: Activity diagram shows the flow from activity to activity. Activities ultimately result in an action, which is made up of executable atomic computations that result in a change in state of the system, or the return of a value. It is used to depict dynamic aspects of a system in terms of its functions.<br /> <br /> Park & Sugumaran • 181<br /> <br /> Agent Elicitation Considering the static and dynamic aspects of a system, objects that need to be “agentified” are determined by applying Agent Selection Rules, which are closely related to the Agent’s characteristics. Nwana (1996) suggests that agents can be classified into 4 groups: smart agent, collaborative learning agent, collaborative agent, and interface agent. Elicited agents are also classified as mobile agents and general agents (stationary agent), based on the mobility of agents. Agents derived using agent selection rules, as well as the objects remaining in the class diagram are consolidated and represented in the Agent-Class diagram. Agent-Class Diagram Based on the assumption that objects and agents can exist together in the real world, the Agent-Class diagram shows the relationships among agents and objects in the target problem domain. The notion we use in expressing the different elements within the Agent-Class diagram is shown below: Element • A : Agent without mobility • M : Mobile agent • Class : Established classes<br /> <br /> Relation • Cooperation ( ): shows the relationships between agents, meaning that cooperation is needed among them. • Employ ( E ): shows the relationships between agents and classes, meaning that agents can use established classes<br /> <br /> Intra-Agent Modeling The Intra agent modeling approach proposed in our methodology is based on the BDI model (Rao et al., 1991), and Reticular Agent Mental Models (Kinny et al., 1996) proposed by Thomas. We propose that the internals of an agent consists of the following four parts: goal, belief, plan, and capability. Figure 2 shows Figure 2: Abstract view of Intra agent model A Goal Belief Plan Capability<br /> <br /> 182 • From Object-Oriented Modeling to Agent-Oriented Modeling<br /> <br /> an abstract view of the Intra agent model, comprising of the above mentioned components. Goal Model Goal is an ultimate objective of an agent to be achieved (Dardenne, 1993). In KAOS (Burmeister, 1996)’s approach, goals are identified in the problem domain analysis. A goal can be expressed as Pattern_of_Goal [objective], and it can be categorized into five groups: Achieve, Cease, Maintain, Avoid, and Optimize. Goal hierarchy shows cooperation among agents corresponding to each goal, depending upon the Goal structure. The notations used in the Goal hierarchy diagram are given below: Element • Nonfunctional Goal: an objective achieved by the entire system • Operationalizable Goal: a functional objective achieved by agents Relation • AND ( A ): Every sub-goal should be satisfied to achieve the parent goal • OR ( A ): One or more sub-goals should be satisfied to achieve the parent goal • Conflict ( ): shows whether a particular goal conflicts with other goals Belief Model Belief is considered to be data that an agent already possesses. It contains information about the environment and the agent itself. This data should be updated if necessary. This information is used to establish the agent’s knowledge base, or Ontology, which can be built using Ontolingua (Gruber, 1993) or KIF (Knowledge Interchange Format) (Kim, Kim, Park, Lee and Park, 1999). The rules that determine what kinds of information goes into different ontologies are listed below. 1. Ontology that can be established in the early stage • Information about Protocol or ACL (Agent Communication Language) for the agent’s communication can be established as Ontology in the early stage. 2. Ontology that needs to update continuously • Attributes and operations in Class diagram can be established as ontology. • Messages among objects in Sequence diagram can be established as ontology. • Agent’s information that needs to be built as a knowledge base is used as ontology.<br /> <br /> Park & Sugumaran • 183<br /> <br /> Plan Model Plan shows agent’s behavior to achieve a goal. It focuses on agent’s behavior changes as time goes on, and shows messages exchanged among agents. Based on the analysis of dynamic aspects of the system, each agent can determine its own behavior, referencing its goal and belief. Agent plan sequence diagram, which extends an established Sequence diagram, represents agent’s behaviors. The agent plan model uses the following primitives: • Mobile(Goal[Objective]): the agent with its goal tends to migrate to other domains • Update(Belief[Type_of_ontology]): the agent updates its ontology corresponding to its information • employ: the agent uses classes • msg[message_context]: message that is exchanged between agents Capability Model An agent’s capability is the set of operations that it can perform. It explains the agent’s internal changes from inputs and outputs. The agent capabilities are represented by using a DFD (Data Flow Diagram), as shown in Figure 3.<br /> <br /> Agent’s Function<br /> <br /> ▼<br /> <br /> Receive<br /> <br /> ▼<br /> <br /> Figure 3: General Form of Agent’s Capability<br /> <br /> Response Message<br /> <br /> Inter-Agent Modeling Agent’s mobility and exchange of messages among agents in multi agent systems are modeled in the Intra agent modeling process. This results in two different types of models: Agent Mobility Model and Agent Communication Model. Agent Mobility Model The Agent Mobility Model shows how an agent migrates to perform a specific task. It also shows mechanisms that determine the destination that the mobile agent migrates to, i.e., the basis of mobile agent migration and which host the agent will move to. Since we cannot tell how the agent decides its destination from the external viewpoint, agent’s internal view (the mental state) is needed to know the agent’s decision mechanism.<br /> <br /> 184 • From Object-Oriented Modeling to Agent-Oriented Modeling<br /> <br /> Agent Communication Model The Agent Communication Model shows exchanging of messages among agents. It shows which agent communicates with what other agents, and which message format is used for the communication. It also shows what information is included in the messages and which process is needed to create those messages.<br /> <br /> AN EXAMPLE FROM ELECTRONIC COMMERCE (EC) DOMAIN In this section, we apply our modeling approach to the electronic commerce domain. We start with the explanation of the problem domain and a sample scenario, and show how we apply our agent modeling methodology to generate an agent-based solution for this problem. Problem Scenario Let us consider a very simple electronic commerce application in which the user is attempting to purchase a component. Let us also assume that in this EC application domain, there are four servers connected to a network. Two hosts are operating on Windows 98, one on Windows NT, and one on Solaris. Each host has a database that contains information regarding products and components of a PC. We employ Mobile agents to help us find the best information regarding PCs and its components and then place an order and carry out a transaction. Figure 4 Figure 4: System Diagram for Problem Domain<br /> <br /> Table 2: Sample problem Scenario A User intends to purchase components of a PC through the Internet. The user enters the name of the component, to an Agent. Agent migrates to search for the information related to that item. Agent compares the information obtained from different sources. Agent sends the information to the user and asks whether to place an order for that item. If User A wants to order, Agent processes the transaction.<br /> <br /> Park & Sugumaran • 185<br /> <br /> depicts an abstract view of the whole system. The details of a particular scenario in which the user interacts with agents to specify what he/she wants and then places an order based on the information gathered by the agents is shown in Table 2. UML based Agent Elicitation In applying our modeling approach, we first perform the EC problem domain analysis, which results in a UseCase, Sequence, Class, and Activity Diagrams. Then we apply the Agent Selection Rules to identify and extract relevant agents. Finally, we produce Agent-Class Diagram. UseCase Diagram There are four actors in our example: a) the user who enters the information, b) the company which has the actual product, c) company’s databases which have the information about the products, and d) the bank which can check the user validation. There also three usecases, namely, Display usecase which captures the communication with customers, Search usecase which finds the information about products, and Order usecase which processes the order. Figure 5 shows the UseCase Diagram applicable to our example domain. Sequence Diagram For each usecase, we produce a Sequence diagram. Figure 6 shows the Sequence Diagram related to the Search usecase, which performs the main tasks. Figure 5: UseCase Diagram for Problem Domain<br /> <br /> 186 • From Object-Oriented Modeling to Agent-Oriented Modeling<br /> <br /> Figure 6: Sequence Diagram for Problem Domain<br /> <br /> Class Diagram and Activity Diagram The Class and Activity diagrams are generated by extracting objects from the Sequence Diagram and the Activity Diagram. The static and dynamic aspects of objects are represented by the attributes and operations of the object. For the EC application, we derive the following objects. The interface aspect is captured in the Main Display, Search Display, and Order Display objects. The system aspects are incorporated in ProductInfo Seeker, Solution Finder, Validation Checker, and Order Process objects. Agent Elicitation and Agent-Class Diagram By applying Agent Selection Rules to the UML based diagrams, we determine objects that can be “agentified” and also identify additional agents that need to be Table 3: Elicited Agents From Agent Selection Rule Interface Agent: Communicating with the user, the Agent understands his/her intentions and exchanges messages with Product Info Seeker Agent to get the information (Rule 2, 3, 4, 5 are applied). Product Info Seeker Agent: As performing the main role, the agent moves to databases and finds product information, checks the user validation, and processes the ordering. This agent is applied to the distributed environment and it cooperates with other agents. Furthermore, it should be able to update itself continuously(Rule 1, 3, 4, 5, 6 are applied). Coordinator Agent: Perceiving the external environment, if there is any change, the agent should update its internal knowledge and provides the route to the Product Info Seeker agent. This is the new agent that helps to perform agent’s mobility efficiently (Rule 1, 2, 3, 4, 5 are applied). Solution Finder Agent: From the information the Product Info Seeker Agent has found, Solution Finder Agent determines the best result (Rule 2, 3, 5 are applied).<br /> <br /> Park & Sugumaran • 187<br /> <br /> Table 4: Goal Modeling of Each Agent Interface Agent: Achieve[Interaction With User] - It serves successful results to the user, interacting with him/her efficiently Product Info Seeker Agent: Achieve[Find Product Info] – It searches the product information successfully Solution Finder Agent: Achieve[Find the Best Solution] – It finds out the best one from the product information that Product Info Seeker Agent has found Coordinator Agent: Maintain[External Interaction] – It perceives external environment and maintains its information<br /> <br /> added. If one or more classes contribute towards the same agent, we represent them in one group. From the Class diagram and Activity diagram for the current EC application, we derive three Agents (Interface Agent, Product Info Seeker Agent, and Solution Finder Agent) and one additional agent (Coordinator Agent). Table 3 shows the functionalities of each of these agents. Based on the identified agents, we next develop the agent-class diagram, which shows how the agents relate to each other and what other classes that they make use of in carrying out their tasks. Mobile agents, for example, Product Info Seeker Agent, are indicated with the M notation to represent its mobile characteristics. Intra Agent Modeling In this section we present the modeling of the internals of the agent, namely, the Intra Agent modeling process. This step involves capturing and representing the goal, belief, plan, and capabilities of the agents. Goal Modeling Every agent has a goal and performs one or more tasks to achieve its goal. In our example domain, the four agents that we have identified have their own set of goals, as shown in Table 4. To achieve its goal, each agent has several sub-goals that should be satisfied. Figure 7 shows the Goal-hierarchy diagram for the current EC application, which shows the relationships among goals and their sub-goals. Belief Modeling Based on the ontology decision rules mentioned in the previous section, Table 5 shows the ontologies established for our problem domain. For example, the “Product Info Seeker Agent” uses ProductInfoOntology and CommunicationOntology. In addition, it has RoutingInfo, UserInfo and Address as the basic belief information.<br /> <br /> 188 • From Object-Oriented Modeling to Agent-Oriented Modeling<br /> <br /> Figure 7: Goal Hierarchy Diagram For the Example Domain Achieve UserRequestSatisfied<br /> <br /> Achieve ProductSearchRequestSatisfied<br /> <br /> Achieve ProductOrderingRequestSatisfied<br /> <br /> Achieve GetUserInfo<br /> <br /> Achieve SearchProductInfo<br /> <br /> Achieve CheckProductAvailability<br /> <br /> Maintain UserInteraction<br /> <br /> Achieve ProductOrderingProcess<br /> <br /> Achieve FindBestSolution Maintain WellInformed SearchPath<br /> <br /> Maintain SearchProductInfo<br /> <br /> :OR :AND :conflict<br /> <br /> :Goal :operationalizable goal<br /> <br /> Table 5: Various Ontologies for the Example Domain ProductInfoOntology: Overall knowledge needed by the user to choose a product. The product kind and its trend are established as ontology (Attributes of Search Display class). UserInteractionOntology: To understand user’s input about ordering process, user information such as name, address, credit card number, etc. is established as ontology (Attributes of the Order Process class). CommunicationOntology: When agents need to cooperate with each other, the protocol or ACL(Agent Communication Language) to be used is established as ontology (Requested operations of classes). ExternalAgentInfoOntology: The overall knowledge to perceive the external environment is established as ontology (Interacting messages in Sequence diagram). RouteDecisionOntology: Knowledge about the route for moving to other databases, is established as ontology (Interacting messages in sequence diagram).<br /> <br /> Plan Modeling As indicated earlier, an agent’s Plan represents its behavior to achieve the goal. For example, Figure 8 shows the plan characteristic of “Product Info Seeker Agent,” which specifies message exchanges among agents from the Interaction Diagram. Capability Modeling Agent’s capability represents operations that are needed for achieving its goal. Figure 9 shows the capability model for “Product Info Seeker Agent,” using the DFD notation. This agent has three capabilities, namely, “Search Product Info(),” “Validation(),” and “Ordering Process().” To add more details to the “Search<br /> <br /> Park & Sugumaran • 189<br /> <br /> Figure 8: Plan Sequence Diagram for “Product Info Seeeker” Agent<br /> <br /> Figure 9: Capability Model for “Product Info Seeker” Agent<br /> <br /> Product Info(),” capability, it can be further decomposed into three sub-capabilities, i.e., “Communication,” “Migrate & Search,” and “Send Info to Solution Finder Agent.” Inter Agent Modeling In this section, we present the Inter Agent modeling process for the EC problem domain under discussion. This process consists of agent mobility modeling which includes strategies for agent migration, as well as agent communication modeling, which captures the dynamics of message exchanging between agents.<br /> <br /> 190 • From Object-Oriented Modeling to Agent-Oriented Modeling<br /> <br /> Agent Mobility Modeling The Agent Mobility Model shows how an agent migrates to perform a task and the criterias that determine the destination for the mobile agent. Figure 10 shows the “Product Info Seeker” agent’s migration mechanism applied to our example domain. An abstract view of the agent’s internal processing to determine when and where to migrate next is shown in the lower half of the diagram (under the bar) shown in Figure 10. This corresponds to the agent’s decision mechanism for the next destination. Based on G1 (the previous goal) and IOE (Information of Environment) as inputs, Decision Making State brings forth G2 (the next goal) and next address as outputs. IOE has all information about agent’s state. For instance, IOE informs you where Mobile Agent is, how Mobile Agent processes its task, etc. If G1 is equal to G2, the previous goal is the same as the next one and the given task is finished. If not, G2 is the sub-goal of G1 and Mobile Agent should process G2 (the next goal). The mobile agent sends the search results from the databases back to the Coordinator Agent. Agent Communication Modeling The Agent Communication Model shows message exchanges between agents. It shows which agent communicates with what other agents and which message format is used for communication. Figure 11 shows the Agent Communication Model specific to our problem. Figure 10: Agent Mobility Model For the Example Domain<br /> <br /> Park & Sugumaran • 191<br /> <br /> Figure 11: Agent Communication Model For the Example Domain<br /> <br /> Generally, to generate a message, the results from an agent’s operation, as well as the current goal are used as inputs. These communication messages are generated by the agent’s internal processing routine. Typically, a message consists of three parameters, namely, sender_address (sender’s address), receiver_address (receiver’s address), and message content.<br /> <br /> SUMMARY AND FUTURE RESEARCH In this paper, we have proposed an agent modeling method for real world applications, and an overall agent-oriented software development process model. The major activities in agent modeling are Agent Elicitation, Intra and Inter Agent Modeling. Prior to the agent modeling process, the application domain is analyzed and modeled using the UML approach. From the UML-based domain model, we suggested criterias on how to select objects that should be agentified and produce an Agent-Class Diagram. This diagram describe the static parts of a system, as well as cooperation among agents. In Intra Agent modeling, we capture the internals of an Agent. The Goal-hierarchy diagram represents cooperation relationships among agents corresponding to each goal. Belief modeling in our methodology provides classification criteria on what knowledge should be established as ontology. Plan Sequence Diagram is used to describe changes in Agent’s behavior and DFD (Data Flow Diagram) is used to represent agent’s capabilities. In Inter Agent Modeling, we model Agent mobility and communication. We have demonstrated the feasibility of our modeling method by applying it to a small electronic commerce example. It is to be noted that our research effort in developing an agent-oriented software process model and the agent modeling framework is in the initial stages. Much work remains to be done. Some of the future work includes formal definition of the proposed methodology, and development of supporting tools. Appli-<br /> <br /> 192 • From Object-Oriented Modeling to Agent-Oriented Modeling<br /> <br /> cation of our modeling method to electronic commerce, as well as other real world application domains will be continued to validate the methodology. We will also extend our research to other phases of agent oriented software development methodology in a systematic way.<br /> <br /> REFERENCES Burmeister, B. (1996). Models and methodology for agent-oriented analysis and design. In K Fischer, editor, Working Notes of the KI’96 Workshop on AgentOriented Programming and Distributed Sytstems. DFKI Document D-96-06. Dardenne, A., Van Lamsweerde, and Fickas, S. (1993). Goal-directed Requirements Acquisition, Science of Computer Programming, 20, pp.3-50. Falchuk, B. and Karmouch, A. (1998). Visual Modeling for Agent-Based Applications, IEEE computer, December. Gruber, T. R. (1993). A Translation Approach to Portable Ontologies, Knowledge Acquisition, 5(2), 199-220. Jennings, N. R., Sycara, K. P., and Wooldridge, M. (1998). A Roadmap of Agent Research and Development, In Journal of Autonomous Agents and Multi-Agent Systems, 1(1), pages 7-36, July. Kim, M. J., Kim, J. T., Park, I. J., Lee, S. Y., and Park, S. Y. (1999). Agentbased Software Analysis Method in Distributed Environment, Fuzzy-IEEE’99, September. Kinny, D., Georgeff, M., & Rao. A. (1996). A methodology and modelling technique for systems of BDI agents, Proc. of the 7th European Workshop on Modelling Autonomous Agents in a Multi-Agent World MAAMAW’96, (LNAI Volume 1038). Heidelberg, Germany: Springer-Verlag. Nwana, H. S. (1996). Software Agents: An Overview», Knowledge Engineering Review, 11(3), pp. 205-244. Rao, A. S. and Georgeff, M. P. (1991). Modeling rational agents within a BDIarchitecture. Proceedings of Knowledge representation and reasoning (KR&R-91), Morgan Kaufmann Publishers, pp. 473-484. Schroeder, M. (1999). Are Distributed objects agents? International Bi-Conference Workshop on Agent-oriented Information Systems (AOIS’99). Thomas,S.R. (1993). PLACA, An Agent Oriented Programming Language, PhD Thesis, Stanford University. UMBC Lab for Advanced Information Technology, KIF (Knowledge Interchange Format), http:// www.cs.umbc.edu/kse/kif/. Wooldridge, M. (1997). Agent-based Software Engineering. In IEE Proceedings on Software Engineering, 144(1), pages 26-37, February. Woolridge, M., Jennings, N., and Kinny, D. (1999). A Methodology for AgentOriented Analysis and Design, Proc. Of Autonomous Agents ’99 Conf., Seattle, WA, pp. 69-76.<br /> <br /> Baghdadi • 193<br /> <br /> Chapter 18<br /> <br /> Web-Based Cooperative Information Systems Modeling Youcef Baghdadi United Arab Emirates University<br /> <br /> This chapter presents a modeling for the Web-Based Cooperative Information Systems (WBCISs). This modeling considers the WBCISs as support of the unavoidable interactions among multiple existing heterogeneous subsystems of the information system and external information sources that share business objects and processes. The WBCIS is considered as an artifact that firstly and mainly allow information exchange, coordination and cooperation among these sources; and secondly data restructing and processes reuse or reengineering. The main concepts are Knowledge Sources and Interaction Component. A knowledge source represents a subsystem of the information system (Personal IS, Workgroup IS or Enterprise IS); or any external information source. The modeling considers the knowledge source as a UML package that presents an interface definition (business objects schema and processes). An interactions component is a kind of Web-based broker of business objects and processes. It is a support for communication services and user-oriented semantic services of the knowledge sources. It is based on the Web so that it deals with semi-structured data and accesses any knowledge source (willing to interact) having its URL. It uses a metadata that describes the knowledge sources as UML package. The modeling specializes interactions components according to the interaction situations of the knowledge source namely interactions for coordination that deal with the consistency of the Previously Published in Managing Information Technology in a Global Economy, edited by Mehdi Khosrow-Pour, Copyright © 2001, Idea Group Publishing.<br /> <br /> 194<br /> <br /> • Web-Based Cooperative Information Systems Modeling<br /> <br /> shared business objects, interactions for cooperation related to the coupled processes’ activities or interactions for transmission that deal with informal and unstructured information exchanges. A Coordination Component allows knowledge source location, access, integration, global view and restructing of the business objects. A Cooperation Component allows process’ activities invocation, reuse or reengineering activities. This methodologic specialization allows easier implementation and reuse of the interaction components. An interaction component is modeled as a UML package.<br /> <br /> INTRODUCTION Work Organization and Information Technology are increasing more and more the heterogeneity of the components of the enterprise information system (IS), that is the enterprise IS is not central and unique. It is rather characterized by the existence of heterogeneous subsystems such as personal IS and workgroup IS which co-exist with the so-called enterprise information system. These subsystems are running on different platforms. Furthermore, these subsystems share business objects and processes with external sources. This motivates the interactions not only among these subsystems but also among these subsystems and external sources representing the business partners. The interactions are necessary for the consistency of the business objects and the synergy of the processes. A general issue concerns with architecture and a modeling for an artifact that supports the interactions among the distributed subsystems of an information system (IS) and the environment. This artifact is considered, in this chapter, as new kind of IS so-called cooperative information system (CIS). This CIS co-exists with the different existing subsystems such as personal information systems (PISs), workgroup information systems (WISs), enterprise information system (EIS) and external sources of information. The CIS deals only with interactions among the existing subsystems of the IS and the interactions inter-organizations. It mainly provides these subsystems with communication services and user-oriented semantic services (in heterogeneous environment). By supporting interactions, a CIS will support coordination and cooperation and therefore collaborative human work (De Michelis, Dubois, Jarke, Matthes, Mylopoulos, Papazoglou, Pohl, Schmidt, Woo and Yu, 1997; Papazoglou and Schlageter, 1997). Although, the existing communication methods, means, tools and technologies such as Computer-Supported Cooperative Work (CSCW) (Schmidt, 1994), GroupWare (Greif, 1988), Workflow Systems (Casati, Ceri, Paraboshi and Pozzi, 1999), Object Technology, Intranet, Internet, Client/Sever and Middleware (e.g., COBRA, DCOM, RMI ODBC, JDBC) (Umar, 1997) implement cooperation between heterogeneous systems. We need a more abstract level (logical) that<br /> <br /> Baghdadi • 195<br /> <br /> models and represents the coherent communications of the organization if we define communications as the set of specialized formal or informal, internal or external, local or global exchanges (of shared business objects having different structuring and presentation such as database tables, data files, text files, html files and so on). These exchanges are representative of all the forms and modes of interactions (Bannon and Schmidt, 1991). We then decide and use the implementing technologies only after the specification of interaction forms and modes. However, a CIS is mainly based on a new IT namely networking (Internet, Intranet), Web, client/server technology and object technology (Benattalah and Bouguettaya, 1997) and (Bouguettaya, Benattalah and Hendra, 1999). In addition, the Web allows presentation of semi-structured data and multimedia information. We therefore use the more suitable implementation of CIS and call it Web-Based Cooperative Information System (WBCIS). A WBCIS is Web-based implementation of the CIS. It is considered as a layer above the well-known Middleware such as CORBA, DCOM, RMI, ODBC or JDBC. It is used for multiple purposes namely for: • Browsing business objects and processes’ activities over the Web; • Querying the structure of business objects according to their implementation (which may be a document, a file, a class of objects, a database table and son on); • Restructuring business objects, to multi-query pieces of data related to business objects; • Invoking the processes’ activities according to their implementation (application, package, procedure, function, ActiveX, Java Applet or Java Beans); • Reusing implementation of a process’s activity implementation or reengineering processes. The modeling considers then two abstract levels: a conceptual level to specify the CIS as a conceptual interaction artifact, and the implementation level to specify the WBCIS as a Web-based implementation of the interaction artifact. The modeling summarizes the properties of the WBCIS in a metadata. The elements of this metadata will be well specified after introducing and specifying the properties of the WBCIS in the second and third sections, respectively.<br /> <br /> WEB-BASED COOPERATIVE INFORMATION SYSTEMS Work Organization and Information Technology increase the distribution of the IS. Indeed, work organization structures the business by departments having their respective goals, skills and specialized processes. Whereas Information Technology allows development and implementation of local and specific computerized IS characterized by their own platform. Therefore, there are, in the same<br /> <br /> 196<br /> <br /> • Web-Based Cooperative Information Systems Modeling<br /> <br /> organization, a proliferation of several heterogeneous subsystems of the IS, which are generally classified into workgroup ISs (WISs), personal ISs (PISs) and enterprise or organization IS (EIS). Workgroup ISs support the formalized knowledge of a departments or groups. Personal ISs support the knowledge of individuals and finally the enterprise IS, which consists principally of legacy systems, supports the collective and formalized knowledge of the whole enterprise. The different subsystems co-exist with the enterprise IS. Of course, this distribution and structuring of the knowledge aims to local autonomy, reliability, availability and performance. It, in the other hand, leads to some constraints or even conflicts at both local and enterprise levels while the mechanisms (to offset) it are neglected. In fact, at the local level, departments, groups or individuals may have constraints of informational and computational resources (e.g., pieces of data). These constraints are due to their specificity and consequently their partial perception of business objects and processes. At the enterprise level, information needed for any action notably decision-making is in part only processed in the local subsystems and a simple data integration is still insufficient. Sometimes, simply browsing business objects and processes activities over a local network or over the Web may raise these constraints. But in general we need more formal interaction mechanisms based upon new technologies namely the Web to locate the necessary knowledge. Furthermore, decision making and business’s improvement and innovation require new types of IS that are respectively group decision support systems (GDSS), business process reengineering (BPR), business network reengineering (BNR) and business scope redefinition (BSR). These new kinds of IS are mainly based upon interactions among local subsystems and especially inter-enterprises. All these systems share business objects and processes. They cannot exist without interactions each other to allow them a global and consistent view of the business objects, processes and the partners. Interaction, which is a dynamic relationship between two or more subsystems is made by reciprocal actions (Erceau and Ferber, 1994), becomes fundamental to allow, coordination, cooperation and therefore re-organization (process reengineering, network reengineering and process redefinition). Interactions are required for satisfying the lack of informational and computational resources, resolving conflicts, making-decision, improving and innovating business processes. Interaction allows not only synergy, but also an emerging knowledge. Emerging knowledge is an added value. In fact, knowledge produced by interactions might be more relevant and more complete than a simple data integration. However, interaction (or interaction mechanisms) and emerging knowledge do not exist naturally. They are to be specified, designed and implemented by means of communication tools. For this purpose, communication aspect has become, these last years, the core of several disciplines that explore and express<br /> <br /> Baghdadi • 197<br /> <br /> new parameters, which are related to work organization and information technology. For instance, CSCW that tends to motive and valid GroupWare used to support and enhance activities in which more than one person are involved. The CIS that represents, at the conceptual level, the global vision of the interaction intra-organization and inter-organizations is well suited as artifact to support both individual and collaborative work. It aims to enable cooperation among a large number of pre-existing information sources including the legacy systems and the external sources. Of course, the CIS relies on new technologies such as Internet, Web, Object-Orientation, Client/Server and particularly Middleware such as CORBA, DCOM, RMI, ODBC, JDBC, Java Applet, Java Beans or ActiveX used to make the different subsystems interoperable and cooperative. Thus new technologies will not be used on case-by-case basis. They are rather used to implement the CIS as a coherent vision of utile interactions. The implemented CIS by means of the Web becomes then Web-Based Cooperative Information System. Thus, the WBCIS can access internal and external knowledge sources whatever their location and implementation, and allow a consistent view of the business objects and processes. We consider then CIS architecture with two abstract levels: a conceptual level and an implementation (physical) level. The first level allows the specification of the CIS as interactions artifact regardless the resources to implement it and the second deals with technology. Nowadays, the suitable technology to largely browse knowledge is the Web. That is, we are interested by WBCISs as an implementation of the CISs. Web-Based Cooperative IS may be used to support different levels of the organization by providing them with communication services and user-oriented semantic services. At local level, it is used whenever there is an expressed need of cooperative work for individuals or group decision-making. It allows a rapid identification rapprochement of different sources of knowledge over the Web that can be involved in the decision-making. At the enterprise level, communications become, with the WBCIS, strategic for decision-making and business improvement and innovation.<br /> <br /> PROPERTIES OF WEB-BASED COOPERATIVE IS This section defines the structural and functional properties of Web-Based Cooperative IS. These properties are summarized in a metadata. Structure of the Web-Based Cooperative IS A Web-Based Cooperative IS has two main components: 1) A set of knowledge sources which are EIS (or legacy systems), WISs, PISs,<br /> <br /> 198<br /> <br /> • Web-Based Cooperative Information Systems Modeling<br /> <br /> and external information sources (that are its subscribers) running on heterogeneous platforms; 2) An interaction component that supports different kinds of interactions among the knowledge sources. Knowledge Source. A knowledge source is a component of the CIS. It has an identity, an existence and therefore autonomy. It also has a goal, some local implementations (or views) of business objects (piece of data or views related to these business objects) and some tasks (related to business processes’ activities) to perform. A knowledge source is a subsystem of the IS, that is, a knowledge source has a name, and a type (PIS, WIS, EIS, or External IS). A knowledge source is made up of two parts: a private part and a collective part. The collective part may be wrapped in an interface definition like in CORBA (www.omg.com) and deals with its relationships with other knowledge sources. It mainly represents its cooperative aspects. This part concerns some functionality, which ensure dynamic relationships with the environment. The private part, which is its internal behavior, represents the activities implemented and performed by the knowledge source, the required pieces of data related to the business objects and the acquisition and invocation functions to capture knowledge from the environment. Thus, a knowledge source is able to interact with the environment to accomplish its goal or to participate to achieve a common objective. This specification, of the knowledge source, allows a system designer to easily wrap the knowledge source as molecular object (Figure 1) or as a UML package (www.rational.com) (Figure 2). Figure 1: Knowledge Source Representation and Wrapping. Interface Definition (Publication) Cooperative Data Schema Data<br /> <br /> Cooperative Task<br /> <br /> Parameters<br /> <br /> Interactions<br /> <br /> Environment<br /> <br /> Behavior Transmission Transmit Messages<br /> <br /> Coordination Request Data<br /> <br /> Cooperation Invoke Task<br /> <br /> Figure 2: Knowledge Source Represented as Package (Using UML Notation). Knowledge Source<br /> <br /> Interactions<br /> <br /> Knowledge Source<br /> <br /> Baghdadi • 199<br /> <br /> A Web-Based Cooperative IS aims to enable cooperation among a large number of knowledge sources by supporting their interactions with each other. Interaction. An interaction is a relationship between two or more knowledge sources (subsystems). It may be a fixed or dynamic. Work organization generally stipulates a fixed relationship. For instance, mechanisms of coordination used to offset a planned task allocation. A complete and global definition considers that interaction is dynamic and temporal. It is then made by a set of reciprocal actions and requires the presence of agents that are able to act and to communicate (for the WBCIS, these agents are the knowledge sources); and a certain degree of freedom. Each knowledge source has a certain degree of freedom within relationship. It has the ability to commit to participate or to quit the relationship. Knowledge source may interact with the environment for different purposes namely for coordinating, for collaborating, for cooperating, or simply for transmitting messages. These concepts are used in different disciplines (Linguistics, Organization, CSCW, DAI...) (De Michelis and Grasso, 1994; Matthes, 1997; Winograd, 1988) and defined by many authors. We will pick up the definition given by (Alquier, 1993) and (Baghdadi and Alquier, 1996) with respect to the IS discipline in which three situations are considered. These situations are subsequent to the nature of the IS which contain informational (business objects) and computational (processes) resources. That is, the two obvious situations are respectively coordination situation and cooperation situation. A third situation deals with informal exchange that we call transmission. Interaction has a structure that shows the interacting knowledge sources, the situation of interaction (why they interact), the business object views (in case of coordination) or the task (in case of cooperation). Coordination is a communication with required data semantics definition (e.g., EDI). Cooperation is a communication with required task semantics definition. It allows articulation of distributed business process activities (e.g., GroupWare and Workflow Systems). Transmission is a communication without semantics. One is only interested in the medium as channel. (e.g., e-mail). Interactions among knowledge sources and the environment are supported by an interaction component that provides all the communication functionality namely the acquisition, the invocation and the commitment. Some communication services and semantic services provided by the interaction component implement this functionality. Interactions Component. An Interaction component is an element of the WBCIS. It is an artifact that provides communication services and semantic services. It may also store interactions among knowledge sources, which are its sub-<br /> <br /> 200<br /> <br /> • Web-Based Cooperative Information Systems Modeling<br /> <br /> Figure 3: Interactions component represented as UML Package. Knowledge Source ▼<br /> <br /> ▼<br /> <br /> ▼ ▼<br /> <br /> Metabase<br /> <br /> Knowledge Source<br /> <br /> scribers in a Base of Interactions (Figure 3). This interaction base may be used further as group memory or interactions cache to allow knowledge’s structuring, integrating and reusing. The interactions component and the metabase (metadata) used by the interactions component are represented by two packages. Inside each package there are specified classes. The interactions component package contains only one class whose name is interactions component and its attributes and operations are as specified in the Figure 4. The package metabase has many associated classes as described in the Figure 6. The interactions component is specialized (Figure 5) into: A Coordination Component that provides communication services and user-oriented semantics services to allow coordination such as distributed data base management, data remote access that make possible the management of the distributed business objects by building their whole semantics. The coordination component allows the consistency of the distributed business objects. A Cooperation Component provides communication services to allow coupled processes’ activities. It allows a global and consistent view of business processes. A Transmission Component provides only communication services needed for transmission such as e-mail. Functionality of the Interactions Component The interactions component is used by any knowledge source provided that knowledge source can access the Web. It provides some communication services and semantic services (translation between heterogeneous sources) according to its specialization. An interaction component for coordination is used for: - Browsing Business Objects over the Web - Querying and retrieving piece of data related to the business objects according to their implementation.<br /> <br /> Baghdadi • 201<br /> <br /> Figure 4: Interaction Component Represented as a UML Class. Interaction Component name : string type : string locate (name : string) : Knowledge source location connect (ks_location : string) : Knowldge source search (bo_name : string) : Business object search (t_name : string) : Task invoke (t_parameter_in) : Parameter_out search (a-name : string) : Attribute access (bo_Implementation) : Attributes getMessage (user, password) : Message sendMessage (message, knowldge source) : Boolean restructure (bo_name : string) : Implementation reengineer (t_name : string) : Implementation find (interaction_parameters) : Interaction<br /> <br /> Figure 5: Specializations of the Interactions Component Represented as UML Classes. Interaction Component name : string locate (ks_name : string) : ks_location connect (ks_location : string) : boolean find (parameter) : interaction<br /> <br /> Cooperation Component<br /> <br /> Transmission Component getMessage (user, password) : Messa sendMessage (message, knowldge so<br /> <br /> Coordination Component<br /> <br /> search (name : string) : Tasks invoke (t_name, parameter_in) : Parameter_out reengineer (name : string) : void<br /> <br /> search (name : string) : Business object search (name : string) : Attribute request (parameter_in) : Parametr_out<br /> <br /> Figure 6: Metadata Description and Formalization with UML Class Diagram. Knowldge Source name : string type : string location : string<br /> <br /> 0..*<br /> <br /> findlocation (name : string) : url findks (name : string) : ks<br /> <br /> Synonym<br /> <br /> Composes 0..*<br /> <br /> Business_Object name : string<br /> <br /> Process name : string sstate : int<br /> <br /> findobject (name : string) : object getsynonym (name : string) : object<br /> <br /> 1..*<br /> <br /> findprocess (name : string) : process getstate () : int updatestae (stae : int) : void<br /> <br /> Description ks_name : string bo_name : string at-name : string type : string<br /> <br /> 1..*<br /> <br /> 1..*<br /> <br /> nextactivity () : activity previousactivity () : activity<br /> <br /> Activity_Parameter_In<br /> <br /> 1..*<br /> <br /> 1..*<br /> <br /> 1..*<br /> <br /> Object_implementation address : string<br /> <br /> Consists of<br /> <br /> *<br /> <br /> Activity name : string<br /> <br /> Manual<br /> <br /> 1..*<br /> <br /> 1..*<br /> <br /> 0..*<br /> <br /> Is a<br /> <br /> Activity_implemetation ks_name : string ac_name : string<br /> <br /> Attribute name : string<br /> <br /> Is a<br /> <br /> findattribute (name : string) : attribute 1..*<br /> <br /> Is a Is a<br /> <br /> Package<br /> <br /> Is a 0..1<br /> <br /> Is a<br /> <br /> Activity_parameter_Out Is a<br /> <br /> Application<br /> <br /> Is a<br /> <br /> Procedure<br /> <br /> Is a<br /> <br /> Is a<br /> <br /> Is a<br /> <br /> Document url : string<br /> <br /> Is a Is a<br /> <br /> Function<br /> <br /> JavaBeans File type : string<br /> <br /> Relational_Table dbms : string<br /> <br /> Class language : string<br /> <br /> Has<br /> <br /> *<br /> <br /> Method<br /> <br /> ActiveX<br /> <br /> Applet<br /> <br /> 202<br /> <br /> • Web-Based Cooperative Information Systems Modeling<br /> <br /> - Capitalizing information. - Integrating business object semantics. An interaction component for coordination is used for: - Browsing the processes and their implantation - Invoking the implementation of the processes - Reusing (by inheritance, overloading or overriding) the implementation of the process - Reengineering the process. The functionality of the Interaction component are based on a metadata (Figure 6) that contains all the information related to the knowledge sources, the different implementation of their business objects and their processes.<br /> <br /> METADATA FOR WEB-BASED COOPERATIVE IS The metadata is essential for the artifact. It represents the data dictionary where the interactions component locates the fundamental components of the cooperative information systems. This chapter specifies the components of the metadata and presents an implementation of this metadata. Metadata Specification The metadata represents the fundamental concepts of the WBCIS and the relationships among them. The concepts are represented as classes according to the UML definition and specification of the classes. Figure 6 represents the fundamental concepts using a UML class diagram. The fundamental concepts are: 1. Knowledge Sources which is described by: - Name - Type (PIS, WIS, EIS or external source) - Location (e.g., URL) - Administrator (user name and password) Examples of knowledge sources in medical domain are Specialist Personal Information System, Patient Record Information System, and Clinic Information System. 2. Business Objects. A business object may have different implementations within several knowledge sources. It is described by some attributes on each distinct implementation and may have some synonyms. It is then described as follows: - Name - Set of attributes for each implementation on each knowledge source. - Synonyms<br /> <br /> Baghdadi • 203<br /> <br /> An implementation of a business object may be: a HTML document, a Database table, a record of file, or an object (according to the object orientation paradigm). For example, the business object patient may be implemented as database table within the Specialist Personal Information system, a file within the Patient Record Information System or an HTML Document within a Clinic Information System. It is described differently on each knowledge source. That is its attributes differ from one implementation to another. 3. Processes. A Process is made up of a set of activities. An activity may have different implementations on several knowledge sources. It has some attributes as parameters input and some attributes as parameters output on each distinct implementation. An activity may have precedence. A process may be subdivided into sub processes. It is described as follows: - Name - State (current activity) - Set of activities implementation on each knowledge source. An implementation may be: Package, Application, Procedure or Function, Method, Applet, ActiveX, Java Bean, - Activity’s Parameters (parameters in and parameters out). For example, the patient monitoring process is a process that may be decomposed into many sub processes distributed over the different knowledge sources which are Specialists’ Personal Information Systems, Patient Record Information System, Clinic Information system, General Practionner Personal Information system and so on. Each sub process is made up of several activities and has consequently a state. Some activities may be identical but differently implemented. A specialist diagnostic is implemented differently from a family doctor diagnostic. The laboratory person and the specialist interpret lab’s Analysis Result differently. So two activities are differently implemented. Moreover, each activity implementation has its own parameters in and parameters out. Metadata Implementation The above-specified metadata as a package that contains classes according to the UML notation and diagrams may be implemented using an object oriented DBMS, a relational DBMS or a set of persistent objects into files (to be independent of particular vendor). We are testing two prototypes of implementation. The first consists of defining and specifying the classes using UML class diagram as in Figure 6, and then implement the classes of the diagram (Figure 6). The<br /> <br /> 204<br /> <br /> • Web-Based Cooperative Information Systems Modeling<br /> <br /> instantiated objects of each class are made persistent by writing their instantiated objects into a file in order to be read later by the interaction component. The second consists of implementing the class diagram of metadata (Figure 6) as a relational database using Oracle8 in order to be accessed later by the interaction component using JDBC. This needs a mapping of the diagram class into a relational schema, which is quasi automatic.<br /> <br /> WEB-BASED COOPERATIVE IS IMPLEMENTATION A simple prototype implementation of this architecture consists of: a) Implementing the metadata using Java, Object-Oriented Database or Relational Database, b) Managing the metadata, c) Implementing the interaction component by a set of successive interactive applets that may be downloaded by the knowledge source to request business object or invoke the process’s activities. Step 1. Any knowledge source may download an applet with an interface that presents a form allowing the end user to search for a particular business object or process. The applet accesses then the metadata to retrieve the requested and display all the synonyms of the business object (in case of the coordination) or the process activity (in case of the cooperation). Step 2. The interaction component locates then the business object or the process at a particular knowledge source (giving its address or its URL). The applet uses the metadata to display the implementation of the requested business object or process activity inside each knowledge source that uses this business object respectively process activity. Step 3. The knowledge source (by mean of its administrator) may continue querying or displaying business object according to its implementation, or, in case of a process, invoking the implementation of the process by passing the parameters to the knowledge source that performs the process and return back the output parameters. Step 4. The knowledge source prepares the query by selecting other knowledge sources that uses the business object and the attributes it is concerned with; and launches the query over the Web. Step 5. After receiving the query result, the knowledge source may use this result immediately, save the result for further use or re-structure its data.<br /> <br /> CONCLUSION Web-based cooperative information system is an implementation of the cooperative information using the Web as main technology. It provides communication services and semantic services for heterogeneous sources of knowledge.<br /> <br /> Baghdadi • 205<br /> <br /> WBCIS can be either an integrator of the knowledge sources of the enterprise, which are the existing collective, departmental and individual IS, or a support for the cooperative work in the wide sense of this term.WBCIS allows knowledge sources to cooperate via specialized interaction components. These interactions components implementation are based upon metadata that describes all the components of the WBCIS architecture. The metadata specifies all the information that allows the interaction component (as broker) to browse the business objects and processes over the subsystems of the information system and the external sources of information. This is an issue today where enterprises particularly try to improve cooperative work because their decisions partially depend on the performance of the communication means and tools they use. Interaction component for coordination that is related to the business objects is implemented as an applet that searches and locates the user business objects over the Web. We could show after how to implement all the functionality of the WBCIS.<br /> <br /> REFERENCES Alquier, A. M. (1993). Les Systèmes d’Information: Modèles Coopératifs, Dossier d’habilitation. Université de Toulouse 1. Baghdadi, Y. and Alquier, A. M. (1996). Cooperative Information System: a Definition, a Framework and a Modeling, Proceedings of the 2nd International Conference on Cooperative Systems, Juan-les-Pins. Bannon, L. J., and Schmidt, K. (1991). CSCW : Four Characters in Search of a Context. In J.M. Bowers and S.D. Benford (eds.): Studies in Computer Supported Cooperative Work, Elseevier Sciences Publishers B.V, pp. 3-16, North-Holland. Benattalah, B., and Bouguettaya, A. (1997). Data Sharing On the Web, EDOC’97, Gold Coast, Australia. Bouguettaya, A., Benattalah, B., and Hendra, L. (1999). World Wide Database Integrating the Web, CORBA and Database, SIGMOD’99. Casati, F., Ceri, S., Paraboshi, S., and Pozzi, G. (1999). Specification and Implementation of Exceptions in Workflow Management Systems. ACM Transactions on Database Systems, 24(3), pp 405- 451, September. De Michelis, G., Dubois, E., Jarke, M., Matthes, F., Mylopoulos, J., Papazoglou, M., Pohl, K., Schmidt, J., Woo, C., and Yu, E. (1997). Cooperative Information System: A Manifesto, In M. P. Papazoglou and G. Schlageter (Eds.), Cooperative Information Systems Trends and Directions. Academic Press. De Michelis, G. and Grasso, M. A. (1994). Situating Conversations within the Language/Action Perspective: The Milan Conversation Model. Proceedings of ACM, Conference on Computer Supported Cooperative Work. October 22-26, pp. 89-100.<br /> <br /> 206<br /> <br /> • Web-Based Cooperative Information Systems Modeling<br /> <br /> Erceau, E. J., and Ferber, J. (1994). Intelligence Artificielle Distribuée et Systèmes Multi-Agents, In Intelligence collective. Hermes. Greif, I. (1988). Computer-Supported-Cooperative-Work. In I. Greif (Ed.), Cooperative-Supported Cooperative Work : A Book of Readings. Matthes, F. (1997). Business Conversations: a High Level System Model from Agent Coordination, Proceedings of the Sixth international Workshop on Database Programming Languages, Estes Park, Colorado. Springer-Verlag, August. Papazoglou, M. P. and Schlageter, G. (1997). Cooperative Information System: Trends and Direction, Academic Press. Schmidt, K. (1994). The Organization of Cooperative Work: Beyond the Leviathan Conception of the Organization of Cooperative Work, Proceedings of ACM, Conference on CSCW, October 22-26. Umar, A. (1997). Application (Re)Engineering: Building Web-Based Applications and Dealing with Legacies, Prentice Hall. Winograd, T. (1988). A language/Action Perspective on the Design of Cooperative Work, In I. Greif (Ed.), Cooperative-Supported Cooperative Work: A Book of Readings. www.omg.com. www.rational.com.<br /> <br /> Rittgen • 207<br /> <br /> Chapter 19<br /> <br /> EMC – A Modeling Method for Developing Web-based Applications Peter Rittgen University Koblenz-Landau, Germany<br /> <br /> Early information systems were mainly built around secondary, administrative processes of the value chain (e.g., accounting). But since the internet came into use, more and more primary processes have become accessible to automation: customer acquisition, ordering, billing and, in the case of intangible goods such as software, even delivery. Hence an increasing part of an enterprise has to be modeled and a substantial part thereof is implemented, usually in an object-oriented programming language like Java. To facilitate this complex task, the MEMO methodology (Multi-perspective Enterprise MOdeling) allows the description of the enterprise on three levels – strategy, organization and information system – and from four angles – process, structure, resources and goals. All partial models for the views are integrated via a common object-oriented core. In this framework we suggest a modeling method for the IS layer, the Event-driven Method Chain (EMC). It is based on the Event-driven Process Chain (EPC) by Scheer, which we adapt to fit both the MEMO methodology and the object-oriented paradigm thus making it suitable for the development of web-based applications. To illustrate this we use the example of a software trading company.<br /> <br /> Previously Published in Challenges of Information Technology Management in the 21st Century, edited by Mehdi Khosrow-Pour, Copyright © 2000, Idea Group Publishing.<br /> <br /> 208 • EMC – A Modeling Method for Developing Web-based Applications<br /> <br /> INTRODUCTION Early information systems were mainly built around secondary, administrative processes of the value chain (e.g., accounting). But since the internet came into use, more and more primary processes have become accessible to automation: customer acquisition, ordering, billing and, in the case of intangible goods such as software, even delivery. Hence an increasing part of an enterprise has to be modeled and a substantial part thereof is implemented. To create such an information system and to adapt it constantly to a changing environment requires a much more efficient software development process than the one suggested by the traditional methods, namely the separation into the phases analysis, design and implementation where each phase is usually performed by a different team, each relying on the documents produced in the previous phase (possibly with backtracking). In these approaches, the coupling between the phases is weak: changes to an analysis model typically require a substantial reorganisation of the design models, which in turn slows down software development considerably. The ARchitecture of Integrated information Systems (ARIS, [Scheer, 1999]) is one such traditional method with a focus on analysis. It received substantial attention both from researchers and practitioners thanks to its close relation to the SAP suite of business applications. Now, there are several reasons why such methods are not suitable for the development of web-based applications (leading to corresponding requirements): 1. The increasing number of automated business processes requires the integration of these processes with the relevant data. But the parts (views) of conventional models are only loosely coupled (e.g., the data and process models of ARIS). A suitable method for developing web-based applications should integrate partial models, especially the process and the data/object model (model integration). 2. Existing methods do not cater for the needs of object orientation. But the predominant use of object-oriented programming languages in developing webbased software demands the compatibility of the modeling method with object-oriented concepts. 3. Traditional software development is usually quite slow. But electronic markets require a quick adaptation of web applications to changing needs. 4. The development of design models typically consists of reinventing the analysis models in a different (more formal) language. A smooth transition from analysis to design, by merely refining the existing analysis models, is preferable (phase integration). To solve these problems, we make use of the MEMO framework, which represents a multi-perspective approach to enterprise modeling where all views are strongly connected via a common object-oriented core. Within this frame-<br /> <br /> Rittgen • 209<br /> <br /> work, the integration of processes and their relevant data is achieved by an analytical, object-oriented process definition language called Event-driven Method Chain (EMC). Apart from model integration, EMCs also facilitate the transition from analysis to design by providing a suitable level of abstraction/formalization, hence speeding up the software development process.<br /> <br /> AN EXAMPLE SETTING To illustrate the problem of developing a web-based application, we consider the example of a young mail-order company trading software products. Up to now, they were organized in a more or less conventional way: customers ordered via phone, fax or surface mail. Orders were processed manually and then entered into a database. The products were stocked in physical form as CDROMs. Stock management was done with the help of a stand-alone system. Delivery was effected by conventional posting, payment by cheque, credit card or money order. Now, this company plans to operate over the internet. Apart from offering new services (such as ordering via the world wide web and downloading of the ordered product), this also requires substantial reorganization: e.g. the isolated Figure 1: Example architecture of a web application for a software trading company internal applications<br /> <br /> order processing<br /> <br /> customer management<br /> <br /> delivery<br /> <br /> .....<br /> <br /> database customers orders items ...<br /> <br /> ▼<br /> <br /> ▼ applet server ▼<br /> <br /> internal external<br /> <br /> ▼ browser<br /> <br /> Java applets<br /> <br /> search<br /> <br /> price info.<br /> <br /> customer<br /> <br /> order<br /> <br /> claim<br /> <br /> 210 • EMC – A Modeling Method for Developing Web-based Applications<br /> <br /> information systems for ordering and stocking have to be integrated to allow the potential customer a combined search for price and availability of a product. The head of IT is therefore asked to draw up a sketch of the principal architecture of the new system (see Figure 1). It consists of a central database containing information about customers, orders, items and so on. All applications, internal and external, operate on this database. Internal applications are the ones used only by the staff of the company, such as order and customer management, delivery etc. The external applications can also be accessed by the (potential) customers. They are made accessible to the world by an applet server feeding the user’s browser. The next sections will show how such an information system can be analyzed and designed rapidly with the help of the EMC method. This method integrates the different views on a system as well as their migration from analysis to design models because it adheres to the multi-perspective methodology for enterprise modeling (MEMO) as outlined in the following section.<br /> <br /> MULTI-PERSPECTIVE ENTERPRISE MODELING (MEMO) In the early phase of analysis, the modeler of any application is typically confronted with a yet largely unstructured problem domain. This applies to webFigure 2: Perspectives on an enterprise (MEMO)<br /> <br /> Rittgen • 211<br /> <br /> based applications in particular, which involve a complete reorganization of a substantial part of the company: processes to be performed over the web have to be designed newly, related internal processes have to be adapted accordingly. These changes affect not only the information system itself but also the organization as a whole resulting in a significant strategical impact of the corresponding decisions. Hence a modeling methodology should distinguish three levels of an enterprise: strategy, organization and information system (see Figure 2). But even if we restrict attention to one of the levels, too much complexity remains to be handled by one model only. Therefore each level is further subdivided into the following four foci: • structure: static description of the domain objects and their relations • process: dynamic representation of the system • resources: means required to execute a process • goals: results to be achieved and their relations The resulting 12 partial models span the 4x3 matrix of the views of MEMO, the acronym of Multi-perspective Enterprise MOdeling (Frank, 1997). Figure 2 gives iconized examples for the 12 views. For example, the strategical process model (SPM) consists of a value chain á la Porter (1985) where the primary processes (procurement, production, distribution, marketing) form the basic chain (arrow-shaped boxes) with the subsidiary (supporting) activities attached to them (the flags). On the organizational and IS levels, an EPC-like language for modeling process is used. The OSM is represented in the form of an organizational chart and the ISM is an object class model. The remaining views in the matrix have not been covered yet. Here we focus on developing an integrated modeling language for the IS level (abstracting from the goal view for the time being). We call this language EMC (Event-driven Method Chain). It covers IPM (IS Process Model), IRM (IS Resource Model) and the integrative part of ISM (IS Structure Model). The details of the structure are thereupon specified with the help of MEMO-OML (MEMO Object Modeling Language, see Frank, 1998). Here MEMO-OML is explained only insofar as it is necessary to understand the integration of all three views. We start form the assumption that the processes of a problem domain are rather easier to identify than the more abstract objects. Hence we put the process focus in the center of the EMC language and suggest that an initial EMC is drawn before the corresponding object model. In fact, the EMC even helps in the construction of the object model. The basic dynamic element of an EMC is the method (or service) which is linked to the objects involved in providing this service. The objects themselves and their relations are defined in MEMO-OML. We establish the resource focus by attaching the resources to the method which requires them. Figure 3 shows how the individual foci are represented in the models according to the MEMO methodology (i.e., a study of methods).<br /> <br /> 212 • EMC – A Modeling Method for Developing Web-based Applications<br /> <br /> Figure 3: Representing the MEMO views in the models<br /> <br /> The process modeling language EMC is based on the Event-driven Process Chains (EPCs) of ARIS. Although this language exhibits major shortcomings as demonstrated in the next section, we do not reject it outright because it has proved its ease of use in practice: it is the preferred choice of consultants and large IT departments, and it is a must for companies introducing SAP. Hence a process language based on EPCs has a better chance of being accepted by the practitioner than some completely new artefact. Still, the shortcomings have to be overcome to make EPCs fit into the MEMO framework (thus achieving model integration), to align them to the object-oriented paradigm and to ensure an unambiguous interpretation of the analysis models by the designers thus achieving phase integration (see points 1-4 in the introduction). The result is the EMC language described in the fifth section.<br /> <br /> SHORTCOMINGS OF EPCS When modeling business processes in ARIS, we identify core processes of the company and represent them as EPCs. An EPC consists of a strictly alternating sequence of events (“invoice arrived”) and functions (or processes) such as “enter invoice” (hence its name). In addition, alternative or concurrent processes can be specified with the help of connectors (XOR, OR, AND). The model either captures existing processes or specifies planned ones, and it can be employed to reengineer inefficient business processes. The syntax of a standard EPC is given quite accurately by Keller and Teufel (1997). It is generally accepted by the majority of the literature on EPCs. Its 14 rules include: K1: There are no isolated nodes. K3/4: Functions and events have exactly one incoming and one outgoing edge (except start and end events).<br /> <br /> Rittgen • 213<br /> <br /> Figure 4: Ambiguous OR join (on the left), matching split and join (on the right)<br /> <br /> K6: Connectors are either splits (1 input, several outputs) or joins (several inputs, 1 output). K8/9: An event is always followed by a function and vice versa (modulo connectors). Concerning semantics, there is little unanimity. It is given only roughly (in a verbal form) in the original publication by Scheer (1992). Later there have also been attempts to give EPCs a formal semantics, e.g., Chen and Scheer (1994), Rump (1997), and Langner, Schneider and Wehler (1997). But all approaches differ considerably, i.e., they attribute different meanings to the same EPC in many cases. Many of these discrepancies stem from diverging interpretations of the logical connectors, in particular of the (X)OR join. So assuming the join has input paths a and b (like in Figure 4, on the left) the following ambiguities may arise: • Does the (closing) join have a matching (opening) split? If so, the semantics is usually taken to be “wait for the completion of all paths activated by the corresponding split.” But how can we identify a matching split? • If there is no matching split, there are three symmetrical interpretations (i.e., interpretations not distinguishing between a and b) of an OR join (see Figure 4, on the left): 1. Wait for the completion of all activated paths (called wait-for-all). 2. Wait only for the path that is completed first and ignore the second (called first-come). 3. Trigger the outgoing path c on each completion of a or b (called every-time).<br /> <br /> 214 • EMC – A Modeling Method for Developing Web-based Applications<br /> <br /> Figure 5: Making the OR join unambiguous<br /> <br /> Figure 6: A non-alternating sequence of events and functions<br /> <br /> • In the case of no matching split, there is also a problem with the XOR join: should it block if both a and b have been activated or should it operate in every-time mode? The semantical shortcomings mentioned above can be remedied by extending the syntax of the connectors. We suggest allowing the modeler to add a comment flag to a connector. This flag can uniquely identify matching connectors (see Figure 4, on the right), and it may serve to clarify the intended meaning of an<br /> <br /> Rittgen • 215<br /> <br /> unmatched join (see Figure 5). Alternatively, the meaning can also be encoded in the connector symbol itself: a standard OR symbol to denote wait-for-all, a funnel-like trapezoid for first-come and an inverse trapezoid for every-time. Beyond their semantical shortcomings, EPCs also exhibit some deficiencies originating in the syntactical domain. Empirical studies like Speck (1998) have shown that particularly middle and upper management people consider the strict alternation between events and functions as too restrictive. They find it hard to identify the necessary events on an abstract level of process description. We suggest dropping this syntactical requirement as dummy events might always be added later if this proves to be necessary. On a conceptual level, there are good reasons to be able to omit events as Figure 6 shows: if “enter invoice” and “effect payment” are performed as one unit (i.e., uninterruptedly) there is no need for an event to trigger the second activity. A similar reasoning leads us to allow two (ore more) consecutive events (see also Figure 6). If we change the syntax of EPCs as outlined in the last two paragraphs, we arrive at the so-called modified EPCs (or modEPCs).<br /> <br /> THE EVENT-DRIVEN METHOD CHAIN After having effected all the modifications suggested in the previous section, the resulting modEPCs provide an excellent basis for the process model of a web application. A unique and formal interpretation can now be given for any EPC, e.g. in the form of a Petri net (see Rittgen, 1999). Hence modEPCs can be understood unambiguously by the protagonists of the following design phase. This leads to less mistakes in the design model and less backtracking from design to analysis thus fulfilling requirements 3 (faster software development) and 4 (phase integration) of section 1. If we put together modEPCs (process focus), classes with their attributes (structural focus) and the resources (resource focus), we arrive at the Eventdriven Method Chain (EMC). Its syntax is shown in Figure 7. Figure 7: General syntax of an EMC<br /> <br /> 216 • EMC – A Modeling Method for Developing Web-based Applications<br /> <br /> Figure 8: A part of the EMC for the web application of section 2<br /> <br /> The function of a modEPC is now performed by some object and hence called the service (or method) provided by this object. Apart from this, the process part of an EMC, consisting of events, methods, connectors and control flow arcs (dashed arrows), follows exactly the syntax of modEPCs (section 4). The object classes involved in providing the service are linked via a double-headed, solid arrow. A class can have attached to it a list of attributes. Classes are also called the internal resources required by a service because they form an integral part of the information system. An external resource is denoted by an oval. It is connected via a solid line to the method requiring it. Now, classifying objects into classes sharing common attributes and methods is an important object-oriented feature. Together with the characteristics provided by the MEMO-OML (see Frank, 1998), our approach fulfils all requirements of object-orientation and hence point 2 of section 1. But how does EMC work in our example setting? Figure 8 shows a part of the EMC for the order processing within the web application outlined in the second section. We assume that the process is fully<br /> <br /> Rittgen • 217<br /> <br /> Figure 9: Object model (structural focus) for the example (in MEMO-<br /> <br /> automated, i.e., it requires no external resources. Upon the arrival of an order, it has to be entered into the system. This service is provided by the class order but it involves also the class customer because the respective customer has to be recorded in the order. Note: the fact that the service enter order is provided by order and not by customer is not represented in the EMC. Although it would have been possible to distinguish between providing and otherwise involved classes by employing different arrows, we decided against this option because during process analysis the modeler is primarily concerned with conceptual issues such as “who has to do with a service?” and not with the exact role a class plays in performing the service. But the latter information, more precisely the assignment of services to classes, is vital for the following design phase and hence should be expressed in the object model (see Figure 9), i.e., while we are still in the analysis phase. According to the EMC, the attributes of order are order id (e.g., a number) and items (a list of ordered items and quantities). These attributes also constitute the skeleton of the respective class definition in the object model (see Figure 9).<br /> <br /> 218 • EMC – A Modeling Method for Developing Web-based Applications<br /> <br /> After entering the order, it is checked for validity. The outcome of this check is represented by the occurrence of either the event “order OK” or the event “order not OK.” The XOR split denotes that these events are mutually exclusive. In the case of an invalid order, a refusal of the order is generated and sent via email. The items of a valid order, i.e., the software packages ordered by the customer, are delivered (e.g., via ftp) and the bill is prepared. After this, further processing may occur. Note that no attributes are specified for the class refusal. The reason might be that the modeler could not think of appropriate attributes and hence left this to the later stage of developing the object model. On the basis of this EMC, an initial object model can be specified without further thinking: it simply consists of all classes and their respective attributes as found in the EMC. After this, the following steps yield a complete object model: 1. assigning services to objects: from the classes involved in a service, the one providing it has to be selected. There the service is recorded. 2. finding missing attributes: each class is thoroughly examined to check whether attributes have been forgotten, e.g., because they are not necessary in the context of the current EMC. This step is best performed after all EMCs for the application lie before us. 3. identifying potentials for generalization: classes sharing common attributes or services are potential candidates for generalization inheriting these attributes from a common super-class. 4. establishing associations between classes: if more than one class is involved in providing a service, there is usually an association between the involved classes. Starting with the initial object model for the EMC of Figure 8, we assign the services to classes as indicated in Figure 9. The EMC gave no attributes for refusal. Looking at actual orders, bills and refusals stored in our file cabinet, we find that a refusal contains some explanatory text and that all letters carry a date. We update the classes accordingly (step 2), and we generalize them to the super-class document with attribute date (step 3). In the last step, we discover that customer and order are involved in enter order, which leads us to establish an association places between them, where a customer can place arbitrarily many orders (0..n) but an order is placed by exactly one customer (1..1). The black triangle indicates the reading direction: customer places order. In a similar way, bill and refusal are connected to order. Please observe that the redundancy of having some of the information present in both EMC and object model (e.g., classes, attributes and services) helps to check inter-model consistency and thus serves model integration (point 1 in section 1).<br /> <br /> Rittgen • 219<br /> <br /> CONCLUSION AND OUTLOOK EMCs provide a way of an integrated analysis of the major aspects of an information system: its structure, its processes and the required resources. Because the underlying paradigm is object-oriented, it enables a seamless transition to object-oriented design and implementation necessary for the development of web-based applications. This is further supported by the unambiguous process semantics of EMCs. In addition, we assume that users already familiar with EPCs will experience few problems in handling EMCs because they resemble each other closely. The process-driven identification of objects helps modelers with less expertise in object-oriented design to create a complete object model, a task that is both highly abstract and challenging even for “OO gurus.” Put together, these features facilitate an efficient development of web-based applications. But nevertheless, substantial work remains to be done especially concerning the still blank spots in the MEMO matrix. First of all, we need a language to describe goals to be achieved by the information system, the organization and the company as a whole. More important still, the achievement of the IS goals must be reflected in the respective IS models i.e. the defined goals should somehow guide the development of these models in a goal-achieving direction. Some preliminary work regarding the strategy and organization levels has been done already, in particular meta models for value chains (SPM) and organizational charts (OSM). However, the inter-level integration remains to be specified. Syntactical integration only requires some kind of common terminology. It can be established by creating a small meta-meta model in the terms of which the meta models for all languages are defined. Semantical integration, on the other hand, is harder to achieve. A possible approach is the object-oriented reconstruction of all models in MEMO-OML.<br /> <br /> REFERENCES Chen, R. & Scheer, A.-W. (1994). Modellierung von Prozessketten mittels Petri-Netz-Theorie, IWi-Heft 107, Institut für Wirtschaftsinformatik, Universität Saarbrücken. Frank, U. (1997). Enriching Object-Oriented Methods with Domain Specific Knowledge: Outline of a Method for Enterprise Modelling. Arbeitsberichte des Instituts für Wirtschaftsinformatik Nr. 4, Universität Koblenz-Landau. Frank, U. (1998). The Memo Object Modelling Language (MEMO-OML), Arbeitsberichte des Instituts für Wirtschaftsinformatik Nr. 10, Universität Koblenz-Landau. Keller, G. & Teufel, Th. (1997). SAP R/3 prozessorientiert anwenden - iteratives Prozess-Prototyping zur Bildung von Wertschöpfungsketten, AddisonWesley, Bonn.<br /> <br /> 220 • EMC – A Modeling Method for Developing Web-based Applications<br /> <br /> Langner, P., Schneider, Ch., & Wehler, J. (1997). Prozessmodellierung mit Ereignisgesteuerten Prozessketten (EPKs) und Petri-Netzen, WIRTSCHAFTSINFORMATIK, 39(5), p. 479-489. Porter, M.E. (1985). Competitive Advantage: Creating and Sustaining Superior Performance. New York: Simon & Schuster. Rittgen, P. (1999). Modified EPCs and Their Formal Semantics. Arbeitsberichte des Instituts für Wirtschaftsinformatik Nr. 19, Universität Koblenz-Landau. Rump, F. (1997). Erreichbarkeitsgraphbasierte Analyse ereignisgesteuerter Prozessketten, Technischer Bericht 04/97, Institut OFFIS, Universität Oldenburg. Scheer, A.-W. (1992). Architektur integrierter Informationssysteme (2nd ed.), Berlin: Springer. Scheer, A.-W. (1999). ARIS – Business Process Modeling (2nd ed.), Berlin: Springer. Speck, M. (1998). Akzeptanz und Operationalität von EPK in der Modellierungspraxis – ein Erfahrungsbericht aus einem ReengineeringProjekt, Arbeitskreistreffen Formalisierung der EPK, Münster, 03-17, http:// www-is.informatik.uni-oldenburg.de/~epk/treffen_170398/speck.ps.<br /> <br /> Leamy, Ballester & Wright • 221<br /> <br /> Chapter 20<br /> <br /> A UML Representation of U.S. Mutual Fund Servicing as an Iconic Model for Servicing the New EU Equivalent – UCITS Patrick Leamy Offshore Fund Consultant, Boston, Massachusetts George Ballester Mellon Trust Boston, USA Thomas Wright Data Modeling Consultant, Cape Elizabeth, Maine<br /> <br /> A Unified Modeling Language (UML) representation of United States mutual fund servicing is a practical, iconic model for designing the service model for the new European Union equivalent - Undertakings for Collective Investment in Transferable Securities or UCITS. As Rom Harre¢ has argued, iconic models and their subjects are both sub-types of the same super-type. Both inherit the properties of the same supertype. An iconic model is a model that substantively resembles its subject. Humans use iconic models as prototypes when they answer questions about classes and objects in the world. When humans test those answers as explanations of the world, they are not testing linguistic propositions against worldly states. They are Previously Published in Managing Information Technology in a Global Economy, edited by Mehdi Khosrow-Pour, Copyright © 2001, Idea Group Publishing.<br /> <br /> 222 • A UML Representation of U.S. Mutual Fund Servicing «metaclass» GLOBAL INVESTMENT FUND -Cross-Border -Public -Diversified -Open-Ended -... +Sells Fund Shares() +Redeems Fund Shares() +Invests in Transferable Securities() +...()<br /> <br /> Class1 US MUTUAL FUND -Cross-Border -Public -Diversified -Open-Ended -... +Sells Fund Shares() +Redeems Fund Shares() +Invests in Transferable Securities() +...()<br /> <br /> Class2 EU UCITS -Cross-Border -Public -Diversified -Open-Ended -... +Sells Fund Shares() +Redeems Fund Shares() +Invests in Transferable Securities() +...()<br /> <br /> testing things against things. They are testing iconic models against real classes and objects. Both the United States Mutual Fund and the European Union UCITS are sub-types of the same super-type – the Cross-Border, Open End Investment Fund. Whereas the “border” in the U.S. is state borders, the “border” in the EU is Member State borders. Since the U.S. mutual fund business is more than seventy-five years old and has grown into a $4 trillion dollar business with a wellestablished service model, it is a fruitful place to begin when attempting to develop a service model for EU UCITS. Unified Modeling Language (UML) is a good way to describe a service model. Before beginning to build a UCITS service model, some historical background is needed to explain UCITS. The creation of the European Union has been a long process of economic and political evolution. The Treaty of Brussels, on July 1, 1967, created the European Community (EC). The six founding members were Belgium, France, Germany, Italy, Luxembourg and the Netherlands. On November 1993, the Maastricht Treaty transformed the EC into the European Union (EU) - an economic and monetary union, using a single European currency. Nine additional states - Ireland, United Kingdom, Greece, Portugal, Spain, Austria, Finland and Sweden – have joined. Although members of the EU, Denmark, Sweden and the United Kingdom have chosen to remain outside of the EUR zone. Other countries - Cyprus, the Czech Republic, Estonia, Hungary, Poland, Slovenia, Bulgaria, Latvia, Lithuania, Romania and Slovakia - have begun negotiations to join. The great success of the American mutual fund industry has not gone unnoticed in Europe. In December of 1985, the Council of Europe voted to create the European Union equivalent of the American mutual fund – Undertakings for Collective Investment in Transferable Securities or UCITS.<br /> <br /> Leamy, Ballester & Wright • 223<br /> <br /> A UCITS is a “mutual fund,” as the term is understood in the United States. To be a UCITS, a fund must satisfy the following EU regulatory criteria. First, the fund’s sole objective must be the collective investment of monies raised from the public in transferable securities using the principle of risk spreading through investment diversification. The term, “public” is meant to also include high, net worth individuals and institutions. U.S. mutual funds are also allowed to issue institutional investor class shares. Second, the fund must be “open-ended;” it must purchase or redeem issue units on demand from the net assets of the fund. UCITS include UK unit trusts, and continental fonds commun de placement and societe¢ d’investissement a’ capital variable. Close-ended funds, money market funds, capital protected futures and options funds, leveraged futures and options funds, property or real estate funds, and currency funds are not UCITS. This is an important difference between EU UCITS and U.S. mutual funds. The first UCITS Directive, 85/611/EEC (amended by 88/220/EEC), established common EU standards for fund legal forms, fund structure, investment strategy, borrowing-powers, prospectus disclosure, and reporting. The legal form of a UCITS fund can either be that of a unit trust or of an investment company. Whereas a UCITS unit trust fund can issue units of various classes, a UCITS investment company fund can issue shares in multiple classes. U.S. mutual funds also issue different classes of shares. Complex UCITS fund structures - umbrella funds with sub-fund compartments or funds that have different charging structures within a single fund - are allowed. This is not different from the case with U.S. mutual funds. Since the original directive, two draft directives have followed. Neither draft directive has gotten out of the discussion stage. The first draft directive, UCITS II, proposed the inclusion of money market funds and fund of funds, or funds that invest in other funds, in UCITS. In the U.S., a fund of funds is allowed if the investor funds are part of the same fund family as the proposed fund of funds. The second draft directive, UCITS III, proclaims that UCITS funds domiciled in one EU member state, can be sold to the public in another EU member state without further regulatory authorization from that state. UCITS fund promoters are only required to inform the fund domicile regulator what are its EU target markets. Only UCITS marketing must comply with local requirements in that target market. This is not unlike U.S. mutual funds, where state, marketing regulations can be important. A paying agent subject to appropriate authority must be appointed in each target state. UCITS can also be marketed in non-European Union Member States such as Switzerland. It has not been an easy process for EU member states to reach agreement regarding the establishment of UCITS. Unlike the United States, there is no Eu-<br /> <br /> 224 • A UML Representation of U.S. Mutual Fund Servicing<br /> <br /> ropean wide equivalent of the Securities and Exchange Commission. There is no European stock exchange that has the presence that the NYSE and NASDAQ have. While there is only one security settlement institution, DTC, in the United States, there are more than twelve in Europe. There are fifteen different languages to deal with. Before UCITS, European Union funds were mostly bond funds restricted to each nation state. Despite these difficulties, European investors have quickly warmed up to equity funds. The amount of money flowing into European equity funds in May 2000 was three times higher than it was in May 1999. In September 2000, Barron’s reported that Europe’s equity market capitalization reached 80% of nominal 2000 GDP, as compared to 60% in 1999 and 22% in 1990. In August 2000, Moody’s Investors Services alleged that there were some 12,000 registered UCITS in the European Union. Other UCITS information sources consider that number too high. Despite the fact that American mutual fund industry sales have nearly reached a market saturation point, European financial institutions have been busy buying smaller American mutual companies. Italy’s UniCredito recently bought the Pioneer Group. Netherland’s ING bought ReliaStar. Behind these purchases partly lies the European Fund Promoter recognition of the applicability of the U.S. mutual fund servicing model to European Union UCITS. Aware of the opportunities for American mutual fund companies servicing UCITS in Europe, American financial institutions, such as Mellon Trust, Chase, Citibank, Fidelity, Vanguard, Janus, and Goldman Sachs, having established themselves as funds processors in the International Financial Service Center (IFSC) in Dublin. Despite its historical prominence as the European fund, processing center, Luxembourg now faces the prospect of a challenge from Dublin for the claim to be the UCITS processing center for Europe. As Mark Tennant of Chase puts it, “Fund managers are now much more interested in where they can source funds than in where they can invest them.” Two interesting features of UCITS legislation frequently go unnoticed. The first concerns custodians; and the second concerns information technology processing. The Investment Company Act of 1940 requires U.S. mutual funds to use a custodian. The custodian provides safekeeping, trade processing, accounting, and reporting services. Although the majority of U.S. mutual funds employ global trust banks as a custodian, a member firm of a national stock exchange or a central securities clearing system can legally be used. The EU UCITS legislation requires a UCITS fund to use a custodian/trustee that has a registered office in the same EU Member State as the fund; but, there is an escape clause. A UCITS investment company that markets more than 80% of its shares through major, European<br /> <br /> Leamy, Ballester & Wright • 225<br /> <br /> stock exchange can apply for exemption from the custodian requirement. Euroclear’s FundSettle and Clearstream Banking’s Vestima may be taking aim at this exception. U.S. mutual fund companies have developed huge information processing complexes to do mutual fund service processing from multiple processing centers. Software companies such a Sunguard offer robust, mutual fund processing software. Like the U.S. Investment Company Act of 1940, The EU UCITS legislation does not address the location of information processing. The Luxembourg and Ireland UCITS legislation requires that UCITS fund manual administration and control occur within Luxembourg and Ireland respectively. It does not require that the actual information processing systems be there. There is considerable unused fiber optic, data communications capacity under the Atlantic Ocean between the U.S. and Dublin that could easily be used to connect U.S. mutual fund information processing complexes to UCITS fund management companies. S.W.I.F.T., then international bank message network, will add Fund Processing Messages to its ISO 15022 Security Messages in 2001. The Internet, which has long been a major information vehicle for U.S. mutual funds, is becoming an important information vehicle in Europe for UCITs. Mellon Trust is the administrator for the Prudential UK, Egg Internet Fund Supermarket. Chase has just started Fund-Hub with Investia; and Brown Brothers Harriman has begun Fund WorldView. Both Fidelity and Citibank are planning Internet, European fund supermarkets. The U.S. Mutual Fund Servicing Model is built around ten components. Mutual Fund Shareholders join the mutual fund using an Underwriter or Distributor. A Transfer Agent services the mutual fund shareholders. Brokers do the securities trades for the mutual fund. A Custodian safe keeps the assets of the mutual fund and provides due diligence reporting. A Mutual Fund Management Company runs the mutual fund using a Mutual Fund Information Processing Complex. Federal and State Government Regulators regulate the mutual fund. The EU UCITS Servicing Model is built around ten components. UCITS Shareholders join the UCITS fund using an Underwriter or Distributor. A Transfer Agent services the UCITS shareholders. Brokers do the bond and equity trades for the UCITS. A Custodian safe keeps the assets of the UCITS and provides due diligence reporting. If more than 80% of the UCITS shares are on major European stock exchanges, a custodian is not legally required. A Pan European Fund Clearing Service, like Euroclear’s Fund Settle or Clearstream’s Vestima could be used. A UCITS Management Company runs the UCITS using a UCITS Information Processing Complex. The Information Processing Complex does not have to be in the European Union. It could be in the United States. European Union and Member State Government Regulators regulate the UCITS.<br /> <br /> 226 • A UML Representation of U.S. Mutual Fund Servicing U.S. MUTUAL FUND SERVICE MODEL<br /> <br /> Message1() Shareholders<br /> <br /> Message3() Mutual Funds<br /> <br /> Message2()<br /> <br /> Message5()<br /> <br /> Securities Markets<br /> <br /> Message4()<br /> <br /> Message6()<br /> <br /> Underwriters /Distributors<br /> <br /> Brokers<br /> <br /> Message13() Message11() Message12()<br /> <br /> Message14()<br /> <br /> Information Processing Complexes Message16()<br /> <br /> Message18()<br /> <br /> Message15()<br /> <br /> Message17()<br /> <br /> Message7()<br /> <br /> Message8()<br /> <br /> Transfer Agents<br /> <br /> Custodians<br /> <br /> Mutual Fund Management Company<br /> <br /> Message9()<br /> <br /> Message10()<br /> <br /> Federal and State Regulators<br /> <br /> E U U C IT S S E R V IC E MODEL<br /> <br /> M e s s a g e 1 () S h a r e h o ld e rs<br /> <br /> M e s s a g e 2 ()<br /> <br /> M e s s a g e 3 () U C IT S<br /> <br /> S e c u ritie s M a rk e ts<br /> <br /> M e s s a g e 4 ()<br /> <br /> M e s s a g e 5 () M e s s a g e 6 ()<br /> <br /> U n d e rw rite rs /D is trib u to r s<br /> <br /> B ro ke rs<br /> <br /> M e s s a g e 1 3 () M e s s a g e 1 1 () M e s s a g e 1 2 ()<br /> <br /> M e s s a g e 1 4 ()<br /> <br /> In fo rm a tio n P ro c e s s in g C o m p le x e s M e s s a g e 1 8 ()<br /> <br /> M e s s a g e 1 6 () M e s s a g e 1 5 ()<br /> <br /> M e s s a g e 1 7 () M e s s a g e 7 () M e s s a g e 8 ()<br /> <br /> T r a n s fe r A g e n ts<br /> <br /> C u s to d ia n s<br /> <br /> U C IT S M a n a g e m e n t C o m p a n y<br /> <br /> M e s s a g e 9 ()<br /> <br /> M e s s a g e 1 0 ()<br /> <br /> E U a n d M e m b e r S ta te R e g u la to rs<br /> <br /> Leamy, Ballester & Wright • 227 UCITS PAN EUROPEAN CLEARING SYSTEM<br /> <br /> Clearing System Participant UCITS CLEARING SYSTEM<br /> <br /> -Participant ID +Joins Fund() +Quits Fund() +Places Order() +Cancels Order()<br /> <br /> 1 1 UCITS Transfer Agent -Transfer Agent ID<br /> <br /> *<br /> <br /> * CLEARING SYSTEM ORDER<br /> <br /> Participant Acct -Participant ID -Security Acct ID -Cash Acct ID -Fund Activity History Acct +Book Shares() +Credit Cash() +Record Fund History()<br /> <br /> 1<br /> <br /> *<br /> <br /> -Order Ref No -Trade Date -Settle Date +Enter() +Validate() +Approve() +Notify Transfer Agent() +Affirm Order() +Reject() +Settle()<br /> <br /> 1<br /> <br /> 1<br /> <br /> +Rejects Order() +Acknowledges Order() +Confirms Order()<br /> <br /> * *<br /> <br /> 1<br /> <br /> UCITS Paying Agent -Paying Agent ID<br /> <br /> 1<br /> <br /> +Pays Cash() +Receives Cash()<br /> <br /> FUND ORDER -Clearing System Ref No -Fund ID -NAV -Par Amt -Currency -Net Amt<br /> <br /> A Pan European Fund, Clearing Service would potentially use three types of accounts – a securities clearing account, a cash clearing account, and a fund activity history account for reporting purposes. To minimize the chance of a transaction failure, the service would need to reserve the shares and cash about to be sent to the Transfer Agent when shares are subscribed and redeemed. The handling of corporate action events affecting the fund’s underlying bonds and equities is a very important part of such a service. Fund reporting of fund net asset value (NAV) would involve three European time zones. In conclusion, A Unified Modeling Language (UML) representation of United States mutual fund servicing is a practical, iconic model for beginning the design of a service model for the new European Union equivalent - Undertakings for Collective Investment in Transferable Securities or UCITS. UCITS present an important market opportunity for both European and American financial institutions.<br /> <br /> REFERENCES American investing – Feelings are no longer mutual (2000). The Economist, May 20. Aronson, J. L., Harre¢, R., and Way, E. C. (1994). Realism Rescued, Duckworth, London. Bid to exempt marketing of funds hits Brussels e-commerce plans (2000). Financial Times, October 9. Boar, B. (1984). Applications Prototyping, NY: John Wiley & Sons.<br /> <br /> 228 • A UML Representation of U.S. Mutual Fund Servicing<br /> <br /> Clearstream Banking (2000). Vestima Funds-Service, Luxembourg. Cross-Border Distribution of Funds: Hurdles, Opportunities (2000). Securities Industry News, August 28. Cross-Border Sales of mutual funds in Europe ‘set to soar’ (2000). Financial Times, August 21. Ernst & Young (2000). Investment Funds in Luxembourg, Luxembourg, August. Euroclear (2000). A guide to FundSettle, Brussels. EU moves to broaden funds’ investment scope (2000). Financial Times, October 18. EU wants more investment freedom for pension funds (2000). Financial Times, October 2. Fowler, M. (1997). UML Distilled – Applying the Standard Object Modeling Languages, Reading, MA: Addison-Wesley. Friday’s Heated Rally in Europe Probably Has Legs (2000). Barron’s, September 4. Graham, I. (1993). Object Oriented Methods, Reading, MA: Addison-Wesley. Harre¢, R. (2000). Models and Type-hierarchies: Cognitive Foundations of Iconic Thinking, in Paton, R. and Neilson, I. (Eds.), Visual Representations and Interpretations, London: Springer, pp. 97-109. Hobson, D. (2000). A man for all seasons, Global Custodian, Fall. KPMG (2000). Funds and Fund Management 2000, www.kpmg.ie. Lantz, K. (1984). The Prototyping Methodology, Englewood Cliffs, NJ: PrenticeHall. Pioneers tackle distribution issues (2000). Custody & Settlement, June 26-July 2. Pozen, R. (1988). The Mutual Fund Business, Cambridge, MA: The MIT Press. SWIFT to Develop Mutual Fund Standards (2000). Operations Management, September 18. Wilkie, G. (1993). Object-Oriented Software Engineering, Reading, MA: Addison-Wesley. William Fry Solicitors (1996). International Financial Services Centre Dublin Investment Funds, London. ‘Wisemen’ look certain to reject European SEC (2000). Financial Times, September 17.<br /> <br /> Calero, Marcos & Piattini • 229<br /> <br /> Chapter 21<br /> <br /> Relationships Between Relationships: An Empirical Study C. Calero and M. Piattini Universidad de Castilla-La Mancha, Spain E. Marcos Universidad Rey Juan Carlos, Spain Since Chen published the E/R model in 1976, some proposals extending its expressive power have appeared, some of them are based in the preceding semantic models. Thus, currently, some conceptual models allow relationships between relationships and even generalizations of relationships. These proposals could be better understood if relationships are considered as object types allowing other possibilities as, for example, aggregation of relationships. In this chapter, using a modeling example, we will discuss about the benefits of this approach, mainly about the possibility to model simpler conceptual schemata. We also present an empirical study for proving if modeling with relationships between relationships is more difficult than not use them for novice designers. As a result of this study, it seems that complexity is not affected by the kind of modeling selected.<br /> <br /> INTRODUCTION An essential objective in the modeling task is reducing the gap between a specific universe of discourse and its conceptual representation. As Jesse et al. (1996) state“...the level of abstraction that we can speak directly affects the Previously Published in Managing Information Technology in a Global Economy, edited by Mehdi Khosrow-Pour, Copyright © 2001, Idea Group Publishing.<br /> <br /> 230<br /> <br /> • Relationships Between Relationships: An Empirical Study<br /> <br /> size of the problem we can solve.” In order to enrich the representational power of the conceptual models, database community has been extending the E/R model proposed by Chen (1976). Different extensions as Batini et al. (1992), Elmasri and Navathe (1994), Atzeni et al. (1999), improve the E/R models adding concepts as generalisation. Other extensions are based on object-oriented concepts (Rumbaugh et al., 1991) including, for example, the aggregation concept. In this paper we argue about some extension of the relationship concept. E/R model supports relationship between entities with attributes. Different relationship improvements have been offered, for example MERISE (Morejon, 1994) allows modeling using relationship between relationships and generalizations of relationship. UML (Booch et al., 1997) supports a special kind of class, the “association class.” This class, attached to an association, allows supporting the concept of relationship between relationship directly supported by other models as MERISE. The concept of relationship between relationship is not a new concept, it was backed up by some semantic models as KL-ONE (Brachman and Schmolze, 1985). In our opinion, it is a pity that this capacity is not generally supported by commercial CASE tools. Recently, some conceptual models (Pirotte et al., 1994; Boch and Odell, 1997) and implementation models (Díaz and Paton, 1994) consider relationship as object types. If relationships are objects they can have attributes, methods (in object-oriented models), relationship with other relationships, generalizations and, as well as aggregations. In addition to claiming for models that support the capacity before mentioned, the main goal of this paper is to argue about the benefits of considering relationships as object types in the conceptual modeling. Firstly, we’re going to model an example, using this capacity and discussing the benefits of this solution with regard to other approaches. Afterwards, we are going to pose the results of an experiment with a group of students which tries to demonstrate that this new constructor does not imply a more complex way of modeling. The rest of this chapter is organized as follows: in the next section, through a modeling example, we state the benefits of considering relationships as object types; the third section is the experiment; finally, in the fourth section, we sum up the main conclusions.<br /> <br /> RELATIONSHIPS BETWEEN RELATIONSHIPS In this section we discuss the advantages of considering relationships as object types in conceptual modelling. A conceptual schema for the library of a university is used as an example. Figure 1 sums up the library requirements. For the discussion we are going to use MIMO (Marcos, 1997), a model which improves<br /> <br /> Calero, Marcos & Piattini • 231<br /> <br /> Figure 1: Requirements of a University library<br /> <br /> Figure 2: Loan as an entity<br /> <br /> Figure 3: Loan as a relationship<br /> <br /> Figure 4: Loan as two different relationships<br /> <br /> 232<br /> <br /> • Relationships Between Relationships: An Empirical Study<br /> <br /> Figure 5: Loans as a generalisation hierarchy<br /> <br /> the E/R model with new object-oriented concepts. There are different possibilities to model this example. Figure 2 shows one of the possible solutions that considers loan as an entity. The conceptual schema proposed in this solution expresses all the semantic constraints defined in the requirements. An alternative solution is considering loan as a relationship rather than as an entity. A first approach is shown in figure 3. However, this schema does not represent all the requirements. Thus, the restriction of requirement 3, only teachers can borrow department books, has to be expressed in an additional notation (e.g., through a constraint language). In order to preserve this requirement in the schema, see Figure 4, we can define two different loan relationships: one between book and teacher and another between student and general book. In this case, we have two different relationships which have the same characteristics (loan date, giving back date...). In spite of these relationships has a strong relation because they refer to the same concept, the schema does not reflect this fact. This weakness could be solve introducing relationship generalisations, as it is shown in Figure 5. This solution, just as the solution in Figure 2, gathers all the requirements of the example. However, in our opinion and in a intuitive way, the solution of Figure 5 seems to be simpler than the solution of Figure 2. It would be necessary to have some technique for selecting the best one based in something different to intuition, and a good way is by making an experiment. So, we prepared an experiment with the objective to know if both kinds of modeling have the same complexity.<br /> <br /> EXPERIMENT In the past, empirical validation has been a relaxed process relying on the credibility of the proposer. Now, things are changing and many researchers and<br /> <br /> Calero, Marcos & Piattini • 233<br /> <br /> practitioners assume that a subjective information based only in the experience is necessary but not sufficient. They expect the empirical validation to demonstrate that the assumptions made or supposed are right. As Basili points out, software engineering is a laboratory science, but there is insufficient analysis and experimentation (Basili, 1999). Typically experimentation is looking for a relationship between two variables, such as process and product characteristics, and may be performed for many purposes: to study process effects, product characteristics, environmental constraints (cost or schedule). Besides, it is necessary to combine experiments to build a body of knowledge that is useful to the discipline. Useful results of a experimentation depend on careful, rigorous and complete experimental design. There are a lot of ways to made empirical validations but basically we can divide it in two: experimentation and case studies. The experimentation is usually made using controlled experiments and the case studies usually work with real data. Both of them are necessary, the controlled experiments for having a first approach and the case studies for making the results stronger. The goal of our experiment is to prove the practical utility of the new kind of relationship we have presented. Our intention is to prove that there is no difference for the user between both alternatives. So, in this case, we can derive that if both are valid ways to make the design it will be logical to use the simpler one. The next question is, can I know which one is simpler?. To answer this question we can use metrics. Metrics are useful mechanisms for controlling, among others the complexity. In our case we will use two metrics for conceptual modeling proposed by Genero et al. (2000) the number of entities and the number of relationships. These two metrics can be used for measuring complexity, in this way, lesser are the values of these metrics, lesser is the complexity of the conceptual modeling. In the rest of this section, we summarize an experiment done in order to prove if any of both kind of relationship models is more complex that the other one. The experiment has been prepared using the steps described in Pfleeger (1995), that is, listing of the hypotheses; description of the subjects; description of the material conforming the experiment; design guidelines; and finally, checking the results against the initial hypotheses. Our final purpose is to prove that there is no difference using any of both models presented, that is, both of them have the same complexity to understand and to use. If we can arrive to this conclusions, the only way to choose the best one (the simpler one, the easier to maintain...) will be by using the metrics. Initial hypotheses • Null hypothesis: Using a different kind of relationships in the conceptual sche-<br /> <br /> 234<br /> <br /> • Relationships Between Relationships: An Empirical Study<br /> <br /> mata does not influence its comprehension • Alternative hypothesis 1: Using a different kind of relationships in the conceptual schemata influences its comprehension Subjects The participants in the experiment were final-year (undergraduate) Computer Science students at the University of Castilla-La Mancha, who were enrolled in a one-semester advanced database course. The students were familiar with databases. The students were unaware of the experiment, till the very same day of its conclusion. Sixteen students participated in the experiment. Experimental materials Four documents were prepared, 1. a document with a conceptual schema do not using relationships among relationships. 2. the question/answer paper with eleven questions with a boolean answer. Each question ask about a possible relationship between entities of the schemata trying to obtain if it was a valid relationship or not. Like this, when the answer was correct, it would be because the relationship was understood, and if the answer was incorrect, it would be because it was not understood. 3. a document with a conceptual schemata using relationships among relationships. 4. the question/answer paper with eleven questions with a boolean answer. Each question ask about a possible relationship between entities of the schemata trying to obtain if it was a valid relationship or not. Like this, when the answer was correct, it would be because the relationship was understood, and if the answer was incorrect, it would be because it was not understood. A handout was given to each student, and the time spent in each test was recorded. A preliminary experiment was led with a different and smaller set of students to improve the final version. Although both schemas (using relationships among relationships and don’t using them) were semantically equivalents, students didn’t know it. The basic difference between both were the names used for relationships and entities and the value of the number of entities and relationships: five entities and three relationships when using relationships among relationships and nine entities and four relationships without relationships among relationships. Experimental design The experiment attempts to prove if using relationships among relationships step up the difficulty of understand the conceptual schema. We have a variance<br /> <br /> Calero, Marcos & Piattini • 235<br /> <br /> study because we have related samples of sixteen subjects, so we have that the results obtained from the experiments are correlated and that the study we must made is a contrast of hypothesis for two variances. Independent variables The independent variable is the kind of relationship used. In one case we had a model without relationships between relationships and in the other one we had a model with relationships between relationships. Dependent variables In our experiments, we want to control the complexity of both models we are testing. One way to do this it is controlling the understandability by measuring the time spent in each case to answer the questions related with each one of both models. So, since what we wanted to measure is if conceptual modeling don’t using relationships among relationships is easier than using them, we decided to give our subjects as much time as they needed to finish the tests they had carry out. This way, our study would focus on the different amounts of time needed for the completion of the tests of the experiment. In each test, time was annotated by the subject in the question/answer paper from the moment the test was displayed to the moment the subject finished. Controlled variables We have tried to minimize variability among participants choosing students from the same degree and with the same experience in databases. Effects of irrelevant variables were minimized by making the same trials for all the subjects. Procedure Experiments were made consecutively during an hour session. Subjects assume responsibility for annotating the starting and the ending hour in each test. Both tests were made in different order by the subjects (half of them made first the test related with the conceptual modeling using relationships among relationships and the other half started with the classic conceptual modeling) to prevent apprenticeship effects. Experimental results There are three major items to consider when choosing the analysis techniques: the nature of the data collected, the motivation for performing the experiment, and the type of experimental design used (Pfleeger, 1995). As we have already indicated, we have a contrast of hypothesis for two variances. Due to these characteristics, the t statistic is the technique that we must<br /> <br /> 236<br /> <br /> • Relationships Between Relationships: An Empirical Study<br /> <br /> Table 1: Results of the t-statistic for the experiment<br /> <br /> apply for obtain the results (Rohatgi, 1976). Table 1 shows the results for the t-statistic. In this table, the first column represents each one of both tests made by the students, column two the variance of the population. The third column represents the variance of the sample and the last one indicates the result obtained for the t-statistic for our experiment, this value must be compared to the value in the t-statistical table. Power of a statistical test is dependent on three different components: a (error margin), the size of the effect being investigated and the number of subjects. Since the effect size and the number of subjects are constants, increasing a is the only option for increasing the power of the test applied. This way, we choose a value α=0,01 (99% level of confidence). This way, with α=0,01, we look for the statistic value in tables where the numerator is 0.995 (1 - α/2 ) and the denominator is 14 (n-2), seeing that the value is t0.995,14=2.9764. Comparing the values obtained from the experiment with t0.995,14, we can ensure that as: tobserved > / t0.995, 14 We must accept the null hypothesis so, both kinds of representation have the same variance and so the type of representation does not influence the understandability of the conceptual modeling. Following these results there is no reason for do not use any one of both models presented. So, we need other factor for selecting the easier one. One way to take this decision is by using metrics. Metrics are useful mechanisms for controlling complexity. In this way, we can work with metrics for conceptual modeling for trying to select the best model. Metrics used As we have said we need metrics that measure the complexity of a conceptual modeling. The metrics we have selected are the proposed by Genero et al. (2000): Table 2: Values for the metrics<br /> <br /> Calero, Marcos & Piattini • 237<br /> <br /> Number of entities. Defined as the number of entities for a conceptual model Number of relationships. Defined as the number of relationships in a conceptual model. In table 2 we present the values of the metrics for each one of both examples we worked with in the experiment: So, as the test which doesn’t use relationships among relationships have more entities and more relationships than the other one (remembering that both are semantically equivalents), it seems to be better to use the model with relationships between relationships. However, this is only a first study and it would be necessary to made more experimentation, replicating this same experiment, making other controlled experiments and finally, working with real data to have more solid conclusions.<br /> <br /> CONCLUSIONS In this paper we have argue about the benefits of using relationships between relationship in conceptual modeling. We have presented an experiment and we have prove that it seems that there is not difference of complexity between both models. So, we have used metrics for selecting the easier one and we have concluded that using relationships between relationships is less complex from the metrics point of view. As a conclusions of both techniques (the experiment and the metrics application) we can conclude that the model which use relationships between relationships seems to be easier to understand than the other one. However, this is only a first study and it is necessary to replicate it and to made more controlled experiments for having more reliable results.<br /> <br /> ACKNOWLEDGMENT This study has been done during the staying of Coral Calero at the University Rey Juan Carlos for her PhD studies.<br /> <br /> REFERENCES Atzeni, P., Ceri, S., Paraboschi, S. and Torlone, R. (1999). Database Systems: Concepts, Languages and Architectures, McGraw Hill. Basili, V. R (1999) Using experiments to build a body of knowledge, 20/1/99, Madrid, España. Batini et al. (1992). Conceptual Database Design: An Entity Relationship Approach. Benjamin/Cummings. Bock, C. and Odell, J. (1997). A More Complete Model of Relationship, Journal of Object-Oriented Programing. SIGS Publications, June, 10(3), pp. 38-40, 47.<br /> <br /> 238<br /> <br /> • Relationships Between Relationships: An Empirical Study<br /> <br /> Booch, G., Rumbaugh, J. and Jacobson, I. (1997). Unified Modelling Language, V1.0, Rational Software Corporation, January. Brachman, R. J. and Schmolze, J. G. (1985). An Overview of the KL-ONE Knowledge Representation System, Cognitive Science 9, pp. 171-216. Chen, P. (1976). The Entity/Relationship Model: Toward a Unified View of Data. ACM Transactions on Database Systems, 1(1), March. Chonoles, M. J., Schardt, J. A., and Magrogan, P. J. (1996). Speaking of Methods, Report on Object and Analysis Design; SIGS Publications, March-April, p. 8-12. Díaz, O. and Paton, N. (1994). Extending ODBMSs Using Metaclasses, IEEE Software, May, pp. 40-47. Elmasri and Navathe (1994). Fundamentals of Database Systems, AddisonWesley. Genero, M., Piattini, M. and Calero, C. (2000). An approach to evaluate the complexity of conceptual database models. The 3rd European Software Measurement Conference, FESMA - AEMES 2000. Morejon (1994). MERISE: Vers une modélisation orientée object. Les Éditions d’Organisation. Pfleeger, S.L. (1995). Experimental design and analysis in software engineering. Annals of Software Engineering, 219-253, JC Baltzer AG, Science Publishers. Pirotte, A., Zimányi, E., Massart, D., and Yakusheva, T. (1994). Materialization: a powerful and ubiquitous abstraction patter, in J. Bocca, M. Jarke and C. Zaniolo (Eds.), Proc. of the 20th Int. Conf. on Very Large Data Bases, VLDB’94, Morgan Kaufmann, p. 630-641. Rochfeld (1992). OOM: évolution de MERISE vers une aproche object. Journées AFCET Ingénierie des bases de données. Rohatgi, V.K. (1976). An introduction to probability theory and mathematical statistics. Wiley Series in Probability and mathematical statistics. Rumbaugh et al. (1991), Object-Oriented Modeling and Design. Englewood Cliffs, NJ: Prentice-Hall.<br /> <br /> Kovach & Fertalj • 239<br /> <br /> Chapter 22<br /> <br /> Informationbase – A New Information System Layer Dragan Kovach SUPER-KING Inc., Croatia Kresimir Fertalj University of Zagreb, Croatia<br /> <br /> In the paper, the concept of informationbase (IB) is described. The IB is a top layer of the information system (IS). The IB layer uses information systems database and existing application programs to provide a structured set of reports and graphs, directly and permanently available to the user. The informationbase described in the article acts as an intelligent and very agile information manager. At appropriate times, it activates predefined options for report generation, supplies the reports with parameters, stores generated information into a well-organized database and manages the authorization of information retrieval.<br /> <br /> INTRODUCTION Formally, information is a collection of symbols. Within an IS, information can be presented by a collection of various data purposefully and meaningfully organized into a report or graph. In the database of an IS, one has the data, that is only the raw material for the information. Thus, the meta-base aimed to store the information collections, which is described in this article, is referred as informationbase (IB). One of the IS myths is Just enter a command and you will get the information you need. In reality, to get an information, the user needs: Previously Published in Managing Information Technology in a Global Economy, edited by Mehdi Khosrow-Pour, Copyright © 2001, Idea Group Publishing.<br /> <br /> 240 • Informationbase<br /> <br /> • to browse through the menus in order to find the option one needs, • to understand the capabilities of the option and to enter the parameters required by that option, which requires some skill and effort, • to execute the option and … • … to wait to get the required information. The IB concept, described in this article, changes that completely, i.e. makes the myth true - the user gets the information directly and instantly. The concept is based on the following thinking: all relevant information concerning the scope covered by the IS should be automatically generated and must always be readily available to the users, instead of being ad hoc produced by individuals. Thus the information as the final product of an IS should really (rather than potentially) be available to the users of the information system.<br /> <br /> THE CONCEPT OF THE INFORMATIONBASE The informationbase is a set of reports and graphs generated in advance and ready to be used. It can be built for the customer’s organization and one calendar year. For each year, a new IB is to be formed and several informationbases can be kept in the system. The model of the informationbase The information contents (Information) are classified in two hierarchical levels (Chapter and ChapterEntry), as presented by the simplified logical model in Figure 1: The simplified IB model Chapter ChapterId<br /> <br /> ReportDefinition ReportId<br /> <br /> ChapterTitle OptionNo<br /> <br /> Template ChapterEntry<br /> <br /> TemplateId<br /> <br /> ChapterId (FK) EntryId TemplateId (FK) ReportId (FK) SectionTitle OptionNo DateInterval TimePeriod NDays TimeActivator<br /> <br /> Information ChapterId (FK) EntryId (FK) InformationContent<br /> <br /> Parameter ParamerId ChapterId (FK) EntryId (FK) TemplateId (FK) ParameterTypeId (FK) ParameterValue<br /> <br /> ParameterType ParameterTypeId<br /> <br /> Kovach & Fertalj • 241<br /> <br /> Figure 1. Chapters and chapter entries are defined by titles, which represent the IB menu options. Option number (OptionNo) defines the position of that option within a menu. Although each IB can have a number of chapters, the set of chapters should be limited to some extent in order to assure easy navigation through the IB. The organization of chapters and sections is not fixed and can be defined by the user. Having in mind that this may require some expert knowledge a default structure of the IB should be offered to the user, who could adapt it later. The information contents are generated based on predefined reports (ReportDefinition) and then stored into the informationbase (Information). For each chapter entry, the following special parameters are to be stored: Type of date interval: Reports can be made for some period. Date interval can refer to: • date of data entry, • document date, • financial relation (obligation) start date, • payment due date, • financial month/year, • planned due date, • order delivery date, • etc. Relative report time period: Time period can be, for instance: • yesterday, • today, • previous month, • current month, • current year up today, • current year up to the end of previous month, • etc. An additional parameter “+/- N days” (NDays) can be set. This parameter can be used to adjust the relative period at the time of report generation. The IB report driver can use the NDays to compute the time limits for “yesterday”, “previous month” etc. Generation of a particular report is driven by a set of parameters (Parameter). Each parameter can be assigned to a predefined parameter type (ParameterType). Parameters can be used to filter the original data (e.g., by document types, by organizational units), to sort and group the data and to limit the size of results (e.g., to first N rows). The sets of parameter values can be saved as templates (Template) that are used for later manual updates and/or automatic generation of information.<br /> <br /> 242 • Informationbase<br /> <br /> The generation of IB contents Information contents can be generated automatically and/or manually and the resulting contents are stored into the IB. There are three ways to update the IB: • Manually: the user generates an ad hoc report, which can be stored in selected IB chapter. • Semiautomatic: the user starts the option for the automatic update of the whole IB or the automatic update of a particular IB part. • Automatic: the process of report generation is triggered automatically. For instance, the generation can occur every day at specified time. When the information contents are generated automatically, the aforementioned parameters and templates are used for each entry that is going to be updated. The generation process can be tuned by time activators. The time activator triggers the automatic update of chapter entry and can be set for: • a calendar day, • a calendar month, • a calendar year, • a financial month, • etc. In this way, some reports are produced daily, some monthly, etc. When an automatic IB update has been started, the IB manager: • scans the time activators, • checks which entries are to be updated, • runs appropriate application programs for report generation, supplying them with predefined parameters, • finally, updates the IB. Access to the IB can be controlled by the authorization system, which can be part of IB manager.<br /> <br /> PRACTICAL OBSERVATIONS The IB concept has been implemented in TOMAS (TOtal MAnagement System), an enterprise resource planning (ERP) software, developed by SUPERKING Inc. from Zagreb, Croatia. In Croatian version, the name of the software is SUPER (Sustav Upravljanja Poslovanjem Elektronièkim Raèunalom). TOMAS was put into production in several Croatian firms. Standard IB TOMAS offers a standard (default) IB, with an initial classification of chapters and entries and all parameters ready made. An example of some standard chapters and entries is shown in the following tables.<br /> <br /> Kovach & Fertalj • 243<br /> <br /> Table 1 TOMAS - Informationbase : C H A P T E R S Organization : 30 CROATIA - INVEST Inc. Commerce 1 SALES 2 PURCHASING 3 INVENTORIES Manufacturing 4 PRODUCTION PLAN 5 PRODUCTION CONTROL<br /> <br /> Year : 1999 Finance<br /> <br /> 6 7<br /> <br /> Accounts: RECEIVABLES PAYABLES<br /> <br /> 8 COST CONTROL 9 BALANCES 10 FINANCIAL ANALYSIS<br /> <br /> Table 2 T O M AS - In form ationbase : S A L E S O rganization : 30 C R O A T IA – IN VE ST Inc. 1 2 3 4<br /> <br /> S AL E S O R D ER S In previous m onth In current m onth W ith due date in up to 10 days Late for m ore than 10 days<br /> <br /> 5 6 7<br /> <br /> S ales o rd ers su m m ary b y: B uyer C lass of product P roduct<br /> <br /> 8 9<br /> <br /> B ar charts: V alue of orders O rdered quantities<br /> <br /> P R IC E C O N T R O L 10 S ales price m ovem ents 11 List of invoice prices 12 A ctual/plan prices<br /> <br /> Year : 1999<br /> <br /> 13 14 15 16 17<br /> <br /> AC T U AL S ALE S Yesterday T oday C urrent m onth P revious m onth Year to previous m onth<br /> <br /> 18 19 20 21<br /> <br /> AB C an alysis b y: W arehouse B uyer C lass of product P roduct<br /> <br /> P erio d s com pariso n b y: 22 B uyer 23 P roduct B ar ch arts: 24 V alues for m onthly sales 25 Q uantities for m onthly sales<br /> <br /> 244 • Informationbase<br /> <br /> Table 3 TOMAS - Informationbase : P R O D U C T I O N C O N T R O L Organization : 30 CROATIA - INVEST iNC.<br /> <br /> Year : 1999<br /> <br /> PRODUCTION CAPACITY USAGE 1 Summary of capacity usage 2 3 4 5<br /> <br /> UNFINISHED WORK ORDERS 10 List of work orders 11 Work orders older than ... days<br /> <br /> Capacity usage by: Organizational unit Foreman Work center Worker<br /> <br /> Work orders finished: 12 Yesterday 13 Today<br /> <br /> Finished product entries in warehouse: SUMMARY OF PRODUCTION COSTS BY 14 Yesterday 15 Today 6 Product class 16 Current month 7 Product 8 Work center 9 Work orders with cost balance > ...%<br /> <br /> Table 4 TOMAS - Informationbase : F I N A N C I A L A N A L Y S I S Organization: 30 CROATIA - INVEST Inc.<br /> <br /> Year : 1999<br /> <br /> Planned vs. actual results: 5 Why profit has been changed 1 Company as a whole 2 Organizational units 6 What is required to increase the profit 7 What if ... Key business indicators: 3 Company as a whole 4 Organizational units<br /> <br /> Kovach & Fertalj • 245<br /> <br /> The standard IB in TOMAS provides the users with dozens of parameters and has capability of producing billions of report variations per chapter entry, depending on parameter values. The user can change defaults or even create a new IB from scratch hence no programming is involved in this process. However, the initial adaptation should be carried out with help of IS professionals. Advantages of the IB For ERP software such as TOMAS, IB concept brings the following advantages. Information is comprehensive and carefully structured: Information is usually organized in approximately a dozen chapters and 200 reports altogether, which cover all aspects of business in various ways, such as: • summarized by relevant entities (materials, vendors, etc.), • applied to typical time segments (yesterday, today, current month, current year, etc.), • presented as ABC analysis, i.e., sorted by relevant value, • due dates approaching in forthcoming period, e.g., orders to be delivered, • due dates that are already late, e.g., undelivered orders or unpaid invoices, • exceptions to the rules, e.g., inventories below minimum. In general, what is going to be stored in the IB depends on the potential of the particular IS and on users’ needs, apart from the IB. Still, whatever the quality of an IS is, the IB concept makes possible that full potential of the system is carefully structured, completely transparent and available to the users. Without the IB, the IS is much more difficult to grasp. Full availability and direct use of information: The IB user gets the information personally, without intermediates, at any time and from any place (remote access and/or via Internet). Only the basic computer literacy is required. The requested information is immediately available because it is generated in advance. Information is always up to date hence the report generation and the IB updates are done automatically. The IB directs attention of the users: Titles of chapters and chapter entries indicate the aspects to be scrutinized, and lead the user to the desired information even when he/she has no idea what to look for. Minimized efforts and costs: Information is generated automatically. Once being produced, it can be used by many users simultaneously, so both the human resources and the computer resources are spared.<br /> <br /> 246 • Informationbase<br /> <br /> Users’ acceptance of the concept Briefly, the users’ acceptance and reactions to the informationbase can be classified as follows. The IB is very well accepted by: • the managers and owners, even when they are totally computer illiterate, which is most often the case, • the financial officers responsible for management reporting, hence their job can be done much easier, • the middle management, e.g. sales managers, who control daily operations. The IB is less used by: • the very experienced users of TOMAS – they often prefer to directly use the standard reporting features and to generate ad hoc reports, • other users, particularly those performing daily transactions.<br /> <br /> CONCLUSION The IB is a new IS layer, which uses the IS database and application programs in order to maintain the final product of the IS – the information. The information is comprehensive, carefully structured and legibly presented, permanently up to date and available to the users. The IB concept makes possible that the users and the most important ones, the managers, can forget about all intricacies of the IS. All one needs to do is to enter the IB menu and select the entry for the required information. The IB concept brings forward a sort of IS management that makes the full potential of the IS more visible, its use much easier and its operation more efficient.<br /> <br /> REFERENCES Auer, T. (1988). Quality of IS use, European Journal of Information Systems, 7(3), 192-201. Awad, E. M. (1985). Systems Analysis and Design, Irwin, Inc., Homewood, Illinois. Fertalj, K. (1997). An improvement of methods to accelerate and standardize the software application production, Ph.D. Thesis (in Croatian), ZPM FER, Zagreb, Croatia. Grimshaw, D.J., Mot, P.L. and Roberts, S.A. (1997). The role of context in decision making: some implications for database design, European Journal of Information Systems, 6(2), 122-128.<br /> <br /> Kovach & Fertalj • 247<br /> <br /> Senna, J.A. and Olson, D.H. (1996). Decision support for the administrative man: a prototype DSS case, European Journal of Information Systems, 5(1), 10-23. Watts, S. H. (1989). Managing the Software Process, Addison-Wesley Publishing Company, Inc. Willcocks, L. P. and Lacity, M.C. (1998). Strategic Sourcing of Information Systems: Perspectives and Practices, John Wiley & Sons Ltd.<br /> <br /> 248 • A Comparison of Stochastic Models<br /> <br /> Chapter 23<br /> <br /> A Comparison of Stochastic Models for the Interarrival Times of Packets in a Computer Network Dennis Guster St. Cloud University, USA Semyon Litvinov Penn State - Hazelton, USA Mary Richardson Grand Valley State University, USA David Robinson St. Cloud State University, USA Because of the complexity and over-subscription of today’s networks, the importance of valid simulation techniques to aid in determining sound network design is paramount. A number of studies have shown that the theoretical exponential packet interarrival rates are not appropriate for many network installations. This chapter compares two other 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. The Markov chain model, although not perfect, yielded some promising results.<br /> <br /> Previously Published in Managing Information Technology in a Global Economy, edited by Mehdi Khosrow-Pour, Copyright © 2001, Idea Group Publishing.<br /> <br /> Guster, Litvinov, Richardson & Robinson • 249<br /> <br /> INTRODUCTION The past decade could be classified as the “decade of connectivity;” in fact, it is commonplace for computers to be connected to a LAN, which in turn is connected to a WAN which provides an Internet connection. On an application level this connectivity provides access to data that even five years earlier was unavailable to the general population. This growth has not occurred with out problems, however. The number of users and the complexity/size of their applications continue to mushroom. Many networks are over subscribed in terms of bandwidth especially during peak usage periods. Often network growth was not planned for and these networks suffer from poor design. Also the explosive growth has often necessitated that crisis management be employed just to keep basic applications running. Whatever the source of the problem it is clear that proactive design and management strategies need to be employed to optimize available networking resources. Obviously one way to increase network bandwidth is to increase the speed of the links. However, this may not always be practical due to cost or implementation time. Furthermore, this solution needs to be carefully thoughtout because increasing speed in one part of a network could adversely effect response time in another part of that network. Another solution would be to optimize the currently available bandwidth through programming logic. Quality of service and reservation band with are two popular methods currently being utilized. Implementation of these optimization methods is rarely simple and often requires a high degree of experimentation if they are to be effectively configured (Walker, 2000). This experimentation can have detrimental effects on a live network often taking away resources from mission critical applications. Therefore, the most efficient way to ascertain the potential benefit and derive baseline configuration parameters for these optimization methods is through simulation. Simulation can also be very effective in planning a network design. For example, what if network link #3 was increased to 100Mbs? Would workstations on that link experience an improvement in response time? What would happen to workstations on the other part of the total network? Simulation has been used for many years in network design, however the time and cost of its use have often been prohibitive. In recent years new windows based point and click products such as Comnet III have eliminated the drudgery and the cost of writing simulations via a command line interface (CACI Comnet III Reference Manual, 1998). Under Comnet III the appropriate devices are selected, connected together and their characteristics defined. There is still a limiting factor in this process: the definition of the distribution of the packet interarrival rates.<br /> <br /> 250 • A Comparison of Stochastic Models<br /> <br /> The theoretical model often used to describe computer networking is the Poisson. This model may have been adequate for some of the first single tier, single protocol networks. However, it lacks validity in today’s heirarically complex multi-protocol networks. A number of studies confirm that the expected interarrival distribution of packets is not exponential as would be expected in the classical M/M/S model (Krzenski, 1998; Partridge, 1993; Vandolore, Babic and Jain, 1999; Guster, Robinson and Richardson, 1999). The interarrival distribution selected can have a major impact on the results of the simulation. In a study by Krzenski (1998) that analyzed the simulated performance on a shared Ethernet network twelve different interarrival distribution were tried within the same simulation problem. There were vast dicrepanies in the results. For example the number of collision episodes varied from 310 with a gamma distribution to 741 with an integer distribution. These results further support the need to have the correct distribution in simulations designed to provide design and management feedback about computer networks. The frustration of the past work and the need for additional research is best summarized by Partridge (1993) “…We still do not understand how data communication traffic behaves. After nearly a quarter of a century of data communication, researchers are still struggling to develop adequate traffic models. Yet daily we make decisions about how to configure networks and configure network devices based on inadequate models of data traffic. There is a serious need for more research work on non-Poisson queuing models.<br /> <br /> PAST METHODOLOGIES A number of different strategies have been employed in the development of non-Poisson queuing models. One method involves viewing the observation interval as containing several independent Poisson processes rather that as a single exponential distribution. In a study by Guster et al. (1999) actual data was analyzed and shown to contain three Poisson processes of differing characteristics. During the first phase activity was increasing. During the second phase activity was decreasing. The last phase followed a classical Poisson model. For each phase, a power law process model was fit to the data, indicating the nature of the changing traffic intensity (b<1 – decreasing intensity, b=1 – constant intensity). This data was taken over a 24-hour period. The three phases had widely different levels of traffic intensity. In a shorter time frame, for example ten minutes, one is less likely to see differences in intensity that dramatic. Thus, the power law process model is most appropriate for longer time frames. A second strategy focuses on the influence any given data point has on later data points. In other words, does knowing the magnitude of the packet interarrival<br /> <br /> Guster, Litvinov, Richardson & Robinson • 251<br /> <br /> rate at any point in the time interval make it easier to predict the next interarrival time? Historically, there has been a tendency to apply statistical treatments such as regression, ANOVA, or time series analysis to categorize or forecast interarrival trends (Frieberger, 1972). These methods have proved to be limited in accuracy for modeling interarrival rates and require large truly representative databases from which to calculate results. Therefore, the attractiveness of methodologies such as Markov chains that use a more independent technology is apparent. Specifically Markov chains require only the previous data point to determine the probability of subsequent data points increasing or decreasing (Guster and Robinson, 2000).<br /> <br /> PURPOSE In order to analyze the effectiveness of the two methodologies on a common data set a series of files containing the interarrival rates of Ethernet traffic will be examined. The data from each file will be the actual data and three different predictive models will be derived from it. First, an exponential model that represents the theoretical distribution suggested by queuing theory will be determined. Second, a power law process model will be generated which is representative of the multiple Poisson processes methodology. Last, Markov chains will be used to devise a model that is representative of the independent data point method. Therefore, the purpose of the chapter is to determine which of the three methods is most effective in modeling the interarrival rate of Ethernet packet traffic.<br /> <br /> DATA COLLECTION To obtain the data for this study, a computer network test bed was configured that allowed workload characteristics to be replicated. A workload generation machine running Netperf software sent a TCP stream across the network to the monitor machine. This monitor machine trapped each arriving packet, timestamped it and stored it in a file that was used in the analysis. The trial length was set for 10 minutes. Interarrival times were computed from the time-stamps contained in the Ethernet data file.<br /> <br /> DISTRIBUTION ANALYSIS The empirical distribution of the interarrival times is pictured in Figure 1. Note the prominent spikes in the distribution. This makes a fit to the commonly-used exponential distribution dubious. During the ten minute (601.24 seconds) segment, 529,236 interarrival times were measured for an average of 880.24 arrivals per second. This would be the estimated parameter in an exponential fit, with a<br /> <br /> 252 • A Comparison of Stochastic Models<br /> <br /> Figure 1 9000<br /> <br /> Counts from Data<br /> <br /> 8000 7000 6000 5000 4000 3000 2000 1000 0 0.0<br /> <br /> 0.5<br /> <br /> 1.0<br /> <br /> Time in mSec<br /> <br /> mean interarrival time equal to the reciprocal of this number, or 1.136 milliseconds between arrivals. To assess goodness of fit of a given model to the actual data, simulations were run based on the classical model with its estimated parameters. The interarrival times of the simulation were then tallied and accumulated to derive the empirical cumulative distribution function of the interarrival times. The distribution function (CDF) is a useful calculation to assess goodness of fit to the actual data. The distribution functions of the simulations from our various models will be compared to the distribution function of the actual data, to determine the best model for the given data. A graph of the CDF of the actual data, compared to the CDF of an exponential model with a mean of 1.136 milliseconds per arrival, is given in Figures 2a and 2b. Figure 2a depicts the relatively short arrivals in the curve where as Figure 2b represents the longer arrival time intervals. The solid line represents the actual data and the dotted line the exponential model. Note that for small interarrival times (less than 1 millisecond), the actual data has many more arrivals than would be expected from the exponential model. For times bigger than 1 millisecond, the exponential model has more arrivals, but the actual data has a substantial percentage of arrivals much higher than 1 millisecond. This feature could be best described by saying that the actual data has an extremely heavy tail in its interarrival distribution.<br /> <br /> Guster, Litvinov, Richardson & Robinson • 253<br /> <br /> The first alternative to the exponential fit is the power law process model, which allows for changes in traffic intensity over the given period of time. In this case, the test bed was configured for heavy levels of traffic, but generated at a constant level of intensity. So here the possible gains from the power law process are not realized. A fit of the power law process model yielded the following parameter estimates: b=.9955 and l= 905.8176. A value of b near 1 indicates a near constant level of intensity. This implies that the power law fit will be no better Figure 2a<br /> <br /> 1.0<br /> <br /> Distribution Function<br /> <br /> 0.9 0.8 0.7 0.6 0.5 0.4 0.3 0.2 0.1 0.0 0.0<br /> <br /> 0.5<br /> <br /> 1.0<br /> <br /> Time in mSec<br /> <br /> Figure 2b<br /> <br /> Distribution Function<br /> <br /> 1.0<br /> <br /> 0.9<br /> <br /> 0.8<br /> <br /> 0.7<br /> <br /> 0.6 0<br /> <br /> 1<br /> <br /> 2<br /> <br /> 3<br /> <br /> 4<br /> <br /> 5<br /> <br /> 6<br /> <br /> Time in mSec<br /> <br /> 7<br /> <br /> 8<br /> <br /> 9<br /> <br /> 10<br /> <br /> 254 • A Comparison of Stochastic Models<br /> <br /> than the exponential fit. A simulation of the power law process with these parameters was performed, and the cumulative distribution function (CDF) was computed. It was found to be identical with that of the exponential distribution with a mean interarrival time of 1.136 milliseconds. The graph of this CDF would be identical to that of the exponential model in Figures 2a and 2b. The Markov chain model was the next model to be simulated. This model uses structure in the data that is not used in other models, namely the dependence of one interarrival time with the time that follows it. The spikes in the empirical distribution of Figure 1 indicates that some interarrival times occur frequently, but it does not indicate whether the occurrences of a particular interarrival time are spread uniformly throughout the data set. To investigate this, all interarrival times were categorized into one of four time frames: (1) less than .075 msec, (2) between .075 and .15 msec, (3) between .15 and .30 msec, (4) greater than .3 msec. To examine patterns in the arrival times, a Markov transition probability matrix was compiled (Table 1). This type of table can be used to estimate probabilities for what magnitude of interarrival time will follow a given previous interarrival time. Table 1: Markov Transition Probability Matrix Previous InterArrival Time (1) (2) (3) (4)<br /> <br /> Following Interarrival Time (1) (2) (3) (4) .048 .091 .745 .116 .528 .209 .052 .211 .022 .758 .049 .170 .019 .211 .295 .476<br /> <br /> Overall marginal probabilities for the 4 categories: .188 .320 .242 .249 The marginal probabilities indicate the proportion of interarrival times in each of the four categories. For example, moderately short interarrival times (category 2) are most common in the data set, occurring 32.0% of the time. Examination of the transition matrix above yields interesting observations. The Ethernet transitions, from one interarrival time to the next, are relatively predictable. That is, given an interarrival time, the next interarrival category can be predicted successfully according to the highest probability in each row of the transition matrix.<br /> <br /> Guster, Litvinov, Richardson & Robinson • 255<br /> <br /> These probabilities are: From (1) to (3) From (2) to (1) From (3) to (2) From (4) to (4)<br /> <br /> .745 .528 .758 .476<br /> <br /> To judge how well a Markov model using the transition probability matrix represents the actual data, a Markov simulation was run whereby each interarrival time category was randomly generated according to the above probabilities, based on the previous interarrival time category. To determine an actual interarrival time within a category, a random time was chosen uniformly across each of the first three intervals. An exponential distribution was used for random times generated within the last category. This has the effect of smoothing out the spikes in the interarrival time distributions of the simulation, while maintaining the same proportions of interarrival times in each category as were present in the original data. To compare this set of Markov-simulated interarrival times with the actual data, the distribution functions are presented in Figure 3a and 3b. The solid line represents the empirical CDF from the actual data, while the short-dashed line represents the empirical CDF from the Markov simulation. The long-dashed line represents the empirical CDF from the exponential model (as well as the power law process model). One can see that the Markov simulated data has approximately the correct distribution for interarrival times less than 0.3 msec. That is, the CDF of the Markov data closely approximates the CDF of the actual interarrival times for that range of time. Beyond 0.3 msec, however, the Markov CDF lags behind the actual CDF. Recall that in this range, an exponential distribution was used to Figure 3a 1.0<br /> <br /> Distribution Function<br /> <br /> 0.9 0.8 0.7 0.6 0.5 0.4 0.3 0.2 0.1 0.0 0.0<br /> <br /> 0.5<br /> <br /> Time in mSec<br /> <br /> 1.0<br /> <br /> 256 • A Comparison of Stochastic Models<br /> <br /> Figure 3b<br /> <br /> Distribution Function<br /> <br /> 1.0<br /> <br /> 0.9<br /> <br /> 0.8<br /> <br /> 0.7<br /> <br /> 0.6 0<br /> <br /> 1<br /> <br /> 2<br /> <br /> 3<br /> <br /> 4<br /> <br /> 5<br /> <br /> 6<br /> <br /> 7<br /> <br /> 8<br /> <br /> 9<br /> <br /> 10<br /> <br /> Time in mSec<br /> <br /> generate a random interarrival time greater than 0.3 msec. Again the inadequacy of an exponential approximation to actual data is apparent. But overall, the Markov model provides data with a much more accurate distribution than either the exponential model or the power law process model. With other data that encompasses a broader time frame than the 10 minute segment used here, the power law process has proven to be more useful than in this case.<br /> <br /> CONCLUSIONS AND RECOMMENDATIONS As the need to make the most of available network bandwidth increases, the importance of having valid simulation techniques available to test optimization methodologies increases. The key to this validity is an interarrival distribution that is truly representative of the actual data. This chapter explored several alternatives in selecting this distribution. First, the actual data obviously offers the best accuracy, but is often impractical due to its massive size. Furthermore, selecting a representative sample is often challenging due to widespread variation over time exhibited by most network traffic. Second, the exponential distribution, which according to queuing theory should be appropriate, does not fit the data in this study as well in a number of other studies. Using this distribution in a simulation involving the test bed network would lack greatly in validity. Third, the power law process had limited value in this relatively short time interval study. In fact, it fit no better than the exponential. It may, however, offer more promise in data sets involving much larger time spans.<br /> <br /> Guster, Litvinov, Richardson & Robinson • 257<br /> <br /> Fourth, the Markov process exhibited somewhat promising results. In fact, the visual plots reveal a much closer fit than the other models tested. However, its limitations in the .3 to about 5 milliseconds range make it far from a perfect choice. The results herein indicate the complexity of the data and subsequently the difficulty in determining a mathematical model that would truly represent it. The results exhibited by the Markov process are encouraging, and studies that examine more sophisticated Markov-related models should be encouraged. Also, additional research involving longer time spans should be employed to ascertain how each of the methods scale. The importance of obtaining the appropriate distribution for network traffic should not be underestimated. Without it simulations designed to ascertain network design efficiency, network performance, and the effectiveness of software optimization techniques generate invalid results.<br /> <br /> REFERENCES CACI Comnet III Reference Manual (1998). CACI Products Inc., La Jolla, CA. Frieberger, W. (1972). Statistical Computer Performance Evaluation. Academic Press. Guster, D. and Robinson, D. (2000). Using Markov Chains to Analyze the Interarrival Distributions of ATM and Ethernet Traffic in Computer Networks. A paper to be presented at the 31st annual meeting of the Decision Sciences Institute, Orlando, FL, November 18-21. Guster, D., Robinson, D., and Richardson, M. (1999). Application of the Power Law Process in Modeling the Interarrival Times of Packets in a Computer Network. Proceedings of the 30th Annual Meeting of the Midwest Decision Sciences Institute, Springfield, IL, April 22-24. Krzenski, K. (1998). Analysis of the Predictive Process Request-Response Modeling in a Hypermedia Environment. Masters Thesis, St. Cloud State University. Krzenski, K. (1998). The Effect of Varying the Packet Interarrival Distribution in the Simulation of Ethernet Computer Networks. Unpublished graduate research project, St. Cloud State University. Partridge, C. (1993). The End of Simple Traffic Models. (Editor’s Note), IEEE Network, 7(5). Vandolore, B., Babic, G., and Jain, R. (1999). Analysis and Modeling of Traffic in Modern Data Communications Networks. A paper submitted to the Applied Telecommunication Symposium. Walker, J. (2000). Testing and Tuning QoS for Network Policies. Technical Paper. Net IQ Corporation.<br /> <br /> 258 • A Methodology for Adaptive Workflows<br /> <br /> Chapter 24<br /> <br /> A Methodology for Adaptive Workflows Liu Shuzhou and Angela Goh Eck Soong Nanyang Technological University, Singapore<br /> <br /> A workflow methodology is required to analyze business logic and model workflow components. Current studies handle business process modeling and workflow modeling in an independent manner, making it hard to analyze the information system and organization requirements while modeling business logic. Moreover, current methodologies also lack support for modeling complex dynamic processes in adaptive workflows. In this chapter, a methodology is proposed to unify business process modeling and workflow automation. The information system and organization perspectives of workflow are identified in each development phase. An analysis of the domain and an object notation in the methodology can help to build a stable system.<br /> <br /> INTRODUCTION Workflow provides a way to automate business processes. A workflow methodology is important for the analysis of business logic, and to model workflow components. Many commercial products provide guidelines for workflow design. These guidelines can be regarded as methodologies (Changengine admin Edition Process Design Guide, 1998). However, they are based on specific workflow products. A general methodology can facilitate heterogeneous workflow application. Unfortunately, there are only a few general approaches for analysis and design, such as WIDE (Baresi, Casati et al., 1999) and Derung’s approach (1997). Previously Published in Managing Information Technology in a Global Economy, edited by Mehdi Khosrow-Pour, Copyright © 2001, Idea Group Publishing.<br /> <br /> Shuzhou & Soong • 259<br /> <br /> WIDE (Baresi et al., 1999) proposes a methodology for supporting workflow design, which is divided into three phases: workflow analysis, workflow design and mapping to target workflow systems. The workflow analysis starts from existing well-defined business processes, goals and external Information systems. The business process goals and characteristics are analyzed to determine the “workflowability” of the proposed business processes. In the design phase, the normal process flow is decomposed into sub-processes, super-tasks, business transactions, and tasks. A pattern-based approach is adopted for specifying typical exceptions to the normal flows. In the mapping phase, the results of design are mapped onto commercial workflow products and standard workflow models. Derungs et al. (1997) propose a methodology to support the transformation of business processes into workflow applications. The methodology contains three central steps: Requirement Specifications, Conceptual Design and Realization. The Requirement Specification investigates the data and function requirement gaps between the process design and the As-Is-System, and then identifies the relevant workflow. Following that, the requirements and a plan for the infrastructure are determined. The Conceptual Design identifies activities, assigns them to work steps and describes the activities for the program design from the business viewpoint. The integration mechanism and the dialog for the user will be determined in this phase. The organization structure is designed and implemented too. Michael Amberge (1997) proposes a two-stage modeling procedure for the development of workflow relevant application. The first-stage uses business process modeling to identify the relevant business tasks to be supported. The second stage uses workflow modeling to specify in detail the domain-related requirements for workflow application. However, no further details on notation and stepwise guidance are presented. In these studies, business process modeling and workflow modeling are separated. Workflow methodology is used to automate a well-defined process. This is also true for most workflow products. For example, ARIS (1997) is a process modeling tool and FlowMark (1996) is a workflow modeling tool. An ARIS-toFlowMark interface (1997) is used to integrate them. However, this separation results in several drawbacks. Firstly, since the process model and workflow model use different notations and tools, integration can be costly. Secondly, workflow automation can affect business logic. For example, a traditional commerce payment process is different from e-commerce payment process, since the latter has to consider network security problems. A well-defined business process may have to be changed when workflow is automated. It would be better to identify such changes as early as possible. Thirdly, workflow systems usually focus on hardware/software integration, resource integration and organization coordination. On the other hand, business processes only emphasizes on functional re-<br /> <br /> 260 • A Methodology for Adaptive Workflows<br /> <br /> quirements of the system, and does not cover all aspects of the workflow. Loss of requirement analysis in organization and information systems may result in project failure or system re-design. It is expected that adaptive workflow should support complex dynamic processes, and that process definition should be allowed to change accordingly (Sheth, 1996). Exceptions can be used to define error and unexpected conditions, as seen in WIDE (Baresi et al., 1999). However, workflow change is not limited to exception handling. Sometimes, the main business logic may be changed. Such changes require rebuilding business logic through re-analysis and re-design. An adaptive workflow methodology should be able to identify, trace and manage these changes. To resolve these problems, this paper presents a methodology to unify business process modeling and workflow automation. Workflow processes, information systems and organizational policies will be analyzed and designed. In section 2, an overview of the approach will be described. Following that, the details of each phase are presented.<br /> <br /> OVERVIEW OF THE APPROACH The methodology contains four phases: domain analysis, business analysis, workflow design and workflow construction. The framework is shown in Figure 1. A domain model can be used to define the common features and variation in a specific domain (Sodhi, 1999). The domain analysis defines the basic concepts and functions of similar applications. In addition, current technologies and organization responsibilities in the domain are identified. The business analysis identifies specific requirements of the system. Common functional requirements can be derived from the domain model by making use of domain knowledge. Applicationspecific requirements need to be specified separately. The non-functional requireFigure 1: The process of workflow methodology Domain analysis Domain knowledge Business analysis Application requirements Workflow Design Workflow components Workflow implementation<br /> <br /> Shuzhou & Soong • 261<br /> <br /> ments, such as cost, time and customer satisfaction, will determine choice of technologies. In workflow design, the workflow process will be decomposed to sub-processes. Roles and technologies to support sub-processes execution are identified too. These workflow components are organized into objects and relationships among them are identified. In workflow implementation, workflow components are mapped to specific systems for execution. Applying information technology should not just result in doing “original work faster,” but also help to improve business process (Chaffey, 1998). The methodology can support continuous improvement of business process since workflow process, information technology and organization policies are analyzed and designed simultaneously. The effect of information systems and organization to workflow process is identified in the early phase of development. In contrast with other approaches, there is no gap between business process and workflow process. The development process is iterative and workflow process can be defined in an evolutionary way to respond to change. For a new application, the domain analysis should be carried out at the beginning. A changed workflow process can re-use existing domain knowledge to facilitate workflow analysis, and the variation in domain model can help to identify the components that require change. In the workflow design phase, the workflow model is organized as objects since the object-oriented paradigm can help to construct a stable system and facilitate change. As UML (Booch, Rumbaugh and Jacobson, 1998) is the de facto industry standard modeling notation for Object Oriented development, some UML notations will be adopted in the methodology. Details of the methodology will be described through a library management system example.<br /> <br /> DOMAIN ANALYSIS Domain analysis is used to model common features and variations in a particular application domain. As a first step, domain experts will survey existing systems and find common features among them. The system scope will be identiFigure 2: Use Case of library domain extends return reader<br /> <br /> loan<br /> <br /> uses uses<br /> <br /> overdue<br /> <br /> reminder<br /> <br /> reservation<<option>><br /> <br /> query by reader<br /> <br /> <<alternative rel="nofollow">> query<br /> <br /> <<alternative rel="nofollow">><br /> <br /> query by staff<br /> <br /> 262 • A Methodology for Adaptive Workflows<br /> <br /> Figure 3: Function/technology matrix Use Case choice return loan Loan at counter Loan at machine query Query by reader Query by staff<br /> <br /> Database Internet Intranet Self Check machine + + + + + + + +<br /> <br /> fied. The basic functions of the system are described. For the library management system, the basic functions can include loan and return of books. Besides that, similar to FODA (Feature-Oriented Domain Analysis) (Sodhi, 1999), alternative and optional functions can be specified. They can be used to describe variation of the domain. Some library management systems can support reservation of books, and so, this is described as optional function. The querying operation is also the basic function of systems, but since queries may be invoked by staff or readers, querying is defined as alternative function. These functions are described in Use Case Diagrams and are shown in Figure 2. The Use Case diagrams is extended with stereotypes << option >> and <<alternative rel="nofollow">> to describe option and alternative functions. Here the “reservation” Use Case is optional since some systems do not provide this function. “Query” function can be defined in two ways: “query by reader” and “query by staff,” and hence, it is described as an “alternative.” The “overdue” feature is seen as an exception and described as extended Use Case. Both “overdue” and “reservation” will invoke reminders to the reader, so the “reminder” is described as a common Use Case for them. After analysis of the functional aspects, the information technology support for each Use Case should be identified. The domain experts survey the current information technology application in the domain, and then, for each Use Case, possible information technologies to support it will be identified. For each alternative Use Case, related information technologies are also specified. This is described in a function/technology matrix. Figure 3 shows the matrix for the library management system. In the matrix, the technologies that can support each Use Case are identified by “+” sign in the form. Different technologies can result in different Use Cases. For example, loaning a book at a counter is different from loaning a book at a selfcheck machine. A choice column is used to specify such differences. For simplication, only three Use Cases are listed in Figure 3. In Use Case diagrams, external actors are described and there is no description for internal actors. Since the organization structure can vary significantly, it is difficult to specify a common internal organization structure in the domain analysis. However, it would be better to identify responsibilities of automation operations (which is related to information systems) and manual operations (which is related<br /> <br /> Shuzhou & Soong • 263<br /> <br /> to organization members) since they are executed by different workflow components. The Use Case description is extended to describe the responsibilities. For example, the responsibilities of “return” can be: “The reader sends the book to a staff. The staff clears the loan information by amending the database that stores the loan information.” Domain models define common features for a group of applications and are more stable than a specific application. However, the domain model can still be changed. For example, a new technology or a new service may emerge. The extension of a Use Case diagram can help to define domain changes. An exception can be defined as an extended Use Case. A new function can be added by using the <<alternative rel="nofollow">> stereotype. Finally, a function can be labeled as an <<option>> when it is no longer treated as a basic function.<br /> <br /> BUSINESS ANALYSIS The domain analysis identifies the common capabilities of an application. In business analysis, a specific requirement will be specified. Workflow automation is always driven by certain goals, such as improving the service of customers, decreasing cost and enhancing quality. A goal can be used to describe the reason that a system is needed, and requirements are used to specify how a goal should be accomplished by a proposed system (Anton, 1996). Goals that are specified explicitly can help to identify workflow requirements. In our approach, the goal-driven approach will be adopted. The goals are identified before the requirements are derived. The priorities of goals can be specified. There are three levels of priorities: mandatory, expected and optional. The mandatory goals define basic function and performance aims that must be attained. The goals stated as “expected” should be attained as far as possible. Finally, the optional goals may be attained but not deemed necessary. The analyst will determine the goals from the library staff and the users. The domain model can also help to identify goals. The basic functions in domain, such as “return book,” “loan book,” must be achieved and defined as mandatory goals. The analyst chooses which alternative function will be achieved and then define it as a mandatory goal. The optional functions can be chosen to achieve or not. They can be defined as “mandatory,” “expected” or “optional” goals according to specific application system requirements. In a typical library management system, the goals are as follows: (1) return book (mandatory): Reader should return their books before they are overdue. (2) loan book (mandatory): Readers with validate library cards can borrow books from the library. (3) reserve book (mandatory): Reader can reserve a book if it is not available.<br /> <br /> 264 • A Methodology for Adaptive Workflows<br /> <br /> Figure 4: Technology support for “renew book” Use Case choice Database Internet Intranet Self Check machine renewbook renewat counter + renewat machine + + +<br /> <br /> Figure 5: Conflict Coordination Matrix for goals Use Case loan<br /> <br /> choice<br /> <br /> reader satisfaction(expected) Loan at counter 0 Loan at machine +<br /> <br /> Lowdaily cost (expected) +<br /> <br /> low construction cost (option) + -<br /> <br /> (4) renew book (mandatory): Reader can renew a book if no one reserved it. (5) query book (mandatory): Reader can query a book. (6) reader satisfaction (expected): Reader should be satisfied with library services. (7) low daily cost(expected): The daily cost of running the whole system should be low. (8) low construction cost (optional): The cost to build the whole system should be low. The “return book,” “loan book,” “reserve book,” “renew book” and “query book” describe basic system behavior and are defined as mandatory. The “reader satisfaction” and “low daily cost” measure the system performance and should be attained as far as possible. The “low construction cost” is important but not necessary, so it is defined as optional. The goals can be related to functional requirements and non-functional requirements. The functional requirements describe what the system does and the non- functional requirements describe how the system behaves with respect to some observable attributes such as performance, reliability and reusability (Ninth International Workshop on Software Specification and Design, 1998). As discussed above, the function requirements of common goals can be derived from the domain model. The specific-goal requirements, such as “renew book,” are not defined in the domain and need to be defined here. They are also described as Use Cases, and the possible technologies required to support them will be identified by a function/technology matrix, as shown in Figure 4. “Reader satisfaction,” “low daily cost” and “low construction cost” are described as system attributes and can be associated with multiple processes. These goals can be used to choose appropriate Use Cases. For each Use Case, the effect on goals is analyzed and then the appropriate Use Case is selected to attain the goals. WIDE methodology (Baresi et al., 1999) uses a case/goal matrix, but it<br /> <br /> Shuzhou & Soong • 265<br /> <br /> Figure 6: Use Case of library application extends return loan at machine<br /> <br /> reader<br /> <br /> uses uses<br /> <br /> overdue<br /> <br /> reminder<br /> <br /> online reservation renew at machine query by reader<br /> <br /> Figure 7: Use Case description for “return”<br /> <br /> Use case return<br /> <br /> Version 1.0<br /> <br /> Pre condition Post condition Creation date The reader borrow The book is 2000.9 the book returned<br /> <br /> Valid date 2001.1-2003.1<br /> <br /> Figure 8: Use Case/Organizations matrix Use Case return renew at machine<br /> <br /> Office accept books renew books<br /> <br /> Finance accept fines<br /> <br /> does not consider the effect of organization and external information systems, such as database, Internet and Intranet. Here the Conflict Coordination Matrix will be used. For example, for “loan book,” the Conflict Coordination Matrix is shown in Figure 5. If a Use Case can have a positive effect on certain factor, a symbol “+” will be used; if there is no effect, a symbol “0” will be used; otherwise, a symbol “-” will be used. When “loan at machine” is used, the loan process will be faster, and the reader satisfaction will be enhanced. The “loan at machine” can decrease daily cost since fewer loan counter staff is needed, but it will increase the construction cost since new hardware and software will be required. As “low construction cost” is an optional goal, the “loan at machine” approach is adopted. Using a similar analysis, the “online reservation” “query by reader” and “renew at machine” are also selected. This is described with Use Case diagrams in Figure 6.<br /> <br /> 266 • A Methodology for Adaptive Workflows<br /> <br /> A textual description can be used to identify additional information for Use Case, such as how and when the Use Case begins and ends, and Use Case objectives (Objective Systems, 1993). In business analysis, Use Case version, pre/post condition, creating date and valid date etc. will be described. For example, the “return” Use Case description is given in Figure 7. The version information is helpful in tracing changes to business logic. The pre condition specifies when the Use Case can be started. The post condition describes expected status after execution. The creation date and valid date specifies the duration of a Use Case. Workflow supports cross organization boundaries business process. For each Use Case, the organization responsibilities are specified, as shown in the Use Case/Organizations matrix that is partially shown in Figure 8. The matrix specifies which department will take part in the Use Case and the responsibilities of each department. Here the responsibilities of roles are not specified, which will be attained in the further refinement. The results of the business analysis can experience change when user requirements or goals change. Since a domain model defines common features for a group of applications, the change of business model can be derived from domain models in a controlled manner. Firstly, a new requirement or a new goal is established, and then the variation in the Use Cases and technologies in the domain models are re-evaluated. A modified Use Case is selected to replace the original Use Case. For example, after the construction of the system, it is found that some people are not familiar with self-check machines and their satisfaction is low. As an interim solution, a few staff may be stationed at the counter to service the loans until the readers are familiar with the machines. The domain model provides “loan at counter” choice and it will be used. The new requirement requires the coexistence of “loan at counter” and “loan at machine.” They are both presented in the modified Use Case diagrams. So the change can be traced by comparing differences among domain models, original models and current models. However, if a Figure 9: Activity diagrams for “return” Cashier<br /> <br /> Reader bring book to return<br /> <br /> Record payment & produce receipt<br /> <br /> Counter staff discharge the loan<br /> <br /> check loan status<br /> <br /> pay fines<br /> <br /> overdue ok cancel the due date<br /> <br /> Database modify loan record<br /> <br /> Shuzhou & Soong • 267<br /> <br /> Figure 10: Class diagrams in library management system Information systems<br /> <br /> Staff Name Office<br /> <br /> path command install() uninstall()<br /> <br /> Databases loan_record …… modify() ……<br /> <br /> Loan Status book due_date<br /> <br /> ……<br /> <br /> isOverdue()<br /> <br /> Counter staff …… discharge_loan() check_loan_status() cancel_due_date()<br /> <br /> Cashier …… proces_payment() ……<br /> <br /> specific function is not involved in the domain model, it will be analyzed in a normal way. After the analysis, domain experts will determine whether it is necessary to add the function to the domain models or not.<br /> <br /> WORKFLOW DESIGN Business analysis specifies system requirements. The details of the whole system will be identified in workflow design. In business analysis, the function requirements are described as Use Cases. Scenarios can refine Use Cases, and activity diagrams with “swimlanes” in UML will be used to describe them. UML activity diagrams do not specify how to decompose the process. In our approach, the following criteria are provided: (1) If a process is executed by different organization roles, the process should be decomposed until it can be executed by one organization role. (2) If a process is executed through information systems, the information system services will be described as separate activities. (3) If there is information passing among organization members or information systems in a process, the process should be decomposed. (4) If a process execution can change the control flow, it should be decomposed to specify the choice, split and joined topologically. As an example, the “return” process can be specified. When the reader returns a book, the counter staff will discharge the loan by modifying the loan record in the database. Since the process is executed through the database, the “modify loan record” service of the database will be defined as a separate activity. The staff will check the loan status. If the loan is not overdue, the due date will be canceled. Otherwise, the reader will need to pay a fine to a cashier and receive an invoice. The activity diagram of “return” is described in Figure 9. The “swimlanes” group the responsibilities for organization roles and information systems. The diagrams show what services the information systems should provide, how to interact with the information system, and what data will be pro-<br /> <br /> 268 • A Methodology for Adaptive Workflows<br /> <br /> cessed. Services provided by organization roles are identified. The information systems, workflow relevant data and organization roles can be defined as objects. A Class Diagram is used to describe them. In addition to that, the Class diagrams can also help to describe other workflow-related objects. For example, the security, audit data, workflow scheduling policy etc. Some class descriptions of the library management system are shown in Figure 10. In the class diagrams, the information systems record basic properties common to all information systems, and database management systems are defined as its sub-class. Similarly, the staff is used to the describe organization perspective, and has two sub-classes, Counter staff and Cashier. The Loan Status describes workflow relevant data. The isOverdue() method will be used to determine whether a book is overdue. Only the inheritance relationships are presented here. In addition, the composition relationship and substitution relationships are important too. A composition relationship can help to compose an organization element, such as department and division. The substitution relationship is helpful in role assignments: when a role is not available, another can replace his work. They can also be described by using composition and association notations in UML class diagrams. It is well known that the object abstraction and inherit can help to construct a more stable system compared to a function-based description. Here the workflow organizations, workflow relevant data and workflow information systems are all organized as objects. Furthermore, as the process models and workflow information models are explicitly separated, changes to any one of these can be isolated and identified separately thereby decreasing the complexity of the model. Figure 11: The mapping rules between workflow design models and WfMC models Meta-model type Workflow type definition<br /> <br /> Activity<br /> <br /> Transition conditions Workflow relevant data Role Invoked application<br /> <br /> Meta-model type attributes Workflow process name Version number Process start and termination condition Security, audit or other control data Activity name Participant assignment Automation mode Other scheduling constraints Flow or execution conditions Data names and path Data type Naming and organisational entity Generic type or name Execution parameters Location of access path<br /> <br /> Workflow design model Use Case name Use Case version label Use Case pre-condition and postcondition Workflow control objects Activity name in activity diagrams Swimlanes in activity diagrams Object super class Workflow scheduling object methods Workflow data objects Workflow data objects attributes Workflow data object class Workflow role object attributes Workflow object class Workflow object attributes Workflow object attributes<br /> <br /> Shuzhou & Soong • 269<br /> <br /> WORKFLOW IMPLEMENTATION In workflow implementation, the workflow design model will be mapped to specific workflow management systems to enact the process. However, due to the wide variety of workflow products, different implementation approaches are usually adopted. It may appear that workflow design mapping has to be defined for each system since we want to provide a general workflow methodology. Fortunately, the Workflow Management Coalition(WfMC) provides a workflow model to describe common characteristics of all workflow management systems (Lawrence, 1997). The mapping will be done on WfMC models instead of a specific system. Common workflow models in WfMC can facilitate workflow management system integration and interoperation. Moreover, changes in the underlining workflow management systems will not affect workflow implementation models. WfMC defines three components to help import and export workflow definitions between different workflow systems. The meta-model defines core objects in workflow process. These objects are common entities in workflow systems. The Workflow Process Definition Language (WPDL)(WfMC TC-1016P) provides a formal way to define a process using the objects and attributes in the meta-model. The Workflow API (WAPI)(WfMC-TC-1009) is used to manipulate process definition attributes. As the meta-model describes the workflow semantics, the workflow design specification will firstly be mapped onto the metamodel. Secondly, the WPDL will be used to describe the specification. Following that, a WfMC-complaint workflow system can access the definition with WAPI. A brief introduction to the mapping is given as follows. The meta-model includes basic entities in a workflow process definition, their relationship and attributes. Some main entity types and their related attributes are listed in Figure 11. The mapping rules from workflow design model to WfMC meta-model are also presented. In workflow type definition, the Use Case name is mapped to the workflow process name. The textual description of Use Case can provide version, precondition and post-condition information. They are mapped to WfMC meta-model directly. The security, audit or other control data can be obtained from related data object in the workflow design model. In activity type, the activity name can be obtained from the activity diagrams. The participant assignment is determined by the swimlanes the activity belongs to in the activity diagrams. The super class of the activity executor determines the automation mode. If the super class is role, the automation mode is manual. Otherwise, it is automatic. The scheduling constraints can be derived from methods of a workflow scheduling object, which selects a preferred workflow to execute.<br /> <br /> 270 • A Methodology for Adaptive Workflows<br /> <br /> In workflow design, the data objects provide methods to test the transition conditions and to define execution conditions in meta-models. The workflow relevant data object attributes specifies data names and the path needed in metamodels. The data object class itself defines a data type. Similarly, roles and invoked application attributes can be derived from related objects in design models. WPDL can be used to describe workflow models formally to facilitate workflow definition exchange. The entities in workflow design models are mapped to the language. As an example, the library management can be described by WPDL as: MODEL Library_Management // model head WPDL_VERSION 1.1 …… //workflow definition WORKFLOW return // workflow head CREATED 2000.9 //activities in workflow ACTIVITIY discharge_the_loan PERFORMER counter_staff MOD manual // other activity attributes END_ACTIVITIY //other activities END_WORKFLOW //other workflow definition END_MODEL<br /> <br /> So far, the transition from the workflow design model to WPDL can not be done automatically. The mapping has to be done in a manual way. Future work will include a program to support automatic or semi- automatic transition. After the workflow design model is mapped to WPDL models, a WfMC compliant workflow management system can make use of the API to access the workflow models. For example, the “WMFetchProcessDefintion” will extract a process definition from a set of process definitions that meet the selection criteria. The “WMStartProcess” can start a specific process. The details of the API can be obtained in (WfMC-TC-1009).<br /> <br /> CONCLUSION In this chapter, a methodology to support adaptive workflow is proposed to unify business process modeling and workflow automation. Domain models and object models can help to construct a stable system in an adaptive workflow. A library management system was used to explain the methodology. Future work<br /> <br /> Shuzhou & Soong • 271<br /> <br /> includes formal support for the methodology and an attempt to automate the transition between workflow design and implementation.<br /> <br /> REFERENCES Amberg, M. (1997). The Benefits of Business Process Modeling for Workflow Systems, in Workflow Handbook 1997: workflow standard. John Wiley & Sons Ltd. Anton, A.I. (1996). Goal-based requirement analysis. Proceedings of the Second International Conference on Requirements Engineering, April. Baresi, L., Casati, F. et al. (1999). WIDE workflow development methodology. Proceedings of the international joint conference on Work activities coordination and collaboration. February, San Francisco, CA USA. Booch, G., Rumbaugh, J., and Jacobson, I. (1998). The Unified Modeling Language user guide. Addison-Wesley. Chaffey, D. (1998). Groupware, workflow, and intranets : reengineering the enterprise with collaborative software. Digital Press. Changengine Admin Edition (AdminFlow) Process Design Guide (1998). Hewlett Packard. Derungs, M., Vogler, P., and Osterle, H. (1997). From BPR models to workflow applications, in Workflow Handbook 1997: workflow standard. John Wiley & Sons Ltd. IBM (1996). Programming Guide, in IBM FlowMark Manuals, AOS Group. IDS (1997). ARIS FlowMark Interface in ARIS Toolset Manuals, Oct. IDS (1997). ARIS Toolset, in http://www.ids-scheer.com/indexp.htm, IDS Prof. Scheer Gmbh. Lawrence, P. (1997). Workflow handbook 1997: workflow standard. John Wiley & Sons Ltd. Objective Systems SF AB (1993). Objectory Process. Putting non-function requirements into software architecture. (1998). Ninth International Workshop on Software Specification and Design, April. Sheth, A. NSF Workshop on Workflow and Process Automation in Information Systems: State-of-the-Art and Future, Athens, GA 1996. In http://ra.cs.uga.edu/ activities/NSF-workflow/final-summary.html. Sodhi, J. (1999). Software reuse: domain analysis and design processes. McGraw-Hill.<br /> <br /> 272 • About the Editor<br /> <br /> About the Editor<br /> <br /> Kees van Slooten is a member of the faculty of technology and management, department of business information systems, at the University of Twente. He has a Ph.D. from the University of Twente and a Msc in Information Science and Mathematics. Before coming to the university, he had been active in systems analysis, design, programming, and consultancy. Now, he is supervising Ph.D. projects in the area of situation-specific business modeling aiming at implementing enterprise-wide information systems and e-commerce applications. He is teaching the following subjects: Information; Advances in Information Systems Development; and Information Systems for Co-operative Work. He has been a member of program committees of several international conferences and working groups. He is active in editing international journals and he published many articles in the area of information systems modeling.<br /> <br /> Index • 273<br /> <br /> Index<br /> <br /> A action duration 171 adaptability 97 adaptation 178 adaptive workflows 258 agent design 177 agent elicitation 176 agent implementation 177 agent integration 177 agent modeling 177, 178 agent technology 96 agent-based commerce systems 30 Agent-Oriented (AO) methodology 178 Agent-Oriented Modeling 176 agent-oriented software development 176 agents 95 algorithms 23 Anatomic Organ (AO) 80 anchors 58 antonym 32 application domain 43, 78 application programming interfaces (API) 151 ARchitecture of Integrated information Systems (ARIS) 208 ARIS 259 ARIS-to-FlowMark interface 259 art-collector 45 articulate knowledge 122 aspect descriptor 44 aspect type 44<br /> <br /> association class 230 associative relationships 62 automated reasoning 19 autonomy 97, 178 AX marker 74<br /> <br /> B BCC Business and Procedure Act 1939 132 BDI (Belief-Desire-Intention) 178 behavior aspect 7 Brisbane Financial Emergency Act 1939 132 business analysis 260 business engineering 163 business engineering methodology 163 business network reengineering (BNR) 196 business process reengineering (BPR) 196 business rules 128 business scope redefinition (BSR) 196<br /> <br /> C cardinalities 46 CASE environments 55 catalog clearing house 147 Catalog Exchange Protocol (CEP) 147 classification criteria 30, 33 classificatory knowledge 33<br /> <br /> 274 • Index<br /> <br /> classifying relations 30 cluster 21 cognitive overhead 58 collaboration 98 Combined Formal Technique 113 commercial web site development tools 55 compatibility relation 81 ComplementarityDeterminingRegion (CDR) 23 complex domains 78 Complex of Coordinated Control 113 complex schemas 65 component relationships 62 computer network 248 computer science 95 computer support 109 Computer-Supported Cooperative Work (CSCW) 194 computing domain 121 concept 41 concept acquisition modeling 30 conceptual data model 7 conceptual hypermedia modeling 41 conceptual modeling 55, 56, 59 conceptual relations 78 conceptual schema 69 conceptual web site modeling 55 conflict resolution 131 consistency constraints 57 constructed ontology 39 content description 78 context-based navigation paradigm 42 context-sensitive visualization principle 50 cooperation 178 Cooperation Component 194, 200 cooperative information system (CIS) 194 coordinated planning 108 coordinated resource control 109 Coordination Component 194, 200 Coordination theory 163 core catalogs 138 correlation 32 current web site development 55<br /> <br /> D data modeling 71 data modeling abstractions 42 data structure 43 data warehousing 139 database queries 51 database schemata 17 decision control systems 116 decision making systems 108 decision support system 109 Decision-Making Units (DMU) 115 defeasible logic 128, 129 defeasible rules 134 definition study 5 Description Logics (DL) 19 DescriptionUnit 23 design documentation 9 destination node 43 DFD (Data Flow Diagram) 183 digital catalog library (DCL) 146 distribution function (CDF) 253 DNA sequence 21 DNA sequence data 16 domain 46 domain analysis 177, 260 domain conceptualization 31 dynamic business environment 69 dynamic constraint 74 dynamic environment 98<br /> <br /> E e-commerce based ontology 30 e-commerce concept acquisition process 33 e-commerce concept relation ontology 31 e-commerce concepts 31 e-commerce ontology 30 e-markets 163 EE-Cat 137, 139 EJB (Enterprise Java Beans) 91 electronic catalog 137, 139 electronic catalog system 137 Electronic Commerce (EC) 95, 137, 177 Electronic Commerce Application 176<br /> <br /> Index • 275<br /> <br /> electronic markets (e-markets) 163 elementary information objects 60 EMC (Event-driven Method Chain) 211 emerging knowledge 196 emulation 166 Enhanced Entity Relationship (EER) 19 enterprise information system (EIS) 194 enterprise or organization IS (EIS) 196 enterprise performance 109 Enterprise Resource Planning (ERP) 1 enterprises 109 entity 21 entity-relationship 41 Entity-Relationship diagram 170 Entity-Relationship-model 151 environmental constraints 102 equivalence association 32 European Community (EC) 222 European Union (EU) 222 European Union UCITS 222 Event-driven Method Chain (EMC) 207, 209, 215 Event-driven Process Chain (EPC) 207 exercise price 34 existential dependencies 57 expensive redesign 17 expressiveness 130 Extended Electronic Catalog 137 external information objects 61<br /> <br /> F flowMark 259 FODA (Feature-Oriented Domain Analysis) 262 formal hypermedia data model 42 full codification 123 functional design 5 Functional Unit Test 3<br /> <br /> G gene expression chips 17 General Image Retrieval 78 generalization dependencies 57<br /> <br /> genome sequencing 17 Global Design Guidelines 155 gradation 31 group decision support systems (GDSS) 196 guided tour 42<br /> <br /> H HDM 43 heterogeneous databases 17 hierarchical relationships 59, 62 hierarchy relation 81 higher-order information units 42 homonyms 71 horizontal specialization 47 HTTP protocol 56 HYDESIGN model 57 hyperbase engine 50 hyperform 43 hypermedia data model 41 hypermedia engines 43 hypermedia paradigm 41 hyperstorm 43<br /> <br /> I Iconic Model 221 Iconic Modeling Tool (IMT) 178 image interpretation 79 implementation framework 42 indexing 79 informal ontology 19 Information and Communication Technology (ICT) 163 information aspect 7 information chunks 58 information content 50 information objects 59, 60 information system (IS) 170, 194, 207, 239, 258 Information System Layer 239 Information Systems Analysis and Design (ISAD) 6 information systems modelling (ISM) 170 information technology 194 information-hiding concept 43 information-oriented aspect analysis 9<br /> <br /> 276 • Index<br /> <br /> informationbase (IB) 239 inheritance 131 intelligent agents 176 Inter Agent modeling 176 Interaction Component 193 interface definition 198 Internal Schema (IS) 69, 75 Internet 139 Internet Commerce Server 140 Intra Agent Modeling 176 inverse link type 46 IPM (IS Process Model) 211 IRM (IS Resource Model) 211 ISD Methodology 1 ISM (IS Structure Model) 211<br /> <br /> K knowledge domain 57 knowledge elicitation 135 knowledge sources 193 knowledge-based system (KBS) development 31<br /> <br /> L large Web sites 55 layout template 43 legacy systems 197 link types 46 link typing 41 links 41 LiveCommerce 140 loan relationships 232 lost in hyperspace phenomenon 42<br /> <br /> M Majorant Schema (MS) 69, 70, 72 MAS (Multi Agent System) 178 Medial Sign (MS) 80 Medical Image Class (MIS) 80 Medical Region (MR) 80 Medical Region and Medical Sign (MR/MS) 80 medical signs 80 MEMO methodology (Multi-perspective Enterprise MOd 207 MESH 42, 43<br /> <br /> MESH’s context-based navigation paradigm 49 MESH’s object-oriented hypermedia data model 42 meta model 55 Meta-Data Coalition (MDC) 89 meta-data nodes 159 ”meta-model” 84, 86 meta-model technologies 86 meta-object facility 87 mMeta-object facility systems 89 metadata 195 method engineering 1, 2 microcosm 43 model engineering 84 model integration 208 Model-Driven Architecture (MDA) 85 model-oriented software 85 MOF (Meta-Object Facility) 85 Molecular Biological Information 16 molecular biology 17 Multi-Agent System (MAS) 165 multi-linguistic relation 81 multifaceted content 78 multimedia systems 78<br /> <br /> N navigation areas 60 navigation context 42, 43 navigation structure 50 navigational data access 41 navigational model 66 navigational relationships 62, 65 navigator 61, 65 node 43 node content 43, 51 node types 43 node typing hierarchy 51 nodes 41 non-hierarchical relationships 59 nonmonotonic reasoning 129<br /> <br /> O Object Management Architecture (OMA) 151 Object Management Group (OMG) 151<br /> <br /> Index • 277<br /> <br /> object oriented (OO) concepts 96, 178, 208 object schema 171 Object Systems Analysis and Design (OSAD 6 object-oriented abstractions 41 object-oriented approach 41 object-oriented design patterns 17 object-oriented modeling 176 object-oriented programming languages (OOPL) 156 object-relational database management system (ORDBMS) 150 object-relational database schema 152 OCL (Object Constraint Language) 91, 151 OCL constraints 157 OIM (Open Information Model) 89 OMG (Object Management Group) 85 Ontological Design Patterns (ODPs) 16, 18, 19 ontology 17, 86, 87 ontology building 39 ontology design 18 ontology-based concept acquisition 31, 39 OOHDM 43 open-ended list 130 operational database applications 69 optimal decisions 108 optimal planning 108 optimization 30 organization aspect 8<br /> <br /> P parallel planning 108 pattern 81 perceivable equivalencies 42 personal information systems (PISs) 194, 196 Petri Net 8, 114 phase integration 208 platform-independent implementation framework 41 polygons 81 posteriority 132<br /> <br /> private-collector 45 problem aspect 8 procedural program code 55 process-oriented aspect 7 product hierarchy 141<br /> <br /> Q questioning scheme 30, 34<br /> <br /> R reasoning 171 referred rules 131 Residential Tenancies Act 1994 133 Residential Tenancies Act 1997 132 resource-consumption tasks 108 Reticular Agent Mental Models 181 rigid node 44 RMM 43 RTIM (for Repository Type Information Model) 89<br /> <br /> S SBL (Structure Behavior Locality) 57 schema change 74 schema evolution 69 semantic Web 85 SENSOR project 150 sensu latu 122 sequential path 42 server functionality 56 shape 81 shared repository 138 Situated Method Engineering 2 SMIF RFP (Serial Model Interchange Format) 91 Soft Systems Methodology (SSM) 95, 96, 99 software agent 95 software components 17 Software Package Development Methodology (SPDM) 1, 3 Software Package Manufacturing Company (SPMC) 1 software packages 1 software structure 4 source nodes 46<br /> <br /> 278 • Index<br /> <br /> spatial relations 78, 81 SPDM 10 SPE (Software Process Engineering) 91 SPMC 2 state update function 172 static data constraint 74 stochastic models 248 strategical process model (SPM) 211 strength 32 strict rules 134 strike price 34 sub link type 46 sub-concept 32 super-concept 32 superiority 131 synergy 196 synonym 32 synonymy relation 81 syntactic complexity 130<br /> <br /> T T-cell receptor (TcR) 21 tacit knowledge 121, 122, 123 Tacit Knowledge Acquisition 121 technical design 5 Technical Unit Test 3 Temporary Design Guidelines 156 Terminological-Hierarchy ODP 20 time consuming 17 topological relations 82 trading agents 30 traditional business applications 56 traditional information systems 56 traditional ontology 38 translation graph 157 transmission component 200<br /> <br /> U U.S. Mutual Fund Servicing 221 UCITS 221, 223 UML (Unified Modelling Language) 85 UML CORBAfacility Interface Definition 152 UML repository 150, 151, 152 UML-based software 150<br /> <br /> Unified Modeling Language (UML) 19, 150, 221 uniform layout 41 user-defined routines (UDR) 152 user-defined types (UDT) 152 user-driven exploration 41<br /> <br /> V vagueness 130 validation 177 verification 177 vertical link specialization 46 visualization 42<br /> <br /> W Web sites 56 Web-based applications 207 Web-Based Cooperative Information Systems (WBCISs) 193 WIDE 259 Work Organization 194 Workflow API (WAPI) 269 workflow design 261 workflow implementation 261 Workflow Management Coalition (WfMC) 269 Workflow Process Definition Language (WPDL) 269 workgroup information systems (WISs) 194, 196 World Wide Web 57, 60 worldview 102<br /> <br /> X XMI (XML Model Interchange) 91<br /> <br /> A New Title from IGP! Business to Business Electronic Commerce: Challenges & Solutions Merrill Warkentin Mississippi State University, USA<br /> <br /> In the mid-1990s, the widespread adoption of the Web browser led to a rapid commercialization of the Internet. Initial success stories were reported from companies that learned how to create an effective direct marketing channel, selling tangible products to consumers directly over the World Wide Web. By the end of the 1990s, the next revolution began—business-tobusiness electronic commerce. Business to Business Electronic Commerce: Challenges and Solutions will provide researchers and practitioners with a source of knowledge related to this emerging area of business. ISBN 1-930708-09-2 (h/c); US$89.95; eISBN 1-591400-09-0 ; 308 pages • Copyright © 2002<br /> <br /> Recommend IGP books to your library!<br /> <br /> IDEA GROUP PUBLISHING IGP<br /> <br /> Hershey • London • Melbourne • Singapore • Beijing 1331 E. Chocolate Avenue, Hershey, PA 17033-1117 USA Tel: (800) 345-4332 • Fax: (717)533-8661 • cust@idea-group.com<br /> <br /> See the complete catalog of IGP publications at http://www.idea-group.com<br /> <br /> NEW from Idea Group Publishing • • • • • • • • • • • • • • • • • • • • • • • • • •<br /> <br /> Data Mining: A Heuristic Approach, Hussein Aly Abbass, Ruhul Amin Sarker & Charles S. Newton ISBN: 1-930708-25-4 / eISBN: 1-59140-011-2 / 310 pages / US$89.95 / © 2002 Managing Information Technology in Small Business: Challenges and Solutions, Stephen Burgess ISBN: 1-930708-35-1 / eISBN: 1-59140-012-0 / 367 pages / US$74.95 / © 2002 Managing Web Usage in the Workplace: A Social, Ethical and Legal Perspective, Murugan Anandarajan & Claire A. Simmers ISBN: 1-930708-18-1 / eISBN: 1-59140-003-1 / 386 pages / US$74.95 / © 2002 Challenges of Information Technology Education in the 21st Century, Eli Cohen ISBN: 1-930708-34-3 / eISBN: 1-59140-023-6 / 290 pages / US$74.95 / © 2002 Social Responsibility in the Information Age: Issues and Controversies, Gurpreet Dhillon ISBN: 1-930708-11-4 / eISBN: 1-59140-008-2 / 282 pages / US$74.95 / © 2002 Database Integrity: Challenges and Solutions, Jorge H. Doorn and Laura Rivero ISBN: 1-930708-38-6 / eISBN: 1-59140-024-4 / 300 pages / US$74.95 / © 2002 Managing Virtual Web Organizations in the 21st Century: Issues and Challenges, Ulrich Franke ISBN: 1-930708-24-6 / eISBN: 1-59140-016-3 / 368 pages / US$74.95 / © 2002 Managing Business with Electronic Commerce: Issues and Trends, Aryya Gangopadhyay ISBN: 1-930708-12-2 / eISBN: 1-59140-007-4 / 272 pages / US$74.95 / © 2002 Electronic Government: Design, Applications and Management, Åke Grönlund ISBN: 1-930708-19-X / eISBN: 1-59140-002-3 / 388 pages / US$74.95 / © 2002 Knowledge Media in Health Care: Opportunities and Challenges, Rolf Grutter ISBN: 1-930708-13-0 / eISBN: 1-59140-006-6 / 296 pages / US$74.95 / © 2002 Internet Management Issues: A Global Perspective, John D. Haynes ISBN: 1-930708-21-1 / eISBN: 1-59140-015-5 / 352 pages / US$74.95 / © 2002 Enterprise Resource Planning: Global Opportunities and Challenges, Liaquat Hossain, Jon David Patrick & M. A. Rashid ISBN: 1-930708-36-X / eISBN: 1-59140-025-2 / 300 pages / US$89.95 / © 2002 The Design and Management of Effective Distance Learning Programs, Richard Discenza, Caroline Howard, & Karen Schenk ISBN: 1-930708-20-3 / eISBN: 1-59140-001-5 / 312 pages / US$74.95 / © 2002 Multirate Systems: Design and Applications, Gordana Jovanovic-Dolecek ISBN: 1-930708-30-0 / eISBN: 1-59140-019-8 / 322 pages / US$74.95 / © 2002 Managing IT/Community Partnerships in the 21st Century, Jonathan Lazar ISBN: 1-930708-33-5 / eISBN: 1-59140-022-8 / 295 pages / US$89.95 / © 2002 Multimedia Networking: Technology, Management and Applications, Syed Mahbubur Rahman ISBN: 1-930708-14-9 / eISBN: 1-59140-005-8 / 498 pages / US$89.95 / © 2002 Cases on Worldwide E-Commerce: Theory in Action, Mahesh Raisinghani ISBN: 1-930708-27-0 / eISBN: 1-59140-013-9 / 276 pages / US$74.95 / © 2002 Designing Instruction for Technology-Enhanced Learning, Patricia L. Rogers ISBN: 1-930708-28-9 / eISBN: 1-59140-014-7 / 286 pages / US$74.95 / © 2002 Heuristic and Optimization for Knowledge Discovery, Ruhul Amin Sarker, Hussein Aly Abbass & Charles Newton ISBN: 1-930708-26-2 / eISBN: 1-59140-017-1 / 296 pages / US$89.95 / © 2002 Distributed Multimedia Databases: Techniques and Applications, Timothy K. Shih ISBN: 1-930708-29-7 / eISBN: 1-59140-018-X / 384 pages / US$74.95 / © 2002 Neural Networks in Business: Techniques and Applications, Kate Smith and Jatinder Gupta ISBN: 1-930708-31-9 / eISBN: 1-59140-020-1 / 272 pages / US$89.95 / © 2002 Managing the Human Side of Information Technology: Challenges and Solutions, Edward Szewczak & Coral Snodgrass ISBN: 1-930708-32-7 / eISBN: 1-59140-021-X / 364 pages / US$89.95 / © 2002 Cases on Global IT Applications and Management: Successes and Pitfalls, Felix B. Tan ISBN: 1-930708-16-5 / eISBN: 1-59140-000-7 / 300 pages / US$74.95 / © 2002 Enterprise Networking: Multilayer Switching and Applications, Vasilis Theoharakis & Dimitrios Serpanos ISBN: 1-930708-17-3 / eISBN: 1-59140-004-X / 282 pages / US$89.95 / © 2002 Measuring the Value of Information Technology, Han T. M. van der Zee ISBN: 1-930708-08-4 / eISBN: 1-59140-010-4 / 224 pages / US$74.95 / © 2002 Business to Business Electronic Commerce: Challenges and Solutions, Merrill Warkentin ISBN: 1-930708-09-2 / eISBN: 1-59140-009-0 / 308 pages / US$89.95 / © 2002<br /> <br /> Excellent additions to your institution’s library! Recommend these titles to your Librarian! To receive a copy of the Idea Group Publishing catalog, please contact (toll free) 1/800-345-4332, fax 1/717-533-8661,or visit the IGP Online Bookstore at: [http://www.idea-group.com]! Note: All IGP books are also available as ebooks on netlibrary.com as well as other ebook sources. Contact Ms. Carrie Stull at [cstull@idea-group.com] to receive a complete list of sources where you can obtain ebook information or IGP titles.<br /> <br /> </div> </div> </div> <div class="row hidden-xs"> <div class="col-md-12"> <h2></h2> <hr /> </div> <div class="col-lg-2 col-md-3"> <div class="note"> <div class="note-meta-thumb"> <a href="https://epdf.tips/optimal-inventory-modeling-of-systems-multi-echelon-techniques-second-edition.html"> <img src="https://epdf.tips/img/300x300/optimal-inventory-modeling-of-systems-multi-echelo_5a90efd0b7d7bcf11d43b794.jpg" alt="Optimal inventory modeling of systems: multi-echelon techniques, Second Edition" /> <h3 class="note-title">Optimal inventory modeling of systems: multi-echelon techniques, Second Edition</h3> </a> </div> <div class="note-action"> <a class="more-link" href="https://epdf.tips/optimal-inventory-modeling-of-systems-multi-echelon-techniques-second-edition.html">Read more</a> </div> </div> </div> <div class="col-lg-2 col-md-3"> <div class="note"> <div class="note-meta-thumb"> <a href="https://epdf.tips/building-information-modeling.html"> <img src="https://epdf.tips/img/300x300/building-information-modeling_5b35eae2b7d7bc492d1350e7.jpg" alt="Building Information Modeling" /> <h3 class="note-title">Building Information Modeling</h3> </a> </div> <div class="note-action"> <a class="more-link" href="https://epdf.tips/building-information-modeling.html">Read more</a> </div> </div> </div> <div class="col-lg-2 col-md-3"> <div class="note"> <div class="note-meta-thumb"> <a href="https://epdf.tips/optimal-reliability-modeling-principles-and-applications4f925092dab0c0a79481e5c76192f23c43712.html"> <img src="https://epdf.tips/img/300x300/optimal-reliability-modeling-principles-and-applic_5bfe5dc9b7d7bcfa1f28628d.jpg" alt="Optimal Reliability Modeling : Principles and Applications" /> <h3 class="note-title">Optimal Reliability Modeling : Principles and Applications</h3> </a> </div> <div class="note-action"> <a class="more-link" href="https://epdf.tips/optimal-reliability-modeling-principles-and-applications4f925092dab0c0a79481e5c76192f23c43712.html">Read more</a> </div> </div> </div> <div class="col-lg-2 col-md-3"> <div class="note"> <div class="note-meta-thumb"> <a href="https://epdf.tips/optimal-reliability-modeling-principles-and-applications.html"> <img src="https://epdf.tips/img/300x300/optimal-reliability-modeling-principles-and-applic_5a62c8e4b7d7bc7562de9b89.jpg" alt="Optimal reliability modeling: principles and applications" /> <h3 class="note-title">Optimal reliability modeling: principles and applications</h3> </a> </div> <div class="note-action"> <a class="more-link" href="https://epdf.tips/optimal-reliability-modeling-principles-and-applications.html">Read more</a> </div> </div> </div> <div class="col-lg-2 col-md-3"> <div class="note"> <div class="note-meta-thumb"> <a href="https://epdf.tips/information-modeling-the-express-way.html"> <img src="https://epdf.tips/img/300x300/information-modeling-the-express-way_5ac97db1b7d7bc583451449c.jpg" alt="Information Modeling the EXPRESS Way" /> <h3 class="note-title">Information Modeling the EXPRESS Way</h3> </a> </div> <div class="note-action"> <a class="more-link" href="https://epdf.tips/information-modeling-the-express-way.html">Read more</a> </div> </div> </div> <div class="col-lg-2 col-md-3"> <div class="note"> <div class="note-meta-thumb"> <a href="https://epdf.tips/grafting-characterization-techniques-kinetic-modeling.html"> <img src="https://epdf.tips/img/300x300/grafting-characterization-techniques-kinetic-model_5b43ed93b7d7bc5b5ba89813.jpg" alt="Grafting-Characterization Techniques-Kinetic Modeling" /> <h3 class="note-title">Grafting-Characterization Techniques-Kinetic Modeling</h3> </a> </div> <div class="note-action"> <a class="more-link" href="https://epdf.tips/grafting-characterization-techniques-kinetic-modeling.html">Read more</a> </div> </div> </div> <div class="col-lg-2 col-md-3"> <div class="note"> <div class="note-meta-thumb"> <a href="https://epdf.tips/information-modeling-methods-and-methodologies.html"> <img src="https://epdf.tips/img/300x300/information-modeling-methods-and-methodologies_5af0fb08b7d7bce73a664a56.jpg" alt="Information Modeling Methods and Methodologies" /> <h3 class="note-title">Information Modeling Methods and Methodologies</h3> </a> </div> <div class="note-action"> <a class="more-link" href="https://epdf.tips/information-modeling-methods-and-methodologies.html">Read more</a> </div> </div> </div> <div class="col-lg-2 col-md-3"> <div class="note"> <div class="note-meta-thumb"> <a href="https://epdf.tips/information-modeling-for-internet-applications.html"> <img src="https://epdf.tips/img/300x300/information-modeling-for-internet-applications_5ab7103fb7d7bc9e1f81ec2e.jpg" alt="Information Modeling for Internet Applications" /> <h3 class="note-title">Information Modeling for Internet Applications</h3> </a> </div> <div class="note-action"> <a class="more-link" href="https://epdf.tips/information-modeling-for-internet-applications.html">Read more</a> </div> </div> </div> <div class="col-lg-2 col-md-3"> <div class="note"> <div class="note-meta-thumb"> <a href="https://epdf.tips/information-criteria-and-statistical-modeling.html"> <img src="https://epdf.tips/img/300x300/information-criteria-and-statistical-modeling_5b3a78feb7d7bccf6b0f6254.jpg" alt="Information Criteria and Statistical Modeling" /> <h3 class="note-title">Information Criteria and Statistical Modeling</h3> </a> </div> <div class="note-action"> <a class="more-link" href="https://epdf.tips/information-criteria-and-statistical-modeling.html">Read more</a> </div> </div> </div> <div class="col-lg-2 col-md-3"> <div class="note"> <div class="note-meta-thumb"> <a href="https://epdf.tips/conceptual-modeling-of-information-systems.html"> <img src="https://epdf.tips/img/300x300/conceptual-modeling-of-information-systems_5a5d4a7cb7d7bcd31b202a2d.jpg" alt="Conceptual Modeling of Information Systems" /> <h3 class="note-title">Conceptual Modeling of Information Systems</h3> </a> </div> <div class="note-action"> <a class="more-link" href="https://epdf.tips/conceptual-modeling-of-information-systems.html">Read more</a> </div> </div> </div> <div class="col-lg-2 col-md-3"> <div class="note"> <div class="note-meta-thumb"> <a href="https://epdf.tips/innovative-information-systems-modelling-techniques.html"> <img src="https://epdf.tips/img/300x300/innovative-information-systems-modelling-technique_5b9c1ebcb7d7bc141cf6617c.jpg" alt="Innovative Information Systems Modelling Techniques" /> <h3 class="note-title">Innovative Information Systems Modelling Techniques</h3> </a> </div> <div class="note-action"> <a class="more-link" href="https://epdf.tips/innovative-information-systems-modelling-techniques.html">Read more</a> </div> </div> </div> <div class="col-lg-2 col-md-3"> <div class="note"> <div class="note-meta-thumb"> <a href="https://epdf.tips/scale-modeling-tips-and-techniques-scale-modeling-handbook-no-12.html"> <img src="https://epdf.tips/img/300x300/scale-modeling-tips-and-techniques-scale-modeling-_5ac15aaab7d7bc8243c589b2.jpg" alt="Scale Modeling Tips and Techniques (Scale Modeling Handbook, No. 12)" /> <h3 class="note-title">Scale Modeling Tips and Techniques (Scale Modeling Handbook, No. 12)</h3> </a> </div> <div class="note-action"> <a class="more-link" href="https://epdf.tips/scale-modeling-tips-and-techniques-scale-modeling-handbook-no-12.html">Read more</a> </div> </div> </div> <div class="col-lg-2 col-md-3"> <div class="note"> <div class="note-meta-thumb"> <a href="https://epdf.tips/character-modeling-with-maya-and-zbrush-professional-polygonal-modeling-techniqu.html"> <img src="https://epdf.tips/img/300x300/character-modeling-with-maya-and-zbrush-profession_5a8fa1a3b7d7bccc24c66748.jpg" alt="Character Modeling with Maya and ZBrush: Professional polygonal modeling techniques" /> <h3 class="note-title">Character Modeling with Maya and ZBrush: Professional polygonal modeling techniques</h3> </a> </div> <div class="note-action"> <a class="more-link" href="https://epdf.tips/character-modeling-with-maya-and-zbrush-professional-polygonal-modeling-techniqu.html">Read more</a> </div> </div> </div> <div class="col-lg-2 col-md-3"> <div class="note"> <div class="note-meta-thumb"> <a href="https://epdf.tips/character-modeling-with-maya-and-zbrush-professional-polygonal-modeling-techniqudcb89b88068fb46b4d7dd553be1cdc822223.html"> <img src="https://epdf.tips/img/300x300/character-modeling-with-maya-and-zbrush-profession_5b9b2dc6b7d7bc5654f8a09a.jpg" alt="Character Modeling with Maya and ZBrush: Professional polygonal modeling techniques" /> <h3 class="note-title">Character Modeling with Maya and ZBrush: Professional polygonal modeling techniques</h3> </a> </div> <div class="note-action"> <a class="more-link" href="https://epdf.tips/character-modeling-with-maya-and-zbrush-professional-polygonal-modeling-techniqudcb89b88068fb46b4d7dd553be1cdc822223.html">Read more</a> </div> </div> </div> <div class="col-lg-2 col-md-3"> <div class="note"> <div class="note-meta-thumb"> <a href="https://epdf.tips/optimal-nutrition-for-optimal-health.html"> <img src="https://epdf.tips/img/300x300/optimal-nutrition-for-optimal-health_5a8a35d9b7d7bc343214006d.jpg" alt="Optimal Nutrition for Optimal Health" /> <h3 class="note-title">Optimal Nutrition for Optimal Health</h3> </a> </div> <div class="note-action"> <a class="more-link" href="https://epdf.tips/optimal-nutrition-for-optimal-health.html">Read more</a> </div> </div> </div> <div class="col-lg-2 col-md-3"> <div class="note"> <div class="note-meta-thumb"> <a href="https://epdf.tips/optimal-nutrition-for-optimal-health7484cf76196291aef65bbd397919c31250225.html"> <img src="https://epdf.tips/img/300x300/optimal-nutrition-for-optimal-health_5a8a35ebb7d7bc343214006e.jpg" alt="Optimal Nutrition for Optimal Health" /> <h3 class="note-title">Optimal Nutrition for Optimal Health</h3> </a> </div> <div class="note-action"> <a class="more-link" href="https://epdf.tips/optimal-nutrition-for-optimal-health7484cf76196291aef65bbd397919c31250225.html">Read more</a> </div> </div> </div> <div class="col-lg-2 col-md-3"> <div class="note"> <div class="note-meta-thumb"> <a href="https://epdf.tips/optimal-nutrition-for-optimal-healthba3cc29d1174137f3632eb4cbc74c1364936.html"> <img src="https://epdf.tips/img/300x300/optimal-nutrition-for-optimal-health_5a8a36d2b7d7bc3332c11314.jpg" alt="Optimal Nutrition for Optimal Health" /> <h3 class="note-title">Optimal Nutrition for Optimal Health</h3> </a> </div> <div class="note-action"> <a class="more-link" href="https://epdf.tips/optimal-nutrition-for-optimal-healthba3cc29d1174137f3632eb4cbc74c1364936.html">Read more</a> </div> </div> </div> <div class="col-lg-2 col-md-3"> <div class="note"> <div class="note-meta-thumb"> <a href="https://epdf.tips/modeling-materials-continuum-atomistic-and-multiscale-techniques.html"> <img src="https://epdf.tips/img/300x300/modeling-materials-continuum-atomistic-and-multisc_5ab5967ab7d7bccd12c6518f.jpg" alt="Modeling Materials: Continuum, Atomistic and Multiscale Techniques" /> <h3 class="note-title">Modeling Materials: Continuum, Atomistic and Multiscale Techniques</h3> </a> </div> <div class="note-action"> <a class="more-link" href="https://epdf.tips/modeling-materials-continuum-atomistic-and-multiscale-techniques.html">Read more</a> </div> </div> </div> <div class="col-lg-2 col-md-3"> <div class="note"> <div class="note-meta-thumb"> <a href="https://epdf.tips/compact-modeling-principles-techniques-and-applications.html"> <img src="https://epdf.tips/img/300x300/compact-modeling-principles-techniques-and-applica_5ace9ab2b7d7bc2e2dfe9894.jpg" alt="Compact Modeling: Principles, Techniques and Applications" /> <h3 class="note-title">Compact Modeling: Principles, Techniques and Applications</h3> </a> </div> <div class="note-action"> <a class="more-link" href="https://epdf.tips/compact-modeling-principles-techniques-and-applications.html">Read more</a> </div> </div> </div> <div class="col-lg-2 col-md-3"> <div class="note"> <div class="note-meta-thumb"> <a href="https://epdf.tips/managing-event-information-modeling-retrieval-and-applications.html"> <img src="https://epdf.tips/img/300x300/managing-event-information-modeling-retrieval-and-_5ab5a855b7d7bcdd1fa5a8b5.jpg" alt="Managing Event Information: Modeling, Retrieval, and Applications" /> <h3 class="note-title">Managing Event Information: Modeling, Retrieval, and Applications</h3> </a> </div> <div class="note-action"> <a class="more-link" href="https://epdf.tips/managing-event-information-modeling-retrieval-and-applications.html">Read more</a> </div> </div> </div> <div class="col-lg-2 col-md-3"> <div class="note"> <div class="note-meta-thumb"> <a href="https://epdf.tips/modeling-decisions-information-fusion-and-aggregation-operators.html"> <img src="https://epdf.tips/img/300x300/modeling-decisions-information-fusion-and-aggregat_5b3ef286b7d7bc2071c5064d.jpg" alt="Modeling Decisions: Information Fusion and Aggregation Operators" /> <h3 class="note-title">Modeling Decisions: Information Fusion and Aggregation Operators</h3> </a> </div> <div class="note-action"> <a class="more-link" href="https://epdf.tips/modeling-decisions-information-fusion-and-aggregation-operators.html">Read more</a> </div> </div> </div> <div class="col-lg-2 col-md-3"> <div class="note"> <div class="note-meta-thumb"> <a href="https://epdf.tips/groundwater-modeling-using-geographical-information-systems.html"> <img src="https://epdf.tips/img/300x300/groundwater-modeling-using-geographical-informatio_5af0d752b7d7bcf14e2898c9.jpg" alt="Groundwater Modeling Using Geographical Information Systems" /> <h3 class="note-title">Groundwater Modeling Using Geographical Information Systems</h3> </a> </div> <div class="note-action"> <a class="more-link" href="https://epdf.tips/groundwater-modeling-using-geographical-information-systems.html">Read more</a> </div> </div> </div> <div class="col-lg-2 col-md-3"> <div class="note"> <div class="note-meta-thumb"> <a href="https://epdf.tips/modeling-materials-continuum-atomistic-and-multiscale-techniquesa7c0b4482d9993d4046d075acfefb4bf21556.html"> <img src="https://epdf.tips/img/300x300/modeling-materials-continuum-atomistic-and-multisc_5ab596a1b7d7bccd12c65190.jpg" alt="Modeling Materials: Continuum, Atomistic and Multiscale Techniques" /> <h3 class="note-title">Modeling Materials: Continuum, Atomistic and Multiscale Techniques</h3> </a> </div> <div class="note-action"> <a class="more-link" href="https://epdf.tips/modeling-materials-continuum-atomistic-and-multiscale-techniquesa7c0b4482d9993d4046d075acfefb4bf21556.html">Read more</a> </div> </div> </div> <div class="col-lg-2 col-md-3"> <div class="note"> <div class="note-meta-thumb"> <a href="https://epdf.tips/vlsi-fault-modeling-and-testing-techniques.html"> <img src="https://epdf.tips/img/300x300/vlsi-fault-modeling-and-testing-techniques_5b42dedcb7d7bc5910609090.jpg" alt="VLSI Fault Modeling and Testing Techniques:" /> <h3 class="note-title">VLSI Fault Modeling and Testing Techniques:</h3> </a> </div> <div class="note-action"> <a class="more-link" href="https://epdf.tips/vlsi-fault-modeling-and-testing-techniques.html">Read more</a> </div> </div> </div> <div class="col-lg-2 col-md-3"> <div class="note"> <div class="note-meta-thumb"> <a href="https://epdf.tips/modeling-materials-continuum-atomistic-and-multiscale-techniques-pdf-5eccd0f6e1ac6.html"> <img src="https://epdf.tips/img/300x300/modeling-materials-continuum-atomistic-and-multisc_5eccd0f7097c47770a8b4b10.jpg" alt="Modeling Materials: Continuum, Atomistic and Multiscale Techniques" /> <h3 class="note-title">Modeling Materials: Continuum, Atomistic and Multiscale Techniques</h3> </a> </div> <div class="note-action"> <a class="more-link" href="https://epdf.tips/modeling-materials-continuum-atomistic-and-multiscale-techniques-pdf-5eccd0f6e1ac6.html">Read more</a> </div> </div> </div> <div class="col-lg-2 col-md-3"> <div class="note"> <div class="note-meta-thumb"> <a href="https://epdf.tips/data-modeling-techniques-for-data-mining-ibm.html"> <img src="https://epdf.tips/img/300x300/data-modeling-techniques-for-data-mining-ibm_5a3c4e42b7d7bc0f38d04d07.jpg" alt="Data modeling techniques for data mining IBM" /> <h3 class="note-title">Data modeling techniques for data mining IBM</h3> </a> </div> <div class="note-action"> <a class="more-link" href="https://epdf.tips/data-modeling-techniques-for-data-mining-ibm.html">Read more</a> </div> </div> </div> <div class="col-lg-2 col-md-3"> <div class="note"> <div class="note-meta-thumb"> <a href="https://epdf.tips/modeling-materials-continuum-atomistic-and-multiscale-techniques-pdf-5eccd0f59f710.html"> <img src="https://epdf.tips/img/300x300/modeling-materials-continuum-atomistic-and-multisc_5eccd0f5097c47770a8b4b0f.jpg" alt="Modeling Materials: Continuum, Atomistic and Multiscale Techniques" /> <h3 class="note-title">Modeling Materials: Continuum, Atomistic and Multiscale Techniques</h3> </a> </div> <div class="note-action"> <a class="more-link" href="https://epdf.tips/modeling-materials-continuum-atomistic-and-multiscale-techniques-pdf-5eccd0f59f710.html">Read more</a> </div> </div> </div> <div class="col-lg-2 col-md-3"> <div class="note"> <div class="note-meta-thumb"> <a href="https://epdf.tips/structural-modeling-and-experimental-techniques-second-edition.html"> <img src="https://epdf.tips/img/300x300/structural-modeling-and-experimental-techniques-se_5ac43369b7d7bc0a339a3495.jpg" alt="Structural Modeling and Experimental Techniques, Second Edition" /> <h3 class="note-title">Structural Modeling and Experimental Techniques, Second Edition</h3> </a> </div> <div class="note-action"> <a class="more-link" href="https://epdf.tips/structural-modeling-and-experimental-techniques-second-edition.html">Read more</a> </div> </div> </div> <div class="col-lg-2 col-md-3"> <div class="note"> <div class="note-meta-thumb"> <a href="https://epdf.tips/data-modeling-techniques-for-data-warehousing.html"> <img src="https://epdf.tips/img/300x300/data-modeling-techniques-for-data-warehousing_5a652279b7d7bc280dad87f3.jpg" alt="Data Modeling Techniques for Data Warehousing" /> <h3 class="note-title">Data Modeling Techniques for Data Warehousing</h3> </a> </div> <div class="note-action"> <a class="more-link" href="https://epdf.tips/data-modeling-techniques-for-data-warehousing.html">Read more</a> </div> </div> </div> <div class="col-lg-2 col-md-3"> <div class="note"> <div class="note-meta-thumb"> <a href="https://epdf.tips/underwater-acoustic-modeling-principles-techniques-and-applications.html"> <img src="https://epdf.tips/img/300x300/underwater-acoustic-modeling-principles-techniques_5b8712a4b7d7bc3d7d550458.jpg" alt="Underwater acoustic modeling: principles, techniques and applications" /> <h3 class="note-title">Underwater acoustic modeling: principles, techniques and applications</h3> </a> </div> <div class="note-action"> <a class="more-link" href="https://epdf.tips/underwater-acoustic-modeling-principles-techniques-and-applications.html">Read more</a> </div> </div> </div> </div> </div> <div class="col-lg-3 col-md-4 col-xs-12"> <div class="panel-recommend panel panel-primary"> <div class="panel-heading"> <h4 class="panel-title">Recommend Documents</h4> </div> <div class="panel-body"> <div class="row m-0"> <div class="col-md-3 col-xs-3 pl-0 text-center"> <a href="https://epdf.tips/optimal-inventory-modeling-of-systems-multi-echelon-techniques-second-edition.html"> <img src="https://epdf.tips/img/60x80/optimal-inventory-modeling-of-systems-multi-echelo_5a90efd0b7d7bcf11d43b794.jpg" alt="" width="100%" /> </a> </div> <div class="col-md-9 col-xs-9 p-0"> <label> <a href="https://epdf.tips/optimal-inventory-modeling-of-systems-multi-echelon-techniques-second-edition.html"> Optimal inventory modeling of systems: multi-echelon techniques, Second Edition </a> </label> <div class="note-meta"> <div class="note-desc">OPTIMAL INVENTORY MODELING OF SYSTEMS Multi-Echelon Techniques Second Edition Recent titles in the INTERNATIONAL SER...</div> </div> </div> <div class="clearfix"></div> <hr class="mt-15 mb-15" /> </div> <div class="row m-0"> <div class="col-md-3 col-xs-3 pl-0 text-center"> <a href="https://epdf.tips/building-information-modeling.html"> <img src="https://epdf.tips/img/60x80/building-information-modeling_5b35eae2b7d7bc492d1350e7.jpg" alt="" width="100%" /> </a> </div> <div class="col-md-9 col-xs-9 p-0"> <label> <a href="https://epdf.tips/building-information-modeling.html"> Building Information Modeling </a> </label> <div class="note-meta"> <div class="note-desc">Building Information Modeling Other Books in the McGraw-Hill Construction Series Defect-Free Buildings: A Constructio...</div> </div> </div> <div class="clearfix"></div> <hr class="mt-15 mb-15" /> </div> <div class="row m-0"> <div class="col-md-3 col-xs-3 pl-0 text-center"> <a href="https://epdf.tips/optimal-reliability-modeling-principles-and-applications4f925092dab0c0a79481e5c76192f23c43712.html"> <img src="https://epdf.tips/img/60x80/optimal-reliability-modeling-principles-and-applic_5bfe5dc9b7d7bcfa1f28628d.jpg" alt="" width="100%" /> </a> </div> <div class="col-md-9 col-xs-9 p-0"> <label> <a href="https://epdf.tips/optimal-reliability-modeling-principles-and-applications4f925092dab0c0a79481e5c76192f23c43712.html"> Optimal Reliability Modeling : Principles and Applications </a> </label> <div class="note-meta"> <div class="note-desc">OPTIMAL RELIABILITY MODELING OPTIMAL RELIABILITY MODELING Principles and Applications WAY KUO Texas A&M University ...</div> </div> </div> <div class="clearfix"></div> <hr class="mt-15 mb-15" /> </div> <div class="row m-0"> <div class="col-md-3 col-xs-3 pl-0 text-center"> <a href="https://epdf.tips/optimal-reliability-modeling-principles-and-applications.html"> <img src="https://epdf.tips/img/60x80/optimal-reliability-modeling-principles-and-applic_5a62c8e4b7d7bc7562de9b89.jpg" alt="" width="100%" /> </a> </div> <div class="col-md-9 col-xs-9 p-0"> <label> <a href="https://epdf.tips/optimal-reliability-modeling-principles-and-applications.html"> Optimal reliability modeling: principles and applications </a> </label> <div class="note-meta"> <div class="note-desc"></div> </div> </div> <div class="clearfix"></div> <hr class="mt-15 mb-15" /> </div> <div class="row m-0"> <div class="col-md-3 col-xs-3 pl-0 text-center"> <a href="https://epdf.tips/information-modeling-the-express-way.html"> <img src="https://epdf.tips/img/60x80/information-modeling-the-express-way_5ac97db1b7d7bc583451449c.jpg" alt="" width="100%" /> </a> </div> <div class="col-md-9 col-xs-9 p-0"> <label> <a href="https://epdf.tips/information-modeling-the-express-way.html"> Information Modeling the EXPRESS Way </a> </label> <div class="note-meta"> <div class="note-desc">Information Modeling the EXPRESS Way This page intentionally left blank Information Modeling the EXPRESS Way DOUGL...</div> </div> </div> <div class="clearfix"></div> <hr class="mt-15 mb-15" /> </div> <div class="row m-0"> <div class="col-md-3 col-xs-3 pl-0 text-center"> <a href="https://epdf.tips/grafting-characterization-techniques-kinetic-modeling.html"> <img src="https://epdf.tips/img/60x80/grafting-characterization-techniques-kinetic-model_5b43ed93b7d7bc5b5ba89813.jpg" alt="" width="100%" /> </a> </div> <div class="col-md-9 col-xs-9 p-0"> <label> <a href="https://epdf.tips/grafting-characterization-techniques-kinetic-modeling.html"> Grafting-Characterization Techniques-Kinetic Modeling </a> </label> <div class="note-meta"> <div class="note-desc">Surface Modification of Polymers by Grafting Yoshikimi Uyama1, Koichi Kato2, and Yoshito Ikada1* * 1 To whom correspond...</div> </div> </div> <div class="clearfix"></div> <hr class="mt-15 mb-15" /> </div> <div class="row m-0"> <div class="col-md-3 col-xs-3 pl-0 text-center"> <a href="https://epdf.tips/information-modeling-methods-and-methodologies.html"> <img src="https://epdf.tips/img/60x80/information-modeling-methods-and-methodologies_5af0fb08b7d7bce73a664a56.jpg" alt="" width="100%" /> </a> </div> <div class="col-md-9 col-xs-9 p-0"> <label> <a href="https://epdf.tips/information-modeling-methods-and-methodologies.html"> Information Modeling Methods and Methodologies </a> </label> <div class="note-meta"> <div class="note-desc">Information Modeling Methods and Methodologies John Krogstie Norwegian University of Science and Technology, Norway SINT...</div> </div> </div> <div class="clearfix"></div> <hr class="mt-15 mb-15" /> </div> <div class="row m-0"> <div class="col-md-3 col-xs-3 pl-0 text-center"> <a href="https://epdf.tips/information-modeling-for-internet-applications.html"> <img src="https://epdf.tips/img/60x80/information-modeling-for-internet-applications_5ab7103fb7d7bc9e1f81ec2e.jpg" alt="" width="100%" /> </a> </div> <div class="col-md-9 col-xs-9 p-0"> <label> <a href="https://epdf.tips/information-modeling-for-internet-applications.html"> Information Modeling for Internet Applications </a> </label> <div class="note-meta"> <div class="note-desc"></div> </div> </div> <div class="clearfix"></div> <hr class="mt-15 mb-15" /> </div> <div class="row m-0"> <div class="col-md-3 col-xs-3 pl-0 text-center"> <a href="https://epdf.tips/information-criteria-and-statistical-modeling.html"> <img src="https://epdf.tips/img/60x80/information-criteria-and-statistical-modeling_5b3a78feb7d7bccf6b0f6254.jpg" alt="" width="100%" /> </a> </div> <div class="col-md-9 col-xs-9 p-0"> <label> <a href="https://epdf.tips/information-criteria-and-statistical-modeling.html"> Information Criteria and Statistical Modeling </a> </label> <div class="note-meta"> <div class="note-desc">Springer Series in Statistics Advisors: P. Bickel, P. Diggle, S. Fienberg, U. Gather, I. Olkin, S. Zeger Springer Ser...</div> </div> </div> <div class="clearfix"></div> <hr class="mt-15 mb-15" /> </div> <div class="row m-0"> <div class="col-md-3 col-xs-3 pl-0 text-center"> <a href="https://epdf.tips/conceptual-modeling-of-information-systems.html"> <img src="https://epdf.tips/img/60x80/conceptual-modeling-of-information-systems_5a5d4a7cb7d7bcd31b202a2d.jpg" alt="" width="100%" /> </a> </div> <div class="col-md-9 col-xs-9 p-0"> <label> <a href="https://epdf.tips/conceptual-modeling-of-information-systems.html"> Conceptual Modeling of Information Systems </a> </label> <div class="note-meta"> <div class="note-desc">Conceptual Modeling of Information Systems Antoni Olivé Conceptual Modeling of Information Systems With 185 Figures ...</div> </div> </div> <div class="clearfix"></div> <hr class="mt-15 mb-15" /> </div> </div> </div> </div> </div> </div> <div class="modal fade" id="report" tabindex="-1" role="dialog" aria-hidden="true"> <div class="modal-dialog"> <div class="modal-content"> <form role="form" method="post" action="https://epdf.tips/report/optimal-information-modeling-techniques" style="border: none;"> <div class="modal-header"> <button type="button" class="close" data-dismiss="modal" aria-hidden="true">×</button> <h4 class="modal-title">Report "Optimal Information Modeling Techniques"</h4> </div> <div class="modal-body"> <div class="form-group"> <label>Your name</label> <input type="text" name="name" required="required" class="form-control" /> </div> <div class="form-group"> <label>Email</label> <input type="email" name="email" required="required" class="form-control" /> </div> <div class="form-group"> <label>Reason</label> <select name="reason" required="required" class="form-control"> <option value="">-Select Reason-</option> <option value="pornographic" selected="selected">Pornographic</option> <option value="defamatory">Defamatory</option> <option value="illegal">Illegal/Unlawful</option> <option value="spam">Spam</option> <option value="others">Other Terms Of Service Violation</option> <option value="copyright">File a copyright complaint</option> </select> </div> <div class="form-group"> <label>Description</label> <textarea name="description" required="required" rows="3" class="form-control" style="border: 1px solid #cccccc;"></textarea> </div> <div class="form-group"> <div style="display: inline-block;"> <div class="g-recaptcha" data-sitekey="6Lemmz0UAAAAAANSnNH_YtG0406jaTUcUP7mxrLr"></div> </div> </div> <script src='https://www.google.com/recaptcha/api.js'></script> </div> <div class="modal-footer"> <button type="button" class="btn btn-default" data-dismiss="modal">Close</button> <button type="submit" class="btn btn-success">Send</button> </div> </form> </div> </div> </div> <footer class="footer" style="margin-top: 60px;"> <div class="container-fluid"> Copyright © 2024 EPDF.TIPS. All rights reserved. <div class="pull-right"> <span><a href="https://epdf.tips/about">About Us</a></span> | <span><a href="https://epdf.tips/privacy">Privacy Policy</a></span> | <span><a href="https://epdf.tips/term">Terms of Service</a></span> | <span><a href="https://epdf.tips/copyright">Copyright</a></span> | <span><a href="https://epdf.tips/dmca">DMCA</a></span> | <span><a href="https://epdf.tips/contact">Contact Us</a></span> | <span><a href="https://epdf.tips/cookie_policy">Cookie Policy</a></span> </div> </div> </footer>  <div class="modal fade" id="login" tabindex="-1" role="dialog" aria-labelledby="myModalLabel"> <div class="modal-dialog" role="document"> <div class="modal-content"> <div class="modal-header"> <button type="button" class="close" data-dismiss="modal" aria-label="Close" on="tap:login.close"><span aria-hidden="true">×</span></button> <h4 class="modal-title" id="add-note-label">Sign In</h4> </div> <div class="modal-body"> <form action="https://epdf.tips/login" method="post"> <div class="form-group"> <label class="sr-only" for="email">Email</label> <input class="form-input form-control" type="text" name="email" id="email" value="" placeholder="Email" /> </div> <div class="form-group"> <label class="sr-only" for="password">Password</label> <input class="form-input form-control" type="password" name="password" id="password" value="" placeholder="Password" /> </div> <div class="form-group"> <div class="checkbox"> <label class="form-checkbox"> <input type="checkbox" name="remember" value="1" /> <i class="form-icon"></i> Remember me </label> <label class="pull-right"><a href="https://epdf.tips/forgot">Forgot password?</a></label> </div> </div> <button class="btn btn-primary btn-block" type="submit">Sign In</button> </form> <hr style="margin-top: 15px;" /> <a href="https://epdf.tips/login/facebook" class="btn btn-facebook btn-block"><i class="fa fa-facebook"></i> Login with Facebook</a> </div> </div> </div> </div>  <script async src="https://www.googletagmanager.com/gtag/js?id=UA-111550345-1"></script> <script> window.dataLayer = window.dataLayer || []; function gtag(){dataLayer.push(arguments);} gtag('js', new Date()); gtag('config', 'UA-111550345-1'); </script> <script src="https://epdf.tips/assets/js/jquery-ui.min.js"></script> <link rel="stylesheet" href="https://epdf.tips/assets/css/jquery-ui.css"> <script> $(function () { $("#document_search").autocomplete({ source: function (request, response) { $.ajax({ url: "https://epdf.tips/suggest", dataType: "json", data: { term: request.term }, success: function (data) { response(data); } }); }, autoFill: true, select: function( event, ui ) { $(this).val(ui.item.value); $(this).parents("form").submit(); } }); }); </script>  <div id="EPDFTIPS_cookie_box" style="z-index:99999; border-top: 1px solid #fefefe; background: #97c479; width: 100%; position: fixed; padding: 5px 15px; text-align: center; left:0; bottom: 0;"> Our partners will collect data and use cookies for ad personalization and measurement. <a href="https://epdf.tips/cookie_policy" target="_blank">Learn how we and our ad partner Google, collect and use data</a>. <a href="#" class="btn btn-success" onclick="accept_EPDFTIPS_cookie_box();return false;">Agree & close</a> </div> <script> function accept_EPDFTIPS_cookie_box() { document.cookie = "EPDFTIPS_cookie_box_viewed=1;max-age=15768000;path=/"; hide_EPDFTIPS_cookie_box(); } function hide_EPDFTIPS_cookie_box() { var cb = document.getElementById('EPDFTIPS_cookie_box'); if (cb) { cb.parentElement.removeChild(cb); } } (function () { var EPDFTIPS_cookie_box_viewed = (function (name) { var matches = document.cookie.match(new RegExp("(?:^|; )" + name.replace(/([\.$?*|{}\[\]\\\/\+^])/g, '\\$1') + "=([^;]*)")); return matches ? decodeURIComponent(matches[1]) : undefined; })('EPDFTIPS_cookie_box_viewed'); if (EPDFTIPS_cookie_box_viewed) { hide_EPDFTIPS_cookie_box(); } })(); </script>  </body> </html> <script data-cfasync="false" src="/cdn-cgi/scripts/5c5dd728/cloudflare-static/email-decode.min.js"></script>