Software engineering and development

SOFTWARE ENGINEERING AND DEVELOPMENT No part of this digital document may be reproduced, stored in a retrieval system or transmitted in any form or by any means. The publisher has taken reasonable care in the preparation of this digital document, but makes no expressed or implied warranty of any kind and assumes no responsibility for any errors or omissions. No liability is assumed for incidental or consequential damages in connection with or arising out of information contained herein. This digital document is sold with the clear understanding that the publisher is not engaged in rendering legal, medical or any other professional services.

SOFTWARE ENGINEERING AND DEVELOPMENT

ENRIQUE A. BELINI EDITOR

Nova Science Publishers, Inc. New York

Copyright © 2009 by Nova Science Publishers, Inc. All rights reserved. No part of this book may be reproduced, stored in a retrieval system or transmitted in any form or by any means: electronic, electrostatic, magnetic, tape, mechanical photocopying, recording or otherwise without the written permission of the Publisher. For permission to use material from this book please contact us: Telephone 631-231-7269; Fax 631-231-8175 Web Site: http://www.novapublishers.com NOTICE TO THE READER The Publisher has taken reasonable care in the preparation of this book, but makes no expressed or implied warranty of any kind and assumes no responsibility for any errors or omissions. No liability is assumed for incidental or consequential damages in connection with or arising out of information contained in this book. The Publisher shall not be liable for any special, consequential, or exemplary damages resulting, in whole or in part, from the readers’ use of, or reliance upon, this material. Any parts of this book based on government reports are so indicated and copyright is claimed for those parts to the extent applicable to compilations of such works. Independent verification should be sought for any data, advice or recommendations contained in this book. In addition, no responsibility is assumed by the publisher for any injury and/or damage to persons or property arising from any methods, products, instructions, ideas or otherwise contained in this publication. This publication is designed to provide accurate and authoritative information with regard to the subject matter covered herein. It is sold with the clear understanding that the Publisher is not engaged in rendering legal or any other professional services. If legal or any other expert assistance is required, the services of a competent person should be sought. FROM A DECLARATION OF PARTICIPANTS JOINTLY ADOPTED BY A COMMITTEE OF THE AMERICAN BAR ASSOCIATION AND A COMMITTEE OF PUBLISHERS. LIBRARY OF CONGRESS CATALOGING-IN-PUBLICATION DATA Software engineering and development / Enrique A. Belini. p. cm. Includes index. ISBN 978-1-61668-289-7 (E-Book) 1. Software engineering. 2. Computer software--Development. I. Belini, Enrique A. QA76.758.S64557 2009 005.1--dc22 2009014731

Published by Nova Science Publishers, Inc.

New York

CONTENTS Preface

vii

Expert Commentaries A

Succinct Representation of Bit Vectors Supporting Efficient rank and select Queries Jesper Jansson and Kunihiko Sadakane

B

Heterogeneity as a Corner Stone of Software Development in Robotics Juan-Antonio Fernández-Madrigal, Ana Cruz-Martín, Cipriano Galindo and Javier González

Short Communications

1 3

13

23

A

Embedding Domain-Specific Languages in General-Purpose Programming Languages Zoltán Ádám Mann

25

B

Studying Knowledge Flows in Software Processes Oscar M. Rodríguez-Elias, Aurora Vizcaíno, Ana I. Martínez-García , Jesús Favela and Mario Piattini

37

C

Software Product Line Engineering: The Future Research Directions Faheem Ahmed, Luiz Fernando Capretz and Muhammad Ali Babar

69

D

Software Development for Inverse Determination of Constitutive Model Parameters A. Andrade-Campos, P. Pilvin, J. Simões and F. Teixeira-Dias

93

E

Design of Molecular Visualization Educational Software for Chemistry Learning L.D. Antonoglou, N.D. Charistos and M.P. Sigalas

125

vi

Contents F

Software Components for Large Scale Super and Grid Computing Applications Muthu Ramachandran

151

G

Principles and Practical Aspects of Educational Software Evaluation Quynh Lê and Thao Lê

175

Research and Review Studies

185

Chapter 1

Testing Event-driven Software – the Next QA Challenge? Atif M. Memon

187

Chapter 2

Debugging Concurrent Programs Using Metaheuristics Francisco Chicano and Enrique Alba

193

Index

223

PREFACE Software engineering is one of the most knowledge intensive jobs. Thus, having a good knowledge management (KM) strategy in these organizations is very important. This book examines software processes from a knowledge perspective flow, in order to identify the particular knowledge needs of such processes to then be in a better position for proposing systems or strategies to address those needs. Its possible benefits are illustrated through the results of a study in a software maintenance process within a small software organization. Furthermore, software product line architecture is regarded as one of the crucial piece of entity in software product lines. The authors of this book discuss the state of the art of software product line engineering from the perspectives of business, architecture, process and organization. In recent years, domain-specific languages have been proposed for modelling applications on a high level of abstraction. Although the usage of domain-specific languages offers clear advantages, their design is a highly complex task. This book presents a pragmatic way for designing and using domain-specific languages. Other chapters in this book examine the development of numerical methodologies for inverse determination of material constitutive model parameters, discuss some of the reasons for the irrelevancy of software engineering to the robotic community, review the evolution of robotic software over time, and propose the use of Ant Colony Optimization, a kind of metaheuristic algorithm, to find general property violations in concurrent systems using a explicit state model checker. In the design of succinct data structures, the main objective is to represent an object compactly while still allowing a number of fundamental operations to be performed efficiently. In Expert Commentary A, the authors consider succinct data structures for storing a bit vector B of length n. More precisely, in this setting, one needs to represent B using n+ o(n) bits so that rank and select queries can be answered in O(1) time, where for any i ∈ {1, 2, . . . , n}, rank0(B, i) is the number of 0s in the first i positions of B, select0(B, i) is the position in B of the ith 0 (assuming Bcontains at least i0s), and rank1(B, i) and select1(B, i) are defined analogously. These operations are useful because bit vectors supporting rank and select queries are employed as a building block for many other more complex succinct data structures. The authors first describe two succinct indexing data structures for supporting rank and select queries on B in which B is stored explicitly together with some auxiliary information. The authors then present some matching lower bounds. Finally, the authors discuss generalizations and related open problems for supporting rank and select queries efficiently on strings over non-binary alphabets.

viii

Enrique A. Belini

In the last years the complexity of robotic applications has raised important problems, particularly in large and/or long-term robotic projects. Software engineering (SE) seems the obvious key for breaking that barrier, providing good maintenance and reusing, coping with exponential growth of programming effort, and integrating diverse components with guarantees. Suprisingly, SE has never been very relevant within the robotic community. In Expert Commentary B the authors briefly describe some causes for that, review the evolution of robotic software over time, and provide some insights from our most recent contributions. They have found that many problems arising from the conflicts raised by robotic complexity can be well addressed from a SE perspective as long as the focus is, at all levels, on the heterogeneity of components and methodologies. Therefore the authors propose heterogeneity as one of the corner stones of robotic software at present. In recent years, domain-specific languages have been proposed for modelling applications on a high level of abstraction. Although the usage of domain-specific languages offers clear advantages, their design is a highly complex task. Moreover, developing a compiler or interpreter for these languages that can fulfil the requirements of industrial application is hard. Existing tools for the generation of compilers or interpreters for domainspecific languages are still in an early stage and not yet appropriate for the usage in an industrial setting. Short Communication A presents a pragmatic way for designing and using domainspecific languages. In this approach, the domain-specific language is defined on the basis of a general-purpose programming language. Thus, general programming mechanisms such as arithmetics, string manipulations, basic data structures etc. are automatically available in the domain-specific language. Additionally, the designer of the domain-specific language can define further domain-specific constructs, both data types and operations. These are defined without breaching the syntax of the underlying general-purpose language. Finally, a library has to be created which provides the implementation of the necessary domain-specific data types and operations. This way, there is no need to create a compiler for the new language, because a program written in the domain-specific language can be compiled directly with a compiler for the underlying general-purpose programming language. Therefore, this approach leverages the advantages of domain-specific languages while minimizing the effort necessary for the design and implementation of such a language. The practical applicability of this methodology is demonstrated on a case study, in which test cases for testing electronic control units are developed. The test cases are written in a new domain-specific language, which in turn is defined on the basis of Java. The pros and cons of the presented approach are examined in detail on the basis of this case study. In particular, it is shown how the presented methodology automatically leads to a clean software architecture. Many authors have observed the importance of knowledge for software processes. This fact has caused that every time more researchers and practitioners initiate efforts to apply knowledge management in software processes. Unfortunately, much of such efforts are just oriented to aid big software companies, and in using existing knowledge management systems or strategies that have not been developed following the specific and particular knowledge needs of the process in which they are included. This fact has caused that often such efforts do not really help to the people who should benefit by using them. In this chapter the authors state that one way to address this problem is to first study software processes from a knowledge flow perspective, in order to identify the particular knowledge needs of such processes to then be in a better position for proposing systems or strategies to address those

Preface

ix

needs. Short Communication B presents an approach which has been used to accomplish the last objective. Its possible benefits are illustrated through the results of a study in a software maintenance process within a small software organization. The recent trend of switching from single software product development to lines of software products in the software industry has made the software product line concept viable and widely accepted methodology in the future. Some of the potential benefits of this approach include cost reduction, improvement in quality and a decrease in product development time. Many organizations that deal in wide areas of operation, from consumer electronics, telecommunications, and avionics to information technology, are using software product lines practice because it deals with effective utilization of software assets and provides numerous benefits. Software product line engineering is an inter-disciplinary concept. It spans over the dimensions of business, architecture, process and organization. The business dimension of software product lines deals with managing a strong coordination between product line engineering and the business aspects of product line. Software product line architecture is regarded as one of the crucial piece of entity in software product lines. All the resulting products share this common architecture. The organizational theories, behavior and management play critical role in the process of institutionalization of software product line engineering in an organization. The objective of Short Communication C is to discuss the state of the art of software product line engineering from the perspectives of business, architecture, organizational management and software engineering process. This work also highlights and discusses the future research directions in this area thus providing an opportunity to researchers and practitioners to better understand the future trends and requirements. Computer simulation software using finite element analysis (FEA) has, nowadays, reached reasonable maturity. FEA software is used in such diverse fields as structural engineering, sheet metal forming, mould industry, biomechanics, fluid dynamics, etc. This type of engineering software uses an increasingly large number of sophisticated geometrical and material models. The quality of the results relies on the input data, which are not always readily available. The aim of inverse problem software, which will be considered here, is to determine one or more of the input data relating to FEA numerical simulations. The development of numerical methodologies for inverse determination of material constitutive model parameters will be addressed in Short Communication D. Inverse problems for parameter identification involve estimating the parameters for material constitutive models, leading to more accurate results with respect to physical experiments, i.e. minimizing the difference between experimental results and simulations subject to a limited number of physical constraints. These problems can involve both hyperelastic and hypoelastic material constitutive models. The complexity of the process with which material parameters are evaluated increases with the complexity of the material model itself. In order to determine the best suited material parameter set, in the less computationally expensive way, different approaches and different optimization methods can be used. The most widespread optimization methods are the gradient-based methods, the genetic, evolutionary and natureinspired algorithms, the immune algorithms and the methods based in neural networks and artificial intelligence. By far, the better performing methods are gradient-based but their performance is known to be highly dependent on the starting set of parameters and their results are often inconsistent. Nature-inspired techniques provide a better way to determine an optimized set of parameters (the overall minimum). Therefore, the difficulties associated to

x

Enrique A. Belini

choosing a starting set of parameters for this process is minor. However, these proved to be computationally more expensive than gradient-based methods. Optimization methods present advantages and disadvantages and their performance is highly dependent on the constitutive model itself. There is no unique algorithm robust enough to deal with every possible situation, but the use of sequential multiple methods can lead to the global optimum. The aim of this strategy is to take advantage of the strength of each selected algorithm. This strategy, using gradient-based methods and evolutionary algorithms, is demonstrated for an elasticplastic model with non-linear hardening, for seven distinct hyperelastic models (Humphrey, Martins, Mooney-Rivlin, Neo-Hookean, Ogden, Veronda-Westmann and Yeoh) and for one thermoelastic-viscoplastic hypoelastic model. The performance of the described strategy is also evaluated through an analytical approach. An important goal for chemical education is students’ acquisition of key concepts and principles regarding molecular structure. Chemists have developed a rich symbolic language that helps them create and manipulate mental and external representations that describe spatial relations of aperceptual particles in order to investigate and communicate chemical concepts. High school and college students pose significant difficulties in understanding these concepts, mastering the symbolic language and making connections and transformations between symbolic, microscopic and macroscopic representations of chemical phenomena. Over the past decade the development of molecular visualization tools has changed the nature of chemistry research and created promising prospects for their integration in chemistry education which could help students overcome these difficulties. In Short Communication E the authors examine the case of molecular visualization in chemistry education and describe a number of educational packages that utilize new molecular visualization tools they developed to support learning of chemistry concepts in secondary and tertiary education. Software development for large and complex systems remains a costly affair. The complexity for supercomputing applications that require high speed and high precision systems grows exponentially. Short Communication F provides an approach to design and development of supercomputing applications based on software components which have potential to minimize the cost and time for complex and high dependability systems. Software components are aimed to provide a self-contained entity that can be adapted to the required environment quickly and easily. However this definition need to extended for large scale supercomputing paradigm. This will be a quite considerable paradigm shift for Component Based Software Engineering (CBSE) paradigm that exists today. The main criteria for supercomputing and grid applications include flexibility, reusability, scalability, highly concurrent, parallel & multi-threaded, security, distributed and data-intensive systems. This chapter defines a new paradigm for CBSE for supercomputing applications. Therefore design for large scale software components is the major emphasis of this chapter. As explained in Short Communication G, software is not just a product for all-purpose use. Generally, software is produced for a specific purpose in a domain. Some software products appeal to a wide range of users such as word processing, drawing, and editing. However, software is developed to cater for the demand of targeted users. For example, Statistical Packages for Social Science (SPSS) is a statistic analysis tool for analyzing quantitative data in research. In education, the main aim of software is to enhance teaching and learning. It is important to evaluate educational software to determine its effectiveness. There are a number of issues concerning evaluation of educational software such as users’ and evaluators’ perspectives on teaching and learning, translation theory into practice.

Preface

xi

A particular class of software that is fast becoming ubiquitous is event-driven software (EDS). All EDS share a common event-driven model – they take sequences of events (e.g., messages, mouse-clicks) as input, change their state, and (sometimes) output an event sequence. Examples include web applications, graphical user interfaces (GUIs), network protocols, device drivers, and embedded software. Quality assurance tasks such as testing have become important for EDS since they are being used in critical applications. Numerous researchers have shown that existing testing techniques do not apply directly to EDS because of the new challenges that EDS offer. Chapter 1 lists some of these challenges and emphasizes on the need to develop new techniques (or enhance existing ones) to test EDS. Model Checking is a well-known and fully automatic technique for checking software properties, usually given as temporal logic formulae on the program variables. Some examples of properties are the absence of deadlocks, the absence of starvation, the fulfilment of an invariant, etc. The use of this technique is a must when developing software that controls critical systems, such as an airplane or a spacecraft. Most model checkers found in the literature use exact deterministic algorithms to check the properties. The memory required for the verification with these algorithms usually grows in an exponential way with the size of the system to verify. This fact is known as the state explosion problem and limits the size of the system that a model checker can verify. When the search for errors with a low amount of computational resources (memory and time) is a priority (for example, in the first stages of the implementation of a program), non-exhaustive algorithms using heuristic information can be used. Non-exhaustive algorithms can find errors in programs using less computational resources than exhaustive algorithms, but they cannot be used for verifying a property: when no error is found using a non-exhaustive algorithm the authors still cannot ensure that no error exists. In Chapter 2 the authors propose the use of Ant Colony Optimization, a kind of metaheuristic algorithm, to find general property violations in concurrent systems using an explicit state model checker. Metaheuristic algorithms are a well-known set of techniques used for finding near optimal solutions in NP-hard optimization problems in which exact techniques are unviable. Our proposal, called ACOhg-mc, takes also into account the structure of the property to check in order to improve the efficacy and efficiency of the search. In addition to the description of the algorithm, the authors have performed a set of experiments using the experimental model checker HSF-SPIN and a subset of models from the BEEM benchmark for explicit model checking. The results show that ACOhg-mc finds optimal or near optimal error trails in faulty concurrent systems with a reduced amount of resources, outperforming in most cases the results of algorithms that are widely used in model checking, like Nested Depth First Search or Improved Nested Depth First Search. This fact makes our proposal suitable for checking properties in large faulty concurrent programs, in which traditional techniques fail to find counterexamples because of the model size. In addition, the authors show that ACOhg-mc can also be combined with techniques for reducing the state explosion such as partial order reduction and the authors analyze the performance of this combination.

EXPERT COMMENTARIES

In: Software Engineering and Development Editor: Enrique A. Belini, pp. 3-12

ISBN 978-1-60692-146-3 c 2009 Nova Science Publishers, Inc.

Expert Commentary A

S UCCINCT R EPRESENTATION OF B IT V ECTORS S UPPORTING E FFICIENT rank AND select Q UERIES Jesper Jansson1,∗,† and Kunihiko Sadakane2,‡ 1 Ochanomizu University, 2-1-1 Otsuka, Bunkyo-ku, Tokyo 112-8610, Japan 2 Department of Computer Science and Communication Engineering, Kyushu University, 744 Motooka, Nishi-ku, Fukuoka 819-0395, Japan

Abstract In the design of succinct data structures, the main objective is to represent an object compactly while still allowing a number of fundamental operations to be performed efficiently. In this commentary, we consider succinct data structures for storing a bit vector B of length n. More precisely, in this setting, one needs to represent B usingn+ o(n) bits so that rank and select queries can be answeredin O(1) time, where for any i ∈ {1, 2, . . . , n}, rank 0 (B, i) is the number of 0s in thefirst i positions of B, select 0 (B, i) is the position in B of the ith 0 (assuming B contains at least i 0s), and rank 1 (B, i) and select 1 (B, i) are defined analogously.These operations are useful because bit vectors supporting rank andselect queries are employed as a building block for many other morecomplex succinct data structures. We first describe two succinct indexing data structures for supportingrank and select queries on B in which B is stored explicitlytogether with some auxiliary information.We then present some matching lower bounds.Finally, we discuss generalizations and related open problems for supportingrank and select queries efficiently on strings over non-binaryalphabets.

1.

Introduction

Let B ∈ {0, 1}n be a bit vector of length n. For any i ∈ {1, 2, . . . , n}, let B[i] denote the value of B atposition i, and for any i, j ∈ {1, 2, . . . , n} with i ≤ j, letB[i..j] be the bit ∗

E-mail address: [email protected] Funded by the Special Coordination Funds for Promoting Science and Technology, Japan. ‡ E-mail address: [email protected] †

4

Jesper Jansson and Kunihiko Sadakane

vector consisting of B[i], B[i + 1], . . . , B[j].(If i > j then B[i..j] is defined to be ∅.)Next, define the following operations: • rank 0 (B, i) – Return the number of 0s in B[1..i]. • rank 1 (B, i) – Return the number of 1s in B[1..i]. • select 0 (B, i) – Return the position in B of the ith 0. • select 1 (B, i) – Return the position in B of the ith 1. In this commentary, we consider the problem of constructing a data structure for storing any given B such that rank 0 (B, i), rank 1 (B, i),select 0 (B, i), and select 1 (B, i) queries can be carried out efficiently.We focus on indexing data structures for B, where B is storedverbatim in n bits and one is allowed to use o(n) extra bitsof storage (called the index) to efficiently support rank andselect queries on B. We assume the word-RAM model of computation with wordlength w = ⌈log n⌉ 1 bits in order to handle pointers to the data structure in constant time.In the word-RAM model, the CPU can perform logical operations such as ANDand OR, and arithmetic operations such as addition, subtraction,multiplication, and division between two integers in the interval[0, 2w − 1] (w-bit integers) in constant time.The CPU can also read/write a wbit integer from/to a specific memory cellin constant time; in other words, if B is a stored bit vector of length n,then for any given i ∈ {0, 1, . . . , n − w}, B[(i + 1)..(i + w)] can beobtained in O(1) time. The commentary is organized as follows: In Section 2., we outline how to construct in O(n) timean index for B of size O(n log log n/ log n) = o(n)bits which allows each subsequent rank or select query to be answeredin O(1) time.The presentation in Section 2. is based on [20] for rank and [28] for select.Next, in Section 3., we state some lower bounds from [11]and [19] which match the upper bounds given in Section 2.Then, in Section 4., we discuss generalizations to non-indexingdata structures as well as generalizations to non-binary vectors,and finally, in Section 5., we provide examples of otherdata structures that depend on efficient rank and select datastructures for bit vectors and non-binary vectors,and mention some directions for further research.

2.

Upper Bounds for Indexing Data Structures

Jacobson [15] presented a space-efficient indexing data structurefor B which allows rank and select queries on B to be answered inO(1) and O(log n) time, respectively, while requiring onlyO(n log log n/ log n) bits for the index.A series of improvements to Jacobson’s data structure were made byClark [4],Munro [20],Munro et al. [23],and Raman et al. [28], reducing the time needed to answereach select query to O(1) while usingan index of size O(n log log n/ log n) bits. Below, we describe two simplified indexing data structures for Bbased on [20] for rank To make the presentation more readable, we omit“⌈”, “⌉”, “⌊”, and “⌋” symbolswhere obvious. Also, we allow the last block in any partition into blocks to be smallerthan the specified block size. 1

Throughoutthis commentary, “log” denotes the base-2 logarithm and“logσ ” denotes the base-σ logarithm.

Succinct Representation of Bit Vectors Supporting Efficient rank and select Queries 5

2.1.

An Indexing Data Structure for rank Queries (based on [20])

Conceptually divide the bit vector B into blocks of lengthℓ = log2 n each, and call each such block a large block.Next, divide every large block into small blocks of length s = 12 log n each.Create auxiliary data structures for storing the values of rank 1 forthe boundaries of these blocks as follows:Use an integer array Rℓ [0..n/ℓ] in which every entry Rℓ [x]stores the number of 1’s in B[1..xℓ], andan integer array Rs [0..n/s] in which every y entry Rs [y] stores thenumber of 1’s inB[(⌊ ℓ/s ⌋·ℓ + 1)..ys],i.e., the number of 1’s in the yth small block plus the total number of1’s in all small blocks which belong to the same large block as smallblock y and which occur before small block y.The space needed to store Rℓ isO( nℓ · log n) = O( logn n ) bitsbecause each of its entries occupies O(log n) bits, and the

log n spaceneeded to store Rs isO( ns · log(ℓ + 1)) = O( n log log n )bits because all of its entries are between 0 and ℓ. To answer the query rank 1 (B, i) for any given i ∈ {1, 2, . . . , n},compute x = ⌊ ℓi ⌋, y = ⌊ si ⌋, and z = i − ys,and use the relationrank 1 (B, i) = rank 1 (B, ys) + Pz Pz q=1 B[ys + q] = Rℓ [x] + Rs [y] + q=1 B[ys + q],where the first two terms are directly available from Rℓ and Rs .To compute the third term in constant time, the following table lookuptechnique can be applied:In advance, construct a table Tr [0..(2s − 1), 1..s] in which eachentry Tr [i, j] stores the number of 1’s in the first j bits of thebinary representation P of i.Then, whenever one needs to compute zq=1 B[ys + q],first read the memory cell storing B[(ys + 1)..(ys + s)](because s < w, this can be done in constant time),interpret this s-bit vector as an integer p,where p ∈ {0, 1, . . . , 2s − 1},and find the value Tr [p, z] in the table.Hence, rank 1 (B, ys + z) can be computed in constant time.The size of the √ table Tr is2s · s · log(s + 1)=O( n · log n · log log n) = o(n) bits,and all of the auxiliary data structures Rℓ , Rs , Tr may beconstructed in O(n) time. To compute rank 0 (B, i), no additional data structures are necessarybecause rank 0 (B, i) = i − rank 1 (B, i).Therefore we have:

Theorem 1. Given a bit vector of length n, after O(n) time preprocessing andusing an index of size O(n log log n/ log n) bits,each rank 1 and rank 0 query can be answered in O(1) time.

2.2.

An Indexing Data Structure for select Queries (based on [28])

Define ℓ = log2 n and construct an array storing the position ofthe (iℓ)th occurrence of a 1 in B for alli = 1, 2, . . . , nℓ .Regions in B between two consecutive positions stored in the array arecalled upper blocks.If the length of an upper block is at least log4 n, it is sparse.For every sparse upper block, store the positions of all its 1’s explicitlyin sorted order.Since the number of such blocks is at most logn4 n , the spacerequired for storing the positions of all 1’s in all sparse upper blocks isat most logn4 n · log2 n · log n =

n log n

bits. For every non-sparse 1 2

upper block U , further divide it intolower blocks √ of length s = log n each and construct acomplete tree for U with branching factor log n whose leaves arein one-to-one correspondence with the lower blocks in U .The height of the tree is at most 7, i.e., at most a con4 stant, because thenumber of leaves is at most logs n = 2 log3 n.For each non-leaf node v of √ the tree, let Cv be an array of log n integers such that Cv [i] equals the number of 1’s inthe subtree rooted at the ith child of v.(All Cv -arrays can be computed in O(n) time prepro2n cessing.)The entire bit vector B contains at most ns = log n lower blocks, so the total number

6

Jesper Jansson and Kunihiko Sadakane

of nodes in all trees representing allthe upper blocks is O( logn n ) and furthermore, the total numberof entries in all Cv -arrays is at most this much.Since the number of 1’s in any tree is at most log2 n, every entryin a Cv -array can be stored in O(log log n) bits.Therefore, the total space needed to store all trees(including all the Cv -arrays) isO( logn n ·log log n) bits. To answer the select 1 (B, i) query in constant time, first divide iby ℓ to find the upper block U that contains the ith 1, andcheck whether U is sparse or not.If U is sparse, the answer to the select 1 query is stored explicitlyand can be retrieved directly.If U is not sparse, start at the root of the tree that represents U anddo a search to reach the leaf that corresponds to the lower block with thejth 1, where j equals i modulo ℓ.At each step, it is easy to determine which subtree contains the jth 1 inO(1) time by a table lookup using the Cv array for√ the currentnode v, and then adjust j and continue to the next step.(For the lookup, use an ( log n + 1)-dimensional table T such thatentry T [c1 , c2 , . . . , c√log n , j] = x if and only ifthe first subtree contains exactly c1 1’s, the second subtree containsexactly c2 1’s, etc. and the jth 1 belongs to the xth √ subtree.The space needed to store T is o(n) bits because the index of T is encoded in ( log n + 1) · 2 log log n ≤ 0.5 log n bitsfor large enough n, so T has O(20.5 log n ) = O(n0.5 ) entrieswhich each need log log n bits.)Finally, after reaching a leaf and identifying the corresponding lower block,find the relative position of the jth 1 inside that lower block byconsulting a global table of √ size21/2 log n · 21 log n · log log n=O( n log n log log n)bits which stores the relative position of the qth 1 inside a lower blockfor every possible binary string of length 12 log n and everypossible query q in {1, 2, . . . , 12 log n}. To answer select 0 queries, construct data structures analogous to thosefor select 1 described above.We obtain the following. Theorem 2. Given a bit vector of length n, after O(n) time preprocessing andusing an index of size O(n log log n/ log n) bits,each select 1 and select 0 query can be answered in O(1) time.

3.

Lower Bounds for Indexing Data Structures

By applying two different techniques,one consisting of a reduction from a vector addition problem and theother one a direct information-theoretical argument involving reconstructingB from any given indexing data structure for B together with anappropriately defined binary string,Miltersen [19] proved the following theorem.(Recall that B is assumed to be stored explicitly in addition to the bitsused by the indexing data structure.) Theorem 3. [19] It holds that: 1. Any indexing data structure for rank queries on B using word size w,index size r bits, and query time t must satisfy2(2r + log(w + 1))tw ≥ n log(w + 1). 2. Any indexing data structure for select queries on B using word size w,index size r bits, and query time t must satisfy 3(r + 2)(tw + 1) ≥ n. In particular, for the case t = O(1) and w = O(log n),Theorem 3 immediately implies the lower boundsr = Ω(n log log n/ log n) for rank indexing data structuresand r = Ω(n/ log n) for select indexing data structures. Using a counting argument based on binary choices trees, these lower boundswere strengthened by Golynski [11] as follows:

Succinct Representation of Bit Vectors Supporting Efficient rank and select Queries 7 Theorem 4. [11] If there exists an algorithm for either rank or select queries on Bwhich reads O(log n) different positions of B, has unlimited access to an index of size r bits, and log n is allowed to use unlimited computationpower, then r = Ω( n log log n ). Hence, the upper bounds given in Theorems 1and 2 are asymptotically optimal.Note that Theorem 4 is very general;it does not impose any restrictions on the running time or require the readpositions of B to be consecutive for the lower bound to hold. Theorem 5. [11] Suppose that B has exactly m positions set to 1 for some integer m.If there exists an algorithm for either rank or select queries on Bwhich reads at most t different positions of B, has unlimited access toan index of size r bits, and is allowed to use unlimited computation power,then r = Ω( mt · log t).

4.

Generalizations

The indexing data structures in Sections 2. and 3. assume that the bit vector B is always stored explicitly.However, the space used by this type of encoding is far from optimal if the number of 1’s in B is much smaller than n, or close to n.This is because the number of bit n
n n−m n vectors of length n having m 1’s is m ≈ 2nH0 , whereH0 = m n log m + n log n−m is n the 0th order entropy of the bit vector,which may be much less than 2 , the number of distinct bit vectors oflength n.In fact, there exist data structures for rank /selectusing only nH0 + O(n log log n/ log n) bitsto store B such that any consecutive O(log n) bits of B canstill be retrieved in constant time2 : Theorem 6. [28] For a bit vector B of length n with m 1’s, after O(n) timepreprocessing n n−m n and using nH0 + O(n log log n/ log n) bits,where H0 = m n log m + n log n−m ,each rank 1 , rank 0 , select 1 , and select 0 query can beanswered in O(1) time.Moreover, any consecutive O(log n) bits of B can be retrieved inO(1) time. The rank /select data structures can be extended to non-binary vectors.A string S of length n over an alphabet A is a vector S[1..n]such that S[i] ∈ A for 1 ≤ i ≤ n.Let σ be the alphabet size, i.e., σ = |A|.We assume that A is an integer alphabet of the form{0, 1, . . . , σ − 1} and that σ ≤ n.(Without loss of generality, we further assume that σ is a powerof 2.)Below, we consider succinct data structures for S supporting the followingoperations for any i ∈ {1, 2, . . . , n} and c ∈ {0, 1, . . . , σ − 1}: • access(S, i) – Return S[i]. • rank c (S, i) – Return the number of occurrences of c in S[1..i]. • select c (S, i) – Return the position of the ith c in S. S may be encoded in n log σ bits by the obvious representationusing log σ bits for each position S[i], but there exist otherencodings which improve the rank and select query time complexitiesat the cost of increasing the space complexity and the time needed 2

Observethat these data structures do not store B directly, so to retrieveO(log n) consecutive bits of B in O(1) time is no longertrivial.

8

Jesper Jansson and Kunihiko Sadakane

toretrieve S[i] for any given i ∈ {1, 2, . . . , n}.Hence, there is a trade-off between the size of a data structure and theaccess/rank /select query times.Table 1 lists the performance of two straightforward datastructures D1 and D2 (explained below) and threeimproved data structures proposed in [1, 12, 13]. The first straightforward data strucTable 1. The trade-off between the size (in bits) and the time neededto answer each access, rank c , and select c query for various datastructures.|S| denotes the number of bits to encode S, H0 is the 0th orderentropy of S, and α = log log σ log log log σ. Reference D1 in Section 4. D2 in Section 4. [13] [12] [1]

Size of data structure n(H0 + log e) + σ · o(n) |S| + (σ + 1) · o(n) nH0 + log σ · o(n) n log σ + n · o(log σ) |S| + n · o(log σ)

access time O(σ) O(1) O(log σ) O(log log σ) O(1)

rank c time O(1) O(log σ) O(log σ) O(log log σ) O(α log log σ)

select c time O(1) O(log σ) O(log σ) O(1) O(α)

ture D1 stores σ bit vectorsV0 , V1 , . . . , Vσ−1 of length n such that Vc [i] = 1 if andonly if S[i] = c, along with rank1 and select1 indexing data structuresfor these bit vectors.Then rank c (S, i) = rank 1 (Vc , i) and select c (S, i) = select 1 (Vc , i),and therefore they can be obtained in constant time.On the other hand, access requires O(σ) time because it mustexamine all of V0 [i], V1 [i], . . . , Vσ−1 [i].Each bit vector Vc can be encoded
inlog mnc ≈ mc (log e + log mnc ) bitsby Theorem 6, where mc denotes the number of c’s in P S.In total, the space is c {mc (log e + log mnc ) + O(n log log n/ log n)} = n(H0 + log e) + σ · O(n log log n/ log n) bits. The second straightforward data structure D2 stores S explicitlyin n log σ bits.In addition, it stores a rank1 and select1 indexing data structure foreach of the bit vectors V0 , V1 , . . . , Vσ−1 of D1 .The bit vectors V0 , V1 , . . . , Vσ−1 are not stored explicitly,so to answer rankc and selectc queries,D2 must have a method to compute any consecutive log n bits of Vc that are required by the indexing data structure for Vc .This can be done in O(log σ) time by repeating the following steps2 log σ times,each time obtaining 1 1 2 logσ n bits of Vc :In O(1) time, read 2 log n consecutive bits from Sand put them in a bit 1 vector r.To find the 2 logσ n bits of Vc that correspond to r,let s be the bit vector of length 1 1 2 log n consisting of 2 logσ n copies of the length-(log σ)pattern 000 . . . 01, let t be s multiplied by c, and and let u bethe bitwise exclusive-or between r and t.Note that for any nonnegative integer i,the length-(log σ) pattern of u starting at positioni·log σ equals 000 . . . 00 if and only if the correspondingposition in S contains the symbol c.Finally, look up entry u √ in a table having 21/2 log n = nentries to obtain a bit vector of size 12 logσ ncontaining a 1 in position i if and only ifu[(i · log σ)..((i + 1) · log σ) − 1] = 000 . . . 00.Thus, rank c and select c take O(log σ) time.The access query takes constant time because S is explicitly stored.The total space is that of storing S plusσ · O(n log log n/ log n) bits for the rank1 andselect1 indexing data structures, plus the size of the lookup table which √ is n · 12 logσ n = o(n) bits. In Table 1, |S| denotes the number of bits to encode S. It is n log σ if S is not compressed; however, it can be reduced byapplying a compression algorithm which supports instant Theorem 7. There exists a succinct data structure for storing a string S[1..n] over an

Succinct Representation of Bit Vectors Supporting Efficient rank and select Queries 9 alphabet A = {0, 1, . . . , σ − 1} in n(log logσ n + k log σ) nHk + O logσ n 



bits for any k ≥ 0, where Hk is the kth order empiricalentropy of S, such that any substring of the formS [i . . . i + O(logσ n)]with i ∈ {1, 2, . . . , n} can be decoded in O(1) time on theword-RAM. By using this theorem, we can compress S into nHk + o(n log σ)bits.Furthermore, we can regard the compressed data as an uncompressed string.Therefore the query time in Table 1 does not change.

5.

Concluding Remarks

Succinct data structures that support efficient rank and select querieson bit vectors and non-binary vectors are important because they form thebases of several other more complex data structures.Some examples include succinct data structures for representingtrees [2, 6, 10, 16, 17, 22, 23],graphs [3, 15],permutations and functions [21, 24],text indexes [7, 14, 29, 30],prefix or range sums [26],and polynomials and others [9].In these data structures, a typical use of rank and select querieson bit vectors is to encode pointers to blocks of data.For example, suppose that to compress some data we partition it into blocks,compress each block independently into a variable numbers of bits, andconcatenate the result into a bit vector C.Then we can use another bit vector B[1..|C|] such that B[i] = 1 if and onlyif the ith bit of C is the starting position of a block, and applyselect 1 queries on B to find the correct starting and ending positionsin C when decompressing the data corresponding to a particular block.Some directions for further research include dynamization to supportoperations that allow B to be modified online [27],proving lower bounds on the size of succinct datastructures [5, 11, 19](note that the lower bounds shown in Section 3. hold only ifthe bit vector is stored explicitly using n bits, and thus do nothold for bit vectors stored in a compressed form),and practical implementation [25].Although the sizes of the known indexing data structures for bit vectors areasymptotically optimal, the o(n) additional space needed by an index isoften too large for real data and cannot be ignored.Therefore, for practical applications, it is crucial to develop otherimplementations of succinct data structures.Another open problem involves access/rank /selectoperations on non-binary vectors.No single data structure listed in Table 1 supports constanttime access, rank and select queries.What are the best possible lower and upper bounds on the number of bitsrequired to achieve this?Finally, a related topic is compressed suffix arrays [14],which are data structures for efficient substring searches.The suffix array [18] uses n log n bits for a string oflength n with alphabet size σ, while the compressedsuffix array uses only O(n log σ) bits, which is linear inthe string size. On the other hand, the compressed suffix array does notsupport constant time retrieval of an element of the suffix array.An important open problem is to establish whether there exists a data structureusing linear space and supporting constant time retrieval.

10

Jesper Jansson and Kunihiko Sadakane

References [1] J. Barbay, M. He, J. I. Munro, and S. S. Rao. Succinct indexes for strings, binary relations and multi-labeled trees. In Proceedings of the 18 th Annual ACM-SIAM Symposium on Discrete Algorithms (SODA 2007), pages 680–689, 2007. [2] D. Benoit, E. D. Demaine, J. I. Munro, R. Raman, V. Raman, and S. S. Rao. Representing Trees of Higher Degree. Algorithmica, 43(4):275–292, 2005. [3] D. K. Blandford, G. E. Blelloch, and I. A. Kash. Compact representations of separable graphs. In Proceedings of the 14 th Annual ACM-SIAM Symposium on Discrete Algorithms (SODA 2003), pages 679–688, 2003. [4] D. Clark. Compact Pat Trees. PhD thesis, The University of Waterloo, Canada, 1996. [5] E. D. Demaine and A. L´opez-Ortiz. A Linear Lower Bound on Index Size for Text Retrieval. Journal of Algorithms, 48(1):2–15, 2003. [6] P. Ferragina, F. Luccio, G. Manzini, and S. Muthukrishnan. Structuring labeled trees for optimal succinctness, and beyond. In Proceedings of the 46 th Annual IEEE Symposium on Foundations of Computer Science (FOCS 2005), pages 184–196, 2005. [7] P. Ferragina and G. Manzini. Indexing compressed texts. Journal of the ACM, 52(4):552–581, 2005. [8] P. Ferragina and R. Venturini. A simple storage scheme for strings achieving entropy bounds. Theoretical Computer Science, 372(1):115–121, 2007. [9] A. G´al and P. B. Miltersen. The cell probe complexity of succinct data structures. In Proceedings of the 30 th International Colloquium on Automata, Languages and Programming (ICALP 2003), volume 2719 of Lecture Notes in Computer Science, pages 332–344. Springer-Verlag, 2003. [10] R. F. Geary, N. Rahman, R. Raman, and V. Raman.A simple optimal representation for balanced parentheses.In Proceedings of the 15 th Annual Symposium on Combinatorial Pattern Matching (CPM 2004), volume 3109 of Lecture Notes in Computer Science, pages 159–172. Springer-Verlag, 2004. [11] A. Golynski.Optimal lower bounds for rank and select indexes. Theoretical Computer Science, 387(3):348–359, 2007. [12] A. Golynski, J. I. Munro, and S. S. Rao. Rank/select operations on large alphabets: a tool for text indexing. In Proceedings of the 17 th Annual ACM-SIAM Symposium on Discrete Algorithms (SODA 2007), pages 368–373, 2006. [13] R. Grossi, A. Gupta, and J. S. Vitter. High-order entropy-compressed text indexes. In Proceedings of the 14 th Annual ACM-SIAM Symposium on Discrete Algorithms (SODA 2003), pages 841–850, 2003.

Succinct Representation of Bit Vectors Supporting Efficient rank and select Queries 11 [14] R. Grossi and J. S. Vitter. Compressed Suffix Arrays and Suffix Trees with Applications to Text Indexing and String Matching. SIAM Journal on Computing, 35(2):378– 407, 2005. [15] G. Jacobson.Space-efficient static trees and graphs.In Proceedings of the 30 th Annual Symposium on Foundations of Computer Science (FOCS 1989), pages 549–554, 1989. [16] J. Jansson, K. Sadakane, and W.-K. Sung. Ultra-succinct Representation of Ordered Trees. In Proceedings of the 18 th Annual ACM-SIAM Symposium on Discrete Algorithms (SODA 2007), pages 575–584, 2007. [17] H.-I. Lu and C.-C. Yeh. Balanced Parentheses Strike Back. To appear in ACM Transactions on Algorithms, 2008. [18] U. Manber and G. Myers. Suffix arrays: A New Method for On-Line String Searches. SIAM Journal on Computing, 22(5):935–948, October 1993. [19] P. B. Miltersen.Lower bounds on the size of selection and rank indexes.In Proceedings of the 16 th Annual ACM-SIAM Symposium on Discrete Algorithms (SODA 2005), pages 11–12, 2005. [20] J. I. Munro. Tables. In Proceedings of the 16 th Conference on Foundations of Software Technology and Theoretical Computer Science (FSTTCS 1996), volume 1180 of Lecture Notes in Computer Science, pages 37–42. Springer-Verlag, 1996. [21] J. I. Munro, R. Raman, V. Raman, and S. S. Rao. Succinct representations of permutations.In Proceedings of the 30 th International Colloquium on Automata, Languages and Programming (ICALP 2003), volume 2719 of Lecture Notes in Computer Science, pages 345–356. Springer-Verlag, 2003. [22] J. I. Munro and V. Raman. Succinct representation of balanced parentheses and static trees. SIAM Journal on Computing, 31(3):762–776, 2001. [23] J. I. Munro, V. Raman, and S. S. Rao. Space efficient suffix trees. Journal of Algorithms, 39(2):205–222, 2001. [24] J. I. Munro and S. S. Rao. Succinct Representations of Functions. In Proceedings of the 31 st International Colloquium on Automata, Languages and Programming (ICALP 2004), volume 3142 of Lecture Notes in Computer Science, pages 1006– 1015. Springer-Verlag, 2004. [25] D. Okanohara and K. Sadakane. Practical Entropy-Compressed Rank/ Select Dictionary. In Proceedings of the Workshop on Algorithm Engineering and Experiments (ALENEX 2007), 2007. [26] C. K. Poon and W. K. Yiu. Opportunistic Data Structures for Range Queries. In Proceedings of Computing and Combinatorics, 11 th Annual International Conference (COCOON 2005), volume 3595 of Lecture Notes in Computer Science, pages 560– 569. Springer-Verlag, 2005.

12

Jesper Jansson and Kunihiko Sadakane

[27] R. Raman, V. Raman, and S. S. Rao. Succinct dynamic data structures. In Proceedings of Algorithms and Data Structures, 7 th International Workshop (WADS 2001), volume 2125 of Lecture Notes in Computer Science, pages 426–437. Springer-Verlag, 2001. [28] R. Raman, V. Raman, and S. S. Rao.Succinct indexable dictionaries with applications to encoding k-ary trees, prefix sums and multisets. ACM Transactions on Algorithms, 3(4):Article 43, 2007. [29] K. Sadakane. New Text Indexing Functionalities of the Compressed Suffix Arrays. Journal of Algorithms, 48(2):294–313, 2003. [30] K. Sadakane. Compressed Suffix Trees with Full Functionality. Theory of Computing Systems, 41(4):589–607, 2007.

In: Software Engineering and Development Editor: Enrique A. Belini, pp. 13-22

ISBN: 978-1-60692-146-3 © 2009 Nova Science Publishers, Inc.

Expert Commentary B

HETEROGENEITY AS A CORNER STONE OF SOFTWARE DEVELOPMENT IN ROBOTICS Juan-Antonio Fernández-Madrigala, Ana Cruz-Martínb, Cipriano Galindoc and Javier Gonzálezd System Engineering and Automation Department, University of Málaga (Spain)

Abstract In the last years the complexity of robotic applications has raised important problems, particularly in large and/or long-term robotic projects. Software engineering (SE) seems the obvious key for breaking that barrier, providing good maintenance and reusing, coping with exponential growth of programming effort, and integrating diverse components with guarantees. Suprisingly, SE has never been very relevant within the robotic community. In this text we briefly describe some causes for that, review the evolution of robotic software over time, and provide some insights from our most recent contributions. We have found that many problems arising from the conflicts raised by robotic complexity can be well addressed from a SE perspective as long as the focus is, at all levels, on the heterogeneity of components and methodologies. Therefore we propose heterogeneity as one of the corner stones of robotic software at present.

1. Introduction Robots are mechatronic systems [2], therefore they integrate electromechanical devices and software. Although software has usually contributed to robotics with its plasticity when compared to implementations on bared hardware, some of its limits, mostly computational

a

E-mail address: [email protected] E-mail address: [email protected] c E-mail address: [email protected] d E-mail address: [email protected] b

14

Juan-Antonio Fernández-Madrigal, Ana Cruz-Martín, Cipriano Galindo et al.

complexity [19] and its intrinsic nature as a manipulator of pre-existing symbols, have also limited the finding of practical solutions to some robotic problems+. In the last decades, a new limit of robotic software has been more and more evident when robotic projects have become large (for example, the development of complete robot architectures [18] or multirrobot systems [3]) and/or long-term. This kind of projects necessarily have to cope with the integration of very diverse components, ontologies, and methods in a guaranteed, maintainable and extensible way. It is clear at present that, under those requirements, sophisticated software methodologies are unavoidable for breaking the barrier of complexity without sacrificing robotic dependability. In particular, software engineering (SE) seems the obvious key for helping in these issues, namely by providing good maintainance and reusing and integrating with guarantees components that are diverse. Suprisingly, SE has never been considered very relevant within the robotics community, as demonstrated by the lack of specialized journals in the area and the reduced number of workshops on SE organized by robotics people. A few reasons could be: the small scale of most robotic applications until more or less one decade ago, the strongly reductionist methodology used in typical robotic problems, and, in cases, the improper belief that SE has nothing to do with "pure" robotics. Only a few research groups within robotics have proposed a number of tools more or less inspired in SE methodologies during the last twenty years (see section 2). These tools have set the basis for a deeper knowledge of the limits and characteristics of robotic software, but they have not formed yet a consistent solution that covers all aspects of such software. Recently, we have proposed a characteristic that serves to differentiate robotic software: heterogeneity ([10], [12], [13]). We have found that many problems arising from the conflicts between robotic complexity and dependability can be well addressed from a SE perspective as long as heterogeneity is included, as a core feature, at all levels of development, instead of forcing the use of a common solution and set of methodologies. Therefore, we have constructed a minimalistic framework for covering the main stages of heterogeneous software development: design, implementation, validation, debugging, and maintenance. This framework, called BABEL, has demonstrated that allowing a high level of heterogeneity at all the levels of development facilitates the achievement of modern robotic goals. In the following we explore the evolution of robotic software (section 2) and show, through BABEL, the role of heterogeneity as one of the corner stones of robotic software (sections 3 and 4). Since particular and detailed examples and results have been reported elsewhere during the last years, we focus here on the essential aspects of our approach.

2. The Main Stages in the Evolution of Robotic Software As the robotics realm itself, robotic software has continually evolved, running in parallel to the hardware and software technologies available at the moment. For summarizing the main trends, we identify here three different stages in time, each of them characterized by a particular software issue that received certain effort from the robotics research community in order to solve the robotic problems at the time. Nevertheless, these stages should be + For instance, efficient solutions to the Simultaneous Localization and Mapping problem suffer from software complexity [17]. Also, the autonomous acquisition of symbols from sub-symbolic information [8] is still an open issue.

Heterogeneity as a Corner Stone of Software Development in Robotics

15

understood as a convenient discretization of a continuous process; thus it is not rare that the works mentioned here can be considered to belong to more than one. The first stage we can set in the evolution of robotic software, that we could call raw robotic programming, covered from the lately sixties until the late eighties of the XX century. In that period robotics programming was limited to solutions based on direct hardware implementation of algorithms [4] or ad-hoc programming of concrete hardware platforms [23], [32]. Most of the development of programming languages for robots was focused during that period on industrial manipulators [25], although those languages were of a very low level (close to assembler). In a second stage, that we could call middleware robotic programming and extended around the early nineties of the XX century, the goal for the robotic software developers shifted to provide pre-defined software platforms to control the physical devices of the robot (actuators and sensors); in spite of this software being tightly coupled to specific hardware, it alleviated the, until the moment, heavy task of programming complex robots. In this period, some robotic software was in fact real-time operative systems, like ALBATROSS [36], Harmony [20], or Chimera II [33]. But this stage do not stopped there: these platforms led to the ability of a more complex processing, and, accordingly, the notion of robotic control architecture (a set of software elements or modules that worked together in order to achieve a robotic task) also received attention by the robotics community+. So, the first years of that 90's decade also offered interesting architectures like TCA [29] or NASREM [1]. Since then, architecture solutions were continuously released to the robotics arena: e.g., new robotics fields (for example, multirobots) demanded their own architectural approaches ([24]). Finally, we can distinguish a last stage of robotics software that embraced from the mid nineties to present and can be called robotics software engineering. The key point at this stage is that some SE aspects are considered when programming robots, mainly due to the still increasing complexity of robotic applications. Now, the goal is not to produce a closed or static architecture, but a framework that allows the developer to produce the architectural solution he/she may need in his/her particular situation∗. Examples of free, commercial, and/or academical frameworks are ORCCADD [30], Cimetrix's CODE [7], RTI's ControlShell [28], GeNoM [16], NEXUS [9] (a previous instance of our current BABEL development system), OSACA [31], OROCOS [35], Player/Stage [26], CARMEN [37], MARIE [38], RobotFlow [25], CLARAty [13], or Microsoft Robotics Studio [22]. Different SE concepts -like object-oriented programming, software lifecycle, software validation, reusability, CASE tools, or automatic code generation- are being progressively included into these frameworks. However, not all of these focus on SE in the same manner or intensity. In particular, it is very common that they are not able to deal with heterogeneity in a desirable way, which is our aim with BABEL.

+ Notice that a robot software architecture can be conceptually seen nowadays as a robotic middleware. ∗ For more details on the current state of the art of robotic software, you can consult [5].

16

Juan-Antonio Fernández-Madrigal, Ana Cruz-Martín, Cipriano Galindo et al.

3. Towards a Heterogeneity-Based Robotic Software Development System Currently, large and/or long-term robotic projects involve many different researchers with very different programming needs and areas of research, using a variety of hardware and software that must be integrated efficiently (i.e., with a low development cost) in order to construct applications that satisfy not only classic robotic requirements (fault-tolerance, realtime specifications, intensive access to hardware, etc.) but also software engineering aspects (reusability, maintainability, etc.). This indicates three main sources of heterogeneity: hardware, software, and methodological. They appear with different strength at each stage of the robotic application lifecycle: analysis, design, verification, implementation, validation, debugging, maintainance... Our aim with the identification and inclusion of heterogeneity as one of the pervasive features of robotic applications is to set the basis for a comprehensive software development framework, in the sense that it covers all the stages of the robotic software lifecycle. Up to now, we have reported, in the context of our BABEL development system, tools and methodologies for stages that are present in the most common models for software development (Waterfall, Iterative, etc. [27]), which are described in the following.

3.1. Robotic Software Design Software design consists of finding a conceptual solution to a given problem in terms of software components and methodologies. From the heterogeneity perspective, the design of a robotic application should be the foundation for integrating diverse elements while guaranteeing certain requirements (produced by a previous stage of analysis, not covered here). The problem in robotic systems is that there is no wide standardization for components, and thus, forcing the use of one standard or of some unique framework is difficult to achieve. Our philosophy is the opposite to that: we consider heterogeneity in components as a core feature of the design framework, that is to be preserved. Thus, we maintain the framework to a minimum, stablishing the smallest structural and behavioral ontologies of design that allow us to express the most important requirements in a robotic application without sacrificing diversity. BABEL provides a heterogeneity-based specification for the design of robotic applications, currently called Aracne. Aracne is based on three design ontologies: structural, behavioral, and the structural-behavioral link. Each of these contains a minimalistic set of specifications where most of the heterogeneity present in a complex robotic application can fit. Recently, Aracne is being extended as a specification language, called H [12]. The main features of Aracne/H are: ¾ Clear identification of both the software components that are portable and those that are tied to some platform. The former have a low “heterogeneity level”, while the latter comprise most of the heterogeneity present in the application. ¾ The structural ontology is based on active objects or components [34], called modules, that provide certain services to other modules and maintain an internal

Heterogeneity as a Corner Stone of Software Development in Robotics

¾

¾

¾

¾

¾

17

status. This ontology is different from the one of the object oriented paradigm, since ours includes execution and intercommunication models explicitly (concurrency, synchronization, client-server/subscriber-publisher behavior, etc.). The inclusion of an execution model into the structural ontology links it with the behavioral ontology, where the logic of services is specified. Aracne/H permits us to design the logic (code) of the modules in different programming languages or visual methodologies, in a way that isolates and highlights heterogeneity. The structural-behavioral link makes up a complete design for the application. We currently include in the ontology for this link basic fault-tolerance mechanisms in the form of software replication [21]. The three ontologies of Aracne/H include the explicit specification of the most important robotic requirements, namely: hardware dependencies, real-time, and faulttolerance. Aracne/H allows us to design, with the same specification, both distributed and nonnetworked applications, hard, soft, and mixed real-time systems, modules with different programming paradigms, etc. Finally, due to its intrinsic minimalistic nature, the specification is open to cope with most off-the-shelf components and with their evolution in time, important concerns in the component-based software engineering field (CBSE) [34].

Currently we have a visual designing tool, called the Module Designer, that implements the Aracne specification and allows us to make up the design of the application easily, integrating different programming languages and platforms. We have developed a number of robotic applications over the last decade using Aracne (see for example [14], [15], [13], [12]), obtaining important benefits, as summarized in section 4.

3.2. Robotic Software Implementation One of the most relevant differences of BABEL with respect to other approaches is that it considers into the design all the elements of the application, which includes behavior, i.e., code. That allows us to develop tools for generating implementations almost directly from the design. The Module Designer of the BABEL development system is a CASE tool that not only facilitates the heterogeneous design, but is also able to transform automatically that design into an implementation, which can be supported by heterogeneous execution platforms. Its main features are: ¾ It provides a user-friendly integrated development environment for visually designing modules according to the Aracne/H specification, specifying their public interfaces, services, codifications and dependencies. ¾ The tool automatically generates the software for converting that design into a complete executable program and for the integration of this program into a (possibly distributed) robotic application composed of other modules.

18

Juan-Antonio Fernández-Madrigal, Ana Cruz-Martín, Cipriano Galindo et al. ¾ It includes the possibility of generating implementations for a given set of particular platforms, and is extensible to platforms not covered yet. Examples of the platforms and languages supported is reported elsewhere [13].

The Module Designer also includes logging and debugging facilities that can be placed at critical paths in the logic (code) of modules. This links the implementation to the verification and validation stages.

3.3. Robotic Software Verification and Validation The goal of software verification is to guarantee that a given design/implementation satisfies all its requirements. In a design made with the Aracne specification it is easy to check a number of possible pitfalls during design and also conflicts between dependencies during implementation, independently on the highly heterogeneous nature of the components that integrate the application. This includes: ¾ Checking the possibility of satisfying the real-time requirements of the different components (currently simplified to WCETs -Worse-Case Execution Times-). ¾ Checking if all the platforms needed for the satisfaction of the requirements are present in the deployment (otherwise, the Module Designer adapts the implementation for reduced requirement satisfaction). ¾ Checking for some limited kinds of dependency cycles that could end in deadlocks. ¾ Also, the information present in the design is enough to carry out scheduling analysis when the application needs hard real-time. On the other hand, the goal of software validation is to check if a given design/implementation satisfies the intended application in practice. A debugger tool is included in BABEL that retrieves execution information for carrying out off-line analysis of the real-time performance for the cases where that information reflects robotic goals (for example, in navigation modules that need to react to the environment at predefined times). Sometimes, this tool also serves for verification, discovering errors or faults in programming.

3.4. Robotic Software Maintenance Large and/or long-term robotic projects cannot be carried out efficiently without software bootstrapping, that is, without reusing. However, it is quite evident the still present trend in robotics of repeating the same programming effort time after time for different platforms or control architectures. As long as this way of working is used, the development of complex robotic application will be severely handicapped. The Aracne design specification, and in particular its most recent extension H, is aimed to reusing by including some characteristics of the object-oriented paradigm. For instance, in H inheritance has been appropriately adapted to the heterogeneity of the design: the structural

Heterogeneity as a Corner Stone of Software Development in Robotics

19

design of a module can be separately inherited from the behavioral design, allowing us to maintain a repository of logical interfaces and a set of behavioral logics (code) that fit into them. In summary, inheritance allows us to specialize previous developments to new necessities, while the separation between the structural and the codification design isolates the changes that have to be made due to evolution of hardware or software. For coping with the important amount of information that this approach generates (which must be appropriately stored in any large robotic project), BABEL also includes a tool for maintenance. This tool is a web site under development [11] that holds all the designs produced up to now, classified through a simple versioning system, and accessable by the members of our group and their collaborators, since the data held there belongs to particular research projects. Nevertheless, some of the modules and results, and all the documentation and the most tested configuration of BABEL, are freely available from the site.

4. Results, Conclusions, and Future Work Along this text we have set one of the most important characteristics of robotic software, that differentiates it from other kinds of software applications: heterogeneity. This heterogeneity is to be understood as a pervasive characteristic: every stage and every level of detail in the development of a robotic application should deal appropriately with diverse components and methodologies. Based on this idea we have described our approach to the treatment of heterogeneity from a software engineering perspective. Our solution is a minimalistic software development system, called BABEL, that is aimed to cover the most important stages of the robotic software lifecycle. We have used BABEL for our robotic projects during the last decade. The benefits have been evident: ¾ It has made possible to break the complexity barrier in current robotic applications, mainly by enforcing the reuse of software and eliminating the completely reprogramming of algorithms for each new platform. ¾ It has allowed us to guarantee the most relevant requirements of robotics applications, mostly regarding dependability. ¾ The time effort dedicated to robotic programming has been, in general, transformed from exponential into linear [13]. ¾ BABEL has allowed us to develop very different research projects with very different requirements, hardware components (we have a number of different robots in our laboratories), and software (operating systems, libraries, etc.), without slowing down the development due to component evolvement and diversity. ¾ Our system has enabled the integration of people with very different skills into interdisciplinary groups of research (from under-graduate students to professors). Part of the effort that was not spent in re-programming existing applications for new robots is now devoted to maintaining the BABEL system. Thus, we are working in including new hardware and software components as we acquire new equipment, and also in adjusting in a continuous basis the ontologies of the Aracne/H specification to cover the most diversity we can while maintaining them as minimalistic as possible.

20

Juan-Antonio Fernández-Madrigal, Ana Cruz-Martín, Cipriano Galindo et al.

However, this kind of effort has important drawbacks for us as robotic researchers. In an interesting article, Bruyninckx [6] mentions some of them: ¾ The small interest that a good software practice has for the robotics researcher, since it cannot be translated into citation index or other tangible results. ¾ Fundings are currently more centered on fundamental research, and not in middleware projects that, though do not offer new or original results, are the basis for a well-supported robotics research in the long term. ¾ Robotics experts are often not really interested in those advances that software engineering could offer to the developers of robotic software. From an optimistic point of view, it is clear that the interest on software engineering in robotics is increasing in the last years. Although there is much work to do to consolidate this trend, just the unavoidable necessity of breaking the complexity barrier in software development in order to build the robotic applications of the present and future should be enough for changing the robotic software status within the community.

References [1] Albus J.S., Quintero R., Lumia R. “An overview of Nasrem - The NASA/NBS standard reference model for telerobot control system architecture”. NISTIR 5412, National Institute of Standards and Technology, Gaithersburg, Md.. 1994. [2] Appukutam K.K., “Introduction to Mechatronics”, Oxford University Press, ISBN 9780195687811, 2007. [3] Balch T., Parker L.E. (eds), “Robot Teams: from Diversity to Polymorphism”, AK Peters, ISBN 1-56881-155-1, 2002. [4] Brooks R.A. “A Robust Layered Control System for a Mobile Robot”. IEEE Journal of Robotics and Automation, Vol. RA-2, no. 1. 1986. [5] Brugali D. “Software Engineering for Experimental Robotics”. Springer – STAR. 2007. [6] Bruyninckx, H. “Robotics Software: The Future Should Be Open”. IEEE Robotics and Automation Magazine, March 2008, pp. 9-11. 2008. [7] Cimetrix CODE. http://www.cimetrix.com/code.cfm. 2008. [8] Coradeshi S., Saffiotti A., “An Introduction to the Anchoring Problem”, Robotics and Autonomous Systems, vol. 43, no. 2-3, pp. 85-96, 2003. [9] Fernández J.A., González J. “The NEXUS Open System for Integrating Robotic Software”. Robotics and Computer-Integrated Manufacturing, Vol. 15(6). 1999. [10] Fernández-Madrigal J.A. Galindo C., González J., “Integrating Heterogeneous Robotic Software”, 13th IEEE Mediterranean Electrotechnical Conference (MELECON), Benalmádena-Málaga (Spain), May 16-19, 2006 [11] Fernández-Madrigal J.A., Cruz-Martín E., “The BABEL Development Site”, http://babel.isa.uma.es/babel2, 2008. [12] Fernández-Madrigal J.A., Galindo C., Cruz A., González J., “A Software Framework for Coping with Heterogeneity in the Shop-Floor”, Assembly Automation no. 4, vol. 27, pp. 333-342, ISSN 0144-5154, 2007.

Heterogeneity as a Corner Stone of Software Development in Robotics

21

[13] Fernández-Madrigal J.A., Galindo C., González J., Cruz E., and Cruz A., ”A Software Engineering Approach for the Development of Heterogeneous Robotic Applications”, Robotics and Computer-Integrated Manufacturing, vol. 24, no. 1, pp. 150-166, ISSN 0736-5845, 2008. [14] Fernández-Madrigal J.A., González J., “A Visual Tool for Robot Programming”, 15th IFAC World Congress on Automatic Control, Barcelona, Spain, July 2002. [15] Fernández-Madrigal J.A., González J., “NEXUS: A Flexible, Efficient and Robust Framework for Integrating the Software Components of a Robotic System”, IEEE International Conference on Robotics and Automation (ICRA'98), Leuven, Belgium, May 1998 [16] Fleury S., Herrb M., Chatila R. “GenoM: A Tool for the Specification and the Implementation of Operating Modules in a Distributed Robot Architecture”. Proceedings of the IEEE/RSJ International Conference on Intelligent Robots and Systems (IROS'97). 1997. [17] Fresse U., Larsson U., Duckett T., “A Multilevel Relaxation Algorithm for Simultaneous Localization and Mapping”, IEEE Transactions on Robotics, vol. 21, no. 2, pp. 196-207, 2005. [18] Galindo C., González J., Fernández-Madrigal J.A., “Control Architecture for HumanRobot Integration. Application to a Robotic Wheelchair”, IEEE Transactions on Systems, Man, and Cybernetics part B, vol. 36, no. 5, pp. 1053-1067, 2006. [19] Garey M.R., Johnson D.S., “Computers and Intractability: A Guide to the Theory of NPCompleteness”, Freeman (ed.), ISBN 978-0716710455, 1979. [20] Gentleman W.M., MacKay S.A., Stewart D.A., Wein M. “An Introduction to the Harmony Realtime Operating System”. Newsletter of the IEEE Computer Society Technical Committee on Operating Systems. 1988. [21] Guerraoui R., Schiper A., “Software-Based Replication for Fault Tolerance”, IEEE Computer. Vol. 30, no. 4., 1994 [22] Microsoft Robotics Studio. http://msdn.microsoft.com/en-us/robotics/default.aspx. 2008. [23] Mitchell T.M. “Becoming Increasingly Reactive”. Proceedings of the AAAI Conference. 1990. [24] Parker L.E. “ALLIANCE: An Architecture for Fault Tolerant Multi-Robot Cooperation”. IEEE Transactions on Robotics and Automation, 14 (2). 1998. [25] Paul R.P., “Robot Manipulators: Mathematics, Programming and Control”, MIT Press, ISBN 0-262-16082-X,1981. [26] Player Project. http://playerstage.sourceforge.net/. 2008. [27] Pressman R.S., “Software Engineering. A Practitioner's Approach”, 6th edition, McGraw-Hill, ISBN 978-0073019338, 2004. [28] Schneider S.A., Ullman M.A., Chen V.W. “ControlShell: a real-time software framework”. IEEE International Conference on Systems Engineering. 1991. [29] Simmons R., Lin L.-J., Fedor C. “Autonomous Task Control for Mobile Robots (TCA)”. Fifth IEEE International Symposium on Intelligent Control. 1990. [30] Simon D., Espiau B., Castillo E., Kapellos K. “Computer-Aided Design of a Generic Robot Controller Handling Reactivity and Real-Time Control Issues”. Rapports de Recherce nº 1801, Programme 4: Robotique, Image et Vision, INRIA. 1992. [31] Sperling W., Lutz P. “Enabling Open Control Systems – An Introduction to the OSACA System Platform”. Robotics and Manufacturing, Vol. 6, ASME Press New York. 1996.

22

Juan-Antonio Fernández-Madrigal, Ana Cruz-Martín, Cipriano Galindo et al.

[32] SRI: Shakey the Robot. http://www.sri.com/about/timeline/shakey.html. 2008. [33] Stewart D.B., Schmitz D.E., Khosla P.K. “The Chimera II Real-Time Operating System for Advanced Sensor-Based Control Applications”. IEEE Transactions on Systems, Man and Cybernetics, vol. 22, no. 6, Nov/Dec. 1992. [34] Szyperski C., Gruntz D., Murer S., “Component Software: Beyond Object-Oriented Programming”. Boston, Ma., 2nd edition, Addison-Wesley, ISBN 0201745720, 2002. [35] The Orocos Project. http://www.orocos.org/. 2008. [36] Von Puttkamer E., Zimmer U.R. “ALBATROSS: An Operating-System under RealtimeConstraints”. Real-Time magazine, Diepenbemmd 5 – 1650 Beersel – Belgium, Vol. 5, no. 3, 91/3. 1991. [37] http://carmen.sourceforge.net, 2007 [38] http://marie.sourceforge.net, 2007 [39] http://robotflow.sourceforge.net, 2005 [40] http://claraty.jpl.nasa.gov, 2008

SHORT COMMUNICATIONS

In: Software Engineering and Development Editor: Enrique A. Belini, pp. 25-35

ISBN: 978-1-60692-146-3 © 2009 Nova Science Publishers, Inc.

Short Communication A

EMBEDDING DOMAIN-SPECIFIC LANGUAGES IN GENERAL-PURPOSE PROGRAMMING LANGUAGES Zoltán Ádám Mann AAM Consulting Ltd.; Budapest University of Technology and Economics

Abstract In recent years, domain-specific languages have been proposed for modelling applications on a high level of abstraction. Although the usage of domain-specific languages offers clear advantages, their design is a highly complex task. Moreover, developing a compiler or interpreter for these languages that can fulfil the requirements of industrial application is hard. Existing tools for the generation of compilers or interpreters for domain-specific languages are still in an early stage and not yet appropriate for the usage in an industrial setting. This paper presents a pragmatic way for designing and using domain-specific languages. In this approach, the domain-specific language is defined on the basis of a general-purpose programming language. Thus, general programming mechanisms such as arithmetics, string manipulations, basic data structures etc. are automatically available in the domain-specific language. Additionally, the designer of the domain-specific language can define further domain-specific constructs, both data types and operations. These are defined without breaching the syntax of the underlying general-purpose language. Finally, a library has to be created which provides the implementation of the necessary domain-specific data types and operations. This way, there is no need to create a compiler for the new language, because a program written in the domain-specific language can be compiled directly with a compiler for the underlying general-purpose programming language. Therefore, this approach leverages the advantages of domain-specific languages while minimizing the effort necessary for the design and implementation of such a language. The practical applicability of this methodology is demonstrated on a case study, in which test cases for testing electronic control units are developed. The test cases are written in a new domain-specific language, which in turn is defined on the basis of Java. The pros and cons of the presented approach are examined in detail on the basis of this case study. In particular, it is shown how the presented methodology automatically leads to a clean software architecture.

26

Zoltán Ádám Mann

1. Introduction In the last decades, the requirements toward software have become tougher and tougher. The complexity of the problems that are solved by software is growing, while at the same time the expectations concerning numerous other, non-functional, aspects (for instance, maintainability, usability, fault-tolerance, parallelism, throughput etc.) have also increased significantly. Moreover, in today’s highly competitive software market, it is crucial to minimize time-to-market for software, to be able to quickly add fixes or new features to products. Since the human brain has not evolved significantly in this time, the only way to create more complex software more quickly is to raise the level of abstraction for software development. Just imagine how it would be to develop software that should fulfil today’s requirements, if you had to keep in mind which piece of data is in which register of the processor! In order to cope with increasing complexity, the profession moved from machine code to assembler, from assembler to high-level programming languages, then to object orientation, to component orientation etc. Today, we think in terms of high-level programming abstractions, such as components, threads, GUI elements etc., and not in terms of what the hardware can offer (registers, memory addresses, interrupts). Despite all this development, the requirements are still ahead of what we can deliver safely with our current software development practices. So, what will be the next quantum leap in increasing the level of abstraction? Many researchers agree that the destination of this journey will be some kind of model orientation [6]. Software development will mean creating an abstract, logical model of what the software is supposed to do, without technical details on how it will fulfil those aims. As formulated by Brooks in his seminal paper “No silver bullet,” the essence of software development is the construction of abstract, conceptual structures; the difficulties arising from the representation of these structures within the framework of a programming language are just accidental and are decreasing with scientific progress [1]. There are some debates in the research community on what the future model oriented software development process will look like∗: •

•

One possibility is to define a universal modelling language that can be used for the development of any software application. Most notably, the Object Management Group (OMG) follows this path with the Unified Modelling Language (UML) [12]. In contrast, others argue that modelling at a really high level of abstraction is only possible with domain-specific concepts, which can be best accomplished by a domain-specific language (DSL). In recent years, this latter approach has gained tremendously in popularity [2] and is also the topic of this paper. More on DSLs can be found in Section 0. Another question is how to bridge the gap between the abstract model and the real features of the available platform. Two main approaches can be distinguished, similar to compiled vs. interpreted programming languages. The first approach

∗ Also, there are minor differences in the terminology, e.g. model-based vs. model-driven vs. model-oriented.

Embedding Domain-Specific Languages…

•

27

consists of generating (possibly in more than one step) program code from the model, after which the code can be executed using traditional mechanisms. For instance, the OMG’s Model-Driven Architecture (MDA) paradigm falls into this category [11]. The other approach consists of executing the model itself with a suitable model interpreter. As an example, the Executable UML (xUML) approach belongs to this category [9]. When hearing the word ‘model,’ one tends to think of a graphical representation, like an UML model. However, graphical modelling has its limitations. Not only is a graphical representation less appropriate for machine processing, but also for the human reader, it is quite hard to understand hundreds (or more) of pages of graphical models. Usually, a textual model is more concise and can therefore scale better in model size when readability is concerned. Thus, textual modelling languages became more popular in recent years [5].

In the rest of the paper, textual domain-specific languages are considered. The issue of generating code from the model vs. interpreting the model itself will be discussed in more detail.

1.1. Paper Organization The rest of the paper is organized as follows. In Section 0, the concept of DSLs is described in more detail, with special emphasis on the challenges associated with the development of a DSL. Section 0 contains a case study, introducing the domain of testing electronic control units. In this domain, there is a need for a DSL for the specification of test cases. Section 0 describes the proposed pragmatic way of defining a DSL based on a generalpurpose language in principle, followed by the second part of the case study in Section 0, in which the practical applicability of the proposed approach is presented for specifying test cases for electronic control units. Section 0 contains a discussion of the lessons learned in the application of the proposed methodology, while Section 0 concludes the paper.

2. DSLs 2.1. General Properties of DSLs A DSL is a language for the description of programs, or of models of programs∗, on a specific field of application (called a domain). Since the language is tailored to one domain, complex constructs and abstractions of the domain can be supported directly by the language. A number of benefits are expected from this clear focus on one domain, such as: • •

Concise representation of complex issues; Gain in productivity;

∗ From a theoretical point of view, the distinction between a program and a model of the program is artificial, since a model can be defined as an abstract representation of a system, and thus the program itself can also be regarded as a model.

28

Zoltán Ádám Mann • • •

Improved maintainability; Better communication between IT and functional departments; Efficient development of variants and of software product lines.

The idea of domain-specific languages is not new. There are several languages that are already widely used and can be regarded as a DSL, for instance: • • • •

SQL (Structured Query Language) for the definition of database queries and manipulations; XSLT (eXtensible Stylesheet Language Transformation) for the definition of transformations between XML (eXtensible Markup Language) files; sed scripts for string manipulations; make scripts for directing the software build process.

As can be seen from this list, these widely used DSLs are usually tailored to a technical domain. For functional∗ domains, the idea of DSLs can also be leveraged; however, by the nature of functional domains, these languages are usually known and used only by a limited set of experts. Examples include: • • • •

CPL (Call Processing Language) for the definition of Internet telephony services; BPMN (Business Process Modeling Notation) for the definition of business processes; OWL (Web Ontology Language) for the definition of ontologies for the Semantic Web; VoiceXML for the definition of interactive voice dialogues between a human and a computer.

2.2. Creating DSLs Developing a DSL and the supporting tool chain is a time-consuming process requiring much care and deep expertise [10]. The process can be divided into five phases: decision, analysis, design, implementation, and deployment [5]. Out of these, especially challenging are the analysis phase and the implementation phase. In the analysis phase, the constructs of the domain that should be integrated into the language have to be identified and formalized. Although there are several methodologies for this kind of domain engineering, this phase is definitely time-consuming and requires special expertise. In the implementation phase, the necessary tool chain must be developed for the language: editor, compiler / interpreter, debugger, profiler etc. Parts of this can be automated ∗ In this context, the distinction between technical and functional is as follows. Functional issues are those intrinsic properties of the system which result directly from the end user’s functional requirements. In contrast, technical issues are related to the implementation of the system with a specific technology. Accordingly, a technical domain is relevant for the IT expert, whereas a functional domain may also be relevant to the end user.

Embedding Domain-Specific Languages…

29

(e.g., parser generation), and there are also language workbenches [3] for facilitating the whole process (e.g., Eclipse Modeling Framework, Microsoft Visual Studio DSL Tools). However, not all the steps can be fully automated, so that creating efficient tools for a nontrivial DSL remains a difficult process with a lot of manual work. In particular, developing a compiler or interpreter for the language that can fulfil the requirements of industrial application is hard.

3. Case Study – Part 1 As a case study for a domain-specific language, the domain of testing electronic control units (ECUs) in vehicles is considered. An ECU is an embedded computer system with a specific control function within a bigger mechatronic system. For instance, a high-end car contains nowadays up to 80 ECUs (e.g., ABS, tuner, night vision camera control, airbag control etc.). The ECUs within a car are interconnected so that they can exchange messages. For the interconnection of ECUs several bus technologies are in use, from which two are the most common ones: Controller Area Network (CAN) and Media Oriented System Transport (MOST). CAN supports the transmission of 8-byte messages with a data rate of up to 500 kilobit/sec and a non-negligible error rate. MOST is a more expensive technology, supporting the safe transmission of messages of up to 4 kilobyte in length and a data rate of up to 23 megabit/sec. Moreover, the two technologies differ significantly in their addressing scheme. Car manufacturers spend huge amounts of resources with testing whether every ECU obeys its specification in every possible combination and under all imaginable circumstances. Testing ECUs has several flavours and there are several methodologies. In this paper, we will focus on the testing of generic system functions (e.g. power management, security, personalization) that have to be implemented in every ECU according to the same logical specification, but with different technical details, e.g. depending on the bus technology used by the ECU (CAN/MOST) [4]. It should also be noted that, in order to find errors in the earliest possible stage, these generic system functions are usually first implemented and tested in the form of a software simulation on a PC. The testing of these functions basically consists of sending different sequences of messages to them and comparing the replies from the ECU with the expected behaviour (whether there was a reply at all; whether timing requirements were met; whether the data in the reply were as expected etc.). Now the challenge is the following. The test cases for testing (a) the PC simulation of the function; (b) the implementation of the function in a CAN ECU; (c) the implementation of the function in a MOST ECU are almost the same at the logical level. However, at the level of the communication technology, the three cases are quite different. The aim is to define the test cases only once, at a sufficiently high level of abstraction, and use them in all three cases (see Figure 1). Thus, the goal is to define a DSL with the following main concepts: • • •

Sending of messages with defined content to the System Under Test (SUT); Waiting for messages from the SUT with given timing constraints; Comparing the contents of a received message with a predefined pattern.

30

Zoltán Ádám Mann Simulation

simulated ECUs

execution for

Model of testcase Testcase Testcase execution for CAN CAN ECU execution for MOST

MOST ECU

Simulated boardnet

Figure 1. The same logical test cases should be executed for different ECU implementations.

The DSL should be free of any references to the specific communication technology; however, it should be possible to run the test cases without modification on any of the supported technology platforms. The resulting DSL is described in Section 0.

4. A Pragmatic Approach to DSL Development In light of the challenges associated with the development of a DSL (see Section 0), we suggest that DSLs should be developed from scratch only if (a) there are some specific requirements concerning the tool chain that are otherwise hard to fulfil (e.g., hard requirements concerning performance may require a very specific optimizing compiler) and (b) the foreseen wide-spread usage of the DSL justifies the efforts. Otherwise, we propose using a pragmatic approach in order to leverage the benefits of DSLs even in projects with very limited budget, as follows. The DSL should be defined on the basis of an existing general-purpose programming language (GPL). Thus, general mechanisms such as arithmetics, string manipulations, basic data structures etc. are automatically available in the DSL. Additionally, the designer of the DSL will of course define further, domain-specific, constructs. These can be categorized as data types and operations. Both can be defined without breaching the syntax of the underlying GPL, as data types and operations in the GPL. Finally, a library has to be created which provides implementation in the GPL for the defined domain-specific data types and operations. In other words: the DSL is nothing but a GPL enriched with domain-specific data types and operations, which are defined in the GPL themselves. A program written in the DSL is thus at the same time also a program in the GPL. The representation of the DSL within the GPL is possible, because there are so many degrees of freedom in the design of the DSL. Usually, the requirements concerning the future

Embedding Domain-Specific Languages…

31

DSL are very high-level: what kinds of domain constructs should be available in the language and what kinds of operations should be possible on these constructs (see for instance the requirements formulated in Section 0 in connection with the DSL for ECU test case specification). There are usually no strict constraints on the syntax of the language, so any logical, readable, and coherent syntax can be used. Thus, the syntax of a GPL is usually applicable. This approach has several major advantages. First of all, since a program in the DSL is at the same time also a program in the GPL, the whole tool chain of the GPL can be used for programs written in the DSL. This way, the efforts involved in the creation of the DSL are drastically reduced. Moreover, it is safe to assume that the tool chain of a GPL is significantly more mature – concerning comprehensiveness, correctness, documentation, etc. – than the tools that would be created for the sake of the DSL. Furthermore, many useful features of the DSL can simply be inherited from the GPL “free of charge,” such as macros, inheritance, etc. – features that you might not bother to include in the language if developed from scratch. Of course, this approach also has some limitations. If, for some reason, there are very specific requirements concerning the syntax of the DSL that cannot be found in any available GPL, then this approach cannot be applied. Also, this approach does not yield a clear separation between code and model, which can be a problem if some team members are supposed to work on the model only. In any case, since the presented approach allows for the quick and easy construction of DSLs, it can be used as a rapid prototyping methodology. Suppose for instance that for a given domain DSL1 is created using the above methodology. The language can be tried in practice and fine-tuned based on the experience in an early stage of the design. Afterwards, a second language DSL2 can be created which is semantically equivalent to DSL1, but its syntax is closer to the logical syntax of the domain instead of the syntax of the GPL. Then, only a DSL2-to-DSL1 compiler must be created, in order to have a full-fledged DSL (namely, DSL2) with moderate efforts.

5. Case Study – Part 2 We have applied the presented approach to the ECU test case specification domain presented in Section 0. That is, we developed a DSL for the black-box testing of ECUs, based on Java as the underlying GPL.

5.1. Design of the DSL The building blocks of test cases consist of the sending of messages to the ECU and the waiting for the reply from the ECU. The most common scenario is that the test case sends a message to the ECU and expects a reply in a given time frame. Such a building block can have a variety of parameters, such as: • • •

The message that should be sent to the ECU; Criteria for the acceptance of the reply (e.g. bit 12 must be 0 in the reply); Minimum and maximum reply time.

32

Zoltán Ádám Mann

There are other, similar building blocks. For instance, it is possible to specify that, after having sent a given message to the ECU, no reply must arrive within a given time frame. From such building blocks, complex test cases can be compiled, as shown in Figure 2. //Inquiry + 1st reply messageToSend=new MessageInquiry(TEST_ID); idOfExpectedReply=TEST_ID; minimalWaitTime=0; maximalWaitTime=100; sendMessageAndWaitForReply(); //2nd reply minimalWaitTime=175; maximalWaitTime=225; waitForReply(); //3rd reply waitForReply(); //wait one more period; no further reply should arrive waitNoReply();

Figure 2. Example test case.

This test case tests that an inquiry sent to the ECU results in exactly 3 replies, from which the first one must arrive within 100 milliseconds after sending the inquiry and the next two with a gap of approximately 200 milliseconds between them. The grammar of the DSL is specified in EBNF notation in Figure 3. := * := <param-spec> := <param-spec-opt> <param-spec> := + <min-time-spec> <max-time-spec> <param-spec-opt> := ? * <min-time-spec>? <max-time-spec>? := "messageToSend=new MessageInquiry(" ");" := | … := "idOfExpectedReply=" ";" | … <min-time-spec> := "minimalWaitTime=" ";" <max-time-spec> := "maximalWaitTime=" ";" := "sendMessageAndWaitForReply();" | "sendMessageNoReply();" | "waitForReply();" | "waitNoReply();"

Figure 3. Grammar of the DSL for ECU testing.

Embedding Domain-Specific Languages…

33

5.2. Implementation of the DSL The domain-specific constructs of the language – the attributes minimalWaitTime, messageToSend etc. as well as the operations waitForReply() etc. – are specified in an abstract Java class called ECUTest. All test cases are Java classes that inherit from this abstract class, so that these attributes and operations can be used in all the test cases (see Figure 4). Of course, the exact behaviour of these operations depends on the used technology (calling Java routines vs. using CAN messages vs. using MOST messages). Hence, the operations in the class ECUTest do nothing but delegate the work to an adapter. The class ClientTest can be parameterized with different adapters according to the used technology. All details concerning the technology are encapsulated in the relevant adapter. The test cases themselves are free of any technology-related details. The domain-specific language constructs are defined in the parent class.

Simulation ECUTest

AdapterCan CAN ECU

Test1

Testn

AdapterMost

AdapterJava

MOST ECU

Simulated boardnet

Figure 4. Embedding the DSL into Java via inheritance.

This way, the challenge described in Section 0 is met: the test cases are specified at a logical level, only once, but can be used without any modifications with the different technologies.

6. Discussion Based on the presented case study, two issues are discussed: • •

The consequences of using an underlying GPL on the DSL; The resulting software architecture.

34

Zoltán Ádám Mann

6.1. Consequences on the Language As can be seen from Figure 2 and Figure 3, the syntax of the language is sufficiently simple, and contains only constructs of the given domain. Thus, expressing test cases in the DSL is really simple and easy to understand. In particular, it is much simpler than its implementation in Java, in particular because the latter involves at least two threads: one for receiving the asynchronous incoming messages, the other for checking the elapsed time and interrupting the first one after the specified amount of time. The chosen syntax elegantly hides this complexity from the user, who can thus focus on the logic of the test case instead of the difficulties of multithreaded Java programming. It should also be noted that, although embedding the DSL into Java imposes some constraints on the syntax of the DSL (e.g., every command must be followed by a semicolon), these restrictions are not disturbing at all. What is more, the embedding in Java provides a lot of powerful features free of charge. For instance, comments can be added to the test cases according to Java syntax, although this was not explicitly defined in the language grammar. More importantly, when judging the acceptability of the data contained in an incoming message, the full power of Java can be used to perform sophisticated computations (e.g. take a substring of the data field, interpret it as a hexadecimal number, compute a formula based on this number etc.). Defining these features from scratch, without relying on the existing features of Java, would be a quite tedious and time-consuming task.

6.2. The Resulting Architecture When looking only at the result in Figure 4, one could argue that this is a pure Java system, without any use of a DSL. In a way, this is indeed the case: through the embedding in Java, at the end all artefacts are in Java, and the DSL is not visible at all. However, when assessing Figure 4 thoroughly, one can also state that the result is a really clean architecture in which technology-related code and functional (i.e., test-related) code is successfully separated, in the sense of separation of concerns. It should also be noted that this feature is guaranteed automatically by the usage of the DSL, since the DSL only contains constructs of the domain, and no technology-related issues. Therefore we can conclude that even if the DSL is not visible in the final product, its use is justified also by the final product because the consequent use of the DSL leads automatically to the presented clean software architecture. Moreover, as mentioned in Section 0, the option is still available to extract the test cases from the Java program into separate non-Java files, and transform them in an automated way to Java or interpret them on-the-fly, if a looser coupling is needed.

7. Conclusion This paper has presented a pragmatic approach for the development of DSLs, in which the DSL is not created from scratch, but rather on top of an existing GPL. The GPL is extended with domain-specific constructs that are defined and implemented as data structures

Embedding Domain-Specific Languages…

35

and operations in the GPL. This way, the tools for the GPL can be used directly also in connection with the DSL, which drastically reduces the efforts of implementing the DSL. The presented case study showed how this approach can be applied in practice. A DSL has been devised for the black-box testing of ECUs on the basis of Java. With the presented approach, it is possible to specify the test cases at a high level of abstraction, without making any reference to the underlying technology (whether CAN, MOST, or direct Java function calls). The resulting DSL is simple and easy to use; moreover, its use leads automatically to a clean software architecture. To sum up: the presented approach helps to leverage the power of DSLs even in small projects in which creating a full-fledged DSL from scratch would not be feasible.

References [1]

Brooks, F. P., Jr.: No Silver Bullet – Essence and Accidents of Software Engineering, Computer, 1987 [2] Cook, S.; Jones, G.; Kent, S.; Wills, A. C.: Domain-Specific Development with Visual Studio DSL Tools, Addison-Wesley, 2007 [3] Fowler, M.: Language workbenches – the killer app for domain specific languages?, http://www.martinfowler.com/articles/languageWorkbench.html [4] Heider, A.; Mann, Z. Á.; Staudacher, B.: Verteiltes System, Automobil Elektronik, 03/2006 [5] Karlsch, M.: A model-driven framework for domain specific languages, Master’s thesis, Hasso-Plattner-Institute of Software Systems Engineering, 2007 [6] Kempa, M.; Mann, Z. Á.: Aktuelles Schlagwort: Model Driven Architecture, Informatik Spektrum, August 2005 [7] Ludwig, F.; Salger, F.: Werkzeuge zur domänenspezifischen Modellierung, OBJEKTspektrum, 03/2006 [8] Luoma, J.; Kelly, S.; Tolvanen, J.: Defining Domain-Specific Modeling Languages – Collected Experiences, Proceedings of the 4th OOPSLA Workshop on Domain-Specific Modeling, 2004 [9] Mellor, S; Balcer, M: Executable UML – A foundation for model-driven architecture, Addison-Wesley, 2002 [10] Mernik, M; Heering, J.; Sloane, A. M.: When and how to develop domain-specific languages, ACM Computing Surveys, volume 34, issue 4, pages 316-344, 2005 [11] Object Management Group: Model Driven Architecture, http://www.omg.org/mda/ [12] Object Management Group: Unified Modeling Language, http://www.uml.org/

In: Software Engineering and Development Editor: Enrique A. Belini, pp. 37-68

ISBN: 978-1-60692-146-3 © 2009 Nova Science Publishers, Inc.

Short Communication B

STUDYING KNOWLEDGE FLOWS IN SOFTWARE PROCESSES Oscar M. Rodríguez-Elias1,a , Aurora Vizcaíno2,b, Ana I. Martínez-García3,c, Jesús Favela3,d and Mario Piattini2,e 1

University of Sonora, Matemathics Department, Hermosillo, Son., Mexico Universidad de Castilla-La Mancha, Escuela Superior de Informática, Paseo de la Universidad No. 4, Ciudad Real, Spain, 3 CICESE Research Center, Computer Science Department, Ensenada, B.C., Mexico 2

Abstract Many authors have observed the importance of knowledge for software processes. This fact has caused that every time more researchers and practitioners initiate efforts to apply knowledge management in software processes. Unfortunately, much of such efforts are just oriented to aid big software companies, and in using existing knowledge management systems or strategies that have not been developed following the specific and particular knowledge needs of the process in which they are included. This fact has caused that often such efforts do not really help to the people who should benefit by using them. In this chapter we state that one way to address this problem is to first study software processes from a knowledge flow perspective, in order to identify the particular knowledge needs of such processes to then be in a better position for proposing systems or strategies to address those needs. This chapter presents an approach which has been used to accomplish the last objective. Its possible benefits are illustrated through the results of a study in a software maintenance process within a small software organization.

a

E-mail address: [email protected] E-mail address: [email protected] c E-mail address: [email protected] d E-mail address: [email protected] e E-mail address: [email protected] b

38

Oscar M. Rodríguez-Elias, Aurora Vizcaíno, Ana I. Martínez-García et al.

Introduction Software engineering is one of the most knowledge intensive jobs (Robillard, 1999). Thus, having a good knowledge management (KM) strategy in these organizations is very important (Aurum et al., 2003). Nevertheless, there are some factors which negatively affect the use of traditional KM systems (KMS) in software companies in many cases (Desouza, 2003). Some reasons for the latter are related to the fact that much KMS are not designed taking into account the real knowledge needs of the knowledge workers of organizations (Stewart, 2002). Developing KMS considering the daily work done in organizational processes is important to get them accepted by their potential users. This is of particular relevance in small and medium size organizations, since it is often difficult for those organizations to have enough resources for performing big changes into their processes to include KMS or strategies (Sparrow, 2001). In fact, small organizations should be capable of identifying the role that KM plays in their activities and current systems before developing or acquiring new tools (Wong, 2005). They should search for ways to integrate these current systems as part of the KM strategies designed, in such a way that these should be aligned to the every day work carried out by their employees. In this chapter, we present a methodological approach which has been useful to achieve the last objective in a software process. The methodology is oriented to aid in the study of organizational processes to obtain information useful to propose the design of KMS and strategies which consider the real knowledge needs of the knowledge workers; also considering the tools being used by them to achieve their job’s activities. The methodology is composed of a set of steps that pursuit three general goals: 1) to model organizational processes from the point of view of the knowledge that flows through them, 2) to analyze the knowledge, sources, their flow and the manner in which all these interact with the activities of the processes, and 3) to identify the tools or systems that support the process and that can play an important role as knowledge flow enablers. The information obtained by accomplishing these goals, should be finally useful to aid in the proposal of KM systems or strategies focused on improving the knowledge flow within the studied processes. The methodology was taken into practice in the domain of software processes, to evaluate their possible benefits and limitations. The main results of this case study are also presented in this chapter. The remain of this chapter is organized as follows: the next section, titled background, presents a general view of the use of knowledge management in software engineering, its importance, the main approaches reported in literature, and some of the main open issues we have observed. We are particularly interested on small software organizations, for which we also include in this section a subsection focused on addressing this issue, to finally discuss about the integration of KM into the every day work processes to introduce the need of an approach such as the one described in this chapter. In the third section we present the methodological approach we have followed to study software processes with the goal of designing KMS or strategies. Later, section four presents examples of the application of this approach and the results obtained from its use in a real setting. After this, a discussion of the results and observations from this case study is presented, to finally conclude and present some directions for further work.

Studying Knowledge Flows in Software Processes

39

Background Three main areas have motivated the present work, the improvement of knowledge flow in software engineering processes, the state of such an approach in small software development companies, and finally, the use of process-oriented KM to improve work processes in organizations. Next we present a discussion in such fields, in order to position the context of the present work.

Software Engineering and Knowledge Flow One of the main assets of a software organization is its organizational knowledge (Aurum et al., 2003). A KM strategy (Haggie & Kingston, 2003) can bring many benefits to software organizations which include time and cost reduction, quality increase, and improvement of the work environment or the software developer’s performance, see for instance (Dingsøyr & Conradi, 2002; Rus & Lindvall, 2002; Tiwana, 2004). Improving knowledge flow is a perhaps the main goal in KM initiatives (Borghoff & Pareschi, 1997). Consequently, in order to provide KM support in an organization, one important step is to understand how knowledge flows through it (Nissen, 2002). The flow of knowledge in software companies may be affected by many factors, such as inexistence or not updated documentation, often personal turnover, inexperienced employees, etc. These types of problems make KM an important concern for processes such as software maintenance (Anquetil et al., 2007), since they can be also related to a low level maturity of such processes, causing, for instance, dependability on source code and in the personal memory of employees (Singer, 1998). On the other hand, some characteristics of maintenance organizations with high level maturity can be related to the use of KM activities, such as updated documentation or management of expert skills (Chapin, 2003). Therefore, carrying out a process analysis focused on knowledge flow has the potential of bringing various advantages to software companies, as it can help to: •

•

•

Identify knowledge-related problems. A formal representation of a process can be used as a communication channel between the actors of the process, and the process analyzers. This can enable brainstorming to identify problems such as knowledge bottlenecks, and a search for possible solutions to solve them (Hansen & Kautz, 2004). Increase the information of the knowledge and knowledge sources involved in the process. The explicit representation of elements in process models facilitates the analysis of those elements (Conradi & Jaccheri, 1999). People analyzing models with explicit representation of knowledge and its sources can be induced to think about those elements and, as a consequence, provide more information about them. Identify tools that can be integrated within the KM initiative. An important part of successful KM initiatives is to integrate the organizational technical infrastructure (Jennex & Olfman, 2005), and to connect the KM support to the real work of the organization (Davenport, 2007). Many tools often used in software development may be powerful knowledge sources or KM systems (Lindvall & Rus, 2003). However, those systems might not be used to their full potential as KM systems. Analyzing

40

Oscar M. Rodríguez-Elias, Aurora Vizcaíno, Ana I. Martínez-García et al.

•

•

•

software processes and having a special focus upon the way in which the tools used in the process can provide support to the knowledge flow may facilitate their integration as a part of the KM initiative. Identify requirements in order to acquire or develop new tools through which to improve the knowledge flow. Once the problems affecting the knowledge flow are identified, it is easier to define requirements through which to modify the tools currently used, or to acquire or develop new tools to solve those problems. Analyze the effects of including KM strategies in the process. Process models which consider the knowledge flowing through the process can be used to analyze the effects caused by the inclusions of changes in the knowledge flow (Nissen & Levitt, 2004); this can, for instance, be carried out by modifying the process models of the current process to reflect the changes, and then comparing both models in order to analyze how these changes may affect the process. Improve the assignment of human resources. Assigning people appropriate roles in the development process is crucial to the attainment of a productive development team (Acuña et al., 2006). One of the main steps for this is to identify the profile required for each role, which includes the identification of the knowledge and skills that are required for the people that will play a specific role. Software process models that consider the knowledge and skills required in the activities performed by the different roles can be used to obtain information with which to define those profiles.

KM in Small Software Organizations Traditional approaches for managing knowledge in software organizations require the use of staff that are in charge of packaging knowledge or experiences, maintaining an experience base, and supporting software projects in identifying and using appropriate experiences (V. R. Basili et al., 1994). Since such staff must be separated from the developers’ staff, this may entail the need for resources that might not be easily available to small companies, although such approaches have been successfully applied in large software companies, see for instance (Dingsøyr & Conradi, 2002; Schneider et al., 2002). The latter point has motivated some researchers to propose lightweight approaches through which to help small organizations to adopt experience reuse. For instance, some approaches focus upon the use of postmortem analysis to capture experiences, either at the end of development projects (Dingsøyr, 2005; Dingsøyr et al., 2001), or during maintenance projects (Anquetil et al., 2007; de Sousa et al., 2004). It is clear that small software companies are different to the large ones in many aspects (Richardson & von Wangenheim, 2007), they have fewer resources which are often not sufficient for them to be able to engage in a novel KM approach that requires new tools, processes, training, etc., or that require having staff in charge of creating, maintaining, capturing, etc. a base of experiences or knowledge (Laporte et al., 2008). Mature KM initiatives for software organizations require a well established software process with a measurement program that enables the company to obtain data which is useful for measuring how they are working and how they can improve the quality of both the product and the process (Victor R. Basili & Caldiera, 1995). Unfortunately, many small software companies have not only not adopted standard processes and measurement programs (Laporte et al.,

Studying Knowledge Flows in Software Processes

41

2008), but have also not defined their own processes well (García et al., 2006), and these can sometimes seem chaotic (Harris et al., 2007). All this makes harder for such organizations to adopt traditional KM practices. Therefore, it is important to study means for helping small software companies to include KM activities according to their particular processes and needs. The importance of this last can be even grater if we consider that most of the software organizations world wide are considered to be small or very small companies (Laporte et al., 2008; Richardson & von Wangenheim, 2007). On the other hand, as has been observed by Land et al. (Land et al., 2001), KM efforts in software organizations commonly focus upon managing explicit knowledge outside the development process, while important knowledge involved in the development processes is not explicitly managed. Some studies have shown that even in software companies which do not have explicit KM practices, software engineers implicitly apply some kind of KM in their daily work, see for instance (Aurum et al., 2008; Meehan & Richardson, 2002; Ward & Aurum, 2004). Therefore, before engaging in a costly KM effort, small companies should first become aware of the implications of KM in their current systems (Sparrow, 2001) by, for instance, studying its processes to identify and understand the role that knowledge flow plays in them. Once accomplished this, we should be in a better shape to propose strategies to integrate KM into the software processes.

Process-Oriented Knowledge Management In recent years, KM experts have noted that KM approaches should be better integrated to the real work processes of organizations, (Scholl et al., 2004). From this observation, developing means to facilitate the analysis of work processes from a KM point of view has become an important concern (Maier & Remus, 2002). There exists some works reported in the literature which have applied process analysis methods to study software process from knowledge flow or knowledge management points of view. Hansen and Kautz (Hansen & Kautz) have used Rich Pictures (Monk & Howard, 1998) to study knowledge flows in a software process. Rich Pictures is a flexible Process Modeling Language (PML) which can be easily adapted to interleave different perspectives in a process model. In this study, the authors analyzed the process in order to define a knowledge map, which was then used to find problematic and missing knowledge flows. We have also performed a similar study (Rodríguez et al., 2004a) in which knowledge flows of a software maintenance process were analyzed by modeling them using Rich Picture. From this last study, some requirements for a KM tool emerged (Rodríguez et al., 2004b). Woitsch and Karagiannis (Woitsch & Karagiannis, 2003) have proposed a tool and a modeling approach which focus upon facilitating the analysis, documentation and implementation of enterprise KM systems. They use various types of models to represent different elements of the process, such as activities, people, etc. They illustrate the approach with a case study in a software organization and show how those models can be used to design an organizational memory. Nissen and Levitt (Nissen & Levitt, 2004) have used a tool to design virtual teams with which to analyze knowledge flows in a software process. Zhuge (Zhuge, 2002) has proposed an approach for analyzing knowledge flows in software organizations by decomposing the processes in tasks and knowledge nodes, and defining the workflow of tasks and the sequence of the knowledge transfers between knowledge nodes,

42

Oscar M. Rodríguez-Elias, Aurora Vizcaíno, Ana I. Martínez-García et al.

based on the inputs and outputs of tasks and knowledge nodes (for instance knowledge consumed or generated in the node). Finally, Strohmaier and Tochtermann (Strohmaier & Tochtermann, 2005) propose a framework with which to define a knowledge process and a tool to facilitate the development of a knowledge infrastructure, and this is exemplified by the development of a knowledge portal for a software company. However, this approach focuses upon the development of KM systems and not upon the analysis of software processes. From the review of the last works, we can state that studying knowledge flows can be a good start to identify and understand the main knowledge needs in a process, and as a consequence, to have information useful to start defining or designing KM systems or strategies focused on addressing those needs. In our work presented in this chapter, we have been using a Knowledge Flow Identification methodology called KoFI (Rodríguez-Elias et al., 2007a; Rodríguez-Elias et al., 2007b) to study knowledge flows in software processes. The advantage we see in this methodology is that it does not require the use of special tools for applying it, such as occurred with some of the methods we have found in literature. For instance, it does not require the use of a specific process modeling approach. Instead, the methodology proposes some recommendations for selecting a PML. On the other hand, much of the methods which we have found, are oriented to the development of specific types of KM systems. In our case, we are more interested on identifying and understanding the knowledge flows in the processes before deciding on a specific type of KM system. Moreover, we are interested on identifying the manner of integrating the current tools used in the software processes into the KM strategies, and perhaps, base such strategies in those tools. Therefore, the KoFI methodology was designed following these objectives (Rodríguez-Elias et al., 2007b). Next we describe the KoFI methodology to latter present the manner in which it was applied to study a software maintenance process.

A General View of the Kofi Methodology The KoFI methodology was designed to aid in the analysis of software processes from a knowledge flow perspective (Rodríguez-Elias et al., 2007a). It was defined to assist in three main areas: 1) to identify, structure, and classify the knowledge that exists in the process studied, 2) to identify the technological infrastructure which supports the process and affects the knowledge flow, and 3) to identify forms with which to improve the knowledge flow in the process. KoFI is orientated towards helping to analyze specific work processes. Therefore, it is necessary to define the specific process and model it. The process models are later analyzed following a four stage process, to finally identify and describe the tools which, positively or negatively, affect the flow of knowledge. The Figure 1 presents a schematic view of the KoFI methodology. The process followed to apply the methodology is iterative, since each stage may provide information useful for the preceding stages. The process models are also capable of evolving while they are being analyzed in the different stages of KoFI.

Studying Knowledge Flows in Software Processes

43

The KoFI methodology To specify the process to be analyzed

To identify knowledge sources

Process Analysis Phase

To identify knowledge topics

Knowledge focused process modeling

To identify knowledge flows Process Modeling Phase

KM Tools Analysis Phase

Analysis of the tools involved in the flow of knowledge

To identify knowledge flow problems

Figure 1. General view of the KoFI methodology.

As despicted in Figure 1, KoFI has three main phases: knowledge-focused process modeling, analysis of the process (which include identification of knowledge sources, topics, and flows, and knowledge flow problems), and analysis of the tools affecting the knowledge flow. To describe and illustrate the different phases of KoFI, we will use a sample case. Next we describe this sample case, to latter describe the different phases of KoFI.

A Sample Case In this sample case, we will analyze the process followed to create a software development plan in a small software company. The project plan is written by the head of the development department (HD), together with the project management (PM). The project plan must contain information for contacting the client who requests the system, the system’s description, the main expected functionality, references to the main related documents (principally the requirements specification), a detailed description of the main activities required to fulfill the project, the estimated time and cost, required personnel and resources, and a detailed description of the sequence of activities, and the personnel assigned to them.

Process Modeling Phase In this phase, the process is modeled in order to use those models to support the analysis. It is important that the models facilitate the identification of issues related to the knowledge involved in the process. Traditional PMLs can be used to identify issues related to implicit knowledge flows, such as the information sources which are required, generated, or modified by an activity (Abdullah et al., 2002). However, it is important that a PML used to analyze knowledge flow provides explicit representation of the knowledge consumed or generated in activities, the knowledge required by the roles participating in those activities, the sources of that knowledge, or knowledge dependencies. Because there are not much PML with this

44

Oscar M. Rodríguez-Elias, Aurora Vizcaíno, Ana I. Martínez-García et al.

characteristics (Bera et al., 2005), one way is to adapt existing PMLs to integrate the representation of knowledge. It is recommended to model the process at different levels of abstraction. First, a general view of the process can be defined with a general and flexible process modeling technique. To perform a detailed analysis, a more formally constrained language should be used. It may also be helpful to use a PML which has been designed for the type of process that is being analyzed, since this language should provide primitives to represent specific elements involved in that type of processes and the explicit representation of those elements will facilitate their analysis. In our case, we have used an adaptation of the Software Process Engineering Metamodel (SPEM) (Rodriguez et al, in press). The latter has been chosen due to the fact that our main domain area is software processes. SPEM is a UML based metamodel which has been specifically designed for software process modeling (OMG, 2002). There are various advantages of using SPEM. First, UML is the most extended modeling language for software development; this may facilitate the assimilation of SPEM as standard software PML. Secondly, it is possible to use any UML modeling tool supporting UML profiles to produce SPEM models (Bézivin & Breton, 2004), and there are many software modeling tools which enable the use of UML as a modeling language: commercial, open source, and free tools. Finally, SPEM enables the modeling of a software process from different views, at different levels of abstraction and with a formally constrained language. SPEM considers three main elements in the software processes: roles, activities and work products. A work product is everything generated or consumed in the activities of the process. The adaptation to SPEM used in our work consists on defining special types of work products to represent knowledge and knowledge sources involved in the processes. In this manner, it is possible to specify the knowledge generated or used in an activity, the knowledge contained in a specific source, the role responsible of specific knowledge or sources, between other things. Since the focus of this paper is not on the modeling language, further details of this aspect are not presented; a detailed description of the SPEM adaptation can be found in (Rodríguez-Elias et al., in press). In this paper we shall limit ourselves to simply present some examples while presenting the model of the sample process.

Modeling the Sample Case Four main elements are the ones used to represent knowledge related issues in the models: 1) knowledge topics (first icon in Figure 2), used to represent specific knowledge topics, subjects, or areas; knowledge sources (second icon in Figure 2), used to represent the main documents or other sources of knowledge involved in the process; knowledge packages (third icon in Figure 2), used to group related knowledge topics or sources; and knowledge transfers (last icon in Figure 2), a multiple relationship used to represent transfers of knowledge between roles and/or sources. These elements are used in the SPEM diagrams to represent knowledge issues, as is next described.

Studying Knowledge Flows in Software Processes

KTopic

KSource

GroupedKnowledge

45

KnowledgeTransfer

Figure 2. Notation icons used in the adaptation of SPEM.

The first step in the modeling phase is to identify the main activities and knowledge packages involved in the process. This is done by creating use cases of the process. A regular use case in SPEM shows the relationships between the roles of the process, and the workflows in which they participate. In our case, we use the use cases to represent the workflows and the main knowledge packages involved in them. Figure 3 shows a use case of the sample process. As can be observed, there have been identified three main workflows: 1) to write the document (project plan), 2) to estimate the cost and time of the project, and 3) to define and assign the activities. Related to these workflows four main knowledge packages have been identified: 1) the head of the department’s knowledge, 2) the information contained in the project plan, 3) the project manager’s knowledge, and 4) the software engineers’ knowledge. The packages are related to the workflows with dependencies. Therefore, the direction of the arrows means that a workflow or activity depends on the pointed knowledge package, or that the knowledge packaged depends on an activity or workflow, perhaps because the knowledge is generated from such activity. The knowledge packages of Figure 3 highlight the fact that most of the knowledge used or generated in the process modeled is tacit, that means, it is in the head of the people who perform the process.

Project plan development

Head of the Department’s Knowledge

Project Manager’s knowledge

To write the document

Project plan information

Time and cost estimation

To define and assign activities Figure 3. Use case of the sample process.

Software Engineers’ knowledge

46

Oscar M. Rodríguez-Elias, Aurora Vizcaíno, Ana I. Martínez-García et al.

Once identified the main knowledge packages and workflows, we then modeled the specific activities of each workflow, to identify the roles participating in it, and the knowledge sources and packages being required or generated in such activities. To this end, an adaptation of the activity diagrams is used. Figure 4 presents an example in which the “writing the document” workflow is modeled. This model illustrates the main packages of knowledge or information being required or generated in the activities. In this manner, it is possible to explicitly show: • • •

knowledge requirements. The knowledge required by a role to accomplish its activities, or the knowledge required to accomplish a specific activity. knowledge dependencies. Activities that require knowledge generated in the previous ones. knowledge loses or knowledge difficult to find. Important knowledge that could be not being captured or is difficult to find because, perhaps it is distributed in different sources, or the sources are unknown by the employees. To highlight this fact, it could be used the knowledge source icon to represent the means where the knowledge used or generated resides, and knowledge packages to represent that knowledge that is not being captured, or that could be difficult to find. Project Manager

Head of the Department

Knowledge about the text edition tool

To create the document Knowledge about formatting the document’s content

Información del plan

To fill the document To analyze the plan

Head of the department’s experience

To develop business Summarized summary project plan

Figure 4. Activity diagram of one of the workflows of the sample process.

To describe the specific knowledge subjects that are contained in a knowledge package, we use an adaptation of a class diagram which has been called knowledge package diagrams. This diagrams help to decompose the knowledge packages in knowledge areas or specific topics or subjects. In this manner, we can start classifying the knowledge involved in the

Studying Knowledge Flows in Software Processes

47

process, as is illustrated in Figure 5, in which we show the decomposition of the information contained in the project plan. Project plan Information Project description Expected functionality Estimated time and cost

Information about the client Assigned personnel

Name of the person responsible Address

Information about related documents

Activities to be done

Information about the client

Resources assignment

Information about the activities

Time and cost restrictions

Information about the related documents Document’s name Document’s description Document’s location

Summarized project plan Summarized project description Main functionality Estimated time and cost

Assigned personnel

Information about the activities Activities’ description

Resources assignment

Assigned engineers Estimated time Dependencies with other activities

Figure 5. Example of a knowledge package diagram, used to decompose specific knowledge areas or subjects grouped in a package.

Finally, it is important to identify the specific sources where the different knowledge subjects identified can be obtained. To accomplish this, we use an adaptation of class diagrams, in which the sources and the knowledge they contain is modeled, together with the roles responsible of the sources. A relationship called knowsAbout is used to specify the knowledge that a specific source contain. Figure 6 presents an example of this type of diagram. In the example, we specify the sources related to the information of the project plan. As can be seen, three main sources are identified: the project plan itself, the requirement specification document, and an summary of the project plan. The diagram also shows dependencies between sources, for instance, the content of the project plan depends on the information contained in the requirement specification. Additionally, these diagrams can be also used to start classifying the different types of sources. For example, the requirement specification and the project plan have been classified into a group called system documentation.

48

Oscar M. Rodríguez-Elias, Aurora Vizcaíno, Ana I. Martínez-García et al.

Project Plan knows about

responsible

Project Manager

Project plan information

System documentation Expected functionality knows about

knows about

knows about

Summarized project plan responsible

Information about the client Summarized information about the project plan

Head of the department

Requirement specification responsible

Requirements engineer

Figure 6. Example of an adapted class diagram, used to illustrate the relationships between knowledge sources, topics, and roles.

The Process Analysis Phase Once obtained an initial model of the process, we can use them to analyze the process. However, those models could be changed during this phase as more details of the process are being obtained. As was shown in Figure 1, the analysis of the process is carried out in four stages, described in the following subsections.

Identifying Knowledge Sources The first stage of the process analysis phase of KoFI is to identify the main sources of knowledge involved in the process. This stage also include the organization and classification of the sources found. The above is a first step towards the definition of a taxonomy of sources and topics of knowledge, which is one of the first steps in the development of KMSs (Rao, 2005). Additionally, an ontology can be developed from this taxonomy to help define the relationships between the sources and the other elements of the process. This type of ontologies can later be used to structure the knowledge base of the process (O'Leary, 1998). The main issues that should be considered during this stage are: • •

•

Documents used or generated by during the process. Products of the process. In software organizations, the produced software, source code for instance, is one of the main sources of knowledge in many cases (Seaman, 2002). People involved on the process, such as staff members, external consultants, etc.

Studying Knowledge Flows in Software Processes • •

49

Information systems used by the actors of the process, such as data bases, organizational memories, knowledge bases, organizational portals, etc. Other tools which could be being used to obtain or generate information or knowledge. For instance, software development environments can provide tools to help obtain knowledge about the structure of specific pieces of source code, the history of a software system, simulate operation scenarios, etc.

From the example we have been following from previous sections, we can observe the existent of different sources. First, there two types of documents: the project plan and the associated documents, such as the resume of the plan, and the requirement specification. Secondly, it can be identified that people involved are the head of the department and the project manager. However, since some of the information required by these people is obtained from the software engineers, they are also an important source. In the scenario there is not description about the use of tools or information systems. However, let us suppose that for selecting the personnel to be in charge of the project, the company uses a human resource management system, which has information about the work assigned to each employee and their experience profile, in such a way that the this information can be used to make an initial assignation of personnel to the project. This system should be classified as an information system. On the other hand, let us now suppose that we identify that the project manager uses a tool to help him/her to estimate the time or cost that the project will consume, for instance making use of previous project data; then, this tool can be classified in the support tools category.

Figure 7. A metamodel for knowledge sources description and classification.

To classify and describe each knowledge source, KoFI proposes a metamodel which consists in a classification schema composed by categories (KSourceCategory) and types (KSourceKind), and other elements useful to provide more information about the sources,

50

Oscar M. Rodríguez-Elias, Aurora Vizcaíno, Ana I. Martínez-García et al.

showed in Figure 7. If we follow this metamodel, then for each source identified, we should describe its location (the place in which it can be found or through which it can be consulted), its physical support if apply (i.e. electronic source or paper), and the specific format of the source (for instance, if the source is a electronic file, it could be free text, pdf, etc.). The LocationKind property is used to define predefined types of locations, for example a data base, an email, a physical address, etc. The KConcept element refers to a knowledge concept, which can be both: a knowledge source or a knowledge topic. By using the classification schema of the metamodel, then Figure 8 could represent an example of the classification of the sources described in the previous paragraphs.

Figure 8. An example of a classification schema of the knowledge sources identified in the sample process.

Finally, it is important to comment that during the identification of the knowledge sources, we should also start identifying the main knowledge topics that could be obtained from them.

Identifying Knowledge Topics In this stage, the topics of knowledge that can be obtained from the sources found in the previous stage are defined together with the knowledge that the people involved in the process may have or require. As the same as in the previous stage, a taxonomy and an ontology can be used to classify the types of knowledge and define their relationships with other elements of the process. The ontology must define means to relate the knowledge sources with the knowledge areas or topics that can be found in them. Each knowledge topic should be described by a name and a brief description, additionally it is important to identify alternative names, and dependencies with other topics.

Studying Knowledge Flows in Software Processes

51

The main issues that should be taken into account are: • • • • •

Knowledge about the organization, such as its structure, norms, culture, etc. Knowledge about the organizational processes, such as their activities, people involved, etc. Activities dependant knowledge, such as proceedings or tools used to accomplish them. Knowledge about the domain of the work done in the company. In our case software development. Other types of knowledge, such as foreign language speaking, or other knowledge or skills which are not part of the daily work but could be important.

In the sample process we could identify that the knowledge required to create the project plan include: the information that the document should contain, the format that the document should follow, the sources from which the information captured in the document is obtained, the methods to follow for estimating the time and cost of the project, information about the activities to be performed and about the personnel assigned to the project.

Figure 9. A metamodel for knowledge topics classification.

To classify the knowledge topics, we also follow the metamodel proposed by KoFI. Figure 9 shows the part of the metamodel focused on the classification schema of the knowledge topics. As can be observed, the classification is based on a hierarchy of knowledge categories (KCategory), knowledge areas (KArea), and knowledge subjects (KSubject). A knowledge category is a structural element of high level of abstraction used to group related knowledge areas. Knowledge areas are subdivisions of the knowledge categories which are logically related with the category by, for instance, inheritance, aggregation, or composition. Knowledge subjects are subdivisions of the knowledge areas that represent basic concepts which have an explicit and well defined description. Subjects define knowledge elements that can be defined as a unit. Of course, defining what will constitute a knowledge area and what a subject can be a subjective decision. Thus, this decision should be taken depending on each

52

Oscar M. Rodríguez-Elias, Aurora Vizcaíno, Ana I. Martínez-García et al.

particular case. The three elements of the hierarchy are considered as knowledge topic since, in this manner, it is possible to refer to a knowledge category, area, or subject to specify the knowledge required or generated in the process. In some cases it could be needed to specify that for solving a problem it is important to know about subjects grouped in a category or in an area, and in other cases to a specific subject. For instance, we could decide to search for a person who knows about programming languages, or about a specific programming language (i.e. java), or about specific issues of a programming language (i.e. accessing databases with java). By using the classification schema of the metamodel, then Figure 10 could represent an example of the classification of the knowledge topics. In this example, we highlight the fact that there exist predefined methods for estimating the cost and time of the project. Additionally, the example illustrate that this topic is part of both: and area grouping the knowledge related to the creation of the project plan, and other grouping estimating methods, which is also part of a bigger area called methods and tools. Finally, all the knowledge areas mentioned are part of a category grouping the knowledge related to the development process activities.

Figure 10. An example of a classification schema of the knowledge topics identified in the sample process.

Identifying Knowledge Flows In this stage, the process model is used to identify the way in which the knowledge and sources are involved in the activities performed in the process. The main activities in the processes must be identified, along with the decisions that the people performing those activities have to make. Figure 11 presents the part of the metamodel proposed in KoFI, and that represents the relationships between the knowledge concepts and work definitions. A work definition is an element of SPEM; it refers to an operation or a set of operations that must be performed to accomplish a process (OMG, 2002). Therefore, each work definition must have a goal; this means there must be a purpose for which to perform the operation.

Studying Knowledge Flows in Software Processes

53

Then, a work definition can be a simple task or a decision to make, or a group of them, such as a complete activity, workflow or sub-process. These work definitions are related to the knowledge concepts either because these last are required to accomplish them, or because they are generated from them. Finally, the metamodel also establish that each knowledge source can have a certain level of knowledge about other knowledge concepts, either about knowledge topics or other sources.

Figure 11. Metamodel of the relationships between work definitions and knowledge concepts. Project plan information Required

General data Activity

Obtained

Project’s name Project’s description

To create the document

General data

Information about the client Details

To fill the document

Details

Expected functionality Estimated time and cost

Details To analize the plan

Information about related documents Activities to be done Resources assignment

General data

To develop business summary

Assigned personnel Information about the activities

Figure 12. Knowledge transfer diagram of the project plan information of the sample process.

Following the metamodel, the process models are analyzed to identify the relationships between knowledge topics, sources, and work definitions. Then, it should be easier to identify the way the knowledge flows through the process while the people involved perform their

54

Oscar M. Rodríguez-Elias, Aurora Vizcaíno, Ana I. Martínez-García et al.

activities; for example, the sources which could be being used as knowledge transfer mechanisms between activities or people. It is important to identify either flows of knowledge between activities or between sources; for example the transfer of knowledge from a person to a document. The main diagrams that could help to perform this analysis are the activity diagrams for identifying the knowledge or sources required or generated in the activities of the process, and the class diagrams to identify the knowledge contained in each source. For instance, in Figure 4 it can be observed that the project plan document is the main source used to transfer knowledge between activities and between actors of the process. If more details are required to analyze the manner in which the knowledge contained in a source is being used or generated in the different activities in which it participates, the source’s knowledge transfer diagram proposed by Rodriguez-Elias et al. (Rodríguez-Elias et al., in press) can be used. This type of diagram shows the sequence in which the knowledge contained in a source is obtained by or extracted from such source, and the activities in which all this takes place. Figure 12 presents an example that shows the information that is contained in the project plan.

Identifying Knowledge Flow Problems The last stage of the process analysis phase is to discover the problems that may be affecting knowledge flow. For example, whether the information generated from an activity is not captured, or whether there are sources that might be able to assist in the performance of certain activities but that are not consulted by the people in charge of them. To do this, KoFI proposes using problem scenarios, which are stories describing a problem which is taking place in the process being analyzed (Rodríguez-Elias et al., 2007a). This story must show how the problems detected are affecting the knowledge flow. Then, one or more alternative scenarios must be defined to illustrate possible solutions, and the manner in which those alternative solutions may improve the flow of knowledge. These possible solutions are then used as the basis for proposing the KM strategy or system. The problem scenario approach is a combination of the problem frames (Jackson, 2005) and the scenario (Carroll & Rosson, 1992) techniques. These both techniques have proven to be useful to obtain requirements for designing software systems (Chin et al., 1997; Cox et al., 2005). The knowledge flow problems identified should be classified, then it should be selected a sample case to illustrate the specific type of problem in each category. The problem scenario is described by a name and the type of problem it refers to. The problem is explained through a story that shows the way it appears in practice. The possible solutions to the problem are explained with alternative scenarios that show the manner in which we expect the problem could be solved or reduced by using the proposed solution. In the sample process we found a system in which all the projects are captured. This system allows define the activities of the project and the people in charge of them. When the activities are defined, the system sends a message with the information of the activities to the engineer who should accomplish each of them. Then, the engineers can have a registry of the activities done, in progress, or those that are pending. Although the engineers can modify the information of the activities assigned to them (i.e. status, time required to accomplish them, etc.), we find that this information is not reflected in the main project plan, since the information is modified only locally in the workplace of each engineer. Therefore, we find it

Studying Knowledge Flows in Software Processes

55

is difficult to the project manager to know exactly which the status of the entire project is. To know this, the project manager must consult each engineer. After analyzing the problem, we might propose to modify the system in a manner in which it could be possible to reflect the changes made by the engineers in each activity, in the main project plan. This problem could be described by a problem scenario as the shown in the Table I. Table I. An example of a problem scenario for describing a knowledge flow problem Problem: Inconsistent information in the activities performed Type: Lost information Scenario description: John, the person responsible of one of the projects of the informatics department, must define the activities of the project and estimate the time needed for each one, in order to specify the total time needed for accomplishing the project. John knows that the time of each activity is partially dependant on the engineer in charge of it. Thus, John decides to assign each activity to the engineer who will perform it before estimating the time. This assignation is performed by John taking care of its personal knowledge about the expertise that each engineer has, assigning the most suitable engineer for each activity, trying to reduce the time that each activity could need. After this, John consults each engineer, and together they define the time each activity could spend. When John calls one of the engineers, he informs John about other activities he has to perform in other project; thus John must reassign the activities, and perform all the process again. Alternative scenario When John starts the definition of the activities to be done, he uses the project manager system to identify similar activities and estimate the average time they consumed. If this time seems to be independent of the engineer in charge, John might suppose that in this time it will not be different. If the last is not the case, then John could analyzes if the variation depends on the engineer in charge, and consult them to define which could be the cause of this variation. In this manner, John could start making an estimation which could be independent of the engineers in charge of each activity. Additionally, once John decides to assign the activities to the engineers, he uses the system to identify which engineers have other pending activities, considering this additional situation when he makes the assignation of the engineer for each activity of the project.

The problem scenarios can be used to identify requirements for designing applications focused on solving or reducing the knowledge flow problems identified. However, there might be cases in which the proposed solution can be the modification of the existent technical infrastructure, such as the case presented here. For these cases, it is required to first analyze the manner in which the existent systems are participating in the flow of knowledge, to then be able to define the way to modify them to improve the flow. The final phase of KoFI, following described, is focused on aiding in this objective.

The Tool Analysis Phase The final phase of the methodology focuses on analyzing the manner in which the tools used to support the activities of the process affect the flow of knowledge. To this end, we have used the Rodriguez-Elias et al. framework (Rodríguez-Elias et al., 2008). The objectives followed in this framework include: • •

To identify the role that the tools used in the process play as knowledge flow enablers. To identify requirements to improve the use of the tools as knowledge flow enablers.

56

Oscar M. Rodríguez-Elias, Aurora Vizcaíno, Ana I. Martínez-García et al. • • •

To identify the possible effects in the knowledge flow of the possible modifications to the tools. To identify possible uses of the tools in other process or activities of the organization. To compare different tools that could support similar activities, from a knowledge flow perspective.

To accomplish the last objectives, the framework proposes four main steps to analyze information systems as knowledge flow enablers: 1. The first step is to define the application domain of the system. This includes: a.

identifying the use of knowledge, that means whether the knowledge managed by the tool is useful for the business strategy, for the organization’s managers, for the organization’s daily live, for the work processes domain, or for technical activities; b. identifying the scope of the knowledge, which can be single persons, an intra or extra organizational group, the entire organization, multiple organizations, or an entire sector of the industry; and c. identifying the domain of the knowledge managed, which can be knowledge about the business strategic, the organization, the management, the products or services provided by the organization, or about technical activities. 2. The second step consists on identifying the structure of the knowledge, that means, whether the knowledge managed is tacit or explicit, and if it is explicit, how well structured or formalized it is. 3. The third step focuses on defining the KM activities being supported by the tool, such as creation, application, capture, storing, retrieval, transfer, etc. 4. The fourth step consists on the definition of the main technical aspects considered important for the tools. Particularly if the tool performs some activities in an automatic manner or if it manages distributed or local knowledge. As an example of the use of the framework, we will use the projects management system described in the previous section. From the description of such system, we observe that it is being used to facilitate the transfer of knowledge from the project manager to the software engineers, since the systems allows to the engineers to know which activities are assigned to them. Based on this, we might conclude that the projects manager system application domain is the work processes, particularly the project management process, and the development process. The scope is intra-organizational group since it is used by the people of the development department (project managers and software engineers). And the domain of the knowledge managed could be project planning and scheduling. The type of knowledge managed it is explicit, however, how formalized it is will depend on the form the information is being stored in the system. For instance, if it is managed mainly as free text, it will be unstructured. On the other hand, if it is being managed as registries in a well structured and defined database, it will be structured.

Studying Knowledge Flows in Software Processes

57

The knowledge management activities supported will depend on the functionality provided by the system. First, we might conclude that it aid in the capture and storage of knowledge phases, and in the transfer of knowledge from the project manager to the software engineers. However, if the tool provides a well defined structure for capturing the knowledge, for instance it specify the type of information and the manner in which this should be captured, then it will be aiding to the knowledge formalization phase. Additionally, if the system provide with means for organizing the stored information, for instance to facilitate the identification of specific projects, perhaps past projects with specific characteristics, then the system will be aiding in the knowledge retrieval stage. Finally, in certain cases technical aspects are the ones responsible of facilitating or blocking the acceptance of KM systems. These technical aspects could be related to for instance security, work overload, or distribution of the knowledge. For instance, one problematic technical aspect of the projects management system could be the fact that modifications made by the engineers to the status of the activities are not reflected in the main project plan. In this case, the knowledge of such status is distributed across the personal workspaces of the engineers, and it is not being managed by the tool. As can be observed, by analyzing the functionality of the tools being used in the process, we can start identifying the manner in which they are supporting specific KM activities. Additionally, this analysis can be used to start defining proposals by which to improve the KM support of the tools, or to decide whether the tool is facilitating or blocking the flow of knowledge. All this information can be later used to make decisions about, for instance, if the tool should be modified, leaved as it is, or perhaps changed by another or eliminated from the process. To support these statements, in the following section, we describe some of the results of the application of the described methodology to study a software maintenance process.

Applying the KoFI Methodology The goal of this section is to describe the results we have obtained by applying the KoFI methodology in real settings. Particularly, we focused on the results of a case study carried out in a software development group to study its software maintenance process. This case study is presented as follows: first, we describe the context of the study, to latter present the manner in which the analysis of the process was carried out, together with some of the results of this analysis. Finally, we shall describe the main observations and lessons learnt from the study.

The Context of the Study The group of software developers who took part in the case study was the Informatics Department (ID) of a research centre, which is in charge of maintaining the information systems used in this centre. At the time of the study the group was composed of fourteen people: the head of the department (HD), a secretary, six software engineers (SEs), and six assistant programmers (APs). One of the SEs was a novice, with only 2 months’ experience in the job; the other SEs had between 5 and 11 years experience; all of the APs had spent less than 1 year in their jobs. The group was in charge of maintaining the applications in 5 domain

58

Oscar M. Rodríguez-Elias, Aurora Vizcaíno, Ana I. Martínez-García et al.

areas: finances, human and material resources, academic productivity, and student services. All of the applications were of about 10 to 13 years old, if we take into account the development of their first version. Most of them used the Oracle database management systems and programming tools. Normally, these applications require only one or two people for their maintenance, and can be considered as medium size applications (between 50 and 100 different modules per application, taking into account reports, views, forms, menus, etc., -the ID does not have an exact measurement of their current size-). Most of the maintainers did not participate as original developers of the systems. APs were assigned to the modification activities; there are often changes in the particular people involved in these tasks. The ID does not follow standard software processes. Nevertheless, its maintenance process is similar to others we have studied in literature (i.e. (Chapin et al., 2001; Polo et al., 2003a)). The work of the ID is organized into projects triggered by maintenance requests, which are of two types: modification requests (MRs) made by the users of the systems to improve or to add new features, or to adapt the system to changes in the environment (the operating system, the process, etc.); and problem reports (PRs), which describe problems the users have experienced with the systems. Each SE is responsible for the requests∗ of the systems assigned to him/her, even though some of the changes may eventually be made by another SE or by an AP. All the requests are stored in a logbook. The logbook is used to track the status of each request by the HD and the users who made them. The SEs use the logbook to track the requests assigned to them, and to consult information about the request. The data of the process was obtained from interviews with the members of the ID, direct non-participatory observation, and the analysis of documents and information systems of the ID. We first developed an initial model of the process whose modification was based on observations and comments made by the members of the ID during the period of our final interviews. We used the previous models as a mechanism by which to analyze the process in the final interviews, until the SEs agreed with the models.

The Analysis Phase The results of the analysis phase have been classified in three main categories: the identification and classification of knowledge sources and topics, the identification of aspects related to knowledge flows (knowledge flows problems), and tools being used as knowledge flow enablers.

Identification and Classification of Knowledge Sources and Topics One of the main contributions of the study was that it helped us to initiate the identification and classification of the main knowledge topics required by the ID and the sources in which such knowledge can be obtained. These are the first two steps in the methodology followed. First, we identified the main general topics of knowledge required by the maintainers to perform modifications to the systems they are in charge of. These general topics were classified into knowledge packages of related topics, which also have sub-

Studying Knowledge Flows in Software Processes

59

packages of more specialized topics. The main knowledge needs of a maintainer were: 1) the knowledge related to the system being maintained, which includes knowledge of the structure of the system, the correct functioning of the system, and so on; 2) the application domain of the system, which includes topics related to the specific concepts used in that application domain, and the process being supported by the system; and 3) technical knowledge, which includes topics related to the programming language and the development environment being used. One important observation we made was that the knowledge requirements of the maintainers were directly related to their experience in the maintenance process carried out by the organization, the applications being maintained, and the technical infrastructure used during the process. We observed that novel engineers were more concerned on acquiring knowledge about the technology they must use to accomplish their activities, such as the programming language or the development tools. Maintainers with a medium experience were more interested on knowing about the application they must maintain, such as its structure, dependencies between the modules of the system, etc.; while the most experienced maintainers were more concerned on knowing about the application domain of the system being maintained, such as the details of the processes supported by the system, the way the users are using the system, and the main problems they have while using system. On the other hand, respecting to the knowledge sources, we confirmed what other authors have reported about the documentation problems in software maintenance (Lethbridge et al., 2003; Lientz, 1983; Singer et al., 1997). First, the ID has not much formal documentation of the systems they are maintaining. In fact, some of the systems have not documentation at all. Additionally, most of the documentation that the ID has is not updated, and for making the problem bigger, although the few documents the ID has are stored in a central repository to make them available to all the engineers, most of those documents are unknown by them. Moreover, even though some engineers know that there are some documents that could be useful for them; they do not use them since it is difficult to find them because the engineers do not know what the documents names are, or in which specific directory they are. Thus, they believe they will spend much time trying to find a document, so they just do not use the available documentation. All this problems cause the engineers head to be the main knowledge source in the ID. This means that most of the knowledge of the ID remains tacit. Nevertheless, we made two important observations about the use of knowledge sources in the group studied. First, we found that some of the engineers are actually making their own KM effort, and trying to capture some of the knowledge they often require in a formally manner, although this cause them a work overload. The engineers are aware of that this extra job will help them to reduce the time and effort they spend in common activities. For instance, some of the engineers have created documents that describe the internal structure of the systems they are in charge of, in a way in which these documents help them to know which are the source files of a specific module of the system, or which are the database tables or other modules related to it. However, these documents are just known by the engineers who created them since they remain in the engineers’ workspace. The second observation we made, was that much of the sources consulted by the engineers are outside the ID. Particularly, the engineers often consult to the users to obtain knowledge about the application domain of the system. However, we also found that part of ∗ We use requests to refer to both, MRs and PRs.

60

Oscar M. Rodríguez-Elias, Aurora Vizcaíno, Ana I. Martínez-García et al.

the information provided by the users is also stored in documents available in an organizational portal of the research centre.

Identification of Knowledge Flow Problems and Knowledge Flow Support The main knowledge flowing in the maintenance process was the associated with a maintenance request, and the main mechanisms being used in the ID as knowledge flow channel is a logbook in which the maintenance requests are stored. However, just a little part of such knowledge is stored in the requests themselves, and not all the maintainers write the same information. A request may frequently only contain initial data, such as the client who made it, the person responsible for solving it, and a brief description of the problem. The study helped us to identify other sources that could also have information related to the request. First, there were documents containing descriptions of the requirements of changes. These documents were very diverse, some times they were memos, other times they were emails, and in other cases they were just notes in the maintainers’ personal notebook. Additionally, we found there were some emails containing information related to the files changed, and the modifications done to the databases. The last was observed once we defined all the specific topics of knowledge included in a package containing the information related to a request, and then, identifying the different sources which could be useful to obtain each of those topics (see Rodríguez-Elias et al., in press). From this exercise, we identified all the sources related to the information of a maintenance request. Then, we were able to recommend the ID to modify its logbook in order to allow the inclusion of links to documents associated with each request. The goal is to enable the maintainers to access all the associated documents and information related to a request from the same request, thus improving the use of the logbook as a knowledge flow facilitator.

Practical Contribution of the Case Study As described in the previous section, the case study has give us useful information for identifying some of the aspects to be considered while defining KM strategies or systems for a group with similar characteristics as the one we have studied. However, additionally to these results, the case study has also made some important contributions to Informatics Department and its personnel. Next we provide a list of what we consider were the main contributions. •

•

The members of the ID are now aware of some of the problems they face in their maintenance process and are consequently developing tools to address some of these problems. They have, for instance, developed a web portal in which all the documents and information of the systems being maintained will be easily accessible. The logbook is being used more often as an important source of knowledge. When we conducted the study, not all the engineers used the logbook on a regular basis, but it is now a key part of their process. This might help the ID to maintain better control over the changes they make.

Studying Knowledge Flows in Software Processes •

•

61

The study has improved the sharing of knowledge among members of the ID. Through the analysis of the models, the members of the ID have become aware of sources of knowledge that they did not previously know existed, and these can be used to obtain important knowledge for their activities. The ID personnel are now interested in formally describing their processes as a step towards the adoption of a standard software process model. They are interested in taking on a Mexican standard for small-to-medium-size software development organizations which was approved by the Mexican government as a measure towards promoting the Mexican software industry (Oktaba, 2005). This process model considers the integration of a knowledge base as an important part of the software process. The ID did not previously have a formal description of their processes. They discovered that the analysis of the process models we made might be a useful aid in the formal description of their processes. The representation of knowledge and its sources in the models is of particular interest in aiding the definition of the knowledge base.

Related Work The identification of the knowledge required by people performing software engineering activities is an important research area. For instance, Lethbridge in (Lethbridge, 2000) and Kitchanham et al. in (B. Kitchenham et al., 2005) present studies aimed at identifying the knowledge that software professionals require in practice. It can be observed that much of such knowledge is obtained during practice, and thereafter, depends on the context of the organization in which that knowledge is applied. These works provide an appropriate reference through which to identify the main knowledge areas related to software engineering. However, they are too wide to be practical when classifying the knowledge involved in specific small software organizations. In spite of the importance of software maintenance (Polo et al., 2003b), there are few studies dealing with software maintenance knowledge needs. Most of these works can be classified in the field of program comprehension (Ko et al., 2006; Mayrhauser & Vans, 1995). This may be because source code is the main source of information for software maintainers (Singer, 1998). However, they frequently also consult other sources (Seaman, 2002), and it is important to identify how these are related to the maintainers’ knowledge needs. Two types of studies address this issue: •

Koskinen et al. (Koskinen et al., 2004) have proposed a program comprehension tool by which to facilitate software maintainers’ access to information sources in order to fulfill certain information needs defined from a review of literature. On the other hand, our research group (Rodríguez et al., 2004a; Vizcaíno et al., 2003) has proposed the use of software agents (Nwana, 1996) to facilitate access to knowledge sources in software maintenance. This last approach is not focused upon facilitating code comprehension, but upon facilitating software maintainers’ access to sources which will be useful for obtaining information from other domains, such as the application domain, users’ behavior, and previous maintenance requests, amongst others.

62

Oscar M. Rodríguez-Elias, Aurora Vizcaíno, Ana I. Martínez-García et al. •

Oliveira et al. (Oliveira et al., 2003) have performed a study through which to identify the knowledge involved in software maintenance, from which an ontology was developed (Dias et al., 2003). Oliveira et al.’s ontology is similar to the ontology of Ruiz et al. (Ruiz et al., 2004), since both ontologies identifies the main elements that are involved in the maintenance process, and the relationships between them. Additional, both ontologies are based on the Kitchenham et al.’s ontology of software maintenance (B. A. Kitchenham et al., 1999). Nevertheless, Anquetil et al. in (Anquetil et al., 2007) illustrate how such types of ontologies can be used as frameworks for obtaining knowledge about software maintenance projects. They used their ontology to discover what to request during postmortem analysis in maintenance projects.

The works of Koskinen et al. (Koskinen et al., 2004) and Rodriguez et al. (Rodríguez et al., 2004a) show that relating knowledge sources to specific knowledge needs can make a contribution towards aiding software maintainers to access the knowledge sources that might be useful for specific activities. On the other hand, Oliveira and her colleagues (Anquetil et al., 2007; Oliveira et al., 2003) illustrate that having a model of the tasks to be carried out, and the elements involved in those tasks, such as knowledge and sources, can facilitate the identification of such knowledge needs, and the knowledge sources that might be related to them. However, the works described do not provide methods for studying specific software processes in order to identify and understand knowledge needs, and knowledge flow problems. Other related works are those which have been conducted to identify KM practices in software processes. Meehan and Richardson (Meehan & Richardson, 2002) investigated the software process of three small Irish software companies in order to identify their KM practices. From the study, the authors extracted some recommendations to accomplish some KM activities, such as knowledge creation, storing, etc. Aurum et al. (Aurum et al., 2008; Ward & Aurum, 2004) have also investigated KM practices in software companies, but they have studied big Australian companies. Between the main findings of these studies was the identification of some enablers of the KM process in the organizations studied, principally leadership, technology and culture. Although the above works provides important results about KM practices in software companies, they do not provide a method by which to obtain those findings for specific software companies, as we have done in this chapter. Finally, Lutters and Seaman (Lutters & Seaman, 2007) have proposed the use of “war stories” as a methodological approach by which to perform empirical software engineering research. They use that method to study the documentation usage practices in a set of software maintenance environments. A war story is a type of storytelling technique useful to obtain data in interviewing settings. The characteristic of a war story is that it is a detailed description of a problematic situation in a specific setting. Since war stories could be very extended, detailed, and open (the interviewed is free of telling what s/he wants), transcribing and analyzing them becomes a hard and time consuming job. War stories, as well as other story telling techniques, are useful for exploratory studies, in which we are interested on developing theories from the observed data. In our case, we are interested on more practical and focused information, particularly, the knowledge requirements and knowledge flow problems of specific software processes. Nevertheless, through the use of the KoFI methodology in our study we observed some of the same situations reported by Lutters and

Studying Knowledge Flows in Software Processes

63

Seaman, particularly, that maintainers consult people when they have not formal sources available, that the most useful sources are those written by maintainers, that unofficial sources become very valuable in some cases, and that location of knowledge sources is a relevant issue, since when they are difficult to find they are not used.

Conclusion In this paper, we have described the use of the KoFI methodology as a means to study knowledge flows in software processes. The application of the methodology in real settings was also described, along with the results obtained from these applications. As is described in this chapter, the methodology assisted us in the identication of certain knowledge problems in a software process, and in the proposal of alternatives with which to solve them. Furthermore, we consider that one of the main contributions of the study was that of making the members of the studied group aware of the importance of having a KM strategy. They became conscious of some of the KM activities that they were actually carrying out, and of the tools which can facilitate knowledge management in their process. Therefore, we can argue that the usage of KoFI can facilitate the implementation of KM strategies in software processes, particularly if current practices and tools are taken into account when developing those strategies. The main difference between the present work and others that we have found in literature is its focus on attempting to integrate the current working tools as part of the KM strategy, and perhaps as the basis of it. Doing this could reduce the cost of using KM strategies or systems, mainly in small or medium enterprises which are often unable to meet great expenses which, moreover, only render a profit in the long term. As future work we intend to continue evaluating the benefits and limitations of the KoFI methodology in order to measure how it can help to improve software processes´ knowledge flow. Additionally, we are also interested on analyzing the benefits and results of the methodology in settings different to software engineering since we think that the general character of this methodology allows its usage in different domains.

Acknowledgements This work is partially supported by CONACYT, Mexico; the ESFINGE project (TIN2006-15175-C05-05) Ministerio de Educación y Ciencia (Dirección General de Investigación)/ Fondos Europeos de Desarrollo Regional (FEDER), and the MELISA Project (PAC08-0142-3315), Junta de Comunidades de Castilla-La Mancha, Consejería de Educación y Ciencia, both from Spain.

References [1]

Abdullah, M. S., Benest, I., Evans, A., & Kimble, C. (2002, September 2002). Knowledge modelling techniques for developing knowledge management systems. Paper presented at the European Conference on Knowledge Management, Dublin, Ireland.

64 [2] [3] [4] [5] [6] [7] [8] [9] [10] [11] [12] [13] [14] [15] [16] [17] [18]

Oscar M. Rodríguez-Elias, Aurora Vizcaíno, Ana I. Martínez-García et al. Acuña, S. T., Juristo, N., & Moreno, A. M. (2006). Emphasizing human capabilities in software development. IEEE Software, 23(2), 94-101. Anquetil, N., de Oliveira, K. M., de Sousa, K. D., & Batista Dias, M. G. (2007). Software maintenance seen as a knowledge management issue. Information and Software Technology, 49(5), 515-529. Aurum, A., Daneshgar, F., & Ward, J. (2008). Investigating knowledge management practices in software development organizations - an australian experience. Information and Software Technology, 50(6), 511-533. Aurum, A., Jeffery, R., Wohlin, C., & Handzic, M. (Eds.). (2003). Managing software engineering knowledge. Berlin, Germany: Springer. Basili, V. R., & Caldiera, G. (1995). Improve software quality by reusing knowledge & experience. Sloan Management Review, 37(1), 55-64. Basili, V. R., Caldiera, G., & Rombach, H. D. (1994). The experience factory. In J. J. Marciniak (Ed.), Encyclopedia of software engineering (pp. 469-476): John Willey & Sons. Bera, P., Nevo, D., & Wand, Y. (2005). Unravelling knowledge requirements through business process analysis. Communications of the Association for Information Systems, 16, 814-830. Bézivin, J., & Breton, E. (2004). Applying the basic principles of model engineering to the field of process engineering. UPGRADE, V(5), 27-33. Borghoff, U. M., & Pareschi, R. (1997). Information technology for knowledge management. Journal of Universal Computer Science, 3(8), 835-842. Carroll, J. M., & Rosson, M. B. (1992). Getting around the task-artifact cycle: How to make claims and design by scenario. ACM Transactions on Information Systems, 10(2), 181-212. Chapin, N. (2003). Software maintenance and organizational health and fitness. In M. Polo, M. Piattini & F. Ruiz (Eds.), Advances in software maintenance management: Technologies and solutions (pp. 1-31). Hershey, PA. USA: Idea Group Inc. Chapin, N., Hale, J. E., Khan, K. M., Ramil, J. F., & Tan, W.-G. (2001). Types of software evolution and software maintenance. Journal of Software Maintenance and Evolution: Research and Practice, 13(1), 3-30. Chin, G. J., Rosson, M. B., & Carroll, J. M. (1997). Participatory analysis: Shared development of requirements from scenarios. Paper presented at the Conference on Human Factors in Computing Systems (CHI97), Atlanta, GA, USA. Conradi, R., & Jaccheri, L. (1999). Process modelling languages. In J. C. Derniame, B. A. Kaba & D. Wastell (Eds.), Software process (Vol. LNCS 1500, pp. 27-52). Berlin: Springer. Cox, K., Phalp, K. T., Bleistein, S. J., & Verner, J. M. (2005). Deriving requirements from process models via the problem frames approach. Information and Software Technology, 47(5), 319-337. Davenport, T. H. (2007). Information technologies for knowledge management. In K. Ichijo & I. Nonaka (Eds.), Knowledge creation and management: New challenges for managers (pp. 97-117). New York, NY.: Oxford University Press. de Sousa, K. D., Anquetil, N., & Oliveira, K. M. d. (2004, 20-21 June). Learning software maintenance organizations. Paper presented at the 6th International Workshop on Learning Software Organization (LSO 2004), Banff, Canada.

Studying Knowledge Flows in Software Processes

65

[19] Desouza, K. C. (2003). Barriers to effective use of knowledge management systems in software engineering. Communications of the ACM, 46(1), 99-101. [20] Dias, M. G. B., Anquetil, N., & Oliveira, K. M. d. (2003). Organizing the knowledge used in software maintenance. Journal of Universal Computer Science, 9(7), 641-658. [21] Dingsøyr, T. (2005). Postmortem reviews: Purpose and approaches in software engineering. Information and Software Technology, 47(5), 293-303. [22] Dingsøyr, T., & Conradi, R. (2002). A survey of case studies of the use of knowledge management in software engineering. International Journal of Software Engineering and Knowledge Engineering, 12(4), 391-414. [23] Dingsøyr, T., Moe, N. B., & Nytrø, Ø. (2001). Augmenting experience reports with lightweight postmortem reviews. Lecture Notes in Computer Science, 2188, 167-181. [24] García, S., Graettinger, C., & Kost, K. (2006). Proceedings of the first international workshop for process improvement in small settings, 2005 (Special Report No. CMU/SEI-2006-SR-001). Pittsburgh, PA: Carnegie Mellon, Software Engineering Institute. [25] Haggie, K., & Kingston, J. (2003). Choosing your knowledge management strategy. Electronic Journal of Knowledge Management Practice, 4(June), Article 5. [26] Hansen, B. H., & Kautz, K. (2004, November 10-12). Knowledge mapping: A technique for identifying knowledge flows in software organizations. Paper presented at the European Conference on Software Process Improvement (EuroSPI 2004), Trondheim, Norway. [27] Harris, M., Aebischer, K., & Klaus, T. (2007). The whitewater process: Software product development in small it businesses. Communications of the ACM, 50(5), 89-93. [28] Jackson, M. (2005). Problem frames and software engineering. Information and Software Technology, 47(14), 903-912. [29] Jennex, M. E., & Olfman, L. (2005). Assessing knowledge management success. International Journal of Knowledge Management, 1(2), 33-49. [30] Kitchenham, B., Budgen, D., Brereton, P., & Woodall, P. (2005). An investigation of software engineering curricula. The Journal of Systems and Software, 74(3), 325-335. [31] Kitchenham, B. A., Travassos, G. H., Mayrhauser, A., Niessink, F., Schneidewind, N. F., Singer, J., et al. (1999). Towards an ontology of software maintenance. Journal of Software Maintenance: Research and Practice, 11, 365-389. [32] Ko, A. J., Myers, B. A., Coblenz, M. J., & Aung, H. H. (2006). An exploratory study of how developers seek, relate, and collect relevant information during software maintenance tasks. IEEE Transactions on Software Engineering, 32(12), 971-987. [33] Koskinen, J., Salminen, A., & Paakki, J. (2004). Hypertext support for the information needs of software maintainers. Journal of Software Maintenance and Evolution: Research and Practice, 16(3), 187-215. [34] Land, L. P. W., Aurum, A., & Handzic, M. (2001). Capturing implicit software engineering knowledge. Paper presented at the 13th Australian Software Engineering Conference (ASWEC'01), Sydney, NSW, Australia. [35] Laporte, C. Y., Alexandre, S., & Renault, A. (2008). Developing international standards for very small enterprises. IEEE Computer, 41(3), 98-101. [36] Lethbridge, T. C. (2000). What knowledge is important to a software professional? IEEE Computer, 33(5), 44-50.

66

Oscar M. Rodríguez-Elias, Aurora Vizcaíno, Ana I. Martínez-García et al.

[37] Lethbridge, T. C., Singer, J., & Forward, A. (2003). How software engineers use documentation: The state of the practice. IEEE Software, 20(6), 35- 39. [38] Lientz, B. P. (1983). Issues in software maintenance. Computing Surveys, 15(3), 271278. [39] Lindvall, M., & Rus, I. (2003). Knowledge management for software organizations. In A. Aurum, R. Jeffery, C. Wohlin & M. Handzic (Eds.), Managing software engineering knowledge (pp. 73-94). Berlin: Springer. [40] Lutters, W. G., & Seaman, C. B. (2007). Revealing actual documentation usage in software maintenance through war stories. Information and Software Technology, 49(6), 576-587. [41] Maier, R., & Remus, U. (2002). Defining process-oriented knowledge management strategies. Knowledge and Process Management, 9(2), 103-118. [42] Mayrhauser, A. v., & Vans, A. M. (1995). Program comprehension during software maintenance and evolution. IEEE Computer, 28(8), 44-55. [43] Meehan, B., & Richardson, R. (2002). Identification of software process knowledge management. Software Process Improvement and Practice, 7, 47-55. [44] Monk, A., & Howard, S. (1998). The rich picture: A tool for reasoning about work context. Interactions, 5(2), 21-30. [45] Nissen, M. E. (2002). An extended model of knowledge-flow dynamics. Communications of the Association for Information Systems, 8, 251-266. [46] Nissen, M. E., & Levitt, R. E. (2004). Agent-based modeling of knowledge flows: Illustration from the domain of information systems design. Paper presented at the Hawaii International Conference on System Science (HICSS 2004), Big Island, Hi, USA. [47] Nwana, H. S. (1996). Software agents: An overview. Knowledge Engineering Review, 11(3), 205-244. [48] O'Leary, D. E. (1998). Using ai in knowledge management: Knowledge bases and ontologies. IEEE Intelligent Systems, 13(3), 34-39. [49] Oktaba, H. (2005, October 19-20). Moprosoft: A software process model for small enterprises. Paper presented at the First Int. Research Workshop for Process Improvement in Small Settings, Pittsburgh, Pennsylvania. [50] Oliveira, K. M., Anquetil, N., M.G, D., Ramal, M., & Meneses, R. (2003). Knowledge for software maintenance. Paper presented at the Fifteenth International Conference on Software Engineering and Knowledge Engineering (SEKE'03), San Francisco, CA. [51] OMG. (2002). Software process engineering metamodel specification (spem). Retrieved October 29, 2004, from http://www.omg.org/technology/documents/formal/ spem.htm [52] Polo, M., Piattini, M., & Ruiz, F. (2003a). A methodology for software maintenance. In M. Polo, M. Piattini & F. Ruiz (Eds.), Advances in software maintenance management: Technologies and solutions (pp. 228-254). Hershey: Idea Group Inc. [53] Polo, M., Piattini, M., & Ruiz, F. (Eds.). (2003b). Advances in software maintenance management: Technologies and solutions. Hershey, PA, USA: Idea Group Inc. [54] Rao, M. (Ed.). (2005). Knowledge management tools and techniques: Practitioners and experts evaluate km solutions. Amsterdam: Elsevier. [55] Richardson, I., & von Wangenheim, C. G. (2007). Why are small software organizations different? IEEE Software, 24(1), 18-22.

Studying Knowledge Flows in Software Processes

67

[56] Robillard, P. N. (1999). The role of knowledge in software development. Communications of the ACM, 42(1), 87-92. [57] Rodríguez-Elias, O. M., Martínez-García, A. I., Vizcaíno, A., Favela, J., & Piattini, M. (2007a). Identifying knowledge flows in communities of practice. In M. E. Jennex (Ed.), Knowledge management: Concepts, methodologies, tools, and applications (Vol. 2, pp. 841-849). Hershey, PA, USA: Idea Group Press. [58] Rodríguez-Elias, O. M., Martínez-García, A. I., Vizcaíno, A., Favela, J., & Piattini, M. (2008). A framework to analyze information systems as knowledge flow facilitators. Information and Software Technology, 50(6), 481-498. [59] Rodríguez-Elias, O. M., Martínez-García, A. I., Vizcaíno, A., Favela, J., & Piattini, M. (in press). Modeling and analysis of knowledge flows in software processes through the extension of the software process engineering metamodel. International Journal of Software Engineering and Knowledge Engineering. [60] Rodríguez-Elias, O. M., Martínez-García, A. I., Vizcaíno, A., Favela, J., & Soto, J. P. (2007b, June 16). Knowledge flow analysis to identify knowledge needs for the design of knowledge management systems and strategies: A methodological approach. Paper presented at the 9th Intl. Conf. on Enterprise Information Systems (ICEIS 2007), Funchal, Madeira – Portugal. [61] Rodríguez, O. M., Martínez, A. I., Favela, J., Vizcaíno, A., & Piattini, M. (2004a). Understanding and supporting knowledge flows in a community of software developers. Lecture Notes in Computer Science, 3198, 52-66. [62] Rodríguez, O. M., Martínez, A. I., Vizcaíno, A., Favela, J., & Piattini, M. (2004b, 20-24 Sep.). Identifying knowledge management needs in software maintenance groups: A qualitative approach. Paper presented at the Fifth Mexican International Conference on Computer Science (ENC'2004), Colima, México. [63] Ruiz, F., Vizcaíno, A., Piattini, M., & García, F. (2004). An ontology for the management of software maintenance projects. International Journal of Software Engineering and Knowledge Engineering, 14(3), 323-349. [64] Rus, I., & Lindvall, M. (2002). Knowledge management in software engineering. IEEE Software, 19(3), 26-38. [65] Schneider, K., von Hunnius, J.-P., & Basili, V. R. (2002). Experience in implementing a learning sofware organization. IEEE Software, 19(3), 46-49. [66] Scholl, W., König, C., Meyer, B., & Heisig, P. (2004). The future of knowledge management: An international delphi study. Journal of Knowledge Management, 8(2), 19-35. [67] Seaman, C. (2002, Octubre 2002). The information gathering strategies of software maintainers. Paper presented at the International Conference on Software Maintenance (ICSM'2002), Montreal, Canada. [68] Singer, J. (1998, 16-19 November). Practices of software maintenance. Paper presented at the International Conference on Software Maintenance, Bethesda, Maryland, USA. [69] Singer, J., Lethbridge, T. C., Vinson, N., & Anquetil, N. (1997). An examination of software engineering work practices. Paper presented at the CASCON'97, Toronto, Ontario, Canada. [70] Sparrow, J. (2001). Knowledge management in small firms. Knowledge and Process Management, 8(1), 3-16.

68

Oscar M. Rodríguez-Elias, Aurora Vizcaíno, Ana I. Martínez-García et al.

[71] Stewart, T. A. (2002). The case against knowledge management. Business 2.0, 3(February), 80. [72] Strohmaier, M., & Tochtermann, K. (2005). B-kide: A framework and a tool for business process-oriented knowledge infrastructure development. Journal of Knowledge and Process Management, 12(3), 171-189. [73] Tiwana, A. (2004). An empirical study of the effect of knowledge integration on software development performance. Information and Software Technology, 46(13), 899-906. [74] Vizcaíno, A., Favela, J., Piattini, M., & García, F. (2003, 2003). Supporting software maintenance in web repositories through a multi-agent system. Paper presented at the International Atlantic Web Intelligence Conference (AWIC’2003). [75] Ward, J., & Aurum, A. (2004). Knowledge management in software engineering describing the process. Paper presented at the 15th Australian Software Engineering Conference (ASWEC 2004), Melbourne, Australia. [76] Woitsch, R., & Karagiannis, D. (2003). Process-oriented knowledge management systems based on km-services: The promote approach. International Journal of Intelligent Systems in Accounting, Finance & Management, 11, 253-267. [77] Wong, K. Y. (2005). Critical success factors for implementing knowledge management in small and medium enterprises. Industrial Management & Data Systems, 105(3), 261279. [78] Zhuge, H. (2002). Knowledge flow management for distributed team software development. Knowledge-Based Systems, 15(8), 465-471.

In: Software Engineering and Development Editor: Enrique A. Belini, pp. 69-92

ISBN: 978-1-60692-146-3 © 2009 Nova Science Publishers, Inc.

Short Communication C

SOFTWARE PRODUCT LINE ENGINEERING: THE FUTURE RESEARCH DIRECTIONS

1

Faheem Ahmed1,a, Luiz Fernando Capretz2,b and Muhammad Ali Babar3,c

College of Information Technology, United Arab Emirates University, Al Ain, United Arab Emirates 2 Department of Electrical & Computer Engineering, Faculty of Engineering, University of Western Ontario, London, Ont., Canada 3 Lero, University of Limerick, Ireland

Abstract The recent trend of switching from single software product development to lines of software products in the software industry has made the software product line concept viable and widely accepted methodology in the future. Some of the potential benefits of this approach include cost reduction, improvement in quality and a decrease in product development time. Many organizations that deal in wide areas of operation, from consumer electronics, telecommunications, and avionics to information technology, are using software product lines practice because it deals with effective utilization of software assets and provides numerous benefits. Software product line engineering is an inter-disciplinary concept. It spans over the dimensions of business, architecture, process and organization. The business dimension of software product lines deals with managing a strong coordination between product line engineering and the business aspects of product line. Software product line architecture is regarded as one of the crucial piece of entity in software product lines. All the resulting products share this common architecture. The organizational theories, behavior and management play critical role in the process of institutionalization of software product line engineering in an organization. The objective of this chapter is to discuss the state of the art of software product line engineering from the perspectives of business, architecture, organizational management and software engineering process. This work also highlights and

a

E-mail address: [email protected] E-mail address: [email protected] c E-mail address: [email protected] b

70

Faheem Ahmed, Luiz Fernando Capretz and Muhammad Ali Babar discusses the future research directions in this area thus providing an opportunity to researchers and practitioners to better understand the future trends and requirements.

1.1. Introduction In today’s digitized economy, organizations endeavor, to the best of their abilities, to capture a major portion of the market share to be profitable. Software organizations are also continuously innovating and improving business operations such as technology, administration, and product development process. Their major concern is the effective use of software assets, thus reducing considerably the development time and cost of software products to capture market segments. For many organizations that deal in wide areas of operation, from consumer electronics, telecommunications, and avionics to information technology, the future of software development is in software product lines. Software product lines are promising, with the potential to substantially increase the productivity of the software development process and emerging as an attractive phenomenon within organizations that deal with the software development. Software product lines involve assembling products from existing core assets, and then growing those core assets continuously as the production proceeds. The software industry has shown a growing interest in the concept of software product line. One of the major concerns of software development organizations is the effective utilization of software assets, thus reducing considerably the development time and cost of software products. Many organizations that deal in wide areas of operation, from consumer electronics, telecommunications, and avionics to information technology, are using software product lines practice because it deals with effective utilization of software assets. Clements et al. [1] report that software product line engineering is a growing software engineering subdiscipline, and many organizations including Philips, Hewlett-Packard, Nokia, Raytheon, and Cummins are using it to achieve extraordinary gains in productivity, time to market, and product quality. Clements 2] defines the term software product line as a set of softwareintensive systems sharing a common, managed set of features that satisfy the specific needs of a particular market segment or mission, and are developed from a common set of core assets in a prescribed way. Some other terminologies for “software product line” that have been widely used in Europe are “product families,” “product population,” and “system families”. The concept of a software product line is a comprehensive model for an organization building applications based on common architectures and other core assets [3]. Clements [2] defines the term “software product line” as a set of software-intensive systems sharing a common managed set of features that satisfy the specific needs of a particular market segment or mission and that are developed from a common set of core assets in a prescribed way. The Software Engineering Institute (SEI) proposes the Product Line Technical Probe (PLTP) [4], which is aimed at discovering an organization’s ability to adopt and succeed with the software product line approach. The framework is divided into three essential activities: product development, core asset development, and management. van der Linden [5] pointed out that in 1995 the Architectural Reasoning for Embedded Systems (ARES) project began in Europe to provide architectural support for developing product families. In the overview of another European project, Engineering Software Architecture, Processes and Platforms for SystemFamilies (ESAPS) [6], a system family is defined as a group of systems sharing a common,

Software Product Line Engineering: The Future Research Directions

71

managed set of features that satisfy core needs of a scoped domain. The main objectives of system families are to reduce development efforts and to handle the impact of growing system complexity. Ommering [7] introduced another term called “product population”, which is a collection of related systems based on similar technology but with many differences among them. Northrop [8] stresses that fielding a product line involves core asset development and product development using core assets under the aegis of technical as well as organizational management. The essential activities of the software product line process are core asset development, product development, and management. All the three activities are linked and are highly iterative in nature. The link among the activities establishes a communication path among them to provide feedback. There is no fixed order of execution of these activities. They can be performed in any order and they give feedback to other activities for their execution. The feedback received at each activity is used to accommodate changes and modify the process. The software product line process can be described in terms of four simple concepts. The four simple concepts that interact with each other are: software assets, a decision model for products, a production mechanism process, and output products that result from software product line activity. Krueger [9] states that software asset inputs are a collection of software assets that can be configured and assembled in different ways to create all of the products in a product line. The decision model for products elaborates the requirements of the products within a product line. Production mechanism and process defines the procedures for assembling and configuring products from existing software assets. Software products are the collection of all products that can be produced from the product line. Associated processes are performed with those basic four concepts for the establishment of a software product line. Core assets in a software product line may include architecture, reusable software components, domain models, requirement statements, documentation, schedules, budgets, test plans, test cases, process descriptions, modeling diagrams, and other relevant items used for product development. There is no specific definition for core asset inclusion, except that it is an entity used for development purposes. The goal of core asset development is to establish the production capability of developing products [2]. The major inputs to the core asset development activity are: product constraints, styles, patterns, frameworks, production constraints, production strategy, and the inventory of pre-existing assets. The outputs of core assets development are software product line scope, core assets and the production plan. Software product line scope describes the characteristics of the products developed. The production plan gives an in-depth picture how products will be developed from core assets. Core assets are those entities that may be used in the product development. The collection of core assets is termed as core asset repository and the initial state of the core asset repository depends upon the type of approach being used to adopt software product line approach within an organization. In product development activity, products are physically developed from the core assets, based on the production plan, in order to satisfy the requirements of the software product line. The essential inputs of product development activity are requirements, product line scope, core assets and the production plan. Requirements describe the purpose of the product line along with functionalities and characteristics of the products developed. Product line scope describes qualification criteria for a product to be included or excluded from software product line based on functional and non-functional characteristics. The production plan describes a

72

Faheem Ahmed, Luiz Fernando Capretz and Muhammad Ali Babar

strategy to use the core assets to assemble products. A product line can produce any number of products depending upon the scope and requirements of the software product line. The product development activity iteratively communicates with core asset activity and adds new core assets as products are produced and software product line progresses. Management plays a vital role in successfully institutionalising the software product line within an organization, because it provides and coordinates the required infrastructure. Management activity involves essential processes carried out at technical and organizational levels to support the software product line process. It ensures that necessary resources must be available and well coordinated. The objective of “Technical Management” is to oversee the core asset and product development activities by ensuring that the groups who build core assets and the groups who build products are engaged in the required activities, and are following the processes defined for the product line [4]. Technical management plays a critical role in decision-making about the scope of software product line based on requirements. It handles the associated processes of software development. Northrop [8] summarized the responsibilities of organizational management, which are: structuring an organization, resource management and scheduling, cost control and communication. Organizational management deals in providing a funding model for the software product line in order to handle cost constraints associated with the project. It ensures a viable and accurate communication and operational path between essential activities of software product line development because the overall process is highly iterative in nature. The fundamental goal of the organizational management is to establish an adoption plan, which completely describes a strategy to achieve the goals of software product line within an organization. The major responsibility of the management is to ensure proper training of the people to become familiar with the software product line concepts and principles. Management deals with external interfaces for smooth and successful product line and performs market analysis for internal and external factors to determine the success factor of software product line. Management performs organizational and technical risk analysis and continues tracking critical risk throughout the software product line development. van der Linden [5] reports that the term “product family” or “system family” is used in Europe whereas in the United States the term “software product line” is commonly used. As Europeans were working on product family engineering, researchers in the United States founded the SEI’s product line initiative, the major reason for this being that until 1996 the United States and European communities in this field worked independently. The objective of the software product line is to address the specific needs of a given business. Krueger [9] considers that the objective of a software product line is to reduce the overall engineering effort required to produce a collection of similar systems by capitalizing on the commonality among the systems and by formally managing the variation among the systems. A software product line gives an excellent opportunity to establish a production facility for software products based on a common architecture. To capture various market segments, it provides a means for the reuse of assets, thus reducing development time and the cost of software products. The software product line increases the quality and reliability of successive products, thereby gaining the confidence of customers. According to van der Linden [5], whenever an organization wants to establish product family development it must keep a number of things under consideration. In Europe, the acronym BAPO [5], is very popular for defining the process components associated with software product lines. BAPO is considered critical in its consideration of how products resulting from software product lines make a

Software Product Line Engineering: The Future Research Directions

73

profit. Software engineering, business, management and organizational sciences provide foundations for the concept of software product line engineering, and thus, it has become an inter-disciplinary concept.

1.2. Businesss of Software Product line Engineering Today, all businesses are experiencing greater competition, and customers’ expectations continuously increase as technology advances at an unprecedented rate of growth. The rapid and continual changes common to the present business environment not only affect business itself but also have a profound impact on production. Software is perhaps the most crucial piece of a business entity in this modern marketplace, where important decisions need to be made immediately. Organizations that fail to respond appropriately do not survive longer. The keys to success are in continuously monitoring customers and the competitors and in making improvement plans based on observations and measurements. Business is perhaps the most crucial factor in a software product line, mainly due to the necessities of long-term strategic planning, initial investment, longer payback period and retaining the market presence. Business is perhaps the most crucial dimension in the software product family process, mainly due to the necessities of long-term strategic planning, initial investment, longer payback period, and retention of the market presence. The “Business” in BAPO is considered critical because it deals with the way the products resulting from software product lines make profits. Bayer et al [10] at Fraunhofer Institute of Experimental Software Engineering (IESE) develop a methodology called PuLSE (Product Line Software Engineering) for the purpose of enabling the conception and deployment of software product lines within a large variety of enterprise contexts. PuLSE-Eco is a part of PuLSE methodology, deals with defining the scope of software product lines in terms of business factors. Pulse-Eco identifies various activities, which directly address the business needs of software product lines such as: system information, stakeholder information, business objectives and benefit analysis. van der Linden et al. [11] identify some main factors in evaluating the business dimension of software product line such as: identity, vision, objectives and strategic planning. They classified the business maturity of software product line into five levels in the ascending order: reactive, awareness, extrapolate, proactive and strategic. Clements and Northrop [4] highlight customer interface management, market analysis, funding, and business case engineering as important activities from the perspectives of managing the business of software product line. Kang et al. [12] present a marketing plan for software product lines that includes market analysis and marketing strategy. The market analysis covers need analysis, user profiling, business opportunity, time to market and product pricing. The marketing strategy discusses product delivery methods. Toft et al. [13] propose “Owen molecule model” consisting of three dimensions of social, technology and business. The business dimension deals with setting up business goals and analyzing commercial environment. Fritsch and Hahn [14] introduce Product Line Potential Analysis (PLPA), which aims at examining the product line potential of a business unit through discussions with managers of the business unit because in their opinion they know the market requirements, product information and business goals of the organization. Schmid and Verlage [15] discuss the successful case study of setting up software product line at Market Maker and highlights market and competitors analysis, vision of potential market segment,

74

Faheem Ahmed, Luiz Fernando Capretz and Muhammad Ali Babar

and products as significantly important activities. Ebert and Smouts [16] weight marketing as one of the major external success factors of product line approach and further concluded that forecasting, ways to influence market, strong coordination between marketing and engineering activities, are required for gaining benefits from product line approach. Strategic plans are the focus of an organization’s endeavors to accomplish the desired level of achievement in a particular area. Strategic planning starts with elaborating strategic objectives. Niemelä [17] highlighted eight different strategies for adopting software product lines in an organization: minimizing risk, extending market share, maximizing end-user satisfaction, balancing cost and potential, balancing cost, customer satisfaction and potential, and maximizing potential. Niemelä [17] further concluded that a company has to evaluate the current status of their business, architecture, process, and organizational issues before making a decision about choosing one strategy out of those in order to achieve desired benefits. The software product line process needs resources, which must be delegated in strategic plans. Strategic planning must clearly outline what is to be developed from the software product line in order to gain competitive advantages and capture market segments to achieve strategic targets. Strategic plans are required to maintain organizational wide efforts to identify and exploit attractive long-range business opportunities by having the software product line in practice. The benefits of being the first in the market have long been recognized in the business sector; pioneers often gain a sustainable competitive advantage over followers, because, initially, they are the only solution-providers in a particular market segment. Thus, they usually capture a bigger portion of the market because they were first. It becomes very difficult for successors to gain a share of the market segment, especially in the case of software, where migration to other software is relatively uncommon. The timing for technology-based products entering the market is even more critical for the profitability and competitive position of an organization. The right product at the right time has a high potential of success. Order of market entry is perceived as a crucial business decision, with a long-lasting and profound impact on the performance of an organization in capturing and retaining the market. Appropriate timing to launch a software product into the market is even more essential for software development organizations. Timing is essential in launching a new product from the software product line in order to capture major shares of the market. The order of entry to the market depicts the delivery schedule for the software product family and provides guidelines to developers about development schedules. Organizations consider brand name a crucial catalyst of business success. A brand is regarded as both a promise of quality to customers and a point of comparison with other products or services. Bennett [18] defined brand as a name, term, sign, symbol, design, or any combination of these concepts that is used to identify the goods and services of a seller. Brand name products generally have high potential for increasing an organization’s business. Branded product serve, as an interface between customers and the organization, and loyalty to a brand is a kind of word-of-mouth advertisement from customers. Brand name strategy has also been successfully adopted in software development. Many successful brands in software, such as Windows®, AutoCAD®, and MATLAB®, successfully retain a significant number of customers, thus capturing a major portion of the market segment. But currently there is gab between software product line engineering and brand name strategy; many different products not originating from one software product line can be plugged under one marketed product line. Windows® is a working example of this scenario. Despite this fact there are successful cases that are using brand name strategy in software product lines concept. The product line

Software Product Line Engineering: The Future Research Directions

75

of Symbian operating system for mobile phones is an example of this scenario. Long range of products under this brand name is currently successfully installed in the handsets of Nokia, Sony Ericsson, Samsung and Panasonic etc. Jaasksi [19] presented the case study of developing software product line of mobile browsers under the brand name of “Nokia Mobile Browser” at Nokia is also an example of current use of brand name strategy in software product lines. The concept of market orientation provides an advantage over competitors by identifying what customers’ want, and then offering products that are different and superior to those offered by competitors. Market orientation deals with the acquisition, sharing, interpretation, and use of information about customers and competitors, both of which have a significant impact on the performance of the business. Birk et al. [20] defines market orientation in context of software product lines as whether the organization targets a specific market segment without a specific customer in mind or addresses individual customer projects. The software product line deals with developing a considerable number of products to capture various market segments, thus providing justification for a product line. Market orientation provides imperative information about the concerns and requirements of customers, which needs to be accommodated in the successive products from a product line. Pulse-Eco [21] illustrates various activities associated with market orientation for successful adoption of software product lines concept in an organization. It considers collecting and analyzing stakeholders’ information is helpful in defining the product line scope. Business success is highly dependent on the extent to which customers are satisfied with an organization’s product and services, as well as how they win the loyalty of customers by improving their relationships management. Relationships management plays a significant role in successful software product line development. Excellent working relationships with customers allow the developers to improve the performance and functionalities of successive products from the product line by better understanding the customers’ requirements and learning about market trends from the end users. The software product line can play a significant role in the business vision because it tends to produce long-term benefits to the organization. A clear statement about business vision will guide practitioners of the software product line to establish a production facility in order to meet the future goals of the organization. By including the software product line in the business vision, an organization can stream line its business operations in order to capitalize on its market audience for profitable venture. Wijnstra [22] concluded that a complete business roadmap is needed to describe what is expected from the software product lines in the years to come and how it will fit in the plan for the release of new products. The key to a successful business in today’s competitive environment is innovation. Organizations are continuously adopting innovations in major areas of business operations, such as technology, administration, and production processes. . Organizations with designs on capturing a major share of the market, in order to increase business, spend heavily on research and development. Business objectives influence research and development efforts because the order of a product’s entry into the market can make a significant difference in achieving strategic goals. Thus, research and development in technology, administration, processes, and product produce enduring results. The software product line is a relatively new concept, and a lot of research and development in process definition and development methodology is in progress. The research is occurring at various levels of industry and academia to improve the process and product development activity of the software product line for the successful industrialization of this valuable concept. Organizations are trying to institutionalize this concept in innovative ways to make the most

76

Faheem Ahmed, Luiz Fernando Capretz and Muhammad Ali Babar

effective use of it. Böckle [23] highlighted some measures of innovation management in software product line organizations, which include a planned innovation process, clear roles and responsibilities definition for innovation management structure. Böckle [23] further stressed that the evolution of the product portfolio, platform, variability model, and reference architecture shall be planned with further innovations in mind. The business of software product line engineering has a profound impact on the long term planning and vision of the organization in the market place. The significance of the business factor in product line engineering requires a better understanding of various non-software development factors which originates from business theory. This makes software product line engineering multi-disciplinary paradigm which needs contributions from many experts in different areas of knowledge and expertise. Although business has always been highlighted as one of the critical success factors in product line engineering but has given least attention by product line engineering community to streamline the concept and integrate with software development efforts. Some of the leading areas of core research in software product line engineering and business factors are as follows: ƒ ƒ ƒ ƒ ƒ

ƒ ƒ ƒ

ƒ

ƒ ƒ ƒ ƒ ƒ

Development of a business case and methodology to evaluate the significance in terms of cost and benefits for an organization. An organizational wide economic model for developing and managing software product line engineering, emphasizing return on investment. A methodology to develop production plan for the resulting products and allocation of resources. The issues of translating the business requirements into product line requirements which involves from non-technical (business group) to technical (architecture group). The role and impact of strategic planning of the organization in developing and managing software product line. How organization can achieve its strategic goals using the product line approach. Decision planning and implementation in allocating and committing resources to achieve the long-range business goals. Marketing plans to identify and exploit attractive long-range business opportunities. How market orientation provides imperative information about the concerns and requirements of customers, which need to be accommodated in successive products from a product line. Customer orientation enables an organization to develop customer-centered products. How this information assists in the domain- and application-engineering activities of the software product line development to capture market segments. Evaluation of appropriate timing to launch a software product into the market from product line in order to maximize the profit. The role of business vision in managing and developing software product line. Knowledge management of customers, marketing and competitors. Methodology to evaluate the business performance of the organization dealing with software product line engineering. Methodology to evaluate the practice of various key business factors in organization.

Software Product Line Engineering: The Future Research Directions

77

1.3. Institutionalization of Software Product Line Engineering The “Organization” in BAPO is considered critical because it deals with the way the organization responds, adopts and institutionalizes this concept. Institutionalization is the process by which a significantly new structure or practice is incorporated into a system of existing structures and practices [24]. Clements and Northrop [4] elaborate the institutionalization of software product line in an organization from the perspectives of product development and core assets development. Institutionalizing a software product line from the aspects of product development process anticipate the product development as a routine and predictable activity in an organization to achieve the product line goals of the organization. Clements and Northrop [4] emphasis that institutionalizing a software product line from the perspectives of managing and developing a core assets repository for software product line involves improving the processes that are associated with building, maintaining, and evolving the core assets and making those processes a part of standard organizational practice. In short institutionalization of software product lines refers to the wide acceptance of the concept in the roots of the organization. It involves integrating or improving the processes within organization that are associated with a product line infrastructure, and introducing those processes as a part of organizational character. The whole institutionalization process involves an organizational level culture and strong commitments in acquiring knowledge, skills and motivations to effectively initiate, launch and manage software product lines. Institutionalization of software product lines require that the concept has been entrenched at all levels of the organization, and it is supported with a necessary infrastructure of organizational wide guidelines, required training, and required resources. Successfully institutionalization of software product line in an organization has a profound impact on the product development behavior of the organization. It changes the mindset of the organization from single system development to a family of software products. The organizational theory focuses on the design and structures of the organization dealing in software product line. The organizational behavior aims at understanding the behavior, attitude and performance of the people. Software product line requires enriching this concept within the roots of the overall organizational behavior. Organizational management plays a vital role in successfully institutionalizing software product line within an organization because it provides and coordinates the infrastructure required. Initiating and launching a software product line within an organization to gain benefits out of this approach is not sufficient. The alignment of organizational theory, organizational management, and organizational behavior are required in the process of institutionalization of software product line in an organization. Thus, organizational factors play a key role in institutionalizing software product lines within an organization. Software product line is an inter-disciplinary concept, which has its roots in software engineering, business, management and organizational sciences. The organization in the business of software product line has to deal with multiple organizational factors in addition to their efforts in software development in order to institutionalize software product line, which in turn has the potential to achieve maximum benefits out of this approach. The organizational dimension is perhaps the least addressed area in software product line research due to relatively a new concept in software engineering paradigms. Much of the efforts have been spent on process, architecture and business aspects of the product line. Some scenarios of organizational structure for software product line are presented. The

78

Faheem Ahmed, Luiz Fernando Capretz and Muhammad Ali Babar

researchers generally highlight that domain-engineering unit and several applicationengineering units are required from organizational structure standpoint. Bosch [25] presents four organizational models for software product lines: development department, business units, domain engineering units, and hierarchical domain engineering units. Bosch [25] also points out a number of factors that influence the organizational model such as geographical distribution, project management maturity, organizational culture and the type of systems. Macala et al. [26] report that software product line demands careful strategic planning, a mature development process, and the ability to overcome organizational resistance. Dikel et al. [27] share their experiences about initiating and maintaining software product lines at Nortel and discuss organizational, management and staffing issues grouped into a set of six organizational principles which they believe are critical in the long-term success of a software product line. Jacobsen et al. [28] focus on roles and responsibilities of personals within organizations dealing with software product lines. Mannion [29] elaborates that the management issues, organizational structure, culture and learning in context of successfully adopting the concept of software product line engineering needs close attention. Koh and Kim [30] concludes that all members of an organization experience and share their own success stories under existing processes and organizational structure in order to successfully adopt software product line approach. Clements and Northrop [4] discuss organizational issues of software product line and identified four functional groups, i.e. the architecture group, the component-engineering group, the product line support group and the product development group. The organizational dimension of software product lines deal with the way the organization is able to deal with complex relationships and many responsibilities [11]. Toft et al. [13] propose “Owen molecule model” consisting of three dimensions of organizational, technology and business. The organizational dimension of Owen molecule model deals with teams hierarchy, individual roles, operational models, individual interaction and communication etc. Introducing software product line practice to an organization significantly impacts the entire organization by fundamentally changing development practices, organizational structures, and task assignments [13]. Bayer et al. [32] at Fraunhofer Institute of Experimental Software Engineering (IESE) develop a methodology called PuLSE (Product Line Software Engineering) for the purpose of enabling the conception and deployment of software product lines within a large variety of enterprise contexts. PuLSE-BC is a technical component of PuLSE methodology and it deals with the ways to baseline organization and customized the PuLSE methodology to the specific needs of the organization. One of the support components of PuLSE is organization issue, which provide guidelines to set up and maintain the right organization structure for developing and managing product lines. According to Birk et al. [31] introducing product line development to an organization can fundamentally change the development practices, organizational structures, and task assignments. These changes can in turn impact team collaboration and work satisfaction. Verlage and Kiesgen [33] report the case study of successful adoption of software product line and conclude that organizational structure and change management are significantly important areas of concern. Organizational culture refers to the working environment in an organization. Some of the key process activities of software product line engineering, including domain engineering, software product line requirements engineering, commonality and variability management and business case engineering etc., require a lot of team effort, group discussion and innovation. The studies in organizational culture highlight two types of cultures: closed and

Software Product Line Engineering: The Future Research Directions

79

open. In closed organizational cultures, the decisions are made at the higher levels and are directly dictated to the lower levels without considering the views and observations of most employees. In contrast, open organizational cultures make decisions on the basis of discussions and employee involvement. Software product line engineering requires a culture of openness, where employees have the chance to participate in discussions and have the power to express their views. For example, variability management is one of the critical process elements that require an active involvement from various parts of the organization, such as the business unit and the development unit, to specify areas for expansion in the product line architecture and introducing product specific functionalities. An organizational culture that supports teamwork, sharing of experiences, innovation and learning has relatively greater potential institutionalizing software product line engineering. Particularly, an organization with a culture that supports the reusability of software assets is more likely to succeed in moving from single product development to a systematic line of products. Organizational commitment concerns the willingness of individuals and groups to achieve the long term strategic objectives of an organization. The payback period of software product line engineering is relatively longer than the single product development approach. Consequently, this transitional period requires a strong commitment from individuals, groups and management to adopt the software product line engineering concept and to exercise patience with its development process. The organizational policies such as business vision and strategic planning must highlight the concept of software product line engineering as a priority in order to reflect the organizational commitments. Furthermore, these policies must be well communicated to the employees so that they understand the significance of this approach in achieving the organizational goals. As well, the success of any long-term strategy in an organization necessitates the commitment of its employees. The management has to create a positive working environment in order to increase the level of employee commitment. Such an environment can be achieved through well-defined job placement, promotion strategy, appreciation and reward system, job security and competitive compensation. An organization is the planned coordination of activities of a number of people for the achievement of some common, explicit purpose or goal, through a division of labor and function, and through a hierarchy of authority and responsibility [34]. Organizational theories provide guidelines for developing organizational structures in order to accomplish the goals of a company. Wilson and Rosenfeld [35] define organizational structure as the established pattern of relationships between the parts of an organization, outlining communication as well as control and authority. According to Gordon [36] organizational structure refers to the delineation of jobs and reporting relationships in an organization and coordinates the work behavior of employees in accomplishing the organization’s goals. The structure of an organization is generally not a static phenomenon, since organizations tend to change their structures under the circumstances of changing goals or technologies. The rapid and continual changes common to the present technological environment necessitate that organizations adopt changes through a well defined change management plan. Beckhard and Harris [37] consider organizational change as a movement from the present state of the organization to some future or target state. Furthermore, Todd [38] defines change management as a structured and systematic approach, which provides a conceptual framework that encompasses strategy, politics, people and process. Cao et al. [39] observe that organizational change shows the diversity of an organization, and it also illustrates the

80

Faheem Ahmed, Luiz Fernando Capretz and Muhammad Ali Babar

integration of technical and human activities that have interrelated functions in the organization. The successful implementation of any process methodology ultimately depends on how people perceive that change. A certain degree of resistance is quite normal when a new technology is introduced to an organization. However, this resistance will disappear if people understand that the change is positive and is in their best interest as well as that of the organization. Effective change management therefore depends partly on how the strategy is communicated to the people responsible for the implementation. When people interact with each other, the potential for conflict is present. This potential exists in different areas, as it could be either personal or task related. Walls and Callister [40] maintain that conflict is a process in which one party perceives that its interests are being opposed or negatively affected by another party. Conflict management consists of diagnostic processes, interpersonal styles, negotiating strategies, and other interventions that are designed to avoid unnecessary conflict and to reduce or resolve excessive conflict [41]. Hellriegel et al. [42] introduce four basic forms of conflicts in an organization: goal, cognitive, affective, and procedural. Moreover, Jehn [43] distinguishes between two kinds of intra-group conflict: task conflict and relationship conflict. Task conflict is a perception of disagreement among group members or individuals regarding the content of their decisions. It involves differences in viewpoints, ideas and opinions, whereas relationship conflict is a perception of interpersonal incompatibility and includes annoyance and animosity among individuals [44]. In the software product line engineering, organizational learning can be classified into two domains: external and internal. External learning involves necessary knowledge about customers, competitors, external environments and market segments. This knowledge is necessary in order to effectively utilize the product line by exploiting product characteristics. The domain engineering, the product line requirements and the business case engineering, etc. require that the organization has established procedures and a means to acquire external learning. Overall, this type of learning helps an organization to capture a major market share. Internal learning, on the other hand, requires acquiring, transferring and sharing a software product line methodology, ideas for process improvement and an understanding of the cross functional requirements of product lines in individuals, groups and the organization. Learning is a continuous process, especially for organizations that attempt to institutionalize software product lines. In particular, learning from experience and mistakes further facilitates improvement in the software product line engineering process. One of the major concerns of software development organizations is the effective utilization of software assets, which has the potential to considerably reduce the time and cost of developing software products. Software is perhaps the most crucial piece of business entity in this modern marketplace, where important decisions need to be made immediately. The studies in organizational behavior help in understanding how people, as individuals and groups, deal with managing and developing product line engineering in an organization. The relatively longer payback period of software product line engineering requires a consistency in organizational behavior in order to achieve the strategic objectives of the organization. Establishing a software product line requires setting up the internal structure of the organization and other supporting mechanisms, such as coordination and communication. The concept of a software product line entails a structure of overlapping processes rather than fixed and static ones. The theoretical foundations of this concept divide the overall engineering process into two broad areas, application and domain engineering, and involve a

Software Product Line Engineering: The Future Research Directions

81

stronger coordination and communication between them. The identification and mapping of the roles to the engineering processes requires interpretation and action from management. Verlage and Kiesgen [45] present a case study documenting the successful implementation of software product lines in their organization. As a result, they report that the roles and mapping of the roles to the processes are not fixed; rather, they are interchangeable, or more precisely, dynamic. The organizations that have well defined structures incorporating clearly identified roles of individuals, in addition to strong coordination and communication, are more likely to institutionalize a software product line in comparison to the organizations with structures not supporting coordination and communication. The process of evolving from single product development to a line of products is a significant change in an organization. During this procedure, almost every software development activity needs to be changed. For example, in the case of requirements engineering, an organization has to deal with product specific requirements engineering as well as product line specific requirements engineering. The product specific requirements engineering involves identifying the variability among products, whereas product line requirements engineering entails detecting the commonality among products. Furthermore, there is need to introduce trade off analysis for commonality and variability management. Introducing a new practice such as a product line is relatively difficult in the existing setup of an organization, especially if it is not being introduced with a proper change management plan. Even the best strategy is bound to fail if there is a consistent resistance to innovation and new technology from within the organization. Organizations that communicate the importance of this change via clear guidelines and the establishment of a road map for their employees are more successful in institutionalizing software product lines. Although organization has always been highlighted as one of the critical dimension in product line engineering but has given least attention by product line engineering community to streamline the concept and integrate with software development efforts. Some of the leading areas of core research in software product line engineering and organization dimension are as follows: ƒ ƒ

ƒ

ƒ ƒ ƒ ƒ ƒ

Conflict management planning to resolve and handle conflict in an organization dealing with product line approach. The organizational structure needs to be explored in order to provide a suitable structure which defines specific roles and responsibilities of object. Many traditional organizational structures have been studied for the application in product line environment but they need to be enhanced to accommodate the product line concept. Organizational learning procedures and guidelines to adopt product line approach and switching from traditional product development for single system to line of products. A study to develop strategies to incorporate and monitor the organizational communication process. Change management plans and implementation procedures. Effective utilization of core assets and their management. Developing plans to start and maintain an infrastructure for product line development. Knowledge management in organization for effective use and dissemination of knowledge across the boundaries of the organization.

82

Faheem Ahmed, Luiz Fernando Capretz and Muhammad Ali Babar ƒ ƒ ƒ

Human resource management across organization to provide necessary resources for product line infrastructure. Inter group trust management to enhance the productivity of the product line process. A methodology to assess the organizational dimension of software product line process and to define improvement plans.

1.4. Software Product Line Architecture Software architecture has been a key area of concern in software industry due to its profound impact on the productivity and quality of software products. This is even more crucial in case of software product line, because it deals with the development of a line of products sharing common architecture and having controlled variability. Software architecture has a history of evolution and over a decade the software industry is observing and reporting refinements and advancements. Now the trends in software architecture for single product development have turned into software product line architecture for line of resulting products. Software architecture is the structure of the components of a program or system, their interrelationships, and the principles and guidelines governing their design and evolution [46]. Software architecture has a long history of evolution and in this modern age this transformation leads towards software product line architecture, where the concern is not a single product development rather the focus is on multiple product development by sharing the same architecture. Pronk [47] defines software product line architecture as an ultimate reuse in which the same software in reused for an entire class of products with only minimal variations to support the diversity of individual product family members. According to Jazayeri et al. [48] software product line architecture defines the concepts, structure, and texture necessary to achieve variation in features of variant products while achieving maximum sharing parts in the implementation. Mika and Tommi [49] further elaborate that software product line architecture can be produced in three different ways: from the scratch, from existing product group, or from a single existing product. Software product-line architecture is a powerful way to control the risks and take advantage of the opportunities of complex customer requirements, business constraints, and technology, but its success depends on more than technical excellence [50]. The software product line architecture captures the central design of all products and allows for the expression of variability and commonalities of the product instances, the products are instantiated by configuring the architecture and customizing components in an asset library [51]. The “Architecture” in BAPO is considered critical because it deals with the technical means to build an architecture that is aimed to share by a number of products from the same family. Van der Linden et al. [11] identify some main factors in evaluating the architecture dimension of software product line such as: software product family architecture, product quality, reuse levels and software variability management and classify the architecture maturity of software product line into five levels in the ascending order: independent product development, standardized infrastructure, software platform, variant products and self-configurable products. Birk et al. [31] conclude that explicit documentation of the software product line architecture, platform features, and generic interfaces is important for the product teams to understand the reusable assets.

Software Product Line Engineering: The Future Research Directions

83

The methodologies developed for software product line development either in general or specific to particular application domain consider domain engineering as an integral activity of the overall product line process and has profound impact on building the architecture for the product line. Bayer et al. [52] at Fraunhofer Institute of Experimental Software Engineering (IESE) develop a methodology called PuLSE (Product Line Software Engineering) for the purpose of enabling the conception and deployment of software product lines within a large variety of enterprise contexts. PuLSE-DSSA is a part of PuLSE methodology, which deals with developing the reference architecture for software product line. Knauber et al. [53] further elaborate that the basic idea of PuLSE-DSSA is to incrementally develop reference architecture guided by generic scenarios that are applied in decreasing order of architectural significance. Researchers at Philips® have developed Component-Oriented Platform Architecting (CoPAM) [54] method for the software product lines of electronics products. CoPAM assumes a strong correlation among facts, stakeholder expectations, any existing architecture and the institutions about possible architects in developing software product line architecture. Weiss and Lai [55] discuss the development of Family-Oriented Abstraction Specification and Translation (FAST) method for software product line process and successful use at Lucent Technologies®. FAST method covers a full software product line engineering process with specific activities and targeted artifacts. It divides the overall process of software product line into three major steps of domain qualification, domain engineering and application engineering. Researchers at IESE developed another methodology called KobrA [56], which defines software product line engineering process with activities and artifacts. The process of software product line engineering is divided into framework engineering and application engineering with their sub steps. These steps cover the implementation, releasing, inspection and testing aspects of product line engineering process. Kang et al. [57] propose a Feature Oriented Reuse Method (FORM), which is an extension to the Feature-Oriented Domain Analysis (FODA) method to cover the aspects of software product lines. FORM provides a methodology to use feature models in developing domain architectures and components reusability. Researchers at the VTT technical research centre of Finland have developed Quality-driven Architecture Design and Quality Analysis (QADA) method for developing and evaluating software architectures with emphasis on product line architecture. Matinlassi [58] has reported the comparison of software product line architecture design methods including CoPAM, FAST, FORM, KobrA and QADA, and concluded that these methods do not seem to compete with each other, because each of them has a special goal or ideology. The concepts of commonality and variability management inherently belong to domain engineering are gaining popularity over time due to extensive involvement in software product line concept. According to Coplien et al. [59] commonality and variability analysis gives software engineers a systematic way of thinking about and identifying the product family they are creating. Commonality management deals with the way features and characteristics that are common across the products belong to same product line whereas variability management is other way round. Variability management handles the way the variable features and characteristics are managed in different products of the a product line. Software product line requires systematic approaches to handling commonality and variability and the core of successful software product line management largely relies on effective commonality and variability management. Kang et al. [57] discuss the use of feature models

84

Faheem Ahmed, Luiz Fernando Capretz and Muhammad Ali Babar

to manage commonality and variability in software product line. Lam [60] presents variability templates and variability hierarchy based variability management process. Thompson and Heimdah [61] propose a set based approach to structure commonalities and variability in software product lines. Kim and Park [62] describe the goal and scenario driven approach for managing commonality and variability on software product line. Ommering [63] observes that the commonalities are embodied in an overall architecture of software product line, while the differences result in specifying variation points and by filling those variation points, individual products can be derived. Other researchers [64] [55] [4] have stressed that the software architecture for a product family must address the variability and commonality of the entire set of products. Requirements modeling have always been a key architecture concern in software devolvement, because it provides a better understanding of the requirements of the architecture and allows visualizing the interconnection of various sub-units. Since the popularity of object oriented design, Unified Modeling Language (UML) has become an industry standard, many researchers have attempted to introduce UML in visual modeling of software product line architecture by presenting enhancement in the current state. Birk et al. [31] stress that the organization dealing with software product line architecture should describe the architecture using well-established notations such as UML and the architecture description should cover all relevant architectural views and use clearly defined semantics. Gomma and Shin [65] describe a multiple-view meta-modeling approach for software product lines using the UML notation, which defines the different aspects of a software product line such as: the use case model, static model, collaboration model, state chart model, and feature model. Zuo et al. [66] present the use of problem frames for product line engineering modeling and requirements analysis and demonstrate some additional notation to support the requirements management and variability issues in product line problem frames. Dobrica and Niemelä [67] discuss how UML standard concepts can be extended to address the challenges of variability management in software product line architecture and introduce some extensions in UML standard specification for the explicit representation of variations and their locations in software product line architectures, this work is based on previously mentioned QADA methodology. Eriksson et al. [68] describe a product line use case modeling approach named PLUSS (Product Line Use case modeling for Systems and Software engineering) and conclude that PLUSS performs better than modeling according to the styles and guidelines specified by the Rational Unified Process (RUP) in the current industrial context. Software architecture evaluation techniques are generally divided into two groups: qualitative evaluation and quantitative evaluation. Qualitative techniques include scenarios, questionnaires, checklists etc. Quantitative techniques cover simulations, prototypes, experiments, mathematical models, etc. Etxeberria and Sagardui [69] highlight the issues that can arise when evaluating product line architecture versus evaluating single system architecture, including classifications of relevant attributes in product line architecture evaluation, new evaluation techniques. Graaf et al [70] present a scenario based software product line evaluation technique, which provides guidelines to adapt scenario-based assessment to software product line context. Using the qualitative technique of software architecture evaluation Hoek et al [71] put forward service utilization metrics to assess the quality attribute of software product line architecture. Zhang et al [72] study the impact of variants on quality attributes using a Bayesian Belief Network (BBN) and design a

Software Product Line Engineering: The Future Research Directions

85

methodology applicable to software product line architecture evaluation. Lange and Kang [73] propose a product-line architecture prototyping approach using network technique to assess issues related to software product line architecture evaluation. Gannod and Lutz [74] define an approach to evaluating the quality and functional requirements of software product line architecture. Niemelä et al. [75] discuss the basic issues of product family architecture development and present evaluation model of software product family in industrial setting. Domain engineering has a pivotal role in the process of software product line. The inception phase of software product line starts with conducting a comprehensive domain engineering in defining and narrowing down the scope of product line, which identifies the characteristics of the product line and the products that comprise the product line. The product line engineering envisages the domain engineering into set of three activities: domain analysis, domain design and domain implementation. Domain analysis concentrates on understanding the domain and providing a foundation to domain design, which is an early sketch of the architecture of product line. Domain analysis not only defines the boundaries of the software product line scope but also helps in performing the commonality and variability analysis for the product line. Domain implementation further helps in developing the core architecture of software product line by specifying components and their inter-connections. The activities of domain engineering invariably helps in carrying out commonality and variability analysis. The domain engineering helps in defining the common and variable parts of the software product line requirements, thus explicitly identifying the commonality and variability of the envision products. The software product line requires a strong coordination among domain engineering and application engineering. The domain engineering helps in establishing an infrastructure for software product line and the application engineering uses the infrastructure and develops products using core assets. Requirements modeling provide us with the facility to model the requirements graphically so that requirements can easily be understood by various stakeholders Requirements modeling helps in understanding the requirements of the products and in further elaborating the functionalities and tradeoffs. Software product line needs to elaborate the requirements at two levels: product line level and individual product level. The product line level requirements envisage the commonality among products whereas individual product level requirements represent the variability. Modeling requirements in the context of software product line architecture helps in identifying and specifying the extension points called variation points. It decomposes and specifies the architecture into set of features with their dependency. Requirements models translate the requirements of the targeted market segment and specify the implementation views of the business case. Much of the work on requirements modeling for software product line has concentrated on establishing an extension in the current available modeling techniques like UML and feature diagrams. Product requirements in software product line are composed of a constant and a variable part. The constant part comes from product line requirements and deals with features common to all the products belonging to a family. The variable part represents those functionalities that can be changed to differentiate one product from another. This causes the significance of commonality and variability management in software product line. Commonality among products of a software product line is an essential and integral characteristic of product line approach that paves a way to maximize reusability. The products share the common architecture and they are developed out of common core assets. The commonality management takes much if its’ input from domain engineering and those inputs are further

86

Faheem Ahmed, Luiz Fernando Capretz and Muhammad Ali Babar

elaborated and clearly specified using requirements modeling approaches. The extent of commonality among products is a design decision based on business case engineering and targeted market segment. In order to maximize the reusability of software assets, it is generally recommended to have as much commonality as possible. Variability among products of a software product line is necessary because it makes them a separate business entity. The products from a software product line may vary from each other’s in quality, reliability, functionality, performance and so on, but as they share a common architecture so the variation should not be that much high so that they become out from the scope of a single product line. Those variations must be handled systematically to accommodate changes in various versions of the product. The objective of variability management is to identify, specify and document variability among products in the applications of product line. Software product line architecture represents variability by specifying the variation points, which can be exploited at application engineering level by accommodating the design decisions based on the business case. The variability in products usually results from internal and external factors. The internal factors have their roots in refining the architecture whereas external factors accommodate the market and customers expectations. The introduction of variable features in a product from a software product line is a strategic decision based on market segment. The introduction of variable features in the successive products out of product line also provides a justification for setting up a product line in the organization as well because it helps in attracting new customer and retaining the current one. Fitting the components into the product without tailoring it is the easiest task, but some time we need to make certain changes in the component to meet the requirements for a particular product. Every component present in the core assets must clearly define the variability mechanism to be used in order to tailor them for reuse. The significance of commonality and variability management in software product line architecture and the overall performance of the software product line require tool support, which needs the attention of researchers. Software artifacts management play significant role in the process of development, maintenance and reuse of software. Software product line architecture is one of the critical artifacts of software product line approach, and all the resulting products share this common architecture. The architectural artifacts provide in-depth knowledge about various views, levels of abstractions, variation points, components identification, component behavior and their inter-connection. It has been a general trend in software industry to represent and document architecture using notations and languages such as Architecture Description Language (ADL). Software product lines currently lack an architecture description language to represent the software product line architecture in large. These documentations such as domain analysis, domain design, domain testing, requirements modeling provides inputs to software product line architecture. The configuration management issues of software product line artifacts are imperative in software product lines as it deals with a number of resulted products with different versions and releases as well as several number of core assets with different versions. The concept of configuration management currently used in software industry deals with a single project, or more precisely with a single product, and on the opposite software product line deals with a set of products. Therefore a multi dimensional approach of configuration management should be adopted to cope up with the issue. Configuration management of software product line is a research area where not much work has been done and requires an immediate attention of researchers.

Software Product Line Engineering: The Future Research Directions ƒ

ƒ

ƒ

87

Quality is a major issue for family of products. Like a single product, software quality is fundamental to a family of products’ success. Core and product architectures of family of products are expected to help achieve the required quality attributes. However, one of the key challenges in designing software architectures for core and individual products with respect to the desired level of different quality attributes is that the quality attributes have been found very hard to define, describe and understand. This aspect has very strong subjective interpretation. That is why it is vital to systematically elicit and precisely define quality aspects of a family of products in order to help design appropriate architectures. There are a number of classifications of quality attributes. McCall listed a number of classifications of quality attributes developed by software engineering researchers including himself [76]. A later classification of software quality is provided in [77]. However, none of them has been proven sufficient to define, specify, and model different levels of quality attributes required in different products of a family. There is a vital need for developing appropriate approaches to eliciting, specifying, and modeling quality attributes to be supported by software architectures of a family of products. Designing and evaluating software architectures of a family of systems involves complex and knowledge intensive tasks. The complexity lies in the fact that tradeoffs need to be made to satisfy current and future requirements of a potentially large set of stakeholders, who may have competing vested interests in architectural decisions. The knowledge required to make suitable architectural choices is broad, complex, and evolving, and can be beyond the capabilities of any single architect [78]. Due to the recognition of the importance and far reaching influence of the architectural decisions, several approaches have been developed to support architecting processes. Examples are the Generic Model for architecture design [79], Attribute-driven design [80], Architecture Tradeoff Analysis Method (ATAM) [81], 4+1 views [82], Rationale Unified Process (RUP) [83] and architecture-based development [84]) While these approaches help to manage complexity by using systematic approaches to reason about various design decisions, they provide very little guidance or support to capture and maintain the details on which design decisions are based, along with explanations of the use of certain types of design constructs (such as patterns, styles, or tactics). Such information represents architecture knowledge, which can be valuable throughout the software development lifecycle [85]. We assert that the lack of a systematic approach to capturing and sharing architectural knowledge may preclude organizations from growing their architecture capability and reusing architectural assets. Moreover, the knowledge concerning the domain analysis, architectural patterns used, design alternatives evaluated and design decisions made is implicitly embedded in the architecture and/or becomes tacit knowledge of the architect [86]. Hence, one of the key challenges in successfully development and evolving software architectures is the provision of suitable infrastructure for capturing, maintaining, and sharing architectural knowledge and rationale underpinning key architectural design decisions. Apart from the challenge of devising optimal architectural solutions, specifying the architecture and interfaces of component-based family of systems is a difficult task, which poses several kinds of challenges. For example, industries heavily dependent upon on the component-based software engineering, like automotive, Usually OEMs

88

Faheem Ahmed, Luiz Fernando Capretz and Muhammad Ali Babar

ƒ

(Original Equipments Manufacturers) have to provide an overall architecture of the automotive systems in its cars and distribute these to potential suppliers of systems and components who do the implementation. The AUTOSAR standard is a move to establish an open standard for automotive embedded electronic architecture. AUTOSAR tries to achieve modularity, scalability transferability and reusability of functions. However, even if the architecture and components are specified using AUTOSAR, there is still no checking of conformance or conformance validation. We assert that there is a need for specific methods and tools to validate that those implementations actually conform to the specifications and that the combination of the various implementations conforms to the OEMs’ specifications. Architecture and interface specification is another big challenge in software product line engineering in general and software product line engineering for automotive systems in particular. There is general lack of suitable and reliable methods to accurately and sufficiently provide interface specifications. This is also one of the key research challenges in the context of increasing trend of global software development.

References [1]

P.C. Clements, Jones, L.G., Northrop, L.M. and McGregor, J.D.: Project Management in a Software Product Line Organization. IEEE Software 22 (5) 54-62 (2005) [2] P.C. Clements: On the Importance of Product Line Scope, Proceedings of the 4th International Workshop on Software Product Family Engineering 69-77 (2001) [3] T. Wappler, Remember the basics: key success factors for launching and institutionalizing a software product line, in: Proceedings of the 1st Software Product Line Conference, 2000, pp. 73-84. [4] P.C. Clements, L.M. Northrop, Software product lines practices and pattern, Addison Wesley, 2002. [5] F. van der Linden, Software product families in Europe: The Esaps & Café projects, IEEE Software 19 (4) (2002) 41-49. [6] ESAPS Project (1996) available from: http://www.esi.es/en/Projects/esaps/ overview.html [7] R.V. Ommering, Beyond product families: building a product population, in: Proceedings of the Conference on Software Architectures for Product Families, 2000, pp.187-198. [8] L.M Northrop, SEI’s software product line tenets, IEEE Software 19 (4) (2002) 32-40. [9] C.W. Krueger (2004) Basic software product line concepts, Available from:http://www.softwareproductlines.com/introduction/concepts.html [10] [J. Bayer, O. Flege, P. Knauber, R. Laqua, D. Muthig, K. Schmid, T. Widen, J.M. DeBaud, PuLSE: a methodology to develop software product lines, in: Proceedings of the 5th ACM SIGSOFT Symposium on Software Reusability, 1999, pp. 122-131. [11] F. van der Linden J. Bosch, E., Kamsties, K. Känsälä, H. Obbink, Software product family evaluation, in: Proceedings of the 3rd International Conference on Software Product Lines, 2004, pp. 110-129.

Software Product Line Engineering: The Future Research Directions

89

[12] K.C. Kang, P. Donohoe, E. Koh, J. Lee, K. Lee, Using a marketing and product plan as a key driver for product line asset development, in: Proceedings of the 2nd International Conference on Software Product Lines, 2002, pp.366-382. [13] P. Toft, D. Coleman, J. Ohta, A cooperative model for cross-divisional product development for a software product line, in: Proceedings of the 1st International Conference on Software Product Lines, 2000, pp. 111-132. [14] C. Fritsch, R. Hahn, Product line potential analysis, in: Proceedings of the 3rd International Conference on Software Product Lines, 2004, pp. 228-237. [15] K. Schmid, M. Verlage, The economic impact of product line adoption and evolution, IEEE Software 9(4) (2002) 50-57. [16] C. Ebert, M. Smouts, Tricks and traps of initiating a product line concept in existing products, in: Proceedings of the 25th International Conference on Software Engineering, 2003, pp. 520-525. [17] E. Niemelä, Strategies of product family architecture development, in: Proceedings of the 9th International Conference on Software Product Lines, 2005, pp. 186-197. [18] P.D. Bennett, Dictionary of marketing terms, American Marketing Association, 1988. [19] A. Jaaksi, Developing mobile browsers in a product line, IEEE Software 19(4) (2002) 73-80. [20] G. H Birk, John, I. Schmid, K. von der Massen T., Muller K., Product line engineering, the state of the practice, IEEE Software 20(6) (2003) 52-60. [21] P. Knauber, D. Muthig, K. Schmid, T. Wide, Applying product line concepts in small and medium-sized companies, IEEE Software 17(5) (2000) 88-95. [22] J.G. Wijnstra, Critical factors for a successful platform-based product family approach, in: Proceedings of the 2nd International Conference on Software Product Lines, 2002, pp. 68-89. [23] G. Böckle, Innovation management for product line engineering organizations, in: Proceedings of the 9th International Conference on Software Product Lines, 2005, pp. 124-134. [24] W. R. Scott, Institutions and organizations, Sage Publications, CA, 1995. [25] J. Bosch, Software product lines: organizational alternatives, in: Proceedings of the 23rd International Conference on Software Engineering, 2001, pp. 91-100. [26] R.R.. Macala, L.D. Jr. Stuckey and D.C. Gross, Managing domain-specific, productline development, IEEE Software 13 (3) (1996) 57-67. [27] D. Dikel, D. Kane, S. Ornburn, W. Loftus and J. Wilson, Applying software productline architecture, IEEE Computer 30 (8) (1997) 49-55. [28] I. Jacobsen, M. Griss and P. Jonsson, Software reuse - architecture, process and organization for business success, Addison Wesley, 1997. [29] M. Mannion, Organizing for software product line engineering, in: Proceedings of the 10th International Workshop on Software Technology and Engineering Practice, 2002, pp. 55 –61. [30] E. Koh and S. Kim, Issues on adopting software product line, in: Proceedings of the 11th Asia-Pacific Conference on Software Engineering, 2004, pp. 589. [31] G. H Birk, I. John, K. Schmid, T. von der Massen and K. Muller, Product line engineering, the state of the practice, IEEE Software 20 (6) (2003) 52-60.

90

Faheem Ahmed, Luiz Fernando Capretz and Muhammad Ali Babar

[32] J. Bayer, O. Flege, P. Knauber, R. Laqua, D. Muthig, K. Schmid, T. Widen and J.M. DeBaud, PuLSE: a methodology to develop software product lines, in: Proceedings of the 5th ACM SIGSOFT Symposium on Software Reusability, 1999, pp. 122-131. [33] M. Verlage and T. Kiesgen, Five years of product line engineering in a small company, in: Proceedings of the 27th International Conference on Software Engineering, 2005, pp. 534 – 543. [34] E. H. Schein, Organizational psychology, Prentice Hall, 1988. [35] D.C. Wilson and R.H. Rosenfeld, Managing organizations, McGraw-Hill, 1990. [36] J.R. Gordon, Organizational Behavior: A diagnostic approach, Prentice Hall, New Jersey, 2002. [37] R. Beckhard, and R.T. Harris, Organizational transitions: managing complex change, Addison-Wesley, 1987. [38] A. Todd, Managing radical change, Long Range Planning 32 (2) (1999) 237-44. [39] G. Cao, S. Clarke, and B. Lehaney, A systematic view of organizational change and TQM, The TQM Magazine 12 (3) (2000) 186-93. [40] J.A. Walls and R.R. Callister, Conflict and its management, Journal of Management 21 (3) (1995) 515-558. [41] J. Kottler, Beyond blame: A new way of resolving conflicts in relationships, JosseyBass, San Francisco, 1994. [42] D. Hellriegel, J.W. Jr. Slocum, R.W. Woodman and N.S. Bruning, Organizational behavior, ITP Nelson, Canada, 1998. [43] K.A. Jehn, A multi-method examination of the benefits and detriments of intra-group conflict, Administrative Science Quarterly 40 (1995) 256-82. [44] F. J. Medina, L. Munduate, M.A. Dorado and I. Martínez, Types of intra-group conflict and affective reactions, Journal of Managerial Psychology 20 (3/4) (2005) 219-230. [45] M. Verlage and T. Kiesgen, Five years of product line engineering in a small company, in: Proceedings of the 27th International Conference on Software Engineering, 2005, pp. 534 – 543. [46] D. Garlan and D. Perry, Introduction to the special issue on software architecture, IEEE Transactions on Software Engineering 21(4) (1995), pp. 269-274. [47] B.J. Pronk, An interface-based platform approach, in: Proceedings of the 1st Software Product Lines Conference, 2000, pp. 331-352. [48] M. Jazayeri, A. Ran, and F. van der Linden, Software architecture for product families: principles and practice, Addison Wesley, 2000. [49] K. Mika, M. Tommi, Assessing systems adaptability to a product family, Journal of Systems Architecture 50 (2004) 383-392. [50] D. Dikel, D. Kane, S. Ornburn, W. Loftus and J. Wilson, Applying software productline architecture, IEEE Computer 30 (8) (1997) 49-55. [51] M. Verlage and T. Kiesgen, Five years of product line engineering in a small company, in: Proceedings of the 27th International Conference on Software Engineering, 2005, pp. 534-543. [52] J. Bayer, O. Flege, P. Knauber, R. Laqua, D. Muthig, K. Schmid, T. Wide and J.M. DeBaud, PuLSE: a methodology to develop software product lines, in: Proceedings of the 5th ACM SIGSOFT Symposium on Software Reusability, 1999, pp. 122-131. [53] P. Knauber, D. Muthig, K. Schmid and T. Wide, Applying product line concepts in small and medium-sized companies, IEEE Software 17(5) (2000) 88-95.

Software Product Line Engineering: The Future Research Directions

91

[54] P. America, H. Obbink, R. van Ommering and F. van der Linden COPA: a componentoriented platform architecting method family for product family engineering, in: Proceedings of the 1st Software Product Line Engineering Conference, 2000, pp. 167180. [55] D.M. Weiss and C.T.R. Lai, Software product line engineering: a family based software development process, Addison Wesley, 1999. [56] C. Atkinson, J. Bayer, and D. Muthig, Component-based product line development. The KobrA approach, Proceedings of the 1st Software Product Lines Conference, 2000, pp. 289-309. [57] K. C. Kang, S. Kim, J. Lee, K. Kim, E. Shin, and M. Huh, FORM: a feature-oriented reuse method with domain specific reference architectures, Annals of Software Engineering, 5 (1998) 143-168. [58] M. Matinlassi, Comparison of software product line architecture design methods: COPA, FAST, FORM, KobrA and QADA, in: Proceedings of the 26th International Conference on Software Engineering, 2004, pp.127-136. [59] J. Coplien, D. Hoffman, D. Weiss, Commonality and variability in software engineering, IEEE Software 15 (6) (1998) 37-45. [60] W. Lam, Creating reusable architectures: an experience report, ACM Software Engineering Notes 22(4) (1997) 39-43 [61] J.M. Thompson and M. P.E. Heimdahl, Structuring product family requirements for ndimensional and hierarchical product lines, Requirements Engineering Journal 8(1) (2003) 42-54. [62] M. Kim and S. Park, Goal and scenario driven product line development, in: Proceedings of the 11th Asia-Pacific Conference on Software Engineering, 2004, pp. 584 –585. [63] R. van Ommering, Software reuse in product populations, IEEE Transactions on Software Engineering 31(7) (2005) 537-550. [64] R.R. Macala, L.D. Jr. Stuckey and D.C. Gross, Managing domain-specific, productline development, IEEE Software 13 (3) (1996) 57-67. [65] H. Gomma, M.E. Shin, Multiple-view meta modeling of software product lines, in: Proceedings of the 8th IEEE International Conference on Engineering of Complex Computer Systems, 2002, pp. 238-246. [66] H. Zuo, M. Mannion, D. Sellier, and R. Foley, An extension of problem frame notation for software product lines, in: Proceedings of the 12th Asia Pacific Conference on Software Engineering, 2005, pp. 499-505. [67] L. Dobrica, E. Niemelä, UML notation extensions for product line architectures modeling, in: Proceedings of the 5th Australasian Workshop on Software and System Architectures, 2004, pp. 44 -51. [68] M. Eriksson, J. Börstler and K. Borg, The PLUSS approach - domain modeling with features, use cases and use case realizations, in: Proceedings of the 9th International Conference on Software Product Lines, 2005, pp. 33-44. [69] L. Etxeberria and G. Sagardui, Product line architecture: new issues for evaluation, in: Proceedings of the 9th International Conference on Software Product Lines, 2005, 174185.

92

Faheem Ahmed, Luiz Fernando Capretz and Muhammad Ali Babar

[70] B. Graaf, H. Van Kijk,A. Van Deursen, Evaluating an embedded software reference architecture – industrial experience report, in: Proceedings of the 9th European Conference on Software Maintenance and Reengineering, 2005, pp 354-363. [71] A. van der Hoek, E. Dincel and N. Medvidovic, Using service utilization metrics to assess the structure of product line architectures, in: Proceedings of the 9th International Software Metrics Symposium, 2003, pp. 298-308. [72] H. Zhang, S. Jarzabek, and B. Yang, Quality prediction and assessment for product lines, in: Proceedings of the 15th International Conference on Advanced Information Systems Engineering, 2003, pp. 681-695. [73] F. De Lange, J. Kang, Architecture true prototyping of product lines, in: Proceedings of the 5th International Workshop on Software Product Family Engineering, 2004, pp. 445-453. [74] G.C. Gannod, R.R. Lutz, An approach to architectural analysis of product lines, in: Proceedings of the 22nd International Conference on Software Engineering, 2000, pp.548-557. [75] E. Niemelä, M. Matinlassi, A. Taulavuori, Practical evaluation of software product family architectures, in: Proceedings of the 3rd International Conference on Software Product Lines, 2004, pp. 130-145. [76] J.A. McCall, Quality Factors, in Encyclopedia of Software Engineering, J.J. Marciniak, Editor. 1994, John Wiley: New York, U.S.A. pp. 958-971. [77] ISO/IEC, Information technology - Software product quality: Quality model. ISO/IEC FDIS 9126-1:2000(E) [78] M. Ali-Babar and I. Gorton, A Tool for Managing Software Architecture Knowledge, Proceedings of the 2nd Workshop on SHAring and Reusing architectural knowledge Architecture, rationale, and Design Intent (SHARK/ADI 2007), Collocated with ICSE 2007., 2007. [79] C. Hofmeister, et al., A General Model of Software Architecture Design Derived from Five Industrial Approaches, 5th Working IEEE/IFIP Conference on Software Architecture (WICSA 05), Pittsburgh, PA, USA, 2005. [80] L. Bass, M. Klein, and F. Bachmann, Quality Attribute Design Primitives and the Attribute Driven Design Method, Proceedings of the 4th International Workshop on Product Family Engineering, 2001. [81] P. Clements, R. Kazman, and M. Klein, Evaluating Software Architectures: Methods and Case Studies. 2002: Addison-Wesley. [82] P. Kruchten, The 4+1 View Model of architecture, Software, IEEE, 1995. 12(6): pp. 42-50. [83] P. Kruchten, The Rational Unified Process: An Introduction. 2nd ed. 2000: AddisonWesley. [84] L. Bass and R. Kazman, Architecture-Based Development, Tech Report CMU/SEI-99TR-007, Software Engineering Institute (SEI), Carnegie Mellon University, Pittsburgh, USA, 1999. [85] M. Ali-Babar, I. Gorton, and B. Kitchenham, A Framework for Supporting Architecture Knowledge and Rationale Management, in Rationale Management in Software Engineering, A.H. Dutoit, et al., Editors. 2006, Springer. pp. 237-254. [86] M. Ali-Babar, I. Gorton, and R. Jeffery, Capturing and Using Software Architecture Knowledge for Architecture-Based Software Development, 5th International Conference on Quality Software, 2005.

In: Software Engineering and Development Editor: Enrique A. Belini, pp. 93-123

ISBN: 978-1-60692-146-3 © 2009 Nova Science Publishers, Inc.

Short Communication D

SOFTWARE DEVELOPMENT FOR INVERSE DETERMINATION OF CONSTITUTIVE MODEL PARAMETERS A. Andrade-Campos1,a, P. Pilvin2,b, J. Simões1,3,c and F. Teixeira-Dias1,d 1

Departamento de Engenharia Mecânica, Universidade de Aveiro Campus Universitário de Santiago, Portugal 2 Laboratoire d'Ingénierie des Matériaux de Bretagne, Université de Bretagne-Sud Rue de Saint-Maudé, France 3 Escola Superior de Artes e Design, Avenida Calouste Gulbenkian, Matosinhos, Portugal

Abstract Computer simulation software using finite element analysis (FEA) has, nowadays, reached reasonable maturity. FEA software is used in such diverse fields as structural engineering, sheet metal forming, mould industry, biomechanics, fluid dynamics, etc. This type of engineering software uses an increasingly large number of sophisticated geometrical and material models. The quality of the results relies on the input data, which are not always readily available. The aim of inverse problem software, which will be considered here, is to determine one or more of the input data relating to FEA numerical simulations. The development of numerical methodologies for inverse determination of material constitutive model parameters will be addressed in this chapter.Inverse problems for parameter identification involve estimating the parameters for material constitutive models, leading to more accurate results with respect to physical experiments, i.e. minimizing the difference between experimental results and simulations subject to a limited number of physical constraints. These problems can involve both hyperelastic and hypoelastic material constitutive models. The complexity of the process with which material parameters are a

E-mail address: [email protected]. E-mail address: [email protected]. c E-mail address: josesimoes@ua. d E-mail address: [email protected]. b

94

A. Andrade-Campos, P. Pilvin, J. Simões et al. evaluated increases with the complexity of the material model itself. In order to determine the best suited material parameter set, in the less computationally expensive way, different approaches and different optimization methods can be used. The most widespread optimization methods are the gradient-based methods, the genetic, evolutionary and natureinspired algorithms, the immune algorithms and the methods based in neural networks and artificial intelligence. By far, the better performing methods are gradient-based but their performance is known to be highly dependent on the starting set of parameters and their results are often inconsistent. Nature-inspired techniques provide a better way to determine an optimized set of parameters (the overall minimum). Therefore, the difficulties associated to choosing a starting set of parameters for this process is minor. However, these proved to be computationally more expensive than gradient-based methods.Optimization methods present advantages and disadvantages and their performance is highly dependent on the constitutive model itself. There is no unique algorithm robust enough to deal with every possible situation, but the use of sequential multiple methods can lead to the global optimum. The aim of this strategy is to take advantage of the strength of each selected algorithm.This strategy, using gradient-based methods and evolutionary algorithms, is demonstrated for an elastic-plastic model with non-linear hardening, for seven distinct hyperelastic models (Humphrey, Martins, Mooney-Rivlin, Neo-Hookean, Ogden, Veronda-Westmann and Yeoh) and for one thermoelastic-viscoplastic hypoelastic model. The performance of the described strategy is also evaluated through an analytical approach.

Keywords: Engineering software, inverse problems, material parameter identification, optimization, gradient-based, evolutionary algorithms.

Introduction Presently, numerical simulation software assumes an important role in the design and technological development of new materials and structures. The industrial and scientific communities are already familiarized with the use of simulation software and are becoming more demanding with the precision of results. For this fact, more complex techniques have been developed to simulate with increasing accuracy the behaviour of different materials. Consequently, different constitutive behaviour models have also been presented to characterize the materials in a wider field of applications. However, many of these constitutive behaviour models demand the determination of a large number of parameters adjusted to the material whose behaviour is to be simulated. The problem of parameter identification of mathematical models, created to describe with accuracy the behaviour of physical systems, is a common problem in science and engineering. The complexity of the models (and the number of material parameters) increases with the complexity of the physical system. The determination of parameters should always be performed confronting mathematical and experimental results. However, from the moment when the number of experimental tests and parameters increases, it becomes impracticable to identify the parameters in an exploratory way [1][2]. In these cases, it is necessary to solve the problem using inverse formulations. This approach often leads to the resolution of non-linear optimization problems [3]. Different approaches and different optimization methods can be used to solve non-linear optimization problems with lower computational costs and to efficiently determine the best suited material parameter set. The most common optimization methods are the gradient-based methods followed by the genetic, evolutionary and nature-inspired algorithms. The immune

Software Development for Inverse Determination of Constitutive Model Parameters

95

algorithms and the methods based in neural networks and artificial intelligence are also often used. Without doubt, the better performing methods are gradient-based but their performance is known to be dependent on the starting set of parameters. Nature-inspired techniques provide a different way to determine an optimized set of parameters. Therefore, the difficulty of choosing a starting set of parameters for this process is minor. However, these proved to be computationally more expensive than the gradient-based method. Optimization methods have advantages and disadvantages and their performance is highly dependent on the constitutive model itself. There is no single algorithm robust enough to deal with every possible situation, but the use of multiple methods can lead to the global optimum. The robustness of an optimization algorithm can be improved introducing the cascade methodology, as considered in [4][5] and also adopted in [6][7]. The cascade methodology tries to solve a problem sequentially using a number of autonomous optimization stages. This cascade methodology becomes a very versatile and robust algorithm. Its robustness and efficiency is expected to be always superior to the optimization methods used individually in each stage. The mathematical equations that characterize the behaviour of each material are designated as constitutive models. They describe the macroscopic behaviour that results from the internal constitution of the material. Three classes of behaviour can be distinguished that can be combined in many ways [8]: (i) elastic – when the material recovers its deformation when loads are removed. If this relation is linear and homogeneous then the elasticity is called linear. (ii) plastic – this is characterized by permanent deformations, remaining even after loads are removed, provided the loads are high enough, exceeding some threshold. If the deformation before the plastic threshold is negligible, then the behaviour is called rigidperfectly plastic. (iii) viscous – the response of the material depends on the speed with which loads are applied. The constitutive model equations of solid materials as, for example, metals, try to represent these physical behaviours. Nonlinear constitutive models can be divided in three types: ƒ ƒ

ƒ

Hookean model – intended to extend the linear elastic model to situations where stretches remain small, but rotations may be large. Hypoelastic model – intended to model nonlinear stress-strain behaviour but restricted to infinitesimal strains. Its main application is an approximate theory of plasticity and, then, it is used when elastic strains remain very small. Hyperelastic model – intended to be used to model materials that respond elastically up to very large strains, and account both for nonlinear material behaviour and also for nonlinear kinematics. Usually, these models are formulated with the aid of a strain energy function and strain invariants.

The main applications considered in this chapter will be seven distinct hyperelastic models, one elastic-plastic model and one thermoelastic-viscoplastic hypoelastic model, used in different types of materials. The hyperelastic models are employed to simulate the mechanical behaviour of biologic tissues. Human and animal tissues are known to show nonlinear elastic behaviour up to very large strains, demanding the use of hyperelastic models such as the ones presented by Humphrey [9], Martins [10], Mooney[11]-Rivlin [12], NeoHookean, Ogden [13], Veronda-Westmann [14] and Yeoh [15]. The neo-Hookean model

96

A. Andrade-Campos, P. Pilvin, J. Simões et al.

depends on a single parameter. However, the Ogden model has 6 parameters that need to be identified. The hypoelastic model used in this work combines the three classes of behaviour above mentioned and was developed to characterize metallic materials at room, medium and high temperatures [16]. The model is a unified constitutive model in the sense that plasticity and creep are defined simultaneously, i.e., they are described by the same set of flow rules. In this model, the microstructural state of the material is tracked via a set of variables that evolve both with the deformation and with the temperature. These internal variables may represent a specific material property, such as the resistance to plastic deformation, but are not necessarily physically measurable quantities [9][17][18]. The internal variable thermoelasticviscoplastic constitutive model has 12 material parameters that need to be determined for each material.

Parameter Identification Inverse Problems Computer simulation software using the finite element method (FEM) has proven its value and efficacy [19]. FEM software can be used in such diverse fields as structural engineering, sheet metal forming, mould industry, biomechanics, fluid dynamics, etc. As with any simulation method, FEM simulations require the introduction of several forms of input data, such as initial geometry, domain discretization (finite element mesh), boundary conditions, material constitutive models, etc. The quality of the results relies on the quality of the input data, which are not always readily available. The simulation of physical processes and its final results can be defined as a direct problem (see Figure 1). In this kind of problem there is a total knowledge of the numerical model implemented in the simulation software and the required input data. The goal of this problem is the final set of results that, for a structural problem software, can be the deformed geometry, strains, stresses and other final properties.

Input data Initial geometry Finite element mesh Boundary conditions Process parameters Constitutive model arameters

Output data SIMULATION SOFTWARE

Deformed geometry Strains and stresses Process evolution properties

Figure 1. Direct problem scheme.

Considering that direct problems are well established, it is possible to solve more difficult problems, namely inverse problems. The goal of inverse problems is to determine one or a set of the direct problem input data. Generally, it consists in providing information to the numerical model from the full knowledge of the physical process. In a first approach, the analysis of the experimental observations leads to the association of a mathematical model that would be implemented in the simulation software. These experimental values can then be used to determine the different parameters and coefficients

Software Development for Inverse Determination of Constitutive Model Parameters

97

needed for the mathematical formulation of the model. This can be accomplished solving an inverse problem which consists of searching for a set of parameter values for which the comparison between the experimental reality and the simulation may be considered satisfactory. This methodology is schematically described in Figure 2. The comparison between the physical system data and the numerical data results in a cost function that must be evaluated. Occasionally, it is possible to obtain several distinct sets of parameters for which the comparison is acceptable. When this is the case, it is the role of the user to evaluate the results obtained considering the physical definition and meaning of each parameter. The stages of decision and evolution to a new set of parameters, considering the value of the cost function and the parameter of the previous steps, are done using optimization algorithms and software. In order to improve the process of finding suitable set of parameters at acceptable CPU time, these stages must be accomplished with efficient optimization algorithms.

Input data Initial geometry Finite element mesh Boundary conditions Process parameters Initial const. model parameters

Output data SIMULATION SOFTWARE

New input data New Constitutive model parameters

Deformed geometry Strains and stresses Process evolution properties

Comparison OPTIMIZATION SOFTWARE

Numerical data versus Experimental data

Figure 2. Inverse problem scheme.

The development of software for the determination of the constitutive model parameters started in the beginning of the 1990s using straightforward curve-fitting techniques (vd, e.g. [19][20]). The coupling between engineering simulation software and optimization software was introduced some years after. The works of Chaboche [21], Schnur and Zabaras [22], Cailletaud and Pilvin [3][23], Mahnken and Stein [24][25], Gélin and Ghouati [26][27] are examples. Presently, there are FEM software that offer modules to determine constitutive model parameters when experimental input data is given (e.g. Abaqus [28], Nastran [29], among others).

Definition Of The Objective Function To efficiently determine model parameters, the definition of the error function between the experimental and numerical results is required. This function will be the optimization

98

A. Andrade-Campos, P. Pilvin, J. Simões et al.

objective function and should be able to efficiently conduct the optimization process. A wrong definition of this function will compromise all the optimization process and, therefore, the determination of parameters for the constitutive model. An objective function (OF) should respect the following criteria [30]: ƒ ƒ ƒ

ƒ

ƒ

The errors of the involved experimental data should be removed. All the experimental data points on a single curve should be considered in the optimization and have an equal opportunity to be optimized. All experimental curves should have equal opportunity to be optimized and the identification process should be independent of the number of data points in each experimental curve. An objective function should be able to deal with multi-sub-objective problems, in which the units of sub-objectives may be different and all the sub-objectives should have an equal opportunity to be optimized. Different units and/or the number of curves in each sub-objective should not affect the overall performance of the fitting. The weighting factors used in the objective function should be found automatically.

It should be noted that experimental data consists of several discrete values representing measured points, leading to an experimental curve. In the specific case of structural material models, the experimental data is a set of stress-strain points, defining a stress-strain curve. One of the most used objective error function in engineering software is the sum of the squares of the stress difference at various strains. This function can be mathematically expressed by 2

⎡σ ijsim ( A) − σ ijexp ⎤ S ( A) = ∑∑ ⎢ ⎥ , Dij j =1 i =1 ⎣ ⎢ ⎦⎥ M

Nj

(1)

where A is the vector containing the values of the material parameters, M is the number of curves, Nj is the number of experimental points in each curve and D is a matrix whose coefficients are chosen taking into account the uncertain nature of some observed variables. σsim and σexp are the numerical and experimental values, respectively. Variations of equation 1 were proposed by Mahnken and Stein [24] and by Ghouati and Gélin [26], adding a second term related to stabilization terms and constraints. Gavrus et al. [31] proposed a similar objective function but with an automatic experimental error matrix D, defined as

(

N ⎧⎪ σ kexp ∑ =1 k Di = ⎨ ⎪⎩σ iexp

)

2

if experimental errors are constants if errors are proportional to σ iexp .

(2)

Ponthot and Kleinermann [19] use a relative objective function for the determination of metal forming constitutive models. These authors have shown that a process using relative objective functions reaches the optimum value faster than a process using absolute objective functions. They used the following function:

Software Development for Inverse Determination of Constitutive Model Parameters

M

S ( A) = ∑ j =1

1 Nj

sim exp ωi σ ij ( A) − σ ij ∑ σ ijexp i =1 Ω Nj

ωi is the weight given to the ith experimental point and Ω =

99

2

(3)

∑

N

i =1

ωi is the sum of all

attributed weights. a b = a b if b>10-12 and a b = a if b<10-12. Recently, Cao and Lin [30] have discussed the importance of objective functions for determining material models. They have performed an extensive study of the advantages and disadvantages of different objective functions for unified creep/viscoplastic constitutive equations. These authors have also introduced a new error definition, given by

1 S (A) = M

⎧⎪ 1 ⎨ ∑ j =1 ⎪ ⎩N j M

Nj

∑r i =1

2 ij

⎫⎪ ⎬, ⎪⎭

(4)

with the residual r defined as

(

⎛ ε sim ε Nsimij ε ijexp ε Nexpij 2 rij = ω1ij ⎜ ln ⎜ ε ijexp ⎝

)⎞⎟

(

2

⎛ σ sim ε Nsimij ε ijexp ε Nexpij + ω 2ij ⎜ ln ⎟ ⎜ σ ijexp ⎠ ⎝

)⎞⎟ ⎟ ⎠

2

(5)

and

ωij = φ ⋅ ε ijexp

M

Nj

∑∑ ε j =1 i =1

exp ij

(6)

ω1ij and ω2ij are the weighting factor for the ith experimental data point of the jth curve and ∏ is a scale factor that increases the sensitivity of the objective functions. Figure 3 shows a comparison of experimental data (points) and simulated curve of a physical process. In the same figure, the variations of the objective functions defined in equations 1 to 6 are presented. The first points of the experimental curve are negative not permitting the calculation of the objective function proposed by Cao and Lin due to the use of the ln( ) function. This observation reflects the main failure of Cao and Lin’s objective function, not prepared for the cases when the experimental and simulated values have different signals. The objective function (OF) proposed by Ponthot and Kleinermann [19] reflects well the relative differences between the experimental and the simulated curves. But this OF denotes a disequilibrium when the experimental value tend to zero. This fact can be observed by the peak at ε=0.12, induced by the division of an experimental value of εexp < 1. For ε > 0.25, Ponthot and Kleinermann’s OF matches the OF proposed by Cao and Lin. Both OF define relative errors. Therefore, when the values of εexp increase the absolute differences are minimized, leading to smaller relative errors. This can influence the optimization process considering that some data points will not have an equal opportunity to be optimized. The

100

A. Andrade-Campos, P. Pilvin, J. Simões et al.

data points with smaller εexp will have greater weight in the OF and, consequently, in the optimization process. 340

Experimental datal OF square of the differences OF by Cao and Lin

290

1000

Simulation data OF by Ponthot and Kleidermann

100

1 190

σ

0.1

140

Value of OF

10

240

0.01 90

0.001

40 -10

0.0001

0

0.1

0.2

0.3

0.4

ε

0.5

0.6

0.00001

Figure 3. Comparison of different objective functions (OF). Final value of the objective function (i) Square of the differences =2117.12; (ii) Ponthot and Kleinermann = 2.79; (iii) Cao and Lin = 0.622; (iv) RQUAD=0.997956; Bias=3.59;

The OF defined in equation 1 has the huge advantage of simplicity and agreement to the second∗ criteria. However, if multi-sub-objectives are used, it is necessary to add a coefficient to level the different units of each sub-objective. In economics, statistics and spreadsheet software, the RQUAD function is generally used to correlate different curves. The RQUAD function defines the square of the Pearson product and can be written as

∑ [σ N

RQUAD = 1 −

i =1

N

∑σ i =1

exp i

sim i

−

( A) − σ iexp

(∑

N i =1

σ

exp i

)

]

2

2

(7)

N

This OF is used often in engineering software but it is a good correlation indicative. Note that 0
∑ [σ N

i =1

sim i

( A) − σ iexp

]

∗ The second criteria state that all the experimental data points on a single curve should be considered in the optimization and have an equal opportunity to be optimized

Software Development for Inverse Determination of Constitutive Model Parameters

101

Identification Methodology The identification methodology is supported by the following supposition: The problem of determination of constitutive material model parameters is posed using an inverse formulation that, in its general form, leads to the resolution of a non-linear optimization problem. The identification methodology has the goal of finding the solution of the following optimization problem:

Finding A=[A1, A2,… Ar]T such that min S(A) subject to Ai,min≤Ai≤Ai,max M

∑g m =1

m

( A) ≤ 0

This problem presents the classical structure of an optimization problem. However, the objective function is implicit, non-convex and strongly nonlinear. Generally, the constraints in the identification method define the universe of each parameter. Additionally, other constraint functions can be formulated as inequalities. Some optimization methods, namely some gradient methods, can deal directly with the constraint functions. However, the generality of the methods and algorithms are not prepared for all kind of constraints. One way to overcome this problem is to transform the constraint optimization problem into an unconstraint problem, inserting penalty functions. Thus, the constraints are directly incorporated in the objective function.

Optimization Methods The resolution of an optimization problem often cannot be achieved analytically and must be carried through with the aid of iterative numerical methods. The use of these methods is associated to theoretical and numerical difficulties - there is no unique solution for a nonlinear identification problem (see e.g. [3]). This fact causes practical difficulties to the interpretation and selection of the obtained results. Optimization methodologies can be divided in two classes: (i) exploratory methods, which only use the value of the function to minimize and (ii) slope or gradient methods, that use, in addition to the value of the function, information from the gradients (first order methods) and the Hessian (second order methods) of the function. The nonlinear optimization methods based on the gradient-function can reach local minima through an iterative process whatever the initial guess of the solution. However, these are frequently not the absolute minimum. In most situations, the solution depends on the initial estimation of parameters, leading to different results. Some exploratory methods need a high number of evaluations of the cost function. Thus, these methods can only be used when the effort to evaluate the function is reduced. With the increase of computational power in the last few years, this

102

A. Andrade-Campos, P. Pilvin, J. Simões et al.

approach, more general and easier to implement, gained new breath. However, gradient methods continue to be computationally more efficient. There is a large number of optimization methods (and their variants). Even thought, it is difficult to find efficient and robust optimization methods to solve identification problems. The three main groups of optimization algorithms are (i) the gradient-based methods, (ii) the nature-inspired algorithms and (iii) artificial intelligence algorithms. The two last groups belong to the class of exploratory methods. From the gradient-based methods, traditional procedures, such as BFGS (BroydenFletcher-Goldfarb-Shanno) or conjugate gradient, are divided in the following stages: (i) a descent direction is computed based on the value of the gradient vector at the current iteration point and the previous results. The determination of the descent direction depends directly on the traditional method chosen. (ii) A line-search algorithm is used to calculate the step size and the new approximation point is found using the step size and the direction previously determined. The efficiency of these methods depends uniquely on the efficiency of the computation of the descent direction. The gradient-methods based on the solution of a nonlinear system of equations show more performance than traditional methods. The Gauss-Newton (or Newton-Raphson) and the Levenberg-Marquardt methods belong to this group. They seek the roots of a non-linear system of equations in which the optimization parameters are the unknown variables. It is known that the Gauss-Newton method is very efficient when the optimization variables are far from the optimum but it is not so efficient close to the optimum [19]. The LevenbergMarquardt method is a stabilization of the previous method. Therefore, its results are expected to be better. Other gradient-based methods often applied for identification software are the convex approximation methods, such as the SQP (Sequential Quadratic Programming), Methods of Moving Asymptotes (MMA) and the convex linearization (CONLIN) methods. These methods replace the original problem with a sequence of simple convex explicit subproblems. Then, the optimum of each sub-problem becomes the new parameter approximation and a new sub-problem is successively formulated considering the original problem. Convex approximation methods converge slower than the above mentioned methods and can fail when the convexity is not correctly assigned. However, these methods are already prepared for constrained optimization. The most widely used nature-inspired algorithms are the genetic and evolutionary algorithms, the particle swarm optimization (PSO) and the immune algorithms. While immune algorithms are inspired in human immunity [32], the PSO imitates mathematically the cooperation seen in animal swarms. The evolutionary optimization techniques are based on Darwin's theory of evolution, the Natural Selection. In nature, individuals have to adapt to the surrounding environment in order to survive. In this process, the characteristics that make an individual more prepared to survive are preserved in its reproduction. The characteristics that make it weaker are eliminated. These characteristics are controlled by units denoted by genes. Throughout subsequent generations, the most capable individuals (and their genes) survive. These are transmitted to their descendants during the sexual recombination process defined as crossing. The analogies between the mechanisms of natural selection and the process of learning (or optimization) led to the development of the techniques designated by evolutionary algorithms [33]. The main objective of these methods is to simulate the evolutionary process using computational calculations. The difference between evolutionary

Software Development for Inverse Determination of Constitutive Model Parameters

103

algorithms and genetic algorithms is the codification of the solutions used during the optimization process. The third optimization methods group is composed by the methods based in neural networks and artificial intelligence [34]. The artificial neural network is composed of programmed interconnecting artificial neurons and, artificially, can make useful decisions that can lead to the optimum solution. The difficulty of using artificial neural networks in identification problems is the need a training stage, in which solutions must be previously known. Other optimization techniques, such as simulated annealing, are also used to identify constitutive model parameters. Simulated annealing techniques, that are probabilistic metaalgorithms, are often used for hard problems where the chances of being trapped in local minima are reduced. By far, the better performing methods are gradient-based. However, their performance is known to be highly dependent on the starting set of parameters and results are often inconsistent. Nature-inspired techniques provide a better way to determine an optimized set of parameters (the overall minimum). Therefore, the difficulty of choosing a starting set of parameters for this process is reduced. However, these proved to be computationally more expensive than the gradient-based method. Optimization methods have advantages and disadvantages and their performance is highly dependent on the constitutive model itself. There is no unique algorithm robust enough to deal with every possible situation. Nonetheless, the use of sequential multiple methods can lead to the global optimum. The aim of this strategy is to take advantage of the strength of each selected algorithm. In this multi-stage strategy, called cascade algorithm, various optimizers are activated one after the other in a predefined sequence. The sequence can be either deterministic or evolutionary. It can even combine gradient and evolutionary algorithms. In this chapter, the sequential use of a gradient-based method and an evolutionary algorithm will be analysed.

Cascade Optimization Strategy for Parameter Identification If different optimization methods can be used, it is important to use methods with different strengths, weaknesses and capabilities. The strengths of the gradient-based methods are their objectivity and low computational cost. However, the performance of these methods is highly dependent on the starting set of parameters and, facing non-convex functions, they have a high probability of converging to a local minimum. By opposition, evolutionary algorithms have proved to be independent of the starting set of parameters and to have a large probability of finding the global minima [2]. However, these advantages are reached at the expense of much more CPU time and objective function evaluations. Considering the advantages and disadvantages of the gradient-based and evolutionary methods, it seems that these methods have opposing strengths and weaknesses. Consequently, they have a high potential to be used in a cascade strategy. For the gradient-based methods, a linearization method (the Levenberg-Marquardt method) was used due to the fact that the objective function decreases fast when the parameters are far from the optimum. The evolutionary algorithm selected was a real search space evolutionary algorithm (EA), where the search universe is a continuous real interval.

104

A. Andrade-Campos, P. Pilvin, J. Simões et al.

For the parameter identification problem, where the parameters are real values, the real search EA exhibits higher efficiency than classical binary genetic algorithms [35].

The Levenberg-Marquardt Method and Sensitivity Analysis Considering the continuity conditions and the existence of a derivative in any point of its universe, it is possible to introduce optimization constraints directly in the objective function equation leading to a non-constraint optimization problem with external penalties. Thus, the problem leads to the minimization of the following function: M

ℵ p (A ) = S (A ) + ∑ { α m max[0, g m (A )]} , 2

(8)

m =1

where the constraints are defined by the M inequalities g m (A ) ≤ 0 . The penalty coefficients, αm > 0, lead to the evolution of the optimization process itself. The algorithm developed by Levenberg [36] and Marquardt [37] is a maximum neighbourhood method, is used in the least square estimation of non-linear parameters and has quadratic convergence. This method is similar to the Gauss-Newton method but adds a new parameter (the Levenberg-Marquardt parameter λ) which stabilizes the Gauss-Newton method when close to the optimum. This parameter is updated every iterations according to the convergence rate. The gradient-methods need the evaluation of the first derivative in relation to the optimization parameters. This operation, often called sensitivity analysis, is of extreme importance for an efficient procedure. The derivatives are assembled in the Jacobian matrix defined by

J iα =

∂σ sim ∂ri = s,i ∂Aα ∂Aα

(9)

where r is the residue vector. The most straight-forward procedure to compute the Jacobian matrix is to use the global finite difference method. The precision of this numerical sensitivity approach is lower than the precision of the analytical or the numerical direct method. However, the CPU effort needed is much lower. Additionally, this method allows the use of the selected optimization method with diverse classes of constitutive models and with external FEM simulation programmes. For the kth iteration of the optimization process, the Levenberg-Marquardt step-size, δk, is determined solving the following system of linear equations [38]:

(J

T k

)

J k + λk I δ k = − J k rk . T

(10)

where I is the second order identity tensor. For the convergence of the method, there always exists λk > 0 such that δk is in a descent direction, leading to a decrease in the magnitude of S(A). To account for the weight penalty functions, a term f containing the first derivative of the weight penalty function can be added to the second member of equation (10).

Software Development for Inverse Determination of Constitutive Model Parameters

105

Additionally, the second derivative of the weight penalty function, H, must be added to the first member of equation (10) [39], i.e.

(J

T k

)

J k + λk I + H k δ k = − J k rk + f k . T

(11)

The Real Search Evolutionary Algorithm The main advantages of the probabilistic optimization algorithms based natural evolution models are the fact that it is not necessary to calculate derivatives and the success in discontinuous and multimodal functions. Considering a population of individuals, represented by a matrix P where part of the population can be deliberately defined and the remaining is randomly generated, i.e.

{

}

P 0 = A10 , A 02 ,…, A γ0 ∈ S ,

and A k = [ A1 , A2 , …, Ar ] , k = 1,... , γ , T

(12)

where S is the universe of the real variable individuals and γ is the total number of individuals. This representation is different of that of the classical genetic algorithm (GA) and its chromosome binary strings, in the sense that it is given by a real search point, which is mathematically represented by real variable vector. The assumption that the direct use of the real search point may search more efficiently than the representation decoded into a binary string was made [2][35]. While the binary string in a GA represents a chromosome (genetic representation of a human being), the real continuous variable vector representation can correspond to a set of phenomenological information of the human being itself [35]. The exploration of the search space is done through the successive application of evolutionary operators. The most usual operators are selection, crossover and mutation. The algorithm developed by the authors also uses the operators elitism, scaling and local refinement. The selection of the individuals, in such a way as to allow the use of evolutionary operations, is performed by two well known methods: (i) the classical roulette and (ii) the stochastic roulette. If two individuals are selected to be parental individuals, Cr: I2→I, the crossover operation can be defined as

(

) (

)

Cr A ϕp , A ξp = 1 − χ ϕp A ϕp + χ ξp A ξp , p

(13)

p

where A ϕ and A ξ are parental individuals at generation p and the coefficient χ is defined depending on the type of crossover. In the crossover technique χφ is defined by a normal distribution where it is possible to define the mean and the standard deviation. The standard deviation can be constant or variable with p and, therefore, may assume an adaptive process strategy. As the search proceeds through the optimization process, the members with less fitness tend to be discarded. So, mutation prevents either prematurely loosing information or reaching local minima. The mutation consists in the alteration of a value of one or more variables in the real vector.

106

A. Andrade-Campos, P. Pilvin, J. Simões et al.

The elitism operator consists in keeping the best fitted individual. This operator assures that the best solution is kept along consecutive generations. Local refinement and scaling are operators that control the increasing and decreasing of the search universe of the population. It is recommended to use local refinement only when a prolonged stagnation has been reached. For further information about this operators see the work of Andrade-Campos et al. [2].

The Cascade Algorithm In this work, a gradient-method (Levenberg-Marquardt (LM) method) and an evolutionary method (real search space EA) will be grouped in sequential/cascade strategies. With these global cascade algorithms, it is intended to aggregate the advantages of both algorithms and to minimize their disadvantages. Hence, the following sequences are proposed: LM + EA, EA + LM and LM + EA + LM. An important point in a cascade algorithm is the choice of criteria used to switch from one optimizer to another. In the present case, the authors adopted a heuristic approach based on numerical experiments. The criteria are: i.

Switching from LM to EA: if, from one iteration to another, the relative decrease of the quadratic objective function is less than 1×10-15 or the maximum admissible iteration number (predetermined value) is reached. ii. Switching from EA to LM: if stagnation of more than 500 generations is observed or the quadratic objective function is less than 1×10-15 or the maximum admissible iteration number (predetermined value) is reached.

It should be noted that when switching from EA to LM, only the best value - the elite - is used as a start value for the gradient-based algorithm. When switching from LM to EA, only one value of the new population is known - and becomes the elite - and the other individuals are randomly generated.

Numerical Applications The algorithms and strategies developed and described in previous paragraphs can be employed in distinct types of optimization problems. As it is not theoretically possible to predict the behaviour of each optimization strategy and algorithm, a set of functions having a continuous real universe as search space was adopted. A set of diverse constitutive models whose parameters must be identified was also adopted.

De Jong Functions De Jong [40] proposed a set of mathematical functions to perform the evaluation of optimization algorithms (benchmark functions). This group of functions represents the difficulties usually encountered in optimization problems in an isolated form and allows the

Software Development for Inverse Determination of Constitutive Model Parameters

107

relative evaluation of the strong and weak points of each optimization algorithm. The functions, whose global minima is given by f(x*), are defined as

Function I (sphere model) :

n

f1 (x ) = ∑ xi2 , x ∈ ℜ n , n = 10 i =1

− 5.12 ≤ xi ≤ 5.12 T f1 (x *) = 0, x* = [0, … ,0] ; Function II (step function) :

,

(14)

n

f 2 (x ) = 6n + ∑ ⎣xi ⎦, x ∈ ℜ n , n = 5 i =1

, − 5.12 ≤ xi ≤ 5.12 T f1 (x *) = 0, x* = [− 5.12, … ,−5.12] ; Function III (Rosenbrock) :

n −1

(

(

f 3 (x ) = ∑ 100 ⋅ xi +1 − xi2 i =1

− 5.12 ≤ xi ≤ 5.12

) )+ (x − 1) , x ∈ ℜ , n = 6 2

2

i

(15)

n

.

(16)

f1 (x *) = 0, x* = [1, … ,1] . T

Function I represents a set of quadratic, and therefore continuous, unimodal and convex functions. This function is often used as the first test case of non-linear function since many objective functions take this form. The performance for the sphere function is a measure of the global efficiency of the algorithm. Function II is based on a linear discontinuous function. This function has a number of plateaus defined by the integer operator ⎣ ⎦ . Gradient-based optimization methods deal badly with such functions due to their discontinuity and because the plateaus do not allow the determination of the most favourable direction. If the numerical algorithm does not have adaptive step size, it will be trapped in one of the plateaus. The generalized Rosenbrock function (function III) is considered to be a complex function due to the large central platform and due to the high slope on its limits. Representations of these functions are shown in Figure 4.

(a)

(b)

(c)

Figure 4. Three-dimensional representation of functions (a) I (sphere function), (b) II (step function) and (c) III (Rosenbrock function).

108

A. Andrade-Campos, P. Pilvin, J. Simões et al.

The results obtained by the different strategies are listed in Table 1. The results obtained with the EA correspond to the average performance of each algorithm for 10 executions, with a population of 10 with elitism and crossover and mutation probabilities of 0.6 and 0.001, respectively. Both optimization methodologies, when used individually, reach the minimum for function I. However, the EA needs to perform 4008 more evaluations of the objective functions than the Levenberg-Marquardt (LM) method. As expected, the gradient-based method proved to be more objective than the evolutionary-based method. The cascade strategies have shown to be as efficient as the use of the LM method individually. The exception is the EA+LM strategy, in which the LM method needed more iterations to reach an admissible value of the objective function. This fact can be attributed to the initial values given by the EA method that made it harder to compute the step size and direction by the LM method. It should be noted that the maximum number of generations and iterations was both 100. A higher number of generations and iterations would lead to a better final result. Table 1. Results of the different optimization strategies and algorithms used for the De Jong functions. Function I Function II Function III (sphere model) (step function) (Rosenbrock) Initial values (xi) {5, 5, …, 5}T {5, 5, …, 5}T {5, 5, …, 5}T Boundaries [xmin, xmax] [-5.12, 5.12] [-5.12, 5.12] [-5.12, 5.12] 55 2.027 LM Final quadratic error 1.1×10-22 Iterations 13 6 123 Evaluations 13 6 123 55 2.027 f(x*) 1.1×10-22 -5 EA Final quadratic error 4.1×10 0 0.138 Generations 4021 43 5000 Evaluations 25700 285 30831 -5 0 0.138 f(x*) 4.1×10 LM+EA Final quadratic error 1.1×10-22 0 1.5×10-2 Iterations + Generations 13+1 6+43 123+5000 Evaluations 23 6+285 123+30890 0 1.5×10-2 f(x*) 1.1×10-22 -5 EA+LM Final quadratic error 8.4×10 0 0.1154 Generations + Iterations 100+100 43+6 5000+28 Evaluations 645+100 285+6 30865+28 -5 0 0.1154 f(x*) 8.4×10 0 4.19×10-4 LM+EA+LM Final quadratic error 2.4×10-23 Iter.+ Gener.+ Iter. 13+1+11 6+43+6 123+5000+11 Evaluations 13+10+11 6+285+6 123+30890+11 0 4.19×10-4 f(x*) 2.4×10-23 Function

The results achieved for function II demonstrated the superiority of the evolutionary algorithms when compared to the gradient-based methods regarding discontinuous and/or step functions. For this function, the LM method (either individually or in cascade) cannot

Software Development for Inverse Determination of Constitutive Model Parameters

109

determine the direction to follow even when using an adaptive step size. The plateau is larger than the perturbation used in the finite difference computation of the gradient vector. The various cascade optimization strategies are effective due to the solely existence of at least of one EA stage. The results accomplished with each individual optimization algorithm for the Rosenbrock function are not satisfactory. Although the LM method reached stagnation for a quadratic error of 2.027, the EA method needed more than 30000 evaluations to reach a minimum of 0.117. Notice that, for this problem, the maximum number of generations was limited to 5000. Both the LM+EA and LM+EA+LM optimization strategies led to satisfactory results. The evolution of the quadratic error during the optimization process for the different strategies is represented in Figure 5. For the strategies where LM is the first optimization method, convergence is reached rapidly in the first 100 iterations with relatively small error levels. This fact demonstrates once more the objectivity demonstrated by the gradient-methods. However, in all these strategies, the stagnation is observed of the following method in almost 2000 generations. This can be attributed to the difficulty of EA method to get out of local minima with possible premature convergence. The strategies that start with the EA method always show a convergence with stagnation under 500 generations. Note that EA+LM and LM+EA+LM strategies show a relatively sudden increase of the quadratic error in the end of the calculation process (see Figure 5). For the LM method, this increase occurs when the alteration of the step size (for evaluation of the adaptive step-size) leads to an increase of the quadratic error. This is automatically corrected in the following iteration with a step reduction and an alteration of the direction. 10000 LM

Quadratic OF error

1000

EA LM+EA

100

EA+LM

10

LM+EA+LM

1.E+06

1

1.E+05 1.E+04

0.1

1.E+03 1.E+02

0.01

1.E+01 1.E+00 0

0.001 0

500

50

100

1000 1500 2000 2500 3000 3500 4000 4500 5000

Iterations/Generations Figure 5. Evolution of the objective function (OF) for the different cascade optimization strategies for the generalized Rosenbrock function (function III).

110

A. Andrade-Campos, P. Pilvin, J. Simões et al.

Identification of a Non-linear Elastic-Plastic Hardening Model The second application of the cascade strategies is the identification of the parameters of a constitutive elastic-plastic model with non-linear hardening for steel used in piping manufacture in the nuclear industry (A-533 Steel, Grade B, Class I). The hardening law can be described by the following equation:

σ (ε pl ) = σ 0 + (σ ∞ − σ 0 )[1 − exp(− δε pl )]+ ζε pl , where

(17)

ε pl = 2 3 ε ijplε ijpl is the equivalent plastic strain and ε ijpl is the plastic strain tensor.

This constitutive model has four parameters that must be identified: σ0, σ∞, δ and ζ. Table 2. Initial and optimal values for the hardening model.

Parameters Initial values (xi) Boundaries [σ0min, σ0max] [σ∞min, σ∞max] [δmin, δmax] [ζmin, ζmax] LM Final quadratic error Iteration Evaluations x* EA Final quadratic error Generations Evaluations x* LM+EA Final quadratic error Iteration + Generations Evaluations x* EA+LM Final quadratic error Generations + Iteration Evaluations x* LM+EA+LM Final quadratic error Iter.+ Gener.+ Iter. Evaluations x*

Elastic-plastic model {σ , σ , δ, ζ}T {550, 800, 25, 230}T [1, 800] [200, 900] [1, 50] [200, 500] 0.851 86 86 {457.8, 657.7, 18.9, 308.9}T 1.025 3000 18529 {457.5, 656.4, 19.4, 312.7}T 0.851 86+1000 86+6181 {457.8, 657.7, 18.9, 308.9}T 0.861 1000+28 6187+28 {457.7, 657.3, 18.9, 309.8}T 0.845 86+1000+36 86+6127+36 {457.9, 657.8, 18.9, 308.8}T 0

∞

Table 2 shows the results obtained with different optimization strategies. From the results listed in this table, it is possible to conclude that all the strategies lead to satisfactory results

Software Development for Inverse Determination of Constitutive Model Parameters

111

and similar final parameters. A maximum number of generations of 3000 was chosen for the EA method when used individually. For the multiple methods strategies 1000 was chosen as the maximum number of generations. The initial and final stress-strain curves are shown in Figure 6. From this figure, it is possible to conclude that the stress-strain curve with the indentified parameters accurately represent the experimental results. Figure 7 shows the evolution of the quadratic error for the calculation period for the different optimization strategies. As can be seen from these results, when used separately, the LM method is more efficient than the EA. This efficiency is evaluated through the computational quality/cost relation (the computational cost proportional to the number of iterations and generations). While the LM method needs only 80 iterations (equivalent to the 80 evaluations of the objective function) to reach a quadratic error lower than the unity, the EA method needs at least 3000 generations (18529 evaluations) to reach a quadratic error of 1.025. Thus, the LM method only uses approximately 5% of the time required for EA method. This significant difference can be attributed to the size of the EA search universe. In the optimization strategies where the LM method is used before the EA, a stagnation of the EA method is observed that lasts around 1000 generations. This occurrence can be explained by the fact that the minimum of the function was already found with the LM method and, consequently, the error is small. From the results in Figure 7 and Table 2, it is possible to notice that there is no significant reduction of the quadratic error for multiple optimization methods if the LM method is used. 1000 900

Stress [MPa]

800 700 600 500 400 300

Experimental curve Final parameters Initial parameters

200 100 0 0

0.1

0.2

0.3

0.4

0.5

0.6

Strain Figure 6. Comparison of experimental and numerical stress-strain results for the elastic-plastic constitutive model.

Hence, for constitutive models whose equation is continuous and unimodal, as the elasticplastic model described in this section, the LM method (gradient-based method) is more efficient than EA and a cascade strategy is not necessary to identify its parameters. However, the cascade strategy leads to a slightly higher precision than the one of the LM method.

112

A. Andrade-Campos, P. Pilvin, J. Simões et al. 10000

1.E+05

LM

Quadratic error

1.E+04

EA

1000 100

1.E+03

LM+EA

1.E+02

EA+LM

1.E+01

LM+EA+LM 1.E+00 1.E-01

10

0

50

1 0.1 0

250

500

750

1000

1250

1500

1750

2000

2250

Iterations/Generations Figure 7. Comparison of the convergence of the cascade optimization strategies in the parameter identification of the elastic-plastic model.

Identification of a Set of Hyperelastic Models Presently, numerical simulation assumes a significant role in the understanding of the behaviour of some biological materials. Most of the work presented until today uses hyperelastic models for the simulation of the mechanical behaviour of biological soft tissues under uniaxial tension. The models of Humphrey [9], Martins [10], Mooney-Rivlin [11][12], Neo-Hookean, Ogden [13], Veronda-Westman [14] and of Yeoh [15] are such examples. Recently, Martins et al. [15] presented a comparative study of the performance of such material models in the prediction of the hyperelastic properties in biological tissues Hyperelastic models, however, depend on sets of variables that must be obtained experimentally. Hyperelastic constitutive models are often based on the definition of the strain energy and, in the case of isotropic hyperelastic models, they depend on the strain invariants. In the case of uniaxial stretch, applicable in uniaxial tensile tests of incompressible hyperelastic materials, the Cauchy stress σ assumes the following form:

⎛

1 ⎞⎛ ∂Ψ

1 ∂Ψ ⎞

⎟. σ = 2⎜ λ2 − ⎟⎜⎜ + λ ⎠⎝ ∂I1 λ ∂I 2 ⎟⎠ ⎝

(18)

Ψ represents the strain energy function, λ is the uniaxial principal stretch and I1 and I2 are the first and the second strain invariants, respectively. The Humprey, Mooney-Rivlin and Veronda-Westmann models have only two parameters that need to be identified. These models are both defined by the following strain energy expressions:

ΨHumphrey = c1{exp[c2 (I1 − 3)] − 1},

(19)

Software Development for Inverse Determination of Constitutive Model Parameters

113

ΨMooney− Rivlin = c1 (I1 − 3) + c2 (I 2 − 3),

(20)

ΨVeronda − Westmann = c1{exp[c2 (I1 − 3)] − 1}−

c1c2 (I 2 − 3). 2

(21)

The Yeoh model [15], developed to represent the behaviour of elastomeric incompressible materials, uses three constitutive parameters and has a structure similar to the Mooney-Rivlin model [11]. This model can be written in the following form:

ΨYeoh = c1 (I 1 − 3) + c 2 (I 1 − 3) + c 3 (I 1 − 3) . 2

3

(22)

The most recent model employed in this work is the Martins [10] model. This model has four parameters and can account for anisotropy created by the fibres (defined by the c3 and c4 parameters). Martins’s strain energy is defined by

[

[

]

]

ΨMartins = c1 e c2 ( I1 −3 ) − 1 + c3 e c4 (λ −1) − 1 . 2

(23)

The model whose parameter determination is more difficult is the Ogden [13] model due to its relatively high number of parameters: six. This model can be defined by N

c ( 2i −1)

i =1

c 2i

ΨOgden = ∑

(λ

c2 i 1

)

+ λ c22 i + λ c32 i − 3 ,

(24)

with N=3 and, consequently, cmax=c6. As reference, a simplified model of the Neo-Hookean type can also be used. Its strain energy, Ψ=c1(I1 - 3), comprises a single parameter that needs to be identified.

0.12

Experimental Humphrey

Stress, σ [MPa]

0.1

Martins Mooney-Rivlin

0.08

Neo-Hookean Ogden

0.06

Veronda-Westmann Yeoh

0.04 0.02 0 1

1.05

1.1

1.15

1.2

1.25

1.3

1.35

1.4

1.45

1.5

Elongation, λ=(l +Δl )/l

Figure 8. Stress-stretch curve for pig muscular tissue. Experimental and numerical results for different hyperelastic constitutive models.

Table 3. Results obtained with the different optimization strategies. List of the parameters achieved for the hyperelastic constitutive models.

Initial Constitutive model values (ci)

mphrey

1.0

Levenberg-Marquardt method (LM) Boundaries ([cmin,cmax])

[-10,10]

Final quadratic Iter. error 1.60E-05

Parameters 67

0.010074

Evolutionary algorithm (EA)

Final quadratic Gener. error 1.62E-05

4085

1.393202 rtins

Mooney-Rivlin o-Hookean den

1.0

[-10,10]

3.72E-06

79

1.0

[-10,10]

9.8E-06

500

0.001

[-10,10]

1.86E-04

10

1.0

[-10,10]

1.67E-07

370

-0.080145

1.73E-07

7034

oh

1.0

[-10,10]

9.97E-06

49

7.60E-07

45

Iter.

Parameters

1.59E-05

4085

30

0.010225

-0.097120

1.69E-07

7034

23

-0.097006

1.382680

0.850211

0.849259

0.672615

-0.110218

-0.110193

0.165061

-2.166067 9.36E-06

10000

0.026910

1.88E-04

1000

-0.427402

6.02E-07

10000

0.092100

-2.162456 9.39E-07

10000

4

0.026046

1.86E-04

1000

6

0.026910

0.303149

2.04E-07

10000

498

-0.491979

0.0933134 -0.0933132

0.0933227 -0.0933131

0.495076

-0.215131

-0.64259

0.655642

0.555175

0.528165

1.647322

1.406863

1.543324

-1.315796

1.150036

4.258648

0.022462

-0.644065 1.00E-05

3126

0.983166 [-10,10]

0.009809

Final quadratic Gener. error

0.394441

0.663916 1.0

Parameters

1.423610

-0.092091

ondastman

EA+LM

0.005843

0.022482

-0.268347 9.87E-06

3126

30

2.34E-07

6784

33

0.986504 2.52E-07

6784

0.005606

0.023285 0.962229 0.005381

0.033888

0.033372

0.033757

-0.012706

-0.012207

-0.012373

[gilac1]

Software Development for Inverse Determination of Constitutive Model Parameters

115

Parameter determination should always be performed confronting numerical and experimental results and should obey to some physical constraints (e.g. c1+c2 ≥ 0 for the Mooney-Rivlin model). The experimental results used in this work for the determination of the hyperelastic models’ parameters are the ones obtained by Martins et al. for pig muscular tissue [15]. These results are shown in Figure 8. For the seven hyperelastic models, the EA+LM cascade strategy is evaluated comparing with the sole use of either the EA or the LM method. The results of the different optimization methods and the obtained final parameters are listed in Table 3. It is possible to observe and conclude that the best results (the lowest quadratic errors) are always obtained by the cascade algorithm. It must be notice that the values of the quadratic error are lower than unity for the reason that the stress values (in MPa) are of the order inferior of the unity. Figure 8 presents the stress-strech curves obtained with the hyperelastic constitutive models described in equations 19 to 24 whose coefficients are listed in Table 3. With the exception of the Neo-Hookean model, all other hyperelastic models characterize fairly well the uniaxial mechanical behaviour of the biological soft tissue. Yet, the models that better characterize the experimental curves are the Ogden and Martins models followed by the Yeoh model. This was expected and confirms the results of Martins et al. [15].

Identification of an Internal Variable Thermoelastic-Viscoplastic Model The thermoelastic-viscoplastic constitutive model used in this work is based on the models presented by Brown and Anand [9][18]. This model, developed to describe the deformation of metals at high temperatures and moderate strain rates, uses only one internal state variable. The model assumes three state variables that are the Cauchy stress tensor, σ, the absolute temperature, T, and the isotropic resistance to plastic deformation, s. This last scalar variable accounts for the evolution of the dislocation structure, grain size effects, lattice resistance, etc. [9]. The flow rule is defined as

D vp =

3εp σ′ , 2σ

(25)

where Dvp is the viscoplastic part of the strain rate tensor, σ′ represents the deviatoric stress p tensor and σ is the von Mises equivalent stress. ε is the equivalent plastic strain rate, considered to be dependent on the equivalent stress, the temperature and the evolutive internal state variable s and takes the following form

⎛ Q ⎞⎡ ⎟ ⎢sinh ⎛⎜ ξ σ ε = A exp ⎜⎜ − ⎟ ⎝ s ⎝ RgT ⎠ ⎣ p

⎞⎤ ⎟⎥ ⎠⎦

1

m

.

(26)

In the constitutive model, A, m and ξ are parameters characteristics of the material. Rg is the universal gas constant. Q represents the activation energy and is given as a function of the temperature, i.e. [41]

116

A. Andrade-Campos, P. Pilvin, J. Simões et al.

⎧ ⎡ ⎛T ⎪ Q0 ⎢1.0 + log ⎜ t Q= ⎨ ⎣ ⎝T ⎪Q ⎩ 0

⎞⎤ ⎟⎥ ⎠⎦

if T ≤ Tt

.

(27)

if T > Tt

Q0 is the activation energy in steady-state conditions and Tt is a behaviour transition temperature. The state variable s and its evolution are defined by the following relation:

s s = ε h0 1 − ∗ s p

a

s⎞ ⎛ sgn ⎜1 − ∗ ⎟ , ⎝ s ⎠

(28)

where s* is the saturated value of the internal variable s and is given by n

⎡ε p ⎛ Q ⎞⎤ s = s ⎢ exp ⎜ ds ⎟⎥ . ⎜ R T ⎟⎥ ⎝ g ⎠⎦ ⎣⎢ A ∗

(29)

In the previous mathematical expressions, h0, a, s , n, and Qds are material parameters. Additionally, |x| and sgn(x) are the absolute value and sign of x, respectively. The initial value of the internal state variable s, s0, can be a linear function of temperature, i.e.

s 0 = s 0,1 + s 0, 2T

(30)

where s0,1 and s0,2 are also material parameters. This constitutive model has 12 parameters that must be identified: A, ξ, m, Q0, Tt, h0, a, s , Qds, n, s0,1 and s0,2. This model has the complexity of having a third external variable leading to the determination of the material parameters in a three-dimensional space {ε, T, σ} rather than the usual two-dimensional space {ε, σ}. The success of identification of constitutive model parameters depends on the experimental data. Experimental tests were done for uniaxial tension and simple shear at different temperatures on aluminium alloy specimens. A detailed description of the experimental work can be found in [41]. The material properties for this alloy are all temperature dependent. The Young modulus and Poisson ratio are given as

E (T ) = 72474.0 − 43.48(T − 273) [MPa]

(31)

And

υ (T ) =

18392.0 − 9.366(T − 273) , 54082.0 − 34.114(T − 273)

respectively, where T is the temperature in K [42].

(32)

Software Development for Inverse Determination of Constitutive Model Parameters

117

Table 4. Results obtained with the different optimization strategies and methods for the thermoelastic-viscoplastic constitutive model.

Parameters Initial values (xi) Boundaries

LM

[Amin, Amax] [mmin, mmax] [ξ min, ξ max] [Q0min, Q0max] [Tt min, Tt max] [h0min, h0max] [amin, amax] [ smin , smax ] [nmin, nmax] [Qds min, Qds max] [s0,1min, s0,1max] [s0,2min, s0,2max] Final quadratic error Iterations Evaluations x*

EA

Final quadratic error Generations Evaluations x*

LM+EA

Final quadratic error Iterations + Generations Evaluations x*

EA+LM

Final quadratic error Generations + Iterations Evaluations x*

LM+EA+LM

Final quadratic error Iter.+ Gener.+ Iter. Evaluations x*

Thermoelastic-viscoplastic model { A, m, ξ, Q0, Tt, h0, a, s , n, Qds, s0,1, s0,2}T {1.91×106, 0.13, 10.7, 265×103, 600, 915.6, 1, 30, 0.085, 165×103, 58.4, 0.067}T [1×104, 1×1011] [0.01, 0.5] [1.5, 50] [50×103, 400×103] [0, 950] [200, 5000] [0.1, 5] [1, 150] [0.01, 0.5] [50×103, 400×103] [25, 150] [0, 0.08] 16626.2 800 800 {6.42×107, 0.26, 1.7, 185×103, 600, 3654.3, 4.89, 48.2, 0.01, 256×103, 31.7, 0.02}T 16304.0 20000 114250 {3.65×107, 0.2, 7.75, 197×103, 600, 3668.9, 2.97, 74.7, 0.056, 221×103, 34.0, 0.069}T 16048.7 400+5000 400+32432 {1.31×109, 0.10, 14.7, 170×103, 600, 4130.0, 4.1, 128, 0.06, 179×103, 147.4, 0.07}T 15701.3 5000+337 32160+337 {1.31×109, 0.10, 14.6, 171×103, 600, 4129.0, 4.1, 128, 0.06, 179×103, 147.4, 0.071}T 15552.7 400+15000+380 400+96636+380 {1.31×109, 0.09, 14.7, 170×103, 600, 4130.7, 4.2, 128, 0.06, 178×103, 147.4, 0.069}T

118

A. Andrade-Campos, P. Pilvin, J. Simões et al.

In this constitutive model the internal variable s is defined in a differential form (see equation 28). The explicit numerical integration methods of the Runge-Kutta type have demonstrated to be sufficiently effective in the integration of these equations. The effectiveness of these methods is enhanced if adaptive step is introduced. In this work, second (rk21) and fifth (rk54) Runge-Kutta integration methods with initial conditions and error control were used. Table 4 summarizes the results achieved for the different cascade optimization strategies for the thermoelastic-viscoplastic model. In accordance with this table, it can be observed that all the strategies lead to a similar error level. The error found for the individual use of the EA is lower than the error found for the LM method. However, this result is accomplished at the expense of high computational cost (more than 105 evaluations). The final error achieved with the cascade strategies is lower than to the error reached if the methods are used individually, hence demonstrating the efficiency of the cascade algorithms. It is important to notice that the set of parameters found by the different strategies is distinct. This indicates a multiplicity of local minima of the objective function. The fact that a non-zero final quadratic error is reached can be attributed to the impossibility of the thermoelastic-viscoplastic law to duplicate with full accuracy the experimental results, independently of the material parameters. It is also relevant to point out that the large size of the error (of order of 104) is also due to the definition of the absolute quadratic error. For example, the quadratic error of 16000≈126.52 contains a sum of more than 110 absolute errors (≈11 experimental comparison points for each of the 10 curves). The average of the absolute error per experimental point is 3.7 MPa. The stress-strain curves for the uniaxial tensile and shear tests simulated with the optimum parameters found by the LM+AE+LM strategy are shown in Figure 9 and Figure 10, respectively. From these results it is possible to verify a lower accuracy in the first stages of the tests. 120 100

Stress, σ [MPa]

80 60 Experimental: 40 20 0 0

0.05

0.1

0.15

Strain, ε

Numerical:

T = 298 K T = 313 K T = 348 K T = 383 K T = 423 K

T = 298 K T = 313 K T = 348 K T = 383 K T = 423 K

0.2

0.25

Figure 9. Stress-strain curve for the uniaxial tensile test at different temperatures. Comparison between experimental and numerical results for a thermoelastic-viscoplastic model.

Software Development for Inverse Determination of Constitutive Model Parameters

119

70

Shear stress, τ [MPa]

60 50 40 30 Experimental: T = 293 K T = 313 K T = 348 K T = 383 K T = 423 K

20 10 0 0

0.05

0.1

0.15

0.2

Numerical: T = 293 K T = 313 K T = 348 K T = 383 K T = 423 K

0.25

0.3

Shear strain, γ

Figure 10. Stress-strain curve for the shear test at different temperatures. Comparison between experimental and numerical results for a thermoelastic-viscoplastic model.

The evolution of the quadratic error for the first 5500 iterations/generations for the different optimizations strategies is presented in Figure 11. The strategies that initiate with the EA method converge rapidly as the LM method in the first generations. However, the computational effort in each generation is ten times the effort for the LM method (with a population of 10). In the strategies whose first method is the LM, the quadratic error is constant in the first 13 iterations since the first 13 (number of parameters +1) iterations are used for the calculation of the Jacobian matrix with the global finite differences method. In this method, a small perturbation is introduced (generally between 0.01 and 0.001) in each parameter for initial iteration. 10000000 10000000

LM

Quadratic error

EA 1000000

LM+EA

1000000

EA+LM LM+EA+LM

100000

100000

10000 0

50

100

150

200

10000 0

1000

2000

3000

4000

5000

Iterations/Generations Figure 11. Comparison of the convergence for the different cascade optimization strategies in the parameter identification for a thermoelastic-viscoplastic constitutive model.

120

A. Andrade-Campos, P. Pilvin, J. Simões et al.

Conclusion Currently, many constitutive models require the determination of a large number of parameters adjusted to the material whose behaviour intends to simulate. This procedure can be performed through an optimization algorithm, confronting the numerical results with experimental results. There is no unique algorithm robust enough to deal with every possible situation. Consequently, it can be demonstrated that the use of only one optimization method does not lead to the efficient resolution of the problem of determination of the parameters of constitutive models. Although any problem can be solved by at least one optimization method, no individual optimizer is able to solve all problems. The robustness of the optimization algorithms can be improved by the introduction of cascade algorithms. This multi-stage strategy, in which various optimization methods are activated one after another in a pre-specified sequence, can gather the strengths of each selected algorithm. In this work, the authors presented cascade strategies for the determination of material parameters that successively use a gradient-based method (Levenberg-Marquardt method) and an evolutionary-algorithm inspired method. The evolutionary algorithm proposed in this work is an algorithm whose optimization and search is carried out in a continuous real space, without binary codification. The efficiency of the proposed cascade strategies was evaluated through a set of mathematical functions, seven hyperelastic models and two hypoelastic-plastic models. The applied mathematical functions belong to the group of functions suggested by De Jong. All cascade optimization strategies were capable to reach the global minimum in all the proposed functions. The major difficulties were associated to the search of the minimum for the Rosenbrock function. The LM+EA and the LM+EA+LM were the optimization strategies that delivered the best results. The parameters of an elastic-plastic constitutive model and of a thermoelasticviscoplastic model were identified. While the elastic-plastic model with non-linear hardening contains four parameters, the thermoelastic-viscoplastic model has 12 parameters. The more efficient strategy in the identification of these parameters was the LM+EA+LM. In the case of the thermoelastic-viscoplastic model, the set of parameters found as optimum for the different strategies is distinct, indicating a multiplicity of local minima of the objective function. Having in account the demonstrated applications, it can be concluded that, in a general form and taking in account the robustness, precision and CPU time, the LM+EA+LM algorithm is recommended.

Acknowledgement The authors acknowledge financial support given by the FCT – Fundação para a Ciência e Tecnologia – throught the project PTDC/EME-PME/68975/2006 and the grant SFRH/BPD/20539/2004 co-financed by European community fund FEDER. The authors also thank GRICES and EGIDE for the financial support through the cooperative science Program PESSOA.

Software Development for Inverse Determination of Constitutive Model Parameters

121

References [1]

[2]

[3] [4]

[5] [6] [7]

[8] [9] [10]

[11] [12] [13] [14] [15]

[16] [17] [18]

Bruhns, O. T.; Anding, D. K. On the simultaneous estimation of model parameters used in constitutive laws for inelastic material behaviour. Int. J. Plasticity 1999, 15 (12), 1311–1340. Andrade-Campos, A.; Thuillier, S.; Pilvin, P.; Teixeira-Dias, F. On the determination of material parameters for internal variable thermoelastic-viscoplastic constitutive models. Int. J. Plasticity 2007, 23 (8), 1349–1379. Pilvin, P. Parameter Identification of Constitutive Equations, Proc. of Int. Seminar on the Inelastic Behaviour of Solids: Models and Utilization, Besançon, 1988, 155-164. Patnaik, S. N.; Coroneos, R. M.; Guptill J.D; Hopkins, D.A. Comparative evaluation of different optimization algorithms for structural design applications. Int. J. Numer. Meth. Engng 1996, 39, 1761-1774. Patnaik, S. N.; Coroneos R. N.; Hopkins, D. A. A cascade optimization strategy for solution of difficult design problems, Int. J. Numer. Meth. Engng 1997, 40, 2257- 2266. Papadrakakis, M.; Tsompanakis Y.; Lagaros, N. D. Structural shape optimization using evolution strategies. Engrg Optim. 1999, 31, 515-540. Lagaros, N. D.; Plavris V.; Papadrakakis, M. Multi-objective design optimization using cascade evolutionary computations. Comput. Methods Appl. Mech. Engrg. 2005, 194, 3496-3515. François, D.; Pineau, A. ; Zaoui, A. Mechanical Behaviour of Materials – Volume I: Elasticity and Plasticity, Kluwer Academis Publishers, Dordrecht, Holland, 1998. Humphrey, J. D. Continuum biomechanics of soft biological tissues. Proc. Math. Phys. Eng. Sci. A 2003, 459, 3–46. Martins, J. A. C.; Pires, E. B.; Salvado, R.; Dinis, P. B. A numerical model of passive and active behaviour of skeletal muscles. Comput. Methods Appl. Mech. Eng. 1998, 151, 419–433. Mooney, M. A theory of large elastic deformation. J. Appl. Phys. 1940, 11, 582–592. Rivlin, R. S. Large elastic deformations of isotropic materials. iv: Further developments of the general theory. Philos. Trans. R. Soc. Lond. 1948, A241, 379. Ogden, R. W. Non-Linear Elastic Deformations. Dover Publications Inc., Mineola, NY, USA, 1984. Veronda, D. R.; Westmann, R. A. Mechanical characterization of skin-finite deformations. J. Biomech. 1970, 3, 111–124. Martins, P.; Natal Jorge, R. M.; Ferreira, A. J. M. A comparative study of several material models for prediction of hyperelastic properties: application to silicone-rubber and soft tissues, Strain 2006, 42, 135-147. Brown, S.B.; Kwon, H.K.; Anand, L. An internal variable constitutive model for hot working of metals. Int. J. Plasticity 1989, 5 (2), 95–130. Brown, S.B. An internal variable constitutive model for the hot working of metals. Ph.D. thesis. Massachusetts Institute of Technology, USA, 1987. Anand, L. Constitutive equations for hot-working of metals. Int. J. Plasticity, 1985, 1 (3), 213–231.

122

A. Andrade-Campos, P. Pilvin, J. Simões et al.

[19] Ponthot, J.P.; Kleidermann, J.P. A cascade optimization methodology for automatic parameter identification and shape/process optimization in metal forming simulation. Comput. Methods Appl. Mech. Engrg. 2006, 195 (41-43), 5472–5508. [20] Grédiac, M.; Vautrin, A. A new method for determination of bending rigidities of thin anisotropic plates, J. Appl. Mech. 1990, 57, 964–968. [21] Chaboche, J.L. ; Nouailhas, D. ; Savalle, S. Agice: Logiciel pour l’identification interactive graphique des lois de comportement, La Recherche Aérospatiale, 1991, 3 59–76. [22] Schnur, D.; Zabaras, N. An inverse method for determining elastic material properties and a material interface, Int. J. Numer. Methods Engng 1992, 33, 2039–2057. [23] Cailletaud, G.; Pilvin, P. Identification and inverse problems related to material behaviour, in: H.D. Bui, M. Tanaka (Eds.), Inverse Problems in Engineering Mechanics, Balkema, Rotterdam, 1994, 79–86. [24] Mahnken, R.; Stein, E. The parameter identification for visco-plastic models via finite element method and gradient-methods, Modelling Simul. Mater. Sci. Eng. 1994, 2, 597– 616. [25] Mahnken, R.; Stein, E. A unified approach for parameter identification of inelastic material models in the frame of the finite element method, Comput. Methods Appl. Mech. Engrg. 1996, 136, 225–258. [26] Gélin, J.-C.; Ghouati, O. An inverse method for determining viscoplastic properties of aluminium alloys, J. Mater. Process. Technol. 1994, 45 (1–4), 435–440. [27] Gélin, J.-C.; Ghouati, O. An inverse solution procedure for material parameters identification in large plastic deformation, Commun. Numer. Methods Engrg. 1996, 12 (3), 161–173. [28] Abaqus, Finite element Analysis, Simulia, version 6.7, 2007, www.simulia.com/products/abaqus_fea.html. [29] MD Nastran, MSC software, version 2.1 R2 www.mscsoftware.com/products/nastran.cfm, 2007. [30] Cao, J.; Lin, J. A study on formulation of objective functions for determining material models, Int. J. Mech. Sci. 2008, 50, 193-204. [31] Gavrus, A.; Massoni, E.; Chenot, J.L., An inverse finite element analysis applied to viscoplastic parameter identification, In 2nd ECCOMAS Conf. on Numer. Meth. Engng., Paris, John Wiley and Sons, 1996. [32] Castro, L.; Timmis, J., Artificial Immune Systems: A New Computational Approach. Springer-Verlag New York, Inc. 2002. [33] Coello Coello, C. A., Theorectical and numerical constraint-handling techniques used with evolutionary algorithms: a survey of the state of the art. Comput. Methods Appl. Mech. Engrg. 2002, 191 (11-12), 1245-1287. [34] Lefik, M.; Schrefler, B.A. Artificial neural network for parameter identifications for an elasto-plastic model of superconducting cable under cyclic loading. Comput. Struct. 2002, 80 (22), 1699-1713. [35] Furokawa T.; Yagawa, G. Inelastic constitutive parameter identification using an evolutionary algorithm with continuous individuals, Int. J. Numer. Meth. Engng 1997, 40, 1071-1090. [36] Levenberg, K., A Method for the Solution of Certain Non-Linear Problems in LeastSquares, Quart. Appl. Math. 1944, 2, 164-168.

Software Development for Inverse Determination of Constitutive Model Parameters

123

[37] Marquardt, D.W. An algorithm for least-squares estimation of non-linear parameters, J. Soc. Indust. Appl. Math. 1963, 11, 431-441. [38] Polak, E. Optimization – Algorithms and Consistent Approximations, Springer-Verlag, New-York Inc., 1997. [39] Zhao, K.M.; Lee, J.K. Inverse estimation of material properties for sheet metals, Commum. Numer. Meth. Engng, 2004, 20, 105-118. [40] De Jong, K. An analysis of the behaviour of a class of genetic adaptive systems, PhD thesis, University of Michigan, 1975. [41] Andrade-Campos, A. Numerical Analysis and Modelling of the Mechanical and Thermal Behaviour of Aluminium Alloys, PhD Thesis, University of Aveiro, Portugal, 2005. [42] Teixeira-Dias, F.; Menezes, L.F. Numerical aspects of finite element simulations of residual stresses in metal matrix composites, Int. J. Numer. Meth. Engng 2001, 50, 629644.

In: Software Engineering and Development Editor: Enrique A. Belini, pp. 125-150

ISBN: 978-1-60692-146-3 © 2009 Nova Science Publishers, Inc.

Short Communication E

DESIGN OF MOLECULAR VISUALIZATION EDUCATIONAL SOFTWARE ∗ FOR CHEMISTRY LEARNING L.D. Antonoglou, N.D. Charistos and M.P. Sigalas Department of Chemistry, Aristotle University of Thessaloniki, Greece

Abstract An important goal for chemical education is students’ acquisition of key concepts and principles regarding molecular structure. Chemists have developed a rich symbolic language that helps them create and manipulate mental and external representations that describe spatial relations of aperceptual particles in order to investigate and communicate chemical concepts. High school and college students pose significant difficulties in understanding these concepts, mastering the symbolic language and making connections and transformations between symbolic, microscopic and macroscopic representations of chemical phenomena. Over the past decade the development of molecular visualization tools has changed the nature of chemistry research and created promising prospects for their integration in chemistry education which could help students overcome these difficulties. In this chapter we examine the case of molecular visualization in chemistry education and describe a number of educational packages that utilize new molecular visualization tools we developed to support learning of chemistry concepts in secondary and tertiary education.

Introduction Over the past decade the development of molecular visualization software has changed the nature of chemistry research and created promising prospects for their integration in chemistry education. Research has shown that students’ learning of molecular concepts is enhanced by the use of professional molecular modeling packages [Ealy, 1999, 2004; ∗ A version of this chapter was also published in Leading-Edge Educational Technology, edited by Thomas B. Scott and James I. Livingston published by Nova Science Publishers, Inc. It was submitted for appropriate modifications in an effort to encourage wider dissemination of research.

126

L.D. Antonoglou, N.D. Charistos and M.P. Sigalas

Casanova, 1993]. However, these technologies were developed for research purposes and usually involve complex interfaces presupposing specialized skills in order to produce meaningful visualizations. Moreover they do not invoke pedagogically designed learning tasks. Thus, although fluency with molecular visualization tools is becoming a literacy requirement for chemists, research and professional tools are likely to be inappropriate for beginners to use in educational context. The design and development of effective educational chemistry software requires a specialized approach taking into consideration principles and research findings from multiple disciplines such as chemistry and chemistry learning, technology and software development, cognitive science and pedagogy. The need for a multidisciplinary collaboration between educators, educational researchers, designers, cognitive scientists, and science practitioners in chemistry education has been recognized by others [Jones et al., 2005; Gilbert et al., 2004; Bailey & Garratt, 2002, Stieff et al.,2005; Kozma, 2003]. However developing collaborations between scientists from different disciplines in order to accomplish a common task can be proven a complex and time consuming effort as barriers between different epistemological viewpoints, research practices and scientific terminologies have to be overwhelmed. Our research in chemistry educational technology emerged from the field of quantum and computational chemistry. The usage of molecular modeling software in our scientific research and our engagement in teaching theoretical chemical concepts has driven our practices to the development of molecular visualization tools. Applying our technology for educational purposes has driven our research interests to chemistry learning and cognitive science. Hence, instead of struggling to establish multidisciplinary collaborations, we expand our research through a creative process focusing on the development of molecular visualization educational tools embodying principles from multiple disciplines. The production of new tools and their integration in social contexts creates new knowledge that is subsequently used as resource for further research and development [Liu, 2000; Gurteen, 1998]. Throughout this creative procedure principles from multiple disciplines being evaluated and evolved shape the discipline of chemistry educational technology in our organization. This chapter is divided into two sections. On the first section we present a literature review on the topic of chemistry learning focusing on the educational technologies that enhance understanding of chemical concepts. We initially examine cognitive and constructivist approaches on learning with educational chemistry software. Then we go on to examine essential topics on chemistry learning, such as the nature of chemical representations, expert and novice differences, students difficulties, the role of visuospatial thinking in chemistry, the case of molecular visualization in chemistry learning and finally we conclude to design principles for educational chemistry software. On the second section we describe cases of molecular visualization educational tools which we have developed in our department in order to support learning of chemistry concepts in secondary and tertiary education. The tools are described on the basis of how they implement design principles derived from the first section.

Learning Theory Learning theory can play a crucial role in guiding research and curriculum development related to the design and application of chemistry educational software. We can distinguish

Design of Molecular Visualization Educational Software for Chemistry Learning

127

two major types of learning theories: i) cognitive theory which is focused on information processing of multimedia messages that takes place in learners mind and b) constructivist theory focusing on the interaction of learners with learning tools in a social educational context. These theories are complementary and can provide principles for the design of educational software and its implementation in instruction and learning practices.

Cognitive Theory of Multimedia Learning Mayer [1999, 2001, 2002, 2003] presents a cognitive theory of learning with multimedia messages and proposes design principles for the development of effective instructional media for the acquisition of scientific concepts. A multimedia message is defined as material presented both in pictorial and verbal form. Mayer’s theory is based on three assumptions from cognitive psychology about how the human mind works: dual channel, limited capacity, and active processing. The dual channel assumption states that the human cognitive system consists of two distinct channels for representing and manipulating knowledge: a visualpictorial channel and an auditory-verbal channel [Mayer, 2002; Baddeley, 1999; Paivio, 1986]. The limited capacity assumption states that each channel in the human cognitive system has a limited capacity for holding and manipulating knowledge and each channel can be overloaded when lot of information is presented at one time [Mayer, 2002; Baddeley, 1999; Sweller, 1998]. Active learning assumption states that meaningful learning occurs upon learners’ engagement in active processing within the channels, including selecting relevant words and pictures, organizing them into coherent pictorial and verbal models, and integrating them with each other and appropriate prior knowledge [Mayer, 1999, 2001, 2002]. Based on this framework Mayer proposes eight design principles for the development of effective multimedia instructional messages that conform to these assumptions and foster understanding of difficult concepts: • • • • • • • •

Multimedia Principle. Deeper learning occurs when both words and pictures are used than from the use of words alone. Contiguity Principle. Deeper learning results from presenting words and pictures simultaneously rather than successively. Coherence Principle. Deeper learning occurs when extraneous words, sounds, or pictures are excluded rather than included. Modality Principle. Deeper learning occurs when words are presented as narration rather than as on-screen text. Redundancy Principle. Deeper learning occurs when words are presented as narration only rather than as both narration and on-screen text. Interactivity Principle. Deeper learning occurs when learners are allowed to control the presentation rate than when they are not. Signaling Principle. Deeper learning occurs when key steps in the narration are signaled rather than non-signaled. Personalization Principle. Deeper learning occurs when words are presented in conversational style rather than in formal style.

128

L.D. Antonoglou, N.D. Charistos and M.P. Sigalas

Mayer’s multimedia theory of learning propose an educational setting in which learning occurs with student’s engagement with an instructional message, probably during a lecture, and is focused on the acquisition of difficult concepts. This theory has drawn the attention of educational chemistry researchers [Kozma and Russell, 2005a, 2005b; Ealy, 2004; Robinson, 2004]. Kozma and Russell [2005a] suggest that the multimedia, contiguity, and modality principles encourage the simultaneous use of visualizations along with oral instruction to provide a synergistic learning effect by supporting the active processing of both visual and audio inputs in working memory. The dual processing of information in verbal and pictorial form enhances a person’s ability to connect multiple concepts that are represented in molecular visualizations, which contributes to a more thorough understanding [Ealy, 2004]. Therefore molecular visualization educational software could be used as presentation tools and visual aids in traditional lectures exploiting visual and verbal channels of human cognitive system in order to support student’s understanding of difficult molecular concepts.

Constructivist Approach to Learning Using molecular visualization tools as simple presentation tools to support acquisition of concepts during instruction do not fully exploit the learning opportunities that these tools offer. Constructivist theories of learning posit that knowledge is a human construction and that each student comes to understand scientific concepts based on their individual experiences and their own interpretation of information [Phillips, 1995; Stieff et al., 2005]. Students are considered to be active learners constructing their own understanding and not passive acceptors of knowledge transmitted by the expert instructor, as postulated by information processing theories. Therefore visualization tools should be designed and used as open-ended learning environments, where the learner could actively explore scientific concepts and discover or deduce desired principles for themselves [Perkins, 1991]. Within this approach modern constructivist pedagogy support guided inquiry settings in which the student plays the role of a researcher using visualization tools to pose research questions, make predictions, state the goals of their investigations, collect, analyze and present his/her findings to other students [Edelson, 2001]. Kozma and his colleagues [Kozma and Russell, 2005a, 2005b; Kozma, 2003; Kozma et al. 2000] discuss a situative approach to chemistry learning with visualization tools taking into consideration social and cultural factors. The situative theory focuses on participation in processes that construct knowledge. Within this approach students are considered to be members of knowledge-building communities working on the shared task of constructing knowledge, rather than individual learners memorizing established facts [Kozma et al. 2000; Scardimalia & Bereiter, 1994; Roth & McGinn, 1998]. The situative approach characterizes understanding and learning in terms of people’s participation in practices of inquiry and discourse that include interactions with others and with the material, symbolic and technological resources in their environment [Kozma, 2003]. Visualization tools are nowadays a common practice in almost any aspect of chemical research. Thus fluency with molecular visualization tools is becoming a literacy requirement for chemists. Since chemical phenomena are discussed on the basis of aperceptual particles, visualization tools provide representations with perceivable features that allow the consideration and discussion of objects and processes being otherwise not available for direct

Design of Molecular Visualization Educational Software for Chemistry Learning

129

inspection. From a social-constructivist perspective visualization tools can be considered as cultural tools that mediate between the physical substances that chemists study and the aperceptual chemical entities and processes that underlie and account for the material qualities of these physical substances [Kozma et al. 2000]. Roth and McGinn [1998] support that the usage of symbolic representations, and in our case molecular visualizations, should have a central role in the practice of knowledge-building communities of students, as they support learners' understanding of representations as well as of the scientific concepts and phenomena that these representations stand for. From the situative perspective, the classrooms supporting investigative practices encourage students to participate in activities in which visualizations are used in the formulation and evaluation of conjectures, examples, applications, hypotheses, evidence, conclusions, and arguments [Kozma and Russell, 2005a]. Aligned with the social-constructivist approach Jones et. al. [2001] argue that since molecular visualization is intrinsic to research in chemistry, learning to work with visualizations can be integrated with active, problem-based or inquiry-oriented learning activities that mirror the research experience. Thus, effective molecular visualization educational software should be designed as open-ended learning environments and used as tools that support active and discovery learning, enabling the students to participate in the activities of the community of chemists.

Chemistry Learning Chemistry is considered to be a central science [Atkins, 1987] linking “hard” science such as physics and mathematics, with “soft” science, such as biology and medicine [Brown & LeMay, 1977]. Thus chemistry holds a crucial conceptual position in science education as a whole [Jones et al., 2001]. Erduran and Scerri [Erduran & Scerri, 2002, Erduran, 2001; Scerri & McIntyre, 1997] present a strong case about the idiosyncratic nature of chemical knowledge from the perspective of philosophy of chemistry. They support that, although chemical systems constitute a special class of physical systems, chemical knowledge can not be reduced to physics and mathematization, due to the very nature of chemical concepts, laws and explanations, which tend to be qualitative and classificatory. Nobel prize winning chemist Roald Hoffmann is aligned with this position, stating that reductionism is only one face of understanding and claiming a greater role in science for the forward, constructivist mode [Hoffmann & Torrence, 1993]. Chemistry is also considered to be the most visual of sciences [Harbaken, 1996]. Chemists have developed a rich symbolic language that helps them create and manipulate mental and external representations that describe spatial relations of aperceptual particles in order to investigate and communicate chemical concepts. Thus, chemistry has evolved from a science dominated by physics and mathematics into a science highly dependent on the spatialvisual intelligence [Harbaken, 1996]. The discernible position of chemistry among sciences and the particular features of chemical knowledge require a specialized approach when conducting research in chemistry educational technology. However the majority of research in science education and philosophy of science has traditionally addressed questions on the subject of what is considered to be the paradigm science, that is physics [Erduran & Scerri, 2002 ; Kozma &

130

L.D. Antonoglou, N.D. Charistos and M.P. Sigalas

Russell, 1997]. In the following section we review recent literature on chemistry learning focusing on the role of molecular visualization technologies in chemistry learning.

Levels of Chemical Representations When chemists refer to chemical phenomena they use three levels of representations: macroscopic, microscopic and symbolic [Johnstone, 1982, 1993; Treagust et al., 2003]. The macroscopic level refers to chemical phenomena that are directly available to human perception. They include experiences and phenomena from laboratory experiments and everyday life, such as, changes of color of a solution, dissolution of salts, melting of solids, formation of sediment etc. These phenomena are chemically explained on the basis of the properties, shape, movement and interaction of microscopic particles such as molecules, atoms and electrons. These particles are real but unperceivable. Chemical theory constitutes of concepts and laws that portray the nature and properties of microscopic particles. Therefore the microscopic level of chemical representations refers to real but unperceivable particles and is approached conceptually within the chemical theory. In order to inspect and communicate chemical concepts of aperceptual particles chemists have developed a rich symbolic language that helps them create and manipulate mental and external representations. The symbolic level of chemical representations includes pictorial, algebraic, physical and computational forms such as chemical formulas, chemical equations, graphs, reaction mechanisms etc. While macroscopic observable phenomena and experiences provide an important knowledge base on which formal concepts and principles are built [diSessa, 1993], explanations of chemical phenomena typically rely on the symbolic and microscopic level of representations. Consequently, the ability of students to understand and distinguish the role of each level of chemical representation and the ability to transfer from one level to another is a crucial aspect of chemistry learning [Treagust et al., 2003]. Chemistry learning involves the establishment of conceptual relationships among macroscopic, microscopic, and symbolic representations [Wu, 2003]. Expert chemists conceive and explain chemical phenomena using all three levels of representations [Johnstone, 1993]. Contradictory, chemistry students show difficulties in comprehending the symbolic and microscopic levels of chemical representations, giving explanations using the three levels and making translations and transformations from one level to another [Wu, 2003; Ben-Zvi et al., 1986, Gabel et al., 1987].

Symbolic Chemical Representations Chemists use a plethora of symbolic representations in order to comprehend and communicate chemical concepts. The most widespread amongst them are representations of molecules such as molecular and structural formulas (Fig. 1) and computer generated molecular models (Fig. 2). Chemistry uses a unified theory to make quantitative spatial predictions, which allows highly generalized rules to link theoretical concepts to visual displays. Various types of structural formulas (Fig. 1) that show the connectivity and the spatial arrangements of atoms within a molecule by lines connecting the symbols of the

Design of Molecular Visualization Educational Software for Chemistry Learning

131

chemical elements are an example of a type of productive visualization, in which a set of diagrammatic rules produces qualitatively informative diagrams of an unlimited range of molecules. [Jones et al., 2001].

Figure 1. Various forms of 2D symbolic representations of ethane molecule.

Hoffman and Lazlo [1991] support that symbolic representations of molecular structures are part of the chemical language that chemist use to think about and communicate chemical phenomena. A single chemical formula is then analogous to a word. They support that symbolic representations are hybrids of two opponent entities: symbols as well as models. As symbols, they ought to be arbitrary enough to be applied throughout a wide range of different chemical representations. As models they ought to be reliable and accurate representations of microscopic reality which is conceptually approached by chemical theory. Thus, chemical representations can be considered as conceptual constructions that convey conceptual knowledge, as well as visual diagrams that require domain-general visuospatial skills to be comprehended [Wu & Shah, 2004]. Hoffman & Lazlo [1991] state that “in an important sense, chemistry is the skillful study of symbolic transformations applied to graphic objects”. From a situative perspective Kozma [Kozma et al. 2000] supports that symbolic representations allow chemists to have a common language for their joint inquiry, serving as tools to conduct science investigations and communicate with professional community members. The design of representational systems is a key cultural activity that affects the composition of a community, the other activities in which its members are engaged, and the understanding that community members have about its domain of knowledge. This understanding is both enabled and constrained by symbolic features of the representational system and the operations that can be performed using it [Kozma et al. 2000]. As Kozma [2000] state, “the use and understanding of a range of representations is not only a significant part of what chemists do - in a profound sense it is chemistry”. The nature of chemical symbolic representations is multifold since they can be considered as models, symbols and cultural tools. Therefore they play a central role in chemistry learning.

Expert and Novice Chemists A common practice in science learning research is the study of the differences between experts and novices in a specific domain. From a cognitive science perspective, experts within a domain are distinguished from novices primarily by the ways they organize their knowledge and use it to solve problems and understand the world around them [Gredler, 2001]. Experts organize their knowledge in large interconnected chunks of information based on the underlying principles of the domain. On the contrary, the knowledge of novices is dispersed into small unconnected fragments that correspond to experiences of human

132

L.D. Antonoglou, N.D. Charistos and M.P. Sigalas

perception. These primitive cognitive structures of novices constitute the knowledge base upon which the complexity and organization of expert-like knowledge is to be constructed [Chi et al., 1981; Smith et al., 1993]. While every day experiences correspond to physical phenomena and can act as starting points for the comprehension of concepts and laws in physics, the same does not hold true for chemistry. Chemical phenomena are explained on the basis of the properties of the imperceptible microscopic world. The only perceivable features of microscopic world are those that are embedded in the symbolic chemical representations. Therefore understanding of chemistry is based and constructed upon the surface, perceivable features of symbolic representations [Kozma & Russel, 1997]. Kozma and Russel [1997] studied the differences between expert and novice chemists in regard with the usage of multiple chemical representations. They found that novices rely on the surface features of symbolic representations to understand the chemical phenomena represented. But these surface features enable as well a barrier for their understanding. Novices could not connect or translate between different representations to achieve a deeper understanding based on the underlying chemical concepts. On the contrary, experts can perceive that representations with different surface features represent the same principle, concept, or chemical situation. They can transform the representation of a chemical concept or situation from one form to another. Kozma and Russel [1997; 2005a; 2005b] introduce the term “representational competence” to describe the set of skills and practices that allow expert chemists to reflectively use a variety of representations or visualizations to think about, communicate, and act on chemical phenomena in terms of underlying, aperceptual physical entities and processes.

Difficulties in Learning with Chemical Representations In a recent literature review Wu and Shah [2004] summarized the difficulties of students’ learning with symbolic chemical representations. They state that chemistry students have difficulties to: a) represent chemical concepts at the microscopic or symbolic levels, b) comprehend symbolic and molecular representations conceptually, c) visualize the interactive and dynamic nature of chemical process by viewing symbols and equations, d) make translations between chemical formula, electron configuration, and ball-and-stick models, e) identify the depth cues of 2D models and f) form 3D mental images by inspecting 2D structures. According to Keig and Rubba [1993] the lack of conceptual knowledge inhibits students to interpret the information provided by the symbolic representations and to infer the details in order to construct the new representations. Kozma and Russel [1997] support that the advanced representational skills of experts are due to their ability to create verbal expressions of the symbolic representations which demand conceptual understanding of the symbolic conventions. Apart from the lack of conceptual knowledge, another factor that constrains the ability of learners to demonstrate representational competence involves the mental transformation between two-dimensional and three-dimensional representations. Many students are not able to visualize and mentally manipulate 3-D mental images by viewing 2-D symbolic chemical structures [Copolo & Hounshell, 1995; Tuckey et al., 1991]. To do so they must decode the

Design of Molecular Visualization Educational Software for Chemistry Learning

133

symbolic conventions and the depth cues of the representations and mentally track how depth cues change as a result of rotation. This is found to be difficult task which involves extensive use of visuospatial thinking [Tuckey et al., 1991; Shubbar, 1990; Seddon & Eniaiyeju, 1986].

Visuospatial Thinking in Chemistry Chemistry is a highly visual science. According to Habraken [1996] chemistry has evolved from a science dominated by mathematics into a science highly dependent on visuospatial intelligence. Over the past decades with the development of visualization technologies, thinking in chemistry has shifted from the logical-mathematical thinking to the logical-visuospatial thinking [Habraken et al., 2001]. This is a clear demonstration of the simultaneous evolution of a science and its scientific language. Thus, visuospatial thinking has become the dominant way of thinking in chemistry [Habraken, 2004]. The spatial ability issues that are discussed in chemistry learning literature [Barnea & Dori, 1999; Wu & Shah, 2004] are: a) Spatial visualization, which is the ability to understand accurately three dimensional objects from their two dimensional representation; b) Spatial orientation, which is the ability to imagine how a representation will appear from a different perspective; c) Spatial relations, which is the ability to visualize the effects of operations such as rotation, reflection and inversion, or to mentally manipulate objects; and d) Closure flexibility, which is the ability to apprehend and identify a visual pattern in the presence of distracting stimuli. Visualizing and manipulating three dimensional mental models of molecular structures while observing two dimensional symbolic representations is a common process in chemistry thinking in research as well as in education. A lot of research has been conducted on the role of visuospatial thinking in chemistry learning [Barnea & Dori, 1999; Wu & Shah, 2004; Stieff, 2007; Stieff et al, 2005; Coleman & Gotch, 1998, Tuckey & Selvaratnam, 1993]. These studies reveal the existence of a positive correlation between spatial ability and students’ performance on both spatial and non spatial chemistry problems. Thus visualization technologies that support spatial abilities of chemistry students are essential to help students to appreciate the overall size, shape and structure of molecules and to develop visualization strategies on specific chemistry tasks.

Figure 2. Molecular visualizations of ethane: a) ball and stick, b) wireframe, c) space-filling.

134

L.D. Antonoglou, N.D. Charistos and M.P. Sigalas

Molecular Visualization in Chemistry Learning Molecular visualizations are a special class of symbolic molecular representations that utilize interactive computer generated three-dimensional graphics to depict the spatial relations and connectivity of atoms within molecules as well as various molecular properties. They use the four depth cues (i.e., the foreshortening of lines, the relative sizes of different parts of the structure, the perspective representations of angles, and the extent to which different parts of the structure overlap), 3D cues (i.e., shadow, lighting, texture and free manipulation) and a number of symbolic conventions (i.e., color-coding of the elements, representing chemical bonds as thin material rods) to represent molecular structures and properties in various formats such as ball and stick, wireframe and space-filling (Fig. 2). Over the past decade many researchers have developed molecular visualization educational software [Wu et al, 2001; Schank & Kozma 2002; Barnea & Dori, 1996; Charistos et al, 2005, 2004, 2003; Sigalas et al, 2003; Cass et al., 2005] or used scientific molecular visualization software for educational purposes [Ealy, 1999, 2004; Casanova, 1993]. Research has shown that students’ understanding of chemical concepts is enhanced through the integration of molecular visualization tools in educational activities [Ealy, 2004; Dori & Barak, 2001]. Jones et al. [2001] support that molecular visualizations are a complex hybrid of concrete spatial depiction and abstract visual encoding. They represent physical objects and therefore depict spatial relationships in the world. On the other hand, they employ numerous symbolic graphical conventions to highlight and locate in space theoretically important aspects of molecules. These images are used to convey complex, subtle molecular interactions and dynamics that are difficult to describe in words or 2D symbolic representations [Jones et al., 2005]. The typical learning situation utilizing visualizations involves a process of learning both new concepts and how those concepts are visually represented by images that are intended to facilitate learning the concepts. Fluency with the visual conventions employed in a particular type of visualization develops with time, ultimately leading to the expert’s fluent perception of the conceptual relationships that are encoded in the displays [Jones et al., 2001]. Wu [Wu et al., 2001] discuss a cognitive approach to learning with molecular visualization based on Paivio’s dual coding theory [Paivio, 1986] and the statement that molecular visualizations are conceptual constructs as well as symbolic visual displays. They support that students in order to demonstrate representational skills, one or more of the following cognitive connections should be activated: a) representational connections between conceptual information of external and mental representations, b) representational connections between visual information of external and mental representations, and c) referential connections between learners visual and conceptual cognitive systems. However, several difficulties that students face in understanding and using molecular visualizations can be addressed from a cognitive perspective [Jones et al. 2001, 2005] that is:

Design of Molecular Visualization Educational Software for Chemistry Learning

135

a) Visual subtlety: spatial relationships in molecular visualizations can be difficult to interpret b) Complexity: interpreting a molecular structure may be a complex process when the amount and depth of information encoded in the representation is large and when different representations must be used and compared c) Abstractness and conceptual depth: for novice learners the relationship between a visualization and the underlying concepts is much more difficult to understand than it is for experts. Students must already have some knowledge about the concept and how this concept is represented by the visualization.

Design Principles of Chemistry Educational Software Chemistry learning requires the mastering of a plethora of symbolic representations. Extensive practice with various types of chemical representation is needed by the learners in order to develop representational competence. Classical instructional media such as textbooks can not provide sufficient representations to describe the three-dimensional and dynamic nature of the microscopic world. Molecular visualization software provides the potential for practice with three-dimensional molecular properties, and the reification of dynamic molecular properties that otherwise can not be visualized. Several researchers have proposed design characteristics that visualization software should have in order to support student understanding of chemistry [Kozma & Russell, 1997; Wu & Shah, 2004; Stieff et al., 2005]. Kozma and Russell [1997] support that developers of visualization software could use the representational and computational capabilities of computers to design symbol systems and symbolic environments that are not otherwise available in the classroom. These symbol systems could be designed such that their surface features make explicit certain aspects of chemistry that otherwise are not directly perceivable. Wu and Shah [2004] based on students’ difficulties and alternative conceptions in chemistry, propose several principles that help students understand chemical concepts and develop representational skills through supporting their visuospatial thinking. Specifically they propose that educational chemistry visualization tools should: a) Provide multiple representations and descriptions in order to enable students to make connections between the representations and the concepts that are represented and provide students with opportunities to actively choose a representation suitable for different stages of understanding. b) Make linked referential connections visible, so that students could construct appropriate conceptual connections among multiple representations. c) Present the dynamic and interactive nature of microscopic chemical phenomena and concepts, in order to support visuospatial thinking. d) Promote the transformation between 2D and 3D representations of molecular structures and e) Reduce cognitive load by making information explicit and integrating information for students.

136

L.D. Antonoglou, N.D. Charistos and M.P. Sigalas

Case Study: Molecular Visualization Educational Software In this section we describe a number of educational chemistry tools that we have developed. These tools utilize molecular visualization technology to describe dynamic and static concepts and properties of molecular structure that are essential for chemistry learning in secondary and tertiary education. Namely the molecular visualization tools that we have developed and the corresponding chemistry concepts or properties that they deal with are: a) 3DMolSym, for the concept of symmetry elements and symmetry operations of molecules; b) 3DNormalModes, for molecular normal modes of vibration; c) Enantiomerix3D, for the concept of stereochemistry, chirality and enantiomerism; and d) Polymerix3D, for structural properties of polymers. The first two are intended for use in tertiary education and the others for secondary education. The first three visualize the dynamic nature of the corresponding concepts, properties or processes, while the others visualize static properties and concepts of molecular structures.

Main Features These tools are simplified and learner-centered molecular visualization applications that provide visualization performances on the level of professional tools. They have been developed with the Macromedia Director MX Shockwave Studio authoring tool [Adobe, 2007], incorporating Intel’s 3D Graphics software of adaptive 3D geometry including a set of dynamic algorithms that simplifies the tedious task of creating interactive 3D content. They can be easily delivered as web applications utilizing Shockwave plug-in or as stand alone executable applications that can be run directly from CD or hard disk with no installation procedure. Each tool contains a database of molecular structures that covers all characteristic cases in each domain. The user can visualize a particular molecular model in an interactive threedimensional environment in various formats (e.g. ball and stick, wireframe, space-filling) and freely manipulate the model (e.g. rotate, translate, zoom) in order to appreciate the overall size, shape and structure of the molecule. In addition, each tool provides a number of specialized functions that enable the user to perform certain tasks in order to achieve a deeper understanding of the represented chemical concepts. Some of them (e.g. 3DMolSym and Enantiomerix3D) provide novel activities and visualizations of dynamic chemical concepts that can not be represented by “classical” media and to our knowledge have never been visualized elsewhere.

Design Characteristics The tools conform to the design principles discussed in the precedent section. In particular: a) They provide multiple representations of molecules. Each molecule is represented simultaneously by its chemical name, molecular formula, structural formula and 3D model. The multiple representations allow students with different learning styles to choose their preferred symbol systems and encourage them to make connections between verbal and visual representations; b) They promote transformation between 2D and 3D by

Design of Molecular Visualization Educational Software for Chemistry Learning

137

simultaneously presenting symbolic structural formulas and three-dimensional molecular models. Also, letting the user to freely rotate the model in order to compare it with the two dimensional representation gives him/her the opportunity to decode the depth cues and other graphic conventions that are embedded in the symbolic representation; c) Three of them (e.g. 3DMolSym, 3DNormalModes, Enantiomerix3D) present dynamic visualizations and animations of the corresponding chemical concepts, providing unique representations with dynamic surface features that support visuospatial thinking; d) Reduce cognitive load by making information explicit and integrating it for students. Using 3D visualization techniques these tools provide functions to highlight certain fragments of molecules that have significant conceptual value and guide the user to concentrate on these certain structural aspects while observing the whole molecular structure.

Application in Education The tools provide high quality molecular visualizations with surface features that make explicit certain properties of molecular structures that otherwise are not directly perceivable and can not be represented with other media. Therefore they can be used as presentation tools to promote deeper understanding during instruction, as they provide novel visualizations that can complement the verbal representations of the tutor to exploit the dual processing capabilities of learners’ cognitive system. In addition tutors can ask students questions about the theoretical significance of the representations and respond intelligently to their answers which often reveal alternative or incomplete conceptions. The tutor can then guide the students to use what they know to think more deeply about the issue, or to consider another case. By actively using their concepts in this kind of tutorial setting, students rebuild and extend their conceptual knowledge [Jones et al., 2001]. The tools have been designed as open-ended learning environments providing a sufficient number of characteristic cases and examples of molecules and novel activities with certain molecular concepts. Therefore they can be used in a constructivist mode. They can be used in conjunction with classical textbooks as self-pace tools, where the learners can actively explore the represented molecular concepts, be engaged in extensive practice with these concepts and have experiences that help them create their own knowledge. In addition working with user-friendly and learner-centered molecular visualization tools, students are introduced into the practices of chemistry researchers. In the following sections we describe the specific functions of each tool.

3DMolSym 3DMolSym [Charistos et al, 2005] is an educational program designed to visualize the symmetry elements of molecules and to animate the corresponding symmetry operations in an interactive 3D environment. It is designed to help students visualize dynamic models of the symmetry properties of molecular structure.

138

L.D. Antonoglou, N.D. Charistos and M.P. Sigalas

Chemical Concept: Molecular Symmetry Chemists classify molecular structures in terms of their symmetry. A firm understanding of the basic concept of symmetry is extremely useful in studying molecular and electronic structure, stereochemistry, spectroscopy and reaction mechanisms. Molecular symmetry is discussed in terms of the concepts of symmetry elements and symmetry operations. A symmetry operation is an action that, if carried out on an object (in this case a molecule) leaves it in a configuration that is indistinguishable from the original configuration. A symmetry element is an abstract geometrical entity (line, plane or point) which respect to which one or more symmetry operations can be carried out. The symmetry of a molecule is described by the whole set of symmetry operations that can be applied to it and hence by the whole set of symmetry elements that it possesses. Molecules are then classified to point groups on the basis of type and number of the symmetry elements they possess. There are five symmetry operations and corresponding symmetry elements: E: the identity operation does not do anything to the molecule. The symmetry element is the molecule itself. Cn: an n-fold rotation, the molecule is rotated by an angle 2π/n around a symmetry axis. If a molecule has many rotational axes, the axis with the largest n is called the principal axis. σ: reflection, the molecule is reflected in respect to a plane. Planes including the principal axis are termed vertical planes, σv, or diagonal axes, σd, and planes perpendicular to the principal axis are called horizontal planes, σh. i: inversion, all atoms are projected through the center of symmetry. Sn: an n-fold improper rotation, a composite operation of an n-fold rotation followed by a reflection in a plane perpendicular to this axis. Molecular symmetry is grounded upon group theory, which is a set of mathematical relationships that allow someone to study symmetry of objects and shapes. Chemists usually concern less about the mathematical formalism and more on visualizing how symmetry operations transform molecules in three dimensional space. From a cognitive perspective, the recognition of symmetry elements of molecules is a very difficult task depending on the visuospatial abilities of the learners [Tuckey et al., 1991; Tuckey & Selvaratnam, 1993]. In order to identify each symmetry element of a molecule from the observation of a 2D symbolic representation of the molecular structure, the learner has to perform the following cognitive tasks: a) Form a 3D mental image of the molecular structure, b) Imagine a possible symmetry element of the molecular structure, c) Perform the corresponding symmetry operation to the 3D image mentally, and d) Check if the final 3D image is identical to the initial 3D image. Students have difficulties to perform these tasks and especially to visualize the positions of atoms in space after rotations and reflections [Tuckey et al., 1991]. The most difficult task to visualize is the improper rotation, where the student has to rotate the molecule until it takes a configuration in which a subsequent reflection to a plane perpendicular to the axis of rotation will lead to the initial configuration. These tasks challenge students to create dynamic mental models of the corresponding molecular concepts. Traditional instructional media and 2D symbolic representations do not provide adequate surface features to help students visualize the dynamic nature of these

Design of Molecular Visualization Educational Software for Chemistry Learning

139

concepts. Textbooks can provide only a limited number of examples. Moreover, many cases can not be depicted by 2D symbolic representations and classical media do not give the opportunity to the student to practice and actively explore these dynamic concepts.

Figure 3. The graphic interface of 3DmolSym.

Functionality 3DMolSym is an educational program suitable for undergraduate students in chemistry, designed to visualize the symmetry elements of molecules and to animate the corresponding symmetry operations in an interactive 3D environment (Fig. 3). 3DMolSym operates as a searchable database containing structural and symmetry data of 50 organic and inorganic molecules, spread to all symmetry point groups of chemical interest and covering all characteristic cases. It consists of two modules: the Symmetry Elements mode and the Point Groups mode. In the Symmetry Elements mode the user can search the database to find all molecules having symmetry elements of a certain type (e.g. Cn) or a particular symmetry element (e.g. C3). In the Point Groups mode the user can search the database to find all molecules belonging to a point group of a certain type (e.g. Dnd) or to a particular point group (e.g. D2d). The essential tasks that the user can perform are: •

• • •

Select and display a molecule in simultaneous multiple representations such as, 3D molecular models in ball and stick, wireframe or space-filling format, 2D structural formula, molecular formula and name. Freely manipulate (rotate, translate or zoom) the molecule to any viewpoint. Display any combination or class of the symmetry elements of a selected molecule. Select a particular symmetry element and actively perform and view animation of the application of the associated symmetry operation on the selected molecule.

140

L.D. Antonoglou, N.D. Charistos and M.P. Sigalas

During the animation of a symmetry operation the molecule’s initial geometry is displayed as a semitransparent “ghost” structure allowing the comparison of the orientation of the molecular structure before, during and after the application of the symmetry operation. Throughout the animation the user can still manipulate the molecule to reach the most convenient point from which to view the symmetry operation. The user can adjust the speed, pause and restart the animation at any time. In addition the user can manually perform the symmetry operation on her/his own pace by dragging a slider. After its completion the symmetry maps the molecules onto its “ghost” structure that is itself. 3DMolSym provides unique opportunities to the user to experience extensive practice with a wide range of molecules and their symmetry elements and operations. The animations of the symmetry operation provide dynamic surface features that support visuospatial thinking and help the learner create dynamic mental representations of the corresponding concepts which can then transfer to other molecules. The user can actively perform the animations of the operations and have direct experience with the represented concepts to achieve a deeper understanding.

3DNormalModes 3DNormalModes [Charistos et al, 2003, 2004; Sigalas et al, 2003] is an educational program, suitable for undergraduate students in chemistry that provides a convenient way to illustrate in a interactive 3D environment how a molecule vibrates according to each of its normal modes of vibration, as well as the properties of its normal mode. It is designed to help students visualize dynamic models of molecular vibrational movement.

Figure 4. The graphic interface of 3DNormalModes

Design of Molecular Visualization Educational Software for Chemistry Learning

141

Chemical Concept: Normal Modes of Vibration When a beam of electromagnetic radiation is passed through a substance, it can either be absorbed or transmitted, depending upon its frequency, ν, and the structure of the molecule it encounters. Electromagnetic radiation is energy and hence, when a molecule absorbs radiation gains energy, as it undergoes a quantum transition from an energy state (Einitial) to another (Efinal). A minimum energy conformation of a molecule will not be still, even at absolute zero of temperature, but will wobble around. These movements can be separated into a series of simple motions, called the normal modes. Each of the vibrational motions of a molecule occurs with a certain frequency, which is characteristic of the molecule and of the particular vibration. The energy involved in a particular vibration is characterized by the amplitude of the vibration, so that the higher the vibrational energy, the larger the amplitude of the motion. According to the results of quantum mechanics, only certain vibrational energies are allowed to the molecule, and thus only certain amplitudes are allowed. Associated with each of the normal modes of the molecule, there is a series of energy levels (or vibrational energy states). The molecule may be made to go from one energy level to a higher one by absorption of a quantum of electromagnetic radiation, such that Einitial − Efinal = hν. In undergoing such a transition, the molecule gains vibrational energy, and this is manifested in an increase in the amplitude of the vibration. The frequency of radiation required to cause a transition for a particular vibration is equal to the frequency of that vibration, so that we may measure the vibrational frequencies by measuring the frequencies of radiation which are absorbed by the molecule. Since most vibrational motions in molecules occur at frequencies of about 1014 s−1, then light of wavelength λ = c/ν = 3 × 1010 cm s-1 / 1014 s−1 = 3 × 10−4 cm = 3 μm will be required to cause transitions. As it happens, light of this wavelength lies in the so-called infrared (IR) region of the spectrum. IR spectroscopy, then, deals with transitions between vibrational energy levels in molecules, and therefore is also called vibrational spectroscopy. Raman spectroscopy, although differs in technique, give complementary information to IR spectroscopy. Analysis of the normal modes of a molecule allows us to see which motions have low energy, and which are less accessible. Thus, one of the ongoing challenges in the teaching of vibrational spectroscopy (IR and Raman) is getting students to recognize the relationship between specific spectral transitions and normal modes of the molecule under investigation.

Functionality The 2D symbolic representation of vibrational movement of molecules with more than five atoms is very difficult and is rarely encountered in instructional textbooks. 3DNormalModes provides dynamic visualizations of vibrational molecular movement and linked multiple representations of the underlying concepts. With 3DNormalModes the user can animate a normal mode of a wide range of molecules in an interactive 3D environment. It contains a database with information concerning the structure, the experimental fundamental frequencies and the corresponding normal modes of 30 inorganic and organic molecules. 3DNormalModes enables the user to choose a molecule, orient it appropriately on the screen,

142

L.D. Antonoglou, N.D. Charistos and M.P. Sigalas

choose any of its normal modes of vibration, and visualize the molecule vibrating in 3D according to the normal mode selected (Fig. 4). When a molecule is selected a list of its normal modes is displayed in the normal mode selection panel sorted by frequency or type. Furthermore, the simplified IR and Raman spectra of the molecule are displayed, showing the spectral lines at the frequencies of the IR or Raman active normal modes. The user can select the normal mode of vibration either by clicking the normal mode from the list or by clicking the corresponding spectral line. When a normal mode is selected, information concerning its type, symmetry, frequency and IR and Raman activity are displayed in the information panel and the molecule starts to vibrate according to the selected normal mode. A set of buttons offers a full control over the animation of a normal mode. Thus the user can adjust the rate of the animation, pause and restart the animation. The user can also show or hide atom displacement vectors of the selected normal mode which are represented as a pair of a green and a red vectors showing the directions in which the atoms move forward and backward during the vibration. Finally the user can adjust the length of the displacements of the atoms.

Figure 5. The graphic interface of Enantiomerix3D.

Enantiomerix3D Enantiomerix3D is a molecular visualization educational program suitable for secondary education that is designed to help students understand the concept of stereochemistry. This concept concerns the connectivity and three-dimensional spatial arrangement of atoms within an individual molecule. Even relatively small molecules can have multiple spatial

Design of Molecular Visualization Educational Software for Chemistry Learning

143

arrangements that can result in different stereoisomers, which are unique molecules that are composed of the same atoms with identical bond arrangements. Understanding the structure and relationship between stereoisomers is crucial to the basic and advanced study of chemistry. In common stereochemistry tasks students are required to recognize whether two molecules with same atoms and connectivity in different rotational arrangement are identical or mirror images of each other. When the two molecular configurations are mirror images then they are called enantiomers. This task is isomorphic to canonical psychometric approach of detecting the use of mental rotation for examining three-dimensional objects [Shepard & Metzler, 1971]. The task of identifying whether two molecules are stereoisomers or not can be solved either with an algorithmic procedure, or using visuospatial thinking to perform mental rotations in order to compare the two molecules. Very recently Stieff [2007] found that students choose to employ mental rotation for solving organic chemistry stereochemistry tasks that involve asymmetrical molecular diagrams, while they prefer to employ analytical strategy to solve stereochemistry tasks with symmetrical molecules. These findings underscore the role of visuospatial thinking in understanding stereochemistry concepts.

Chemical Concept: Stereochemistry, Chirality and Enantiomerism A molecule which cannot be superimposed on its mirror image is chiral. The two mirror images of such a molecule are called enantiomers. Crystals or solutions of the two enantiomers rotate the linear polarization of light in different directions, whereas a mixture of equal amounts of the two enantiomers is a racemic mixture and has no optical activity. The existence of chirarity or optical activity of a molecule is determined by its symmetry. Thus, for a molecule not to be chiral should have an axis of improper rotation. A chiral molecule is not necessarily asymmetric having no symmetry elements, as it can have, for example, rotational symmetry. For tetrahedrally-bonded carbon, if all four substituents are different, the molecule is chiral. This particular carbon atoms is called stereocenter or stereogenic center. According to the R / S nomenclature system a chiral center is denoted R or S according to a system by which its substituents are each assigned a priority, based on atomic number and the Cahn Ingold Prelog priority rules. If the center is oriented so that the lowest-priority of the four is pointed away from a viewer, the viewer will then see two possibilities: if the priority of the remaining three substitutents decreases in clockwise direction, it is labeled R (for Rectus), if it decreases in counterclockwise direction, it is S (for Sinistrus).

Functionality Enantiomerix3D includes a database of organic molecular structures that are chiral or achiral (not chiral). When the user selects a molecule its molecular model is displaced in the left 3D screen and its mirror image in the adjacent right 3D screen (Fig. 5). As the user perform free rotations (changes the orientation) of the given configuration of a molecule its mirror image concurrently changes orientation as if it was reflected in a mirror. Thus the user can freely rotate the pair of mirror images in order to investigate whether a specific orientation exists where the two mirror images are superimposed to its other or not. The user

144

L.D. Antonoglou, N.D. Charistos and M.P. Sigalas

can also disable the mirroring relationship of the two screens any time to orient one configuration to a preferable orientation and try to bring the other configurtaion to the same orientation and compare the two images.

Figure 6. The graphic interface of Enantiomerix3D with substituents highlighted.

To be precise identical configuration of chiral molecular structures can never happen. Actually in the concept of stereochemistry we seek for identical positions only for the four substituents adjacent to a central carbon atom being a possible stereogenic center. Thus a function has been implemented in Enantiomerix3D which enables the user to highlight with separate colors the atoms of the substituents directly bonded to this carbon atom and fades all the other atoms that provide irrelevant and distracting information. By this way cognitive load produced by additional visual information is reduced and the user is focused on the explicit information that is needed to solve the task. Also, in this mode a legend with the correspondence of the highlighting colors with the priority of the substituents helps students to label the given structure and its mirror image as R or S (Fig. 6). Enantiomerix3D provides unique dynamic visualization of the concept of stereochemistry and novel activities that can not be achieved with other media. We believe that these dynamic surface features support visuospatial thinking of learners and the active engagement and practice with mirror imaging molecular models promote deeper understanding of the concept of chirality.

Polymerix3D Polymerix3D is a molecular visualization educational program suitable for secondary education that is designed to help students understand molecular and structural properties and concepts of polymers such as the relation of monomer molecules with macromolecular structures and macroscopic properties. It provides multiple linked representations of the

Design of Molecular Visualization Educational Software for Chemistry Learning

145

relevant concepts such as 3D molecular models, 2D structural formulas, macroscopic images and verbal descriptions. Polymerix3D includes a database with various information about several polymers. The user is prompted to select a polymer by its name and view multiple representations of it, namely 3D molecular model, structural formula, name, verbal description of its properties and a macroscopic image of an everyday object that is produced with this polymer. The user can also open a window with verbal description and 2D symbolic representation of the reaction of the polymer’s synthesis and a window with 3D model and 2D structural formula of the monomer molecule from which the polymer is synthesized. It is of great importance for the student to understand how a macromolecular structure of a polymer results from a repeating pattern of building blocks of atoms and how these building blocks result from monomer molecules. When the user selects a polymer its macromolecular structure is initially displayed in an idealized linear configuration. The user can easily understand that this macromolecular structure consists of a repetitive pattern of atoms. However it is still difficult to interpret the visual information provided by a large number of atoms and bonds in order to identify the specific set of atoms that define the building block. So a function has been implemented that enables the user by pressing a button to fade redundant visual information and highlights one building block of atoms. Thus the user can concentrate on the highlighted atoms and simultaneously compare them with the whole macromolecular structure.

Figure 7. The graphic interface of Polymerix3D.

However linear configuration of macromolecular structures of polymers is far from original structures and can create the misconception that all polymers share a common structural conformation. Thus a function has implemented in Polymerix3D that enables the user to visualize a more complicated conformation, calculated on the basis of the unique electronic properties of each structure, which approximates to a more convenient way the “molecular reality” of the polymer.

146

L.D. Antonoglou, N.D. Charistos and M.P. Sigalas

The visualization capabilities of Polymerix3D can be extended by the use of two additional windows. The user can open a window with verbal description and 2D symbolic representation of the synthesis reaction of the polymer. The user can also open a window which displays the monomer molecule as well as the corresponding building block in the form of 3D molecular models and 2D structural formulas. Polymerix3D provides linked multiple representations of molecular concepts concerning the topic of polymers and is designed as an open-ended discovery learning environment. With the use of functions that enable the user to omit redundant visual information reduces cognitive load and guides the attention to special structural characteristics of molecules with significant conceptual meaning. It enables the user to choose preferred representations that suit her/his learning style and make conceptual connections between different representations in order to achieve a deeper understanding of the represented concepts.

Conclusions In this chapter we presented a literature review on the topic of chemistry learning with educational software and described a number of molecular visualization educational tools that we developed to support learning of chemistry concepts in secondary and tertiary education. Chemistry is a science that interprets macroscopic phenomena using explanations, concepts and laws that arise from the properties of the unperceivable microscopic world. Chemists have developed a rich symbolic language that helps them create and manipulate mental and external representations that describe spatial relations of aperceptual particles in order to investigate and communicate chemical concepts. Chemistry students are required to master these symbolic representations in order to develop conceptual understanding of chemical phenomena. Visuospatial ability of learners is a key factor for mastering chemical representations. New visualization technologies enable the development of novel symbolic representations with dynamic surface features that represent chemical concept and processes in a way that can not be represented with traditional media. Chemistry educational software should comfort to research findings and guidelines from learning theories and chemistry learning. Cognitive and constructivist approaches to learning propose directions for the design and implementation of educational chemistry software. Focused research on chemistry learning proposes specific characteristics of effective educational chemistry software. The tools we developed provide high quality molecular visualizations and are designed as open-ended learning environments. They can be used as presentation tools during instruction, as proposed by cognitive approach to learning, or as discovery learning environments for personalized knowledge construction, as proposed by constructivist approach. Each tool incorporates a number of specific functions that enable conceptual connections between multiple representations, visualize the dynamic nature of relevant concepts to support visuospatial thinking and enable the user to have extensive, individualized and active practice with the represented concepts. Therefore we believe that these tools will enhance deeper understanding of the chemical concepts that they visualize.

Design of Molecular Visualization Educational Software for Chemistry Learning

147

References [1] [2] [3] [4] [5]

[6]

[7]

[8] [9] [10] [11]

[12]

[13]

[14]

[15] [16] [17]

[18]

Adobe (2007). Macromedia Director MX 2004. http://www.adobe.com/products/ director/ Atkins, P. W. 1987. Molecules. New York: Scientific American Library. Baddeley, A. D. (1999). Human Memory. Needham Heights, Mass.: Allyn & Bacon. Bailey P. D., & Garratt J. (2002). Chemical education: theory and practice. University Chemistry Education, 6, 39-57. Barnea, N., & Dori, J. Y. (1996). Computerized molecular modelling as a tool to improve chemistry teaching. Journal of Chemical Information and Computer Science, 36, 629-636. Barnea, N., & Dori, J. Y. (1999). High-School Chemistry Students’ Performance and Gender Differences in a Computerized Molecular Modeling Learning Environment. Journal of Science Education and Technology, 8(4), 257-271. Barnea, N., & Dori, Y. J. (2000). Computerized molecular modeling - The new technology for enhancing model perception among Chemistry educators and learners. Chemistry Education: Research and Practice in Europe 1, 109–120. Ben-Zvi, R., Eylon, B., Silberstein, J. (1986). Is an atom of copper malleable?. Journal of Chemical Education, 63, 64-66. Brown, T. L., & LeMay, Jr., H. E. (1977). Chemistry, the Central Science. New Jersey: Prentice-Hall. Casanova, J. (1993). Computer-based molecular modeling in the curriculum. Journal of Chemical Education, 70, 904–909. Cass, M. E.; Rzepa, H. S.; Rzepa, D. R.; Williams, C. K. (2005). An Animated Interactive Overview of Molecular Symmetry. Journal of Chemical Education, 82, 1742. Charistos, N. D., Tsipis, C. A., & Sigalas, M. P. (2005). 3D Molecular Symmetry Shockwave: A Web Application for Interactive Visualization and Three-Dimensional Perception of Molecular Symmetry. Journal of Chemical Education, 82, 1741. Charistos, N. D., Tsipis, C. A., & Sigalas, M. P. (2004). 3D Normal Modes Shockwave: Τhree-dimensional perception of molecular normal modes on the Web. Journal of Chemical Education, 81, 1231. Charistos, N. D., Teberekidis, V.I., Tsipis, C.A., & Sigalas, M.P. (2003). Design and Development of a Multimedia Educational Tool for Interactive Visualization and Three Dimensional Perception of Vibrational Spectra Data of Molecules. Education and Information Technologies, 8, 369-379. Chi, M., Feltovich, P., Glaser, R. (1981). Categorization and representation of physics problems by experts and novices. Cognitive Science, 5, 121–152. Coleman, L. S., Gotch, J. A. (1998). Spatial perception skills of chemistry students. Journal of Chemical Education, 75, 206-209. Copolo, C.F., & Hounshell, P.B. (1995). Using three-dimensional models to teach molecular structures in high school chemistry. Journal of Science Education and Technology, 4(4), 295 - 305. diSessa, A. (1993). Toward an epistemology of physics. Cognition and Instruction, 10,105–225.

148

L.D. Antonoglou, N.D. Charistos and M.P. Sigalas

[19] Dori, Y. J., & Barak, M. (2001). Virtual and Physical Molecular Modelling: Fostering Model Perception and Spatial Understanding. Educational Technology & Society, 4, 6174. [20] Ealy, J. B. (1999). A student evaluation of molecular modeling in first year college chemistry. Journal of Science Education and Technology, 8, 309-321. [21] Ealy, J. B. (2004). Students’ understanding is enhanced through molecular modeling. Journal of Science Education and Technology, 13, 461-471. [22] Edelson, D. C. (2001). Learning-for-use: A framework for integrating content and process learning in the design of inquiry activities. The Journal of Research in Science Teaching, 38, 355-385. [23] Erduran, S. (2001). Philosophy of Chemistry: An Emerging Field with Implications for Chemistry Education. Science & Education, 10, 581–593. [24] Erduran, S., Scerri, E. (2002). The Nature of Chemical Knowledge and Chemical Education. In J. K. Gilbert et al. (Ed.), Chemical Education: Towards Research-based Practice (pp. 7-27). The Netherlands: Kluwer Academic Publishers. [25] Gabel, D. L., Samuel, K. V., Hunn, D. (1987). Understanding the particulate nature of matter. Journal of Chemical Education, 64, 695-697. [26] Gilbert J. K., Justi R., Van Driel J.H., De Jong, O., & Treagust, D.F. (2004). Securing a future for chemical education. Chemistry Education: Research and Practice, 5, 5-14. [27] Gredler E. M., (2001). Learning and Instruction: Theory into Practice. New Jersey: Merirll/Prentice Hall. [28] Greeno, J. (1998). The situativity of knowing, learning, and research. American Psychologist. 53, 5-26. [29] Gurteen, D. (1998). Knowledge, Creativity and Innovation. Journal of Knowledge Management, 2, 5-13 [30] Habraken, C. L. (1996).Why is the Common Perception of Chemistry, the Most Visual of Sciences, so Distorted?. Journal of Science Education and Technology, 5, 193–200. [31] Habraken, C. L. (2004). Integrating into Chemistry Teaching Today’s Student’s Visuospatial Talents and Skills, and the Teaching of Today’s Chemistry’s Graphical Language. Journal of Science Education and Technology, 13, 89-94. [32] Habraken, C. L., Buijs,W., Borkent, H., Ligeon,W.,Werner, H., Meijer, M. (2001). School chemistry vs. chemistry in research: An exploratory experiment. Journal of Science Education and Technology, 10, 249–256. [33] Hoffmann, R., Laszlo, R. (1991). Representation in chemistry. Angewandte Chemie, 30, 1 - 16. [34] Hoffmann, R., Torrence, V. (1993). Chemistry Imagined: Reflections on Science. Washington DC: Smithsonian Institute Press. [35] Johnstone, A. H. (1982). Macro- and micro-chemistry. School Science Review, 64, 377– 379. [36] Johnstone, A. H. (1993). The development of chemistry teaching. Journal of Chemical Education, 70, 701–705. [37] Jones L., Jordan K & Stillings N. (2001). Molecular visualization in science education, Available at http://pro3.chem.pitt.edu/workshop/workshop_report_180701.pdf [38] Jones, L. L., Jordan, K. D., & Stillings, N. A. (2005). Molecular visualization in chemistry education: the role of multidisciplinary collaboration. Chemistry Education: Research and Practice in Europe, 6, 136–149.

Design of Molecular Visualization Educational Software for Chemistry Learning

149

[39] Jones, M. B. (2001). Molecular modeling in the undergraduate chemistry curriculum. Journal of Chemical Education, 78, 867-868. [40] Keig, P.F., Rubba, P.A. (1993). Translation of representations of the structure of matter and its relationship to reasoning, gender, spatial reasoning, and specific prior knowledge. Journal of Research in Science Teaching, 30(8), 883 – 903. [41] Kozma R., Russell, J. (1997). Multimedia and Understanding: Expert and Novice Responses to Different Representations of Chemical Phenomena. Journal of Research in Science Teaching, 34, 949–968. [42] Kozma, R. (2000). The use of multiple representations and the social construction of understandingin chemistry. In M. Jacobson & R. Kozma (Ed.), Innovations in science and mathematics education: Advance designs for technologies of learning (pp. 11–46). Mahwah, NJ: Erlbaum. [43] Kozma, R. (2003). The material features of multiple representations and their cognitive and social affordances for science understanding. Learning and Instruction, 13, 205– 226. [44] Kozma, R., & Russel, J. (2005a). Students becoming chemists: developing representational competence. In J. K. Gilbert (Ed.), Visualization in Science Education (pp. 121-145). The Netherlands: Springer. [45] Kozma, R., & Russel, J. (2005b). Multimedia Learning of Chemistry. In R. E. Mayer (Ed.), Cambridge Handbook of Multimedia Learning (pp. 409-428). New York: Cambridge University Press. [46] Kozma, R., Chin, E., Russell, J., & Marx, N. (2000). The roles of representations and tools in the chemistry laboratory and their implications for chemistry learning. Journal of the Learning Sciences, 9, 105–143. [47] Liu, Y.T. (2000). Creativity or novelty?, Design Studies, 21, 261–276 [48] Martin, N. H. (1998). Integration of computational chemistry into the chemistry curriculum. Journal of Chemical Education, 75, 241–243. [49] Mayer, R. E. (1999). The Promise of Educational Psychology. Upper Saddle River, N.J.: Prentice Hall. [50] Mayer, R. E. (2001). Multimedia learning. New York: Cambridge University Press. [51] Mayer, R. E. (2002). Cognitive theory and the design of multimedia instruction: An example of the two-way street between cognition and instruction. New Directions for Teaching and Learning, 89, 55-71. [52] Mayer, R. E. (2003). The promise of multimedia learning: using the same instructional design methods across different media. Learning and Instruction. 13, 125–139 [53] Paivio, A., (1986). Mental Representations: A Dual Coding Approach. New York: Oxford University Press. [54] Perkins, D. (1991). Technology meets constructivism: Do they make a marriage? Educational Technology, 31, 18-23. [55] Phillips, D. C. (1995). The good, the bad, and the ugly: The many faces of constructivism. Educational Researcher. 24, 5 – 12 [56] Robinson, W. (2004). Cognitive theory and the design of multimedia instruction. Journal of Chemical Education, 81, 10-13. [57] Roth, W. M., McGinn, M. (1998). Inscriptions: Toward a theory of representing as social practice. Review of Educational Research, 68, 35–59

150

L.D. Antonoglou, N.D. Charistos and M.P. Sigalas

[58] Scardimalia, M., Bereiter, C. (1994). Computer support for knowledge-building communities. Journal of the Learning Sciences, 3, 265–283. [59] Scerri, E.R., & McIntyre, L. (1997). The Case for the philosophy of chemistry. Synthese, 111, 213-232. [60] Schank, P., Kozma, R. (2002). Learning chemistry through the use of a representation based knowledge building environment. Journal of Computers in Mathematics and Science Teaching, 21, 253-279 [61] Seddon, G.M., & Eniaiyeju, P.A. (1986). The understanding of pictorial depth cues, and the ability to visualize the rotation of three-dimensional structures in diagrams. Research in Science and Technological Education, 4, 29 - 37. [62] Shepard, R. N., & Metzler, J. (1971). Mental rotation of three-dimensional objects. Science, 171, 701-703. [63] Shubbar, K.E. (1990). Learning the visualization of rotations in diagrams of three dimensional structures. Research in Science and Technological Education, 8, 145–154. [64] Sigalas, M.P., Charistos, N. D., Teberekidis, V.I. & Tsipis, C.A., (2003). 3DNomaModes. Journal of Chemical Education, 80, 1222. [65] Smith, J., diSessa, A., Roschelle, J. (1993). Misconceptions reconceived: A constructivist analysis of knowledge in transition. Journal of the Learning Sciences, 3, 115–163. [66] Stieff, M. (2007). Mental rotation and diagrammatic reasoning in science. Learning and Instruction, 17, 219-234. [67] Stieff, M., Wilensky, U. (2003). Connected Chemistry: Incorporating Interactive Simulations into the Chemistry Classroom. Journal of Science Education and Technology, 12, 285-302. [68] Stieff, Μ., Bateman, C. R., & Uttal, H. D. (2005). Teaching and learning with threedimensional representations. In J. K. Gilbert (Ed.), Visualization in Science Education (pp. 93-118). The Netherlands: Springer. [69] Sweller J., van Merrienboer J., Paas F. (1998). Cognitive architecture and instructional design. Educational Psychology Review, 10, 251–296. [70] Treagust, D.F., Chittleborough, G., Mamiala, T.L. (2003). The role of submicroscopic and symbolic representations in chemical explanations. International Journal of Science Education, 25, 1353-1368. [71] Tuckey, H. P., and Selvaratnam,M. (1993). Studies involving three-dimensional visualization skills in chemistry: a review. Studies in Science Education, 21, 99–121. [72] Tuckey, H., Selvaratnam, M., Bradley, J. (1991). Identification and rectification of student difficulties concerning three-dimensional structures, rotation, and reflection. Journal of Chemical Education, 68, 460-464. [73] Wu, H. K. (2003). Linking the microscopic view of chemistry to real life experiences: Intertextuality in a high-school science classroom. Science Education, 87, 868-891. [74] Wu, H.-K., Krajcik, J. S., Soloway, E. (2001). Promoting understanding of chemical representations: Students’ use of a visualization tool in the classroom. Journal of Research in Science Teaching, 38, 821–842. [75] Wu, H.-K., Shah, P. (2004). Exploring visuospatial thinking in chemistry learning. Science Education, 88, 465-492.

In: Software Engineering and Development Editor: Enrique A. Belini, pp. 151-173

ISBN: 978-1-60692-146-3 © 2009 Nova Science Publishers, Inc.

Short Communication F

SOFTWARE COMPONENTS FOR LARGE SCALE SUPER ∗ AND GRID COMPUTING APPLICATIONS Muthu Ramachandran+ Innovation North: The Faculty of Information and Technology Leeds Metropolitan University, UK

Abstract Software development for large and complex systems remains a costly affair. The complexity for supercomputing applications that require high speed and high precision systems grows exponentially. This chapter provides an approach to design and development of supercomputing applications based on software components which have potential to minimize the cost and time for complex and high dependability systems. Software components are aimed to provide a self-contained entity that can be adapted to the required environment quickly and easily. However this definition need to extended for large scale supercomputing paradigm. This will be a quite considerable paradigm shift for Component Based Software Engineering (CBSE) paradigm that exists today. The main criteria for supercomputing and grid applications include flexibility, reusability, scalability, highly concurrent, parallel & multi-threaded, security, distributed and data-intensive systems. This chapter defines a new paradigm for CBSE for supercomputing applications. Therefore design for large scale software components is the major emphasis of this chapter.

Keywords: software components, software reuse, large scale, scalability, supercomputing

Introduction Software development for large and complex systems remains a costly affair. The complexity for supercomputing applications that require high speed and high precision ∗ A version of this chapter was also published in Supercomputing Research Advances, edited by Yongge Huang published by Nova Science Publishers, Inc. It was submitted for appropriate modificatons in an effort to encourage wider dissemination of research. + E-mail address: [email protected];

152

Muthu Ramachandran

systems grows exponentially. This chapter provides an approach to design and development of supercomputing applications based on software components which have potential to minimize the cost and time for complex and high dependability systems. Software components are aimed to provide a self-contained entity that can be adapted to the required environment quickly and easily. However this definition need to extended for large scale supercomputing paradigm. This will be a quite considerable paradigm shift for Component Based Software Engineering (CBSE) paradigm that exists today. The main criteria for supercomputing applications include flexibility, reusability, scalability, highly concurrent, parallel & multi-threaded, distributed and data-intensive systems. This chapter defines a new paradigm for CBSE for supercomputing applications. Therefore design for large scale software components is the major emphasis of this chapter. Supercomputers (thousands of processors work in parallel to achieve complex highprecision tasks) and grids comprise an infrastructure enabling scientists to use a diverse set of distributed software, services, and components across a variety of dispersed resources to solve a scientific problem. The complexity for supercomputing applications that require high speed and high precision systems grows exponentially. The scientific centres world-wide having to re-write their existing system software to scale to the multi-teraflop systems that are being installed in their centres. Example of a supercomputer consists typically from 1000 processors to more than 4000 processors recently. The first full scale BlueGene/L machine offers a single system with 64, 000 nodes and 128, 000 processors (Bodes et all 2005). Computational method for solving problems has become very important in many scientific and engineering researches where theoretical and experimental evaluations have their limitations or where it can serve as an intermediary between theoretical concepts and experimental findings. The term ‘Supercomputer’ can be defined as a computer that has a very large memory and a processor that performs very fast. The first supercomputer was introduced by Seymour Cray in the early 70’s. The aim of building supercomputers is capability rather than capacity. The performance of any supercomputer is measured based on LINPACK benchmark. The memory hierarchy of a supercomputer is designed in such a way that the processor is fed with data and instructions all the time. Prediction of complicated weather pattern is the most commonly known application of supercomputers. The other areas that use supercomputers for their research include earth sciences (global warming), atomic and molecular physics (checking the nuclear weapon detonation), chemistry, chemical engineering, food science and drug research (investigating the crystallisation behaviour at molecular-scale), nanoscale science, plasma physics, genetic engineering, biomolecular sciences, molecular medicine, fluid dynamics, telecommunications, cosmology, particle physics, etc. Workstation is a desktop supercomputer. Parallel computer is a type of supercomputer in which a single (numerical) task is distributed among various processors simultaneously and thus reducing the time required to solve the problem and efficiency or speed of the supercomputer. BEOWULF is a high performance parallel computer on PC hardware. Main usage is in scientific computing. This uses operating systems like Unix, Linux, and Solaris. There are many applications of supercomputers. However, one of the disadvantages of running a supercomputer is the enormous heat generated by a supercomputer due to its large size, and this reduces the lifetime of the parts. Supercomputers are designed to perform

Software Components for Large Scale Super and Grid Computing Application

153

various tasks (like numerical) in parallel whereas a quantum computer is a computer that uses the quantum mechanical phenomena for solving scientific problems.

Applications Applications of supercomputing and grids are enormous in recent years. Some of them are weather forecasting, simulation of aircraft and military applications, atmospheric and planet study, remote sensing, large scale data analysis, aerospace research, large scale computational fluid dynamics applications, aeronautics, and automobile industries. The characteristics of supercomputing applications: • • • • • • •

High speed and highly parallel Real-time Nodes of systems Grid is an infrastructure for supercomputing and other resources High precision Hyderomechanics Hyroelectrics

Software components design for supercomputing and grids have become a major issues in recent years and in years to come [Bode at al (2005), Trip at al (2005), Naik et al (1993), Laszewski at al (2002), Laprie (2004), Miller and Katz (1991), Silvestri et al (2006), Armstrong et al (1999), and Schulze et al (2006)]. They have all claiming the importance of software components which will dominate supercomputing and grid applications. Silvestri et al (2006) say that the future supercomputing and grid applications will be completely built in a bottom-up fashion using software components deployed on various locations and interconnected to form a workflow graph and to re-configure themselves as and when needed during run=time to self manage those applications that may in need. This chapter also defines software reuse for large scale applications and defines component design guidelines that are highly scalable. These guidelines are then classified to match those design criteria. Software components for supercomputing applications require a detailed analysis of the domain and its boundary in order to define a collection of components for supercomputing applications that are highly reusable and scalable. Therefore this chapter will also introduce a domain analysis process which allows us to define a set of common definitions, domain classification, domain boundaries, domain models, design artefacts, and design guidelines that are based on those domain criteria. This chapter will provide new insights into software components for supercomputing applications. The set of guidelines will help engineers to design and develop a highly scalable software components and architectures with minimum cost, effort and complexity. The approach described in this chapter will lead to new era in supercomputing applications development since it addresses those critical issues that are the key to high performance and scalability.

154

Muthu Ramachandran

Software Development Process Models for Supercomputing and Grid Applications A process is a coherent set of activities for specifying, designing, implementing and testing software systems. This also integrates people, process, procedures/methods and tools. The traditional software development process model is shown in Figure which starts with identifying requirements for a specific application or a product, followed by specification, design, testing, and maintenance. This model has been quite popular and successful in large scale systems such as Defence, Aerospace, Medical, and High integrity applications. However this model may not exactly be suitable for supercomputing and high dependability systems.

System & Software Requirements Engineering and Specification

System & Software Design and Architectures

Software Implementati on and Unit Testing

System & Software Integration Testing Operation & Maintenance

Figure 1. Waterfall model of software development process.

Waterfall model which is shown in Figure 1 remains a core base for many applications today and for the future and it provides a niche framework for procedures. The main principle behind the waterfall model is to firm up requirements before moving on to the phases that follow. The phases are systems and software requirements engineering where the aim is to identify both hardware and software needs from stakeholders and end users and to drive a detailed specification which often forms the basis for a legal contract between the clients and the suppliers. Secondly, to develop detailed design activities which include detailed architectural design and modeling and which conform to the requirements document. The third phase activities include software development and unit testing of each completed code. The fourth phases include activities such as integration and sub-system testing. Finally, the completed system goes on to more in-house alpha testing and at the customer site (beta testing activities) until the customer is satisfied and then the system maintenance contract can be signed-off. Lots of other development process models have emerged but mainly around the waterfall model. The following Figure 2 is a process model produced for supercomputing applications by Laszewski et al (2002).

Software Components for Large Scale Super and Grid Computing Application

155

Collaboration and Identify Problem Solving Strategy Identify High Level Components Identify Tasks, Grid resources Needed, select Components using these resources

Assemble components to solve the problem identified Assembled system is executed as a Grid Service The output is feedback to Scientists/Result Analysis

Figure 2. Component based deployment model for scientific applications.

According to this model the process starts with collaborating with colleagues/experts to identify a problem solving strategy. Secondly, to select the problem solving environment and then to identify a set of high level components that have been successfully used in providing solution to the problem, identify tasks to be solved and then to identify grid resources that are needed, a component has been created to solve the problem, the component is executed as a grid service using the grid resources, and the output is fed back to the scientists. In this chapter we propose a model at the requirements level certain subsets of activities that must be identified and assessed for a large scale supercomputing and grid applications where the main emphasis has been given to non-functional requirements that match onto the characteristics of such applications. This is illustrated in Figure 2 as Requirements Engineering Model for Supercomputing Applications (REMSA). Dependability requirements

Data integrity requirements Interoperability requirements Risk assessment requirements

Fault-tolerant requirements

Predictable resource requirements

Requirements Engineering for Large Scale Supercomputing Applications

Scalability requirements

Failure mode analysis requirements Concurrency, parallel processing requirements Scientific problem requirements definition

Figure 3. Requirements Engineering Model for Supercomputing Applications.

156

Muthu Ramachandran

As shown in this model REMSA consists of number activities mainly focusing requirements for dependability, fault-tolerance, resources, scalability, data integrity, interoperability. Dependability is a characteristic of a system which is able to deliver or complete its functioning without failure. Its service delivery is as expected by the user. Failure modes can be defined as the ways in which a system can fail and can be ranked according to failure severities. Laprie (2004) has proposed a clear model for dependability as shown in the following Figure. We can use this model to capture requirements for dependability. As we can see from the diagram dependability has attributes (availability, reliability, safety etc), means to achieve (fault prevention, tolerance, removal, forecasting), and threats (faults, errors, failures). Likewise we can split each characteristic of components for supercomputing application and their attributes, means, and threats which will provide a good design rationale for software component design. Availability, Maintainability Reliability, Integrity

Attributes

Safety, Confidentiality Faulty prevention Dependability systems

Means

Fault tolerance Fault removal and forecasting Faults

Threats

Errors Failures

Figure 4. Dependability Attributes.

The main aim of this research is to identify a set of characteristics and software component model that has been designed for dependability and supercomputing applications that are scalable and testable with minimum effort and cost. The following section explores some of the existing approaches to software development techniques and then identifies component based software development for supercomputing and grid computing applications.

Component Based Software Development Why do we need software components for supercomputing applications? Software reuse was identified as an attribute of software quality as well as a factor for productivity. Software component has been identified as a unit of abstraction which can be independently used to compose systems. Computer hardware systems are composed and assembled rather than being built where as software systems remains being crafted from scratch rather than being assembled. There have been a number of works on reuse and component based product

Software Components for Large Scale Super and Grid Computing Application

157

development and product-line approach to software development (D’Souza and Wills (1999), Szyperski (1998), Cheesman and Daniels (2000)). In general systems are composed of components (software and hardware inclusively). Therefore, component-based systems are comprised of multiple software components that: • • • • • •

are ready ‘off-the-shelf’, whether from a commercial source (COTS) or re-used from another system, have significant aggregate functionality and complexity, are self-contained and possibly execute independently, preferably used ‘as-is’ rather than modified, must be integrated with other components to achieve required system functionality, use component architectures to build resilient architectures

Examples of components based systems can be drawn from many domains, including computer-aided software engineering (CASE), engineering design and manufacturing (CAD/CAM), office automation, workflow management, command and control, and many others. Figure 5 illustrates a model for component-based software development (Brown 1996). As shown in this diagram the model consists of five stages Off-the-shelf components, Qualified components, Adapted components, Assembled components, and Updated components. Updated components Evolution to update components

Assembled components

Adapted components

Adaptation to remove architectural mismatch

Qualified components

Off-the-shelf components (COTS)

Composition into a selected architectural style

Qualification to discover interface

Figure 5. A model for component based development.

The development of embedded systems from components can be considered to be primarily as assembly and integration process. The CBSE process consists of a number of key steps that are briefly described follow:

158

Muthu Ramachandran •

•

• •

•

Off-the-shelf components have emerged to support product-line approach where identifying and developing reusable components, and interface design play a key role supporting reuse over the product-line. This is an essential first step for starting up a product-line approach. Qualified components have discovered interfaces so that possible sources of conflict and overlap have been identified. This is a partial discovery: only those interfaces important to effective component assembly and evolution are identified. How to qualify/certify a component as a potential candidate for reuse remains an active research topic. Adapted components have been amended to address potential sources of conflict when trying to match for a new set of requirements. Assembled components have been integrated into an architectural infrastructure. This infrastructure will support component assembly and co-ordination, and differentiates architectural assembly from ad hoc “glue”. Updated components have been replaced by newer versions, or by different components with similar behaviour and interfaces. Often this requires wrappers to be re-written, and for well-defined component interfaces to reduce the extensive testing needed to ensure operation of unchanged components is not adversely effected.

However, existing practices have not been able to solve some of the issues emerged when developing reusable components: • • • • •

how to identify and develop reusable components that can guarantee a return-oninvestment (ROI) what makes a component more reusable for embedded systems what kind of a business model for this new approach who will be responsible for making go/no-go decision how to we conduct evaluation, validation, verification, and testing (VVT) of components

Starting up a reuse programme is as hard as reusing them. This is known as Domain Engineering where reusable assets are identified and developed. The process involves finding commonalties among systems to identify components that can be applied to many systems, and to identify product families that are positioned to take fullest advantage of those components. The notion of how to reuse and maintain those components is known as Application Engineering. The third notion is automated generation of reusable frameworks and architectures from a higher level specification are known as Generation Engineering. Software Architecture plays a major role to structure systems so that they can be built from reusable components, evolved quickly, and analysed reliably.

Software Reuse Guidelines Why Reuse? When you look at the electronic engineering community you see many different products comprised of the same standard set of components most of which have

Software Components for Large Scale Super and Grid Computing Application

159

complete interoperability with each other, even between different manufacturers. An example of which would be speakers for a hi-fi system, when you buy a new set of speakers you know they will work with any hi-fi amp even if the amp happens to be five years old. This kind of reuse has come about because of agreed standards and strict guidelines between companies. Within the software engineering community, reuse is both an old and new idea. Programmers have reused ideas, abstractions and processes since the early days of code writing. Today the programming scene is very different with need for large, complex and high quality systems to be built in a very short time period. To achieve this, a more organized approach to reuse is needed. Companies will need more agreement of the standardisation of programming practices and code interoperability before reuse is as advanced as it is practiced in the electronics industry. What can be Reusable? The complexity and subsequently the cost of many projects are constantly rising. Reuse is one answer to keeping costs down while creating huge projects. When making a project its important to remember all of the following can be reused: • • • • • • • •

Code (Functional as well as application generators such as UNIX systems pipes and filters components) Design (OO and Patterns) Applications (Frameworks and Templates) Whole systems Documents (very important) Ideas Knowledge Experience

Issues There are many issues that need to be resolved as component based engineering becomes mainstream practice. These are just a few of the current issues that project managers are asking and with them are possible solutions.

Incentives Appropriate incentives can be established to encourage software engineers to reuse, rather then reinvent code. This can be done simply by offering a bonus to software engineers who reuse components. A more effective way would be to make it a software engineer’s objective to make and reuse components and to assess his performance throughout the year. It would then be possible to identify engineers who have done well and encourage others.

160

Muthu Ramachandran

Cost Cost is an important issue and whether companies are willing to incur the added expense associated with creating reusable software components will be an important test for the success of component based software engineering. To discover the net savings from the reuse of a component you can apply the following formula. E – (S + A) = N An example could be; 50,000 – (2,000 + 40,000) = 8,000 E = estimated cost of project if it were developed from scratch S = sum of the costs associated with reuse A = actual cost of the software as delivered N = net savings from using reuse The following are a list of costs involved in domain engineering. • • • • • • •

Domain analysis and modeling Domain architecture development Increased documentation to facilitate reuse Support and enhancement of reuse components Royalties and licences for externally acquired components Creation or acquisition and operation of a reuse repository Training of personnel in design and construction for reuse

Although these costs can be considerably high, many of the costs mentioned above should already be in practice for software engineering.

Large Scale Reuse Super and grid computing applications requires high level of granularity and reconfigurability and therefore large scale reuse can be achieved if we can develop components with those characteristics identified in the earlier section. The design strategies that can be used for achieving large scale reuse are: • • • • • •

Modularity and high granularity Building blocks (large size component can be used as-it-is) Generics Re-configurability Frameworks Architecture reuse

Software Components for Large Scale Super and Grid Computing Application

161

These are design criteria for large scale reuse and are in addition to managing system composition and interface design. Ramachandran and Fleischer (1996) proposed a model for a large scale software reuse which was used in large scale telecommunication systems. The large-scale granularity of reusable components includes subsystems, building blocks (a collection of object classes} and architectures. The main principles are configurability, conceptual integrity domain-specific architectures (for a product family), design for reuse, reuse guidelines and rules. They have reported to have achieved more than 70% reuse within a product family and more than 40% on a different product family.

Guideline on Component Identification Identifying software components from your application models is a human intensive activity. This comes from domain expertise. However, Pressman (2000) has identified a few self-assessment questions to identify components from your design abstracts as given below: • • • • • • • • • • • •

Is component functionality required on future implementations? How common is the component's function within the domain? Is there duplication of the component's function within the domain? Is the component hardware-dependent? Does the hardware remain unchanged between implementations? Can the hardware specifics be removed to another component? Is the design optimized enough for the next implementation? Can we parameterize a non-reusable component so that it becomes reusable? Is the component reusable in many implementations with only minor changes? Is reuse through modification feasible? Can a non-reusable component be decomposed to yield reusable components? How valid is component decomposition for reuse?

One rule of thumb can be use here is to identify a group of related object classes to make up a self-independent component. UML view of component identification process is depicted in the following diagram (Figure 6). UML process starts with identifying use cases, class modeling, dynamic modeling (state transition and message sequence models), collaboration models (grouping related classes), packaging, components, and deployment/ implementation models (processors and network architectures) where components and packages will be placed in the expected processors. In a later section we will discuss a commonality and variability analysis for component identification in the context of a product family. Implementation effort and ROI: This is an initial step in CBSE and it is therefore vital to identify a component which will have a longer life in your application domain and hence high returns on investment. Therefore it is absolutely essential to have a business view to each identified components with domain experts.

162

Muthu Ramachandran

Identify requirements and Requirements Analysis (Inception)

Identify use cases (Inception)

Identify object classes and Dynamic modelling (state charts and message sequence diagrams

Assign a business value for each identified component

Identify Collabora tions diagrams (grouping classes) and Packages

Compo nent diagram s

Deployment diagrams (Implementation model in terms of processors and networks

Figure 6. UML view of component identification.

Guideline on Component Definition A software component is a self-contained entity which can be executed independently as well as by combining with other parts. In addition, a component also has two distinct interfaces/services (sometime also called services in the context of a modern approach to web based applications and business applications) such as provider interfaces (a set of interfaces that are offered to other components to be connected) and require interfaces (a set of interfaces/services that are required by this component to work independently and to provide the needed services successfully). An example of a software component model in UML2.0 is shown in Figure 7. Requires int er face Defines the services from the component’s environment that it uses

Provides int erface

Component

Defines the services that are provided by the component to other components

Figure 7. UML 2.0 Component [Sommerville 2006].

Implementation Effort and ROI (Return on Investment): The component implementation consists of two parts a specification part and an implementation part. The specification part defines all interfaces and their parameters whereas the implementation part implements those interfaces. This can be implemented in JavaBeans, EJB and also in .NET environment. This may take more effort to implement in other languages. ROI will be higher as it has potential for a large scale reuse opportunities.

Software Components for Large Scale Super and Grid Computing Application

163

Guideline on Component Characteristics Identifying characteristics of a software component is vital for designers such that they can select, design, and evaluate those characteristics that are applicable to their applications. Some of those well known characteristics are: • • • • • • • •

•

Reusable Portable Independent Composable Extensible Testable Separation of concern Granularity (which not only relates to line of code (LOC) but also should consider the choice of development tools and programming language used for implementation, production/development time-scales, the cost for unit testing and integration testing required) Exhibit a three dimensional space (distributable, modular, language and platform independent).

Implementation Effort and ROI: Implementing all of these characteristics needs high level of expertise and training if necessary. However this investment on training staff on good component design is worth and has potential to payoff (ROI).

Guideline on Component Design Components need to be modelled before a detailed design takes place. Before hand it is useful to recap on basic component design principles: • • • • • • • • •

• • •

Low coupling Highly cohesive Pluggable Interface design Information hiding Abstraction Generics where possible Components Naming conventions should be established for components that are specified as part of the architectural model and then refined and elaborated as part of the componentlevel model Interfaces Interfaces provide important information about communication and collaboration (as well as helping us to achieve the OCP: Open-Closed-Principle) Dependencies and Inheritance

164

Muthu Ramachandran • •

It is a good idea to model dependencies from left to right and inheritance from bottom (derived classes) to top (base classes). Make interfaces easy to use correctly and hard to use incorrectly. Responsibility for interface usage errors belongs to the interface designer, not the interface user (Meyers 2004)

Furthermore, Pressman (2005) defines the following as good basic design principles: • • • • • • •

The Open-Closed Principle (OCP). “A module [component] should be open for extension but closed for modification. The Liskov Substitution Principle (LSP). “Subclasses should be substitutable for their base classes. Dependency Inversion Principle (DIP). “Depend on abstractions. Do not depend on concretions.” The Interface Segregation Principle (ISP). “Many client-specific interfaces are better than one general purpose interface. The Release Reuse Equivalency Principle (REP). “The granule of reuse is the granule of release.” The Common Closure Principle (CCP). “Classes that change together belong together.” The Common Reuse Principle (CRP). “Classes that aren’t reused together should not be grouped together.”

Implementation effort and RoI: Again this is similar to previous implementation effort which puts emphasis on training staff on good design and latest component development technology. This is not about just using a latest implementation technology but actually implementing good component design principles using that technology.

Component Model for Supercomputing and Grid Applications Components are pluggable units of abstraction. Component model provides a higher level of abstraction and decomposition early in the life cycle. It is challenging to identify suitable components from computing problem requirements if not deliver a set of components models that will meet those requirements by providing a suitable solution. To develop a component model for a specific application domain it is quite relevant and essential to identify a set of characteristics of the nature of that domain. This will lead to providing a better solution to the problem in had in two ways: a) it helps us to identify a set of non-functional requirements that can be used during the development and implementation and to identify constrains during implementation, and b) it helps us to design component models with those characteristics expressed and implemented explicitly. Therefore in this context a possible set of component characteristics for supercomputing and grid computing systems are as follow: • •

Interoperability Scalability

Software Components for Large Scale Super and Grid Computing Application • • • • • • • • •

165

Dependability Security fault-tolerant reliability high level of data integrity, re-configurability distributed predictability real-time

Based on these characteristics we have proposed a component model for supercomputing applications as shown in Figure 8. In our component model for supercomputing application, there are two types of interfaces as seen in any standard component models, they are requires interfaces which are shown as arrow-in (Node connection, data transfer, re-configuration manager which is capable of changing component functionally at run-time, and process start/stop), and provider interfaces are shown as arrow-out (protected functions, interrupt handlers, event manager, schedule timer, and node configuration). These interfaces can be changed without affecting the component core specification and its implementation. Node connection Data transfer Reconfiguration Manager Process restart

Component Model for Supercomputing Applications which provides two types of interfaces such as requires (a set of functions need from other components as its input parameters) and provides (a set of services/functions supplied/outputted to other components/systems/process es

Protected functions Interrupt Handlers Event Manger Schedule Timer Node configuration

Figure 8. Component Model for Supercomputing Applications

The component model shown above is not a fixed set of functions identified; this is for illustration purpose only. Experts can consult with software developers to identify exact set of these interfaces. Bode et al. (2005) has identified an architectural model and a set of possible reusable software components for supercomputing applications as part of the US DoE initiative project know as SciDAC (scientific discovery through advanced computing) The working group consists of DoE labs, NSF supercomputer centres and major vendors like IBM, Intel, Cray, NCSA, SGI, etc. Their overall aim of their project was to: •

identify and develop a set of scalable system software for their supercomputing infrastructures and operational system software

166

Muthu Ramachandran • • • • •

•

node build, configuration, and information services resource management, scheduling, and allocation process management, system monitoring, and checkpoints validation and integration development of an integrated suite of system software and tools for effective management and utilisation of tera-scale computational resources particularly those at the DoE facilities achieve three main issues: security, heterogeneity and scalability

Their project involves mainly identifying a set of scalable components for the purpose of managing at the infrastructure layer. Secondly, they built their supercomputing nodes and their services. Thirdly, they have identified components for resource management, scheduling and job allocation. However, their main issues were how to build components for security, heterogeneity, and scalability at run-time. There are some of the research challenges ahead in this area of building and customizing components for supercomputing applications.

Authentication Communication

Communication Infrastructure Components Library

Service Communication

Event Manager Meta Scheduler

Accounting

Usage Reports

Meta Monitor

Scheduler

Application Management

Validation & Testing

Job Queue Manager

System & Job Monitor

Process Manager

Meta Manager

Node Configuration & Build Manager

Node Start Manager

Hardware Infrastructure Manager

Checkpoint Restart

Figure 9. Software components for supercomputing applications.

The next future challenge is to prepare these systems software to be scalable for the next generation of peta-op class supercomputers that will face even greater challenges ahead. Figure 9 shows a classification of system software components that can be mapped onto those categories of system infrastructures as a set of a reusable component library for communication infrastructures so that they can be reused by various centres and their application needs (the library consists of three classes of components service directory, authentication communication, event manager), schedule management components (meta scheduler, accounting, scheduler, allocation manager, usage reports, job queue manager), node monitoring components (meta monitor, system job monitor, process manager,

Software Components for Large Scale Super and Grid Computing Application

167

checkpoint restart), and node configuration & build manager (node state manager, meta manager, hardware infrastructure manager) which map onto event manager of the component library. The process of managing and maintaining a component library that used across the country and world-wide can be a challenging task itself for which one can make use of the proposed model for a component based development earlier in this chapter. The important criteria for the design and implementation of these components have to follow the design guidelines identified in the earlier section. This will enable components to be scalable and reusable. XML should be used for component interface communications.

Testing and Evaluation The most commonly given definition of Software testing is the process of uncovering evidence of defects in software systems. However, testing is more than just finding defects, it has many purposes and plays many roles in the software development lifecycle and the following definitions all equally apply to software testing: 1. Testing is the process of exercising or simulating a system or program operation. 2. Testing is used in establishing confidence that a program does what it is supposed to, and doesn’t do what it isn’t supposed to, i.e. reliability estimation. 3. Testing is the process of analysing a program with the intent of finding problems and errors, i.e. defect detection. 4. Testing is a means of measuring system functionality and quality. 5. Testing is evaluating the attributes and capabilities of programs and project work products, and assessing whether they achieve required or acceptable results. 6. Testing includes inspections and structured peer reviews of requirements and design, as well as execution test of code.

Figure 10. A simple test and evaluation process.

A simple testing process consists of evaluation, testing, and execution of those test cases. Evaluation process is a manual validation and verification such as walkthrough and inspection should take place to discover any early aspect of identifying errors. Testing is process which can be done either manually or automatically by using software tools to generate test cases. Execution is the process by which those test cases can be implemented to see if they have

168

Muthu Ramachandran

passed or failed and hence correction can be made to the system. A simple test and system evaluation process model is shown in Figure 10. The objective is to design tests that systematically uncover different classes of error and do so with a minimum amount of time and effort. However, testing can only show where defects are present; it cannot prove the absence of faults. The process of testing programs emerged almost simultaneously with the first experiences of writing programs, with references made to testing as early as 1950. The early view was that you wrote a program and then you tested and debugged it (Hetzel 1988). However, this is no longer the case and the testing and debugging processes are clearly separated. McGregor & Sykes (2001) state that the purpose of software testing is to identify flaws within a program but “testing does not include the debugging or repair of bugs”. The place of development and testing within the development lifecycle really depends on the development methodology used and the Software Quality Assurance (SQA) procedures followed by the development company. However, over the past decade it has been recognised that testing should be conducted throughout the entire project lifecycle, “this is common to software testing in general and not restricted to object oriented testing”. Some traditional development methodologies, such as the Waterfall model, place less emphasis on the testing processes, which occur only once an artefact has been developed. However, additional Quality Assurance processes should be in place within the development company, to ensure that testing procedures are in place throughout the project lifecycle.

Figure 11. The V model of software development process.

Modern software testing encompasses processes to test against documentation, as well as the final product at various stages of the development lifecycle. The Verification and Validation process is a full life cycle approach to testing, encompassing both dynamic and

Software Components for Large Scale Super and Grid Computing Application

169

static testing processes. In the Verification and Validation process each stage of development is equated to a stage in the development lifecycle, as demonstrated below. This is known as the V development model as shown in Figure 11. Testing is an expensive process, with a large proportion of the development budget being spent on it. By testing earlier on in the development cycle, costs can be reduced by identifying errors at an earlier stage in development, thereby mitigating their impact on a project and its end product. In the V model of development, each stage of the development process is associated with a testing phase. The following diagram highlights how the various Verification and Validation testing phases equate to each development stage in the software development process.

Embedded and Real Time Software Testing Hardware is increasing being replaced by software in embedded system design to reduce costs and allow greater flexibility. However, this raises a number of safety issues and emphasises the need for efficient and effective testing methods that can be applied to embedded and real time systems. Many of the methods discussed in previous chapters are utilised in embedded system testing. White Box testing – Due to the strict requirements for safety and reliability embedded systems often require more rigorous white box testing than conventional systems. In this type of testing it is impossible to cover 100% of the code and only the most important code areas are tested. In embedded systems higher code coverage is necessary. Paulson (1999) of the University of Calgary says that “for embedded systems, code-based testing is not required to be done on the target hardware. It is often more practical to do white box testing on the development environment using hardware simulation”. However, it should be noted that systems developed using the object oriented paradigm face the problem that operations cannot be tested in isolation, but only as part of a class. This serves to restrict the use of many of the white box testing techniques. Black Box testing – This type of testing is particularly useful in the testing of embedded systems (Paulson 1999), as it examines the systems functionality from a real-world perspective. It therefore allows the test team to examine whether the system meets requirements, how it will operate under given circumstances, and how it responds in extreme circumstances. Paulson (1999) says that embedded software is frequently used in circumstances where is it necessary for it to “fail gracefully” and that black-box testing should be designed to identify both how the software works and how it fails. Clean-room development – Clean-room and formal methods development are ideal for use in this type of environment. The strict mathematically based notation of the language serves to ensure the correctness of the system or parts of the system specified in this way. Testing by way of inspection, formal reviews and mathematical proofs provide a more rigorous testing process, thereby mitigating many of the errors which may not have been detected in conventional development and testing processes. A lack of testing embedded systems can cause extreme problems. This can be exemplified by the problems experienced in the lead up to the turn of the century. Industry on the whole spent billions of pounds checking for year 2000 compliance and waiting for the potentially serious impacts of system failure. During this time, Yorkshire Electricity in Leeds spent around £12 million on a two year project to test for compliance and prepare for the year

170

Muthu Ramachandran

2000. Their findings were that whilst the majority of system and application software were year 2000 proofed, their embedded systems software presented major potentially life threatening problems. The end result was that there were a number of minor failures within the electricity grid, but no life threatening occurrences were experienced. Had a full lifecycle testing and development methodology being used when originally developing these embedded systems, the financial investment at outset would have been slightly higher however, they could have saved themselves a great deal of money and stress had they done so. However, this cannot always be the case and it raises the question of how do you test legacy systems?

Survey of Testing Tools There are wide spectrums of testing tools currently available, some of which can be downloaded freely over the Internet, whilst others must be purchased. At the moment there are no regulations governing the release of testing tools and therefore quality cannot always be guaranteed. Many are developed with a specific development language in mind; at the moment Java seems to be the most popular target language. In this section we do not aim to present the vast numbers of tools available, but to provide an overview of the types of tool available. A list of proprietary testing tools has been included within the appendices. The following are a list of software testing tools available to cater for all stages of the development and testing lifecycle, including: • •

• • •

•

• •

Code analysers – these monitor code complexity and adherence to standards Coverage analysers – these tools check which parts of the code have been exercised by a test and may be oriented to code statement coverage, conditional coverage and path coverage. Memory analyser tools – such as bounds checkers and leak detectors. These are particularly useful for embedded systems. Load/performance test tools – these test client/server and web applications under various load and stress levels. Performance analysis tools – estimates the amount of code that is time intensive. They can illustrate which routines are time sensitive and may lead the developer to errors in system calls or inefficiencies in the program structure. Again these are useful in embedded systems. GUI testers – these testers have the ability to record and playback operator actions and take snapshots of the displays for later evaluation, and to set up and arrange tests. In embedded systems they can be used as a scripting tool to run tests in the development environment. Coverage tools – these are used during white box testing to track the portion of the code that has been executed. Web test tools – to check that links are valid, html code usage is correct, client side and server side programs work, and that web sites interactions are safe.

Software Components for Large Scale Super and Grid Computing Application • •

•

• • • •

171

Databases – can be used for defect tracking, organisation of test cases, fault analysis and test data generation, amongst other things. Defect tracking tools – used to record the failures, identify the cause and the corrections to the code to eliminate the fault. They can be linked to the configuration management tools and allow automatic distribution of reports. Configuration Management tools – are useful to the tests in allowing them to identify exactly the code revision being tested and to track software faults to a specific revision of each component of the software under test. Configuration Management tools can also be used to track the automated tests and documentation on manual tests to ensure the proper version of the tests are being used. Design tools – such as the Rational Rose ‘Together’ tool, which facilities the design and creation of UML diagrams, and ZTC, a syntax checker for formal methods. Case tools – which provide a graphical method for analysis, design and code generation. Compilers – which check code for syntax and semantics. Test design tools - These tools help organise and execute suites of test cases. Some have graphical user interfaces (GUIs), but they don't have any special support for testing a product that has a GUI.

These tools need to be carefully evaluated and selected for the specific requirements for supercomputing applications. For example test director tool can be used to instrument the code for testing to see what is going on each node of the supercomputing grids.

Conclusion Software components for supercomputing applications have become the key to developing supercomputer applications. Software development for large and complex systems remains a costly affair. The complexity for supercomputing applications that require high speed and high precision systems grows exponentially. This chapter provided an approach to design and development of supercomputing applications based on software components which have potential to minimise the cost and time for complex and high dependability systems. Some of the key points are: 1. Identify non-functional requirements for supercomputing such as re-configurability and reusability 2. Use those non-functional requirements when designing component interface so that the variability can be assessed and modifies for new environment 3. A wide range of testing tools were provided for using it at various aspect in development life-cycle

172

Muthu Ramachandran

References [1]

[2] [3] [4] [5] [6] [7] [8] [9] [10] [11]

[12] [13] [14] [15] [16] [17] [18] [19] [20]

Donzelli, P. and Basili, V (2006) A practical framework for eliciting and modeling system dependability requirements: Experience from the NASA high dependability computing project, Journal of Systems and Software, Volume 79, Issue 1, January 2006, Pages 107-119 Bode, B. et al (2005) Scalable system software: a component-based approach, Journal of Physics: Conference Series 16 (2005) 546–550 Trip, J. L et al. (2005) Partitioning hardware and software for reconfigurable supercomputing applications: a case study, Proc. of the Supercomputing Conference (SC’05), 2005, ACM/IEEE Press Dobbing, B. and Burns, A. (2003), The Ravenscar Profile for real-time and high integrity systems, CrossTalk, the Journal of defence software engineering, November 2003. Gutierrez, J. J et al. (2002) Modeling and schedulability analysis in the development of real-time distributed Ada systems, Ada Letters, Vol. XXII, No.4. Naik, K. V et al (1993) Performance analysis of job scheduling policies in parallel supercomputing environments, , ACM Press Laszewski, v, G. et al (2002) Software, Component, and Service Deployment in Computational Grids, First International IFIP/ACM Working Conference on Component Deployment, June 20-21, 2002, Berlin, Germany Laprie, J-C (2004) Dependable Computing: Concepts, Challenges, Directions, COMPSAC, Hong Kong, 28-30 September 2004 Miller, E. L and Katz, R. H. (1991) Input/output behaviour of supercomputing applications, ACM Press Silvestri, F et al. (2006) Toward a search architecture for software components, Journal of Concurrency and Computation: Practice and Experience, 2006:18:1317-1331 Armstrong, R et al. (1999) Toward a common component architecture for highperformance scientific computing, proc. of the 8th IEEE Intl. Symposium on High performance distributed computing, IEEE Computer Society Press, Los Alamitos, CA, 1999; 13. Bass, R. N (2003) Component architecture in a network management system, Bell Labs technical journal, 8(3), 51-65 (2003) Wiley Schulze, B. Coulson, G., Nandkumar, R., Henderson, R. (2006) Special Issue: Middelware for Grid Computing: A ‘possible future’, Concurrency and computation: practice and experience, 10.1002/cpe.1132, Wiley. McGregor, J. & Sykes, D. (2001) A Practical Guide to Testing Object-Oriented Software. New Jersey, Addison Wesley. Hetzel, J (1988) The art of software testing, John Wiley Sommerville, I (2006) Software Engineering, 8th Edition, Addison Wesley. Pressman, R (2004) Software Engineering, 6th Edition, McGraw Hill Cheesman, J. and Daniels, J. (2000) UML Components, Addison Wesley Eddon, G and Eddon, H (1998) Inside Distributed COM, Microsoft Press. Sessions, R (1998) COM and DCOM, Wiley.

Software Components for Large Scale Super and Grid Computing Application

173

[21] Jacobson, I et al (1997) Software Reuse: Architecture, Process and Organisation for Business Success, Addison Wesley [22] Szyperski, C (1999) Component Software, Addison Wesley [23] D’Souza and Wills (1999) Objects, components and frameworks with UML, Addison Wesley [24] IEEE SW (1998) Special issue on Software components, IEEE Software, September 1998 [25] Brown, W. A and Wallnau, K. C (1998) The Current state of CBSE, September/October 1998 [26] Heineman, G. T. and Councill, W. T (2001) Component-Based Software Engineering, Addison Wesley [27] Sessions, R (2005) Fuzzy Boundaries, ACM QUEUE, Dec/Jan 2005 [28] Pressman, R (2004) Software Engineering, McGraw Hill, 6th edition [29] Brown, A (1996) Component-Based Software Engineering, IEEE Computer Society Press [30] OMG CORBA www.omg.org [31] DCOM www.microsoft.com [32] SunJava www.java.sun.com [33] Williams, J (2001) The Business case for components, Chapter 5, Heineman, G.T and Councill, W.T (Editors), Component-Based Software Engineering, Addison Wesley [34] Brererton, P and Budgen, D (2000) Component-Based Systems: A Classification of Issues, IEEE Computer, November. [35] Meyers, S (2004) The Most important design guidelines, IEEE Software, July/August 2004 [36] Heineman, G. and Crnkovic, I (2005 & 06) Component-Based Software Engineering: 8th International Symposium, CBSE 2005 and CBSE 2006 (Lecture Notes in Computer Science), Springer-Verlog [37] Lowy, Juval (2005) Programming .NET components, O’Reilly [38] Ramachandran, M and Fleischer, W (1996) Design for large scale software reuse: an industrial case study, IEEE International conference on Software Reuse (ICSR 1996), Florida, USA.

In: Software Engineering and Development Editor: Enrique A. Belini, pp. 175-184

ISBN: 978-1-60692-146-3 © 2009 Nova Science Publishers, Inc.

Short Communication G

PRINCIPLES AND PRACTICAL ASPECTS OF EDUCATIONAL SOFTWARE EVALUATION 1

Quynh Lê1 and Thao Lê2 Department of Rural Health, University of Tasmania, Australia 2 Faculty of Education, University of Tasmania, Australia

Abstract Software is not just a product for all-purpose use. Generally, software is produced for a specific purpose in a domain. Some software products appeal to a wide range of users such as word processing, drawing, and editing. However, softwar is developed to cater for the demand of targeted users. For example, Statistical Packages for Social Science (SPSS) is a statistic analysis tool for analyzing quantitative data in research. In education, the main aim of software is to enhance teaching and learning. It is important to evaluate educational software to determine its effectiveness. There are a number of issues concerning evaluation of educational software such as users’ and evaluators’ perspectives on teaching and learning, translation theory into practice.

Keywords: Evaluation, educational software, user-friendly, computer-supported education.

Introduction Computer technology has permeated society in general and education in particular. While computer technology has created an impact in education, the debate on its role in teaching and learning has not comfortably settled [1-6]. While some educators are reluctant to take the advantage of computer in education, others make use of computer technology to enhance teaching and learning. Educational software can play an important role in enhancing educational contexts. The popularity of the Web has brought various parts of the world together. Gradually it has created its own culture. From the educational viewpoint, learning interaction is no more restricted to a few classmates in a classroom. The interaction has widened to include those from different geographical and cultural backgrounds. Teachers are no longer the only

176

Quynh Lê and Thao Lê

powerful source of knowledge and the library is no loner the only “house of information”. In other words, the virtual world almost becomes a reality, not just an imagination. However, like all products on the market, not all educational software is suitable and productive for teaching and learning. Thus awareness of issues related to the evaluation of educational software is important to educators. To capture this dynamic connection between software and educational rationales in software evaluation, metaphor is used an as evaluative approach to highlight the theory and practice of software evaluation as they symbolize different roles that software plays in teaching and learning.

Significance of Evaluation Geissinger [7] made a very interesting statement when he discussed the complexity of evaluation in teaching and learning: A simple question for any educational software should be: “Can this product actually teach what it is supposed to?” It is a simple question to ask, but often difficult to answer because the product may have so many beguiling features. It requires the evaluator to recognize his/her own view of the ways in which students learn, to relate that view to the learning objectives of that portion of the course and to determine how and whether those objectives are carried out in the software (p. 222).

Evaluation is one of the most important aspects of teaching and learning. If it is well planned and conducted, evaluation gives many valuable insights about aim achievement, learners’ attitudes and learning styles, teachers’ performance, learning environment, and course improvement. According to Wilss [8], productive learning is dependent upon considerations such as content, delivery, the needs of the learner, and specific aspects of the learning environment. Evaluation of courses that incorporate technological innovations helps to illuminate factors that may contribute to educationally sound practices and productive learning outcomes. Traditionally, evaluation is formally conducted primarily to find out about students’ ability to undertake a particular task or course. Bain and McNaught [9] point out that teaching staff hold firmly certain views on learning and teaching which reinforce the adoption of the following teaching approaches: • • •

a reproducing, transmitting, expository conception which focuses on reproductive learning; a pre-emptive orientation which focuses on explanations about past students learning difficulties; and a conversational or transformative conception which focuses on mutual meaning making process between teachers and learners (p.56).

A meaningful evaluation of a programme should take into account the dynamic learning and teaching process including participants, academic programmes, and learning conditions. Evaluation of teaching and learning consists of two main types: formative and summative. The former refers to an on-going process whereas the latter refers to a crucial stage, normally at the end, of a teaching programme. Geissinger [7] suggests that formative methods of

Principles and Practical Aspect of Educational Software Evaluation

177

evaluation are used when a project’s outline has been decided and work has begun on the design and development of the various parts. Geissinger says: It can be deliberate and consists of a series of methods to determine whether the project can work as planned or it can be so ad hoc that it consists mainly of obtaining the opinions of passengers-by as to the visual effectiveness of a series of screens (p. 220).

According to Wilss [8], productive learning is dependent upon considerations such as content, delivery, the needs of the learner, and specific aspects of the learning environment. Evaluation of courses that incorporate technological innovations helps to illuminate factors that may contribute to educationally sound practices and productive learning outcomes. Traditionally, evaluation is conducted primarily to find out about students’ ability to undertake a particular task or course. The results gained from this kind of evaluation are often used to reinforce evaluators’ expectations and assumptions. Bain and McNaught [9] point out that teachers firmly hold certain views on learning and teaching which reinforce the adoption of their teaching approaches. Teaching styles and the use of educational resources reflect the views of teachers on how learners “should” learn. The choice of educational software is also determined by the educational principles that they adopt. As the amount and variety of educational software grows, there is a commensurate need for it to be assessed for suitability for its intended purpose. Teachers need to know whether and how an item can be used to improve their teaching; learners need to know how it might impact the learning experience [10]. As computers have become more rapid and powerful, educational software has flourished and there are numerous claims made by software developers in order to sell their products to teachers. Thus, evaluation of educational software is important so that teachers can make an appropriate choice of the software which reflects their educational principles and which is appropriate to the teaching and learning context. While numerous software packages saturate the educational market, there is a growing number of evaluative criteria and checklists (for examples [11]. Instead of adding to the already large number of checklists for software evaluation, we propose a metaphor approach to address evaluation of educational software. The rationale and implementation of this approach will be presented in the rest of this chapter.

Metaphor as an Evaluative Approach According to Henkel [12], great emphasis is being placed on understanding teacher's thought patterns, or the reflection that occurs about the teaching-learning process. Thinking about this process in different ways is crucial for teachers to most effectively understand and carry out their roles in the classroom and school more broadly. Teachers’ roles are most effectively carried out if they are consistent with a coherent educational philosophy. Metaphor concepts present in teachers’ communication with colleagues, students and their parents give meaning to teachers’ views about teaching and learning. We may not always know it, but we think in metaphor. A large proportion of our most commonplace thoughts make use of an extensive, but unconscious, system of metaphorical concepts, that is, concepts from a typically concrete realm of thought that are used to

178

Quynh Lê and Thao Lê

comprehend another, completely different domain. Such concepts are often reflected in everyday language, but their most dramatic effect comes in ordinary reasoning [13]. Metaphors are constantly used by teachers when they talk about their teaching, children’s learning, and most importantly their views, assumptions, and beliefs about teaching and learning. Metaphors are used consciously by teachers to draw attention to important concepts and ideas in education. However in most cases, metaphors have become so widely used in an educational discourse that its metaphorical nature may not be noticed. The following sentences occur very often in teachers’ communication. • • • • •

Some children are like a blank sheet and we need to fill in for them. School is not the real world. It is a prison for some students and a home for others. Teachers and students are members of a learning community. The computer is a tool. It is not a teacher. The Internet is an educational superhighway.

Metaphors may be used as a powerful tool for determining and expressing one's educational philosophy. Often other professionals and lay people are more receptive to ideas when they are expressed indirectly through symbolism. Metaphors use symbolism to link ideas about teaching and learning to something more familiar [12]. The use of educational metaphors in evaluation of education software is illuminative as they are powerful in conceptual construction. Metaphor may create realities for us, especially social realities as they not only make our thoughts more vivid and interesting but they actually structure our perceptions and understanding [14]. Instead of using traditional features for evaluating software such as screen design, navigation, text type, cost and user-friendliness, we use the concept ‘metaphor’ as a basis on which evaluation of software is conducted. By doing this, we assign significance to the educational aspect of education in software evaluation. The following metaphors are chosen as they represent major theoretical perspectives and software developments in educational multimedia: • • • •

Software as a tool; Software as an instructor; Software as a facilitator of learning; Software as a virtual class.

The discussion of each metaphor starts with a brief presentation of the relevant theoretical perspectives and later examines how the metaphors underpin software evaluation. As previously stated, instead of adding to the number of checklists for software evaluation, we propose a metaphor approach to address evaluation of educational software. The points or questions given under each metaphor category should be used as illustrative items of evaluative criteria in the proposed metaphor approach to software evaluation.

Principles and Practical Aspect of Educational Software Evaluation

179

Software as a Tool There are many types of software and they are produced and used for a purpose. In education, the most versatile function of software is instrumental. It is used for performing a certain function such as calculating, drawing, editing, proofreading, communicating, etc. Word processing is the most widely used software in education. Students use them to write assignments, produce documents, and communicate with others. Software for proofreading includes spell checking and grammar checking. Nowadays, most software is multifunctional. For example, word processing software can perform many complex functions, such as text editing, statistical analysis, communication and design. Apart from the versatile software programs for general purposes such as WORD, EXCEL, ACCESS, PowerPoint and Publisher, some software programs are designed for specific purposes such as SPSS, STRATA and SAS for statistical data analysis, NVivo and Atlas-TI for qualitative data analysis, and EndNote for referencing. Evaluation is often made in the form of a checklist used by developers, teachers and learners. A checklist is a list of items, which covers important points to be examined. According to Squires and McDougall [15], many lists of criteria for assessment of individual packages have been used. They vary in content, length and style, but all have been designed in an attempt to help teachers choose software of educational value. Evaluation of software as a tool takes into account the following factors: • • • • • •

The educational background of the target learners; Their Information and Communication Technology (ICT) literacy awareness; The user-friendly features; “Help” facility; Cost; and Hardware support.

Software as an Instructor This metaphor represents the instructionist view of teaching and learning. When software is used as an instructor, its primary role is to teach learners to develop knowledge and skills. Normally it is hierarchically structured in terms of content and skill complexity. Each lesson focuses on a specific content or skill and all the lessons are arranged from introductory to advanced levels. Instruction is sequential in the sense that learners are expected to move sequentially from the early lessons to the final ones. Skipping lessons is discouraged as it interrupts the continuity of the structured instruction and could affect learners’ progress and achievement. Drill-and-practice is a common feature of instructional software as it reflects strongly the Initial-Response-Evaluation (IRE) model, which consists of three sequential stages: 1. Initial stage: Instructors introduce the content in terms of definition, description and explanation.

180

Quynh Lê and Thao Lê 2. Response stage: After having been exposed to instructions, learners are expected to gain knowledge or skills and know how to translate new knowledge or skills into practice. 3. Evaluation: Teachers evaluate learning through responses given by learners.

In the IRE model, learning objectives must be established at the beginning before a software item is developed. They are used to evaluate learning. Objectives used in education, whether they are called learning objectives, behavioural objectives, instructional objectives, or performance objectives are terms that refer to descriptions of observable student behaviour or performance that are used to make judgments about learning - the ultimate aim of all teaching [16]. The following geometry software prototype illustrates the metaphor of software as an instructor. a) Lesson 1: Scale drawing i. What is scale drawing? ii. Some examples of scale drawing iii. Why do we need scale drawing? iv. Scale drawing exercises. b) Lesson 2: Parallelograms i. What is a parallelogram? ii. Three special types of parallelograms iii. Rhombus iv. Rectangle v. Square vi. Angles of a parallelogram c) Investigation exercises In summary, evaluation of educational software from the instructionist perspective takes into account the following factors: • • • • •

Does the software have clearly stated learning objectives? How are the learning objectives projected in the software? Is the software structured in terms of complexity and its developmental stages? Does the software provide items for drill-and-practice exercises? Does the software provide items for testing?

Software as a Facilitator of Learning This metaphor represents constructivism. Papert [17] questioned the traditional view underlying educational software. His view is that educational software based on instructionism does not prepare children for the computer age. While the instructionist model of educational software focuses on the significance of instruction in teaching and learning, the constructivist model of educational software plays less attention to instruction and more on

Principles and Practical Aspect of Educational Software Evaluation

181

the active role of learners in the learning process. Learning is viewed as a meaning making process as learners bring their knowledge, experiences and world view to learning. In many aspects, instruction software is rather consistent in its presentation of form and content to learners; whereas constructionist software varies a great deal, not so much in terms of learning principles but more on the learning experiences and the kind of communicative interaction between learners and their teachers. Turtle Geometry is a pioneer of constructionist educational software under the leadership of Papert. He is one of the pioneers of Artificial Intelligence and Logo at Massachusetts Institute of Technology (MIT). He is a mathematician, computer scientist and prominent educator. Logo is a programming language developed for children. It provides onscreen objects, widely known as Turtles. Children can direct Turtles to move on various paths by giving them commands. Thus they can create various shapes. In language education, a constructionist prototype of web-based software typically consists of the following features: • • • • • • • •

Topic introduction, Inquiry-based learning, Task-based learning, Case study as a basis for discussion and reflection, Questions and discussion, Illustrations, Suggested projects, Resources.

In summary, evaluation of educational software from the facilitator perspective asks the following questions which underlie the constructionist perspective. • • • • • •

Does the software promote curiosity and inquiry? Does the software give choices for learners to control their own learning? Does the software present tasks for problem solving? Does the software provide collaborative learning experiences? Does the software provide interaction with others? Does the software provide educational tools and relevant resources for learners and teachers?

Software as a Virtual Class When we think of educational software, we tend to focus on small items of software such as programs teaching pronunciation, multiplication, grammar, and typing. These software programs are designed to teach a specific skill. There are also educational software packages which are designed for a targeted group of learners such as a web-based academic course and a multimedia-based training program. This type of software is called “courseware”. For example, MIT’s OpenCourseware [18] is produced by MIT and it consists of a number of

182

Quynh Lê and Thao Lê

courseware for different courses such as architecture, health sciences and technology, biology, and economics. As a free courseware, it is basically a collection of course materials placed on the Web. Lê [19] produced a web-based courseware called “Academic Language Courseware” for the teaching of academic genre. It consists of tutorials on key aspects of academic genre, communicative interaction with teachers and other learners, recommended readings, and on-line resources. This courseware is based on the concept and principles of a virtual class. MarketPlace [20] is another type of courseware which has a problem-based orientation. It enables students to participate in economic simulations over the Internet, playing the roles of buyers and sellers in a virtual marketplace. This problem-based courseware includes online discussion facilities, designed to support not only economic dealmaking among participants but also reflection and analysis of the economic patterns that arise from the interactions [20]. Evaluation of educational courseware takes into account the following factors: •

•

• •

•

•

Flexibility: A courseware should be flexible enough to cater for learners’ learning styles and interests when they negotiate through their learning and to allow the learners to learn at their own pace. Interactivity: This includes textual and communicative interactivity. Textually, learners can explore various parts of the courseware, which are structure-based and content-based. Communicatively, a communication board is provided for discussion among participants. Multimedia power: A range of multimedia tools are embedded in the courseware for learners to construct their own materials and to access other sources. Resources: It is important for promoting independent learning. Reading materials include scanned articles from books and those available on the Web. Guided tours of various web sites dealing with specific issues or topics should be made available. A wide range of learning experiences: Apart from the content-based topics dealing with different aspects of a course, there should be different sub-components such as practical implications, problem-solving tasks, and self-testing. Learners' evaluation: The courseware should include a component to provide a userfriendly facility for students to contribute their evaluation and feedback.

According to Geissinger [21], education software is produced for an educational purpose. This sounds very simple. However, evaluation of educational software is a complex task as it requires an understanding of the principles and perspectives of teaching and learning and how they are used to develop educational software. A simple question for any educational software should be: “Can this product actually teach what it is supposed to?” It is a simple question to ask, but often difficult to answer because the product may have so many beguiling features. It requires the evaluator to recognize his/her own view of the ways in which students learn, to relate that view to the learning objectives of that portion of the course and to determine how and whether those objectives are carried out in the software [21].

Principles and Practical Aspect of Educational Software Evaluation

183

Conclusion Computer software is developed for a purpose. Educational software enables a computer system to process data, including both the operating system and a variety of application programs for teaching and learning. With the rapid development of computer technology, software is increasingly powerful. It makes the task of software evaluation more challenging. Basically, two main educational perspectives underlie current software evaluation: instructionist and constructionist. The former is generally teacher-centred and the latter is learner-centred. It is worth noting that it is not strictly an “either-or” commitment as these two theoretical views are not necessarily mutually exclusive in eduction.

References [1] Clark RE. Media will never influence learning. Educational Technology Research and Development 1994;42(2):21-9. [2] Jonassen D. Objectivism versus constructivism: Do we need a new philosophical paradigm? Educational Technology Research and Development 1991;39(3):5-14. [3] Kozma RB. Will media influence learning? Reframing the debate. Educational Technology Research and Development 1994;42(2):7-19. [4] Perelman LJ. School's out: Hyperlearning, the new technology, and the end of education. New York: William Morrow; 1992. [5] Rodd J, Coombs S. Distance learning with a difference: Using the internet to deliver higher education. In: Ottmann T, Tomek I, editors. Proceedings of ED-MEDIA/EDTELECOM 98 world conference. Charlottesville, Virginia: Association for the Advancement of Computers in Education; 1998. p. 1169-74. [6] Skillicorn DB. Practical replacement of lectures by hypermedia courseware. In: Ottmann T, Tomek I, editors. Proceedings of ED-MEDIA/ED-TELECOM 98 world conference. Charlottesville, Virginia: Association for the Advancement of Computers in Education; 1998. p. 1280-5. [7] Geissinger H. Educational software: Criteria for evaluation. In: Kevill R, Oliver R, Phillips R, editors. Proceedings of ASCILITE'97 on what works and why? Perth, WA: Curtin University of Technology; 1997. p. 219-25. [8] Wilss L. Evaluation of computer assisted learning across four faculties at Queensland University of Technology: Student learning process and outcomes. In: Kevill R, Oliver R, Phillips R, editors. Proceedings of ASCILITE'97 on what works and why? Perth, WA: Curtin University of Technology; 1997. p. 636-42. [9] Bain J, McNaugh C. Academics' educational conceptions and the design and impact of computer software in higher education. In: McBeath C, Atkinson R, editors. Proceedings of the Third International Interactive Multimedia Symposium: The learning super highway. New world? New worries? Perth, Western Australia: Promaco Conventions Pty Ltd; 1996. p. 55-9. [10] Hammond N, Trapp A, McKendree J. Evaluating educational software: a suitable case for analysis; 1994 [cited 2009 15 July]; Available from: http://ctiwebct.york.ac.uk/ LTSNCiPAbstracts/CiP94/Hammond.html.

184

Quynh Lê and Thao Lê

[11] CEISMC. Evaluation Tools. Center for Education Integrating Science, Mathematics and Computing (CEISMC); 2006 [cited 2006 12 November]; Available from: http://mime1.marc.gatech.edu/MM_Tools/evaluation.html. [12] Henkel S. Reflective metaphors; 2006 [cited 2006 18 October]; Available from: http://www.bethel.edu/~shenkel/Curriculum/Metaphors/Metaphors.html. [13] Lakoff G. Metaphor, Morality, and Politics or Why Conservatives Have Left Liberals In the Dust; 1995 [cited 2009 15 July]; Available from: http://www.wwcd.org/issues/ Lakoff.html. [14] Lakoff G, Johnson M. Metaphors We Live By. Chicago: University of Chicago Press; 1980. [15] Squires D, McDougall A. Choosing and using educational software: A teachers’ guide. London: The Falmer Press; 1994. [16] Kizlik B. How to Write Learning Objectives that Meet Demanding Behavioral Criteria; 2006 [cited 2009 15 July]; Available from: http://www.adprima.com/objectives.htm. [17] Papert S. The Children's Machine: Rethinking School in the Age of the Computer. New York: Basic Books; 1993. [18] MIT. MITOPENTOCOURSEWARE. Massachusetts Institute of Technology; 20022006 [cited 2006 19 October]; Available from: http://ocw.mit.edu/index.html. [19] Le Q. The Development and Evaluation of a Multimedia-based Instruction Package on Scientific Genre [PhD thesis] Curtin University of Technology; 1999. [20] Resnick M. Distributed Constructionism; 1996 [cited 2009 15 July]; Available from: http://llk.media.mit.edu/papers/Distrib-Construc.html. [21] Geissinger H. Educational software: Criteria for evaluation. In: R. Kevill RORP, editor. Proceedings of ASCILITE'97 on what works and why? Perth, WA: Curtin University of Technology; 1997. vol 219-225

RESEARCH AND REVIEW STUDIES

In: Software Engineering and Development Editor: Enrique A. Belini, pp. 187-191

ISBN 978-1-60692-146-3 c 2009 Nova Science Publishers, Inc.

Chapter 10

T ESTING E VENT-D RIVEN S OFTWARE – T HE N EXT QA C HALLENGE ? Atif M. Memon∗ Department of Computer Science University of Maryland, College Park, MD 20742

Abstract A particular class of software that is fast becoming ubiquitous is event-driven software (EDS). All EDS share a common event-driven model – they take sequences of events (e.g., messages, mouse-clicks) as input, change their state, and (sometimes) output an event sequence. Examples include web applications, graphical user interfaces (GUIs), network protocols, device drivers, and embedded software. Quality assurance tasks such as testing have become important for EDS since they are being used in critical applications. Numerous researchers have shown that existing testing techniques do not apply directly to EDS because of the new challenges that EDS offer. This column lists some of these challenges and emphasizes on the need to develop new techniques (or enhance existing ones) to test EDS.

1.

Introduction

As computers and embedded devices find increasingly more applications in today’s inter-networked world, several classes of event-driven software (EDS) are becoming ubiquitous, including graphical-user interfaces (GUIs), web applications, embedded software, component and object-based software, device drivers, heterogenous active agents, robotcontrol software, simulation software, and visualization software. GUIs are now seen in cars, phones, dishwashers, washing machines, etc. A user interacts with complex underlying software by performing actions such as menu-clicks and selections on the GUI. The software responds by changing its state and/or producing an output, and waits for the next input. Web applications are used via computers, televisions, PDAs, cell phone, and devicespecific browsers. Users perform actions from a multitude of platforms to interact with these ∗

E-mail address: [email protected]

188

Atif M. Memon

applications that change their state, produce outputs, and wait for the next user action. Network protocols form the basis for all network traffic. Protocol Data Units (PDUs) are sent from one networked device (node) to another. The recipient node processes the PDU, responds by changing its state and/or sending a PDU, and waits for the next PDU. Embedded software controls modern buildings, cars, elevators, fire-alarms, etc. Sensors send signals to the software that changes its state, sends output signals to control devices, and continues to wait for signals. Software components (and objects) form the building-blocks of most of today’s large software systems. Messages are sent from one component to another. Components react by changing their internal state, respond with messages, and/or wait for the next message. Device drivers, heterogeneous active agents, robot software, simulation software, and visualization software also use a similar model of execution, i.e., they receive interrupts, database-operations, events, commands, simulation-signals, and user inputs, respectively, to change their internal states, produce outputs, and wait for subsequent inputs. As these EDS are used in critical applications ( e.g., air-traffic controllers1 and space missions 2), their quality becomes important. There are several useful techniques that may be employed during the software development and deployment process to help improve software quality. An important technique is software testing, in which test cases are created and executed on the software. Several researchers have shown that existing testing techniques do not apply directly to certain classes of EDS, e.g., database applications, GUIs, device drivers, web applications, and network protocol implementations; testing them requires the development of new techniques.

2.

Challenges of Testing EDS

EDS (architecture described in attached SUB-COLUMN entitled “What is Event-driven Software?”) is gaining popularity because of the flexibility that it offers to both developers and users: (1) it allows a software developer to implement the EDS by coding (reusable) event-handlers (program code that handles or responds to an event) that can be developed and maintained fairly independently, (2) it gives many degrees of freedom to the software user, e.g., in a GUI, the user is not restricted to a fixed ordering of inputs, (3) it enables complex systems to be built using a collection of loosely coupled pieces of code, and (4) in interconnected/distributed systems, event handlers may be distributed, migrated, and updated independently. However, this flexibility creates problems during execution primarily because of the large number of permutations of events that need to be handled by the EDS. Since, in principle, event handlers may be executed in any order, we have shown that unanticipated interactions between them lead to software failures. The large number of interactions also create several new challenges for quality assurance (QA). First, the space of possible interactions with an EDS is enormous. Each event sequence can result in a different state, and the software may, in principle, need to be tested in all of these states. This large space of interactions results in a large number of input permutations, requiring a large number of test cases. Second, events performed on EDS drive it into different states. Not all events are allowed in each state. Explicit or implicit proto1 2

http://catless.ncl.ac.uk/Risks/23.41.html http://www.space.com/scienceastronomy/solarsystem/mpllatest update.html

Testing Event-driven Software – the Next QA Challenge?

189

cols specify the allowed (and sometimes disallowed) event sequences. EDS must not only be checked for event sequences allowed/disallowed by the protocols but also for those left unspecified. Hence, testing EDS requires the development and execution of a large number of off-nominal test cases, i.e., those that test the software for invalid input event sequences. Third, it is difficult to determine the test coverage of a set of test cases. For conventional software, coverage is often evaluated using the amount and type of underlying code exercised. These coverage criteria alone do not work well for EDS, because in addition to satisfying conventional measures of coverage, it is important to cover the different interactions between event handlers. Fourth, it is difficult to design robust test oracles (mechanisms to determine whether software has executed correctly for a test case) for EDS. In conventional software testing, the verification is done after the end of test case execution. The entire test case is executed by the software and the final output is compared with the expected output. In contrast, test case execution of EDS requires that the verification and test case execution be interleaved because an incorrect state may prevent further execution of the test case, as events in the test case may not be allowed in the incorrect state. Thus, execution of the test case must be terminated as soon as an error is detected. Also, if verification is not done after each step of test case execution, errors may be overlooked and pinpointing the actual cause of the error becomes difficult. Fifth, the run-time environment in which an EDS executes may change the software’s behavior. The space of possible run-time environment configurations is determined by the platform (hardware and software) in which the EDS executes. Since many EDS systems (e.g., web applications) are expected to execute in a large number of client configurations, the space of all possible configurations becomes very large, thereby requiring extensive testing. Finally, it is difficult to create a representation of EDS. It has been shown that finite state machine (FSM) models as well as representations for conventional software fail to scale for large EDS. An additional challenge that hinders research and development of techniques for testing EDS is that since very few specialized techniques exist to test EDS (discussed briefly in attached SUB-COLUMN entitled “Related Work”), unlike conventional software, there is little tool and artifact support for experimentation. We have developed new techniques to test specific classes of EDS, namely GUI-based software, web applications, and network protocol implementations. (These techniques are described briefly in a separate SUB-COLUMN entitled “An Event-flow Model to Test EDS”). We believe that the models that we have developed are general, in that they can be extended to other classes of EDS, and provide an excellent starting point for much needed future work.

An Event-flow Model to Test EDS Many researchers have used state-machine models to test specific classes of EDS. Recognizing the problems of scalability with these state-based models, we have developed a new representation of EDS based on event interactions. The key to the success of this representation is that it does not contain explicit state information. We have developed new models of the EDS’s “event space,” i.e., the software’s events and their interactions. For example, a structure called an event-flow graph represents allowable event sequences in the software. Nodes in an event-flow graph represent events (not states); an edge from node x

190

Atif M. Memon

to node y would mean that event y can be executed after event x. The model contains other structures such as integration trees and pre/postconditions to generate state information ondemand, e.g., for test oracle creation (i.e., mechanisms that determine whether a software executed correctly during testing). We have used abstractions such as detection of mutually exclusive events to make the space manageable for testing. We have defined an EDS test case as a sequence of events and developed search techniques to explore the event space for test case selection/generation, test coverage evaluation, and test oracle creation. Our event-based model has resulted in seminal work on testing certain classes of EDS and a strong foundation for extending the work. Using the event-flow model has enabled us to successfully develop and implement, as tools, several techniques to traverse the event space. They include a new test case generation technique that uses AI planning, test oracles that check the state of the EDS during test case execution, test coverage criteria based on events instead of code, a regression tester that repairs test cases that can no longer be executed on the software, a smoke tester for GUI-based applications, a preliminary tool for automated protocol implementation robustness evaluation, and techniques for searching large client configuration spaces of web and middleware software. (List of papers available on the author’s web-site.)

What Is Event-Driven Software? Various classes of software have been modeled using their event-driven nature. For example, GUIs have been modeled in terms of event-flow graphs, web applications have been modeled as a network of event-driven stages connected by queues, and middleware, embedded software, device drivers, simulation software, and component-based software have been modeled as event-driven software. Although specific implementations may differ, at a high level of architectural abstraction, all of the above event-driven applications contain event handlers that receive and process events. During software initialization , event handlers register themselves and specify the type of events to which they will respond. Then the software goes into an event loop, listening for events and invoking the corresponding event handler(s). Events are generated either by users, devices or event handlers. Event queues distribute events to event handlers. The destination for an event may be determined by a state variable such as mouse location or by an event handler having registered itself as a recipient for the particular event. In an implementation, event handlers may correspond to objects and the processing routines to methods or members functions. In a single-threaded system, one event-handler may be active at a time whereas in a multi-threaded system, multiple event-handlers may be executing concurrently. During software execution, event handlers may execute in any order, depending on the state of the software and the order of input events. Another view of the event-driven model is given by the reactor design pattern, a simple and elegant solution to the problem of developing event-based applications using the objectoriented paradigm [1]. There are several objects in this pattern. Handles identify resources (such as network connections, open files, and synchronization objects) that are managed by an operating system. Reactor defines an interface for registering, removing, and dispatching Event Handler objects. Event Handler specifies an interface used by the Reactor to dispatch callback methods defined by objects that are pre-registered to handle certain types of events

Testing Event-driven Software – the Next QA Challenge?

191

(such as input events, output events, and signals). Concrete Event Handler implements the customized callback method(s) that process events in an application-specific manner. During collaboration between the objects in the reactor pattern, event handler registration is done in the initialization mode and event handling is done in the event handling mode (loop).

Related Work There is little reported work on the general problem of testing event-based software systems. However, many researchers have addressed specific issues relevant to this topic. This section mentions those few who have recognized that testing EDS requires the development of new techniques. Most of the papers address the testing of command-driven software, reactive software, GUIs, and database applications. Several finite-state machine (FSM) models have been proposed to generate test cases for GUIs. In this approach, the software’s behavior is modeled as a FSM where each input triggers a transition in the FSM. A path in the FSM represents a test case, and the FSM’s states are used to verify the software’s state during test case execution. To aid in the scalability of the technique, variations such as variable finite state machine (VFSM) models have been proposed by Shehady et al.. Test cases that mimic novice users have also been generated. This approach relies on an expert to manually generate a sequence of GUI events, and then uses genetic algorithm techniques to modify and lengthen the sequence, thereby mimicking a novice user. White et al. present a new test case generation technique for GUIs. This technique also requires a substantial amount of manual work on the part of the test designer. The test designer/expert manually identifies a responsibility, i.e., a GUI activity. For each responsibility, a machine model called the “complete interaction sequence” (CIS) is identified manually. AI Planning has been found to be useful for generating focused test cases for a robot tape library command language. The main idea is that test cases for command language systems are similar to plans. White proposes a Latin square method to reduce the size of GUI regression test suite. Techniques have also been developed to test database applications in multiple execution environments. Notable is the work by Richardson et al. in TAOS (Testing with Analysis and Oracle Support) who proposes several levels of test oracle support for reactive systems. One level of test oracle support is given by the Range-checker which checks for ranges of values of variables during test-case execution. A higher level of support is given by the GIL and RTIL languages in which the test designer specifies temporal properties of the software. Harrold et al. have developed new techniques for testing object-oriented software and data-flow testing which can be leveraged for event-driven software.

References [1] Schmidt, D. C. Using design patterns to develop reusable object-oriented communication software. Commun. ACM 38, 10 (1995), 6574.

In: Software Engineering and Development Editor: Enrique A. Belini, pp. 193-221

ISBN 978-1-60692-146-3 c 2009 Nova Science Publishers, Inc.

Chapter 11

D EBUGGING C ONCURRENT P ROGRAMS U SING M ETAHEURISTICS Francisco Chicano and Enrique Alba Departamento Lenguajes y Ciencias de la Computacion, E.T.S Ingenieria Informatica, University of Malaga, Spain

Abstract Model Checking is a well-known and fully automatic technique for checking software properties, usually given as temporal logic formulae on the program variables. Some examples of properties are the absence of deadlocks, the absence of starvation, the fulfilment of an invariant, etc. The use of this technique is a must when developing software that controls critical systems, such as an airplane or a spacecraft. Most model checkers found in the literature use exact deterministic algorithms to check the properties. The memory required for the verification with these algorithms usually grows in an exponential way with the size of the system to verify. This fact is known as the state explosion problem and limits the size of the system that a model checker can verify. When the search for errors with a low amount of computational resources (memory and time) is a priority (for example, in the first stages of the implementation of a program), non-exhaustive algorithms using heuristic information can be used. Non-exhaustive algorithms can find errors in programs using less computational resources than exhaustive algorithms, but they cannot be used for verifying a property: when no error is found using a non-exhaustive algorithm we still cannot ensure that no error exists. In this work we propose the use of Ant Colony Optimization, a kind of metaheuristic algorithm, to find general property violations in concurrent systems using an explicit state model checker. Metaheuristic algorithms are a well-known set of techniques used for finding near optimal solutions in NP-hard optimization problems in which exact techniques are unviable. Our proposal, called ACOhg-mc, takes also into account the structure of the property to check in order to improve the efficacy and efficiency of the search. In addition to the description of the algorithm, we have performed a set of experiments using the experimental model checker HSF-SPIN and a subset of models from the BEEM benchmark for explicit model checking. The results show that ACOhg-mc finds optimal or near optimal error trails in faulty concurrent systems with a reduced amount of resources, outperforming in most cases the results of algorithms that are widely used in model checking, like Nested Depth First Search or Improved Nested Depth First Search. This fact makes our proposal suitable

194

Francisco Chicano and Enrique Alba for checking properties in large faulty concurrent programs, in which traditional techniques fail to find counterexamples because of the model size. In addition, we show that ACOhg-mc can also be combined with techniques for reducing the state explosion such as partial order reduction and we analyze the performance of this combination.

1.

Introduction

From the very beginning of computer research, computer engineers have been interested in techniques allowing them to know if a software module fulfils a set of requirements (its specification). These techniques are especially important in critical software, such as airplane controllers, nuclear power plant control systems, or medical tools software, in which people’s lives depend on the software system; or even bank information systems, in which a great amount of money can be lost due to software errors. In addition, modern non-critical software is very complex and these techniques have become a necessity in most software companies. One of these techniques is formal verification, in which some properties of the software can be checked much like a mathematical theorem defined on the source code. A very well-known logic used in software verification is Hoare logic [24]. However, formal verification using logics is not fully automatic. Although automatic theorem provers can assist the process, human intervention is still needed. Model checking [15] is another well-known and fully automatic formal method. In this case all the possible program states are analyzed (in an explicit or implicit way) in order to prove (or refute) that a given concurrent system satisfies a property like, for example, the absence of deadlocks, the absence of starvation, the fulfilment of an invariant, etc. The properties can also be specified using a temporal logic like Linear Temporal Logic (LTL) [14] or Computation Tree Logic (CTL) [13]. The memory required for the verification usually grows in an exponential way with the size of the system to verify. This limit is reached when the model checker is not able to explore more states due to the absence of free computer memory. This fact is known as the state explosion problem and limits the size of the system that a model checker can verify. Instead of applying model checking to the real concurrent system, it is usually applied to a model of the system, usually smaller, reducing the state explosion problem. There exist some languages especially designed for modelling concurrent systems, such as Promela (Process Meta-Language) [26], the language of SMV [28] or the intermediate language of SAL [5]. However, we can also find model checkers using widely spread programming languages for modelling concurrent systems. This is the case of Java PathFinder (JPF) [23], that can check Java programs. Several techniques exist to alleviate the state explosion problem. They reduce the amount of memory required for the search by following different approaches [26]. On the one hand, there are techniques which reduce the number of states to explore, such as partial order reduction [32] or symmetry reduction [12]. On the other hand, we find techniques that reduce the memory required for storing one state, such as state compression, minimal automaton representation of reachable states, and bitstate hashing [26]. Symbolic model checking [8] is another very popular alternative to the explicit state model checking which can reduce the amount of memory required for the verification. In this case, a set of states is represented by a finite propositional formula. However, exhaustive search algorithms are always handicapped in large concurrent systems because most of these systems are too

Debugging Concurrent Programs Using Metaheuristics

195

complex even for the most advanced techniques. When the search for errors with a low amount of computational resources (memory and time) is a priority (e.g., in the first stages of the development), non-exhaustive algorithms using heuristic information can be used. One example of this class of algorithms is Beam-search, included in the Java PathFinder model checker [23]. Non-exhaustive algorithms can find errors in programs using less computational resources than exhaustive algorithms, but they cannot be used for verifying a property: when no error is found using a non-exhaustive algorithm we still cannot ensure that no error exists. Due to this fact we can establish some similarities between heuristic model checking using non-exhaustive algorithms and software testing [29]. In both cases, a large region of the state space of the program is explored in order to discover errors; but the absence of errors does not imply the correctness of the program. This relationship between model checking and software testing has been used in the past for generating test cases using model checkers [4]. A well-known class of non-exhaustive algorithms for solving complex problems is the class of metaheuristic algorithms [6]. They are search algorithms used in optimization problems that can find good quality solutions in a reasonable time. In fact, Genetic Algorithms (GA) [22] and Ant Colony Optimization (ACO) [2] have been applied in the past for searching for property violations in concurrent systems. The previous work on this topic is mainly focussed on safety properties violations, the search for liveness property 1 violations with ACO is recent and only two articles focus on it [10, 11]. Anyway, the search for liveness and safety property violations using ACO has been tackled separately in the past. In this chapter we propose a unique ACO-based algorithm for searching for both safety and liveness property violations in concurrent systems. We present an experimental section in which we compare our algorithmic proposal, against traditional techniques used in the formal methods community using some models from a publicly available benchmark: BEEM [30]. We also study the influence on the results of Partial Order Reduction (POR) [32]. Although POR has been successfully combined with an ACO-based search algorithm for safety properties, it has not been combined with an ACO-based algorithm for liveness properties. In this chapter we combine POR with our algorithmic proposal for searching for general properties. The paper is organized as follows. The next section presents the foundations of explicit state model checking. In Section 3. the problem is formalized as a graph search. Section 4. describes our algorithmic proposal. In Section 5. we present some experimental results comparing our proposal against exhaustive algorithms utilized in the formal methods community and analyzing the influence on the performance measures of the partial order reduction technique. Finally, in Section 6. we discuss the application of our proposal from the software engineering point of view and we outline the conclusions and future work in Section 7. .

1

For a definition of safety and liveness property see Section 2.1..

196

2.

Francisco Chicano and Enrique Alba

Background

In this section we give some details on the way in which properties are checked in explicit state model checking. In particular, we will focus on the model checker HSFSPIN [19], an experimental model checker by Edelkamp, Lluch-Lafuente and Leue based on the popular model checker SPIN [26]. First, we formally define the concept of property of a concurrent system. After that, we detail how the properties can be represented using automata and we define the concept of strongly connected components , which allows us to implement improvements on the search algorithms. Then we detail how heuristic information is used to guide the search for property violations and finally we describe the partial order reduction (POR) technique.

2.1.

Properties

Let S be the set of possible states of a program (concurrent system), S ω the set of infinite sequences of program states, and S ∗ the set of finite sequences of program states. The elements of S ω are called executions and the elements of S ∗ are partial executions. However, (partial) executions are not necessarily real (partial) executions of the program. The set of real executions of the program, denoted by M , is a subset of S ω , that is, M ⊆ S ω . A property P is also a set of executions, P ⊆ S ω . We say that an execution σ ∈ S ω satisfies the property P if σ ∈ P , and σ violates the property if σ ∈ / P . In the former case we use the notation σ ` P , and the latter case is denoted with σ 0 P . A property P is a safety property if for all executions σ that violate the property there exists a prefix σi (partial execution) such that all the extensions of σi violate the property. Formally, ∀σ ∈ S ω : σ 0 P → (∃i ≥ 0 : ∀β ∈ S ω : σi β 0 P) ,

(1)

where σi is the partial execution composed of the first i states of σ. Some examples of safety properties are the absence of deadlocks and the fulfilment of invariants. On the other hand, a property P is a liveness property if for all the partial executions α there exists at least one extension that satisfies the property, that is, ∀α ∈ S ∗ : ∃β ∈ S ω , αβ ` P .

(2)

One example of liveness property is the absence of starvation. The only property that is a safety and liveness property at the same time is the trivial property P = S ω . It can be proved that any given property can be expressed as an intersection of a safety and a liveness property [3]. The formalism above is based on a linear concept of time. We focus on linear time because this is the usual approach for software verification. However, the branching concept of time is also a popular approach in the literature, focused especially on hardware verification. For both approaches there exist temporal logics associated with them: Linear Temporal Logic (LTL) in the first case and Computation Tree Logic (CTL) in the second one. In the case of LTL, which we use in this chapter, atomic propositions are defined on the base of the variables and program counters of the processes of the system. The property is expressed using an LTL formula composed of the atomic propositions. For example, an LTL property can be p (read “henceforth p”), where p ≡ x > 3. This property specifies

Debugging Concurrent Programs Using Metaheuristics

197

an invariant: for a concurrent system to fulfil this property the variable x must always be greater than 3. This property consists of all the executions σ in which the variable x is greater than 3 for all the states of σ. Other two temporal operators are ♦ (read “eventually”) and U (read “until”). A concurrent system satisfies the formula ♦p if for each execution the atomic proposition p is true in some state (eventually in the future p is true). A concurrent system satisfies the formula p U q if for each execution there exists one state s in which q is true and for each state before s the atomic proposition p is true.

2.2.

Property Automaton and Checking

Checking if a concurrent system M satisfies a given property P is equivalent to check the validity of the following proposition: ∀σ ∈ S ω : σ ∈ M → σ ∈ P ,

(3)

which is equivalent to the following one /P . ¬∃σ ∈ S ω : σ ∈ M ∧ σ ∈

(4)

In explicit state model checking the concurrent system M and the property P are represented by finite state ω-automata, A(M ) and A(P ) respectively, that accept those executions they contain. In the context of ω-automata, an execution is accepting if there is an accepting state that occurs infinitely often in the execution. Using A(M ) and A(P ), the check of Equation (4) is translated to check if the intersection automaton A(M ) ∩ A(P ) accepts no execution. In HSF-SPIN (and SPIN) the automaton A(P ), which captures the violations of the property, is called never claim. When a property P is expressed with an LTL formula ϕ the never claim A(P ) is the same as the automaton A(¬P ) associated to the LTL formula ¬ϕ. This never claim can be automatically computed from ¬ϕ using a translation algorithm [21]. In order to find a violation of a given LTL property, HSF-SPIN explores the intersection (or synchronous product) of the concurrent model and the never claim, A(M ) ∩ A(P ), also called B¨uchi automaton. The intersection automaton is computed on-the-fly as the exploration progresses. One state of the intersection automaton is a pair (s, t) where s is a state of the automaton associated to the concurrent system A(M ) and t is a state of the never claim A(P ). In the intersection automaton, one state (s0, t0 ) is successor of (s, t) if s0 is successor of s in A(M ), t0 is successor of t in A(P ), and the propositional formula in the arc (t, t0) of A(P ) is true when it is evaluated using the values of the variables in the state s. As an illustration, in Fig. 1 we show the automaton of a simple concurrent system (left box), the never claim used to check the LTL formula (p → ♦q) (which means that an occurrence of p is always followed by an occurrence of q, not necessarily in the next state), and the synchronous product of these two automata. HSF-SPIN searches in the B¨uchi automaton for an execution σ = αβ ω composed of a partial execution α ∈ S ∗ and a cycle of states β ∈ S ∗ containing an accepting state. If such an execution is found it violates the liveness component of the property and, thus, the whole property. During the search, it is also possible to find a state in which the end state of the never claim is reached (if any). This means that an execution has been found that

198

Francisco Chicano and Enrique Alba Concurrent system 1 {p} 2

{p} 3

{} {}

Never claim

{p, q} 4

Synchronous product

true

×

1,a

q a

b q!p

=

2,a

1,b 3,a

4,a

2,b

3,b

4,b

Figure 1. Synchronous product of a simple concurrent system and a never claim. violates the safety component of the property and the partial execution α ∈ S ∗ that leads the model to that state violates the property 2 . In HSF-SPIN and SPIN model checkers the search can be done using the Nested Depth First Search algorithm (NDFS) [25]. However, if the property is a safety one (the liveness component is true) the problem of finding a property violation is reduced to find a partial execution α ∈ S ∗, i.e., it is not required to find an additional cycle containing the accepting state. In this case classical graph exploration algorithms such as Breadth First Search (BFS), or Depth First Search (DFS) can be used for finding property violations. These classical algorithms cannot be used when we are searching for general property violations (as we do in this chapter) because they are not designed to find the cycle of states β above mentioned. A special case is that of deadlocks. The absence of deadlock is a safety property, however it cannot be expressed with an LTL formula [19]. Thus, when the objective of a search is to check the absence of deadlocks no never claim is used in HSF-SPIN. Instead, a state with no successors is searched using DFS.

2.3.

Strongly Connected Components

In order to improve the search for property violations it is possible to take into account the structure of the never claim. The idea is based on the fact that a cycle of states in the B¨uchi automaton entails a cycle in the never claim (and in the concurrent system). For an illustration, let us focus again on Fig. 1. The cycle ( 1a, 2a, 4a, 1a) of the B¨uchi automaton is mapped into the cycle (a, a) of the never claim and the cycle (1, 2, 4, 1) of the concurrent system. We can observe, that it is not possible to find a cycle in the B¨uchi automaton in which the letters alternate between a and b because there is no such as cycle in the never claim. For improving the search first we need to compute the strongly connected components (SCCs) of the never claim. A strongly connected subgraph G = (V, A) of a directed graph is a subgraph in which for all pairs of different nodes u, v ∈ V there exist two paths: one from u to v and another one from v to u. The strongly connected components of a directed graph are its maximal strongly connected subgraphs. Once we have the SCCs of the never claim we have to classify them into three categories depending on the accepting cycles they include. By an N-SCC, we denote an SCC in which no cycle is accepting. A P-SCC is an SCC in which there exists at least one accepting cycle and at least one non-accepting cycle. 2

A deeper explanation of the foundations of the automata-based model checking can be found in [15] and [26].

Debugging Concurrent Programs Using Metaheuristics

199

Finally, a F-SCC is an SCC in which all the cycles are accepting [20]. As an illustration we show in Fig. 2 a never claim with three SCCs, one of each kind.

N-SCC a P-SCC

b c

e

F-SCC f

g

d

Figure 2. A never claim with an N-SCC, a P-SCC, and an F-SCC. We omitted the labels associated to the arcs for clarity. As we mentioned above, all the cycles found in the B¨uchi automaton have an associated cycle in the never claim, and, according to the definition of SCC, this cycle is included in one SCC of the never claim. Furthermore, if the cycle is accepting (which is the objective of the search) this SCC is necessarily a P-SCC or an F-SCC. The classification of the SCCs of the never claim can be used to improve the search for property violations. In particular, the accepting states in an N-SCC can be ignored 3, and the cycles found inside an F-SCC can be considered as accepting. In HSF-SPIN, there is an implementation of an improved version of NDFS called Improved Nested Depth First Search (INDFS) that takes into account the classification of the SCCs of the never claim [20].

2.4.

Partial Order Reduction

Partial order reduction (POR) is a method that exploits the commutativity of asynchronous systems in order to reduce the size of the state space. The interleaving model in concurrent systems imposes an arbitrary ordering between concurrent events. When the automaton of the concurrent system is built, the events are interleaved in all possible ways. The ordering between independent concurrent instructions is meaningless. Hence, we can consider just one ordering for checking one given property since the other orderings are equivalent. This fact can be used to construct a reduced state graph hopefully much easier to explore compared to the full state graph (original automaton). We use here a POR proposal based on ample sets [27]. Before giving more details on POR, we need to introduce some terminology. We call a partial function γ : S → S a transition. Intuitively, a transition corresponds to one instruction in the program code of the concurrent model. The set of all the transitions that are defined for state s is denoted with enabled(s). According to these definitions, the set of successors of s must be T (s) = {γ(s)|γ ∈ enabled(s)}. In short, we say that two transitions γ and δ are independent when 3

An accepting state can be part of an N-SCC if the state has no loop and it is the only state of the N-SCC.

200

Francisco Chicano and Enrique Alba

they do not disable one another and executing them in either order results in the same state. That is, for all s if γ, δ ∈ enabled(s) it holds that: 1. γ ∈ enabled(δ(s)) and δ ∈ enabled(γ(s)) 2. γ(δ(s)) = δ(γ(s)) Let L : S → 2AP be a function that labels each state of the system automaton A(M ) with a set of atomic propositions from AP . In the automaton of a concurrent system, this function assigns to each state s the set of propositions appearing in the LTL formula that are true in s. One transition γ is invisible with respect to a set of propositions AP 0 ⊆ AP when its execution from any state does not change the value of the propositional variables in AP 0 , that is, for each state s in which γ is defined, L(s) ∩ AP 0 = L(γ(s)) ∩ AP 0 . The main idea of ample sets is to explore only a subset ample(s) ⊆ enabled(s) of the enabled transitions of each state s such that the reduced state space is equivalent to the full state space. This reduction of the state space is performed on-the-fly while the graph is generated. In order to keep the equivalence between the complete and the reduced automaton, the reduced set of transitions must fulfil the following conditions [15]: • C0: for each state s, ample(s) = ∅ if and only if enabled(s) = ∅. • C1: for each state s and each path in the full state graph that starts at s, a transition γ that is dependent on a transition δ ∈ ample(s) cannot be executed without a transition in ample(s) occurring previously. • C2: for each state s, if enabled(s) 6= ample(s) then each transition γ ∈ ample(s) is invisible with respect to the atomic propositions of the LTL formula being verified. • C3: a cycle is not allowed if it contains a state in which some transition γ is enabled but never included in ample(s) for any state s of the cycle. The first three conditions are not related to the particular search algorithm being used. However, the way of ensuring C3 depends on the search algorithm. In [27] three alternatives for ensuring that C3 is fulfilled were proposed. From them, the only one that can be applied to any possible exploration algorithm is the so-called C3static and this is the one we use in our experiments. In order to fulfil condition C3static , the structure of the processes of the model is statically analyzed and at least one transition on each local cycle is marked as sticky. Condition C3static requires that states s containing a sticky transition in enabled(s) be fully expanded: ample(s) = enabled(s). This condition is also called c2s in a later work by Boˇsnaˇcki et al. [7].

2.5.

Using Heuristic Information

In order to guide the search to the accepting states, a heuristic value is associated to each state of the transition graph of the model. Different kinds of heuristic functions have been defined in the past to better guide exhaustive algorithms. In [23] structural heuristics are introduced that attempt to explore the structure of a program in a way conducive to find errors. One example of this kind of heuristic information is code coverage, a well known

Debugging Concurrent Programs Using Metaheuristics

201

metric in the software testing domain. Another example is thread interleaving, in which states yielding a thread scheduling with many context changes are rewarded. Unlike structural heuristics, property-specific heuristics [23] rely on features of the particular property checked. Formula-based heuristics, for example, are based on the expression of the LTL formula checked [19]. Using the logic expression that must be false in an accepting state, these heuristics estimate the number of transitions required to get such an accepting state from the current one. Given a logic formula ϕ, the heuristic function for that formula Hϕ is defined using its subformulae. In this work we use a formula-based heuristic shown in Table 1 that is defined in [19]. Table 1. Formula-based heuristic function ϕ true f alse p a⊗b ¬ψ ψ∨ξ ψ∧ξ f ull(q) empty(q) 2*q?[t]

Hϕ (s) H ϕ (s) 0 ∞ ∞ 0 if p then 0 else 1 if p then 1 else 0 if a ⊗ b then 0 else 1 if a ⊗ b then 1 else 0 H ψ (s) Hψ (s) min{Hψ (s), Hξ (s)} H ψ (s) + H ξ (s) Hψ (s) + Hξ (s) min{H ψ (s), H ξ (s)} capa(q) − len(q) if f ull(q) then 1 else 0 len(q) if empty(q) then 1 else 0 minimal prefix of q if head(q) 6= t then 0 else without t maximal prefix of t’s i@s Di (pci , s) if pci = s then 1 else 0 ψ, ξ: formulae without temporal operators p: logic proposition a, b: variables or constants ⊗: relational operator (=, 6=, <, ≤, ≥, >) q: queue capa(q): capacity of queue q len(q): length of queue q head(q): message in the head of queue q t: tag of a message i: process s: state of a process automaton pci : current state of process i in its corresponding automaton Di (u, v): minimum number of transitions for reaching v from u in the local automaton of process i Hϕ (s): Heuristic function for formula ϕ. H ϕ (s): Heuristic function for formula ¬ϕ.

For searching for deadlocks several heuristic functions can be used. On the one hand, the number of active processes can be used as heuristic value of a state. We denote this heuristic as Hap. On the other hand, the number of executable (enabled) transitions in a state can also be used as heuristic value, denoted with Hex . Another option consists in approximating the deadlock situation with a logic predicate and deriving the heuristic function of that predicate using the rules of Table 1 (see [19]). There is another group of heuristic functions called state-based heuristics that can be used when the objective state is known. From this group we can highlight the Hamming distance Hham and the distance of finite state machines Hf sm . In the first case, the heuristic value is computed as the Hamming distance between the binary representations of the current and the objective state. In the latter, the heuristic value is the sum of the minimum

202

Francisco Chicano and Enrique Alba

number of transitions required to reach the objective state from the current one in the local automaton of each process. We will explain this in more detail. Each process of the concurrent system has an associated local automaton. Given one state of the complete system, each process is in one state of its associated automaton. Before the execution of any search algorithm, the minimum number of transitions required to reach one state from another one is computed for each pair of states in each local automaton. With this information the Hf sm heuristic function consults for each process the minimum number of transitions to reach the objective state from the current state in the local automaton. The value returned by Hf sm is the sum of all these minimum transitions for all the processes.

3.

Problem Formalization

In this chapter we tackle the problem of searching for general property violations in concurrent systems. As we previously mentioned, this problem can be translated into the search of a path4 in a graph (the B¨uchi automaton) starting in the initial state and ending in an objective node (accepting state) and an additional cycle involving the objective node; or a path that leads to the end state of the never claim or to a deadlock state (if the property checked is the absence of deadlocks). We formalize here the problem as follows. Let G = (S, T ) be a directed graph where S is the set of nodes and T ⊆ S × S is the set of arcs. Let q ∈ S be the initial node of the graph, F ⊆ S a set of distinguished nodes that we call accepting nodes, and E ⊆ S a set of nodes that we call end nodes. We denote with T (s) the set of successors of node s. A finite path over the graph is a sequence of nodes π = π1 π2 . . . πn where πi ∈ S for i = 1, 2, . . . , n and πi ∈ T (πi−1 ) for i = 2, . . ., n. We denote with πi the ith node of the sequence and we use |π| to refer to the length of the path, that is, the number of nodes of π. We say that a path π is a starting path if the first node of the path is the initial node of the graph, that is, π1 = q. We will use π∗ to refer to the last node of the sequence π, that is, π∗ = π|π| . We say that a path π is a cycle if the first and the last nodes of the path are the same, that is, π1 = π∗ . Given a directed graph G, the problem at hand consists in finding a starting path π (π1 = q) for which one of the following propositions holds: • π ends in an accepting node and there exists a cycle ν containing the accepting node. That is, π∗ ∈ F ∧ π∗ = ν1 = ν∗ . • π ends in an end node. That is, π∗ ∈ E. The graph G used in the problem is derived from the B¨uchi automaton B (synchronous product of the concurrent system and the never claim, if any). The set of nodes S in G is the set of states in B, the set of arcs T in G is the set of transitions in B, the initial node q in G is the initial state in B, the set of accepting nodes F in G is the set of accepting states in B, and the set of end nodes E in G is the set of nodes that map into end states of the 4

We use here the traditional meaning of path. That is, a path is an alternating sequence of vertices and arcs, beginning and ending with a vertex, in which each vertex is incident to the two arcs that precede and follow it in the sequence, and the vertices that precede and follow an arc are the end vertices of that arc. We use in this chapter the word path instead of the nowadays widely used term walk with the above indicated meaning.

Debugging Concurrent Programs Using Metaheuristics

203

never claim associated to B. In the following, we will also use the words state, transition, accepting state, and end state to refer to the elements in S, T , F , and E, respectively. If the property to check is the absence of deadlocks, G is equal to B, F is empty, and E is the set of deadlock states.

4.

Algorithmic Proposal

In order to solve the previously defined problem we propose here an algorithm that we call ACOhg-mc. This algorithm is based on ACOhg, a new variant of ACO that has been applied to the search for safety errors in concurrent systems [2]. We describe ACOhg in the next section and ACOhg-mc in Section 4.2.. Finally, we describe how the improvement based on SCCs is applied to ACOhg-mc.

4.1.

ACOhg Algorithm

ACOhg is a new kind of Ant Colony Optimization algorithm proposed in [2] that can deal with construction graphs of unknown size or too large to fit into the computer memory. Actually, this new model was proposed for applying an ACO-like algorithm to the problem of searching for safety property violations in very large concurrent systems, however it is general enough to deal with other problems with similar features. In this section we give a general description of ACOhg that is independent on the problem solved and we specify the problem-dependent elements of ACOhg for our problem in the next section. The objective of ACOhg is to find a path from the initial node to one objective node from a set O in a very large exploration graph. We denote with f a function that maps the paths of the graph into real numbers. This function must be designed to reach minimum values when the shortest path to an objective node is found. ACOhg minimizes this objective function. ACO metaheuristic [17] is a global optimization algorithm inspired by the foraging behaviour of real ants. The main idea consists in simulating the ants behaviour in a graph, called construction graph, in order to search for the shortest path from an initial node to an objective one. The cooperation among the different simulated ants is a key factor in the search that is performed indirectly by means of pheromone trails, which is a model of the chemicals real ants use for their communication. The main procedures of an ACO algorithm are the construction phase and the pheromone update. These two procedures are scheduled during the execution of ACO until a given stopping criterion is fulfilled. In the construction phase, each artificial ant follows a path in the construction graph. In the pheromone update, the pheromone trails of the arcs are modified. In [2] two techniques were proposed for dealing with huge graphs when ACOhg is used: the expansion and the missionary technique. In this chapter we focus on the missionary technique because it requires less memory and the quality of the results is similar using both techniques (see [1]). Thus, in the following we will describe ACOhg using the missionary technique, however we will use the name ACOhg alone. In short, the two main differences between ACOhg and the traditional ACO variants are the following ones. First, the length of the paths traversed by ants (the number of arcs in the path) in the construction phase is limited. That is, when the path of an ant reaches a given maximum length λant the ant is stopped. Second, the ants start the path construction

204

Francisco Chicano and Enrique Alba

from different nodes during the search. At the beginning, the ants are placed on the initial node of the graph, and the algorithm is executed during a given number of steps σs (called stage). If no objective node is found, the last nodes of the best paths constructed by the ants are used as starting nodes for the ants in the next stage. In this way, during the next stage the ants try to go further in the graph (see [2] for more details). In Algorithm 1 we show the pseudocode of ACOhg. ACOhg [1] init = {initial node}; next init = ∅; τ = initializePheromone(); step = 1; stage = 1; step ≤ msteps [Ant operations]k=1 to colsize ak = ∅; ak1 = selectInitNodeRan/ O node = selectSuccessor (ak∗ , domly (init); |ak | < λant ∧ T (ak∗ ) − ak 6= ∅ ∧ ak∗ ∈ k k k T (a∗ ), τ ,η); a = a + node; τ = localPheromoneUpdate(τ ,ξ,node); next init = selectBestPaths(init, next init, ak ); f (ak ) < f (abest ) abest = ak ; τ = pheromoneEvaporation(τ , ρ); τ = pheromoneUpdate(τ , abest ); step ≡ 0 mod σs init = next init; next init = ∅; stage = stage+1; τ = pheromoneReset(); step = step + 1; P|init| selectInitNodeRandomly (init) [1] r=uniformRandom(0,1) * i=1 1/f (init[i]) i=1 to |init| p=p+1/f (init[i]) r ≤ p init[i] ∗ [!ht] selectBestPaths (init, next init, ak ) [1] ak∗ is not the last state of any starting path of init |next init| < ι π is the only starting path of init that holds π∗ = ak1 next init ∪{π + ak } w=argmaxf (next init) f (ak ) < f (w) π is the only starting path of init that holds π∗ = ak1 (next init - {w}) ∪{π + ak } next init next init In the following we will describe the algorithm, but previously we are going to clarify some issues related to the notation used in Algorithm 1. In the pseudocode, the path traversed by the kth artificial ant is denoted with ak . For this reason we use the same notation as in Section 3. for referring to the length of the path ( |ak |), the jth node of the path (akj ), and the last node of the path (ak∗ ). We use the operator + to refer to the concatenation of two paths. In line 10, we use the expression T (ak∗ ) − ak to refer to the elements of T (ak∗ ) that are not in the sequence ak . That is, in that expression we interpret ak as a set of nodes. The algorithm works as follows. At the beginning, the variables are initialized (lines 15). All the pheromone trails are initialized with the same value: a random number between τ0min and τ0max . In the init set (initial nodes for the ants construction), a starting path with only the initial node is inserted (line 1). This way, all the ants of the first stage begin the construction of their path at the initial node. After the initialization, the algorithm enters in a loop that is executed until a given maximum number of steps (msteps) set by the user is performed (line 6). In a loop, each ant builds a path starting in the final node of a previous path (line 9). This path is randomly selected from the init set using the procedure shown in Algorithm 2. For the construction of the path, the ants enter a loop (lines 10-14) in which each ant k stochastically selects the next node according to the pheromone (τij ) and the heuristic value (ηij ) associated to each arc (ak∗ , j) with j ∈ T (ak∗ ) (line 11). In particular, if the last node of the kth ant path is i = ak∗ , then the ant selects the next node j ∈ T (i) with probability [17] [τij ]α[ηij ]β , for j ∈ T (i) , α β s∈T (i)[τis ] [ηis ]

pkij = P

(5)

where α and β are two parameters of the algorithm determining the relative influence of the pheromone trail and the heuristic value on the path construction, respectively (see Figure 3).

Debugging Concurrent Programs Using Metaheuristics

205

According to the previous expression, artificial ants prefer paths with a higher concentration of pheromone, like real ants in real world. When an ant has to select a node, the last node of the current ant path is expanded. Then the ant selects one successor node and the remaining ones are removed from memory. This way, the amount of memory required in the path construction is small. The heuristic value ηij of an arc is a problem specific value determined by the designer in order to guide the search to promising regions of the graph.

Pheromone Trail

IJij

k

Heuristic

i

Șij

T(i) n

j m l

Figure 3. An ant during the construction phase. After the movement of an ant from a node to the next one the pheromone trail associated to the arc traversed is updated as in Ant Colony Systems (ACS) [16] using the expression τij ← (1 − ξ)τij (line 13) where ξ, with 0 < ξ < 1, controls the evaporation of the pheromone during the construction phase. This mechanism increases the exploration of the algorithm, since it reduces the probability that an ant follows the path of a previous ant in the same step. The construction process is iterated until the ant reaches the maximum length λant, it finds an objective node, or all the successors of the last node of the current path, T (ak∗ ), have been visited by the ant during the construction phase. This last condition prevents the ants from constructing cycles in their paths. After the construction phase, the ant is used to update the next init set (line 15), which will be the init set in the next stage. In next init, only starting paths are allowed and all the paths must have different last nodes. This rule is ensured by selectBestPaths shown in Algorithm 3, which proceeds as it is explained in the following lines. A path ak is inserted in the next init set if its last node is not one of the last nodes of a starting path π already included in the set. Before the inclusion, the path must be concatenated with the corresponding starting path of init, that is, the starting path π with π∗ = ak1 (this path exists and it is unique). This way, only starting paths are stored in the next init set. The cardinality of next init is bounded by a given parameter ι. When this limit is reached and a new path must be included in the set, the starting path with higher objective value is removed from the set.

206

Francisco Chicano and Enrique Alba

When all the ants have built their paths, a pheromone update phase is performed. First, all the pheromone trails are reduced according to the expression τij ← (1 − ρ)τij (line 20), where ρ is the pheromone evaporation rate and it holds that 0 < ρ ≤ 1. Then, the pheromone trails associated to the arcs traversed by the best-so-far ant ( abest ) are increased using the expression τij ← τij + 1/f (abest ), ∀(i, j) ∈ abest (line 21). This way, the best path found is awarded with an extra amount of pheromone and the ants will follow that path with higher probability in the next step, as in real world. We use here the mechanism introduced in Max-Min Ant Systems (MMAS) [34] for keeping the value of pheromone trails in a given interval [τmin , τmax] in order to maintain the probability of selecting one node above a given threshold. The values of the trail limits are τmax = 1/ρf (abest) and τmin = τmax /a where the parameter a controls the size of the interval. Finally, with a frequency of σs steps, a new stage starts. The init set is replaced by next init and all the pheromone trails are removed from memory (lines 22-27). In addition to the pheromone trails, the arcs to which the removed pheromone trails are associated are also discarded (unless they also belong to a path in next init). This removing step allows the algorithm to reduce the amount of memory required to a minimum value. This minimum amount of memory is the one utilized for storing the best paths found in one stage (the next init set).

4.2.

ACOhg-mc

In this section we present ACOhg-mc, an algorithm based on ACOhg for searching for general property violations in concurrent systems. In Algorithm 4 we show a high level object oriented pseudocode of ACOhg-mc. We assume that acohg1 and acohg2 are two instances of a class implementing ACOhg. In order to complete the description of the algorithm we need to specify the objective function, the heuristic values, and the objective nodes used in acohg1 and acohg2. We will do this later in this section, but before we will give a high level description of ACOhg-mc. The search that ACOhg-mc performs is composed of two different phases (see Fig. 4). In the first one, ACOhg is used for finding accepting states in the B¨uchi automaton (line 2 in Algorithm 4). In this phase, the search of ACOhg starts in the initial node of the graph q and the set of objective nodes O is empty. That is, although the algorithm searches for accepting states, there is no preference on a specific set of them. If the algorithm finds accepting states, in a second phase a new search is performed using ACOhg again for each accepting state discovered (lines 3 to 8). In this second search the objective is to find a cycle involving the accepting state. The search starts in one accepting state and the algorithm searches for the same state in order to find a cycle. That is, the initial node of the search and the only objective node are the same: the accepting state. If a cycle is found ACOhg-mc returns the complete accepting path (line 6). If no cycle is found for any of the accepting states ACOhg-mc runs again the first phase after including the accepting states in a tabu list (line 9). This tabu list prevents the algorithm from searching again cycles containing the just explored accepting states. If one of the accepting states in the tabu list is reached it will not be included in the list of accepting states to be explored in the second phase. ACOhg-mc alternates between the two phases until no accepting state is found in the first one (line 10).

Debugging Concurrent Programs Using Metaheuristics

207

[!ht] ACOhg-mc [1] accpt = acohg1.findAcceptingStates(); First phase node in accpt acohg2.findCycle(node); Second phase acohg2.cycleFound() acohg2.acceptingPath(); acohg1.insertTabu(accpt); empty(accpt) null;

First phase

Second phase

Figure 4. An illustration of the search that ACOhg-mc performs in the first and second phase.

The algorithm can also stop its search due to another reason: an end state has been found. That is, when an end state is found either in the first or the second phase of the search the algorithm stops and returns the path from the initial state to that end state. If this happens, an execution of the concurrent system has been found that violates the safety component of the checked property. When the property to check is the absence of deadlocks only the first phase of the search is required. In this case, ACOhg-mc searches for deadlock states (states with no successors) instead of accepting states. When a deadlock state is found the algorithm stops returning the path from the initial state to that deadlock state. The second phase of the search, the objective of which is to find an accepting cycle, is never run in this situation. Now we are going to give the details of the ACOhg algorithms used inside ACOhg-mc. First of all, we use in this chapter a node-based pheromone model, that is, the pheromone trails are associated to the nodes instead of the arcs. This means that all the values τxj associated to the arcs which head is node j are in fact the same value and is associated to node j. At this moment we must talk about the two heuristic functions presented before: η and H. The heuristic function η depends on each arc of the construction graph and it is defined in the context of ACO algorithms. It is a non-negative function used by ACO algorithms for guiding the search. The higher the value of ηij , the higher the probability of selecting arc (i, j) during the construction phase of the ants. The second heuristic, H, depends on each state of the B¨uchi automaton and it is defined in the context of the problem (heuristic model checking). We use here the notation H to refer to a general heuristic function but in practice this function will be one of the functions defined in Section 2.5. (e.g. Hf sm or Hϕ ). This heuristic H is a non-negative function designed to be minimized, that is, the lower the value of H(j), the higher the preference to explore node j. In our proposal we must derive η from H. The exact expression we use is ηij = 1/(1 + H(j)). This way, ηij increases when H(j) decreases (high preference to explore node j).

208

Francisco Chicano and Enrique Alba Finally, the objective function f to be minimized is defined as ( |π + ak | if ak∗ ∈ O k f (a ) = −|ak | λ if ak∗ ∈ /O , |π + ak | + H(ak∗ ) + pp + pc λant ant −1

(6)

where π is the starting path in init whose last node is the first one of ak , pp , and pc are penalty values that are added when the ant does not end in an objective node and when ak contains a cycle, respectively. The last term in the second row of Eq. (6) makes the penalty higher in shorter cycles (see [9] for more details). The configuration of the ACOhg algorithms executed inside ACOhg-mc is, in general, different in the two phases, since they tackle different objectives. We highlight this fact by using different variables for referring to both algorithms in Algorithm 4: acohg1 and acohg2. For example, in the first phase (acohg1) a more exploratory search is required in order to find a diverse set of accepting states. In addition, the accepting states are not known and no state-based heuristic can be used; a formula-based heuristic or a deadlock heuristic must be used instead. On the other hand, in the second phase ( acohg2) the search must be guided to search for one concrete state and, in this case, a state-based heuristic like the Hamming distance or the finite state machines distance is more suitable.

4.3.

Improvement Using SCCs

When we are searching for an execution that violates an LTL property we can make the search more efficient if we take into account the classification of the never claim SCCs. The improvements are localized in two places of ACOhg-mc. During the first phase, in which accepting states are searched for, those accepting states that belong to an N-SCC in the never claim are ignored. The reason is that an accepting state in an N-SCC cannot be part of an accepting cycle. This way, we reduce the number of accepting states to be explored in the second phase. The second improvement is localized in the computation of the successors of a state (line 10 in Algorithm 1) in both, the first and the second phase of ACOhg-mc. When the successors are computed, ACOhg checks if they are included in the path that the ant has traversed up to the moment. If they are, the state is not considered as the next node to visit since the ant would build a cycle. The improvement consists in checking if this cycle is in an F-SCC. This can be easily checked by finding if the state that closes the cycle is in an F-SCC of the never claim. If it is, then an accepting cycle has been found and the global search stops. The advantages of these improvements depend on the structure of the LTL formula and the model to check. We can notice no advantages in some cases, especially when the number of N-SCC and F-SCC is small. However, the computational cost of the improvements is negligible, since it is possible to check the kind of SCC associated to a state in constant time.

5.

Experiments

In this section we present some results obtained with our ACOhg-mc algorithm. For the experiments we have selected ten models from the BEEM benchmark [31] that are

Debugging Concurrent Programs Using Metaheuristics

209

presented in the following section. After that, we discuss the parameters of the algorithm used in the experiments in Section 5.2.. In Section 5.3. we compare the results obtained with ACOhg-mc against NDFS and INDFS. Next, in Section 5.4. we study the influence on the results of the partial order reduction technique.

5.1.

Promela Models

BEEM (BEnchmarks for Explicit Model checking) is a benchmark of models by Radek Pel´anek [31] that can be found at http://anna.fi.muni.cz/models. The benchmark includes more than 50 parameterized models (a total of 300 concrete models) together with their correctness properties. The main goal of BEEM is to serve as a standard used for the comparison of different model checking algorithms. In order to perform high quality experimental evaluation, researchers need tools in which they can implement model checking techniques (such as HSF-SPIN, which we use) and benchmark sets of models which can be used for comparisons (this is the contribution of BEEM). The models of BEEM are specified in DVE language [30] (the language used in the DiVinE model checker) but Promela versions of some models can be found in the benchmark. These Promela specifications were automatically generated from the DVE models. This translation keeps the semantic of the models but, as it is said in the BEEM web site, the state space is not exactly the same as in the DVE models. We have selected 10 out of the 300 concrete models of the benchmark. For this selection we have considered only those models for which the complete state space has not been explored due to memory constraints (this information is available in the web site). We proceed in this way because ACOhg-mc has been designed to work in large models in which an exhaustive search is not applicable due to the large amount of required memory. There are 49 models in which the state space exploration is incomplete and we have selected 10 out of these models. All these models violate a property. In Table 2 we present the models with some information about them: lines of code, number of processes, the kind of property violated, and the abbreviation we will use below. Table 2. Promela models used in the experiments (from the BEEM benchmark). Model driving phils.5 iprotocol.7 leader filters.6 peterson.7 public subscribe.5 train-gate.7 elevator.5 firewire link.6 schedule world.3 phils.8

Abbrv. dri ipr lea pet pub tra ele fir sch phi

LoC 142 188 222 155 618 307 277 1229 125 323

Processes 4 6 5 5 11 11 7 11 1 16

Property ♦p ((♦p) ∧ (♦q)) → (♦t) ♦p (!p → ♦q) (p → ♦(q ∨ t) (p → ♦q) (p → ♦q) deadlock deadlock deadlock

The first model, driving phils.5, is composed of several processes access-

210

Francisco Chicano and Enrique Alba

ing several resources. iprotocol.7 is an optimized sliding window protocol. leader filters.6 is a leader election algorithm based on filters. The forth model, peterson.7 is the Peterson’s mutual exclusion algorithm for more than two processes (five in this case). public subscribe.5 is a publish/subscribe notification protocol. train-gate.7 is a simple controller of a train gate. elevator.5 is an elevator controller for a building with six floors. firewire link.6 is the link layer protocol of the IEEE-1394 standard. schedule world.3 is a scheduler for machines. Finally, phils.8 is a model of the Dijkstra dining philosophers problem with 16 philosophers.

5.2.

Configuration of the Experiments

The parameters used in the experiments for ACOhg-mc in the two phases are shown in Table 3. These parameters have been selected according to the recommendations in [1]. As mentioned in Section 4., in the first phase we use an explorative configuration ( ξ = 0.7, λant = 40) while in the second phase the configuration is adjusted to search in the region near the accepting state found (intensification). It is possible that these parameters can be tuned in order to improve the efficiency and the efficacy of the search. However, this tuning requires time and we must take into account this time when the algorithm has to be applied, especially if we want to compare it against parameter-free algorithms like NDFS or INDFS. In this work, we do not tune the parameters of the algorithm; we just run the algorithm with the parameters recommended in the literature for ACOhg. This way the tuning time is zero. Table 3. Parameters for ACOhg-mc First phase Parameter Value msteps 100 colsize 10 λant 40 σs 4 ι 10 ξ 0.7 a 5 ρ 0.2 τ0min 0.1 max τ0 10.0 τmax 1/ρf (abest ) τmin τmax /a α 1.0 β 2.0 pp 1000 pc 1000

Second phase Parameter Value msteps 100 colsize 20 λant 4 σs 4 ι 10 ξ 0.5 a 5 ρ 0.2 τ0min 0.1 max τ0 10.0 τmax 1/ρf (abest ) τmin τmax /a α 1.0 β 2.0 pp 1000 pc 1000

With respect to the heuristic information, we use Hϕ (the formula-based heuristic) in the first phase of the search when the objective is to find accepting states and Hap when the ob-

Debugging Concurrent Programs Using Metaheuristics

211

jective is to find a deadlock state. In the second phase we use the distance of finite state machines Hf sm . ACOhg-mc has been implemented inside the HSF-SPIN model checker [18]. In this way, we can use the HSF-SPIN implementation of the heuristic functions above mentioned and, at the same time, all the existing work related to parsing Promela models and interpreting them. We need to perform several independent runs in order to get quantitative information of the behaviour of the algorithm. We perform 100 independent runs of ACOhg-mc to get a high statistical confidence, and we report the mean and the standard deviation of the independent runs. The machine used in the experiments is a Pentium IV at 2.8 GHz with 512 MB of RAM and Linux operative system with kernel version 2.4.19-4GB. In all the experiments the maximum memory assigned to the algorithms is 512 MB: when a process exceeds this memory it is automatically stopped. We do this in order to avoid a high amount of data flow from/to the secondary memory, which could affect significantly the CPU time required in the search.

5.3.

Comparison against Exhaustive Techniques

In this first experiment we compare the results obtained with ACOhg-mc against a classical algorithm used for finding errors in concurrent systems, NDFS, and an improved version of NDFS that takes into account the SCCs of the never claim, INDFS. Both algorithms are deterministic and for this reason we only perform one single run of them. For the models in which the objective is to find a deadlock we only use NDFS, since there is no never claim in order to take advantage of the SCC improvement as INDFS does. In Table 4 we show the hit rate, the length of the error trails, the memory required (in Kilobytes), and the run time (in milliseconds) of the three algorithms. For ACOhg-mc we show the average and the standard deviation of the results obtained in the 100 independent runs. We highlight with a grey background the best results (maximum values for hit rate and minimum values for the rest of the measures). We also show the results of a statistical test (with level of significance α = 0.05) in order to check if there exist statistically significant differences between ACOhg-mc and the exhaustive algorithms. A plus sign means that the difference is significant and a minus sign means that it is not. In the case of the hit rate we use a Westlake-Schuirmann test of equivalence of two independent proportions, for the rest of the measures we use the one sample Wilcoxon sign rank test because we compare one sample (the results of ACOhg-mc) with one single value (the results of NDFS and INDFS). [33]. Concerning the hit rate we can observe that ACOhg-mc is the only one that is able to find error paths in dri, lea, and phi. NDFS and INDFS are not able to find error paths in these models because they require more memory than the available one. This is a relevant result since NDFS is a very popular algorithm in the formal methods community for checking properties using an explicit state model checker. If we focus on the remaining models we observe that ACOhg-mc fails to find an error path in ipr (while NDFS and INDFS are able to find one) and its hit rate in the tra is 97%. In general, the algorithm with higher total hit rate is ACOhg-mc. With respect to the length of the error paths we observe that ACOhg-mc obtains shorter error paths than NDFS and INDFS with statistical significance. The only exceptions are

212

Francisco Chicano and Enrique Alba Table 4. Comparison of ACOhg-mc, NDFS, and INDFS 2*Models 5*dri

5*ipr

5*lea

5*pet

5*pub

5*tra

5*ele

5*fir

5*sch

5*phi

2*Measures Hit rate Length Mem. (KB) CPU (ms) Hit rate Length Mem. (KB) CPU (ms) Hit rate Length Mem. (KB) CPU (ms) Hit rate Length Mem. (KB) CPU (ms) Hit rate Length Mem. (KB) CPU (ms) Hit rate Length Mem. (KB) CPU (ms) Hit rate Length Mem. (KB) CPU (ms)

ACOhg-mc Avg. Std. gris 100/100 gris gris 37.10 gris 1.45 gris 1967.04 gris 19.16 gris 1307.80 gris 379.64 0/100 • • • • • • gris 100/100 gris gris 21.30 gris 1.45 gris 2057.28 gris 16.32 gris 8255.90 gris 743.28 gris 100/100 gris gris 113.28 gris 70.82 2401.96 70.27 52686.00 76471.00 gris 100/100 gris gris 62.65 gris 59.52 gris 2744.84 gris 110.38 2029.40 685.59 97/100 gris 11.26 gris 2.68 gris 1986.53 gris 12.55 71.24 20.97 gris 100/100 gris gris 10.11 gris 7.95 gris 2513.32 gris 313.04 5882.10 7527.91

Hit rate Length Mem. (KB) CPU (ms) Hit rate Length Mem. (KB) CPU (ms) Hit rate Length Mem. (KB) CPU (ms)

gris 100/100 30.18 2077.00 9.10 gris 100/100 8.90 2376.52 67.90 gris 100/100 gris 28.96 gris 2483.92 gris 138.00

gris 6.88 0.00 3.49 gris 3.67 338.07 47.84 gris gris 7.88 gris 221.83 gris 140.25

NDFS Result 0/1 • • • gris 1/1 2657.00 104448.00 17470.00 0/1 • • • gris 1/1 9996.00 6577.00 60.00 gris 1/1 2101.00 5105.00 60.00 gris 1/1 131.00 2137.00 gris 10.00 gris 1/1 5553.00 53248.00 gris 610.00 gris 1/1 gris 22.00 gris 1885.00 gris 0.00 gris 1/1 gris 6.00 gris 1753.00 gris 0.00 0/1 • • •

Test + • • • + • • • + • • • − + + + − + + + + + + + − + + +

INDFS Result Test 0/1 + • • • • • • gris 1/1 + 2657.00 • 104448.00 • 17430.00 • 0/1 + • • • • • • gris 1/1 − 124.00 + gris 1889.00 + gris 10.00 + gris 1/1 − 2053.00 + 4981.00 + gris 50.00 + gris 1/1 + 131.00 + 2133.00 + 20.00 + gris 1/1 − 5553.00 + 53248.00 + 630.00 +

− + + + − + + + + • • •

n/ap. n/ap. n/ap. n/ap. n/ap. n/ap. n/ap. n/ap. n/ap. n/ap. n/ap. n/ap.

n/ap. n/ap. n/ap. n/ap. n/ap. n/ap. n/ap. n/ap. n/ap. n/ap. n/ap. n/ap.

that of fir and sch. The largest differences are that of ele (around 500 times shorter) and pet (around 100 times shorter). Furthermore, we limited the exploration depth of NDFS and INDFS to 10,000 in order to avoid stack overflow problems. If we allowed these algorithms to explore deeper regions we would obtain longer error paths with them. In fact, we ran NDFS using a depth limit of 50,000 in pet and we got an error path of 50,000 states. This means that the length of the error path that is shown in Table 4 for NDFS in pet is in fact a lower bound of the real length that NDFS would obtain in theory. In general, ACOhg-mc obtains error paths that are shorter (with a large difference in some cases) than the ones obtained with NDFS and INDFS. This is a very important result since short error paths are preferred because they enable the programmers to find out faster what is wrong in the concurrent system.

Debugging Concurrent Programs Using Metaheuristics

213

INDFS). [33]. Table 4. Comparison of ACOhg-mc, NDFS, and INDFS Models

dri

ipr

lea

pet

pub

tra

ele

fir

sch

phi

Measures Hit rate Length Mem. (KB) CPU (ms) Hit rate Length Mem. (KB) CPU (ms) Hit rate Length Mem. (KB) CPU (ms) Hit rate Length Mem. (KB) CPU (ms) Hit rate Length Mem. (KB) CPU (ms) Hit rate Length Mem. (KB) CPU (ms) Hit rate Length Mem. (KB) CPU (ms) Hit rate Length Mem. (KB) CPU (ms) Hit rate Length Mem. (KB) CPU (ms) Hit rate Length Mem. (KB) CPU (ms)

ACOhg-mc Avg. Std. 100/100 37.10 1.45 1967.04 19.16 1307.80 379.64 0/100 • • • • • • 100/100 21.30 1.45 2057.28 16.32 8255.90 743.28 100/100 113.28 70.82 2401.96 70.27 52686.00 76471.00 100/100 62.65 59.52 2744.84 110.38 2029.40 685.59 97/100 11.26 2.68 1986.53 12.55 71.24 20.97 100/100 10.11 7.95 2513.32 313.04 5882.10 7527.91 100/100 30.18 2077.00 9.10 100/100 8.90 2376.52 67.90 100/100 28.96 2483.92 138.00

6.88 0.00 3.49 3.67 338.07 47.84 7.88 221.83 140.25

NDFS Result Test 0/1 + • • • • • • 1/1 + 2657.00 • 104448.00 • 17470.00 • 0/1 + • • • • • • 1/1 − 9996.00 + 6577.00 + 60.00 + 1/1 − 2101.00 + 5105.00 + 60.00 + 1/1 + 131.00 + 2137.00 + 10.00 + 1/1 − 5553.00 + 53248.00 + 610.00 + 1/1 22.00 1885.00 0.00 1/1 6.00 1753.00 0.00 0/1 • • •

− + + + − + + + + • • •

INDFS Result 0/1 • • • 1/1 2657.00 104448.00 17430.00 0/1 • • • 1/1 124.00 1889.00 10.00 1/1 2053.00 4981.00 50.00 1/1 131.00 2133.00 20.00 1/1 5553.00 53248.00 630.00 n/ap. n/ap. n/ap. n/ap. n/ap. n/ap. n/ap. n/ap. n/ap. n/ap. n/ap. n/ap.

Test + • • • + • • • + • • • − + + + − + + + + + + + − + + + n/ap. n/ap. n/ap. n/ap. n/ap. n/ap. n/ap. n/ap. n/ap. n/ap. n/ap. n/ap.

Concerning the hit rate we can observe that ACOhg-mc is the only one that is able to find error paths in dri, lea, and phi. NDFS and INDFS are not able to find error paths in these models because they require more memory than the available one. This is a relevant result since NDFS is a very popular algorithm in the formal methods community for checking properties using an explicit state model checker. If we focus on the remaining models we observe that ACOhg-mc fails to find an error path in ipr (while NDFS and INDFS are able to find one) and its hit rate in the tra is 97%. In general, the algorithm with higher total hit rate is ACOhg-mc. With respect to the length of the error paths we observe that ACOhg-mc obtains shorter error paths than NDFS and INDFS with statistical significance. The only exceptions are

214

Francisco Chicano and Enrique Alba

that of fir and sch. The largest differences are that of ele (around 500 times shorter) and pet (around 100 times shorter). Furthermore, we limited the exploration depth of NDFS and INDFS to 10,000 in order to avoid stack overflow problems. If we allowed these algorithms to explore deeper regions we would obtain longer error paths with them. In fact, we ran NDFS using a depth limit of 50,000 in pet and we got an error path of 50,000 states. This means that the length of the error path that is shown in Table 4 for NDFS in pet is in fact a lower bound of the real length that NDFS would obtain in theory. In general, ACOhg-mc obtains error paths that are shorter (with a large difference in some cases) than the ones obtained with NDFS and INDFS. This is a very important result since short error paths are preferred because they enable the programmers to find out faster what is wrong in the concurrent system. If we focus on the computational resources we observe that ACOhg-mc requires between 2 MB and 3 MB of memory in all the models (the maximum is 2.7 MB in pub). This behaviour contrasts with NDFS and INDFS, in which the memory required is highly dependent on the model being checked. In some cases the available memory is not enough for completing the search as it happens in dri, lea, and phi. We must clarify here two issues. First, the failure of ACOhg-mc in ipr is not due to memory constraints (the memory required in ipr was 1953 KB) but to its stochastic nature. Second, NDFS and INDFS do not permanently store the visited states in memory (as other algorithms like Breadth First Search or A∗ do), they only store the states belonging to a branch of the search as they are needed. In fact, a usual property of DFS-like algorithms is that they require a low amount of memory but they obtain a long path to the objective state. In Table 4 we can see that our ACOhg-mc can outperform the memory requirements of both NDFS and INDFS. With respect to the time required for the search, NDFS and INDFS are faster than ACOhg-mc in all the models in which they find an error. The mechanisms included in ACOhg-mc in order to be able to find short error paths with high hit rate and low amount of memory extend the time required for the search. The maximum difference with respect to the time is around 50 seconds (in pet), which is not large from the tester point of view if we take into account that the error path obtained is much shorter (one hundred times). In summary, ACOhg-mc is able to find shorter error paths than NDFS and INDFS using less memory. Furthermore, the results shown in this section suggest that ACOhg-mc is more effective than NDFS and INDFS (higher hit rate). However, in order to clearly support this last claim more experimentation is required.

5.4.

ACOhg-mc and Partial Order Reduction

In our second experiment we want to analyze the influence of the POR technique on the results of ACOhg-mc. In [9] the POR technique was used in combination with ACOhg in order to find safety property violations in concurrent systems. The results showed that the combination is beneficial for the search. The results of this section extend those of [9] in two ways. First, here we use POR in general properties (not only safety properties). Second, we do not know the structure of the selected models of BEEM and, thus, we do not know if their state spaces can be reduced or not. In Table 5 we present the results of applying ACOhg-mc with and without the POR technique to the selected BEEM models (we have omitted here ipr because it is not relevant for the discussion). The information reported is

Debugging Concurrent Programs Using Metaheuristics

215

the same as in the previous section. We also show the results of a statistical test (with level of significance α = 0.05) in order to check if there exist statistically significant differences (last column). A plus sign means that the difference is significant and a minus sign means that it is not. In the case of the hit rate we use, as before, a Westlake-Schuirmann test of equivalence of two independent proportions, for the rest of the measures we use this time a Kruskal-Wallis test because we are comparing two samples [33]. Table 5. Influence of POR on the results of ACOhg-mc Models

dri

lea

pet

pub

tra

ele

fir

sch

phi

Measures Hit rate Length Mem. (KB) CPU (ms) Hit rate Length Mem. (KB) CPU (ms) Hit rate Length Mem. (KB) CPU (ms) Hit rate Length Mem. (KB) CPU (ms) Hit rate Length Mem. (KB) CPU (ms) Hit rate Length Mem. (KB) CPU (ms) Hit rate Length Mem. (KB) CPU (ms) Hit rate Length Mem. (KB) CPU (ms) Hit rate Length Mem. (KB) CPU (ms)

ACOhg-mc Avg. Std. 100/100 37.10 1.45 1967.04 19.16 1307.80 379.64 100/100 21.30 1.45 2057.28 16.32 8255.90 743.28 100/100 113.28 70.82 2401.96 70.27 52686.00 76471.00 100/100 62.65 59.52 2744.84 110.38 2029.40 685.59 97/100 11.26 2.68 1986.53 12.55 71.24 20.97 100/100 10.11 7.95 2513.32 313.04 5882.10 7527.91 100/100 30.18 6.88 2077.00 0.00 9.10 3.49 100/100 8.90 3.67 2376.52 338.07 67.90 47.84 100/100 28.96 7.88 2483.92 221.83 138.00 140.25

ACOhg-mc+POR Avg. Std. 100/100 37.24 1.49 2012.08 35.25 1344.80 370.73 100/100 21.60 1.26 2110.04 54.77 7843.10 599.94 100/100 80.52 5.17 2386.68 12.73 1772.70 15789.89 100/100 53.26 24.99 2301.88 149.78 44.20 23.71 98/100 11.79 3.83 2024.20 26.77 67.86 25.32 100/100 11.79 14.34 2592.72 348.88 6558.90 8361.86 100/100 30.50 6.30 2413.00 0.00 13.80 4.85 100/100 9.00 5.77 2294.04 327.34 65.40 45.86 100/100 27.64 8.96 2458.24 196.01 158.30 156.41

Test − − + + − + + + − + + + − + + + − − + − − − + − − − + + − − + − − − + −

With respect to the hit rate, we can observe that the POR technique has no influence on the effectiveness of the algorithm. The only model in which the results are different is tra but the differences are not significant. If we focus on the length of the error trails we only observe three statistically significant differences in lea, pet, and pub. The first one is a small difference (and the test yielded only marginal significance, with a p-value of 0.0433) but the other two are large differences and they suggest that using POR the length of the error trails can be reduced. This is an interesting result, since, in general, the reduction in the construction graph performed by

216

Francisco Chicano and Enrique Alba

POR does not maintain the optimal paths. That is, states belonging to the optimal error paths can be reduced by POR and, thus, the optimal error path in the reduced model can be longer than the one of the original model. However, when the POR technique does not reduce states belonging to an optimal path, the reduction of the exploration graph can help the algorithms to find a shorter path. Concerning the memory required for the search we cannot observe large differences. In some models like dri and lea ACOhg-mc requires more memory using POR (with statistical significance) but in others like pet and pub less memory is required. Why is not memory always reduced? The objective of POR is to reduce the state space. With this reduction model checkers can always explore the complete state space using less memory. Thus, we expect a reduction of memory when POR is used. However, if the model does not fulfil the property a counterexample must exist and the model checker stops when this counterexample is found. We are here measuring the memory required up to the discovery of this counterexample and this memory could not be reduced, furthermore, it can be increased, as it can be observed in dri. This is not a particular behaviour of ACOhg-mc, it can be also observed in NDFS and INDFS as it is shown in Table 6. Especially interesting is the pet model for which POR is beneficial if ACOhg-mc is used and very damaging if NDFS is used instead. Finally, with respect to the time required for the search, the statistically significant differences in Table 5 suggest that using POR an error path is found earlier. The large differences found in pet and pub and the small one of lea support this proposition. Unlike this, dri and fir support the opposite hypothesis but in this case the differences are smaller. Thus, the general conclusion is that execution time is reduced with POR when ACOhg-mc is used. In summary, we have observed in this section that POR changes the state space in a way that, in general, is beneficial when ACOhg-mc is used for the search for property violations. Memory, computation time, and error path length can be noticeably reduced using POR. However, for some models a small increase in these parameters can be observed.

6.

Discussion

In this section we discuss the utility of our proposal from the software engineer point of view, giving some guidelines that could help practitioners to decide when to use ACOhg-mc for searching for errors in concurrent systems. First of all, it must be clear that ACOhg-mc can find short counterexamples in faulty concurrent systems, but it cannot be used for completely ensuring that a concurrent system satisfies a given property. Thus, ACOhg-mc should be used in the first/middle stages of the software development and after any maintenance modification made on the concurrent system. In these phases, errors are expected to exist in any concurrent software. In spite of the previous considerations, ACOhg-mc can also be used to assure with high probability that the software satisfies a given desirable property (perhaps obtained from its specification). In this case, it can be used at the end of the software life cycle. This is similar to state that the software is “probably correct” after a testing phase in which the software has been run on a set of test cases. Unlike this, in critical systems (like airplane controller software)

Debugging Concurrent Programs Using Metaheuristics

217

Table 6. Influence of POR on the results of NDFS and INDFS Models

ipr

pet

pub

tra

ele

fir

sch

Measures Hit rate Length Mem. (KB) CPU (ms) Hit rate Length Mem. (KB) CPU (ms) Hit rate Length Mem. (KB) CPU (ms) Hit rate Length Mem. (KB) CPU (ms) Hit rate Length Mem. (KB) CPU (ms) Hit rate Length Mem. (KB) CPU (ms) Hit rate Length Mem. (KB) CPU (ms)

NDFS 1/1 2657 104448 17470 1/1 9996 6577 60 1/1 2101 5105 60 1/1 131 2137 10 1/1 5553 53248 610 1/1 22 1885 0 1/1 6 1753 0

NDFS+POR 1/1 2657 60416 7700 1/1 9914 448512 39110 1/1 2386 6571 100 1/1 131 2134 10 1/1 5553 53248 950 1/1 22 2281 10 1/1 6 1753 0

INDFS 1/1 2657 104448 17430 1/1 124 1889 10 1/1 2053 4981 50 1/1 131 2133 20 1/1 5553 53248 630 n/ap. n/ap. n/ap. n/ap. n/ap. n/ap. n/ap. n/ap.

INDFS+POR 1/1 2657 60416 7670 1/1 132 1888 0 1/1 2363 6351 110 1/1 131 2134 10 1/1 5553 53248 950 n/ap. n/ap. n/ap. n/ap. n/ap. n/ap. n/ap. n/ap.

an exhaustive algorithm must be used in the final stages to verify that the software really satisfies the specification. We have stated in the experimental section what are the main advantages of using ACOhg-mc against exhaustive techniques (such as NDFS) in the search for property violations: shorter error paths can be obtained with higher probability and less memory. But, what about the drawbacks? The main drawback we have found from the point of view of the applicability of ACOhg-mc is the large amount of parameters of the algorithm. On the one hand, these parameters make ACOhg-mc more flexible, since it is possible to tackle models with different features changing the parameterization. On the other hand, software practitioners have no time to adjust the parameters of the algorithm and they want a robust algorithm that works well in most situations with minimum cost. In this sense, we understand that a parameterization study must be a priority in the following steps of this research, although general non-parameterized solvers for a problem cannot be expected in practice (and in theory). In fact, from the experiments performed for this and previous work we have outlined a set of rules for assigning values to the parameters (some of them are published in [1]). We already have some clues on how the number of parameters of ACOhg-mc could be largely reduced (work in progress).

218

7.

Francisco Chicano and Enrique Alba

Conclusion

We have presented here a proposal based on ant colony optimization for finding property violations in concurrent systems. This problem is of capital importance in the development of software for critical systems. Our proposal, called ACOhg-mc, is a stochastic algorithm that uses heuristic information based on the property to check to guide the search. We have shown the performance of the proposal on a set of ten models of the BEEM benchmark. We have compared ACOhg-mc against two algorithms used in explicit model checking: NDFS and INDFS. The results show that ACOhg-mc is able to outperform both algorithms in efficacy and efficiency for most of the models. ACOhg-mc requires a very low amount of memory and it is able to find short error trails. We have also analyzed the influence of the POR technique on the results obtained by ACOhg-mc. The results show that, in general, the POR technique can reduce the memory, the computation time, and the length of the error trails found by ACOhg-mc. As future work we plan to combine ACOhg-mc with other techniques for reducing the state space such as symmetry reduction. We have observed in a preliminary (not published) study that a version of ACOhg-mc that does not use pheromone trails for guiding the search is also able to obtain competitive results and requires even less memory. An additional advantage of such kind of algorithm is that it has fewer parameters than a version using pheromone trails. We will study the advantages and limitations of this alternative.

Acknowledgements We would like to thank Walter J. Gutjahr for his revision of this work and his constructive and helpful comments and suggestions. This work has been partially funded by the Spanish Ministry of Education and Science and FEDER under contract TIN2005-08818C04-01 (the OPLINK project). It has also been partially funded by the Spanish Ministry of Industry under contract FIT-330225-2007-1 (the European EUREKA-CELTIC project CARLINK).

References [1] Enrique Alba and Francisco Chicano. ACOhg: Dealing with huge graphs. In Proc. of GECCO, pages 10–17, 2007. [2] Enrique Alba and Francisco Chicano. Finding safety errors with ACO. In Proc. of GECCO, pages 1066–1073, 2007. [3] Bowen Alpern and Fred B. Schneider. Defining liveness. Inform. Proc. Letters, 21:181–185, 1985. [4] P. Ammann, P. Black, and W. Majurski. Using model checking to generate tests from specifications. In Proceedings of the 2nd IEEE International Conference on Formal Engineering Methods, pages 46–54, Brisbane, Australia, December 1998. IEEE Computer Society Press.

Debugging Concurrent Programs Using Metaheuristics

219

[5] Saddek Bensalem, Vijay Ganesh, Yassine Lakhnech, C´esar Munoz, Sam Owre, Harald Rueß, John Rushby, Vlad Rusu, Hassen Sa¨ıdi, N. Shankar, Eli Singerman, and Ashish Tiwari. An overview of SAL. In C. Michael Holloway, editor, Fifth NASA Langley Formal Methods Workshop, pages 187–196, Hampton, VA, 2000. [6] C. Blum and A. Roli. Metaheuristics in combinatorial optimization: Overview and conceptual comparison. ACM Computing Surveys, 35(3):268–308, 2003. [7] Dragan Boˇsnaˇcki, Stefan Leue, and Alberto Lluch-Lafuente. Partial-order reduction for general state exploring algorithms. In SPIN 2006, volume 3925 of Lecture Notes in Computer Science, pages 271–287, 2006. [8] Jerry R. Burch, Edmund M. Clarke, David E. Long, Kenneth L. McMillan, and David L. Dill. Symbolic model checking for sequential circuit verification. IEEE Transactions on Computer-Aided Design of Integrated Circuits and Systems, 13(4), April 1994. [9] Francisco Chicano and Enrique Alba. Ant colony optimization with partial order reduction for discovering safety property violations in concurrent models. Information Processing Letters, 2007. (to appear). [10] Francisco Chicano and Enrique Alba. Finding liveness errors with ACO. In Proceedings of the Cenfenrence on Evolutionary Computation, 2008. [11] Francisco Chicano and Enrique Alba. Searching for liveness property violations in concurrent systems with ACO. In Proceedings of Genetic and Evolutionary Computation Conference, 2008. [12] E. Clarke, R. Enders, T. Filkorn, and S. Jha. Exploiting symmetry in temporal logic model checking. Formal Methods in System Design, 9(1-2):77–104, August 1996. [13] E. M. Clarke, E. A. Emerson, and A. P. Sistla. Automatic verification of finite-state concurrent systems using temporal logic specifications. ACM Trans. Program. Lang. Syst., 8(2):244–263, 1986. [14] Edmund M. Clarke and E. Allen Emerson. Design and synthesis of synchronization skeletons using branching-time temporal logic. In Logic of Programs, Workshop, pages 52–71, London, UK, 1982. Springer-Verlag. [15] Edmund M. Clarke, Orna Grumberg, and Doron A. Peled. Model Checking. The MIT Press, January 2000. [16] M. Dorigo and L. M. Gambardella. Ant colony system: A cooperative learning approach to the traveling salesman problem. IEEE Transactions on Evolutionary Computation, 6(4):317–365. [17] Marco Dorigo and Thomas St¨utzle. Ant Colony Optimization. The MIT Press, 2004. [18] Stefan Edelkamp, Alberto Lluch Lafuente, and Stefan Leue. Directed explicit model checking with hsf-spin. In Lecture Notes in Computer Science, 2057, pages 57–79. Springer, 2001.

220

Francisco Chicano and Enrique Alba

[19] Stefan Edelkamp, Alberto Lluch Lafuente, and Stefan Leue. Protocol verification with heuristic search. In AAAI-Spring Symposium on Model-based Validation Intelligence, pages 75–83, 2001. [20] Stefan Edelkamp, Stefan Leue, and Alberto Lluch-Lafuente. Directed explicit-state model checking in the validation of communication protocols. Intl. Jnl. of Soft. Tools for Tech. Transfer, 5:247–267, 2004. [21] R. Gerth, D. Peled, M.Y. Vardi, and P. Wolper. Simple on-the-fly automatic verification of linear temporal logic. In Proceedings of IFIP/WG6.1 Symposium on Protocol Specification, Testing, and Verification (PSTV95), pages 3–18, Warsaw, Poland, June 1995. [22] Patrice Godefroid and Sarfraz Khurshid. Exploring very large state spaces using genetic algorithms. Intl. Jnl. on Soft. Tools for Tech. Transfer, 6(2):117–127, 2004. [23] A. Groce and W. Visser. Heuristics for model checking Java programs. Intl. Jnl. on Software Tools for Technology Transfer, 6(4):260–276, 2004. [24] Charles Anthony Richard Hoare. An axiomatic basis for computer programming. Communications of the ACM, 12(10):576–580, 1969. [25] G. J. Holzmann, D. Peled, and M. Yannakakis. On nested depth first search. In Proc. Second SPIN Workshop, pages 23–32, 1996. [26] Gerald J. Holzmann. The SPIN Model Checker. Addison-Wesley, 2004. [27] Alberto Lluch-Lafuente, Stefan Leue, and Stefan Edelkamp. Partial order reduction in directed model checking. In 9th International SPIN Workshop on Model Checking Software, Grenoble, April 2002. Springer. [28] Kenneth L. McMillan. Symbolic Model Checking. An approach to the state explosion problem. PhD thesis, Carnegie Mellon University, 1992. [29] Christoph C. Michael, Gary McGraw, and Michael A. Schatz. Generating software test data by evolution. IEEE Trans. on Soft. Eng., 27(12):1085–1110, 2001. [30] Radek Pel´anek. Web portal for benchmarking explicit model checkers. Technical Report FIMU-RS-2006-03, Faculty of Informatics, Masaryk University Brno, 2006. [31] Radek Pel´anek. BEEM: Benchmarks for explicit model checkers. In Proceedings of SPIN Workshop, volume 4595 of Lecture Notes in Computer Science, pages 263–267. Springer, 2007. [32] Doron Peled. Combining partial order reductions with on-the-fly model-checking. Formal Methods in System Design, 8(1):39–64, January 1996. [33] David J. Sheskin. Handbook of Parametric and Nonparametric Statistical Procedures. Chapman & Hall/CRC, 2007.

Debugging Concurrent Programs Using Metaheuristics

221

[34] T. St¨utzle and H. H. Hoos. MAX-MIN ant system. Future Generation Computer Systems, 16(8):889–914. Reviewed by Walter J. Gutjahr (University of Vienna)

INDEX A absolute zero, 141 absorption, 141 academic, 58, 176, 181, 182 acceptors, 128 access, 7, 8, 9, 16, 60, 61, 62, 182 accidental, 26 accounting, 166 accuracy, 94, 118 achievement, 14, 74, 79, 176, 179 ACM, 10, 11, 12, 35, 64, 65, 67, 88, 90, 91, 172, 173, 191, 219, 220 ACS, 206 activation, 115, 116 activation energy, 115, 116 actuators, 15 ad hoc, 158, 177 adaptability, 90 adaptation, 44, 45, 46, 47 administration, 70, 75 advertisement, 74 aerospace, 153 affective reactions, 90 age, 82, 127, 180 agents, 61, 66, 187, 188 aggregation, 51 aid, viii, 37, 38, 42, 57, 61, 95, 101, 191 aiding, 55, 57, 61, 62 air-traffic, 188 algorithm, vii, x, xi, 7, 8, 94, 95, 102, 103, 104, 105, 106, 107, 108, 109, 114, 115, 120, 122, 123, 191, 193, 195, 197, 198, 200, 202, 203, 204, 205, 206, 207, 208, 210, 211, 212, 213, 215, 217, 218 alloys, 122 alpha, 154 alphabets, vii, 10 alternative, 50, 54, 135, 137, 194, 218 alternatives, 63, 87, 89, 200 aluminium, 116, 122 aluminium alloys, 122 amplitude, 141

Amsterdam, 66 animal tissues, 95 animations, 137, 140 anisotropy, 113 annealing, 103 ants, 203, 204, 205, 206, 207, 209 application, viii, 16, 17, 18, 19, 26, 27, 29, 38, 56, 57, 58, 59, 61, 63, 78, 80, 81, 83, 85, 86, 95, 105, 110, 121, 126, 139, 140, 152, 154, 156, 159, 161, 164, 165, 166, 170, 183, 195 architecture design, 83, 87, 91 argument, 6 Aristotle, 125 arithmetic, 4 artificial intelligence, ix, 94, 95, 102, 103 Asia, 91 assessment, 84, 92, 155, 179 assets, ix, 39, 69, 70, 71, 72, 77, 79, 80, 81, 82, 85, 86, 87, 158 assignment, 40, 47, 53 assimilation, 44 assumptions, 127, 177, 178 asymptotically, 7 asynchronous, 34, 199 Atlantic, 68 atoms, 130, 134, 138, 141, 142, 143, 144, 145 attitudes, 176 Aurora, 37, 38, 40, 42, 44, 46, 48, 50, 52, 54, 56, 58, 60, 62, 64, 66, 68 Australia, 65, 68, 175, 183, 218 authentication, 166 authority, 79 automata, 196, 197 automation, 157 availability, 156 awareness, 73, 176, 179

B barrier, viii, 13, 14, 19, 20, 132 barriers, 126 Bayesian, 84 behavior, ix, 17, 61, 69, 77, 79, 80, 86, 90, 189, 191

224

Index

behaviours, 95 Belgium, 21, 22 beliefs, 178 benchmark, xi, 106, 152, 193, 195, 210, 211, 218 benchmarking, 220 bending, 122 benefits, vii, ix, 17, 19, 27, 30, 37, 38, 39, 63, 69, 74, 75, 76, 77, 90 biomechanics, ix, 93, 96, 121 biomolecular, 152 bit vectors, vii, 3, 4, 7, 8, 9 black-box, 31, 35, 169 blame, 90 blocks, 4, 5, 6, 9, 145, 160 bonds, 145 bonus, 159 Boston, 22 bottlenecks, 39 bottom-up, 153 bounds, vii, 3, 4, 7, 9, 10, 11, 170 brainstorming, 39 branching, 5, 196 Brno, 220 building blocks, 31, 32, 145, 161 buildings, 188 business environment, 73 business model, 158 bust, x, 94, 95, 103, 120 buttons, 142

C CAD, 157 CAM, 157 Canada, 10, 64, 67, 69, 90 capacity, 127, 152, 201 carbon, 143, 144 carbon atoms, 143 case study, viii, 25, 27, 29, 33, 35, 38, 41, 57, 60, 73, 75, 78, 81, 172, 173 catalyst, 74 category b, 51 cell, 5, 10, 187 channels, 127, 128 chemical bonds, 134 chemical engineering, 152 chemicals, 203 children, 178, 180, 181 chiral, 143, 144 chiral center, 143 chirality, 136, 144 chromosome, 105 classes, 33, 95, 96, 101, 104, 161, 162, 164, 166, 168, 187, 188, 189, 190 classical, 101, 104, 105, 136, 137, 139, 198, 212 classification, 48, 49, 50, 51, 52, 58, 87, 153, 166, 199, 209 classroom, 135, 150, 175, 177

classrooms, 129 clients, 154 Co, 21 code generation, 15 coding, 134, 188 cognition, 149 cognitive, 80, 126, 127, 128, 131, 132, 134, 135, 137, 138, 144, 146, 149 cognitive load, 135, 137, 144, 146 cognitive perspective, 134, 138 cognitive psychology, 127 cognitive science, 126, 131 cognitive system, 127, 128, 134, 137 collaboration, 78, 84, 126, 148, 155, 161, 163, 191 Collaboration, 155 collaborative learning experiences, 181 college students, x, 125 colors, 144 communication, 28, 29, 30, 39, 71, 72, 78, 79, 80, 81, 163, 166, 177, 178, 179, 182, 191, 203, 220 communities, 67, 72, 94, 128, 129, 150 community, vii, viii, 13, 14, 15, 20, 26, 67, 76, 81, 120, 129, 131, 158, 159, 178, 195, 213 commutativity, 199 compensation, 79 competence, 132, 135, 149 competition, 73 competitive advantage, 74 compiler, viii, 25, 28, 29, 30, 31 complement, 137 complex systems, x, 151, 171, 188 complexity, viii, ix, x, 7, 10, 13, 14, 15, 19, 20, 26, 34, 71, 87, 93, 94, 116, 132, 151, 152, 153, 157, 159, 170, 171, 176, 179, 180 compliance, 169 components, viii, x, 13, 14, 16, 17, 18, 19, 26, 71, 72, 78, 82, 83, 85, 86, 88, 151, 152, 153, 155, 156, 157, 158, 159, 160, 161, 162, 163, 164, 165, 166, 167, 171, 172, 173, 188, 196, 198 composites, 123 composition, 51, 131, 161 comprehension, 61, 66, 132 computation, 4, 7, 102, 109, 172, 209, 216, 218 computational fluid dynamics, 153 computer research, 194 Computer simulation, ix, 93, 96 computer software, 183 computer technology, 175, 183 computing, 164, 165, 172 concentrates, 85 concentration, 206 conception, 73, 78, 83, 176 concrete, 15, 134, 177, 209, 210 concurrency, 17 confidence, 72, 167, 211 configuration, 19, 86, 132, 138, 143, 144, 145, 165, 166, 167, 171, 190, 209, 211 conflict, 80, 81, 90, 158 Congress, 21

Index connectivity, 130, 134, 142, 143 constraints, ix, 29, 31, 34, 71, 72, 82, 93, 98, 101, 104, 115, 210, 214 construction, 26, 31, 128, 146, 160, 178, 203, 205, 206, 208, 209, 215 constructionist, 181, 183 constructivist, 126, 127, 128, 129, 137, 146, 150, 180 consultants, 48 consumer electronics, 69, 70 contiguity, 128 continuity, 104, 179 control, viii, 15, 18, 20, 25, 27, 29, 60, 72, 79, 82, 106, 118, 127, 142, 157, 181, 187, 188, 194 convergence, 104, 109, 112, 119 convex, 102, 107 cooperative learning, 219 coordination, ix, 69, 74, 79, 80, 81, 85 COPA, 91 Coping, 20 copper, 147 CORBA, 173 correlation, 83, 100 costs, 94, 159, 160, 169 coupling, 34, 97, 163 coverage, 169, 170, 189, 190, 200 covering, 14, 139 CPU, 4, 97, 103, 104, 120, 212, 213, 215, 217 CRC, 220 creative process, 126 creep, 96, 99 CRP, 164 crystallisation, 152 cues, 132, 133, 134, 137, 150 cultural factors, 128 culture, 51, 62, 77, 78, 79, 175 curiosity, 181 curriculum, 126, 147, 149 curriculum development, 126 curve-fitting, 97 customers, 72, 73, 74, 75, 76, 80, 86 Cybernetics, 21, 22 cycles, 18, 198, 199, 206, 207, 209

D data analysis, 153, 179 data structure, vii, viii, 3, 4, 5, 6, 7, 8, 9, 10, 12, 25, 30, 34 data transfer, 165 database, 28, 56, 58, 59, 136, 139, 141, 143, 145, 188, 191 database management, 58 decisions, 52, 57, 73, 79, 80, 86, 87, 103 decomposition, 47, 161, 164 defects, 167, 168 definition, x, 28, 48, 52, 53, 55, 56, 61, 71, 75, 76, 97, 98, 99, 112, 118, 151, 152, 155, 167, 179, 195, 199

225

deformation, 95, 96, 115, 121, 122 degrees of freedom, 30, 188 delivery, 73, 74, 156, 176, 177 demand, x, 94, 132, 175, 190 derivatives, 104, 105 designers, 126, 163 detection, 167, 190 detonation, 152 deviation, 105 discipline, 126 discontinuity, 107 discourse, 128, 178 discretization, 15, 96 disequilibrium, 99 dislocation, 115 displacement, 142 distributed computing, 172 distribution, 57, 78, 105, 171 diversity, 16, 19, 79, 82 division, 4, 79, 99 division of labor, 79 DSL, 26, 27, 28, 29, 30, 31, 32, 33, 34, 35 duplication, 161

E earth, 152 economics, 100, 182 Education, 137, 147, 148, 149, 150, 175, 183, 184 educational background, 179 educational research, 126 educational software, x, 126, 127, 128, 129, 134, 146, 175, 176, 177, 178, 180, 181, 182, 183, 184 educators, 126, 147, 175, 176 elastic deformation, 121 elasticity, 95 election, 210 electricity, 170 electromagnetic, 141 electron, 132 electrons, 130 email, 50 employees, 38, 39, 46, 79, 81 enantiomers, 143 encapsulated, 33 encoding, 7, 12, 134 energy, 95, 112, 113, 141 engagement, 126, 127, 128, 144 enterprise, 41, 73, 78, 83 entropy, 7, 10 environment, x, 17, 18, 58, 59, 73, 75, 78, 79, 81, 102, 128, 136, 137, 139, 140, 141, 150, 151, 152, 155, 162, 169, 170, 171, 189 epistemological, 126 epistemology, 147 equipment, 19 estimating, ix, 51, 52, 55, 93 ethane, 131, 133

226

Index

Europe, 70, 72, 88, 147, 148 Europeans, 72 evaporation, 206, 207 evolution, vii, viii, 13, 14, 15, 17, 19, 64, 66, 76, 82, 89, 96, 97, 102, 104, 109, 111, 115, 116, 119, 121, 133, 158, 220 evolutionary process, 102 exclusion, 210 execution, 17, 18, 30, 71, 167, 188, 189, 190, 191, 196, 197, 198, 200, 202, 203, 208, 209, 216 exercise, 60, 79 expert, 28, 39, 126, 128, 132, 134, 191 expertise, 28, 55, 76, 161, 163 explicit knowledge, 41 external environment, 80

F facilitators, 67 failure, 99, 156, 169, 214 family, 70, 72, 73, 74, 77, 82, 83, 84, 85, 87, 88, 89, 90, 91, 92, 161 family development, 72 family members, 82 faults, 18, 156, 168, 171 February, 68 feedback, 71, 155, 182 filters, 159, 210, 211 financial support, 120 finite differences, 119 finite element method, 96, 97, 104, 122 Finland, 83 first generation, 119 fitness, 64, 105 flexibility, x, 133, 151, 152, 169, 188 flow, vii, viii, 37, 38, 39, 40, 41, 42, 43, 54, 55, 56, 57, 58, 60, 62, 63, 67, 68, 96, 115, 212 fluid, ix, 93, 96, 152, 153 focusing, 126, 127, 130, 156 food, 152 forecasting, 74, 153, 156 foreign language, 51 France, 93 free rotation, 143 freedom, 30, 188 funding, 72, 73

G gas, 115 gender, 149 gene, vii, 3, 4 generalizations, vii, 3, 4 generation, viii, 25, 29, 105, 119, 158, 166, 171, 190, 191 generators, 159 genes, 102

genetic algorithms, 103, 104, 220 genre, 182 Germany, 64, 172 global warming, 152 goals, 14, 18, 38, 72, 73, 75, 76, 77, 79, 128 goods and services, 74 government, 61 grain, 115 graph, 153, 189, 195, 198, 199, 200, 202, 203, 204, 206, 207, 208, 215, 216 Greece, 125 grid computing, 156, 160, 164 grids, 152, 153, 171 grouping, 52, 161, 162 groups, 14, 19, 67, 72, 78, 79, 80, 84, 102, 138, 139 growth, viii, 13, 73 guidance, 87 guidelines, 74, 77, 78, 79, 81, 82, 84, 146, 153, 159, 161, 167, 173, 216

H handicapped, 18, 194 handling, 83, 191 Hawaii, 66 health, 64, 182 hearing, 27 heat, 152 height, 5 heterogeneity, viii, 13, 14, 15, 16, 17, 18, 19, 166 heterogeneous, 14, 17, 18, 188 heuristic, xi, 106, 193, 195, 196, 200, 201, 202, 205, 206, 207, 208, 209, 211, 218, 220 high school, 147 high temperature, 115 higher education, 183 high-level, 26, 31 hips, 75 Holland, 121 Hong Kong, 172 human, 26, 27, 28, 40, 49, 58, 64, 80, 102, 105, 127, 128, 130, 131, 161, 194 human brain, 26 human resource management, 49 human resources, 40 hybrid, 134 hybrids, 131 hypermedia, 183 hypothesis, 216

I IBM, 165 ice, 166 ICT, 179

Index identification, ix, 16, 40, 43, 50, 57, 58, 61, 62, 81, 86, 93, 94, 98, 101, 102, 103, 104, 110, 112, 116, 119, 120, 122, 161, 162 identification problem, 101, 102, 103, 104 identity, 73, 104, 138 ideology, 83 idiosyncratic, 129 images, 132, 134, 143, 144, 145 imagination, 176 imaging, 144 immunity, 102 implementation, viii, xi, 9, 13, 14, 15, 16, 17, 18, 25, 28, 29, 30, 34, 41, 63, 76, 80, 81, 82, 83, 85, 88, 127, 146, 161, 162, 163, 164, 165, 167, 177, 188, 189, 190, 193, 199, 211 in transition, 150 incentives, 159 inclusion, 16, 17, 60, 71, 206 incompatibility, 80 incompressible, 112, 113 indexing, vii, 3, 4, 6, 7, 8, 9, 10 industrial, viii, 15, 25, 29, 84, 85, 92, 94, 173 industrial application, 25 industrial experience, 92 industrialization, 75 industry, ix, 56, 61, 69, 70, 75, 82, 84, 86, 93, 96, 110, 159 inelastic, 121, 122 infinite, 196 information processing, 128 Information System, 64, 66, 67 information systems, 49, 56, 58, 66, 67, 194 information technology, ix, 69, 70 infrared, 141 infrastructure, 39, 42, 55, 59, 68, 72, 77, 81, 82, 85, 87, 152, 153, 158, 166, 167 inheritance, 18, 19, 31, 33, 51, 164 inherited, 19, 31 initial state, 71, 202, 208 innovation, 75, 76, 78, 79, 81, 89, 148, 151 inorganic, 139, 141 inspection, 83, 129, 167, 169 inspections, 167 institutionalization, ix, 69, 77 institutions, 83 instruction, 127, 128, 137, 146, 149, 179, 180, 181, 199 instructionism, 180 integration, x, 14, 17, 19, 38, 40, 61, 68, 80, 118, 125, 126, 134, 154, 157, 163, 166, 190 integrity, 154, 155, 156, 161, 165, 172 Intel, 136, 165 intelligence, 129, 133 intensity, 15 interaction, 78, 127, 130, 175, 181, 182, 191 interactions, 128, 134, 170, 182, 188, 189 interactivity, 182 interdisciplinary, 19

227

interface, 73, 74, 88, 122, 139, 140, 142, 144, 145, 157, 158, 161, 162, 164, 167, 171, 190 international standards, 65 Internet, 28, 170, 178, 182, 183 interoperability, 156, 159 interpretation, 75, 81, 87, 101, 128 interrelationships, 82 interval, 4, 103, 207 intervention, 194 interviews, 58 intrinsic, 14, 17, 28, 129 invariants, 95, 112, 196 inversion, 133, 138 investigative, 129 investment, 73, 76, 161, 163, 170 ions, 19, 75, 153, 188, 190, 191, 195, 203, 214, 219 IR spectroscopy, 141 Ireland, 63, 69 ISO, 92 isolation, 169 isotropic, 112, 115, 121 iteration, 102, 104, 106, 109, 119

J Jacobian, 104, 119 Jacobian matrix, 104, 119 January, 172, 219, 220 Japan, 3 Java, viii, 25, 31, 33, 34, 35, 170, 194, 195, 220 job scheduling, 172 jobs, vii, 38, 57, 79 Jordan, 148 justification, 75, 86

K kernel, 211 kinematics, 95 knowledge construction, 146 knowledge transfer, 41, 54

L language, viii, x, 16, 25, 26, 27, 28, 29, 30, 31, 33, 34, 44, 51, 52, 59, 86, 125, 129, 130, 131, 133, 146, 163, 169, 170, 178, 181, 191, 194, 210 large-scale, 161 lattice, 115 law, 110, 118 laws, 121, 129, 130, 132, 146 lead, x, 94, 95, 103, 104, 108, 110, 118, 120, 138, 153, 164, 169, 170, 188 leadership, 62, 181 learners, 127, 128, 129, 132, 134, 135, 137, 138, 144, 146, 147, 176, 177, 179, 180, 181, 182

228

Index

learning, x, 67, 75, 78, 79, 80, 81, 102, 125, 126, 127, 128, 129, 130, 131, 132, 133, 134, 135, 136, 137, 146, 148, 149, 150, 175, 176, 177, 178, 179, 180, 181, 182, 183 learning environment, 128, 129, 137, 146, 176, 177 learning outcomes, 176, 177 learning process, 181, 183 learning styles, 136, 176 life experiences, 150 lifecycle, 15, 16, 19, 87, 164, 167, 168, 169, 170, 171, 216 lifetime, 152 limitations, 27, 31, 38, 63, 152, 218 linear, 9, 19, 95, 104, 107, 116, 143, 145, 196, 220 linear function, 116 links, 17, 18, 60, 170 Linux, 152, 211 listening, 190 literacy, 126, 128, 179 location, 47, 50, 63, 190 logging, 18 London, 69, 184, 219 long-term, viii, 13, 14, 16, 18, 73, 75, 78, 79 loyalty, 74, 75

M machines, 187, 201, 209, 211 mainstream, 159 maintenance, vii, viii, ix, 13, 14, 18, 19, 37, 39, 40, 41, 42, 57, 58, 59, 60, 61, 62, 64, 65, 66, 67, 68, 86, 92, 154, 216 maintenance tasks, 65 management, vii, viii, ix, 29, 37, 38, 39, 41, 43, 56, 57, 58, 63, 64, 65, 66, 67, 68, 69, 70, 71, 72, 73, 75, 76, 77, 78, 79, 80, 81, 82, 83, 84, 85, 86, 89, 90, 157, 166, 171, 172 manipulation, 134 manufacturing, 157 mapping, 65, 81 market, 26, 70, 72, 73, 74, 75, 76, 80, 85, 86, 176, 177 market segment, 70, 72, 73, 74, 75, 76, 80, 85, 86 market share, 70, 74, 80 marketing, 73, 74, 76, 89 marketing strategy, 73 marriage, 149 Marx, 149 Maryland, 67, 187 Massachusetts, 121, 181, 184 Massachusetts Institute of Technology, 21, 121, 181, 184, 219 material resources, 58 mathematics, 129, 133, 149 mathematics education, 149 matrix, 98, 104, 105, 119, 123 MDA, 27 measurement, 40, 58

measures, 76, 189, 195, 212, 215 media, 127, 135, 136, 137, 138, 139, 144, 146, 149, 183, 184 medicine, 129, 152 Mediterranean, 20 melting, 130 memorizing, 128 memory, xi, 4, 5, 26, 39, 41, 128, 152, 193, 194, 195, 203, 206, 207, 210, 211, 212, 213, 214, 216, 217, 218 mental image, 132, 138 mental model, 133, 138 mental representation, 140 messages, xi, 29, 31, 33, 34, 127, 187, 188 metals, 95, 115, 121, 123 metaphor, 176, 177, 178, 179, 180 metaphors, 178, 184 metric, 201 Mexican, 61, 67 Mexico, 37, 63 Microsoft, 15, 21, 29, 172 middleware, 15, 20, 190 migration, 74 military, 153 mimicking, 191 mining, 205 Ministry of Education, 218 mirror, 129, 143, 144 misconception, 145 MMA, 102 mobile phone, 75 modality, 128 modeling, 41, 42, 43, 44, 45, 66, 71, 84, 85, 86, 87, 91, 125, 126, 147, 148, 149, 154, 160, 161, 172 models, ix, x, xi, 16, 17, 27, 39, 40, 41, 42, 43, 44, 48, 53, 58, 61, 64, 71, 78, 83, 84, 85, 93, 94, 95, 96, 98, 99, 104, 105, 106, 111, 112, 113, 114, 115, 120, 121, 122, 127, 130, 131, 132, 133, 137, 138, 139, 140, 144, 145, 146, 147, 153, 154, 161, 164, 165, 189, 191, 193, 195, 210, 211, 212, 213, 214, 216, 217, 218, 219 modules, 15, 16, 17, 18, 19, 58, 59, 97, 139 modulus, 116 molecular medicine, 152 molecular structure, x, 125, 131, 133, 134, 135, 136, 137, 138, 140, 143, 144, 147 molecules, 130, 131, 133, 134, 136, 137, 138, 139, 140, 141, 142, 143, 144, 145, 146 money, 170, 194 monomer, 144, 145, 146 monomer molecules, 144, 145 MOS, 29, 30, 33, 35 motion, 141 mouse, 190 movement, 79, 130, 140, 141, 206 MSC, 122 multidisciplinary, 126, 148 multimedia, 127, 128, 149, 178, 182 multiplication, 4, 181

Index multiplicity, 118, 120 muscular tissue, 113 mutation, 105, 108

N NASA, 20, 172, 219 natural, 102, 105 natural evolution, 105 natural selection, 102 negotiating, 80 Netherlands, 148, 149, 150 network, xi, 85, 103, 122, 161, 172, 187, 188, 189, 190 neural network, ix, 94, 95, 103, 122 neural networks, ix, 94, 95, 103 neurons, 103 New Jersey, 147, 148, 172 New York, 21, 64, 92, 122, 147, 149, 183 NEXUS, 15, 20, 21 nodes, 6, 41, 42, 152, 166, 198, 202, 204, 205, 206, 207, 208 non-linear, x, 94, 95, 101, 102, 104, 107, 110, 120, 123 normal, 80, 105, 136, 140, 141, 142, 147 norms, 51 Norway, 65 novelty, 149 nuclear, 110, 152, 194 nuclear power, 194 nuclear power plant, 194

O objectivity, 103, 109 observations, 38, 57, 58, 59, 73, 79, 96 off-the-shelf, 17, 157 online, 9, 182 openness, 79 operating system, 19, 58, 75, 152, 183, 190 operator, 106, 107, 170, 201, 204 opposition, 103 optical, 143 optical activity, 143 optimization, ix, xi, 94, 95, 97, 98, 99, 100, 101, 102, 103, 104, 105, 106, 107, 108, 109, 110, 111, 112, 114, 115, 117, 118, 119, 120, 121, 122, 193, 195, 203, 218, 219 optimization method, ix, 94, 101, 102, 103, 104, 107, 108, 111, 120, 122 oral, 128 organic, 139, 141, 143 organization, vii, ix, 37, 39, 41, 48, 51, 56, 59, 61, 67, 69, 70, 71, 72, 73, 74, 75, 76, 77, 78, 79, 80, 81, 82, 84, 86, 89, 126, 132 organizational behavior, 77, 80 organizational culture, 78, 79

229

organizations, vii, ix, 38, 39, 40, 41, 48, 56, 61, 62, 64, 65, 66, 69, 70, 74, 76, 78, 79, 80, 81, 87, 89, 90 orientation, 26, 75, 76, 133, 140, 143, 144, 176, 182 overload, 57, 59 OWL, 28

P Pacific, 91 packaging, 40, 161 paper, 25, 26, 27, 29, 34, 44, 50, 63, 64, 65, 66, 67, 68, 195 paradigm shift, x, 151, 152 parallelism, 26 parameter, ix, 93, 94, 96, 97, 100, 101, 102, 104, 112, 113, 119, 122, 206, 207 parents, 177 Paris, 122 particle physics, 152 particle swarm optimization, 102 particles, x, 125, 128, 129, 130, 146 partition, 4, 9 passive, 121, 128 payback period, 73, 79, 80 PDAs, 187 pedagogy, 126, 128 peer, 167 peer review, 167 penalties, 104 penalty, 101, 104, 105, 209 Pennsylvania, 66 perception, 80, 130, 132, 134, 147 perceptions, 178 performance, ix, x, xi, 8, 18, 30, 39, 54, 68, 74, 75, 76, 77, 86, 94, 95, 98, 102, 103, 107, 108, 112, 133, 152, 153, 159, 170, 172, 176, 180, 194, 195, 218 personal, 39, 55, 57, 60, 80 Perth, 183, 184 perturbation, 109, 119 pheromone, 203, 205, 206, 207, 208, 218 philosophers, 211 philosophical, 183 philosophy, 16, 129, 150, 177, 178 phone, 187 physics, 129, 132, 147, 152 pig, 113, 115 planning, 56, 73, 74, 76, 78, 79, 81, 190 plasma, 152 plasma physics, 152 plastic, x, 95, 96, 110, 115, 122 plastic deformation, 96, 115, 122 plastic strain, 110, 115 plasticity, 13, 95, 96 platforms, 15, 17, 18, 30, 187 play, ix, 38, 40, 55, 69, 75, 77, 86, 126, 131, 158, 175

230

Index

plug-in, 136 Poisson, 116 Poisson ratio, 116 Poland, 220 polarization, 143 politics, 79 polymer, 145, 146 polymers, 136, 144, 145, 146 polynomials, 9 population, 70, 71, 88, 105, 106, 108, 119 portfolio, 76 Portugal, 67, 93, 123 positive correlation, 133 postmortem, 40, 62, 65 power, 7, 29, 34, 35, 79, 101, 182, 194 pragmatic, vii, viii, 25, 27, 30, 34 predicate, 201 predictability, 165 prediction, 92, 112, 121 pre-existing, 14, 71 preference, 207, 209 preprocessing, 5, 6, 7 prevention, 156 primitives, 44 prior knowledge, 127 proactive, 73 probability, 103, 205, 206, 207, 209, 216, 217 probe, 10 problem solving, 155, 181, 182 problem-solving task, 182 production, 70, 71, 72, 73, 75, 76, 126, 163 productivity, 27, 58, 70, 82, 156 profit, 63, 73, 76 profitability, 74 profits, 73 program, viii, xi, 17, 25, 27, 30, 31, 34, 40, 61, 82, 137, 139, 140, 142, 144, 167, 168, 170, 181, 188, 193, 194, 195, 196, 199, 200 programming, viii, 13, 15, 16, 17, 18, 19, 25, 26, 30, 34, 52, 58, 59, 159, 163, 181, 194, 220 programming languages, 15, 17, 26, 52, 194 promote, 68, 136, 137, 144, 181 pronunciation, 181 property, vii, xi, 50, 96, 193, 194, 195, 196, 197, 198, 199, 201, 202, 203, 207, 208, 209, 210, 214, 216, 217, 218, 219 proposition, 197, 201, 216 protocol, 188, 189, 190, 210, 211 protocols, xi, 187, 188, 189, 220 prototype, 180, 181 prototyping, 85, 92 psychology, 90 psychometric approach, 143 public, 17, 210, 211

Q quality assurance, 188

quantum, 26, 126, 141, 153 quantum mechanics, 141 query, 4, 5, 6, 7, 8, 9 questionnaires, 84

R race, 143 radiation, 141 radical, 90 Raman, 4, 10, 11, 12, 141, 142 Raman spectroscopy, 141 random, 205 range, x, 9, 75, 131, 140, 141, 171, 175, 182 rapid prototyping, 31 reaction mechanism, 138 real numbers, 203 real time, 169 reality, 97, 131, 145, 176 reasoning, 66, 149, 150, 178 recognition, 87, 138 recombination, 102 rectification, 150 reduction, ix, xi, 6, 39, 69, 109, 111, 194, 195, 196, 199, 200, 210, 215, 216, 218, 219, 220 reductionism, 129 refining, 86 reflection, 133, 138, 150, 177, 181, 182 registries, 56 regression, 190, 191 regular, 45, 60 regulations, 170 relationship, 44, 47, 80, 135, 141, 143, 144, 149, 195 relationships, 45, 48, 50, 52, 53, 62, 75, 78, 79, 90, 130, 134, 135, 138 relative size, 134 relevance, 38 reliability, 72, 86, 156, 165, 167, 169 remote sensing, 153 repair, 168 replication, 17 reproduction, 102 research, ix, x, 4, 9, 14, 16, 19, 20, 26, 57, 60, 61, 62, 70, 75, 76, 77, 81, 83, 86, 88, 125, 126, 128, 129, 131, 133, 146, 148, 151, 152, 153, 156, 158, 166, 175, 189, 194, 217 research and development, 75, 126, 183, 189 researchers, viii, ix, xi, 16, 20, 26, 37, 40, 70, 72, 78, 84, 86, 87, 126, 128, 134, 135, 137, 187, 188, 189, 191, 210 resistance, 78, 80, 81, 96, 115 resolution, 94, 101, 120 resource management, 49, 72, 82, 166 resources, xi, 29, 38, 40, 43, 58, 72, 74, 76, 77, 82, 128, 152, 153, 155, 156, 166, 177, 181, 182, 190, 193, 195, 210, 214 responsibilities, 72, 76, 78, 81 retention, 73

Index returns, 161, 207, 208 reusability, x, 15, 16, 79, 83, 85, 86, 88, 151, 152, 171 risk, 72, 74 risks, 82 road map, 81 roadmap, 75 robotic, vii, viii, 13, 14, 15, 16, 17, 18, 19, 20 robotics, 13, 14, 15, 17, 18, 19, 20, 21 robustness, 95, 120, 190 rods, 134 ROI, 158, 161, 162, 163 rotations, 95, 138, 143, 150 routines, 33, 170, 190 RTI, 15

S safety, 156, 169, 195, 196, 198, 203, 208, 214, 218, 219 salts, 130 sample, 43, 44, 45, 46, 50, 51, 52, 53, 54, 212 Samsung, 75 sand, 6 SAS, 179 satisfaction, 18, 74, 78 savings, 160 scalability, x, 88, 151, 152, 153, 156, 166, 189, 191 scalable, 153, 156, 165, 166, 167 scalar, 115 scaling, 105, 106 scheduling, 18, 56, 72, 166, 201 schema, 49, 50, 51, 52 Schmid, 73, 88, 89, 90 school, x, 125, 147, 177 science education, 129, 148 scientific computing, 152, 172 scientific progress, 26 scientists, 126, 152, 155 scripts, 28 search, xi, 6, 38, 39, 52, 103, 104, 105, 106, 111, 120, 139, 172, 190, 193, 194, 195, 196, 197, 198, 199, 200, 202, 203, 204, 206, 207, 208, 209, 210, 211, 212, 214, 216, 217, 218, 220 searches, 9, 197, 207, 208 searching, 97, 190, 195, 198, 201, 202, 203, 207, 209, 216 second language, 31 secondary education, 136 security, x, 29, 57, 79, 151, 166 sediment, 130 selecting, 42, 49, 127, 207, 209 self-assessment, 161 semantic, 210 semantics, 84, 171 sensing, 153 sensitivity, 99, 104 Sensitivity Analysis, 104

231

sensors, 15 sentences, 178 separation, 19, 31, 34 series, 4, 141, 177 services, 16, 17, 28, 56, 58, 74, 75, 152, 162, 165, 166 shape, 41, 121, 122, 126, 130, 133, 136 shares, 74 sharing, 61, 70, 75, 79, 80, 82, 87 shear, 116, 118, 119 sign, 74, 116, 212, 215 signals, 99, 188, 191 silver, 26 simulation, ix, 29, 93, 94, 96, 97, 104, 112, 122, 153, 169, 187, 188, 190 simulations, ix, 84, 93, 96, 123, 182 Simultaneous Localization and Mapping, 14 sites, 170, 182 skeletal muscle, 121 skills, 19, 39, 40, 51, 77, 126, 131, 132, 134, 135, 147, 150, 179, 180 small firms, 67 Smithsonian, 148 Smithsonian Institute, 148 smoke, 190 social construct, 149 social context, 126 software, vii, viii, ix, x, xi, 13, 14, 15, 16, 17, 18, 19, 20, 21, 25, 26, 28, 29, 33, 34, 35, 37, 38, 39, 40, 41, 42, 43, 44, 45, 48, 49, 51, 54, 56, 57, 58, 59, 61, 62, 63, 64, 65, 66, 67, 68, 69, 70, 71, 72, 73, 74, 75, 76, 77, 78, 79, 80, 81, 82, 83, 84, 85, 86, 87, 88, 89, 90, 91, 92, 93, 94, 96, 97, 98, 100, 102, 122, 125, 126, 134, 135, 136, 146, 151, 152, 153, 154, 156, 157, 159, 160, 161, 162, 163, 165, 166, 167, 168, 169, 170, 171, 172, 173, 175, 176, 177, 178, 179, 180, 181, 182, 183, 184, 187, 188, 189, 190, 191, 193, 194, 195, 196, 201, 216, 217, 218, 220 solutions, xi, 14, 15, 39, 54, 64, 66, 87, 103, 143, 159, 193, 195 sounds, 127, 182 space exploration, 210 Spain, 13, 20, 21, 37, 63, 193 spatial, x, 125, 129, 130, 133, 134, 135, 142, 146, 149 spatial ability, 133 specific knowledge, 44, 46, 47, 62 spectroscopy, 138, 141 spectrum, 141 speed, x, 95, 140, 151, 152, 153, 171 SPSS, x, 175, 179 SQL, 28 stabilization, 98, 102 staffing, 78 stages, xi, 14, 16, 18, 19, 42, 48, 95, 97, 102, 118, 135, 157, 168, 170, 179, 180, 190, 193, 195, 216, 217 stakeholder, 73, 83

232

Index

stakeholders, 75, 85, 87, 154 standard deviation, 105, 211, 212 standardization, 16 standards, 20, 65, 159, 170 starvation, xi, 193, 194, 196 statistical analysis, 179 statistics, 100 steel, 110 stochastic, 105, 214, 218 storage, 4, 10, 57 strain, 95, 110, 112, 113, 115, 119 strains, 95, 96, 98 strategic, 56, 73, 74, 75, 76, 78, 79, 80, 86 strategic planning, 73, 76, 78, 79 strategies, vii, viii, 37, 38, 40, 41, 42, 60, 63, 66, 67, 74, 80, 81, 106, 108, 109, 110, 111, 112, 114, 117, 118, 119, 120, 121, 133, 160 strength, x, 16, 94, 103 stress, 84, 98, 112, 115, 119, 170 stress level, 170 stress-strain curves, 111, 118 structural characteristics, 146 structuring, 72 students, x, 19, 125, 126, 128, 129, 130, 132, 133, 134, 135, 136, 137, 138, 139, 140, 141, 142, 143, 144, 146, 147, 176, 177, 178, 182 subjective, 51, 87 substances, 129 subtraction, 4 supercomputers, 152, 166 superconducting, 122 superiority, 108 suppliers, 88, 154 swarms, 102 switching, ix, 69, 81, 106 symbolic, x, 125, 128, 129, 130, 131, 132, 133, 134, 135, 137, 138, 139, 141, 145, 146, 150 symbols, 14, 130, 131, 132 symmetry, 136, 137, 138, 139, 140, 142, 143, 194, 218, 219 synchronization, 17, 190, 219 synchronous, 197, 202 synergistic, 128 syntax, viii, 25, 30, 31, 34, 171 synthesis, 145, 146, 219 systems, vii, viii, x, xi, 13, 14, 15, 16, 17, 37, 38, 39, 41, 42, 49, 54, 55, 56, 57, 58, 59, 60, 63, 65, 66, 67, 68, 70, 71, 72, 78, 87, 88, 90, 94, 123, 129, 131, 135, 136, 151, 152, 153, 154, 156, 157, 158, 159, 161, 164, 165, 166, 167, 169, 170, 171, 172, 188, 189, 191, 193, 194, 195, 199, 202, 203, 207, 212, 214, 216, 218, 219

T tactics, 87 tangible, 20 targets, 74, 75

taxonomy, 48, 50 teachers, 176, 177, 178, 179, 181, 182, 184 teaching, x, 126, 141, 147, 148, 175, 176, 177, 178, 179, 180, 181, 182, 183 teaching process, 176 team members, 31 technology, 28, 29, 30, 33, 35, 59, 62, 64, 66, 70, 71, 73, 75, 78, 80, 81, 82, 92, 126, 129, 136, 147, 164, 175, 182, 183 telecommunication, 161 telecommunications, ix, 69, 70, 152 telephony, 28 temperature, 96, 115, 116, 141 temporal, xi, 191, 193, 194, 196, 197, 201, 219, 220 tensile, 112, 118 tertiary education, x, 125, 136, 146 test data, 171, 191, 220 textbooks, 135, 137, 141 theory, x, 76, 77, 95, 102, 121, 126, 127, 128, 130, 131, 134, 138, 147, 149, 175, 176, 214, 217 Thessaloniki, 125 thinking, 83, 126, 133, 135, 137, 140, 143, 144, 146, 150 threatening, 170 threats, 156 three-dimensional, 116, 132, 134, 135, 137, 142, 143, 147, 150 three-dimensional model, 147 three-dimensional representation, 132 three-dimensional space, 116 threshold, 95, 207 time, vii, viii, ix, x, xi, 3, 4, 5, 6, 7, 8, 9, 13, 14, 16, 17, 18, 19, 26, 30, 31, 32, 34, 37, 39, 43, 45, 47, 49, 51, 52, 53, 54, 55, 57, 59, 62, 69, 70, 72, 73, 74, 80, 83, 86, 97, 103, 111, 120, 126, 127, 134, 140, 144, 151, 152, 153, 159, 168, 169, 170, 171, 190, 193, 195, 196, 210, 211, 212, 214, 215, 216, 217, 218 time consuming, 62, 126 time frame, 31, 32 timing, 29, 74, 76 tissue, 113, 115 Tokyo, 3 tolerance, 17, 156 tracking, 72, 171 trade, 81 trade-off, 8 traffic, 188 training, 40, 72, 77, 103, 163, 164, 181 transfer, 53, 54, 56, 57, 130, 140, 165 transformation, 82, 132, 135, 136 transformations, x, 28, 125, 130, 131 transition, 116, 141, 161, 191, 199, 200, 203 transitions, 90, 141, 199, 200, 201, 202 translation, x, 175, 197, 210 transmission, 29 traps, 89 trees, 6, 10, 11, 12, 190 trend, ix, 18, 20, 69, 86, 88

Index triggers, 191 trust, 82 turnover, 39 two-dimensional, 116, 132 two-dimensional space, 116 two-way, 149

233

visualization, x, 125, 126, 128, 129, 130, 131, 133, 134, 135, 136, 137, 142, 144, 146, 148, 150, 187, 188 visuospatial, 126, 131, 133, 135, 137, 138, 140, 143, 144, 146, 150 Vitter, 10, 11 voice, 28

U ubiquitous, xi, 187 UML, 26, 27, 35, 44, 84, 85, 91, 161, 162, 171, 172, 173 undergraduate, 139, 140, 149 uniaxial tension, 112, 116 United Arab Emirates, 69 United States, 72 universal gas constant, 115 universe, 101, 103, 104, 105, 106, 111

V validation, 14, 15, 16, 18, 88, 158, 166, 167, 220 validity, 197 values, 5, 96, 97, 98, 99, 104, 108, 110, 114, 115, 117, 191, 197, 203, 207, 208, 209, 212, 217 variability, 76, 78, 79, 81, 82, 83, 84, 85, 86, 91, 161, 171 variable, 9, 83, 85, 86, 96, 105, 115, 116, 118, 121, 190, 191, 197 variables, xi, 96, 98, 102, 105, 112, 115, 191, 193, 196, 197, 200, 201, 205, 209 variation, 55, 72, 82, 84, 85, 86 vector, vii, 3, 4, 5, 6, 7, 8, 9, 98, 102, 104, 105, 109 vehicles, 29 vibration, 136, 140, 141, 142 virtual world, 176 visible, 34, 135 vision, 29, 73, 75, 76, 79

W war, 62, 66 Warsaw, 220 web, xi, 19, 60, 68, 136, 162, 170, 182, 187, 188, 189, 190, 210 Web Ontology Language, 28 web sites, 170, 182 web-based, 181, 182 windows, 146 winning, 129 word processing, x, 175, 179 work environment, 39 workers, 38 workflow, 41, 45, 46, 53, 153, 157 working memory, 128 workplace, 54 workspace, 59 writing, 46, 159, 168

X XML, 28, 167

Y yield, 31, 161