Communications in Computer and Information Science
22
Joaquim Filipe Boris Shishkov Markus Helfert Leszek A. Maciaszek (Eds.)
Software and Data Technologies Second International Conference, ICSOFT/ENASE 2007 Barcelona, Spain, July 22-25, 2007 Revised Selected Papers
13
Volume Editors Joaquim Filipe Polytechnic Institute of Setúbal/INSTICC Av. D. Manuel I, 27A - 2. Esq., 2910-595 Setúbal, Portugal E-mail: jfi
[email protected] Boris Shishkov Interdisciplinary Institute for Collaboration and Research on Enterprise Systems and Technology – IICREST P.O. Box 104, 1618 Sofia, Bulgaria E-mail:
[email protected] Markus Helfert Dublin City University School of Computing Dublin 9, Ireland E-mail:
[email protected] Leszek A. Maciaszek Macquarie University Department of Computing Sydney, NSW, 2109, Australia E-mail:
[email protected]
Library of Congress Control Number: 2008939368 CR Subject Classification (1998): D.2, E.1, D.3, I.2.4, C.1.4 ISSN ISBN-10 ISBN-13
1865-0929 3-540-88654-0 Springer Berlin Heidelberg New York 978-3-540-88654-9 Springer Berlin Heidelberg New York
This work is subject to copyright. All rights are reserved, whether the whole or part of the material is concerned, specifically the rights of translation, reprinting, re-use of illustrations, recitation, broadcasting, reproduction on microfilms or in any other way, and storage in data banks. Duplication of this publication or parts thereof is permitted only under the provisions of the German Copyright Law of September 9, 1965, in its current version, and permission for use must always be obtained from Springer. Violations are liable to prosecution under the German Copyright Law. Springer is a part of Springer Science+Business Media springer.com © Springer-Verlag Berlin Heidelberg 2008 Printed in Germany Typesetting: Camera-ready by author, data conversion by Scientific Publishing Services, Chennai, India Printed on acid-free paper SPIN: 12549450 06/3180 543210
Preface
This book contains the best papers of the Second International Conference on Software and Data Technologies (ICSOFT 2007), held in Barcelona, Spain. It was organized by the Institute for Systems and Technologies of Information, Communication and Control (INSTICC), co-sponsored by the Workflow Management Coalition (WfMC), in cooperation with the Interdisciplinary Institute for Collaboration and Research on Enterprise Systems and Technology (IICREST). The purpose of ICSOFT 2007 was to bring together researchers and practitioners interested in information technology and software development. The conference tracks were “Software Engineering,” “Information Systems and Data Management,” “Programming Languages,” “Distributed and Parallel Systems” and “Knowledge Engineering.” Being crucial for the development of information systems, software and data technologies encompass a large number of research topics and applications: from implementation-related issues to more abstract theoretical aspects of software engineering; from databases and data warehouses to management information systems and knowledge-base systems; next to that, distributed systems, pervasive computing, data quality and other related topics are included in the scope of this conference. ICSOFT 2007 received 292 paper submissions from more than 56 countries in all continents. To evaluate each submission, a double-blind evaluation method was used: each paper was reviewed by at least two internationally known experts from the ICSOFT Program Committee. Only 41 papers were selected to be published and presented as full papers, i.e., completed work (8 pages in proceedings / 30-min oral presentations), 74 additional papers describing work-in-progress were accepted as short papers for 20-min oral presentation, leading to a total of 115 oral paper presentations. Another 76 papers were selected for poster presentation. The full-paper acceptance ratio was thus 14%, and the total oral paper acceptance ratio was 39%. ICSOFT was organized in conjunction with ENASE––the Evaluation of Novel Approaches to Software Engineering working conference. ENASE provides a yearly forum for researchers and practitioners to review and evaluate new software development methodologies, practices, architectures, technologies and tools. The background body of knowledge for ENASE is formed by novel approaches to software engineering with emphasis on software product and process improvement. This book includes a special section with the three best papers from ENASE. We hope that you will find these papers interesting and we hope they represent a helpful reference in the future for all those who need to address any of the research areas mentioned above.
August 2008
Joaquim Filipe Boris Shishkov Markus Helfert Leszek Maciaszek
Conference Committee
Conference Chair Joaquim Filipe
Polytechnic Institute of Setúbal / INSTICC, Portugal
Program Co-chairs Cesar Gonzalez-Perez Markus Helfert Leszek A. Maciaszek Boris Shishkov
IEGPS, CSIC, Spain (ENASE) Dublin City University, Ireland (ICSOFT) Macquarie University - Sydney, Australia (ENASE) University of Twente, The Netherlands (ICSOFT)
Organizing Committee Paulo Brito Marina Carvalho Helder Coelhas Vera Coelho Andreia Costa Bruno Encarnação Luís Marques Vitor Pedrosa Vera Rosário Mónica Saramago
INSTICC, Portugal INSTICC, Portugal INSTICC, Portugal INSTICC, Portugal INSTICC, Portugal INSTICC, Portugal INSTICC, Portugal INSTICC, Portugal INSTICC, Portugal INSTICC, Portugal
ICSOFT Program Committee Francisco Abad, Spain Sergey Jemal Abawajy, Australia Silvia Abrahão, Spain Muhammad Abulaish, India Hamideh Afsarmanesh, The Netherlands Jacky Akoka, France Rafa Al Qutaish, Canada Markus Aleksy, Germany Tsanka Petrova Angelova, Bulgaria Keijiro Araki, Japan Alex Aravind, Canada
Colin Atkinson, Germany Juan Carlos Augusto, UK Elisa Baniassad, China Luciano Baresi, Italy Joseph Barjis, USA Bernhard Beckert, Germany Noureddine Belkhatir, France Fevzi Belli, Germany Alexandre Bergel, Germany Sue Black, UK Maarten Boasson, The Netherlands
VIII
Organization
Wladimir Bodrow, Germany Marcello Bonsangue, The Netherlands Pere Botella, Spain Lisa Brownsword, USA Gerardo Canfora, Italy Cinzia Cappiello, Italy Antonio Cerone, China W.K. Chan, Hong Kong Shiping Chen, Australia T.Y. Chen, Australia Kung Chen, Taiwan, R.O.C. Samuel Chong, UK Peter Clarke, USA Rolland Colette, France Rem Collier, Ireland Kendra Cooper, USA Alfredo Cuzzocrea, Italy Bogdan Czejdo, USA Mehdi Dastani, The Netherlands Sergio de Cesare, UK Clever de Farias, Brazil Rogerio de Lemos, UK Andrea De Lucia, Italy Serge Demeyer, Belgium Steven Demurjian, USA Elisabetta Di Nitto, Italy Massimiliano Di Penta, Italy Nikolay Diakov, The Netherlands Oscar Dieste, Spain Jan L.G. Dietz, The Netherlands Jin Song Dong, Singapore Jing Dong, USA Brian Donnellan, Ireland Juan C. Dueñas, Spain Jürgen Ebert, Germany Paul Ezhilchelvan, UK Behrouz Far, Canada Massimo Felici, UK Rudolf Ferenc, Hungary Juan Fernandez-Ramil, UK Bernd Fischer, UK Gerald Gannod, USA Jose M. Garrido, USA Dragan Gasevic, Canada Nikolaos Georgantas, France Paola Giannini, Italy
John Paul Gibson, France Holger Giese, Germany Karl Goeschka, Austria Swapna Gokhale, USA Jose Ramon Gonzalez de Mendivil, Spain Jesus M. Gonzalez-Barahona, Spain Daniela Grigori, France Klaus Grimm, Germany Yann-Gaël Guéhéneuc, Canada Tibor Gyimothy, Hungary Michael Hanus, Germany Naohiro Hayashibara, Japan Reiko Heckel, UK Christian Heinlein, Germany Markus Helfert, Ireland Rattikorn Hewett, USA Jang-Eui Hong, Republic of Korea Shinichi Honiden, Japan Ilian Ilkov, The Netherlands Ivan Ivanov, USA Stephen Jarvis, UK Damir Kalpic, Croatia Krishna Kavi, USA Taghi Khoshgoftaar, USA Roger (Buzz) King, USA Paul Klint, The Netherlands Alexander Knapp, Germany Mieczyslaw Kokar, USA Rainer Koschke, Germany Jens Krinke, Germany Padmanabhan Krishnan, Australia Martin Kropp, Switzerland Tei-Wei Kuo, Taiwan, R.O.C. Yvan Labiche, Canada Michele Lanza, Switzerland Eitel Lauria, USA Insup Lee, USA Jonathan Lee, Taiwan, R.O.C. Yu Lei, USA Hareton Leung, Hong Kong Kuan-Ching Li, Taiwan, R.O.C. Man Lin, Canada Panos Linos, USA Hua Liu, USA Chengfei Liu, Australia
Organization
David Lorenz, USA Christof Lutteroth, New Zealand Jianhua Ma, Japan Broy Manfred, Germany Tiziana Margaria, Germany Katsuhisa Maruyama, Japan Johannes Mayer, Germany Tommaso Mazza, Italy Fergal McCaffery, Ireland Hamid Mcheick, Canada Massimo Mecella, Italy Karl Meinke, Sweden Simão Melo de Sousa, Portugal Emilia Mendes, New Zealand Manoel Mendonça, Brazil Raffaela Mirandola, Italy Hristo Mirkov, USA Prasenjit Mitra, USA Dimitris Mitrakos, Greece Birger Møller-Pedersen, Norway Mattia Monga, Italy Sandro Morasca, Italy Maurizio Morisio, Italy Markus Müller-Olm, Germany Paolo Nesi, Italy Alan O'Callaghan, UK Rory O’Connor, Ireland Pasi Ojala, Finland Claus Pahl, Ireland Witold Pedrycz, Canada Steve Peters, The Netherlands Mario Piattini, Spain Martin Pinzger, Switzerland Lori Pollock, USA Andreas Polze, Germany Peter Popov, UK Wenny Rahayu, Australia Jolita Ralyte, Switzerland Anders P. Ravn, Denmark Marek Reformat, Canada Arend Rensink, The Netherlands Werner Retschitzegger, Austria Gustavo Rossi, Argentina Guenther Ruhe, Canada
Stefano Russo, Italy Mortaza S. Bargh, The Netherlands Shazia Sadiq, Australia Francesca Saglietti, Germany Bernhard Schätz, Germany Douglas Schmidt, USA Andy Schürr, Germany Isabel Seruca, Portugal Samir Shah, USA Boris Shishkov, The Netherlands Harvey Siy, USA Jacob Slonim, Canada George Spanoudakis, UK Peter Stanchev, USA Nenad Stankovic, Japan Larry Stapleton, Ireland Richard Starmans, The Netherlands Leon Sterling, Australia Junichi Suzuki, USA Ramayah T., Malaysia Yarar Tonta, Turkey Mark van den Brand, The Netherlands Marten van Sinderen, The Netherlands Enrico Vicario, Italy Aurora Vizcaino, Spain Christoph von Praun, USA Christiane Gresse von Wangenheim, Brazil Bing Wang, UK Edgar Weippl, Austria Danny Weyns, Belgium Ing Widya, The Netherlands Dietmar Wikarski, Germany Hongwei Xi, USA Haiping Xu, USA Hongji Yang, UK Tuba Yavuz-Kahveci, USA Rym Zalila Mili, USA Kang Zhang, USA Du Zhang, USA Xiaokun Zhang, Canada Jianjun Zhao, China Hong Zhu, UK Andrea Zisman, UK
IX
X
Organization
ENASE Program Committee Pekka Abrahamsson, Finland Witold Abramowicz, Poland Mehmet Aksit, The Netherlands Colin Atkinson, Germany Giuseppe Berio, Italy Lawrence Chung, USA Jens Dietrich, New Zealand Schahram Dustdar, Austria Jonathan Edwards, USA Maria João Ferreira, Portugal Bogdan Franczyk, Germany Ulrich Frank, Germany Steven Fraser, USA Paolo Giorgini, Italy Cesar Gonzalez-Perez, Spain Brian Henderson-Sellers, Australia Zbigniew Huzar, Poland Stefan Jablonski, Germany Ryszard Kowalczyk, Australia
Philippe Kruchten, Canada Michele Lanza, Switzerland Xabier Larurcea, Spain Pericles Loucopoulos, UK Leszek Maciaszek, Australia Lech Madeyski, Poland Janis Osis, Latvia Jeffrey Parsons, Canada Mario Piattini, Spain Bala Ramesh, USA Gil Regev, Switzerland Francisco Ruiz, Spain Motoshi Saeki, Japan Keng Siau, USA Dave Thomas, Canada Rainer Unland, Germany Jean Vanderdonckt, Belgium Jaroslav Zendulka, Czech Republic
ICSOFT Auxiliary Reviewers Jonatan Alava, USA David Arney, USA Louise Avila, USA Djuradj Babich, USA Tibor Bakota, Hungary Nurlida Basir, UK Massimo Canonico, Italy Glauco Carneiro, Brazil Su-Ying Chang, Taiwan, R.O.C. Shih-Chun Chou, Taiwan, R.O.C. Daniela Cruzes, Brazil Marco D'Ambros, Switzerland Florian Deissenböck, Germany Daniele Theseider Duprè, Italy Lavinia Egidi, Italy Ekaterina Ermilove, The Netherlands Hua-Wei Fang, Taiwan, R.O.C. Massimo Ficco, Italy Christina von Flach, Brazil Rita Francese, Italy Lajos Fulop, Hungary Lajos Jenő Fülöp, Hungary
Udo Gleich, Germany Leonardo Grassi, Italy Andreas Griesmayer, Macau SAR China Ralph Guderlei, Germany Michael Haupt, Germany Stefan Henkler, Germany Martin Hirsch, Germany Florian Hoelzl, Germany Bernhard Hohlfeld, Germany Endre Horváth, Hungary Ping-Yi Hsu, Taiwan, R.O.C. Judit Jasz, Hungary Joop de Jong, The Netherlands Elrmar Juergens, Germany Madhan Karky, Australia Steven van Kervel, The Netherlands Tariq M. King, USA Peter Lammich, Germany Massimiliano de Leoni, Italy Martin Leucker, Germany Yun-Hao Li, Taiwan, R.O.C. Adrian Lienhard, Switzerland
Organization
Ruopeng Lu, Australia Heng Lu, Hong Kong Viviane Malheiros, Brazil Sergio Di Martino, Italy Michael Meisinger, Germany Samar Mouchawrab, Canada Simon S. Msanjila, The Netherlands Sudarsanan Nesmony, Australia Joseph Okika, Denmark Rocco Oliveto, Italy Jennie Palmer, UK Ignazio Passero, Italy Gustavo Perez, USA Christian Pfaller, Germany Roberto Pietrantuono, Italy Dan Ratiu, Germany Giancarlo Ruffo, Italy Ruggero Russo, Italy Laís Salvador, Brazil
XI
Valeriano Sandrucci, Italy Giuseppe Scanniello, Italy Siraj Shaikh, Macau SAR China Marwa Shousha, Canada Istvan Siket, Hungary Carine Souveyet, France Michael Sowka, Canada Bas Steunebrink, The Netherlands Tatiana Tavares, Brazil Matthias Tichy, Germany Carlo Torniai, Italy Kun-Yi Tsai, Taiwan, R.O.C. Laszlo Vidacs, Hungary Stefan Wagner, Germany Doris Wild, Germany Tao Yue, Canada Zhenyu Zhang, Hong Kong Xiaohui Zhao, Australia
ENASE Auxiliary Reviewers Monika Starzecka, Poland Dominique Stein, Germany
Jong Woo, USA
Invited Speakers Jan Dietz David Lorge Parnas Kalle Lyytinnen Stephen Mellor Bart Nieuwenhuis Tony Shan Brian Fitzgerald
Delft University of Technology, The Netherlands University of Limerick, Ireland Case Western Reserve University, Canada Australia K4B Innovation / University of Twente, The Netherlands Bank of America, USA Lero - the Irish Software Engineering Research Centre, Ireland
Table of Contents
Invited Papers Benefits of Enterprise Ontology for the Development of ICT-Based Value Networks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Antonia Albani and Jan L.G. Dietz SOA Pragmatism . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Tony C. Shan
3
23
Software and Data Technologies Part I: Programming Languages A Simple Language for Novel Visualizations of Information . . . . . . . . . . . . Wendy Lucas and Stuart M. Shieber
33
Generic Components for Static Operations at Object Level . . . . . . . . . . . . Andreas P. Priesnitz and Sibylle Schupp
46
A Visual Dataflow Language for Image Segmentation and Registration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Hoang D.K. Le, Rongxin Li, S´ebastien Ourselin, and John Potter A Debugger for the Interpreter Design Pattern . . . . . . . . . . . . . . . . . . . . . . . Jan Vran´y and Alexandre Bergel
60
73
Part II: Software Engineering Concepts for High-Perfomance Scientific Computing . . . . . . . . . . . . . . . . . . Ren´e Heinzl, Philipp Schwaha, Franz Stimpfl, and Siegfried Selberherr
89
A Model Driven Architecture Approach to Web Development . . . . . . . . . . Alejandro G´ omez Cuesta, Juan Carlos Granja, and Rory V. O’Connor
101
Reverse-Architecting Legacy Software Based on Roles: An Industrial Experiment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Philippe Dugerdil and Sebastien Jossi
114
XIV
Table of Contents
A Supporting Tool for Requirements Elicitation Using a Domain Ontology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Motohiro Kitamura, Ryo Hasegawa, Haruhiko Kaiya, and Motoshi Saeki Pattern Detection in Object-Oriented Source Code . . . . . . . . . . . . . . . . . . . Andreas Wierda, Eric Dortmans, and Lou Somers Testing the Effectiveness of MBIUI Life-Cycle Framework for the Development of Affective Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Katerina Kabassi, Maria Virvou, and Efthymios Alepis Developer Stories: Improving Architecture in Agile Practice – How Facilitating Knowledge Management and Putting the Customer in the Drivers Seat Enables Sound Architectural Design . . . . . . . . . . . . . . . . . . . . Rolf Njor Jensen, Niels Platz, and Gitte Tjørnehøj An Ontological SW Architecture Supporting Agile Development of Semantic Portals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Giacomo Bucci, Valeriano Sandrucci, and Enrico Vicario The Vcodex Platform for Data Compression . . . . . . . . . . . . . . . . . . . . . . . . . Kiem-Phong Vo
128
141
159
172
185
201
Part III: Distributed and Parallel Systems Classification of Benchmarks for the Evaluation of Grid Resource Planning Algorithms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Wolfgang S¨ uß, Alexander Quinte, Wilfried Jakob, and Karl-Uwe Stucky A Disconnection-Aware Mechanism to Provide Anonymity in Two-Level P2P Systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . J.P. Mu˜ noz-Gea, J. Malgosa-Sanahuja, P. Manzanares-Lopez, J.C. Sanchez-Aarnoutse, and J. Garcia-Haro
215
228
Part IV: Information Systems and Data Management Approximation and Scoring for XML Data Management . . . . . . . . . . . . . . Giacomo Buratti and Danilo Montesi
243
Quantitative Analysis of the Top Ten Wikipedias . . . . . . . . . . . . . . . . . . . . Felipe Ortega, Jesus M. Gonzalez-Barahona, and Gregorio Robles
257
A Semantic Web Approach for Ontological Instances Analysis . . . . . . . . . Roxana Danger and Rafael Berlanga
269
Table of Contents
Aspects Based Modeling of Web Applications to Support Co-evolution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Buddhima De Silva and Athula Ginige
XV
283
Part V: Knowledge Engineering Recommending Trustworthy Knowledge in KMS by Using Agents . . . . . . Juan Pablo Soto, Aurora Vizca´ıno, Javier Portillo-Rodr´ıguez, and Mario Piattini Recent Developments in Automated Inferencing of Emotional State from Face Images . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Ioanna-Ourania Stathopoulou and George A. Tsihrintzis Inconsistency-Tolerant Integrity Checking for Knowledge Assimilation . . Hendrik Decker Improving Cutting-Stock Plans with Multi-objective Genetic Algorithm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Ramiro Varela, Cesar Mu˜ noz, Mar´ıa Sierra, and In´es Gonz´ alez-Rodr´ıguez Knowledge Purpose and Visualization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Wladimir Bodrow and Vladimir Magalashvili Empirical Experimentation for Validating the Usability of Knowledge Packages in Transferring Innovations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Pasquale Ardimento, Maria Teresa Baldassarre, Marta Cimitile, and Giuseppe Visaggio An Ontological Investigation in the Field of Computer Programs . . . . . . . Pascal Lando, Anne Lapujade, Gilles Kassel, and Fr´ed´eric F¨ urst
297
310 320
332
345
357
371
Evaluation of Novel Approaches to Software Engineering Formal Problem Domain Modeling within MDA . . . . . . . . . . . . . . . . . . . . . Janis Osis, Erika Asnina, and Andrejs Grave
387
Model Based Testing for Agent Systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . Zhiyong Zhang, John Thangarajah, and Lin Padgham
399
A Metamodel for Defining Development Methodologies . . . . . . . . . . . . . . . Manuel Bollain and Juan Garbajosa
414
Author Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
427
Invited Papers
Benefits of Enterprise Ontology for the Development of ICT-Based Value Networks Antonia Albani and Jan L.G. Dietz Delft University of Technology Chair of Information Systems Design PO Box 5031, 2600 GA Delft, The Netherlands {a.albani,j.l.g.dietz}@tudelft.nl
Abstract. The competitiveness of value networks is highly dependent on the cooperation between business partners and the interoperability of their information systems. Innovations in information and communication technology (ICT), primarily the emergence of the Internet, offer possibilities to increase the interoperability of information systems and therefore enable inter-enterprise cooperation. For the design of inter-enterprise information systems, the concept of business component appears to be very promising. However, the identification of business components is strongly dependent on the appropriateness and the quality of the underlying business domain model. The ontological model of an enterprise – or an enterprise network – as presented in this article, is a highquality and very adequate business domain model. It provides all essential information that is necessary for the design of the supporting information systems, and at a level of abstraction that makes it also understandable for business people. The application of enterprise ontology for the identification of business components is clarified. To exemplify our approach, a practical case is taken from the domain of strategic supply network development. By doing this, a widespread problem of the practical application of inter-enterprise information systems is being addressed.
1 Introduction Driven by drastic changing market conditions companies are facing an increasingly complex competitive landscape. Decisive factors such as globalization of sales and sourcing markets, shortened product life cycles, innovative pressure on products, services and processes and customers’ request for individual products are forcing companies to undergo a drastic transformation of business processes as well as organizational and managerial structures [1]. The shift from a function-oriented to a process-oriented organization with a strong customer focus is essential in order to better adapt to fast changing market requirements and to become more flexible while meeting individual customer demands. Within an enterprise the core business processes need to be identified, improved and (partly) automated, while at the same time other processes are outsourced to business partners [2, 3]. As a consequence, business processes concerning e.g. product development, market research, sales, production, J. Filipe et al. (Eds.): ICSOFT/ENASE 2007, CCIS 22, pp. 3–22, 2008. © Springer-Verlag Berlin Heidelberg 2008
4
A. Albani and J.L.G. Dietz
delivery and services are affected and have to be adjusted and integrated not only within a single company but also over multiple tiers of suppliers. Corporate networks, so called value networks [4-6], are formed to better fulfill specific customer requests providing customized products on time in the right quality and at a competitive price. In order to enhance the competitive advantages of value networks, the selection, development, management and integration of respective suppliers, located not only in tier-1 but also in the subsequent tiers, is of great relevance for enabling effective cooperation between enterprises. Modern information and communication technologies (ICT) – like the Internet, semantic standards, distributed applications, component based and service-oriented architectures – are necessary in order to enable the creation and management of dynamic corporate networks [7]. However, the deployment of information and communication technologies for enabling interoperability between business partners does not always meet expectations. At present, ICT-enabled value networks can be largely found in the form of rather small, flexible alliances of professionalized participants. The support of large value networks with multiple tiers of suppliers still causes considerable difficulties. The high degree of complexity resulting from dynamic changes in value networks is the main reason for the lack of practical implementations [8]. Looking at the potential of enabling and improving inter-enterprise cooperation by applying ICT, this article contributes to that area by illustrating the benefits of enterprise ontology for the development of ICT-based value networks. For developing intra- and inter-enterprise information systems it is necessary to use a suitable methodology for modeling the business domain satisfying defined quality criteria and for eliciting the relevant business requirements. Additionally, information systems need to be modeled on a level of abstraction that is understood also by the business people, who are defining the requirements and using the respective systems. The application of business components [9] for the design of high-level information systems appears to be adequate since they directly implement the business activities in an enterprise [9]. All other components are considered either to deliver services to these business components or to offer some general functionality. The identification of business components thus is the first step in the development of an information system according to current standards (component-based, object-oriented, etc.). Needless to say that this step is a very crucial one and that it should be performed at the highest possible level of quality. In the area of business components identification the research initiatives are still scarce see [10-12]. Vitharana [13] recognized that more formal approaches are needed to make the component based paradigm into an effective development tool. The starting point is the set of requirements that have been elicited from the business domain. Requirements engineering is still a weak link, although considerable improvements can be achieved if it is based on an appropriate and highquality business domain model. Such a model offers a more objective starting point for extracting requirements and a more objective criterion for evaluating them than the traditional ‘waiter strategy’ [14]. In a very true sense however, this new approach to engineering requirements shifts the problem only to an earlier stage instead of solving it. The crucial factors now are the appropriateness and the quality of the business domain model. In [15] some quality criteria are proposed regarding a business domain model, which we adopted for our current research:
Benefits of Enterprise Ontology for the Development of ICT-Based Value Networks
5
• It should make a clear and well-founded distinction between the essential business and infological actions. For example, delivering services to customers is essential, but computing the price to be paid is infological (it doesn’t produce a new fact). • It should have the right granularity or level of detail. "Right" in this respect means: finding the actions that are atomic from the business point of view. They may be composite only in their implementations. For example, the request to a supplier is atomic from the business point of view, but to perform a request by postal mail, a number of other (non-essential) actions have to be taken like sending the order form, transporting it and delivering it to the supplier. • It should be complete, i.e. it should contain everything that is necessary and it should not contain anything that is irrelevant. As will be shown in the following, this requirement is probably the hardest to satisfy since it is common practice in most organizations to perform several kinds of coordination acts tacitly, according to the rule "no news is good news". We call a business domain model that satisfies these requirements an enterprise ontology. Several domain modeling techniques exist propagating the business specific aspect of enterprise modeling, but most of them do not satisfy the quality criteria just mentioned. Looking at business processes modeling techniques, being a relevant part of domain modeling, next to the traditional flow charts, there exist e.g. Petri Net [16, 17], Event Driven Process Chains (EPC) [18] and Activity Diagrams [19]. However, in these techniques the notion of business processes is not well defined and there exists no distinction between business and infological actions. Consequently the difference between business processes and other kinds of process remains unclear. This leads to the conclusion that they do not specifically address business processes but can be used for any discrete event process. Other approaches, as e.g. from the Language/Action Perspective (LAP), claim to offer a solution for the mismatch between social perspectives and technical perspectives by explicitly focusing on business specific communication patterns, where social beings achieve changes in the (object) world by means of communication acts [20]. The enterprise ontology [21, 22] methodology is an approach that incorporates LAP and that additionally distinguishes between essential (business), infological and datalogical acts and facts, ultimately resulting in the distinction between three aspect organizations: the B-organization (B from business), the I-organization (I from infological), and the D-organization (D from datalogical). The apparent advantages of enterprise ontology – in particular the huge reduction of complexity [23] – led us to choose this methodology for modeling the business domain. This article builds on previous work regarding enterprise ontology [21, 22] and business components [24-26]. To exemplify the usability of the proposed enterprise ontology and the identification of business components the domain of strategic supply network development [27-29] is introduced as a practical application of interenterprise information systems. The domain extends the frame of reference in strategic sourcing from a supplier centric to a supply network perspective and addresses a widespread problem in the practical application of inter-enterprise information systems. It is structured as follows: in section 2 the domain of strategic supply network development (SSND) is introduced. SSND is used throughout the article as an example domain for inter-enterprise cooperation. In section 3 we present the method that is used to arrive at a right ontological model of an enterprise. To illustrate it, the
6
A. Albani and J.L.G. Dietz
ontology of the SSND case is developed. In section 4, the method for identifying business components is applied to the SSND case. Discussions of the results as well as the conclusions that can be drawn are provided in section 5.
2 The Domain of Strategic Supply Network Development The relevance of the purchasing function in enterprises has increased steadily over the past two decades. Till the 70’s, purchasing was widely considered an operational task with no apparent influence on long term planning and strategy development [30]. This narrow perspective was broadened by research that documented the positive influence that a targeted supplier cooperation and qualification could bring to a company's strategic options [31]. In the 80’s, trends spurred the recognition of the eminent importance of the development and management of supplier relationships for gaining competitive advantages. Such trends were e.g., the growing globalization, the focus on core competencies in the value chain with connected in-sourcing and out-sourcing decisions, as well as new concepts in manufacturing. As a result, purchasing gradually gained strategic relevance on top of its operational and tactical relevance [32]. Based on these developments, purchasing has become a core function in the 90’s. Current empiric research shows a significant correlation between the establishment of a strategic purchasing function and the financial success of an enterprise, independent from the industry surveyed [33, p. 513]. One of the most important factors in this connection is the buyer-supplier-relationship. At many of the surveyed companies, a close cooperation between buyer and supplier led to process improvements and resulting cost reductions that were shared between buyer and suppliers [33, p. 516]. In practice, supplier development is widely limited to suppliers in tier-1, i.e. the direct suppliers. With respect to the superior importance of supplier development, as mentioned above, we postulated the extension of the traditional frame of reference in strategic sourcing from a supplier-centric to a supply-network scope [27-29]. It means the further development of the strategic supplier development to a strategic supply network development. This shifted the perspective in the field of strategic sourcing to analyze multi-tier supplier networks instead of single suppliers.
Fig. 1. Functional decomposition diagram for strategic supply network development
Benefits of Enterprise Ontology for the Development of ICT-Based Value Networks
7
The tasks within the strategic supply network development can be grouped into 3 main areas as illustrated in Fig. 1: strategic demand planning, strategic supply network modeling and strategic supply network qualification [34]. Within the function strategic demand planning, a corporate framework for all purchasing-related activities is defined. This framework consists of a consistent and corporate-wide valid purchasing strategy (define purchasing strategy), a strategic demand planning and demand bundling function (plan strategic demand), and the definition of methods and tools to control performance and efficiency of purchasing and to establish a conflict management concept (define operational framework). The function strategic supply network modeling provides a methodology for the identification (identify strategic supply network), evaluation (evaluate strategic supply network) and selection (select strategic supply network) of potential suppliers, not only located in tier-1 but also in the subsequent tiers. Using evaluation criteria such as lowest cost, shortest delivery time or best quality, and corresponding evaluation methods, the identified supply networks are evaluated. If there is a positive result on the evaluation, the supply network is selected and contractually linked to the company. Within the function strategic supply network qualification, the quality of a performing supplier network is evaluated using evaluation criteria and evaluation methods (evaluate quality of supply network). Dependent on the result of the evaluation, sanctions may be used to improve the quality of the supply network (improve quality of supply network). In this article we focus on the modeling of strategic supply networks and specifically on the identification sub-task. The reason for it is that compared to the traditional strategic purchasing the supplier selection process undergoes the most evident changes in the shift to a supply network perspective. The expansion of the traditional frame of reference in strategic sourcing requires more information than merely data on existing and potential suppliers in tier-1. Instead, the supply networks connected with those suppliers have to be identified and evaluated, e.g., by comparing alternative supply networks. Since the identification of strategic supply networks builds the basis for the evaluation and selection, we introduce shortly the preliminary work done in the area of identification and modeling of strategic supply networks [27, 29, 34]. To model and visualize the network in a structured way, a specific strategic demand for a product to be manufactured is communicated from the OEM to existing and/or potential suppliers. Fig. 2 illustrates an example for an identification process and its results. In the example the OEM is connected to a potential network of suppliers as shown in the left part of Fig. 2. It is assumed that the OEM needs to order two products externally, product 1 and product 2. During the identification process the OEM sends out demands for these products to its strategic suppliers in tier-1. In the example it is assumed that supplier 1-1 and supplier 1-2 get the demand for product 1 while supplier 1-3, supplier 1-4 and supplier 1-5 receive the demand for product 2. These suppliers check whether they can fulfill the demand internally and, if not, send out subsequent demands to their respective suppliers. Each node executes the same process as described until the demand has reached the last tier. The requested information is then returned to the OEM, aggregated and finally visualized as a supply network, in which each participant of the supply network constitutes a network node.
8
A. Albani and J.L.G. Dietz
Fig. 2. Example for result of identification process
This process may result in the identification of several possible supply networks as shown in the right part of Fig. 2, where e.g. product 1 can be provided by two supply networks, supply network 1 (root node S1-1) and supply network 2 (root node S1-2), whereas product 2 can only be provided by supply network 3. It is now up to the OEM to decide which of the potential strategic supply networks (in the example above for product 1) will be selected to fulfill its original demand. Therefore an evaluation process is necessary which has been introduced by the authors in [35]; it will not be elaborated in detail in this article.
3 Enterprise Ontology and Its Application to the SSND Case As motivated in the introduction, we apply enterprise ontology for modeling the business domain. The specific methodology that is used for constructing the ontology of an enterprise is DEMO (Design & Engineering Methodology for Organizations) [20, 21, 36, 37]. As is explained in [21, 36, 37] a distinction is made between production acts and facts and coordination acts and facts. The transaction axiom aggregates these acts/facts into the standard pattern of the (business) transaction. Consequently, two worlds are distinguished: the production world (P-world) and the coordination world (C-world). The complete ontological model of an organization in DEMO consists of four aspect models (Fig. 3). The Construction Model (CM) specifies the composition, the environment and the structure of the organization. It contains the identified transaction types and the associated actor roles and describes the links to production or coordination banks, where all production and coordination facts are stored. The Process Model (PM) details each
Benefits of Enterprise Ontology for the Development of ICT-Based Value Networks
9
single transaction type of the CM according to the universal transaction pattern [21]. In addition, the causal and conditional relationships between transactions are exhibited. The Action Model (AM) specifies the action rules that serve as guidelines for the actors in dealing with their agenda. It contains one or more action rules for every agendum type. The State Model (SM) specifies the object classes, fact types and ontological coexistence rules in the production world. Organization Construction Diagram
Actor Transaction Diagram Transaction Result Table
Actor Bank Diagram
CM
Process Step Diagram
Bank Contents Table
Object Fact Diagram
PM SM Object Property Table
Information Use Table
AM Action Rule Specifications
Fig. 3. The four aspect models
In Fig. 3 the CM triangle is split by a dashed line in a left and a right part. This is due to the logical sequence of producing the aspect models. First, the left part of the CM can be made straight away after having applied the elicitation procedure as discussed in [38]. It contains the active influences among actor roles, being initiator or executor of a transaction type. The CM is expressed in an Actor Transaction Diagram and a Transaction Result Table. Next, the Process Step Diagram, which represents a part of the PM, is produced and after that the AM, which contains the Action Rule Specifications. The action rules are expressed in a pseudo-algorithmic language, by which an optimal balance between readability and preciseness is achieved. Then the SM is produced, expressed in an Object Fact Diagram and an Object Property Table. Next, the right part of the CM is produced. It consists of an Actor Bank Diagram and a Bank Contents Table. Usually the Actor Bank Diagram is drawn as an extension of the Actor Transaction Diagram. Together they constitute the Organization Construction Diagram. After that we are able to complete the PM with the Information Use Table, showing which information is used in which process steps. Based on this method, the ontology for the SSND case has been constructed. Space limitations prohibit us to provide a more extensive account of how the models in the figures below are developed. Also, we will not present and discuss the action rules. Fig. 4 exhibits the Organization Construction Diagram. The corresponding Transaction Result Table is shown in Table 1.
10
A. Albani and J.L.G. Dietz CA00: tier n company
A01
CA01 tier n-1 company
A02
T01
T02
offering
engineering
CPB03
engineerer
A03
CA02
T03
T01
exploring
tier n+1 company
offering
explorer
offerer
A04 T04
evaluator
CPB01
evaluating
CPB02
concluding
A05 T05
concluder
Fig. 4. Organization Construction Diagram of the SSND case Table 1. Transaction Result Table of the SSND case transaction type T01 offering T02 engineering T03 exploring T04 evaluating T05 concluding
resulting P-event type PE01 supply contract C is offered PE02 the BoM of assembly A is determined PE03 supply contract C is a potential contract PE04 supply contract C is evaluated PE05 supply contract C is concluded
The top or starting transaction type is the offering transaction T01. Instances of T01 are initiated by the environmental actor role CA01, which is a company in tier n-1 and executed by actor role A01 (offerer). This company asks the direct supplier (company in tier-n) for an offer regarding the supply of a particular product P. In order to make such an offer, A01 first initiates an engineering transaction T02, in order to get the bill of material of the requested product P. This is a list of (first-level) components of P, produced by A02 (engineerer). Next, A01 asks A03 (explorer) for every such component to get offers from companies that are able to supply the component. So, a number of exploring transactions T03 may be carried out within one T01, namely as many as there are components of P that are not produced by the tier-n company. In order to execute each of these transactions, A03 has to ask companies for an offer regarding the supply of a component of P. Since this is identical to the starting transaction T01, we model this also as initiating a T01. Now however, the executor of the T01 is a company in tier (n+1). Consequently, the model that is shown in Fig. 4 must be understood as to be repeated recursively for every tier until the products to be supplied are elementary, i.e. non-decomposable. Note that, because of the being recursive, an offer (the result of a T01) comprises the complete bill of material of the concerned component of P.
Benefits of Enterprise Ontology for the Development of ICT-Based Value Networks
11
Every offer from the companies in tier n+1 is evaluated in a T04 transaction by the actor role A04 (evaluator). So, there is a T04 for every ‘output’ T01, whereby each company can use their own evaluation and decision rules. The result of a T04 is a graded offer for some component of P. So, what A03 delivers back to A01 is a set of graded offers for every component of P. Next, A01 asks A05 (concluder), for every component of P, to select the best offer. The result is a set of concluded offers, one for every component of P. This set is delivered to A01. Lastly, A01 delivers a contract offer for supplying P, together with the set of concluded offers for delivering the components of P. Because of the recursive character of the whole model, this offer includes the complete bill of material of P, regardless its depth.
Fig. 5. Process Step Diagram of the SSND case
12
A. Albani and J.L.G. Dietz Table 2. Assignment of process steps to shortcuts process steps names request offering promise offering produce contract offering state offering accept offering request engineering promise engineering produce BoM explosion state engineering accept engineering request exploration promise exploration produce potential contract
shortcuts T01/rq T01/pm T01/ex T01/st T01/ac T02/rq T02/pm T02/ex T02/st T02/ac T03/rq T03/pm T03/ex
process steps names state exploration accept exploration request evaluation promise evaluation produce contract evaluation state evaluation accept evaluation request conclusion promise conclusion produce concluded contract state conclusion accept conclusion
Shortcuts T03/st T03/ac T04/rq T04/pm T04/ex T04/st T04/ac T05/rq T05/pm T05/ex T05/st T05/ac
The Organization Construction Diagram in Fig. 4 contains three external production banks. Bank CPB01 contains the data about a company that are relevant for the evaluation of offers. Bank CPB02 contains the different evaluation methods that can be applied. In every instance of T04, one of these methods is applied. CPB03 contains identifiers of all companies that may be addressed for an offer. Lastly, in the transaction result table (Table 1), the supply of a product by a (supplying) company to a (customer) company is called a contract. Fig. 5 exhibits the process step diagram of the SSDN case. Due to visualization reasons only shortcuts are listed for the single process steps. For real names see Table 2. The process step diagram is based on the universal transaction pattern [37]. It shows how the distinct transaction types are related. For the SSND example case, only the so-called basic pattern (request, promise, execute, state, accept) has been used. PF01
PF03
C
C
C is offered
C is a potential contract
C
F
F is the customer company of C
CONTRACT
C
COMPANY
F
F is the supplier company of C
C
P
PRODUCT
P is the product of C
ASSEMBLY PF05
PF04
A
P is a part of A
C
C
C is evaluated
C is concluded
EVALUATED CONTRACT
E
P
M
PF02 EVALUATION METHOD
the BoM of assembly A is determined
E is evaluated with M
Fig. 6. Object Fact Diagram of the SSND case
A
Benefits of Enterprise Ontology for the Development of ICT-Based Value Networks
13
Table 3. Object Property Table of the SSND property type < company information > < contract terms > sub_products(*) #sub_products(*) suppliers(*) sub_contracts(*) evaluation_mark evaluation_marks(*)
object class COMPANY CONTRACT PRODUCT PRODUCT CONTRACT * PRODUCT CONTRACT CONTRACT CONTRACT
scale < aggregated data > < aggregated data > set of PRODUCT NUMBER set of COMPANY set of CONTRACT NUMBER set of NUMBER
From the state T01/pm (promised) a number of transactions T03 (possibly none) and a number of transactions T05 (possibly none) are initiated, namely for every firstlevel component of a product. This is expressed by the cardinality range 0..k. Likewise, from the state T03/pm, a number of transactions T01 and a number of transactions T04 are initiated, namely for every offer or contract regarding a firstlevel component of a product. The dashed arrows, from an accept state (e.g. T02/ac) to some other transaction state, represent waiting conditions. So, for example, the performance of a T03/rq has to wait for the being performed of the T02/ac. Fig. 6 exhibits the Object Fact Diagram and Table 3 the Object Property Table. Together they constitute the State Model of the example case. The Object Fact Diagram is a variant of the Object Role Modeling (ORM) model [39]. One of the major differences is that the OFD contains diamond-shaped unary fact types for representing the results of transactions, i.e., the production fact types. They correspond with the transaction results in Table 1. A roundangle around a fact type or a role defines a concept in an extensional way, i.e. by specifying the object class that is its extension. For example, the roundangle around the production fact type “C is evaluated” defines the concept of evaluated contract. Lastly, the roundangle around the role “A” of the fact type “P is a part of A” defines all assemblies, i.e. all products that do have parts. Properties are binary fact types that happen to be pure mathematical functions, of which the range is set of, usually ordered, values, called a scale. Instead of including them in an Object Fact Diagram they can be more conveniently represented in an Object Property Table. The property types marked by “(*)” in the Object Property Table are derived fact types. The derivation rules are as follows: sub_products (P) #sub_products(P) suppliers(F,P)
sub_contracts(C) evaluation_marks (C)
= {X | X ∈ PRODUCT and X is a part of P}; = card(sub_products (P)); = {X | X ∈ COMPANY and (∃Y ∈ CONTRACT: P is the product of Y and X is the supplying company of Y and F is the customer company of Y)}; = {X | X ∈ CONTRACT and the product of X is Z and the product of C is Y and Z is a part of Y}; = {X | X is an evaluation mark of C};
The information items as defined in the SM, including the derived fact types, constitute all information that is needed to develop a supply network for a particular product.
14
A. Albani and J.L.G. Dietz
4 Identification of Business Components in the SSND Case The set of ontological models of an enterprise, as discussed above, constitutes the basis for the identification of business components. A business component provides a set of services out of a given business domain through well-defined interfaces and hides its implementation [40]. The specification of a business component is defined as a “complete, unequivocal and precise description of its external view” [41]. The enterprise ontology, satisfying the quality criteria (introduced in section 1) of providing a complete domain model, being described at the right granularity or level of detail and modeling only the essential business actions provides the necessary basis for the realization of business components. The enterprise ontology for the SSND case contains all essential information for that business domain. The business components identification (BCI) method [24-26] applied in this section aims at grouping business tasks and their corresponding information objects into business components satisfying defined metrics. The metrics used – being loosely coupling and tight cohesion – are the basic metrics for the component-based development of inter-enterprise business applications focusing on the deployment of components that can be used in different enterprise systems [42-44]. According to the classification of business components identification methods by [44], the BCI method combines Clustering Analysis and CRUD (Create, Read, Update, Delete) based methods. With the BCI method we satisfy the recommendation of Wang et al. of combining current component identification methods in order to achieve satisfactory results. Since the identification of business components is strongly dependant on the underlying business model, the BCI method uses the object classes and fact types from the State Model and the process steps from the Process Model, including their relationships. One can distinguish between three types of relationships necessary for the identification of business components. The relationship between single process steps, the relationship between information objects and the relationship between process steps and information objects. A relationship type distinguishes between subtypes expressing the significance of a relationship. E.g. the relationship between single process steps expresses – based on their cardinality constraints – how often a process step is executed within a transaction and therefore how close two process steps are related to each other in that business domain. The relationship between information objects defines how loosely or tightly the information objects are coupled, and the relationship between process steps and information objects defines whether a corresponding information object is used, created or altered while executing the respective process step. All types of relationship are of great relevance in order to define which information object and process steps belong to which component. The relationships are modeled in the BCI method using a weighted graph. As the nodes represent information objects and process steps, the edges characterize the relationships between the nodes. Weights are used to define the different types and subtypes of relationships and build the basis for assigning nodes and information objects to components. Due to display reasons the graph is visualized in a three-dimensional representation having the process steps and information objects arranged in circles, and without showing the corresponding weights (see Fig. 7).
Benefits of Enterprise Ontology for the Development of ICT-Based Value Networks
15
Fig. 7. Relationships between process steps and information objects
The graph shows all process steps and information objects as well as the relationships between them. For the purpose of clarity, only the shortcuts of all nodes are shown. For the real names, please see Table 2 and Table 4. Table 4. Assignment of information object names to shortcuts information object name Product Assembly Contract Evaluated Contract Potential Contract Concluded Contract Offered contract
shortcut P A C EC PC CC OC
In order to ensure optimal grouping satisfying the defined metrics of loosely coupling and tight cohesion, an optimization problem needs to be solved for which a genetic algorithm has been developed. The algorithm starts with a predefined solution (specific assignment of process steps and information objects to components) and generates better solutions through iterations. The starting solution is generated using a greedy graph-partitioning algorithm [45]. Using a model that provides a complete description of the relevant business domain implicates that a better starting solution is generated. The quality of the starting solution determines the quality of the resulting business components. The enterprise ontology provides an adequate basis for gaining all relevant information for building an adequate starting solution.
16
A. Albani and J.L.G. Dietz
For improving the starting solution, the Kernighan and Lin graph-partitioning algorithm [46] has been applied. This algorithm calculates the internal and external costs of the defined partitions and minimizes the external costs, representing minimal communication between components, by exchanging nodes between different graph partitions. Internal costs are defined as the sum of all weights of edges within a component, while external costs are defined as the sum of all weights of edges connecting nodes located in different partitions, and therefore in different components. Using this algorithm business component models have been generated for different business domains, starting from modeling small business domains, e.g. the one of strategic supply network development as presented in this article, to a business domain in the area of Customer Relationship Management (CRM) and Supply Chain Management (SCM) with more then 500 information objects and 1000 business tasks [47, 48]. In the following we describe how the information of the enterprise ontology is used to build the weighted graph that constitutes the basis for identifying business components, based on the optimization algorithm just explained. The relationship between process steps is provided by the order in which they are executed (visualized by a link between two process steps). For the identification of business components we distinguish between standard, optional and main links, defining the significance of the relationships between two process steps. This is expressed in Fig. 5 by the cardinality constraints assigned to the links. If a link has the cardinality range 0..1 we call it an optional link, since the following process step does not need to be executed. If the cardinality range is set to 0..n then we speak from a main link, indicating that the following process step is executed at least once. If no cardinality range is assigned to a link, we call it a standard link having the following process step executed exactly once. The different types of links are modeled by different weights in the graph. The process steps and their relationships are shown in Fig. 8, positioning all process steps as nodes in a circle and inserting edges for the relationship between two business services. Let us have a closer look at the information objects relevant for the information system to be built. Fig. 6 and Table 3 introduce different types of potential information objects, namely the object classes, fact types and property types. Object classes
Fig. 8. Relationship between process steps
Benefits of Enterprise Ontology for the Development of ICT-Based Value Networks
17
that are provided by external information systems, are traded in a special way in BCI method. They concern the data that are contained in the external production banks (see Fig. 4). Due to space limitations we omit this kind of information here. The remaining information objects relevant for the component identification of the SSND case and their relationships are shown in Fig. 9. Regarding the different types of relationships between single information objects we distinguish between part-of, state-of and related-to expressed by means of edge weights. In the example case a ‘Contract’ (C) that has been evaluated is a state-of ‘Contract’ (C). Additionally, we have ‘Product’ (P) being part-of ‘Assembly’ (A), whereas ‘Contract’ (C) is related-to a specific ‘Product’ (P).
Fig. 9. Relationship between information objects
Next, the relationships between information objects and business services are examined. The information to define those relationships can be gained from the Create/Use Table, see Table 5, which is an extension of the Information Use table of the enterprise ontology. Table 5. Create/Use Table of the SSND case object class or fact type PRODUCT product P is a part of product A the BoM of assembly A is determined ASSEMBLY CONTRACT
supply contract C is offered supply contract C is a potential contract supply contract C is evaluated with method M supply contract C is concluded
process steps T01/rq T01/pm T02/ex T02/rq T02/pm T02/st T02/ac T03/rq T03/pm T02/ac T02/ac T02/ex T03/ex T01/ex T01/st T01/ac T03/ex T03/st T03/ac T04/ex T04/rq T04/pm T04/st T04/ac T05/ex T05/rq T05/pm T05/st T05/ac T01/ac T03/ac T04/ac T05/ac
It contains object classes and fact types that are assigned to specific process steps by differentiating objects that are used and objects that are created. The process steps in which an instance of an object class or property type is created are printed in italic, as are the production fact types (transaction results). For the SSND example, the relationships between information objects and process steps and their weights are visualized in Fig. 10.
18
A. Albani and J.L.G. Dietz
Fig. 10. Relationship between process steps and information objects
Combining the three dimensions of node dependencies – between information objects, between business services and between information objects and business services (shown in Fig. 8, Fig. 9 and Fig. 10) – results in the three dimensional model as shown in Fig. 7. This model is the basis for applying the genetic algorithms in order to cluster related nodes within single components. Applying the BCI method to that graph results in the following graph clustering (see Fig. 11).
Fig. 11. Identified business components
Benefits of Enterprise Ontology for the Development of ICT-Based Value Networks
19
Now that all the nodes in the pictures are ordered and grouped as resulting from the optimization algorithm, two business components can be identified immediately: one containing the business tasks and information objects related to product management and one containing the business tasks and information objects related to contract management. The two components are therefore named Product Manager and Contract Manager and are shown in Fig. 12 according to the UML 2.0 notation [19].
Fig. 12. Identified business components with their provided and required services
It is evident that the derivation of the components is strongly dependent on the weights chosen. Different results could be achieved in assigning different weights to the edges in the graph. In applying the BCI method to many real world cases, we aim at deriving reference values for the different weights. Since the identified business components provide business services to or require business services from other business components either within an enterprise or between enterprises, the single business component services need to be defined. These services are related to the process steps executed in a business transaction. From the diagram in Fig. 5 – describing the process steps of the transaction types introduced in Fig. 4 – the business services are gained and modeled in Fig. 12 either as required services (composed of a semicircle attached to the related component by a line) or as provided services (composed of a circle attached to the component by a line). Even if for this small example only two business components were found, the derivation of the services and information objects assigned to the components would not have been possible without a detailed analysis and modeling of the business domain. This information is essential and provides the basis for the implementation of the business components. Place limitations prevented us to derive components from a larger example domain.
20
A. Albani and J.L.G. Dietz
5 Conclusions In this article, we have addressed the impact of using an enterprise ontology for identifying business components, defined as the highest level software components, directly supporting business activities. Although component-based software development may be superior to more traditional approaches, it leaves the problem of requirements engineering unsolved. Put differently, the component-based approach provides no criteria for determining that a set of identified components is complete (no component is missing) and minimal (there are no unnecessary components). Next to that, it provides no means for determining the point of departure, i.e. an appropriate model of the business domain. The method presented and demonstrated in this article does solve these problems. First, the enterprise ontology constructed by means of DEMO is an appropriate model of the business domain. It satisfies the quality criteria as proposed in the introduction. As a consequence, the identified business components do really and directly support the business activities in which original new facts are created. Moreover, since the process steps (cf. Fig. 5) are atomic from the business point of view, one can be sure to have found the finest level of granularity that has to be taken into account. Also, one can be sure that this set of process steps is complete and minimal. Second, the BCI method, based on the resulting models and tables of the enterprise ontology, provides an automated approach for the identification of business components satisfying defined metrics which are relevant for the development of reusable, marketable and self-contained business components. The metrics introduced in this article – being loosely coupling and tight cohesion – are the basic metrics for the component-based development of inter-enterprise business applications focusing on the deployment of components that can be on different enterprise systems. The usability of the proposed enterprise ontology and the identification of business components is illustrated by means of a practical application of the domain of strategic supply network development. The approach seams to be very promising, but for the identification of the business components additional simulations with different weights and different optimization algorithms are necessary in order to make it applicable in practice.
References 1. Burtler, P., et al.: A Revolution in Interaction. The McKinsey Quarterly 1/97, 4–23 (1997) 2. Davenport, T.H.: The Future of Enterprise System-Enabled Organizations. Information Systems Frontiers 2(2), 163–180 (2000) 3. Davenport, T.H., Short, J.E.: The New Industrial Engineering: Information Technology and Business Process Redesign. Sloan Management Review 31(4), 11 (1990) 4. Malone, T.W., Lautbacher, R.J.: The Dawn of the E-Lance Economy. Harvard Business Review, 145–152 (September-October 1998) 5. Pine, B.J., Victor, B., Boynton, A.C.: Making Mass Customization Work. Havard Business Review 36(5), 108–119 (1993) 6. Tapscott, D., Ticoll, D., Lowy, A.: Digital Capital: Harnessing the Power of Business Webs, Boston (2000) 7. Kopanaki, E., et al.: The Impact of Inter-organizational Information Systems on the Flexibility of Organizations. In: Proceedings of the Sixth Americas Conference on Information Systems (AMCIS), Long Beach, CA (2000)
Benefits of Enterprise Ontology for the Development of ICT-Based Value Networks
21
8. Lambert, D.M., Cooper, M.C.: Issues in Supply Chain Management. Industrial Marketing Management 29(1), 65–83 (2000) 9. Barbier, F., Atkinson, C.: Business Components. In: Barbier, F. (ed.) Business Component-Based Software Engineering, pp. 1–26. Kluwer Academic Publishers Group, Dordrecht (2003) 10. Jang, Y.-J., Kim, E.-Y., Lee, K.-W.: Object-Oriented Component Identification Method Using the Affinity Analysis Technique. In: Konstantas, D., Léonard, M., Pigneur, Y., Patel, S. (eds.) OOIS 2003. LNCS, vol. 2817, pp. 317–321. Springer, Heidelberg (2003) 11. Levi, K., Arsanjani, A.: A Goal-driven Approach to Enterprise Component Identification and Specification. Communications of the ACM 45(10) (2002) 12. Réquilé-Romanczuk, A., et al.: Towards a Knowledge-Based Framework for COTS Component Identification. In: International Conference on Software Engineering (ICSE 2005), St. Louis, Missouri, USA. ACM Press, New York (2005) 13. Vitharana, P., Zahedi, F., Jain, H.: Design, Retrieval, and Assembly in Component-based Software Development. Communications of the ACM 46(11) (2003) 14. Dietz, J.L.G., Barjis, J.A.: Petri net expressions of DEMO process models as a rigid foundation for requirements engineering. In: 2nd International Conference on Enterprise Information Systems, Escola Superior de Tecnologia do Instituto Politécnico, Setúbal (2000); ISBN: 972-98050-1-6 15. Dietz, J.L.G.: Deriving Use Cases from Business Process Models. In: Song, I.-Y., Liddle, S.W., Ling, T.-W., Scheuermann, P. (eds.) ER 2003. LNCS, vol. 2813, pp. 131–143. Springer, Heidelberg (2003) 16. van der Aalst, W.M.P., van Hee, K.M.: Workflow Management: Models, Methods and Tools. MIT Press, MA (2001) 17. Jensen, K.: Coloured Petri Nets. Basic Concepts, Analysis Methods and Practical Use. Monographs in Theoretical Computer Science, Basic Concepts, vol. 1. Springer, Heidelberg (1997) 18. Scheer, A.-W.: ARIS - Business Process Modeling, 2nd edn. Springer, Berlin (1999) 19. UML, OMG Unified Modelling Language, Version 2.0. n.d, http://www.omg.org/technology/documents/modeling_spec_catalo g.htm#UML 20. van Reijswoud, V.E., Mulder, J.B.F., Dietz, J.L.G.: Speech Act Based Business Process and Information Modeling with DEMO. Information Systems Journal (1999) 21. Dietz, J.L.G.: Enterprise Ontology - Theory and Methodology. Springer, Heidelberg (2006) 22. Dietz, J.L.G., Habing, N.: A meta Ontology for Organizations. In: Meersman, R., Tari, Z., Corsaro, A. (eds.) OTM-WS 2004. LNCS, vol. 3292, pp. 533–543. Springer, Heidelberg (2004) 23. Dietz, J.L.G.: The Deep Structure of Business Processes. Communications of the ACM 49(5) (2006) 24. Albani, A., Dietz, J.L.G., Zaha, J.M.: Identifying Business Components on the basis of an Enterprise Ontology. In: Interop-Esa 2005 - First International Conference on Interoperability of Enterprise Software and Applications, Geneva, Switzerland (2005) 25. Albani, A., Dietz, J.L.G.: The benefit of enterprise ontology in identifying business components. In: IFIP World Computing Conference. Santiago de Chile (2006) 26. Albani, A., et al.: Domain Based Identification and Modelling of Business Component Applications. In: Kalinichenko, L.A., Manthey, R., Thalheim, B., Wloka, U. (eds.) ADBIS 2003. LNCS, vol. 2798, pp. 30–45. Springer, Heidelberg (2003) 27. Albani, A., et al.: Dynamic Modelling of Strategic Supply Chains. In: Bauknecht, K., Tjoa, A.M., Quirchmayr, G. (eds.) EC-Web 2003. LNCS, vol. 2738, pp. 403–413. Springer, Heidelberg (2003) 28. Albani, A., Müssigmann, N., Zaha, J.M.: A Reference Model for Strategic Supply Network Development. In: Loos, P., Fettke, P. (eds.) Reference Modeling for Business Systems Analysis. Idea Group Inc. (2006)
22
A. Albani and J.L.G. Dietz
29. Albani, A., Winnewisser, C., Turowski, K.: Dynamic Modelling of Demand Driven Value Networks. In: Meersman, R., Tari, Z. (eds.) OTM 2004. LNCS, vol. 3290, pp. 408–421. Springer, Heidelberg (2004) 30. McIvor, R., Humphreys, P., McAleer, E.: The Evolution of the Purchasing Function. Journal of Strategic Change 6(3), 165–179 (1997) 31. Ammer, D.: Materials Management, 2nd edn. Homewood (1968) 32. Kaufmann, L.: Purchasing and Supply Management - A Conceptual Framework. In: Hahn, D., Kaufmann, L. (eds.) Handbuch Industrielles Beschaffungsmanagement, pp. 3–33. Wiesbaden (2002) 33. Carr, A.S., Pearson, J.N.: Strategically managed buyer - supplier relationships and performance outcomes. Journal of Operations Management 17, 497–519 (1999) 34. Albani, A., et al.: Component Framework for Strategic Supply Network Development. In: Benczúr, A.A., Demetrovics, J., Gottlob, G. (eds.) ADBIS 2004. LNCS, vol. 3255, pp. 67– 82. Springer, Heidelberg (2004) 35. Albani, A., Müssigmann, N.: Evaluation of Strategic Supply Networks. In: Meersman, R., Tari, Z., Herrero, P. (eds.) OTM-WS 2005. LNCS, vol. 3762, pp. 582–591. Springer, Heidelberg (2005) 36. Dietz, J.L.G.: The Atoms, Molecules and Fibers of Organizations. Data and Knowledge Engineering 47, 301–325 (2003)
37. Dietz, J.L.G.: Generic recurrent patterns in business processes. In: Mira, J., Álvarez, J.R. (eds.) IWANN 2003. LNCS, vol. 2687. Springer, Heidelberg (2003) 38. Dietz, J.L.G.: The notion of business process revisted. In: Meersman, R., Tari, Z. (eds.) OTM 2004. LNCS, vol. 3290, pp. 85–100. Springer, Heidelberg (2004) 39. Halpin, T.A.: Information Modeling and Relational Databases. Morgan Kaufmann, San Francisco (2001) 40. Fellner, K., Turowski, K.: Classification Framework for Business Components. In: Proceedings of the 33rd Annual Hawaii International Conference On System Sciences, Maui, Hawaii. IEEE, Los Alamitos (2000) 41. Ackermann, J., et al.: Standardized Specification of Business Components, Gesellschaft fÜr Informatik, Working Group 5.10.3, Technical Report, Augsburg (2002) 42. Jain, H., Chalimeda, N.: Business Component Identification - A Formal Approach. In: Proceedings of the Fifth International Enterprise Distributed Object Computing Conference (EDOC 2001). IEEE Computer Society, Los Alamitos (2001) 43. Kim, S.D., Chang, S.H.: A Systematic Method to Identify Software Components. In: 11th Asia-Pacific Software Engineering Conference (APSEC) (2004) 44. Wang, Z., Xu, X., Zhan, D.: A Survey of Business Component Identification Methods and Related Techniques. International Journal of Information Technology 2(4), 229–238 (2005) 45. Jungnickel, D.: The Greedy Algorithm. In: Jungnickel, D. (ed.) Graphs, Networks and Algorithms, pp. 123–146. Springer, Berlin (2005) 46. Kernighan, B.W., Lin, S.: An efficient heurisitc procedure for partitioning graphs. Bell Systems Technical Journal 49, 291–307 (1970) 47. Selk, B., Klöckner, K., Albani, A.: Enabling interoperability of networked enterprises through an integrative information system architecture for CRM and SCM. In: International Workshop on Enterprise and Networked Enterprises Interoperability (ENEI 2005), Nancy, France (2005) 48. Selk, B., et al.: Experience Report: Appropriateness of the BCI-Method for Identifying Business Components in large-scale Information Systems. In: Conference on ComponentOriented Enterprise Applications (COEA 2005) in conjunction with the Net.Objectdays, Erfurt, Germany (2005)
SOA Pragmatism Tony C. Shan IBM 10712 Hellebore Rd, Charlotte NC 28213, USA
[email protected]
Abstract. This paper presents a pragmatic approach composed of Methodology, Automation, Patterns, and Strategy (MAPS), to effectively manage the architecture design practices and solution development lifecycle of information systems in a service-oriented paradigm. The key challenges in SOA are discussed, such as architecture complexity, evolving technologies, immature governance, fragmented specification efforts, and disparate visual notations. This comprehensive framework aims to provide a mature integration of appropriate knowledge and capabilities to filter the inessential from the essential. In the Methodology dimension, a hybrid method, SOA philosophy, and a methodical approach are the key components. The Automation dimension covers tools, service lifecycle, and COTS mapping. The prominent elements of the Patterns dimension are data caching patterns, reference model, and open source reference implementation. Finally, the Strategy dimension addresses the strategy metamodel, technology architecture planning, and strategy roadmapping. In addition, a 9-point list of SOA wisdom is articulated, which gives best-practice guidelines to adopt and implement SOA pragmatically in large organizations from a practitioner’s perspeoctive. Keywords: Service-oriented, computing, framework, model, architecture, process, integration, environment, technology, development, management, roadmap, infrastructure, standards, practice, pattern, method, taxonomy, strategy.
1 Introduction Information Technology (IT) differs itself from other industries in that it is made of bits rather than atoms. Over the years, IT has achieved remarkable success, becoming pervasive in people’s daily life. However, the IT uniqueness also brings about the poor project execution and defect rate that is unimaginable in other vertical sectors like manufacturing. A recent Chaos Report [1] by the Standish Group revealed some astonishing findings – almost half of IT projects in 2006 were behind schedule, over budget, or do not meet all the requirements, whereas close to one fifth of projects completely failed, i.e. being canceled or not deployed to the field. There have been a number of high-profile project failures in the past few years, wasting hundreds of millions of dollars. For example, the Virtual Case File System [2] by FBI was canceled with an estimated loss of $170 million in 2005. The Department of Homeland Security had to close the Emerge2 program [3] worth $229 million due to project failure in September 2006. J. Filipe et al. (Eds.): ICSOFT/ENASE 2007, CCIS 22, pp. 23–28, 2008. © Springer-Verlag Berlin Heidelberg 2008
24
T.C. Shan
One of the root causes of these immature happenings is the architecture complexity that has grown exponentially in the evolution of several generations of the computing paradigm. A great many Enterprise Architecture (EA) programs in large firms are actually in a primitive shape, generally lack of best-practice disciplines. The IT architecture management and governance are inefficient in many cases, coupled with the organization, culture, and behavior challenges, which leads to inability to deal with the dynamic nature of today’s IT responsiveness.
2 SOA Challenges From a systems development lifecycle (SDLC) standpoint, it is not uncommon that the design efforts of software-intensive systems are disjointed, similar to the old tale of “The Blind Men and the Elephant.” As the architecture complexity continuously grows dramatically, the limitation of the fragmented IT development practices tend to become more visible and devastating. Naturally, SOA is anticipated to be a miracle cure to solve all these problems, which could lead to a more catastrophic failure in the enterprise computing environments, if the expectation is not set right and the impact of SOA is mis-interpreted. In the real-world scenarios, the SOA activities without appropriate mindsets, well-defined objectives, rationalized reasoning, fact-based justification criteria, leadership support, and effective operating models often result in even worse outcome than without SOA. A service-oriented solution can be viewed from different dimensions. In general, there are three key aspects as described below: • Business Aspect o Business architecture o Value chain model o Business solution priorities o Modeling and taxonomy, e.g. BMM, BPMN, CBM • Technology Aspect o Functionality expressed as services o Map to business processes o Based on industry standards (ACORD, iXRetail, eTOM, IFW, IFX, SCOR, HL7, NHI) • Operations Aspect o Quality of services o Middleware and integration o Platforms and frameworks o Network and storage o Virtualization and utility computing Facing the magnitude of the complexity in a service-oriented solution, some of the key SOA challenges are increasing dynamics, growing integration points, disparate visual notations, fragmented WS-* specification efforts, and barriers to deploy functional governance, which collectively further widen the gap of communications. For example, a typical large-size enterprise system today deals with the composition and integration of enterprise portal, enterprise services, user authentication, entitlement
SOA Pragmatism
25
services, customer applications, business process management, service registry/ repository, service management, enterprise service bus, business activity monitoring, legacy systems, EAI, reporting, application frameworks, enterprise information integration, business intelligence, storage, infrastructure, network, quality of services, non-functional requirements, tools, etc. Many practitioners agree that a critical factor to the success of SOA adoption is the effectiveness of handling the complexity of the large-scale architecture as the size and number of details become virtually uncontrollable or unmanageable via traditional methods. A widely-used approach to coping with complexity is divide-and-conquer, in an attempt to decompose the architecture to the level that is simple enough to address the design concerns and provide solutions in a straightforward way. The abstraction technique is also commonly applied to create the simplified models by hiding and filtering details that are irrelevant to the level of considerations. Complexity can be classified into logical – proof of proof of correctness becomes difficult, long, and impossible, psychological – comprehensibility to understand, and structural – number of elements. Various complexity metrics exist such as the graph-theoretic measure. Nevertheless, Fred Brooks pointed out that the essential complexity is irreducible [4]. As Grady Booch put it [5], the most fruitful path of investigation ties architectural complexity to entropy, i.e., the measure of the disorganization of a system and/or the size of the state space of the system. I can "feel" that one system or implementation is more or less complex than another, but I can't empirically defend that feeling in many cases. In reality, handling architectural complexity is essentially in an art format. We argue that wisdom should be leveraged for better analyzability in this regard.
3 Pragmatic Approach As defined in the Merriam-Webster dictionary, wisdom is accumulated philosophic or scientific learning-knowledge and ability to discern inner qualities and relationshipsinsight. According to Doc Childre and Bruce Cryer, wisdom implies a mature integration of appropriate knowledge, a seasoned ability to filter the inessential from the essential [6]. In plain English, SOA wisdom is a whole array of better-than-ordinary ways of dealing with SOA pragmatically, making the best use of available knowledge and often incomplete information – a trait developed by experience, but not taught. We need to take advantage of SOA wisdom to move from chaos to coherence. A pragmatic SOA approach is proposed, which consists of Methodology, Automation, Patterns, and Strategy (MAPS). The methodology dimension is with regard to the disciplined ways to execute SOA. The automation dimension deals with repeatable and objective processes. The patterns dimension documents the best practices and lesson learned, to avoid reinventing the wheel. Finally, the strategy dimension lays out the plans to run SOA in a controlled mode. Figure 1 illustrates the key characteristics of each dimension in the MAPS model. The Methodology dimension addresses the SOA methods that deal with process, people, technology, and information. Standard notations are advocated in modeling and model transformation in round-trip engineering as a discipline in the end-to-end sustainable lifecycle management. Agile methods are leveraged for incremental
26
T.C. Shan
iterations in project execution. Common terminology, taxonomy and ontology are defined to facilitate effective communications among the stakeholders of different background in a semantic fashion. Key indicators are specified to quantify the progress and growth in terms of the maturity of the SOA program. Service governance practices are enforced to properly manage the changes and issues related to culture, organization, and behavior, with roles and responsibilities clearly identified in a RACI matrix. In addition, streamlined methods in a lightweight format are applied to medium- and small-size projects, to promote pragmatism and practicality.
Fig. 1. MAPS Model
The Automation dimension makes use of both commercial and open source tools for various tasks in the SOA project development process, including design-time, runtime and change-time, such as service versioning, testing, build/deploy, service management, business activity monitoring, compliance validation, and service repository. Conformance to the service and platform interoperability is crucial for a heterogeneous environment, using industry standards such as WS-I Basic Profile and Basic Security Profile. Advanced computing techniques are taken advantage of to provide service location transparency in an autonomous on-demand fashion, using workload management, virtualization, grid computing, self-healing, fault-tolerance,
SOA Pragmatism
27
real-time optimization, and so on. Automatic tools help facilitate the change control more efficiently in the SDLC. The Patterns dimension captures and documents the reusable best practices for business services and processes. Patterns can be grouped into different domains: technical, engineering, solution, implementation, foundation, and infrastructure. Reference models are built as an abstract SOA pattern, on which SOA stacks are based. SOA frameworks are constructed accordingly, where runtime products are mapped to individual capabilities to form a combination of SOA logical model and physical model, called SOAstructure. Traditional patterns such as GoF design patterns, Java EE patterns, integration patterns, and analysis patterns are aggregated to be incorporated in the SOA pattern library. Moreover, antipatterns are recorded to keep track of pitfalls and lessons learned in the project executions. The Strategy dimension lays out a vision blueprint and alignment from a strategic viewpoint. A multi-generation plan is created to roadmap a variety of work tracks and streams to accomplish long-term and short-term SOA goals and realize technical capabilities. Different priorities, timelines, funding, constraints, overlapping, and drivers from various stakeholders and portfolios are thoroughly analyzed via techniques like SWOT to justify the tradeoffs and drive out a balanced approach with minimum risk of failures. A key to the success of the strategic SOA planning is the separation of concerns and duties. The deliberations and decisions must be wellcommunicated and vetted. Appropriate trainings need to be planned to retool the skillset of the project teams. The strategy contents must be refreshed periodically to reflect the changes of the conditions and the advance in the field.
4 Pragmatism Guidelines The following is a list of best practice guidelines to implement pragmatism in realworld SOA projects: 1. 2. 3. 4. 5. 6. 7. 8. 9.
Strategy: set a solid plan as a foundation and develop a SOA blueprint Ontology: define a taxonomy with both business and technology semantics as well as service metadata Agreement: enforce design by contract, and leverage repositories for automated interface and contract management Web 2.0/3.0: migrate to social and collaborative computing with rich user experience via Wiki, RIA, mashups, and semantic web Integration: focus on interoperability and portability in composite applications and systems integration Standardization: build architecture based on industry standards and open platforms Discovery: enable dynamic binding and better findability with registry and repository Optimization: achieve evolutionary improvement through incremental advances and maturation Management: leverage policy-driven governance in SOA lifecycle, including design-time, run-time, and change-time
28
T.C. Shan
As a reference, a case study of a pragmatic SOA implementation in the financial industry is presented in a separate publication [7].
5 Conclusions Given the fact that the complexity, size and number of details in IT architecture has been growing at an unprecedented pace, we propose that the SOA wisdom should be leveraged to effectively manage the architecting practices in a disciplined manner. The pragmatic approach defined in this paper consists of four dimensions – Methodology, Automation, Patterns, and Strategy (MAPS). The key challenges in SOA are discussed, such as increasing integration, dynamics, disparate visual notations, fragmented WS-* specification efforts, and barriers to deploy useful governance, which collectively further widen the gap of communications. The MAPS model is a comprehensive framework aiming to enable a mature integration of appropriate knowledge and capabilities to filter the inessential from the essential. In the Methodology dimension, a hybrid method, SOA philosophy, and a methodical engineering framework are the key components. The Automation dimension covers tools, service lifecycle, and COTS mapping. The prominent elements of the Patterns dimension are data caching patterns, reference model, and open source reference implementation. Last but not least, the Strategy dimension addresses the strategy metamodel, technology architecture planning, and strategy roadmapping. In addition, a 9-point list of SOA wisdom is articulated, which gives best-practice guidelines to adopt and implement SOA pragmatically in large organizations from a practitioner’s perspective.
References 1. The Standish Group (2006), http://www.standishgroup.com 2. Goldstein, H.: Who Killed the Virtual Case File? IEEE Spectrum (September 2005) 3. Federal Computer Week (2006), http://www.fcw.com/online/news/1022531.html 4. Brooks, F.P.: No Silver Bullet - essence and accident in software Engineering. In: Proceedings of the IFIP Tenth World Computing Conference, pp. 1069–1076 (1986) 5. Booch, G.: Blog (Handbook of Software Architecture) (2007), http://booch.com/architecture/blog.jsp?archive=2007-02.html 6. Childre, D., Cryer, B.: From Chaos to Coherence, HeartMath, Boulder Creek (2000) 7. Shan, T.C., Hua, W.: A Service-Oriented Solution Framework for Internet Banking. International Journal of Web Services Research 3(1), 29–48 (2006)
Software and Data Technologies
Part I Programming Languages
A Simple Language for Novel Visualizations of Information Wendy Lucas1 and Stuart M. Shieber2 1
2
Computer Information Systems Department, Bentley College, Waltham, MA, USA
[email protected] Division of Engineering and Applied Sciences, Harvard University, Cambridge, MA, USA
[email protected]
Abstract. While information visualization tools support the representation of abstract data, their ability to enhance one’s understanding of complex relationships can be hindered by a limited set of predefined charts. To enable novel visualization over multiple variables, we propose a declarative language for specifying informational graphics from first principles. The language maps properties of generic objects to graphical representations based on scaled interpretations of data values. An iterative approach to constraint solving that involves user advice enables the optimization of graphic layouts. The flexibility and expressiveness of a powerful but relatively easy to use grammar supports the expression of visualizations ranging from the simple to the complex.
1 Introduction Information visualization tools support creativity by enabling discoveries about data that would otherwise be difficult to perceive [8]. Oftentimes, however, the standard set of visualizations offered by commercial charting packages and business intelligence tools is not sufficient for exploring and representing complex relationships between multiple variables. Even specialized visual analysis tools may not offer displays that are relevant to the user’s particular needs. As noted in [9], the creation of effective visual representations is a labor-intensive process, and new methods are needed for simplifying this process and creating applications that are better targeted to the data and tasks. To that end, we introduce a language for specifying informational graphics from first principles. One can view the goal of the present research as doing for information visualization what spreadsheet software did for business applications. Prior to Bricklin’s VisiCalc, business applications were built separately from scratch. By identifying the first principles on which many of these applications were built — namely, arithmetic calculations over geographically defined values — the spreadsheet program made it possible for end users to generate their own novel business applications. This flexibility was obtained at the cost of requiring a more sophisticated user, but the additional layer of complexity can be hidden from naive users through prepackaged spreadsheets. Similarly, we propose to allow direct access to the first principles on which (a subset of) informational graphics are built through an appropriate specification language. The advantages are again flexibility and expressiveness, with the same cost in terms of user sophistication and mitigation of this cost through prepackaging. J. Filipe et al. (Eds.): ICSOFT/ENASE 2007, CCIS 22, pp. 33–45, 2008. c Springer-Verlag Berlin Heidelberg 2008
34
W. Lucas and S.M. Shieber
For expository reasons, the functionality we provide with this language is presented by way of example, from simple scatter plots to versions of two quite famous visualizations: Minard’s depiction of troop strength during Napoleon’s march on Moscow and a map of the early ARPAnet from the ancient history of the Internet.1 We hope that the reader can easily extrapolate from the provided examples to see the power of the language. We then describe how constraints are specified and how the constraint satisfaction process is coupled with user advice to reduce local minima. This is followed by descriptions of the primary constructs in the language and the output generation process for our implementation, which was used to generate the graphics shown in this paper.
2 The Structure of Informational Graphics In order to define a language for specifying informational graphics from first principles, those principles must be identified. For the subset of informational graphics that we consider here, the underlying principles are relatively simple: – Graphics are constructed based on the rendering of generic graphical objects taken from a small fixed set (points, lines, polygons, text, etc.). – The graphical properties of these generic graphical objects are instantiated by being tied to values taken from the underlying data (perhaps by way of computation). – The relationship between a data value and a graphical value is mediated by a function called a scale. – Scales can be depicted via generic graphical objects referred to as legends. (A special case is an axis, which is the legend for a location scale.) – The tying of values is done by simple constraints, typically of equality, but occasionally of other types. For example, consider a generic graphical object, the point, which has graphical properties like horizontal and vertical position, color, size, and shape. The standard scatter plot is a graphic where a single generic object, a point, is instantiated in the following way. Its horizontal and vertical position are directly tied by an equality constraint to values from particular data fields of the underlying table. The other graphical properties may be given fixed (default) values or tied to other data fields. In addition, it is typical to render the scales that govern the mapping from data values to graphical locations using axes. Suppose we have a table Table with fields f, g, and h as in Table 1. We can specify a scatter plot of the first two fields in just the way that was informally described above: {make p:point with p.center = Canvas(record.f, record.g) | record in SQL("select f, g from Table1")}; make a:axis with a.aorigin = (50,50), a.ll = (10,10), a.ur = (160,160), a.tick = (40,40);
1
See Figures 4 and 7 for our versions of these visualizations.
A Simple Language for Novel Visualizations of Information
35
150
150
Table 1.
170
130
120
120 130
f 80 60 90 120 140
g 80 120 140 60 135
h 0 10 3 5 7
90
90
90
90 60
60
50 10
30
50
50
90
130
0
30
50
90
130
10
10
0
10
30 0
60
90
0
120 150
(a)
(b)
30
60
90
120 150
(c)
Fig. 1. Data table and simple scatter plots defined from first principles
The make keyword instantiates a generic graphical object (point) and sets its attributes. The set comprehension construct ({·|·}) constructs a set with elements specified in its first part generated with values specified in its second part. Finally, we avail ourselves of a built-in scale, Canvas, which maps numeric values onto the final rendering canvas. One can think of this as the assignment of numbers to actual pixel values on the canvas. A depiction of the resulting graphic is given in Figure 1(a). (For reference, we show in light gray an extra axis depicting the canvas itself.) Other graphical properties of chart objects can be tied to other fields. In Figure 1(b), we use a colorscale, a primitive for building linearly interpolated color scales. A legend for the color scale is positioned on the canvas as well. Some scaling of the data can also be useful. We define a 2-D Cartesian frame to provide this scaling, using it instead of the canvas for placing the points. let frame:twodcart with frame.map(a,b) = Canvas(a, (3*b)/4+ 10) in let color:colorscale with color.min = ColorMap("red"), color.max = ColorMap("black"), color.minval = 0, color.maxval = 10 in {make p:point with p.center = frame.map(rec.f, rec.g), p.color = color.scale(rec.h) |rec in SQL("select f, g, h from Table1")}, make a:axis with a.scale = frame.map, a.aorigin = (50,50), a.ll = (0,0), a.ur = (140,170), a.tick = (50,50), make c:legend with c.scale = color, c.location = frame.map(150, 180);
A line chart can be generated using a line object instead of a point object. Suppose we take the records in Table 1 to be ordered, so that the lines should connect the points from the table in that order. Then a simple self-join provides the start points (x1 , y1 ) and end points (x2 , y2 ) for the lines. By specifying the appropriate query in SQL, we can build a line plot (see Figure 1(c)). let frame:twodcart with frame.map(a,b) = Canvas(a,(3*b)/4+ 10) in
36
W. Lucas and S.M. Shieber
{make l:line with l.start = frame.map(record.x1, record.y1), l.end = frame.map(record.x2, record.y2) | record in SQL("select tab1.f as x1, tab1.g as y1, tab2.f as x2, tab2.g as y2 from Table1 as tab1, Table1 as tab2 where tab2.recno = tab1.recno+1")}, make a:axis with a.scale = frame.map, a.aorigin = (50,50), a.ll = (10, 10), a.ur = (140,170), a.tick = (40,40);
The specification language also allows definitions of more abstract notions such as complex objects or groupings. We can use this facility to define a chart as an object that can be instantiated with specified data. This allows generated visualizations themselves, such as scatter plots, to be manipulated as graphical objects. For instance, it is possible to form a scatter plot of scatter plots. Figure 2 depicts a visualization of the data sets for Anscombe’s quartet [1], generated by the following specification: define s:splot with let frame:twodcart with frame.map = s.map in { make o:oval with o.center ˜ frame.map(rec.x, rec.y), o.width = 8, o.height = 8, o.fill = true | rec in s.recs }, make a:axis with a.scale = frame.map, a.aorigin = (0,0), a.ll = (0,0), a.ur = (20,15), a.tick = (10,5) in let outer:twodcart with outer.map(x,y) = Canvas(10*x, 10*y) in let FrameRecs = SQL("select distinct a, b from anscombe") in {make sp:splot with sp.map(x,y) = outer.map(x + 25*frec.a, y + 20*frec.b), sp.recs = SQL("select x, y from anscombe where a=frec.a and b=frec.b") | frec in FrameRecs};
3 Specifying Constraints All of the examples in the prior section made use of constraints of type equality only. The ability to add other types of constraints dramatically increases the flexibility of the language. For instance, stating that two values are approximately equal (˜), instead of strictly equal (=), allows for approximate satisfaction of equality constraints. Further, constraints of non-overlapping (NO) force values apart. Together, these constraints allow dither to be added to graphs. Suppose we have another table Table with fields id, f, and g, as in Table 2. We again specify a scatter plot of fields f and g but with two differences from our earlier examples: the center of each point is approximately equal to a data value from the table, and none of the point objects can overlap. The resulting graphic is shown in Figure 3(a).
A Simple Language for Novel Visualizations of Information
a=0 x 10 8 13 9 11 14 6 4 12 7 5
b=1 a=1 b=1 a=0 y x y x 8.04 10 9.14 10 6.95 8 8.14 8 7.58 13 8.74 13 8.81 9 8.77 9 8.33 11 9.26 11 9.96 14 8.1 14 7.24 6 6.13 6 4.26 4 3.1 4 10.84 12 9.13 12 4.82 7 7.26 7 5.68 5 4.74 5
b=0 a=1 y x 7.46 8 6.77 8 12.74 8 7.11 8 7.81 8 8.84 8 6.08 8 5.39 19 8.15 8 6.42 8 5.73 8
37
b=0 y 6.58 5.76 7.71 8.84 8.47 7.04 5.25 12.5 5.56 7.91 6.89
Fig. 2. Graphic depicting Anscombe’s quartet 170
170
Table 2. 130
id f 1 80 2 60 3 90 4 90 5 120 6 140
g 80 120 140 140 60 135
130
90
4
6
130
2
90
50 10
170
5 3
90
10
130
10
1
50 50
90
10
(a)
6
2
90
1
50 50
5 34
130
10
50
90
130
10
(b)
(c)
Fig. 3. Data table and scatter plots with positional constraints
NO({make p:point with p.center ˜ Canvas(record.f, record.g) | record in SQL("select f, g from Table1")}); make a:axis with a.aorigin = (50,50), a.ll = (10,10), a.ur = (160,170), a.tick = (40,40), a.color = RGB(0, 0, 0);
We would like to add labels at each data point and specify three conditions: (1) no point can overlap with another point, (2) no label can overlap with another label, and (3) no point can overlap with a label. We need the ability to associate a variable name with an object or a set of objects for later reference. This is accomplished with the let statement, which provides access to that variable within the body of the statement. The following code contains the required specifications, with its output shown in Figure 3(b).
38
W. Lucas and S.M. Shieber
let points = NO({make p:point with p.center ˜ Canvas(rec.f, rec.g) | rec in SQL("select f, g from Table2")}) in let labels = NO({make l:label with l.center ˜ Canvas(rec.f, rec.g), l.label = rec.id | rec in SQL("select f, g, id from Table2")}) in NO(points, labels); make a:axis with a.aorigin = (50,50), a.ll = (10,10), a.ur = (160,170), a.tick = (40,40), a.color = RGB(0, 0, 0);
The non-overlap constraints between point objects, between label objects, and between point and label objects have moved the label on point 3 farther away from the actual data point than may be desirable. This is a result of the force of a non-overlap constraint being stronger than that of an approximate equality constraint. The user can make adjustments to the layout by dragging any object whose location has been specified as approximately equal to a value, but these adjustment are subject to any constraints placed upon that object. Thus, the user may drag the label 3 to a different location, but the ‘˜’ constraint will keep it near (90, 140), while the ‘NO’ constraint will prohibit it from overlapping with any other point or label. The results of user manipulation to move label 3 to a more desirable location are shown in Figure 3(c).
4 A Detailed Example: The Minard Graphic As evidence of the flexibility of this language, we describe its use for specifying Minard’s well known depiction of troop strength during Napoleon’s march on Moscow. This graphic uses approximate geography to show the route of troop movements, with line segments for the legs of the journey. Width of the lines is used for troop strength and Advance Retreat
Polotzk Gloubokoe
Kowno
Wilna Smorgoni Molodexno Studienska Minsk
Chjat Wixma Dorogobouge
Witebsk Bobr
Moscou Mojaisk Tarantino
Smolensk
Malo-jarosewli
Orscha Mohilow
Oct 24 Nov 28
-10 -20 Dec 7
Dec 6
Oct 18
Nov 9
0 Temperature Nov 14
Dec 1
-30 25
30
35 Longitude
Fig. 4. The graphic generated by a specification extended from that of Figure 5, depicting the troop strength during Napoleon’s march on Moscow
A Simple Language for Novel Visualizations of Information
1 5
10
15
20
25
30
35
40
39
let scalefactor = 45 in let weight = .000002 in % Define the depiction of one (multi-leg) branch of the march % identified by a distinct direction and division define m:march with let frame:twodcart with frame.map = m.map in {make l:line with l.start = frame.map(rec.cx1, rec.cy1), l.end = frame.map(rec.cx2, rec.cy2), l.startWidth = scalefactor * weight * rec.r1, l.endWidth = scalefactor * weight * rec.r2, l.color = ColorMap(rec.color) | rec in m.recs} in % Extract the set of branches that make up the full march let FrameRecs = SQL("select distinct direct, division from marchNap") in % For each branch, depict it {make mp:march with mp.map(x,y) = Canvas(scalefactor*x - 1075, scalefactor*y - 2200), mp.recs = SQL("select marchNap1.lonp as cx1, marchNap1.latp as cy1, marchNap2.lonp as cx2, marchNap2.latp as cy2, marchNap1.surviv as r1, marchNap2.surviv as r2, marchNap1.color as color from marchNap as marchNap1, marchNap as marchNap2 where marchNap1.direct = framerec.direct and marchNap2.direct = marchNap1.direct and marchNap1.division = framerec.division and marchNap1.division = marchNap2.division and marchNap2.recno = marchNap1.recno+1") | framerec in FrameRecs}; % Label the cities along the march and do not allow overlap NO({make e d2:label with d2.center ˜ frameTemp.map(recc.lonc, recc.latc), d2.label = recc.city, d2.color = ColorMap("blue") | recc in SQL("select lonc, latc, city from marchCity")});
Fig. 5. Partial specification of the Minard graphic depicted in Figure 4. This specification does not include the temperature plot.
color depicts direction. The locations of the labels on cities are of approximate equality, as they are not allowed to overlap, and in some cases have been adjusted by the user for better clarity. A parallel graphic shows temperature during the inbound portion of the route, again as a line chart. Our version of the graph is provided in Figure 4. To generate this graphic, we require appropriate data tables: marchNap includes latitude and longitude at each way point, along with location name, direction, and troop strength; marchTemp includes latitude, longitude, and temperature for a subset of the inbound journey points, and marchCity provides latitude, longitude, and name for the traversed cities. The main portion of the graphic is essentially a set of line plots, one for each branch of the march, where a branch is defined as a route taken in a single direction by a single division. Additional graphical properties (width and color) are tied to appropriate data fields. Textual labels for the cities are added using a text graphic object. A longitudinally aligned graph presents temperature on the main return branch.
40
W. Lucas and S.M. Shieber
The specification for this graphic (sans the temperature portion) is provided in Figure 5. After specifying some constants (lines 1–2), we define the depiction of a single branch of the march (6–16): a mapping (m.map) specifies a Cartesian frame (7– 8) in which a line plot composed of a set of line segments (10–16) is placed, with one segment for each set of records (16). These records provide start and end points, along with widths at start and end (to be interpolated between), and color (11–15). Thus, to depict a march leg, all that must be provided is the mapping and the set of records. These are constructed in lines 19–35. For each distinct direction and division (19–20), a separate march leg depiction is constructed (23–35). The mapping is a scaling of the Canvas frame (24), with records for the appropriate division and direction extracted from the marchNap database (25–35). Finally, the cities are labeled using the information in the marchCity database by setting the coordinates of the text labels to be approximately equal to latitude and longitude, setting a fixed color, and specifying that labels cannot overlap (38–42).
5 The Language The examples from this paper were all generated from an implementation of our language. The implementation techniques are outlined in Section 6. The underlying ideas could, however, be implemented in other ways, for instance as a library of functions in a suitable functional language such as Haskell or ML. The language is built around the specification of objects. The main construct is objspec, with a program defined as one or more objspecs. Objspecs are used for instantiating a graphical object of a predefined type, specifying relationships between the set of actual data values and their graphical representations, and defining new graphic types. The make statement is used for instantiating a new instance of an existing object type (either built-in, such as point or line, or user-defined, such as march) with one or more conditions. There are two types of predefined objects: generic and scale. Generic objects provide visual representations of data values and include the primitive types of point, line, oval, rectangle, polygon, polar segment, and labels. Scales are used for mapping data values to their visual representations and are graphically represented by axes and legends. A scale is associated with a coordinate system object and defines a transformation from the default layout canvas to a frame of type twodcart or twodpolar (at this time). In addition to a unique identifier, each object type has predefined attributes, with conditions expressed as constraints on these attributes. Constraints can be of type equality (‘=’) or approximate equality (‘˜’). Constraints enforcing visual organization features [3] such as non-overlap, alignment, or symmetry, can be applied to a set of graphical objects. These types of constraints are particularly useful in specifying network diagrams [7]. While such constraints can be specified in the language, our current implementation supports constraints in the forms of equality, approximate equality, and non-overlap for a subset of object types. All of the generic objects have a color attribute and at least one location attribute, represented by a coordinate. For 2-D objects, a Boolean fill attribute defaults to true, indicating that the interior of that object be filled in with the specified color.
A Simple Language for Novel Visualizations of Information
41
This attribute also applies to line objects, which have start and end widths. When widths are specified, lines are rendered as four-sided polygons with rounded ends. Each type of scale object has its own set of attributes. A coordinate system object’s parent attribute can reference another coordinate system object or the canvas itself. The mapping from data values to graphical values can be specified by conditions on its origin and unit attributes. Alternatively, a condition can be applied to its map attribute in the form of a user-defined mapping function that denotes both the parent object and the scale. Thus, a twodcart object whose parent is Canvas, origin is (5, 10), and unit is (30, 40) can be defined by the mapping function: Canvas.map (30x + 5, 40y + 10). Axes are defined in terms of their origin, ll (lower left) and ur (upper right) coordinates, and tick marks. Legends can be used to graphically associate a color gradient with a range of data values by assigning a color scale object to the scale attribute and a coordinate to the location attribute. Discrete colors can also be associated with data values, as in the Minard Graph example, where tan represents “Advance” and black represents “Retreat.” Attributes can also be defined by the user within a make statement. For example, it is often helpful to declare temporary variables for storing data retrieved from a database. These user-defined attributes are ignored when the specified visualization is rendered. Another construct for an objspec is the type statement. This is used for defining a new object type that satisfies a set of conditions. These conditions are either constraints on attribute properties or other objspecs. An example of the former would be a condition requiring that the color attribute for a new chart type be “blue.” An example of the latter is to require that a chart include a 2-D Cartesian coordinate frame for use in rendering its display and that this frame contain a set of lines and points corresponding to data retrieved from a database. A third type of objspec is a set of objects, a setspec. This takes the form of either a query string or a set of objspecs to be instantiated for each record retrieved by a query string. These two constructs are often used in conjunction with one another to associate data with generic graph objects. For example, a setspec may define a query that retrieves two values, x and y, from a database table. A second setspec can then specify a make command for rendering a set of points located at the x and y values retrieved by the query. Alternatively, the query can be contained within the make statement itself, as shown in the code for the scatter plots in Section 2. Lastly, the let statement associates a variable name with an objspec so that it can be referenced later within the body of the statement. Because this construct is commonly used in conjunction with a make or type statement, two shorthand expressions have been provided. The first of these is an abbreviated form of the let statement in which the make clause is not explicitly stated, with: let var :type with conditions in body corresponding to let var =make var : type with conditions in body . Similarly, the define statement associates a new object definition with a variable name, where: define var : type with conditions in body expands to let var = type var : type with conditions in body . Figure 6 demonstrates the usage of the above objspec constructs for defining a new type of object called a netplot. The code specifies the creation of a set of ovals,
42
W. Lucas and S.M. Shieber
referred to as nodes, with width and height of 10, color of “black,” and center locations corresponding to x and y values queried from a database and mapped to a frame. (Data values were estimated from a depiction of the ARPAnet circa 1971 available at http://www.cybergeography.org/atlas/historical.html.) A set of blue lines are specified, with the endpoint locations of the lines equal to the centers of the circles. Labels are also specified and are subject to constraints, with the center of each label approximately equal to the center of a corresponding node and no overlap allowed between labels or between labels and nodes. define n:netplot with let frame:twodcart with frame.map = n.map in let nodes = {make o:oval with o.center = frame.map(rec.x, rec.y), o.width = n.radius * 2, o.height = n.radius * 2, o.color = n.ccolor, o.fill = true | rec in n.netRecs} in let lines = {make l:line with l.start = nodes[rec.v1].center, l.end = nodes[rec.v2].center, l.color = n.lcolor | rec in n.edgeRecs } in let labels = NO({ make d:label with d.center ˜ frame.map(rec.x, rec.y), d.label = rec.node, d.color = n.ccolor | rec in n.netRecs }) in NO(labels, nodes) in make net:netplot with net.map(x,y) = Canvas(7*x, 7*y), net.netRecs = SQL("select node, x, y from ArpaNodes"), net.radius = 5, net.edgeRecs = SQL("select v1, v2 from ArpaLinks"), net.lcolor = ColorMap("blue"), net.ccolor = ColorMap("black");
Fig. 6. Specification of the ARPAnet graphic depicted in Figure 7
Lincoln Case
Utah
Illinois
MIT
Carnegie
BBN
SRI Harvard
Ames Stanford UCSB
Burroughs MITRE
UCLA SDC RAND
Fig. 7. A network diagram depicting the ARPAnet circa 1971
A Simple Language for Novel Visualizations of Information
43
The output generated from this specification is shown in Figure 7, with the user having made similar adjustments as the one shown in Figure 3(c) to the placement of some labels. This chart and the Minard graphic from the prior section demonstrate the flexibility and control for specifying visualizations that result from working with the right set of first principles. Further, the intricacies of the code required to generate these charts are hidden behind a relatively simple to use but powerful grammar.
6 Implementation The output generation process that renders visualizations from code written in our language, such as those shown in the prior sections, involves four stages. 1. The code is parsed into an abstract syntax tree representation. 2. The tree is traversed to set variable bindings and to evaluate objspecs to the objects and sets of objects that they specify. These objects are collected, and the constraints that are imposed on them are accumulated as well. 3. The constraints are solved as in related work on the G LIDE system [7] by reduction to mass-spring systems and iterative relaxation. Equality constraints between objects are strictly enforced, in that neither the user nor the system can change the position of those objects. Non-overlap constraints between objects are enforced by the placement of a spring between the centers of the objects (at the current time, the system does not solve for non-overlap constraints involving lines). The spring’s rest length is the required minimum distance between those objects. Approximate equality, or near constraints, are enforced by the placement of springs with rest lengths of zero between specified points on two objects. The latter set of springs have a smaller spring constant than those used for non-overlap, thereby exerting less force. Solving one constraint may invalidate another, so an iterative process is followed until the total kinetic energy on all nodes falls below an arbitrarily set value. 4. The objects are rendered. Any primitive graphic object contained in the collection is drawn to the canvas using the graphical values determined as a result of the constraint satisfaction process. The user can make positional adjustments to any objects not subject to equality constraints. At the same time, the system continues to reevaluate its solution and update the position of the objects based on the solving of the constraints.
7 Related Work Standard charting software packages, such as Microsoft Chart or DeltaGraph, enable the generation of predefined graphic layouts selected from a “gallery” of options. As argued above, by providing pre-specified graph types, they provide simplicity at the cost of the expressivity that motivates our work. More flexibility can be achieved by embedding such gallery-based systems inside of programming languages to enable programspecified data manipulations and complex graphical composites. Many systems have this capability: Mathematica, Matlab, Igor, and so forth. Another method for expanding
44
W. Lucas and S.M. Shieber
expressiveness is to embed the graph generation inside of a full object-drawing package. Then, arbitrary additions and modifications can be made to the generated graphics by manual direct manipulation. Neither of these methods extends expressivity by deconstructing the graphics into their abstract information-bearing parts, that is, by allowing specification from first principles. Towards this latter goal, discovery of the first principles of informational graphics was pioneered by Bertin, whose work on the semiology of graphics [2] provides a deep analysis of the principles. It is not, however, formalized in such a way that computer implementation is possible. Computer systems for automated generation of graphics necessarily require those graphics to be built from a set of components whose function can be formally reasoned about. The seminal work in this area was by Mackinlay [4], whose system could generate a variety of standard informational graphics. The range of generable graphics was extended by Roth and Mattis [6] in the SAGE system. These systems were designed for automated generation of appropriate informational graphics from raw data, rather than for user-specified visualization of the data. The emphasis is thus on the functional appropriateness of the generated graphic rather than the expressiveness of the range of generable graphics. The SAGE system serves as the basis for a user-manipulable set of tools for generating informational graphics, SageTools [5]. This system shares with the present one the tying of graphical properties of objects to data values. Unlike SageTools, the present system relies solely on this idea, which is made possible by the embedding of this primitive principle in a specification language and the broadening of the set of object types to which the principle can be applied. The effort most similar to the one described here is Wilkinson’s work on a specification language for informational graphics from first principles, a “grammar” of graphics [10]. Wilkinson’s system differs from the one proposed here in three ways. First, the level of the language primitives are considerably higher; notions such as Voronoi tesselation or vane glyphs serve as primitives in the system. Second, the goal of his language is to explicate the semantics of graphics, not to serve as a command language for generating the graphics. Thus, many of the details of rendering can be glossed over in the system. Lastly, and most importantly, the ability to embed constraints beyond those of equality provides us the capacity to generate a range of informational graphics that use positional information in a much looser and more nuanced way.
8 Conclusions We have presented a specification language for describing informational graphics from first principles, founded on the simple idea of instantiating the graphical properties of generic graphical objects from constraints over the scaled interpretation of data values. This idea serves as a foundation for a wide variety of graphics, well beyond the typical sorts found in systems based on fixed galleries of charts or graphs. By making graphical first principles available to users, our approach provides flexibility and expressiveness for specifying innovative visualizations.
A Simple Language for Novel Visualizations of Information
45
References 1. Anscombe, F.J.: Graphs in statistical analysis. American Statistician 27, 17–21 (1973) 2. Bertin, J.: Semiology of Graphics. University of Wisconsin Press (1983) 3. Kosak, C., Marks, J., Shieber, S.: Automating the layout of network diagrams with specified visual organization. Transactions on Systems, Man and Cybernetics 24(3), 440–454 (1994) 4. Mackinlay, J.: Automating the design of graphical presentations of relational information. ACM Transactions on Graphics 5(2), 110–141 (1986) 5. Roth, S.F., Kolojejchick, J., Mattis, J., Chuah, M.C.: Sagetools: An intelligent environment for sketching, browsing, and customizing data-graphics. In: CHI 1995: Conference companion on Human factors in computing systems, pp. 409–410. ACM Press, New York (1995) 6. Roth, S.F., Mattis, J.: Data characterization for graphic presentation. In: Proceedings of the Computer-Human Interaction Conference (CHI 1990) (1990) 7. Ryall, K., Marks, J., Shieber, S.M.: An interactive constraint-based system for drawing graphs. In: Proceedings of the 10th Annual Symposium on User Interface Software and Technology (UIST) (1997) 8. Shneiderman, B.: Creativity support tools: accelerating discovery and innovation. Communications of the ACM 50(12), 20–32 (2007) 9. Thomas, J.J., Cook, K.A.: A visual analytics agenda. IEEE Computer Graphics and Applications 26(1), 10–13 (2006) 10. Wilkinson, L.: The Grammar of Graphics. Springer, Heidelberg (1999)
Generic Components for Static Operations at Object Level Andreas P. Priesnitz and Sibylle Schupp Chalmers University of Technology, 41296 Gothenburg, Sweden {priesnit,schupp}@cs.chalmers.se http://www.cs.chalmers.se/˜{priesnit,schupp}
Abstract. Reflection allows defining generic operations in terms of object constituents. A performance penalty accrues if reflection is effectuated at run time, which is usually the case. If performance matters, some compile-time means of reflection is desired to obviate that penalty. Furthermore, static meta-information may be utilized for class creation, e.g., in optimizations. We provide such means in generic components, employing static meta-programming. Essentially, object structure is encoded in a generic container that models a statically indexed family. Optimizations benefit any object defined in terms of that container. Keywords: Reflection, Serialization, Class Generation, Container.
1 Introduction Reflection provides access to internal representation details of the class of some given object. We consider reflection on the fields of objects, which is essential for generic implementations of low-level tasks. For instance, we are interested in tasks like serializations and optimizing transformations. Many applications of that kind are performancecritical, whereas reflection usually implies some overhead when it is performed at run time. Our goal is to be able to implement those tasks both generically and efficiently. To avoid performance penalties, we want to apply reflection statically. Common languages do not provide corresponding means. But as some languages offer static metaprogramming facilities, we can specify generic components that achieve the desired effect, thus serve as a portable language extension. Our design relies on sharing the provision of fields for class implementations in generic components. The core component is supposed to manage a collection of objects of different types, thus it forms a heterogeneous container. We want to access those objects in terms of some label, thus the container must model the concept of an indexed family. By separating the aspects of internal class representation, the container becomes a stand-alone generic component, and the remaining task-specific components in our design turn out rather lightweight. Existing implementations of indexed families do not provide all features necessary to use them as internal representations of class fields. Thus, we present an enhanced solution that generalizes the applicability of the container. The outline of this article is as follows: In Sect. 2, we discuss and specify the applications of reflection that we are particularly interested in. In Sect. 3, we lay out the J. Filipe et al. (Eds.): ICSOFT/ENASE 2007, CCIS 22, pp. 46–59, 2008. c Springer-Verlag Berlin Heidelberg 2008
Generic Components for Static Operations at Object Level
47
principal components that constitute our solution. Their heart is the statically indexed family container, whose implementation is in the center of the further discussion. In Sect. 4, we present in general terms the conventional implementation of such containers. In Sect. 5, we motivate and describe in more detail necessary extensions to that approach. In Sect. 6, we put the parts together, we show how to ease this step, and we discuss some consequences of our design. In Sect. 7, we compare our approach with previous work in related domains, and in Sect. 8, we give an evaluation of our results and some concluding remarks. We chose C++ as language of our implementation and of our examples and discuss this choice in Sect. 5.
2 Why Static Reflection? The term reflection encompasses all kinds of access to software meta-information from within the software itself. We restrict our considerations to accessing the instance fields of a given object. Furthermore, we exclude alteration, i.e., the modification of that set of fields. In this section, we exemplify two classes of applications that justify to perform reflection statically. 2.1 Example: Serialization Algorithms whose effect on an object reduces to inspecting its instance fields limit the role of the object to that of a mere record. In other words, these algorithms do not involve knowledge of the particular semantics of the inspected object. A popular example of such applications is serialization, i.e., a mapping of objects to some linear representation. Common cases of such representations are binary encoding, XML objects, or formatted output. In Fig. 1, we depict an object that contains T1 T2
T2
T2
T3
Fig. 1. Exemplary internal representation
– a reference to a collection of objects of type T2 , – information on the number of objects in the collection as an object of type T1 , and – some associated information as an object of type T3 . Consider, for instance, the collection to be a sub-range of a text of characters, not owned by the object, and the associated information to be the most frequent character in that text snippet.
48
A.P. Priesnitz and S. Schupp
We might think of a serialization of that object as resulting in a representation as in Fig. 2. Each field is transformed to its corresponding representation, as symbolized by dashed lines, and these individual representations are concatenated. The meaning of concatenation depends on the representation. But a second thought reveals that this
T1
T2
T2
T2
T3
Fig. 2. Schematic serial representation
example is rather a counter-example: In order to serialize the text snippet, we need to know its length, thus we have to inspect the first field to deal with the second, and we rely on a semantic linkage between both. Thus, a “true” serialization could either create a representation of the reference as such, or treat it as being transparent and represent the (first) referenced object. To produce the outcome in Fig. 2, though, we have to specialize the serialization for this type of object. Some languages provide implementations of certain serialization methods. To define other methods, we need to be able to traverse the fields of objects. Considering common application cases and our previous observation on the example, we restrict these traversals to be Linear. Each field is mapped at most once. The output of the mapping is valid input to a stream. Reversible. Each field is mapped at least once. It is possible to create representations that can be deserialized to an object that is equal to the original. Order-independent. The operation does not depend on a particular order of field access. The contrary would require to consider composition information, which we want to exclude. Deterministic. The access order is not random, though. Otherwise, we were forced to add annotations to element representations to facilitate deserialization. If we lack means of reflection, we have to define field traversal for each class of interest—in practice, to the majority or entirety of classes. Like other polymorphic functionalities, reflection usually is a dynamic feature. It causes constant per-object space overhead due to a hidden reference, and a per-reflection time overhead due to an indirect function call. The latter costs are dominated by the impossibility of inlining such calls, and of then applying further optimizations. These costs are insignificant if objects are large and if reflection occurs seldom. Otherwise, the costs of algorithms that make heavy use of reflection may turn out prohibitive, forcing developers again to provide per-class specializations. This dilemma is avoided if reflection is performed at compile time, abolishing runtime costs in time and space. Run-time reflection is provided by many object-oriented programming languages, e.g., SmallTalk, CLOS, or Java, whereas compile-time reflection is supported only for particular tasks like aspect-oriented programming, if at all.
Generic Components for Static Operations at Object Level
49
2.2 Example: Memory Layout Another kind of operations on the fields of a class are optimizing transformations. Usually, only the compiler is responsible for performing optimizations of the internal representation of objects, in terms of space, place, alignment, or accessibility of their allocation. Given adequate means of static reflection and of static meta-programming, one can perform similar transformations within the code. In contrast to the compiler, the developer usually has some high-level knowledge about objects beyond the information expressible in terms of the language. Optimizations that depend on such knowledge complement and support optimizing facilities of the compiler. As an example, consider the rule-of-thumb of ordering the fields of a class in memory by decreasing size, given that our language allows us to influence that order. The effect of this rule is depicted in Fig. 3 for a 2-byte representation of the number of characters. Fields of less than word size may share a word instead of being aligned at word addresses. If we order the fields in such a way that small fields are adjacent, the compiler is more likely to perform that optimization, reducing the object size in the example from 3 to 2 words. Note that we do not attempt to be smarter than the compiler:
T1
T3
T1 T3 Fig. 3. Differences in memory layout
We can not and do not force it to perform that reduction. The compiler may still decide that it is beneficial to stick to word alignment, e.g., in favor of speed of field access, or even to reorder the fields, if allowed. But vice versa, the compiler might not be allowed to perform that optimization itself unless the proposed order of fields offers or suggests to do so.1 Thus, our strategy is to supply the compiler with as much useful information as possible. Given static reflection, we can inspect the fields of a class and create a new class that contains the fields ordered by size. This effect could not be achieved by a hand-coded alternative, as the size of fields may differ on different hardware. A fixed order that suits some hardware can turn out inappropriate on another.
3 Component-Based Static Reflection We have learned that it is desirable to have static reflection on class fields at our disposal. Thus, we would like to provide this feature ourselves if the language we use does not offer it. In this section, we develop the general outline of our approach to achieve this goal. The individual steps will be discussed in more detail in Sects. 4–6. 1
E.g., the C++ standard introduces several restrictions on actual field order.
50
A.P. Priesnitz and S. Schupp
3.1 Sharing Internal Representation In order to share means and applications of static reflection by all class implementations, we provide them within common generic components. As these components shall be in charge of all matters of (here, static) object composition, they have to be shared by inheritance. An application class is privately derived from a component that defines the internal class representation. Thus, unauthorized access by slicing an object to this component type is inhibited. For simplicity, we call the component Private. Correspondingly, reflection-based functionalities that are supposed to be available in the signature of the application class are provided in a component Public from that the application class is derived publicly. 3.2 Field Access Access to fields of an object corresponds to an injective mapping from identifying labels to the fields. To allow for evaluating that mapping at compile-time, reflection support has to be provided by a component that models a statically indexed family of fields of different types. Because we required order-independence in Sect. 2, that container does not model a tuple. Due to the expected deterministic access order, though, we require that the container is an ordered indexed family, where we adopt the order of labels from the definition of the container. This convention allows to express (e.g., optimizing) transformations in the family component. In common statically typed languages, labels are lexical entities, on which we cannot operate by type meta-programming. Thus, we express labels by empty classes that do not serve any other purpose than static identification. 3.3 Field Specification In order to delegate field definition, creation, deletion, access, and further fundamental methods to the family component, we have to statically parametrize it by a collection of field specifications that supply the necessary information. Besides the obviously needed labels and types, one has to specify: – how to initialize fields, depending on the kind of constructor called for the component, and – how to delete field contents in the destructor or when overwriting fields by assignment. The family has to be self-contained, i.e., able to effect those functionalities for any kind of field types without further support. At the same time, it may not be restrictive; the class developer has to be able to make a choice wherever alternatives of execution exist. 3.4 Separation of Concerns Not all aspects of reflection on fields can be covered by a general implementation of an indexed family. In order to allow for stand-alone usage of the container, classes are not derived from the family directly. Instead, the component Private is a wrapper, which complements the family by non-public features that apply to all application classes
Generic Components for Static Operations at Object Level
51
but not to a family. In other words, the role of Private is to promote the container to a data record, the role of Public is to garnish the record with generic, publicly accessible features. Figure 4 depicts the inheritance relationship between the essential components in our design.
Family fields family methods transformations Private
Public
record methods
class methods AnyClass
Fig. 4. Principal component hierarchy
4 Implementing Heterogeneous Families Statically polymorphic containers store objects of different types. They are common in generic models and provided by several, mostly functional languages. We describe an established approach to defining such containers by user-defined constructs. Our language has to allow expressing generative constructs, as different container types must be created for different sets of element types. Java, for example, is not suitable: It performs type erasure on instances of generic types, instead of creating new types. More generally, our language has to allow conditional type generation, i.e., static metaprogramming (SMP). Candidates are MetaML, MetaOCaml, Template Haskell, or C++. Compile-Time Lists: Given SMP, we can define lists of types by a binarily parametrized type Cons and a type Nil in the same style as lists are defined in LISP [1]. Similarly, a list algorithm is implemented as a type that is parametrized by a type list and that provides the result as an associated type. Mixins: In order to influence class composition, our language has to allow parametrized inheritance, i.e., deriving from a base class that is given as a type parameter. The subclass is then called a mixin [2] and generically extends the base class. We are interested in mixins that add a single field and corresponding functionalities to the base class. A particular problem is to provide practicable mixin constructors that call the base class constructors properly [3].
52
A.P. Priesnitz and S. Schupp
Tuples: Combining the previous idioms, tuples of objects of different types can be defined recursively [4,5]: Cons becomes a mixin that is derived from the list tail and that provides a field of the head type. Nil is an empty class. Elements are accessed by a static natural index. If the number is nonzero, the mixin forwards the access request with the index’ predecessor statically to the base. If it is zero, the field in the mixin is returned. This static recursion causes no run-time overhead. The tuple class implementation is straightforward. But its constructors are tricky to define, as they need to handle arbitrary numbers of initializing arguments.2 Furthermore, the creation of temporaries has to be avoided when passing arguments on from a mixin constructor to a base constructor. Families: An arbitrarily, yet statically indexed family is implemented analogously to a tuple [6,7]: The mixin class is parametrized by a list—assumed to represent a set—of type pairs Field
. The second type indicates a field type, whereas the first type is an identifying label to be matched, instead of an index, when accessing the field. The list of field specifiers does not necessarily determine the order in which the mixins are composed. Thus, we may reorder that list before creating the family, e.g., in decreasing order of field type size. Constructor implementations differ from those for a tuple, but are similarly intricate. We are not tied anymore to a certain order of arguments nor forced to provide all of them. Instead, constructors take as initializers a set of label-value pairs that need to be searched for a matching label.,...,..., Cons, Cons, Nil> > > >, public Public<Snippet> { friend class Public<Snippet>; typedef Private Private_; public: Snippet(char const* text, unsigned from, unsigned to) : Private_(init(Length(),to-from), init(Text(),text+from), init(Most_Frequent(), most_frequent(text+from,to-from))) {} // ... void shift(int offset) { get(Text()) += offset; get(Most_Frequent()) = most_frequent(get(Text()),get(Length())); } };[email protected] [email protected] 2 INRIA Futurs, Lille, France [email protected] [email protected] , [email protected] 2 School of Computing, Dublin City University, Ireland [email protected] > associations which go out from them, and AddBookToCart ES calls to SearchBook. On other hand, we have that SearchBook ES could be replaced with SearchForAuthor, SearchForSubject or SearchForTitle due to the <<extends>> associations.> relations to other ESs depending on the associated system sequence. If the user executes an ES where <<extend>> associations are coming in, as SearchBook ES, means that any of those ESs can be executed instead; the final selection depends on the user. As ESs are similar to functions, when one is ended, the execution returns to the ES which made the call. Using the example in Figure 3, a user executes the first extended service, OrderBook. Later he/she can select either UpdateCart or AddBookToCart extended services. From UpdateCart can change the number of books selected for a specific one and he/she can delete one, as well as to add other book selecting the appropriate extended service. From AddBookToCart the user can makes a search, and this search can be done for: author, subject o title. This model extends the requirements specified in the CUS model to have a second level of abstraction. Using this model, it is easy to check how many parts have a specific CUS. In Figure 2 we have the metamodel of the (using Java 5 notation)> public class <>{ <> private <> <>; <<ENDFOREACH>> <<EXPAND AccessorMethods FOREACH attribute>> } <<ENDDEFINE>> <> public <> get<>() { return this.<>; } public void set<>( <> <> ) { this.<> = <>; } <<ENDDEFINE>> 2.4.2 From Content PIM to SQL From a given relational model and for each table create a new file where we have to: • • • •<parameterValues> The only parameter values we record in the trace are the one with primitive types, because we are interested in SQL statements passed as parameters. This will help us find the modules playing the role of “entities” (database tables access). For the server part (PL/SQL), the trace can be generated using the system tools of Oracle. 3.5 Execution Trace Analysis At this stage, we analysed the trace to find the modules involved in the execution. The result for the client part is presented in figure 13. We found that only 44 modules are involved in the processing of this use-case, which is one of the biggest in the application. But this should not come as a surprise. Since this system is a packaged software, then a lot of the implemented functions are unused. The last step is to sort out the roles of the modules in the execution of the use case. This will allow us to cluster the modules according to their role. Then we analysed the code of the executed functions to identify screen-related functions (i.e. VB6 functions used to display information). The associated modules then play the role of the boundaries in the robustness diagram. Next, we analysed the parameter values of the functions to find SQL statements. The corresponding modules play the role of the entities in the robustness diagram. The remaining modules play the role of the control object. The result of this analysis is presented in figure 14. The modules in the top layer are boundaries (screens), the bottom layer are the entities and the middle layer contains the modules playing the role of the control object.[email protected] , [email protected] [email protected] 2[email protected] 2 Department of Informatics, University of Piraeus 80 Karaoli & Dimitriou St., 18534 Piraeus, Greece {mvirvou,talepis}@unipi.gr[email protected] [email protected] [email protected] 2 Department of Computer Science, University of Bologna Mura Anteo Zamboni 7, Bologna, Italy [email protected] [email protected] Department of Computer Languages and Systems, Universitat Jaume I, Spain [email protected] [email protected] , [email protected] [email protected] , {aurora.vizcaino,javier.portillo,mario.piattini}@uclm.es[email protected] [email protected] 2 University of Cantabria. Department of Mathematics, Statistics and Computing, Los Castros s/n,39005, Santander, Spain [email protected] [email protected] , [email protected] [email protected] , [email protected] , [email protected] , [email protected] [email protected] , where A is an object’s action, R is a result of this action, O is an object (objects) that receives the result or that is used in this action (for example, a role, a time period, a catalog, etc.), PrCond is a set PrCond = {c1, …, ci}, where ci is a precondition or an-ing the < result> [to, into, in, by, of, from] a(n) , [PrCond,] E And the more abstract form is the following: -ing a(n) , [PrCond,] E The identified functional characteristics are described in the form . The identified TFM functional features are as follows. 1: Arriving a person, person, ex; 2: Creating a reader account, {unregistered person}, Lib, in; 3: Creating a reader card, Lib, in; 4: Giving out the card to a reader, Lib, in; 5: Getting the status of a reader, R, ex; 6: Completing a request_for_book, R, in; 7: Sending a request_for_book, R, in; 8: Taking out the book copy from a book fund, Lib, in; 9: Checking out a book copy, {completed request, book copy is available}, Lib, in; 10: Giving out a book copy, Lib, in; 11: Getting a book copy [by a registered reader], R, ex; 12: Returning a book copy [by a registered person], R, ex; 13: Taking back a book copy, Lib, in; 14: Checking the term of loan of a book copy, Lib, in; 15: Evaluating the condition of a book copy, Lib, in; 16: Imposing a fine, {the loan term is exceeded, the lost book, or the damaged book}, Lib, in; 17: Returning the book copy to a book fund, Lib, in; 18: Paying a fine, {imposed fine}, R, in; 19: Closing a fine, {paid fine}, Lib, in; 20: Completing a statement_of_utilization, {hardly damaged book copy}, Lib, in; 21: Sending the book copy to a Disposer, Lib, in; 22: Utilizing a book copy, Disposer, ex. Introduction of topology means establishing cause-and-effect relations between the identified functional features. Cause-and-effect relations are visualized as arcs of a digraph that are oriented from a cause vertex to an effect vertex. Cause-effect relations form causal chains that sometimes are functioning cycles. All the cycles and sub-cycles should be carefully analyzed in order to completely identify existing functionality of the system. The main cycle (cycles) of system’s functioning (i.e. functionality that is vitally necessary for system’s life) must be found and analyzed before starting further analysis. In case of studying a complex system, a TFM can be separated into a series of subsystems according to identified cycles. The result of the first two activities is represented in Fig.3a that illustrates a TFM composed for the mentioned fragment of library’s functioning. Fig. 3a clearly shows that cause-and-effect relations forms functioning cycles, and illustrates the main functional cycle defined by experts, which includes the following ordered functional features “17-8-9-10-11-5-12-13-14-15-17” (bold arrows). These functional features describe book checking out and taking back. They are assumed to be main, because have a major impact on business system operating. A cycle that includes the functional features “5-6-7-17-8-9-10-11-5” illustrates an example of the first-order subcycle.[email protected] , [email protected] 
