toc

Team LiB
Next Section

Software Evolution with UML and XML
Software Evolution with UML and XML
by Hongji Yang (ed)
Idea Group Publishing © 2005 (418 pages)
ISBN:1591404622

Providing a forum of expert insights, this text not only investigates the potential powerful applications of two popular languages (UML and XML) in the field of software evolution, but also discovers what will happen when these three are linked together.

Table of Contents
 | Software Evolution with UML and XML
 | Preface
 | Chapter I | - | A Framework for Managing Consistency of Evolving UML Models
 | Chapter II | - | Deriving Safety-Related Scenarios to Support Architecture Evaluation
 | Chapter III | - | A Unified Software Reengineering Approach towards Model Driven Architecture Environment
 | Chapter IV | - | Towards the Integration of a Formal Object-Oriented Method and Relational Unified Process
 | Chapter V | - | On the Co-Evolution of SSADM and the UML
 | Chapter VI | - | Software Evolution with XVCL
 | Chapter VII | - | UML- and XML-Based Change Process and Data Model Definition for Product Evolution
 | Chapter VIII | - | Rapid Pattern-Oriented Scenario-Based Testing for Embedded Systems
 | Chapter IX | - | Developing a Software Testing Ontology in UML for a Software Growth Environment of Web-Based Applications
 | Chapter X | - | Abstracting UML Behavior Diagrams for Verification
 | Chapter XI | - | Support for Architectural Design and Re-Design of Embedded Systems
 | Chapter XII | - | Describing and Extending Classes with XMI—An Industrial Experience
 | Index
 | List of Figures
 | List of Tables
 | List of Definitions

Team LiB
Next Section


backcover

Team LiB

Back Cover

Software Evolution with UML and XML provides a forum where expert insights are presented on the subject of linking three current phenomena: software evolution, UML and XML. Software evolution and reengineering are a real problem in the software industry; various attempts have been made in these areas and there is still room for improvement. Tackling evolution with the help of UML and XML can be very beneficial to the software community, especially as the cost of software evolution makes up a considerable proportion, sometimes even 70-80%, of the total budget of a software system. Software Evolution with UML and XML not only investigates the potential powerful applications of two popularly used languages, UML and XML, in the field of software evolution, but also discovers what will happen when these three are linked to work together.

About the Editor

Hongji Yang is currently the Head of Division of System Design in the School of Computing at De Montfort University and also Deputy Technical Director in the Software Technology Research Laboratory at De Montfort University. He received his Ph.D. in Computer Science from Durham University, England, his M.Phil. in Computer Science from Jilin University, China, and his B.Sc. in Computer Science from Jilin University, China.

Team LiB


Software Evolution with UML and XML

Hongji Yang
De Montfort University,
UK

IDEA GROUP PUBLISHING

Acquisitions Editor: Mehdi Khosrow-Pour
Senior Managing Editor: Jan Travers
Managing Editor: Amanda Appicello
Development Editor: Michele Rossi
Copy Editor: Michael Jaquish
Typesetter: Sara Reed
Cover Design: Lisa Tosheff

Published in the United States of America by
Idea Group Publishing (an imprint of Idea Group Inc.)
701 E. Chocolate Avenue, Suite 200
Hershey PA 17033
Tel: 717-533-8845
Fax: 717-533-8661
E-mail: cust@idea-group.com
Web site: http://www.idea-group.com

and in the United Kingdom by
Idea Group Publishing (an imprint of Idea Group Inc.)
3 Henrietta Street
Covent Garden
London WC2E 8LU
Tel: 44 20 7240 0856
Fax: 442073793313
Web site: http://www.eurospan.co.uk

© 2005 Idea Group Inc.

All rights reserved. No part of this book may be reproduced in any form or by any means, electronic or mechanical, including photocopying, without written permission from the publisher.

Library of Congress Cataloging-in-Publication Data

Software evolution with UML and XML / Hongji Yang, editor.
p. cm.
Includes bibliographical references and index.

1-59140-462-2

(h/c) – ISBN 1-59140-463-0 (s/c) – ISBN 1-59140-464-9 (ebook)
1. Computer software–Development. 2. UML (Computer science) 3. XML (Document markup language) I. Yang, Hongji.
QA76.76.D47S6615 2004
005.1–dc22

2004022147

British Cataloguing in Publication Data
A Cataloguing in Publication record for this book is available from the British Library.

All work contributed to this book is new, previously-unpublished material. The views expressed in this book are those of the authors, but not necessarily of the publisher.

Acknowledgments

I feel that it is beyond words to express my gratitude to people who have helped with the publication of this book.

I would like to acknowledge all the authors for their academic insights and the patience to go through the whole proposing-writing-revising-finalising process to get their chapters ready. In addition, most of the authors of the chapters included in this book also served as reviewers for chapters written by other authors, and thanks go to them for providing constructive and comprehensive reviews.

Special thanks go to Dr. Y. Li of BTexact, UK, and Dr. H. Zheng of Semantic Designs, Inc., USA, for providing reviews in their specialised fields to some of the submitted chapters, though they are not chapter authors.

Special thanks also go to the publishing team at Idea Group Inc., in particular to Mehdi Khosrow-Pour, whose enthusiasm motivated me to start this project which provides me such a fantastic opportunity to work with many excellent scholars in the world, to Jan Travers, for her continuous support in logistics of the project, and to Michele Rossi for the initial setting up of the project, such as providing a template for chapters.

Finally, I would like to thank my wife and my son for their support throughout this project.

Hongji Yang, PhD
Loughborough, UK
May 2004

About the Authors

Hongji Yang is professor, head of Division of System Design and leader of the Software Evolution and Re-engineering Group (SERG), the School of Computing at De Montfort University (UK). He received a BSc and MPhil in Computer Science from Jilin University, China, and a PhD in Computer Science from Durham University, UK. His research interests include software engineering and distributed computing. He served as programme co-chair at IEEE International Conference on Software Maintenance (ICSM '99), programme co-chair at IEEE International Workshop on Future Trends in Distributed Computing Systems (FTDCS'01) and program chair at IEEE Computer Software and Application Conference (COMPSAC'02).

Alessio Bechini earned a PhD at the Department of Information Engineering, Università di Pisa (Italy), where he is currently assigned research and teaching activities. His research interests are in theoretical and practical aspects of concurrent computing, in dynamic analysis of multithreaded programs, and in system-level simulation of embedded systems. Moreover, in the embedded systems field, he worked on performance evaluation and methodological approaches to the design of multi-core SoCs. He is a member of IEEE Computer Society.

Richard J. Botting was a programmer and mathematician in the 1960s. In 1971, he earned his PhD in Computer Science at Brunel University (UK). He was on the faculty of Computer Science for seven years. He became a trainer in British Civil Service College. He helped develop SSADM. In 1982, he moved to California State University, San Bernardino, USA, and founded the Computer Science Department, becoming its first chair. He was in the fifth and eighth editions of 'Who's Who Among America's Teachers'. He maintains a web site on his research into the theory and practice of software development. He is currently focusing on the UML, agile ways to use mathematics while developing software, and mathematical models of software processes.

Giacomo Cabri is a research associate in Computer Science at the Università di Modena e Reggio Emilia, Italy. He received a Laurea degree in Electronic Engineering from the University of Bologna (1995) and a PhD in Computer Science from the University of Modena and Reggio Emilia (2000). He is affiliated with the Department of Information Engineering at Modena. His research interests include methodologies, tools and environments for agents and mobile computing, wide-scale network applications, and object-oriented programming.

Carl K. Chang is professor and chair of the Department of Computer Science at Iowa State University (USA). He received a PhD in Computer Science from Northwestern University and worked for Bell Laboratories before joining the academia. His research interests include software engineering and net-centric computing. He published extensively in these areas. He was editor-in-chief of IEEE Software from 1991-94. As a fellow of IEEE, he currently serves as the 2004 president of IEEE Computer Science.

Yifeng Chen received his BSc degree in Computer Science from Peking University and stayed there for a year as a research assistant. He studied as a research student at Oxford University Computing Laboratory and received a DPhil (Balliol College, Oxford) in 2001. He was appointed to a university lectureship in the Department of Computer Science, University of Leicester in 2000. The theoretical aspects of his research lie in predicative semantics of various computational models including parallelism, object-orientation and multi-threading. His practical research involves applying semantic theories to the design of a programming language called FLEXIBO that supports object-oriented program development in a decentralized environment like Internet. His past research also covered some aspects of neural computing and pattern recognition.

Josie Huang has worked in business field from 1992-1999 in Taiwan, where she gained particular interest in risk management and information technology combined work experience as an accountant, external and internal auditor in financial service and computer peripheral manufacturing company. She currently is a PhD student on evaluation of collaborative systems to support a virtual enterprise and also a research assistant in the DIECoM project in Glasgow Caledonian University, School of Computing and Mathematical Sciences, UK.

Qingning Huo is a software developer at Lanware Ltd., London and a part-time PhD student with the Department of Computing of Oxford Brookes University. He received his BSc and MSc in Computer Science from Huazhong University of Science and Technology and Nanjing University in China, respectively. His research interests include software testing, agent technology and web-based information systems. He has published a number of papers on this topic.

Marco Iori obtained a Laurea degree in Computer Science Engineering from the Università di Modena e Reggio Emilia, Italy (2003). He developed his thesis during a period of training at OTConsulting, where he explored the world of management and evolution of classes in an automated way. His interests include methodologies and tools for metamodeling, object-oriented programming, and management of information through XML technology.

Stan Jarzabek is an associate professor with the Department of Computer Science, School of Computing, National University of Singapore (NUS) and an adjunct associate professor with the Department of Electrical & Computer Engineering, University of Waterloo. He received his Master in Mathematics and PhD in Computer Science from the Warsaw University. He spent 12 years of his professional career in industry. Stan's current interest is the application of meta-programming techniques to achieve software engineering goals, such as enhanced reusability and maintainability. Stan has worked on software reuse (product line approach), component-based software engineering, static program analysis, reverse engineering, programming environments and compiler-compilers. He has published 70 papers in international journals and conference proceedings (his recent paper received the ACM SIGSOFT distinguished paper award). He has also given courses for industry on software reuse and reengineering. From 2000-2002, he was a principal investigator in collaborative projects involving universities (NUS and the University of Waterloo) and companies in Singapore and Toronto. Stan joined NUS in 1992. From 1990-1992, he was a research manager with CSA Research Pte. Ltd. (a company developing CASE tools). From 1984-1989, he was an assistant professor at McMaster University, Hamilton, Canada, doing research on software engineering. From 1998-1999, he was on sabbatical leave from NUS, at the Fraunhofer Institute for Experimental Software Engineering, Germany, and at the University of Waterloo, Canada.

Ping Jiang is a lecturer in Cybernetics, Internet and Virtual Systems at the University of Bradford, Bradford (UK), and a professor in Information and Control at Tongji University, Shanghai, China. From 1998-2000, he was an Alexander von Humboldt research fellow in Lehrstuhl fuer Allgemeine und Theoretische Elektrotechnik, Universitaet Erlangen-Nuernberg, Germany. From 2002-2003, he was a senior research fellow on the Framework V project DIECoM at Glasgow Caledonian University, Glasgow, UK. His research interests include virtual organization; multi-agent; control theory and application; learning control and neural networks; distributed control system; robotics; robot vision; product configuration management.

He Jifeng is a senior research fellow in the International Institute for Software Technology of the United Nations University since 1998. He has been a distinguished researcher in the Programming Research Group at the Oxford University Computing Laboratory during 1983-1998. He is also a professor of Computer Science at East China Normal University in Shanghai. His main research interests include theories of concurrency, design techniques for safety-critical systems, and linking theories of programming. The book of his and C.A.R. Hoare on unifying theories of programming is now widely studied by people working on linking theories. He is the chair of the steering committee of the International Conference on Formal Engineering Methods (ICEFM) and PC members of many international conferences on formal method and theories of computing.

Xiaoshan Li is an associate professor at the University of Macau. He earned his PhD from the Institute of Software, the Chinese Academy of Sciences (1994). His research interests include formal methods, object-oriented software engineering with UML, component-based and model-driven software development, and software testing.

Jing Liu graduated from Shanghai University and received her PhD in computer software theory in 2004. She is an associate professor of computer science and technology department of Shanghai University. She worked as a fellow of International Institute of United Nations University in 2003 and 2004. Her research areas include software architecture, development processes and application of formal methods in system development.

Zhiming Liu received an MSc from the Institute of Software, the Chinese Academy of in 1987 and a PhD in 1991 at the University of Warwick, England. His research area is in Formal Models and Theories of Computing and Formal Methods in Software Engineering. He is internationally known for his work on a transformational approach to fault-tolerant and real-time system development, and his recent work on object-oriented, component-based, and UML-based software development. He was a PC Co-Chair of the Second International Conference on Software Engineering and Formal Methods (SEFM04), the PC Chair of the FME04 Workshop on Formal Aspects of Component Software (FACS03), and PC members of a number of international conferences on formal engineering methods. Dr. Liu is a member of ACM.

Neil Loughran is a researcher in the Computing Department at Lancaster University (USA). His interests involve variability realization mechanisms and using aspect orientation programming (AOP) and frame technology ('framed aspects') to provide support for software configuration, evolution, reuse and product line architectures. His other interests are use of AOP in mobile systems, databases and asset mining.

Dingding Lu is a PhD student studying with Dr. Carl K. Chang in the Department of Computer Science at Iowa State University (USA). Her research interests include software architecture based requirement engineering and requirement engineering for software application families. Lu obtained an MS of Computer Science from Iowa State University and a BS of Applied Math and Information Science from Zhejiang University in China.

Robyn R. Lutz is an associate professor with the Department of Computer Science at Iowa State University (USA) and a senior engineer at the Jet Propulsion Laboratory, California Institute of Technology. She received a PhD from the University of Kansas. Her research interests include software safety, safety-critical product lines, defect analysis, and the specification and verification of requirements, especially for fault monitoring and recovery. Her research is supported by NASA and by the National Science Foundation. She is a member of IEEE and of the IEEE Computer Society.

Quentin Mair is a senior lecturer at Glasgow Caledonian University, UK. He was a research assistant at the University of Stirling (1986-1990) where he developed software tools for the Esprit DESCARTES project (formal specification of real-time systems). Since 1991, he has been a member of academic staff in the Division of Computing at Glasgow Caledonian University where his interests cover programming, operating systems and distributed systems. Between 1997 and 2003 he contributed to the Framework 4 VISCOUNT and Framework 5 DIECoM projects. He is currently studying toward a PhD; his thesis is in the area of distributed software configuration management.

María del Mar Gallardo is associate professor with the Department of Computer Science of the University of Málaga (Spain). She received a PhD in Computer Science from the same university (1997) with a thesis on the use of abstract interpretation to improve the execution of concurrent logic languages. Her work is currently focused on abstract model checking. For more information, visit: http://www.lcc.uma.es/~gallardo. To contact: gallardo@lcc.uma.es

Jesus Martínez is an assistant lecturer with the University of Málaga (Spain), where he obtained his MSc in Telecommunications Engineering (2000). He is a PhD candidate in the software engineering program of the Computer Science Department. His research is focused on using formal methods and model-checking in distributed computing and programmable routing devices, along with the full integration of these techniques within development environments, CASE and UML related tools using XML. To contact: jmcruz@lcc.uma.es

Tom Mens received a Licentiate in Mathematics, an Advanced Master in Computer Science, and a PhD in Science at the Vrije Universiteit Brussel (Belgium). He has been a teaching and research assistant, a research councellor for industrial research projects, and a postdoctoral fellow of the Fund for Scientific Research - Flanders. Since October 2003, he has lectured on software engineering and programming languages at the Universiteir de of Mons-Hainaut (Belgium). He has published numerous peer-reviewed articles on the topic of software evolution, and has been active in many international workshops and conferences. He is cofounder and coordinator of two international scientific research networks on software evolution. He is a co-promotor of an interuniversity research project on software refactoring.

Pedro Merino earned a PhD in Computer Science (1998). He is associate professor at the University of Málaga (Spain). He works on model checking for software and for communication protocols. He is also interested in active networks, especially in the integration of performance and safety analysis. For more information, visit: http://www.lcc.uma.es/~pedro. To contact: pedro@lcc.uma.es

Julian Newman is a reader in Computing at Glasgow Caledonian University, UK, and convener of the Communications, Collaboration and Virtual Enterprises research group (C2AVER). He has previously worked at International Computers Limited, Heriot-Watt University, Ulster Polytechnic and City of London Polytechnic. His current research interests are in enabling technologies for distributed and virtual organizations, in computer supported collaborative work and in theories of information. He was a co-investigator on the CEC Framework V project DIECoM, and is currently Principal Investigator on the EPSRC project "Role Based Access Control for the Evolution of Tertiary Courseware". He is a member of the ACM, the AIS and the UKAIS.

Alan O'Callaghan is a senior lecturer in the Faculty of Computing Sciences and Engineering at De Montfort University (DMU) (UK) and a researcher in its Software Technology Research Centre. He is DMU's representative to the Object Management Group and is on the advisory board of Hillside (Europe), the Patterns' Movement's facilitating body in Europe. He has authored four books and more than 70 papers and articles in the areas of object orientation, software architecture and software patterns, and regularly delivers consultancy and training to industry on UML, object technology and patterns.

Ray Paul has been a professional electronics engineer, software architect, developer, tester and evaluator for the past 24 years, holding numerous positions in the field of software engineering. Currently, he serves as the deputy for C2 Metrics and Performance Measures for Software for the Department of Defense (DoD) chief information officer (CIO) (USA). In this position, he supervises development of objective, quantitative data on the status of software resources in DoD information technology (IT) to support major investment decisions. These metric data are required to meet various congressional mandates, most notably the Clinger-Cohen Act. He holds a doctorate in software engineering and is an active member of the IEEE Computer Society. He has published more than 50 articles on software engineering in various technical journals and symposia proceedings, primarily under IEEE sponsorship.

Ernesto Pimentel is a full professor at the University of Malaga (Spain). He earned his PhD in Computer Science (1993). His research activity is related with the application of formal methods to software engineering, including topics like models for concurrency, component-based software development, and abstract model checking. More information, visit: http://www.lcc.uma.es/~ernesto.

Cosimo Antonio Prete is a full professor of Computer Engineering at the Università di Pisa (Italy). His research interests include graphical user interfaces, multiprocessor architectures, cache memory, and embedded systems. He has performed research in programming environments for distributed systems, in commit protocols for distributed transactions, in cache memory architecture and in coherence protocols for tightly coupled multiprocessor systems. He acted as project manager for several projects funded by the European Commission and by IT companies. He is a member of IEEE Computer Society and ACM.

Bing Qiao is a full-time PhD student at the Software Technology Research Laboratory of De Montfort University, UK. He earned BSc and MSc in Computer Science from Northwestern Polytechnical University in China, in 1998 and 2001 respectively. His research interests focus on software reengineering, reverse engineering, UML/XML modelling and web development and evolution. He has a number of publications on those topics.

Awais Rashid is a lecturer in the Computing Department at Lancaster University, UK. He holds a BSc in Electronics Engineering with Honours from the University of Engineering and Technology, Lahore, Pakistan, an MSc in Software Engineering Methods with Distinction from the University of Essex, UK, and a PhD in Computer Science from Lancaster University, UK. His principal research interests are in aspect-oriented software engineering, extensible database systems and aspect-oriented database systems. He is a member of the IEEE and the IEEE Computer Society.

Andrea Salvarani is an application architect at OTConsulting in Reggio Emilia, Italy. He received a Laurea degree in Computer Science Engineering from the University of Modena (1998). Since 1999, he has been responsible for the research & development team at OTConsulting and collaborates with the University of Modena and Reggio Emilia on new technologies. His research interests include architectures, methodologies and object-oriented programming.

Jocelyn Simmonds received the a Bachelor of Science in Computer Engineering from the Universidad de Chile, and a Master of Science in Computer Science in the international master's programme co-organised by the Ecole des Mines de Nantes (France) and the Vrije Universiteit Brussel (Belgium). She has been a teaching assistant for the introductory courses on computer science and software engineering at the Universidad de Chile. Her MSc thesis studied the use of Description Logics as a way to maintain the consistency of evolving UML models.

Wei-Tek Tsai received a PhD (1986) and MS (1982) in Computer Science from the University of California at Berkeley, California, and an SB (1979) in Computer Science and Engineering from MIT, Cambridge, Massachusetts. He is now a professor of Computer Science and Engineering at Arizona State University, Tempe, Arizona (USA). Before coming to Arizona, he was a professor of Computer Science and Engineering at the University of Minnesota, Minneapolis. His main research areas are software testing, software engineering, embedded system development. His work has been sponsored by DoD, NSF, Intel, Motorola, Hitachi Software Engineering, Fujitsu, US WEST, Cray Research, and NCR/Comten.

Xiao Wei graduated with a degree in Computer Science from Zhejiang University (2002) and is currently a PhD student in the Department of Computer Science at Arizona State University (USA). His main research areas are associated with pattern-oriented testing technique and system requirement completeness and consistency analysis.

Ragnhild Van Der Straeten received a Licentiate degree in Applied Mathematics at the Universiteit Gent (Belgium). She received a Licentiate degree in Applied Computer Science at the Vrije Universiteit Brussel (Belgium). She is a teaching assistant and PhD student at the System and Software Engineering Lab at the Vrije Universiteit Brussel. She has published peer-reviewed international articles on the topic of consistency maintenance between UML models.

Lian Yu received her Doctor of Engineering degree from Yokohama National University (Department of Electrical and Computer Engineering) in 1999. She joined the faculty of the Department of Information Systems and Science from 1999-2000. She is a faculty associate at the Department of Computer Science and Engineering of Arizona State University (USA). Her main research areas are software engineering, validation and verification, parallel machines scheduling, fuzzy inference to production management problems, distributed computing, Web services and supply chain management.

Hongyu Zhang received a PhD in Computer Science from the School of Computing, National University of Singapore (2003). Since November 2003, he has been a lecturer at the School of Computer Science and Information Technology, RMIT University, Melbourne, Australia. His current research areas include software reuse, product line development, variability mechanism, generative programming, software engineering and knowledge engineering.

Weishan Zhang is a lecturer at the School of Software Engineering, Tongji University, China. He received his BSc, master's degree and PhD from Northwestern Polytechnical University. From September 2001 to September 2003, he was doing postdoctoral research at the Software Engineering Lab, Department of Computer Science. His research interests include software engineering especially software reuse techniques, management information system, and computer integrated manufacturing system.

Hong Zhu received a BSc, MSc and PhD in Computer Software from Nanjing University (1982, 1984 and 1987, respectively). He is a senior lecturer in computing at the Department of Computing of Oxford Brookes University, UK. Dr. Zhu worked at Brunel University and the Open University as a research fellow (1990-1994), and as a professor at Nanjing University before joining Oxford Brookes University in 1998. His research interests cover several areas in software engineering, which include software testing, agent-oriented software development, software automation, requirements engineering, etc. He has published over 80 research papers in journals and conference proceedings.


Preface

This book provides a forum where expert insights are presented on the subject of linking together three current phenomena: Software Evolution, UML, and XML.

What These Three Are

Having not been clearly defined (IEEE, 1993; ISO, 1995), software evolution is the set of activities, both technical and managerial, that ensures that software continues to meet organisational and business objectives in a cost-effective way (RISE, 2004). It reflects a controlled approach to system change (Warren, 1999).

UML (Unified Modeling Language) is a language for specifying, visualising, constructing, and documenting the artifacts of an object-oriented software-intensive system under development. The language is a unifier of proven software modeling languages already existing in the early 1990s, which reflects what a unification project set out to achieve: to model systems, to address issues of scale, and to create a modeling language (Booch, Rumbaugh, & Jacobson, 1998).

XML (Extensible Markup Language) is a toolkit for creating, shaping, and using markup languages. XML will make it possible to create hundreds of new markup languages to cover every application and document type. It is a general-purpose information storage system, with features such as ensuring document integrity, formatting documents, and supporting culture localisation (Ray, 2003).


Why These Three

Each of the three, in their own rights, is a relatively independent and huge subject.

Software evolution was a relatively less important part in software life cycle in software engineering but has presently been becoming a crucial part of software life cycle (Sommerville, 2001). It can be confidently stated, without using any references that the cost of software evolution makes up a considerable proportion, sometimes even 70 to 80%, of the total budget of a software system. Software evolution has been tackled by different methods, (e.g., Yang & Ward, 2003) and a road map was drawn (Bennett & Rajlich, 2002).

In the meantime, developments in UML (launch of UML 2.0 version) (UML, 2004; Fowler, 2003) and XML (launch of XML 1.1 version) (XML, 2004) have made them dramatically more powerful. Sometimes, UML and XML have been hailed as panaceas, standards, frameworks, 21st century languages, and so forth.

It is high time to link software evolution coherently with UML and XML, with a hope that UML and XML will help to solve software evolution problems.


How to Link These Three

What has happened and what will happen when these three are linked to work together has been partly answered, ranging from theory and engineering to tools, by authors of this book.

It is observed that nowadays software starts evolving before it is delivered, in order to meet users' requirements and to be in touch with technology advances, and therefore it is best that work on evolution should start accordingly at the infancy of software development. Because UML and XML are with software development at the very beginning in most projects, it is natural to involve UML and XML in software evolution throughout a software systems' life cycle. For example, UML can be the target platform for reverse engineering existing software during software evolution, on which legacy software can be comprehended and new user requirements can be integrated for forward engineering, and XML can be a global communication mechanism during software evolution.

Software evolution has been seriously studied for a good number of years (Lehman, 1980, 1985); however, today it is still one of the seven grand challenges in computing (Bennett, Budgen, Hoare, & Layzell, 2004).

If UML technology will develop to the stage that Booch (Norfolk, 2004) predicted (executable UML, where it needs not look like UML to mere mortals but uses UML semantics and becomes a UML metamodel underneath), software evolution will become "direct" evolution, that is, only UML dialogue boxes will be evolved.


References

Bennett, K. H., & Rajlich, V. T. (2002). Software maintenance and evolution: A road map. IEEE International Conference on Software Engineering. Dublin, Ireland.

Bennett, K. H., Budgen D., Hoare, C. A. R., & Layzell, P. (2004). Grand challenges –Software evolution. Conference on Grand Challenges in Computing, British Computer Society, Newcastle upon Tyne, UK.

Booch, G., Rumbaugh, J., & Jacobson I. (1998). The Unified Modeling Language user guide. Boston: Addison-Wesley.

Fowler, M. (2003). UML distilled: A brief guide to the standard object modelling language (3rd ed.). Boston: Addison-Wesley.

IEEE (1993). IEEE standard 1219: Standard for software maintenance. Los Alamitos, CA: IEEE Computer Society Press.

ISO (1995). ISO 12 207 Information technology – Software life cycle processes. Geneva, Switzerland: International Standards Organisation.

Lehman, M. M. (1980). On understanding laws, evolution and conversation in the large program lifecycle. Journal of Software and Systems, 1, 213–221.

Lehman, M. M. (1985). Program evolution. London: Academic Press.

Norfolk, D. (2004). Grany Booch: Bulletin interview. The Computer Bulletin. Swindon, UK: The British Computer Society.

Ray, E. (2003). Learning XML (2nd ed.). Sebastopol, CA: O'Reilly.

RISE (2004). Webpage of Research Institute for Software Evolution (RISE), formerly the Centre for Software Maintenance (CSM), University of Durham, England, http://www.dur.ac.uk/CSM/

Sommerville, I. (2001). Software Engineering (6th ed.). Boston: Addison-Wesley.

UML (2004). UML resource page. Object Management Group, http://www.uml.org

Warren, I. (1999). The renaissance of legacy systems - Method support for software system evolution. London: Springer-Verlag.

XML (2004). Website of World Wide Web Consortium. http://www.w3.org/TR/xml11/

Yang, H., & Ward, M. (2003). Successful evolution of software systems. Norwood, MA,: Artech House.


Organisation of this Book

The book is organised into 12 chapters; a brief description of each chapter follows.

Chapter 1, A Framework for Managing Consistency of Evolving UML Models, is by T. Mens, R. Van Der Straeten, and J. Simmonds. This chapter suggests that the UML metamodel and contemporary CASE tools must provide adequate and integrated support for software evolution in all aspects: version control, traceability, impact analysis, change propagation, inconsistency management, and model refactoring. Through proposing a framework, the chapter focuses on inconsistency management and model refactoring, by extending the UML metamodel with support for versioning, making a classification of the possible inconsistencies of UML design models, and using a formalism of description logics.

Chapter 2, Deriving Safety-Related Scenarios to Support Architecture Evaluation, is by D. Lu, R. R. Lutz, and C. K. Chang. This chapter introduces an analysis process that combines the different perspectives of system decomposition with hazard analysis methods to identify the safety-related use cases and scenarios, which are the detailed instantiations of system safety requirements for helping with software architectural evaluation. By modeling the derived safety-related use cases and scenarios into UML diagrams, visualisation of system safety requirements will help to enrich the knowledge of system behaviours and to provide a reusable asset to support system development and evolution.

Chapter 3, A Unified Software Reengineering Approach towards Model-Driven Architecture Environment, is by B. Qiao, H. Yang, and A. O'Callaghan. Software evolution can be achieved effectively from an architectural point of view, and the OMG's Model Driven Architecture provides a unified framework for developing middleware-based modern distributed systems and a definite goal for software evolution. This chapter presents a unified software reengineering approach towards the Model- Driven Architecture environment, which consists of a framework, a process, and related techniques.

Chapter 4, Towards the Integration of a Formal Object-Oriented Method and Relational Unified Process, is by J. Liu, Z. Liu, X. Li, H. Jifeng, and Y. Chen. This chapter presents a formal object—oriented method within Relational Unified Process (RUP), for unifying different views of UML models, to improve the quality of software, and for scaling up the use of the formal method with the use-case-driven, iterative, and incremental aspects of RUP.

Chapter 5, On the Co-Evolution of SSADM and the UML, is by R. J. Botting. This chapter shows how a system developed using the Structured Systems Analysis and Design Methodology (SSADM) can evolve to fit UML and XML. Many SSADM-designed systems are still in use, and therefore evolving SSADM designs to use UML and XML is important.

Chapter 6, Software Evolution with XVCL, is by W. Zhang, S. Jarzabek, H. Zhang, N. Loughran, and A. Rashid. During software system evolution many variants will arise because of the variant requirements and software architecture needs to be transformed to mitigate the architecture erosion problem. To facilitate evolution it is essential to ensure traceability from variants in high-level software models to architecture and to code components, test cases, and so forth. Metaprogramming is a method to generate source code in a target language from a program specification in a high-level language, and an XML-based metaprogramming technology named XVCL is developed in order to address the problems.

Chapter 7, UML and XML-Based Change Process and Data Model Definition for Product Evolution, is by P. Jiang, Q. Mair, J. Newman, and J. Huang. This chapter presents a software architecture and implementation to support in-service product configuration management applicable to both the automotive and aerospace industries: defining an exchangeable multidomain enterprise data model using an XML DTD, presenting a UML process model for configuration change management, developing a framework to show how exported XMI definitions can be translated into WfMC XPDL, and describing an evolution process for in-service embedded software using the OSGi Framework.

Chapter 8, Rapid Pattern-Oriented Scenario-Based Testing for Embedded Systems, is by W. T. Tsai, R. Paul, L. Yu, and X. Wei. Systems often change, and each change requires reverification and revalidation. Modern software development processes such as agile process even welcome and accommodate frequent software changes. Traditionally, software reverification and revalidation are handled by regression testing. This chapter presents a pattern-oriented scenario-based approach to rapidly reverify and revalidate frequently changed software.

Chapter 9, Developing a Software Testing Ontology in UML for a Software Growth Environment of Web-Based Applications, is by H. Zhu and Q. Huo. In order to support sustainable long-term evolution of software systems executing on Web-based platforms, this chapter proposes a multiagent software growth environment, and designed and implemented a prototype system with emphasis on testing and quality assurance.

Chapter 10, Abstracting UML Behavior Diagrams for Verification, is by M. del Mar Gallardo, J. Martínez, P. Merino, and E. Pimentel. This chapter discusses the combined use of UML and XML in the domain of software abstraction for verification. In particular, UML- based software development environments are now including verification capabilities based on state exploration.

Chapter 11, Support for Architectural Design and Re-Design of Embedded Systems, is by A. Bechini and C. A. Prete. This chapter addresses the architectural design and redesign of embedded systems from a methodological viewpoint, taking into account both the hardware and software aspects, to find out the most convenient structure for the investigated system.

Chapter 12, Describing and Extending Classes with XMI: An Industrial Experience, is by G. Cabri, M. Iori, and A. Salvarani. This chapter reports on industrial experience about the management and the evolution of object classes in an automated way. The proposed approach enables the description of classes via XML documents, and allows the evolution of such classes via automated tools which manipulate the XML documents in an appropriate way.


Chapter I: A Framework for Managing Consistency of Evolving UML Models

Tom Mens,
Université Mons-Hainaut,
Belgium
Ragnhild Van Der Straeten,
Vrije Universiteit Brussel,
Belgium
Jocelyn Simmonds,
Universidad de Chile,
Chile

As the standard for object-oriented analysis and design, the UML (Unified Modeling Language) metamodel, as well as contemporary CASE (Computer-Aided Software Engineering) tools, must provide adequate and integrated support for all essential aspects of software evolution. This includes version control, traceability, impact analysis, change propagation, inconsistency management, and model refactorings. This chapter focuses on the latter two aspects, and shows how tool support for these aspects can be provided. First, we extend the UML metamodel with support for versioning. Second, we make a classification of the possible inconsistencies of UML design models. Finally, we use the formalism of description logics, a decidable fragment of first-order predicate logic, to express logic rules that can detect and resolve these inconsistencies. We also show how the logic rules are used to propose model refactorings. As a proof of concept, we report on the results of initial experiments with a prototype tool we developed for this approach.

A Framework for Managing Consistency of Evolving UML Models

Introduction

Any software system that is deployed in a real-world setting is subject to evolution (Lehman, Ramil, Wernick, Perry, & Turski, 1997). Because of this, it is crucial for any software development process to provide support for software evolution during all development phases. This includes support for version control (Conradi & Westfechtel, 1998), traceability management and change impact analysis (Bohner & Arnold, 1996), change propagation (Rajlich, 1997), inconsistency management (Finkelstein, Gabbay, Hunter, Kramer, &Nuseibeh, 1993; Grundy, Hosking, & Mugridge, 1998; Spanoudakis & Zisman, 2001), and software restructuring (Opdyke, 1992; Fowler, 1999).

Since design forms an essential part of the software development process, the activities mentioned above should not be restricted to source code, but should affect design models as well. Since UML (Unified Modeling Language) is the generally accepted object-oriented design standard, it ought to play an essential role in software evolution. Unfortunately, contemporary tools and environments for UML do not provide adequate and integrated support for many of the essential aspects of software evolution indicated above. The main underlying cause of all the problems mentioned is that the UML metamodel itself provides very poor support for software evolution. Hence, we do not only need to address the problem from a technical point of view (tool support), but from a conceptual point of view as well (metamodel support). If we have such an "evolution aware" UML metamodel, we should be able to come up with an "evolution framework" that allows us to address the various evolution aspects in a uniform and integrated way. This is summarised in Figure 1, which illustrates the different kinds of evolution activities that an ideal UML tool should be able to perform.

Click To expand
Figure 1: Tool support for evolving UML models

Such tool support is crucial because of the inherent complexity of UML design models, which are typically expressed as a (large) collection of interdependent and partially overlapping UML diagrams. Different aspects of the software system are covered by different types of UML diagrams. Because of the wide variety of different types of UML diagrams, and the many relationships between them, managing all these diagrams is a very complex task. To make it even more complex, as the software evolves, those diagrams need to undergo changes to correct errors, accommodate new requirements, and so on. Any of those changes may lead to inconsistencies within or across UML diagrams, and may in turn require subsequent changes to other elements in the UML diagrams. An additional problem is that changes to the design may necessitate changes in the source code as well, and vice versa. All of this contributes to the complexity of the problem, making tool support crucial.

The inherent complexities of UML design models will continue to grow as these models evolve, following Lehman's second law of software evolution: "As a program is evolved its complexity increases unless work is done to maintain or reduce it" (Lehman et al., 1997). To counter this growing complexity, we need techniques that restructure the design to improve its quality and reduce its complexity. Such techniques, called model refactorings, are the design level equivalent of source code refactorings that have been thoroughly studied in literature (Opdyke, 1992; Fowler, 1999; Mens & Tourwé, 2004).

When we look at contemporary CASE (Computer-Aided Software Engineering) tools for UML, they provide poor support for the problems mentioned above that are induced by evolving UML models. Hence, the goal is to provide better tool support for UML model evolution, preferably in a uniform way. This chapter initiates a first attempt in this direction, by providing a framework for design model evolution based on the formalism of description logics. We report on some experiments with a prototype tool that we developed to illustrate how this formalism can tackle the problems of inconsistency management and model refactoring in a uniform way. Practical validation in an industrial setting is not yet possible, since this requires the implementation and integration of our approach in a full-fledged contemporary UML environment. Such integration is too premature given the current state of research, as there are many open research problems that remain to be solved.

Basic Definitions for Evolution Support Techniques

In this section, we provide definitions for the following evolution concepts: version control, traceability management, change propagation, change impact analysis, software restructuring, inconsistency management, and round-trip engineering.

Traceability is defined as the "degree to which a relationship can be established between two or more products of the development process, especially products having a predecessor-successor or master-subordinate relationship to one another. For example, the degree to which the requirements and design of a given software artefact match" (IEEE, 1999). As shown in Figure 2, two types of traceability, namely horizontal and vertical traceability, can be identified (IEEE, 1999). Vertical traceability expresses relationships between software artefacts in the same phase of the software life cycle. Horizontal traceability expresses relationships between software artefacts that reside in different phases of the software life cycle, for example, dependencies between a requirements specification and a design model. Emphasizing traceability reduces maintenance costs and improves the quality of aspects of the software development process. Traceability analysis involves examining dependency relationships among software artefacts of the same kind or between software artefacts at different phases of the software life cycle, for example, a dependency between a requirements specification and a corresponding design model.

Click To expand
Figure 2: Horizontal and vertical traceability relationships

If a software entity is modified, it is possible that this change propagates to other entities that need modification too. Change propagation occurs when making a change to one part of a software system requires other system parts that depend on it to be changed as well (Rajlich, 1997). These dependent system parts can on their turn require changes in other system parts. In this way, a single change to one system part may lead to a propagation of changes to be made throughout the entire software system.

Impact analysis is defined as the "process of identifying the potential consequences (side effects) of a change, and estimating what needs to be modified to accomplish a change" (Bohner & Arnold, 1996). Impact analysis tries to assess the impact of changes on the rest of the system: when a certain software entity changes, which system parts will be affected, and how will they be affected? This knowledge is particularly helpful to predict the cost and complexity of changes and to help decide whether to implement these changes in a new release.

A version of a software artefact represents a snapshot in the evolution history of that software artefact. If concurrent changes are made to software artefacts, different versions of the same software artefact may exist at the same moment in time. Version control manages the simultaneous changes made by multiple users to a collection of software artefacts, without having version confusion (Ohst, Welle, & Kelter, 2003). Version control is essential when developing software with large teams, where different people may make concurrent changes to diagrams. If we use state-based versioning, we need tools to compare differences between successive versions of the same software artefact. If we use change-based versioning, we need tools that relate different versions based on the sequence of changes that was used to obtain the new version from an earlier one (Conradi & Westfechtel, 1998).

Software restructuring is "the transformation from one representation form to another at the same relative abstraction level, while preserving the subject system's external behaviour (functionality and semantics)…. While restructuring creates new versions that implement or propose change to the subject system, it does not normally involve modifications because of new requirements. However, it may lead to better observations of the subject system that suggest changes that would improve aspects of the system. Restructuring is often used as a form of preventive maintenance to improve the physical state of the subject system with respect to some preferred standard" (Chikofsky & Cross, 1990). In an object-oriented context, the term refactoring is used instead of restructuring (Opdyke, 1992; Fowler, 1999). Therefore, we will use the term model refactoring when we are talking about restructurings of object-oriented design models.

Design models describe the system from different viewpoints and at different levels of abstraction and granularity. These models may also be expressed using different notations, and different software developers can be involved in the software modeling process. All these issues are bound to lead to inconsistencies among models. An inconsistency is informally described as "a state in which two or more overlapping elements of different software models make assertions about aspects of the system they describe which are not jointly satisfiable" (Spanoudakis & Zisman, 2001). Overlaps are defined as "relations between interpretations ascribed to software models by specific agents" (Spanoudakis & Zisman). Inconsistency management has been defined by Finkelstein, Spanoudakis, and Till (1996) as "the process by which inconsistencies between software models are handled so as to support the goals of the stakeholders concerned." Nuseibeh, Easterbrook, and Russo (2000) propose general frameworks describing the activities of this process. Both approaches agree that the process of managing inconsistencies includes activities for detecting, diagnosing, and handling them. These activities are extended by Spanoudakis and Zisman: detection of overlaps, detection of inconsistencies, diagnosis of inconsistencies, handling of inconsistencies, tracking, and specification and application of an inconsistency management policy. Additionally, Spanoudakis and Zisman present a survey of techniques and methods supporting the management of inconsistencies.

Co-evolution refers to the set of tools and techniques to keep software entities in different levels of the software lifecycle synchronised when the software evolves. This encompasses techniques such as code generation and reverse engineering. A special notion of co-evolution is round-trip engineering. Round-trip engineering is the "seamless integration between design and source code, between modeling and implementation. With round-trip engineering a programmer generates code from a design, changes that code in a separate development environment, and recreates the adapted design diagram back from the source code" (Demeyer, Ducasse, & Tichelaar, 1999).


Current Support for UML Model Evolution

Co-evolution is mostly studied in the context of the synchronisation of design and source code artefacts. Wuyts (2001) uses logic metaprogramming to support co-evolution between object-oriented design and source code. He implemented a synchronisation framework, SOUL, that provides a layered library of logic rules that allows reasoning about Smalltalk code. Del Valle (2003) uses this framework to provide general support for round-trip engineering between UML models and Java source code. As argued in Demeyer et al. (1999), UML by itself is insufficient to serve as a tool-interoperability standard for integrating round-trip engineering tools. In Van Gorp, Stenten, Mens, and Demeyer (2003), extensions to the UML metamodel are proposed to provide better support for the round-trip engineering process. However, when we look at contemporary UML CASE tools, they typically have some support in place for managing traceability and round-trip engineering. In Together® (Borland, 2004), for example, changes in the code are reflected in the class diagram automatically. In Nickel, Niere, and Zündorf (2000), the focus is on round-trip engineering support not only for UML class diagrams but also for UML behaviour diagrams.

For the aspects of change propagation, impact analysis, version control, and inconsistency management, much less design-level tool support is available. Therefore, there is currently a lot of emphasis on these issues within the research field.

Design-level support for impact analysis has been proposed by Briand, Labiche, and O'Sullivan (2003). Such support is very useful, because it allows one to look at change impacts to the system before the actual implementation of such changes. As such, a proper decision on whether to implement a particular change can be made based on what design elements are likely to get impacted. Such early decision making and change planning is crucial to reduce the cost of changes.

Version control is not supported by the UML 1.5 metamodel, and as such, also not supported by current UML CASE tools. Van Der Straeten, Mens, Simmonds, and Jonckers(2003) and Simmonds, Van Der Straeten, Jonckers, and Mens (2004) show how versions can be integrated in the UML metamodel with only some minor additions. Ohst et al. (2003) provide support for state-based versioning to address the differences between UML versions. Extensions of the UML metamodel as proposed in Simmonds et al. enable change-based versioning of UML models as well. In order to achieve such change-based versioning, however, a detailed taxonomy is needed of the different kinds of changes that can be applied to UML models. Such a taxonomy has been proposed by Briand et al. (2003).

Most of the research on software restructuring and software refactoring is restricted to programs (Opdyke, 1992;Fowler, 1999). Design critics, on the other hand, are "intelligent user interface mechanisms embedded in a design tool that analyze a design in the context of decision making and provide feedback to help the designer improve the design. Feedback from critics may report design errors, point out incompleteness, suggest alternatives, or offer heuristic advice" (Robbins, 1998). Model refactorings are the design-level equivalent of program refactorings. A set of basic UML model refactorings is provided in Sunyé, Pollet, LeTraon, and Jézéquel (2001) to improve the software design in a stepwise fashion. Boger, Sturm, and Fragemann (2002) show how model refactorings can be integrated in the Poseidon UML refactoring browser. Astels (2002) uses a UML tool to perform refactorings more easily and also to aid in code smell detection.

For inconsistency management, support at design level becomes even more crucial than at the source code level. Indeed, a UML design model is typically expressed as a (large) collection of interdependent and partially overlapping UML diagrams. Different aspects of the software system are covered by different types of UML diagrams. Because of the wide variety of different types of UML diagrams, and the many relationships between them, keeping all these diagrams mutually consistent is very difficult without proper tool support. This is especially the case if all of these diagrams can undergo changes as the software evolves.


Inconsistency Management for UML Models: Our Solution

As specified in Van Der Straeten et al. (2003) and Simmonds et al. (2004), to address the lack of inconsistency management in UML, there is first of all a need to specify the inconsistencies between (evolving) models in a formal and precise way. The current UML metamodel provides poor support for consistency preservation and software evolution. Therefore, the first contribution of this chapter is to show how to provide a UML profile that introduces support for versioning and evolution.

Based on the different kinds of inconsistencies we have observed between UML models, we propose a classification of inconsistencies. To be able to detect and resolve these inconsistencies in an automated way, we need a formal specification of model consistency and a formal reasoning engine relying on this specification. Therefore, we use the formalism of description logic (DL) (Baader, McGuinness, Nardi, & Patel-Schneider, 2003). This is a two-variable fragment of first-order predicate logic that offers a classification task based on the subconcept-superconcept relationship. While the satisfiability problem is undecidable in first-order logic, most DLs have decidable inference mechanisms. These inference mechanisms allow us to reason about the consistencies of knowledge bases specified by DLs.

The tool chain we set up is called Conan (for Consistency Analyser), and is depicted in Figure 3. As description logic tool we chose Loom (MacGregor, 1991). UML design models are expressed in the UML CASE tool Poseidon. These design models are exported in XMI (XML Metadata Interchange) format, and translated into description logics format using Saxon, an XML (Extensible Markup Language) translator. The logic code is then asserted into a knowledge base maintained by the Loom logic reasoning engine. This tool chain allows us to specify UML models, their evolution, consistency rules and model refactorings in a straightforward way and to automate the crucial activity of detecting and resolving inconsistencies.

Click To expand
Figure 3: Tool setup for managing inconsistencies in UML with description logics

We deliberately chose a tool chain, as opposed to a single integrated tool, to accommodate for the rapid evolution of standards (such as UML, XML and XMI), and to facilitate the replacement of existing tools (e.g., Loom, Saxon, or Poseidon) by other ones that are more appropriate in a specific context. The tool chain is currently in a prototyping phase, so much additional work is needed to make it applicable to industrial-size problems.


Motivating Example

We will now introduce a concrete and motivating example. The example is based on the design of an automatic teller machine (ATM), originally developed by Russell Bjork for a computer science course at Gordon University.

Figure 4 shows part of a class diagram for the ATM simulation. The class diagram contains an ATM class together with its subclass PrintingATM. Several user Sessions can be active on an ATM. An ATM possesses exactly one CashDispenser and exactly one CardReader. A PrintingATM owns exactly one ReceiptPrinter.

Click To expand
Figure 4: Class diagram for the ATM example

The sequence diagram in Figure 5, which has been simplified for space and clarity reasons, represents the behaviour of the class diagram. More specifically, it shows part of a general interaction between instances of the classes ATM, Session, CardReader, and CashDispenser, when a user decides to make a withdrawal. The messages sent in the diagram verify if there is enough cash in the ATM. If so, the amount of cash is dispensed and the card is returned to the user.

Click To expand
Figure 5: Sequence diagram for ATM example

The state diagram in Figure 6 represents the internal behaviour for the PrintingATM class, which is an ATM that has the extra printing functionality. The transitions in this state diagram indicate the permitted behaviour sequences on an instance of PrintingATM. When a customer wants to withdraw money from his account, he has to insert a bank card and enter the associated PIN number. If the PIN is not valid, the card is returned to the user. If a valid PIN has been entered, the ATM prompts the user to enter the amount to withdraw from his account. First, the ATM checks that the client's account has sufficient funds. If so, the ATM proceeds to check if it can dispense this amount. Once these checks have been passed, the ATM dispenses the money. Afterwards, the PrintingATM class, unlike its parent, the ATM class, prints a receipt. Finally, the card is ejected.

Click To expand
Figure 6: State diagram for the PrintingATM class

An idealized view of inheritance in object-oriented programming languages is formalized by the substitutability principle (Liskov, 1988). This principle states that an object of a subclass of class A can be used wherever an object of class A is required. If we want this principle to hold in our example, an instance of PrintingATM must be usable in each situation where an instance of ATM is required. To guarantee this, a consistency relationship must be specified between the sequence diagram of Figure 5 and the state diagram of Figure 6: It is important that each sequence of the ATM sequence diagram should be contained in the set of sequences of the PrintingATM state diagram.

This kind of consistency is called invocation consistency and is defined in general in Engels, Heckel, and Küster (2001). In our case, ATM and PrintingATM are not invocation consistent, because an instance of PrintingATM will, after dispensing the cash, always print a receipt. It is not possible to skip this printing and immediately eject the card, which is the original behaviour of the ATM class.


Classification of Inconsistencies

In this section we propose a classification of UML design inconsistencies. To this extent, we restrict ourselves to inconsistencies that can arise between class diagrams, sequence diagrams and state diagrams. To be even more precise, we will restrict the state diagrams to those that can be represented by a protocol state machine. This means that every transition must have as trigger a call event that references an operation of the class, and must have an empty action sequence.

Dimensions of Inconsistencies

As illustrated in Figure 7 and described in the literature, a first dimension distinguishes between three different types of consistencies.

  1. Horizontal consistency, also named intraconsistency or intramodel consistency indicates consistency between different models at the same level of abstraction, and within the same version. For example, in any UML model, the class diagrams and their associated sequence diagrams and state diagrams should be mutually consistent (Kuzniarz, Reggio, & Sourouille, 2002).

  2. Evolution consistency indicates the consistency between different versions of the same model. For example, when a class diagram evolves, it is possible that its associated state diagrams and sequence diagrams become partially inconsistent (Engels, Küster, Heckel, & Groenewegen, 2002). These inconsistencies need to be detected and resolved.

  3. Vertical consistency, also named interconsistency or intermodel consistency, indicates the consistency between models at different levels of abstraction (Kuzniarz et al., 2002). "Vertical" refers to the process of refining models and requires the refined model to be consistent with the one it refines (Engels, Küster, Heckel, & Groenewegen, 2001). For example, the source code can be considered as a refinement of the design model, and both need to be kept mutually consistent. As an important terminological side note, this terminology is not compatible with the notions of horizontal and vertical traceability ( Figure 2). For example, horizontal traceability is a prerequisite for vertical consistency and vice versa.

Click To expand
Figure 7: Three types of consistency between UML models

A second dimension, which is orthogonal to the first, distinguishes between syntactic and semantic consistencies.

  1. Syntactic consistency ensures that a specification conforms to the abstract syntax specified by the metamodel. This requires that the overall model be well formed (Engels, Küster, Heckel, & Groenewegen, 2001).

  2. Semantic consistency, with respect to horizontal consistency, requires models of different viewpoints to be semantically compatible with regard to the aspects of the system which are described in the submodels. Semantic consistency, with respect to vertical consistency, requires that a refined model be semantically consistent with the one it refines (Engels, Hausmann, Heckel, & Sauer, 2002).

A final dimension, defined in Engels, Heckel and Küster (2001), distinguishes between two specific kinds of consistency that are related to the inheritance hierarchy in object-oriented languages.

  1. Observation consistency requires that an object of the subclass always behaves like an object of the superclass, when viewed according to the superclass description. In terms of UML state diagrams (corresponding to protocol state machines) this can be rephrased as "after hiding all new events, each sequence of the subclass state diagram should be contained in the set of sequences of the superclass state diagram."

  2. Invocation consistency on the other hand, requires that an object of a subclass of a certain class can be used wherever an object of that certain class is required. In terms of UML state diagrams (corresponding to protocol state machines), each sequence of the superclass state diagram should be contained in the set of sequences of the state diagram for the subclass. As we already explained before, the motivating ATM example of the previous section is observation consistent but not invocation consistent.

Detailed Classification of Inconsistencies

The main focus of this chapter will be on evolution consistency, and how this affects and interacts with the other kinds of consistencies. Additionally, we only address semantic consistency, as current UML CASE tools have incorporated ad-hoc support for compliance with UML well-formedness rules. Based on the different kinds of semantic inconsistencies we observed between UML class diagrams, sequence diagrams, and state diagrams, we propose a two-dimensional classification of inconsistencies.

The first dimension indicates whether structural or behavioural aspects of the models are affected. Structural inconsistencies arise when the structure of the system is inconsistent, and typically appear in class diagrams which describe the static structure of the system. Behavioural inconsistencies arise when the specification of the system behaviour is inconsistent, and typically appear in sequence diagrams and state diagrams that describe the dynamic behaviour of the system.

The second dimension concerns the level of the affected model. A class diagram belongs to the Specification level because the model elements it represents (such as classes and associations) serve as specifications for instances (such as objects, links, transitions, and events) in sequence diagrams and state diagrams belonging to the Instance level. Consequently, inconsistencies can occur at the Specification level, between the Specification and Instance level, or at the Instance level. These categories of observed inconsistencies are listed in Table 1, and are explored in detail in Simmonds (2003).

Table 1: Two-dimensional inconsistency table
 | Behavioural | Structural
Specification | invocable collaboration behaviour consistency observable collaboration behaviour inconsistency | dangling (type) reference inherited association inconsistency instance specification missing
Specification / Instance | incompatible specification | instance specification missing
Instance | invocable behaviour inconsistency observable behaviour inconsistency incompatible behaviour inconsistency | disconnected model

Behavioural Inconsistencies

The inconsistencies considered in this category refer to situations in which the behaviour of the system, as described in sequence diagrams and state diagrams, is incomplete, incompatible, or inconsistent with respect to existing behaviour or definitions.

  • Specification inconsistencies. The types of models considered at this level are class diagrams and sequence diagrams mapping into an Interaction and an underlying Collaboration (see UML metamodel version 1.5). In the UML, a sequence diagram can be expressed at "specification level" and at "instance level." The main difference is the interpretation. At instance level, a sequence diagram represents messages between objects (instances of classes), whereas at "specification level" a sequence diagram represents messages between roles played by classes. In this case, sequence diagrams at "specification level" are considered. There are no behavioural specification inconsistencies for class diagrams, because of their structural nature. For sequence diagrams, two kinds of behavioural inconsistencies are identified. An invocable collaboration behaviour inconsistency arises when the set of message sequences of the parent collaboration is not a subset of the set of message sequences of the child collaboration. An observable collaboration behaviour inconsistency arises when, after hiding the messages associated to new association roles, the set of message sequences belonging to the child collaboration is not a subset of the set of message sequences of the parent collaboration.

  • Specification/instance inconsistencies. All inconsistencies we identified here can be classified as incompatible specifications. They arise when model elements do not comply with the specifications that characterise them. Some examples: (1) a link between objects in a sequence diagram does not respect the multiplicity restrictions imposed by the class diagrams in the corresponding model; (2) a link between objects in a sequence diagram does not respect the navigability restrictions imposed on the associations in the class diagrams of the corresponding model; (3) an abstract class that has no concrete subclasses in the class diagrams of the corresponding model is instantiated in a sequence diagram.

  • Instance inconsistencies. At the instance level we have encountered three different kinds of inconsistencies.

    Invocable behaviour inconsistencies (Engels, Heckel & Küster, 2001) arise when any of the following constraints in or between sequence diagrams and state diagrams is violated: (1) each sequence of the superclass state diagram should be contained in the set of sequences of the state diagram for the subclass; (2) the ordered collection of stimuli sent by an object of the superclass should be contained in the ordered collection of stimuli sent by an object of the subclass; (3) the ordered collection of stimuli received by an object of the superclass in a sequence diagram should exist as a sequence of the state diagram for the subclass, or vice versa. An example of this last constraint violation was demonstrated in our motivating ATM example.

    Observable behaviour inconsistencies (Engels, Heckel and Küster, 2001) arise when any of the following constraints in or between sequence diagrams and state diagrams is violated: (1) after hiding all new events, each sequence of the subclass state diagram should be contained in the set of sequences of the superclass state diagram; (2) after hiding stimuli that are associated to newly introduced operations, the ordered collection of stimuli sent by an object of the subclass should be contained in the ordered collection of stimuli sent by an object of the superclass; (3) after hiding stimuli that are associated to newly introduced operations, the ordered collection of stimuli received by an object of the subclass in a sequence diagram should exist as a sequence of the state diagram for the superclass.

    Incompatible behaviour inconsistencies arise due to inconsistent behaviour specifications for a class in a model. For example, the ordered collection of stimuli received by an object in a sequence diagram does not exist as a sequence of events in the protocol state machine of the object's class. A concrete example of this conflict can be found in Simmonds et al. (2004).

Structural Inconsistencies

The inconsistencies considered in this category refer to situations in which the structure of the system, as detailed in class diagrams, is incomplete, incompatible, or inconsistent with respect to existing behaviour or definitions.

  • Specification inconsistencies. At the specification level, we identified three kinds of structural inconsistencies.

    Inherited association inconsistencies arise due to problems with inherited associations between different classes in the class diagrams of a model. For example, we can have an infinite containment when the composition (the multiplicity constraints of these composition relationships are important) and inheritance relationships between classes in the class diagrams of a model form a cycle that produces infinite containment of the instances of the affected classes.

    Dangling (type) references occur when a parameter's or attribute's type refers to a class that does not exist in any of the class diagrams of the corresponding model.

    Role specification missing occurs when a model element specification does not exist in a model but is used in a sequence diagram mapping into an Interaction and an underlying Collaboration. Many different occurrences of this problem category can be identified: (1) there is a Classifier Role in a sequence diagram whose base classifier does not exist in the class diagrams of the corresponding model; (2) a message references an action that references a non-existing operation or a nonexisting attribute; (3) an Association Role is related to an association that does not exist between the base classes of the corresponding Classifier Roles.

  • Specification/instance inconsistencies. Between models and instances, we can have the problem of missing instance specifications. This means that a model element specification does not exist in a model, as it has either been removed from a diagram or not included yet. Many different occurrences of this problem category can be identified: (1) an object in a sequence diagram is the instance of a class that does not exist in any of the class diagrams of the corresponding model; (2) the protocol state machine of a state diagram is associated to a class that does not exist in any of the class diagrams of the corresponding model; (3) a stimulus, event, guard, or action references an attribute or operation that does not exist in the corresponding class (or its ancestors); (4) a link in a sequence diagram is related to an association that does not exist between the classes of the linked objects (or between the ancestors of these classes).

  • Instance inconsistencies. At the instance level, we identified the potential problem of disconnected models. This problem is related to the topography of the diagrams, specifically, when it contains parts that are disconnected from each other. For example, a state or transition may have been deleted or omitted in a state diagram, resulting in a set of states that are not reachable from the initial state. As another example, an object or link may have been deleted or omitted in a sequence diagram, resulting in a set of objects that are unreachable. A concrete example of this conflict can be found in Simmonds et al. (2004).

UML Profile for Model Evolution

In this section we present a UML profile that supports model evolution and inconsistency management. The underlying ideas are based on earlier work to extend the UML metamodel with support for evolution (Mens, Lucas, & Steyaert, 1999; Mens & D'Hondt, 2000; Van Der Straeten et al., 2003; Simmonds et al., 2004).

The three types of consistency explained in Figure 7 can be expressed as follows in the UML metamodel. For expressing vertical consistency, we can use the UML Refinement relationship, which is a stereotype of the Abstraction metaclass. It specifies the derivation relationship between a model and a refinement of this model that includes more specific details. Horizontal and evolution consistency can be expressed by specialising the Trace stereotype of the Abstraction metaclass into Horizontal Trace and Evolution Trace, respectively. To support versioning of UML models, we introduced a VersionedElement, which is a Model Element to which the stereotype <<versioned>> is attached. It's tagged value represents the version of the corresponding model element.

All these extensions are summarised in Table 2 and Figure 8. Note that, because stereotypes are inherited by subclasses in the UML metamodel, any kind of ModelElement, including Model, can be versioned. We deliberately leave the type of value for the "version" tagged value open, so that different version control tools can use different representations of versions to suit their specific needs.

Table 2: Summary of UML profile for model evolution
Stereotype name | Base class | Parent | Tagged values
Trace <<trace>> (from Core) | Abstraction | none |
Refinement <<refine>> (from Core) | Abstraction | none |
HorizontalTrace <<horizontal>> | Abstraction | Trace |
EvolutionTrace <<evolution>> | Abstraction | Trace |
VersionedElement <<versioned>> | ModelElement | none | tagtype="version" multiplicity=1
Click To expand
Figure 8: UML metamodel changes for enabling model consistency

For the three newly introduced stereotypes HorizontalTrace, EvolutionTrace and VersionedElement, we also need to specify the following well-formedness constraints:

  • A <<versioned>> Model can only contain <<versioned>> ModelElements as owned Elements. The version of each owned Element must equal the version of the containing Model.

  • A <<horizontal>> Trace can only be specified between <<versioned>> clients and <<versioned>> suppliers that all have the same version.

  • All suppliers of an <<evolution>> Trace must be <<versioned>> and must have the same version. All clients of an <<evolution>> Trace must be <<versioned>> and must have the same version. The version of the suppliers must precede the version of the clients.

The code of these constraints appears as follows in OCL (Object Constraint Language):

context ModelElement def:
let isVersioned: Boolean =
 self.stereotype->name->includes("versioned")
let getVersion: TaggedValue =
 self.stereotype->any(name="versioned").definedTag
    ->any(tagType="version").typedValue

context Model inv:
 self.isVersioned implies
 self.ownedElement
       ->forall(e | e.isVersioned and
                 (e.getVersion = self.getVersion))

context Abstraction inv:
(self.stereotype->name->includes("horizontal")) implies
(self.client->union(self.supplier))
      ->forall(e | e.isVersioned and
                (e.getVersion = self.getVersion))

context Abstraction inv:
 let aSupplier = self.supplier->any(true)
 let aClient = self.client->any(true) in
 (self.stereotype->name->includes("evolution")) implies
  ((aSupplier.getVersion < aClient.getVersion) and
   self.supplier->forall(e | e.getVersion = aSupplier.getVersion) and
    self.client->forall(e | e.getVersion = aClient.getVersion))


Tool Support Based on Description Logics

Motivation for Description Logics

The essential evolution problem that needs to be addressed is how to keep different models consistent when any of them evolves. This requires a formal framework that allows us to make formal guarantees about consistency; that is, ensuring that there are no inconsistencies, or guaranteeing that all possible inconsistencies are detected. Such a framework allows us to deal with inconsistencies in a generic way, making it easy to adapt to changes to the UML standard. For example, if a new type of model element (or even a new kind of diagram) is introduced we can accommodate inconsistencies that occur with this type of model element.

We take a logic-based approach to the detection of inconsistencies, which is characterised by the use of a formal inference engine. We use the formalism of description logic (DL), which is a knowledge representation formalism (Baader et al., 2003). This formalism allows us to represent the knowledge of the world by defining the concepts of the application domain and then use these concepts to specify properties of individuals occurring in the domain. The basic syntactic building blocks are atomic concepts (unary predicates), atomic roles (binary predicates), and individuals (constants). The expressive power of the language is restricted. It is a two-variable fragment of first-order predicate logic and as such it uses a small set of constructors to construct complex concepts and roles.

The most important feature of DL is its reasoning ability. This reasoning allows us to infer knowledge that is implicitly present in the knowledge base. Concepts are classified according to subconcept-superconcept relationships; for example, Model is a ModelElement. In this case, Model is a subconcept of ModelElement and ModelElement is the superconcept of Model. Classification of individuals provides useful information on the properties of individuals. For example, if an individual is classified as an instance of Model, we infer that it is also a ModelElement.

Spanoudakis and Zisman (2001) identified two inherent limitations of logic-based approaches: first-order logic is semidecidable, and theorem proving is computationally inefficient. These limitations do not apply for DL, which is decidable and uses optimized tableau- and automata-based algorithms.

Another important advantage of DL systems is that they have an open world semantics, which allows the specification of incomplete knowledge. Due to their semantics, DL systems are suited to express the design structure of a software application. For example, Cali, Calvanese, De Giacomo, and Lenzerini (2001) translated UML class diagrams to the description logic DLR.

Even with all the expressive power of first-order logic, it is not possible to define the transitive closure of a relation in first-order logic. In Bodeveix, Millan, Percebois, Camus, Bazes, and Ferraud (2002) this is also recognized as a deficiency of OCL. The wellformedness rules of the UML metamodel which are expressed in OCL make heavy use of additional operations to navigate over the metamodel. These operations are often recursive and this could be avoided if it were possible to express transitive closure in OCL (Bodeveix et al., 2002). Most DL systems provide a mechanism to define the transitive closure of a role.

Tool Support

Several implemented DL systems exist (e.g., Loom, Classic, RACER, and so on). We explain one such system, Loom, and explain why we have selected it for integration into our tool setup ( Figure 3). Loom offers reasoning facilities on concepts and individuals for the DL ALCQRIFO. This logic extends the basic description logic ALC with qualified number restrictions on roles, inverse roles, role hierarchy and nominals. The distinguishing feature between Loom and other DL systems is the incorporation of an expressive query language for retrieving individuals and its support for rule-based programming. Inconsistencies that arise because of UML model evolution can be detected and resolved by means of logic queries on the knowledge base. This knowledge base contains the UML metamodel representation, the different UML model instances, and the rules that specify inconsistencies between these models and how to resolve them.

We translated the UML metamodel and our UML profile in Loom in terms of atomic concepts and roles as well as more complex descriptions that can be built from them with concept constructors. As an example we give the Loom translation of the meta association between ModelElement and Model with roles namespace and owned Element (cf. Figure 8). The translation uses (inverse) roles between concepts. The role namespace between a ModelElement and a Model translates into the role namespace having as domain the concept ModelElement and as range Model. The role ownedElement translates into the role ownedElement which is the inverse role of namespace. UML metaclasses and stereotypes are translated into Loom concepts. As an example, the translation of VersionedElement is given. To indicate the fact that VersionedElement is a stereotyped metaclass, it is defined as a concept that is both a ModelElement and Versioned where the stereotype Versioned is a concept which is a Stereotype with property version.

        (LOOM:defrelation namespace
        :domain ModelElement
        :range Model: characteristics :single-valued)
        (LOOM:defrelation ownedElement
        :is (:inverse namespace))
        (LOOM:defconcept Versioned
        :is Stereotype
        :roles (version))
        (LOOM:defconcept VersionedElement
        :is (:and ModelElement Versioned))

In the same way all the other classes, stereotypes, inheritance relationships, associations, and attributes in the UML metamodel are translated into Loom. Multiple inheritance of metaclasses and stereotypes is naturally translated into the powerful subsumption mechanism of description logics. The complete translation of the metamodel into Loom code can be found in (Simmonds, 2003). The OCL well-formedness rules of our UML profile are translated into logic rules.

The modeling elements of user-defined class, sequence, and state diagrams are specified as instances of the appropriate classes, associations, and attributes of the UML metamodel. This guarantees the consistency of user-defined model elements with the UML metamodel. As an example, the ATM class of Figure 4 is represented by the instance ATM of the concept Class. Furthermore, different properties for ATM are specified; for example, this class has the operations getPin() and getAmountEntry() presented by getPin and getAmountEntry which are instances of the concept Operation. The complete translation of the metamodel into Loom code can be found in Simmonds (2003).

        (create'ATM 'Class)
        (tellm (:about ATM
        (name ATM)
        (Has-feature getPin)
        (Has-feature getAmountEntry)
        ...
        (Is-parent-of PrintingATM)
        (IsAbstract false)
        (In-namespace Class-Diagram)))

The tool chain we implemented has already been illustrated in Figure 3. It detects model inconsistencies and suggests solutions and possible model refactorings. UML models that have been created with a UML CASE tool are exported in the XMI format (XML Metadata Interchange), and translated into logic assertions using SAXON, an XSLT tool. These logic assertions are then automatically loaded into a knowledge base maintained by Loom, the description logic engine. Loom is developed as a server which can be used by multiple clients. This server runs the description logic engine, where the logic equivalent of the UML metamodel is preloaded. Predicates used in the detection and resolution of design inconsistencies and model refactorings are also preloaded. Currently, Conan runs independently of the UML CASE tool being used, because our UML profile for model evolution (see previous section) is not yet supported by current CASE tools. The ideal situation would be if the consistency maintenance process could be automated by directly invoking the description logic engine from within a CASE tool, and by providing feedback about the detected inconsistencies and model refactorings to this tool. This would involve building the UML CASE tool on top of the reasoning engine. In this manner, an integrated environment can be offered that supports UML modeling, version control, detection and resolution of inconsistencies, and model refactoring.

Related Work on Managing Design Inconsistencies

Finkelstein et al. (1993) explain that consistency between partial models is neither always possible nor is it always desirable. They suggest the use of temporal logic to identify and handle inconsistencies. This formalism is used to describe sequences of actions that lead to inconsistencies, unlike the approach taken in our work that uses logic to find conflicting instances. Grundy et al. (1998) claim that a key requirement for supporting inconsistency management is the facilities for developers to configure when and how inconsistencies are detected, monitored, stored, presented, and possibly automatically resolved. They describe their experience with building complex multiple-view software development tools supporting inconsistency management facilities. The DL approach is also easily configurable, by adding, removing, or modifying logic rules in the knowledge base.

In addition, Finkelstein (2000) has elaborated a list of the technical challenges that arise when trying to build a toolset that deals with evolution and consistency. Tools dealing with these two aspects should help establish, express, and reason about the relationships between formal languages, check consistency with respect to these relationships, and provide diagnostic feedback. Where inconsistencies have been detected, these tools should help to visualise the inconsistencies. The user should be able to specify policies with respect to when consistency should be checked and when resolution mechanisms should be applied. This approach has been used as a guideline for the tool development in our work.

A wide range of different approaches for checking consistency has been proposed in the literature. Engels, Heckel and Küster (2001) motivate a general methodology to deal with consistency problems based on the problem of protocol state machine inheritance. In that example, statecharts as well as the corresponding class diagrams are important. Communicating Sequential Processes (CSP) are used as a mathematical model for describing the consistency requirements. This idea is further enhanced in Engels, Küster, et al. (2002) and Engels, Heckel, Küster, and Groenewegen (2002) with dynamic metamodeling rules as a notation for the consistency conditions because of their graphical, UML-like, notation.

Rasch and Wehrheim (2003) study consistency problems arising between class and associated state diagrams. The common semantic domain used for classes and state diagrams is the failure-divergences model of the process algebra CSP.

Ehrig and Tsiolakis (2000) investigate the consistency between UML class and sequence diagrams. UML class diagrams are represented by attributed type graphs with graphical constraints, and UML sequence diagrams by attributed graph grammars. As consistency checks between class and sequence diagrams only existence, visibility and multiplicity checking are considered. In Tsiolakis (2001) the information specified in class diagrams and state diagrams is integrated into sequence diagrams. The information is represented as constraints attached to certain locations of the object lifelines in the sequence diagram. The supported constraints are data invariants and multiplicities on class diagrams and state and guard constraints on state diagrams. Fradet, Le Métayer, and Périn (1999) use systems of linear inequalities to check consistency for multiple view software architectures. In Kielland and Borretzen (2001) a consistency checker is implemented using an XML parser and by translating the structure of the XMI documents representing UML models into Prolog. The checks are limited to syntactical errors and completeness/omissions in UML class, state, and sequence diagrams. These approaches only present and check a very limited number of inconsistencies.

The problem of verifying whether the interactions expressed by a collaboration diagram can indeed be realised by a set of state machines has been treated by Schfer, Knapp, and Merz (2001). They have developed HUGO, a prototype tool that checks if state machine models and collaborations (translated into sets of Büchic automata) match up, using the SPIN model checker to verify the model against the automata (Holzmann, 1997). This problem has also been analysed by Litvak, Tyszberowicz, and Yehudai (2003), using an algorithmic approach, instead of using external model checkers. They have put their ideas into practice, by implementing the BVUML tool that receives state and sequence diagrams as XMI files.

Finally, note that consistency of models should not be confused with consistency of a modeling language. UML has been formalised within rewriting logic and implemented in the Maude system (Alemán, Toval, & Hoyos, 2000; Toval & Alemán, 2000). The objectives are to formalize UML and transformations between different UML models. They focus on using reflection to represent and support the evolution of the metamodel.


Experiments

In this section we explain, by means of two concrete experiments with our motivating example, how we used the proposed tool setup to detect design inconsistencies and propose model refactorings.

Experiment 1: Detecting Inconsistencies

We were able to detect each inconsistency in the classification of Table 1 by specifying the necessary logic predicates. For most of the inconsistencies, we also provided rules to automatically resolve the detected inconsistencies.

We will now show how this has been achieved for the invocation inconsistency of our motivating example. The generate-received-operations function generates the ordered collection of stimuli received by the object received as a parameter. Using a query, the list of stimuli received by the parameter object is generated. The ordered list is returned.

(defun generate-received-operations (?object)
 (let* ((?ordered-rec-ops)
 (?received-ops
   (retrieve (?name 1 ?name2 ?stimulus ?callaction ?operation)
     (:and
     (Receiver-of ?object ?stimulus)
     (name ?stimulus ?name1)
     (Initiates ?stimulus ?callaction)
    (CallAction-operation ?callaction ?operation)
    (name ?operation ?name2)))))
    (setq ?ordered-rec-ops (sort ?received-ops '< :key 'first))))

The traverse-sm function recursively traverses a state machine, using the ordered collection of stimuli as a guide when choosing transitions. The traversal does not necessarily start at the initial state, because the behaviour depicted in a sequence diagram usually has omissions, in contrast to protocol state machines, that should be as complete as possible. The first part of the function is the end condition for the recursion: either a final state has been reached, or all the behaviour specified by the sequence diagram has been examined. If this is not the case, a query is used to find the transitions exiting from the current state. Using the sequence diagram behaviour as a guide, one of these is chosen, and the recursion continues. If there are no suitable transitions from the current state, an inconsistency has been found, and the user is notified.

(defun traverse-sm (?from ?from-name ?seq-list)
  (let* ((?aux) (?current (second (first ?seq-list))))
    (format t"Current operation: ~S~%" ?current)
    (if (or (equalp (format NIL "~S" (get-value ?from 'name)) "|I|FINAL")
      (equalp ?seq-list NIL))
     (format t "No behaviour consistency problems")
      (do-retrieve (?transition ?operation ?name ?callevent ?state)
      (:and
         (Is-source-of ?from ?transition)
         (Triggered-by ?transition ?callevent)
         (Is-occurence-of ?callevent ?operation)
         (name ?operation ?name)
        (Is-target-of ?state ?transition))
(if (equalp ?operation NIL)
 (traverse-sm ?state (get-value ?state 'name) ?seq-list)
(if (equalp ?name ?current)
 (traverse-sm ?state (get-value ?state 'name) (cdr ?seq-list))
 (format t "Inconsistency found at state: ~S~%" ?from-name)))))))

When this predicate is applied to the diagrams of the motivating example, the obtained results indicate that instances of the subclass PrintingATM cannot be substituted by instances of the superclass ATM. This is because, in the state diagrams of Figure 6, there are no outgoing transitions from the GiveCash state that have the ejectCard event as a trigger. The term fi is a Loom function that finds the individual associated to the Loom identifier given as an argument.

UML(49): (traverse-sm (fi VerifyAccountBalance-SM-1.0)
 "VerifyAccountBalance" (generate-received-operations (fi anATM-1.0)))
Current operation: |I|CHECKIFCASHAVAILABLE
Current operation: |I|DISPENSECASH
Current operation: |I|EJECTCARD
Inconsistency found at state: |I|GIVECASH
NIL

Experiment 2: Model Refactorings

As a second experiment, we used logic rules in Loom to suggest model refactorings, the design-level equivalent of source-code refactorings (Opdyke, 1992; Fowler, 1999). We used logic rules to automatically suggest such model refactorings to improve the UML design.

Figure 9 shows a version of the ATM class hierarchy, where the issueReceipt() operation is owned by the ATM class, and not by the PrintingATM class. The sequence diagrams describing the behaviour of the Deposit class, one with respect to the ATM class, and the other with respect to the PrintingATM class, are shown in Figures 10 and 11, respectively.

Click To expand
Figure 9: ATM class hierarchy, version 1
Click To expand
Figure 10: Sequence diagram for deposit transactions in the ATM class
Click To expand
Figure 11: Sequence diagram for deposit transactions in the PrintingATM class

Improvements of the class diagram design can be suggested based on information available in the sequence diagrams. More specifically, a Push Down Method refactoring can be proposed (Fowler, 1999). In the given set of sequence diagrams, the operation issueReceipt() is only sent to instances of the PrintingATM class, and never to instances of the ATM class, that is, the owner of the operation. This fact allows us to conclude that the operation issueReceipt() can be pushed down and become a method of the class PrintingATM.

The push-down-method function checks whether an operation is invoked exclusively by direct subclasses of the operation's owner. This is done by first checking if the operation is used by the instances of the owner class. The generate-rec-sent-operations function generates the set of stimuli that are sent or received by all the instances of a class, that is, passed as a parameter. The check-use function recursively checks if an operation has been used by the instances of a class. Then a query is used to find the direct subclasses of the owner class. As with the owner class, each subclass is checked to determine if the operation is received or sent by at least one instance of the subclass. Finally, a condition is checked for each subclass found to determine if the operation is used by the subclass. If this condition is met, the user is informed of the candidate methods that could be pushed down, and into which subclasses.

(defun push-down-method (?parent?oper)
 (let ((?list2) (?flag2) (?list1) (?flag1))
   (setq ?list1 (generate-rec-sent-operations ?parent))
   (setq ?flag1 (check-use ?oper ?list2))
   (do-retrieve (?gen ?child)
   (:and
    (Is-generalization-of ?gen ?child)
    (Is-specialization-of ?gen ?parent))
    (progn ()
      (setq ?list2 (generate-rec-sent-operations ?child))
      (setq ?flag2 (check-use ?oper ?list2))
     (if (and (equalp ?flag1 "NOT USED") (equalp ?flag2 "USED"))
         (format t "Operation ~S in class ~S should be pushed down
         to class ~S~%"
             (get-value ?oper 'name) ?parent ?child))))))

The class diagram shown in Figure 4 shows the same portion as Figure 9, after including the recommended changes that were derived from the information contained in the sequence diagrams. As expected, after applying the predicates to the example, the tool recommends to push down the issueReceipt() from the ATM class to the PrintingATM class.

Operation |I|ISSUERECEIPT in class |I|ATM-1.0 should be pushed down
 to class |I|PRINTINGATM-1.0
NIL


Conclusion

In this chapter we proposed formal tool support to address the important problem of inconsistency management in evolving UML models. To this extent, we first provided a classification of semantic inconsistencies in and between evolving class diagrams, sequence diagrams, and state diagrams. Secondly, we provided a UML profile to support versioning and evolution. Finally, we provided tool support based on the formalism of description logics. An XML translator was used to translate the UML models, exported from a CASE tool in XMI format, into the logic database of the description logics tool. We provided some experiments with this logic tool and showed how it allowed us to detect inconsistencies and to suggest model refactorings.

Obviously, the prototype tool we developed needs to be improved in many different ways. First of all, we need a better integration with existing UML CASE tools, either by building the CASE tool on top of the DL engine and logic database, or by providing plugins for existing CASE tools. We also need more interactive support for detecting and resolving inconsistencies, as well as for suggesting and applying model refactorings. Our tool also needs to be integrated with an existing version control system (CVS) to provide persistent storage of all the evolutions made to the different UML models.

Finally, we need to investigate how our tool can be combined with complementary tools that provide other kinds of evolution support such as change impact analysis and change propagation.

From a more formal point of view, many open research questions remain. How can we fully exploit the decidability property of description logics? What are the limitations of the description logics formalism? Can we automatically translate OCL constraints into logic rules? Can other evolution techniques such as change propagation and impact analysis be expressed using the same formalism?


References

Aleman, J., Toval, A., & Hoyos, J. (2000). Rigorously transforming UML class diagrams. In Proceedings Workshop Models, Environments and Tools for Requirements Engineering (MENHIR). Universidad de Granada, Spain.

Astels, D. (2002). Refactoring with UML. In Proceedings International Conference Extreme Programming and Flexible Processes in Software Engineering (pp. 67–70). Alghero, Sardinia, Italy.

Baader, F., McGuinness, D., Nardi, D., & Patel-Schneider, P. (2003). The description logic handbook: Theory, implementation and applications. Cambridge, UK,: Cambridge University Press.

Bodeveix, J.-P., Millan, T., Percebois, C., Camus, C. L., Bazes, P., & Ferraud, L. (2002). Extending OCL for verifying UML model consistency. In L. Kuzniarz, G. Reggio, J. Sourrouille, & Z. Huzar (Eds.), Consistency problems in UML-based software development, Workshop UML 2002, technical report.

Boger, M., Sturm, T., & Fragemann, P. (2002). Refactoring browserfor UML. In Proceedings International Conference Extreme Programming and Flexible Processes in Software Engineering (pp. 77–81). Alghero, Sardinia, Italy.

Bohner, S. A., & Arnold, R. S. (1996). Software change impact analysis. In S. A. Bohner & R. S. Arnold (Eds.), (pp. 1–26).

Borland. (2004, December 1). Borland. Retrieved from http://www.borland.com/to-gether/

Briand, L., Labiche, Y., & O'Sullivan, L. (2003). Impact analysis and change management of UML models. In Proceedings International Conference Software Maintenance (pp. 256–265). IEEE Computer Society Press.

Call, A., Calvanese, D., De Giacomo, G., & Lenzerini, M. (2001). Reasoning on UML class diagrams in description logics. In Proceedings IJCAR Workshop on Precise Modelling and Deduction for Object-Oriented Software Development (PMD).

Chikofsky, E. J., & Cross, J. H. (1990). Reverse engineering and design recovery: A taxonomy. IEEE Software, 7(1), 13–17.

Conradi, R., & Westfechtel, B. (1998). Version models for software configuration management. ACM Computing Surveys, 30(2), 232–282.

Del Valle, J. G. (2003). Towards round-trip engineering using logic metaprogramming. Unpublished master's thesis, Department of Computer Science, Vrije Universiteit Brussel, Belgium and Ecole des Mines de Nantes, France.

Demeyer, S., Ducasse, S., & Tichelaar, S. (1999). Why unified is not universal. UML shortcomings for coping with round-trip engineering. In B. Rumpe (Ed.), Proceedings International Conference Unified Modeling Language (pp.630–644). Kaiserslautern, Germany: Springer-Verlag, LNCS 1723.

Ehrig, H., & Tsiolakis, A. (2000). Consistency analysis of UML class and sequence diagrams using attributed graph grammars. In H. Ehrig & G. Taentzer (Eds.), ETAPS 2000 Workshop on Graph Transformation Systems (pp. 77–86). Berlin, Germany.

Engels, G., Hausmann, J., Heckel, R., & Sauer, S. (2002). Testing the consistency of dynamic UML diagrams. In Proceedings International Conference Integrated Design and Process Technology (IDPT). Pasadena, CA.

Engels, G., Heckel, R., & Kiüster, J. M. (2001). Rule-based specification of behavioral consistency based on the UML meta-model. In M. Gogolla & C. Kobryn (Eds.), Proceedings International Conference UML 2001 - The Unified Modeling Language: Modeling languages, concepts, and tools (pp. 272–286). Toronto, Canada: Springer-Verlag, LNCS 2185.

Engels, G., Heckel, R., Kiister, J. M., & Groenewegen, L. (2002). Consistency-preserving model evolution through transformations. In J.-M. Jézéquel, H. Huβmann, & S. Cook (Eds.), Proceedings International Conference UML 2002 - The Unified Modeling Language. Model engineering, concepts, and tools (pp. 212–227). Dresden, Germany: Springer-Verlag, LNCS 2460.

Engels, G., Kiister, J. M., Heckel, R., & Groenewegen, L. (2001). A methodology for specifying and analyzing consistency of object-oriented behavioral models. In Proceedings ESEC/FSE (pp. 186–195). New York: ACM Press.

Engels, G., Kiister, J. M., Heckel, R., & Groenewegen, L. (2002). Towards consistency-preserving model evolution. In Proceedings International Workshop on Principles of Software Evolution (pp. 129–132). New York: ACM Press.

Finkelstein, A. (2000). A foolish consistency: Technical challenges in consistency management. In I. Ibrahim, J. Kung, & N. Revell (Eds.), Proceedings International Conference Database and Expert Systems Applications (pp. 1–5). London: Springer-Verlag, LNCS 1873.

Finkelstein, A., Gabbay, D. M., Hunter, A., Kramer, J., & Nuseibeh, B. (1993). Inconsistency handling in multi-perspective specifications. In European Software Engineering Conference (pp. 84–99). Springer-Verlag, LNCS 1873.

Finkelstein, A., Spanoudakis, G., & Till, D. (1996). Managing interference. In Joint Proceedings Sigsoft '96 Workshops (pp. 172–174). New York: ACM Press.

Fowler, M. (1999). Refactoring: Improving the design of existing programs. Boston: Addison Wesley.

Fradet, P., Le Metayer, D., & Perin, M. (1999). Consistency checking for multiple view software architectures. In Proceedings International Conference ESEC/FSE '99, 1687, 410–428. Springer-Verlag, LNCS 1687.

Grundy, J. C., Hosking, J. G., & Mugridge, W. B. (1998). Inconsistency management for multiple-view software development environments. IEEE Transactions on Software Engineering, 24(11), 960–981.

Holzmann, G. J. (1997). The model checker spin. IEEE Transactions on Software Engineering, 23(5), 279–295 (Special issue on formal methods in software practice).

IEEE. (1999). Standard glossary of software engineering terminology 610.12–1990. In IEEE Standards Software Engineering, Volume One: Customer and Terminology Standards. IEEE Press.

Kielland, T., & Borretzen, J. A. (2001). UML consistency checking (Research Report No. SIF8094). Oslo, Norway: Institutt for datateknikk og informasjonsvitenskap.

Kuzniarz, L., Reggio, G., & Sourouille, J. (2002). Consistency problems in UML-based software development: Workshop materials. (Technical Report No. 2002–06). Blekinge Institute of Technology, Department of software engineering and computer science.

Lehman, M. M., Ramil, J. F., Wernick, P., Perry, D. E., & Turski, W. M. (1997). Metrics and laws of software evolution - The nineties view. In Proceedings International Symposium Software Metrics (pp. 20–32). IEEE Computer Society Press.

Liskov, B. (1988). Data abstraction and hierarchy. In L. Power & Z. Weiss (Eds.), Addendum to the proceedings oopsla-87: Object-oriented programming systems, languages and applications (pp. 17–34). New York: ACM Press.

Litvak, B., Tyszberowicz, S., & Yehudai, A. (2003). Consistency validation of UML diagrams. In ECOOP Workshop on Correctness of Model-Based Software Composition. Universität Karlsruhe, Germany.

MacGregor, R. (1991). Inside the LOOM description classifier. SIGART Bulletin, 2(3), 88–92.

Mens, T., & D'Hondt, T. (2000). Automating support for software evolution in UML. Automated Software Engineering Journal, 7(1), 39–59.

Mens, T., & Tourwe, T. (2004). A survey of software refactoring. IEEE Transactions on Software Engineering, 30(2), 126–139.

Mens, T., Lucas, C., & Steyaert, P. (1999). Supporting disciplined reuse and evolution of UML models. In J. Bezivin & P.-A. Muller (Eds.), Proceedings UML '98 - beyond the notation (pp. 378–392). Mulhouse, France: Springer-Verlag, LNCS 1618.

Nickel, U., Niere, J., & Zundorf, A. (2000). Roundtrip engineering with FUJABA. In Proceedings Second Workshop on Software Re-engineering WSR. Bad-Honnef, Germany: Technical Report 8/2000, Universitat Koblenz-Landau.

Nuseibeh, B., Easterbrook, S., & Russo, A. (2000). Leveraging inconsistency in software development. Computer, 33(4), 24–29.

Ohst, D., Welle, M., & Kelter, U. (2003). Differences between versions of UML diagrams. In Proceedings ESEC/FSE (pp. 227–235). New York: ACM Press.

Opdyke, W. F. (1992). Refactoring object-oriented frameworks. Unpublished doctoral dissertation, University of Illinois, Urbana-Champaign.

Rajlich, V. (1997). A model for change propagation based on graph rewriting. In Proceedings International Conference Software Maintenance (pp. 84–91). IEEE Computer Society Press.

Rasch, H., & Wehrheim, H. (2003). Checking consistency in UML diagrams: Classes and state machines. In Formal Methods for Open Object-Based Distributed Systems, (pp. 229–243). Springer-Verlag, LNCS 2884.

Robbins, J. E. (1998). Design critiquing systems (Technical Report No. UCI-98–41). Department of Information and Computer Science, University of California, Irvine.

Schfer, T., Knapp, A., & Merz, S. (2001). Model checking UML state machines and collaborations. In Electronic Notes in Theoretical Computer Science, 47, 1–13.

Simmonds, J. (2003). Consistency maintenance of UML models with description logics. Unpublished master's thesis, Department of Computer Science, Vrije Universiteit Brussel, Belgium and Ecole des Mines de Nantes, France.

Simmonds, J., Van Der Straeten, R., Jonckers, V., & Mens, T. (2004). Maintaining consistency between uml models using description logic. In Proceedings Langages etModélés á Objets 2004, RSTI serie L 'Objet, 10(2–3), 231–244. Hermes Science Publications.

Spanoudakis, G., & Zisman, A. (2001). Inconsistency management in software engineering: Survey and open research issues. In S. K. Chang (Ed.), Handbook of software engineering and knowledge engineering, 1, 329–380. London: World Scientific Publishing Co.

Sunyé, G., Pollet, D., LeTraon, Y., & Jézéquel, J.-M. (2001). Refactoring UML models. In Proceedings UML 2001, (pp. 134–138). Toronto, Canada: Springer-Verlag, LNCS 2185.

Toval, A., & Aleman, J. (2000). Formally modeling UML and its evolution: A holistic approach. In S. Smith & C. Talcott (Eds.), Formal methods for open object-based distributed systems iv (pp. 183–206). Stanford, CA: Kluwer Academic Publishers.

Tsiolakis, A. (2001). Semantic analysis and consistency checking of UML sequence diagrams. Unpublished master's thesis, Technische Universitat Berlin. (Technical ReportNo. 2001ä06).

Van Der Straeten, R., Mens, T., Simmonds, J., & Jonckers, V. (2003). Using description logics to maintain consistency between UML models. In P. Stevens, J. Whittle, & G. Booch (Eds.), UML 2003 - the unified modeling language, (pp. 326–340). San Francisco, USA: Springer-Verlag, LNCS 2863.

Van Gorp, P., Stenten, H., Mens, T., & Demeyer, S. (2003). Towards automating source-consistent UML refactorings. In P. Stevens, J. Whittle, & G. Booch (Eds.), UML 2003 - the unified modeling language, (pp. 144–158). San Francisco, USA: Springer-Verlag, LNCS 2863.

Wuyts, R. (2001). A logic meta-programming approach to support the co-evolution of object-oriented design and implementation. Unpublished doctoral dissertation, Vrije Universiteit Brussel, Department of Computer Science.


Chapter II: Deriving Safety-Related Scenarios to Support Architecture Evaluation

Dingding Lu,
Iowa State University, USA, and Jet Propulsion Laboratory/Caltech, USA
Robyn R. Lutz,
Iowa State University,
USA
Carl K. Chang,
Iowa State University,
USA

This chapter introduces an analysis process that combines the different perspectives of system decomposition with hazard analysis methods to identify the safety-related use cases and scenarios. It argues that the derived safety-related use cases and scenarios, which are the detailed instantiations of system safety requirements, serve as input to future software architectural evaluation. Furthermore, by modeling the derived safety-related use cases and scenarios into UML (Unified Modeling Language) diagrams, the authors hope that visualization of system safety requirements will not only help to enrich the knowledge of system behaviors but also provide a reusable asset to support system development and evolution.

Introduction

This chapter defines a technique to identify and refine the safety-related requirements of a system that may constrain the software architecture. The purpose of the approach presented here is to provide a relatively complete set of scenarios that can be used as a reusable asset in software architectural evaluation and software evolution for safety-critical systems.

For this purpose, we will identify, refine, and prioritize the safety-related requirements in terms of scenarios by using safety analysis methods. The resulting scenarios can serve as input to software architectural evaluation. By evaluating various kinds of architectural decisions against the input safety-related requirements, the evaluation approach will assist in the selection of an architecture that supports the system safety. The resulting scenarios are reusable during software evolution. By reusing those common scenarios, and hence the common architectural decisions, the cost of development and the time to market can be reduced.

The objective of this chapter is to introduce a technique that:

  1. identifies and refines the safety-related requirements that must be satisfied in every design and development step of the system,

  2. instantiates the nonfunctional requirement – safety – into misuse cases and misuse scenarios that are further modeled by UML, and

  3. provides a reusable asset – utility tree – that may either support the engineering decision making during software development or become input to future software architectural evaluation.

Background

Currently many safety-critical systems are being built. Some safety-critical systems include software that can directly or indirectly contribute to the occurrence of a hazardous system state (Leveson, 1995). Therefore, safety is a property that must be satisfied in the entire lifetime of safety-critical systems.

Though safety is the key property of the safety-critical systems, some aspects of the system are not related to safety. A software requirement can be categorized as a safety-related requirement if the software controls or contributes to hazards (Leveson, 1995).

Identifying those safety-related requirements can guide the engineers to explore the most critical parts of the system and allocate development resources efficiently.

Two existing software safety analysis methods are adapted in this chapter to identify and prioritize the safety-related requirements for the targeted system (Lu, 2003). One is Software Failure Mode and Effect Analysis (SFMEA). SFMEA is an extension of hardware Failure Mode and Effect Analysis (FMEA) which has been standardized (Military Standard, 1980). SFMEA is well documented (Reifer, 1979; Lutz & Woodhouse, 1997) though there is no standard to guide performing SFMEA. SFMEA works forward to identify the "cause-effect" relationships. A group of failure modes (causes) are considered and the possible consequences (effects) are assessed. Based on the severity of the effect, the possible hazards are identified and prioritized. SFMEA uses tabular format. Some typical entries of SFMEA are depicted in Table 1.

Table 1: The entries of SFMEA
Item | Failure mode | Cause of failure | Possible effect | Priority level | Hazard reduction mechanism

The other is Software Fault Tree Analysis (SFTA). SFTA is an important analysis technique that has been used successfully for a number of years and in a variety of critical applications to verify requirements and design compliance with robustness and fault-tolerance standards. Historically, fault tree analysis has been applied mainly to hardware systems (Raheja, 1991), but good results have been obtained in recent years by applying the technique to software systems as well (Hansen, Ravn & Stavridou, 1998; Leveson, 1995; Lutz, Helmer, Moseman, Statezni & Tockey, 1998; Lutz & Woodhouse, 1997; Lu & Lutz, 2002). SFTA uses Boolean logic to break down an undesirable event or situation (the root hazard) into the preconditions that could lead to it. SFTA is thus a top-down method that allows the analyst to explore backward from the root hazard to the possible combinations of events or conditions that could lead to the occurrence of root hazard. SFTA uses a tree structure. The hazard is at the root of the tree and the intermediate nodes or leaves represent potential causes of the hazard. A sample software fault tree is displayed in Figure 1.

Click To expand
Figure 1: A sample software fault tree (Sommerville, 2001)

Figure 1 describes a portion of SFTA for a safety-critical system: the insulin delivery system (Sommerville, 2001), which monitors the blood glucose level of diabetics and automatically injects insulin as required. From the SFTA, the root hazard is the "incorrect insulin dose is administered". The events "incorrect sugar level measured", "sugar computation error", and "algorithm error" could be the causes of the root hazard and thus become the intermediate nodes or leaves of the SFTA.

As an important aspect of software development, software architecture will greatly influence the qualities of the system such as safety and reliability. Thus, the available software architectural styles must be evaluated against the safety requirements so that the best-fit architectural decisions can be made to build the system.

We here use the definition proposed by Bass, Clements, and Kazman (2003): "The software architecture of a program or computing system is the structure or structures of the system, which comprise software elements, the externally visible properties of those elements, and the relationships among them." Software architectural styles such as client-server and pipe-filter have been defined by Shaw and Garlan (1996) to describe the component and connector types, and the set of constraints (e.g., performance, safety, and reliability) on how they can be combined. Definition of software architecture is important in terms of opening a channel for communication among different stakeholders, capturing the specific system properties in the early design stage, and providing architecture reuse for similar systems in the same domain.

When there is more than one architectural style that can be chosen for a system or a component of a system, architectural evaluation must be performed to trade off advantages and disadvantages among a variety of architectural decisions and to select the most suitable one for the system. Software architectural evaluation has been practiced since the early 1990's. The Architecture Tradeoff Analysis Method (ATAM) (Clements, Kazman, & Klein, 2001) is one such evaluation method that has shown promising results when applied in industry. An example of the application of ATAM is to use this method to evaluate a war game simulation system (Jones & Lattanze, 2001)

ATAM is a good starting point for software architectural evaluation. It gives an overview of several quality attributes (key properties such as performance, reliability, and safety) that need to be satisfied in the architectural design. The quality attributes are grouped under the root of a tree which ATAM calls a utility tree. The utility tree has "utility" as the root node and the quality attributes as the first-level nodes. Each quality attribute is further refined into scenarios that are the lower-level nodes in the utility tree. The scenarios are derived by brainstorming of experts and prioritized according to how much they will impact the system development.

The derived and prioritized scenarios are the inputs to the architectural evaluation step in ATAM. All the available architectural decisions are evaluated against those scenarios by assessing the potential effect of a specific architectural decision on each scenario (Lutz & Gannod, 2003). The effect is categorized into four kinds (risk, sensitivity, tradeoff, and non-risk) from the most critical to the least significant. Thus an architectural decision which incurs risk on many of the scenarios may be abandoned and those which accommodate most of the scenarios will be selected.

From the ATAM process, we can see that the accuracy of the evaluation relies on the completeness of the input scenario set. However, the scenarios derived either from the experience checklists or from the experts' brainstorming may cause lack of coverage, guidance, detail, and traceability.

In order to avoid these problems, the complete view of a system is developed to decompose the system from different architectural perspectives.

The complete view of a system refers to the 4 + 1 view model of software architecture developed by Kruchten (1995). The four views are the logical view, process view, physical view, and development view. Each view describes the different levels of software structure from four different perspectives of system development. The plus-one view refers to scenarios that represent the behavioral instances of the software functionalities.

Hofmeister, Nord and Soni (1999) took the view model one step further. They identified four different views (conceptual view, module view, code view, and execution view) which are used by designers to model the software. The conceptual view describes the high-level components and connectors along with their relationships. The module view describes the functional decomposition of the software. The code view organizes the source code, libraries, and so forth. The execution view deals with dynamic interactions between the software and the hardware or system environment. Each view deals with different engineering concerns. The safety-related requirements are mapped from the upper-level view to the lower-level view and are further refined in the context of that view. Segregating the system into four views gives a systematic way of revealing the system structure that helps to understand the domain in the early design stage, to identify the safety-related requirements, and to achieve relative completeness in scenario derivation.


Overview of the Safety-Related Scenario Derivation Process

In order to achieve improved coverage, completeness, and traceability in deriving safety-related scenarios, our process is founded on three key bases that are introduced in the previous section. First, the four architectural views of the system provide a way to study the system from four different perspectives and to consider different engineering concerns in each view. Second, the safety-related requirements define the overall safety factors of the system and guide the engineers to further explore those factors. Third, the safety analysis methods (SFMEA and SFTA) elicit and prioritize misuse cases and misuse scenarios (Alexander, 2003). The derived misuse cases and misuse scenarios transform the system safety into testable requirements that can serve as the input to the later architectural evaluation. The evaluation selects the suitable architectural decisions which will in turn impact the safety of the system.

Figure 2 depicts an overview of the process. The vertical direction describes the decomposition of the system into four views and maps the safety-related requirements into each view. Both the knowledge of the system and the safety-related requirements are detailed and enriched as one proceeds in this direction.

Click To expand
Figure 2: The overview of the process

There are three steps in the vertical direction, and the first step is global analysis. The objective of global analysis is to identify the overall safety factors that will be further refined or decomposed into the four architectural views. During the refining and decomposing, the undesirable system functionalities that may affect system safety are captured and represented as misuse cases (Alexander, 2003). For each misuse case, a set of misuse scenarios is derived to model the detailed system behaviors within the specific misuse case. Thus, the misuse scenarios are the instantiations of the overall safety factors.

The second step in the vertical direction is the four-view system decomposition. The four views consider the engineering concerns of the system from four different perspectives. The first two views (conceptual and module) include design issues that involve the overall association of system capability with components and modules as well as interconnections between them. The third view (code) includes design issues that involve algorithms and data structures. The fourth view (execution) includes the design issues that are related to hardware properties and system environment such as memory maps and data layouts.

Though most of the engineering concerns of each view are independent of other views, some may have impacts on the later views. On the other hand, the later views may place constraints back on the earlier views. Thus the relationship between the two views is bidirectional and iterative as shown in Figure 3.

Click To expand
Figure 3: The four views system decomposition

The resulting overall safety factors from the global analysis are localized (refined and decomposed) within the context of each view in terms of misuse cases and misuse scenarios. Meanwhile, additional safety concerns may also be investigated and identified.

After the misuse cases and misuse scenarios are derived, the last step of the vertical direction can be performed; that is, to produce a utility tree with the utility—safety as the root node and the overall safety factors as the second-level nodes. The remaining lower-level nodes are the derived misuse cases that are further decomposed into a set of misuse scenarios. The utility tree provides a top-down mechanism for directly translating the safety goal into concrete misuse scenarios. A sample utility tree is shown in Figure 4.

Click To expand
Figure 4: A Sample utility tree

The advantages of constructing a utility tree are to provide a straightforward way to gather the main results of each step in the process and to serve as a reusable asset in later UML modeling by directly mapping the misuse cases and misuse scenarios into UML diagrams.

In the vertical direction, we have mentioned that misuse scenarios will be derived for each view to instantiate the safety-related requirements. How the misuse scenarios are derived and prioritized is the task that will be fulfilled in the horizontal direction.

There are two steps in the horizontal direction that will be performed for each view. The first step is the forward hazard analysis - the SFMEA where the misuse cases are to be identified. As explained before, SFMEA works forward from the failure modes to possible effects to identify and prioritize the potential hazards. The overall safety factors resulting from the global analysis will guide the hazard identification here.

Within each view, every one of the overall safety factors is considered in order to derive the related possible hazards. The identified hazards will be prioritized according to the potential effects they may cause. The high-priority hazards will be mapped into the next view to be further investigated. Thus, a traceable link among the four views is established by looking at the recorded hazards in the SFMEA tables. The identified hazards are those undesirable functionalities of the system and thus are categorized as the misuse cases.

The second step is the backward hazard analysis: the SFTA where the misuse scenarios are to be derived. As described before, SFTA works backward to reason about the existence of a specific combination of basic events (the leaf nodes) which may lead to the root hazard. In each view, SFTA will take the identified hazards with high priorities in SFMEA as the root nodes and construct software fault trees.

A minimal cut set of a fault tree represents a combination of basic events that will cause the top hazard and cannot be reduced in number; that is, removing any of the basic events in the set will prevent the occurrence of the top hazard (Leveson, 1995). Every minimal cut set in a software fault tree will be mapped into a misuse scenario that consists of three components: stimuli, system reactions, and response. The basic events in the minimal cut set represent the stimuli of the misuse scenario. The paths from basic events to the root node through the intermediate nodes in the fault tree are the series of system reactions after the stimuli is triggered. The root hazard is the final response. For example, considering a minimal cut set of the fault tree in Figure 1, a misuse scenario can be derived: an algorithm error happens during a sugar computation, thus causing an incorrect sugar level measured; the system response is to administer an incorrect insulin dose to patient.

Combining the results of the SFMEA and SFTA analysis, every misuse case (the hazard) is decomposed into a set of misuse scenarios. The derived misuse cases and misuse scenarios become the lower-level nodes in the utility tree and are ready to be further transformed into UML diagrams.

After we have introduced the vertical and horizontal directions as well as the activities within each direction, we summarize the entire approach as an algorithm:

  1. Perform a global analysis for the entire system and identify the overall safety factors.

  2. Within the domain of each view, use SFMEA to derive new hazards by applying the overall safety factors as guideline and to refine high priority hazards input from earlier view.

  3. Prioritize hazards based on the potential safety effects they may cause and define the mechanisms that will be used in future design to prevent the hazards from happening.

  4. Use SFTA to apply fault tree analysis for each high-priority hazard.

  5. Derive misuse scenarios by mapping each minimal cut set of a fault tree into a scenario.

  6. Repeat steps 2 to 5 until each of the four views is analyzed.

  7. Construct a utility tree with the safety as root node. The second-level nodes are the overall safety factors identified in step 1, global analysis. The lower-level nodes are derived misuse cases (hazards) and misuse scenarios from each view.

  8. Model the misuse cases and misuse scenarios by UML diagrams.

We illustrate these steps of the overall process in the following two figures. Figure 5 outlines the overall process. Step 1 of the algorithm, the global analysis, will be performed before the four-view system decomposition starts. The identified overall safety factors will become the first-level nodes of the utility tree and will be mapped into each of the four views. After all the analysis activities (steps 2 through 5) within each of the four views are taken, the output misuse cases and misuse scenarios become the lower-level nodes in the utility tree. The resulting utility tree thus includes the main results of the process.

Click To expand
Figure 5: The outline of the process

Figure 6 shows the activities involved within each of the four views. Those activities are involved in steps 2 through 6 of the algorithm. The overall safety factors will become the input to each of the four views together with the high-priority hazards of the earlier view. (But note that there will not be any high-priority hazards input to the conceptual view because it is the first one of the four views.)

Click To expand
Figure 6: The activities within each view

The contributions of the technique we have presented here are (1) to provide a structured and systematic way to instantiate safety-related requirements into detailed and testable misuse scenarios by decomposing the system from the four architectural perspectives; (2) to identify the safety-related requirements by deriving the hazards in SFMEA and defining the prevention mechanisms for the hazards; (3) to adapt UML modeling by transforming the misuse cases and misuse scenarios into UML diagrams; and (4) to support future software architectural evolution by providing a detailed scenario-based In the next several sections, we will discuss the process of the approach in detail by applying it to a case study. The case we will use is the insulin delivery system (Sommerville, 2001). We selected this system based on its suitable size and its safety concerns.


Global Analysis

The global analysis is to identify the overall safety factors which may affect the system safety. If there are potential hazards involved in those factors, the safety of the system may be compromised. Furthermore, some of these hazards are not likely to be identified and prevented during the testing stage of system development. To avoid either expensive rework, or the even more costly recovery from catastrophic consequences, there are three activities in the global analysis: identify and describe the overall safety factors, extract the subset of the safety factors based on the needs of a specific system, and evaluate the impact of the safety factors.

Identify and Describe the Overall Safety Factors

There are two ways to perform the identification of factors. One way is to use the accumulated experience checklist from former projects. The experience checklist usually comes from the brainstorming session of experts and continues to be extended and enriched during project development. There are two advantages of using the experience checklist when a similar new system is going to be built. First, the valuable prior experience can be reused and part of the rework can be saved. Second, those same problems that happened and prevented development in the previous project can be easily avoided during the development of the new system.

Though the experience checklist may cover most aspects of the system, the new system may bring in new concerns. Particularly when a new system is going to be built, there may not be any previous experience checklist which can be used as the basis to derive the safety factors.

Another way is to import the four architectural views safety category defined by (Hofmeister, Nord, & Soni, 1999). Directly introducing the safety category to derive the overall safety factors brings two benefits. First, the safety category itself is clearly described and organized; thus it provides a starting point to think about the safety factors of a specific system. Second, the safety category represents the general safety concerns and thus can be easily adapted to different kinds of systems.

In our process, the four architectural views safety category will be taken as the primary way to identify the overall safety factors. The accumulated experience checklist will work as the complement to ensure coverage as complete as possible.

Extract the Subset of the Safety Factors Based on the Needs of a Specific System

The resulting set of overall safety factors are relatively complete and general so they can be applied to various kinds of systems. However, some of the factors may not be applicable to a specific system. For example, a wind speed monitoring system will not take any input from a keyboard or be otherwise manipulated by a human operator. Thus, the human computer interface safety factor will not be applicable in this case.

Depending upon the characteristics of a specific system, we will only focus on the subset of the identified safety factors that are applicable to the system. In this way, we scale down the overall number of the safety factors that need to be further analyzed.

Evaluate the Impact of the Safety Factors

The potential impact of a safety factor on the system development needs to be evaluated. The evaluation will be performed by asking the question, "If the factor involves problems, how severely will it affect other factors and hence the system development?"

Every safety factor will be categorized as high, medium, and minor according to the severity of its possible effect. The higher the impact level is, the higher priority the factor will have.

After the overall safety factors are identified and their priorities are assessed, they will become the first-level node in the utility tree and be ordered from the highest to the lowest priority.

We illustrate these three activities below by applying them to the insulin delivery system (Sommerville, 2001). The insulin delivery system uses sensors to monitor the patient's blood sugar level then calculates the amount of insulin needing to be delivered. The controller sends the command to the pump to pump the set amount of insulin. Finally, the insulin will be sent to the needle and injected into the patient's body. Thus, the insulin delivery system is an embedded system and uses several pieces of equipments to fulfill the task.

In step one, we import the four architectural views safety category defined by Hofmeister, Nord, and Soni (1999) and use the checklist of an advanced imaging solution system, IS2000 (Hofmeister et al.) as the complement. A set of safety factors is derived as in Table 2.

Table 2: The safety factors
Software | Management | Hardware
Human-computer interface | Product cost | General-purpose hardware (processor, network, memory, disk)
Input and output variable | Staff skills | Equipment quality
Input and output Trigger | Development schedule |
Output specification | Development budget |
Output to trigger event relationships |  |
Specification of transitions between states |  |
Performance |  |

In step two, we identify the subset of the derived safety factors that are relevant to the characteristics of the insulin delivery system. The results are those safety factors that are marked as bold in Table 2.

In step three, we will analyze the possible impacts of the given safety factors on the system. Those software factors will interact with each other. If any of them has problems, the problems may propagate to other factors. Thus, we assign the impacts of the software factors as high. Among the management factors, the staff's skills may have an effect on system development quality and thus be assigned as medium. How important the development schedule and budget are depend on the company's condition. In this case, we assume that the schedule and budget will not be problems and assign them as minor. Because the insulin delivery system will be put in the patient's body to operate, the quality of the equipment, such as sensors and needle, will be critical and we assign the impact of the hardware factor as high. A table can be constructed to display the set of the safety factors and levels of their potential impacts on the system, as shown in Table 3.

Table 3: The impact levels of the overall safety factors
Safety factor | Impact level
Human-computer interface | High
Input and output variable | High
Trigger event | High
Output to trigger event relationships | High
Specification of transitions between states | High
Staffs skills | Medium
Development schedule | Minor
Development budget | Minor
Equipments quality | High


The Four-View System Decomposition

The Definition of the Four Views (Hofmeister, Nord, & Soni, 1999)

The conceptual view is the highest system level view and thus the first level of the system abstraction. The conceptual view is tied very closely to the application and describes the overall functionalities of the system, so it is less constrained by the hardware and software platforms. The conceptual view regards the functionalities of the system as black boxes and as being relatively independent from detailed software and hardware techniques. The functionalities are represented as components in the conceptual view. The communications and data exchanges between those functionalities are handled by connectors.

The module view takes a closer look into system implementation. It deals with how the functionalities of the system can be realized with software techniques. The system functionalities which have been outlined in the conceptual view are mapped into subcomponents and subsystems in the module view. Thus the abstracted functionalities will be decomposed into several functional parts and each provides a specific service to the system. Also, the data exchanges between subsystems or subcomponents will be described in the module view.

The execution view describes the system development in terms of its runtime platform elements which include software and hardware properties, such as memory usage, processes, threads, and so forth. It captures how these platform elements are assigned and how the resources are allocated to fulfill the system functionalities. The subsystems and subcomponents of the module view are mapped into the execution view by allocating the software or hardware resources for them.

The code view describes how the system is implemented. In this view, all the functionalities of the system are fulfilled and all the runtime entities assigned by the execution view are instantiated by using a specific programming language. Thus the dependencies among system functionalities, library functions, and configuration files are made explicit in this view.

The conceptual view of the insulin delivery system is shown in Figure 7.

Click To expand
Figure 7: The conceptual view of the insulin delivery system (Sommerville, 2001)

Figure 7 depicts the conceptual view of the insulin delivery system in terms of components and connectors. Here, the connectors are abstracted as arrows pointing from one component to another. The functionalities of each component are explained as follows (Sommerville,2001):

  1. Delivery subsystem: a component that receives the output describing how much insulin dose from the controller, pumps the requested amount of insulin from the reservoir and delivers it to the patient.

  2. Sensor: a component used to measure the glucose level in the user's blood and send the results back to the controller.

  3. Controller: a component that controls the entire system.

  4. Alarm: a component used to sound an alarm when there is any problem.

  5. Display: A display component, which shows the latest measure of blood sugar and the status of the system.

  6. Clock: a component that provides the controller correct current time.

In Figure 8, the controller component has been decomposed into three functional parts, each providing a service to implement the insulin delivery function. The communications among those functional parts are also displayed. By decomposing the components, revealing the internal functionalities included in the components, and depicting the message passing among functional parts, a more detailed view of the system is provided.

Click To expand
Figure 8: Portion of the module view of the insulin delivery system (Sommerville, 2001)

The Activities of Each View

As we have mentioned in the overview of the approach, the four-view system decomposition provides a structural way to analyze the system in the vertical direction while the horizontal direction (the activities involved in each view) actually performs the detailed tasks of the approach. There are two main activities that need to be fulfilled within each of the four views: hazard derivation and priorization using SFMEA, and hazard analysis and misuse scenarios derivation using SFTA.

Hazard Derivation and Prioritization – SFMEA

The overall safety factors derived in the global analysis prior to the four-view system decomposition are those key issues which must be satisfied in the system development. Hazard analysis for the overall safety factors need to be performed to ensure the system safety. By partitioning the system development activities and engineering concerns into four different views, it is possible for us to achieve a relatively complete coverage of hazards derivation and prioritizing.

Identify the Hazards and Their Causes

There are two ways to identify the hazards for each of the four views.

First, instantiate and refine the overall safety factors derived in the global analysis. The overall safety factors will be input into each view and refined within the detail level of the specific view. For example, when the input and output of the overall safety factors is mapped into the conceptual view of the insulin delivery system, the hazard insulin dose is misadministered can be identified.

Second, further explore and refine the high-priority hazards of the earlier view. Within a view, if a hazard has high priority that means this hazard may have severe consequences. Thus, more attention and more resources need to be given to this hazard to prevent it from happening. The later view will take the high-priority hazards in the earlier view as input and further analyze and refine those hazards. This way, the hazards derivation can be traced from the earlier views to the later views and vice versa. However, note that this way of hazards derivation is not applicable to the conceptual view. The conceptual view is the earliest view, thus no high priority hazards of an earlier view exist to be used as the input. Take the above hazard insulin does is misadministered of the conceptual view as an example. This hazard is classified as high priority and input into the module view. In the module view, this hazard is refined into two hazards. One is insulin overdose and another is insulin underdose. If any of these two hazards is identified as high priority, it will be input into the execution view, and then the code view, to be further analyzed.

After the hazards have been identified, the possible reasons that may cause the hazards are assessed. The causes of the hazards provide valuable information for locating the possible erroneous requirements.

Prioritize the Hazards and Define Hazards Prevention Mechanism

When a set of hazards is derived, the potential effects they may cause during system development will be assessed. Each hazard will be assigned a level of priority according to the severity of its effect. The more severe the effect a hazard may cause, the higher the priority it will have. High-priority hazards may cause severe consequence to the system and thus deserve more attention to be paid and more system resources to be spent in order to prevent them from occurring.

Within the context of each view, the potential hazard preventing mechanisms will be defined for those high- or medium-level hazards. Those minor hazards which will not have much safety impact on the system may be left unchanged first and be taken care of when there are enough development resources available.

From the hazard identification and prioritization discussed above, we can see the hazards are the undesirable functionalities of the system that might have catastrophic consequences. Thus we categorize the hazards as misuse cases in the later utility tree construction.

We illustrate these two steps in the conceptual and module views of the insulin delivery system. The hazards in the conceptual level view of the insulin delivery system have been identified as follows by applying the SFMEA analysis. However, we omit the causes of the hazards and the hazard prevention mechanisms. The reason for doing so is to provide simplicity by not delving into too much detail as we introduce the approach while maintaining the necessary connection between steps of the approach.

  1. Insulin dose misadministered: an overdose or underdose amount of insulin is administered

    • Factors concerned: Human-computer interface
      Input and output

    • Components involved: Sensor, controller, pump, needle assembly

    • Hazard level: Catastrophic

    • Priority: High

  2. Power failure: one or more components stop functioning due to a failure in power supply

    • Factors concerned: Power supply problem

    • Hazard level: Catastrophic

    • Components involved: all components

    • Priority: High

  3. Machine interferes with other machines: Machine interferes electronically with other equipment in the environment

    • Factor concerned: Electrical interference

    • Hazard level: high

    • Components involved: sensor, controller, alarm

    • Priority: medium

  4. Sensor problem: sensor may break down or senses wrong blood sugar level

    • Factors concerned: Input and output

      • Trigger events completeness

      • Sensor and actuator quality

      • Hazard level: Catastrophic

      • Components involved: sensor

      • Priority: High

  5. Allergic reaction: Patients may be allergic to the medicine or insulin used by the delivery system

    • Factor concerned: Clinical problems

    • Hazard level: High

    • Priority: Medium

In the module view of the system, first, the identified hazards with high priorities in the conceptual view will be further refined and explored. Second, the overall safety factors will be mapped into the module view. The resulting SFMEA table is Table 4. From the SFMEA table, we can find that two hazards (the insulin misadministered and sensor problem) in the conceptual view have been refined and four additional hazards have been identified

Table 4: The resulting module view SFMEA table of the insulin delivery system

Item

Failure mode

Cause of failure

Possible effect

Priority Level

Hazard prevention

Insulin dose administered

Overdose

  1. Incorrect blood sugar measured

  2. Blood sugar analyze wrong

  3. insulin amount compute incorrect

  4. insulin delivery controller malfunction

  5. incorrect amount of insulin pumped.

Cause patient to die

High

Rigid quality control of equipments such as sensor, pump, controller to eliminate defectives. Inspection and comprehensive tests are to be used to ensure the correctness of analysis and computation methods.

Underdose

Same

Same

High

Same

Sensor

Incorrect data

  1. sensor break down

  2. incorrect data sensed

Cause wrong blood parameter s to be output

High

Rigid quality control of sensors. A range check provided to sound an alarm when the data output by the sensor is over-range or under-range

Blood sugar analysis equipment

Incorrect analysis results

  1. The input blood parameters are incorrect

  2. The method used to analyze blood sugar is incorrect

Cause wrong blood sugar analysis results

High

Recheck the input blood parameters by sensor, discard the data if it's not within the normal range. Comprehensively test the analysis method

Insulin amount computation

Incorrect amount computed

  1. The input blood sugar level is incorrect

  2. the computation algorithm is incorrect

Cause incorrect insulin amount computed

High

Set a normal range for input sugar level, sounds alarm when it's out of range. Comprehensively test the algorithm

Insulin delivery controller

Incorrect pump commands sent

  1. The input insulin amount is incorrect

  2. The delivery controller breaks down

Cause incorrect pump control command s sent

High

Compare the input insulin with the past history record, sound an alarm when there is any exception. Rigid quality check for the equipment

Insulin pump

Incorrect amount of insulin pumped

  1. The input pump control commands are incorrect

  2. Insulin pump breaks down

Cause incorrect amount insulin pumped

High

Compare the input commands with the past history record, sound an alarm when there is any exception. Rigid quality check for the equipment

Hazard Analysis and Misuse Scenarios Derivation – SFTA

Those high-priority hazards identified by SFMEA may have severe effects on system development and thus need to be further analyzed by using Software Fault Tree Analysis (SFTA).

Hazard Analysis and Fault Tree Construction

Each high-priority hazard in the SFMEA table of a specific view becomes the root hazard of a software fault tree analysis. Whether to expand the fault tree analysis to include medium- or even minor-priority hazards depends on the system needs and the availability of development resources.

The software fault tree analysis will be carried out within the context of a specific view. Therefore, for each view, its SFTA analysis will only trace down to the requirement problems which are at the same level of detail as that of this view. However, the resulting fault trees may be subject to further exploration in the next view if necessary. For example, one leaf node of the fault tree of an earlier view may become the hazard in a later view and thus be further refined there.

By performing the SFTA in this way, we can consider the possible hazards and their causes within a specific view. This allows the potential problems existing within each view to be isolated and treated independently. Also, the fault trees are adaptive and expandable in that the nodes of the fault trees in the earlier views can be further analyzed in the later views. Thus, the involvement of the same hazards in different views can be traced.

We illustrate the SFTA analysis of the module view by analyzing the hazard—the insulin overdose—and by constructing the associated fault tree as excerpted in Figure 9.

Click To expand
Figure 9: The fault tree of "insulin overdose" in the module view (Sommerville, 2001)

Misuse Scenarios Derivation

As the SFMEA gives a static way to reveal the potential hazards of the system within a specific view, the SFTA makes it possible to unveil the behaviors of system events that may cause the hazards. After the software fault trees are constructed, the misuse scenarios (Alexander, 2003) are ready to be derived and input into the utility tree.

The method used to derive those misuse scenarios is based on the minimal cut sets of the fault trees as we have discussed. Thus, every misuse scenario describes a possible system behavior sequence (intermediate nodes along the paths from the minimal cut set to the root hazard) which is aroused by the stimulus (the basic events of the minimal cut set) and results in the system response (the root hazard).

The misuse scenarios derived from the fault tree in Figure 9 are listed in Table 5.

Table 5: The derived misuse scenarios
Hazard | Misuse scenarios
Insulin overdose administered | SM1: the sensor failure causes incorrect sugar level to be measured; the system's response is to administer an overdose of insulin.
 | SM2: The sugar computation error causes incorrect sugar level to be measured; the system's response is to administer an overdosed of insulin.
 | SM3: The timer failure cause correct dose to be delivered at the wrong time, thus resulting in an overdose of insulin to be delivered
 | SM4: The insulin computation error causes delivery system failure; the system's response is to administer an overdosed of insulin.
 | SM5: The pump incorrect signals cause delivery system failure; the system's response is to administer an overdosed of insulin


Utility Tree Construction and UML Modeling

We have discussed the steps that need to be performed in our process. We are now ready to compose the main results and prepare for the further UML modeling.

Construct the Utility Tree

As we mentioned before, one of the advantages of constructing a utility tree is to provide a systematic way to gather the main results of the process. Hence, the hierarchical relationships among nodes in the utility tree clearly depict the traceable link for results from steps of the process.

We take the insulin delivery system as an example to construct the utility tree. The resulting utility tree is shown in Figure 10.

Click To expand
Figure 10: The utility tree of the insulin delivery system

The root of the utility tree is safety, which is the key concern of the system development. The overall safety factors identified in the Global Analysis section are the second-level nodes. The misuse cases and misuse scenarios derived during SFMEA and SFTA analysis for each of the four views become the lower-level nodes grouped under corresponding safety factors.

UML Modeling

To utilize the standard modeling notation provided by UML, the misuse cases and misuse scenarios are transformed into UML use case diagrams and sequence diagrams. The original definitions of the UML use case diagram and sequence diagram are notations that represent the intended system functionalities and system behaviors. It is worth noting that our misuse cases and misuse scenarios are those potentially hazardous system functionalities and behaviors that need to be prevented. The UML modeling for the misuse cases (MC1 and MC2) and misuse scenario (MSM1) of Figure 10 are illustrated in Figure 11 and Figure 12, respectively.

Click To expand
Figure 11: The use case diagram of misuse cases UC1 and UC2
Click To expand
Figure 12: The sequence diagram of misuse scenario MSM1

There are several advantages of modeling the resulting misuse cases and misuse scenarios into UML diagrams.

First, the graphical tools provided by UML help us visualize those undesirable system functionalities and behaviors. The interrelationships among system components are depicted, such that appropriate architectural decisions can be made to prevent the occurrences of those undesirable functionalities and behaviors.

Second, UML is a standard modeling language. After modeling the misuse cases and misuse scenarios into UML diagrams, those existing UML analysis methods can be adapted to further investigate the prevention mechanisms for the misuse cases and misuse scenarios.

Third, future software architectural decisions can also be modeled in UML. Thus, the misuse cases and misuse scenarios can serve to derive the architectural constraints during UML modeling.


Discussion and Future Work

We have explained our analytical approach in detail by using a case study, and, after performing the entire approach, we have two main results: an SFMEA table for each of four views, and a utility tree.

The SFMEA Table

The analysis produces an SFMEA table for each of the four views. The resulting four SFMEA tables provide traceability to the origins of the identified hazards. By checking the hazards recorded in each table, we can trace the hazards involved from the earlier views to the later views, and where the hazards originate from the later views to the earlier views.

The SFMEA tables play an important role in software evolution. The four SFMEA tables are reusable. The defined hazard-prevention mechanisms can be reused during the detailed system design stage. The common hazard-prevention mechanisms can be directly imported when the same hazards are encountered during the later software evolution. The four SFMEA tables are expandable. A new column can be added into the SFMEA table to include software architectural decisions which are made to prevent the hazards and thus satisfy the safety of the system. Those architectural decisions are subject to be evaluated and selected in the future software architectural evaluation process.

The Utility Tree

After the construction of the utility tree has been finished, the completed utility tree reveals a top-down structure of how the first-level nodes—the overall safety factors—are detailed and instantiated into misuse scenarios of each view.

The utility tree provides a visible way to illustrate how the overall safety factors may be violated by listing those misuse scenarios that can occur during the system development and that may cause catastrophic consequences. By comparing how many misuse scenarios are listed under each of the overall safety factors, those factors involving more problems can be easily highlighted. Thus, the guidance can be provided for engineers to pay more attention to those highlighted factors during system development.

The utility tree serves as an input to future software architectural evaluation. As mentioned above, the SFMEA tables can be expanded to include architectural decisions. How to rank one architectural decision over another is the key question needing to be answered during architectural evaluation. The misuse scenarios in the utility tree serve as the input to this architectural evaluation process. By evaluating how many misuse scenarios an architectural decision can prevent or how efficient an architectural decision is in preventing misuse scenarios, a better decision can be selected.

A possible direction for future work is to expand the approach to handle product line software. A product line is defined as a set of systems sharing a common, managed set of features satisfying a particular market segment or mission (Clements & Northrop, 2001). Product line software development supports reuse (building member systems from a common asset) and software evolution (a new member system is built by reusing common features of the existing member systems) (Clements & Northrop). By handling product line software, the approach can have improved adaptability during software evolution.


References

Alexander, I. (2003). Misuse case: Use cases with hostile intent. IEEE Software, Jan/Feb, 58–66.

Bass, L., Clements, P., & Kazman, R. (2003). Software architecture inpractice (2nd ed.). Boston: Addison-Wesley.

Clements, P., & Northrop, L. (2001). Software product lines: Practice and patterns. Boston: Addison-Wesley.

Clements, P., Kazman, R., & Klein, M. (2001). Evaluating software architectures: Methods and case studies. Boston: Addison-Wesley.

Hansen, K.M., Ravn, A.P., & Stavridou, V. (1998). From safety analysis to software requirements. IEEE Transactions on Software Engineering, 24(7), 573–584.

Hofmeister, C., Nord, R., & Soni, D. (1999).Applied software architecture. Boston: Addison-Wesley.

Jones, L. G., & Lattanze, A. J. (2001). Using the architecture tradeoff analysis method to evaluate a war game simulation system: A case study. Software Engineering Institute, Carnegie Mellon University, Technical Note CMU/SEI-2001-TN-022.

Kruchten, P. (1995, November). The '4+1' View Model of Software Architecture. IEEE Software, 12(6), 42–50.

Leveson, N.G. (1995). Safeware: System safety and computers. Boston: Addison-Wesley.

Lu, D. (2003). Two techniques for software safety analysis. Master's thesis, Iowa State University, Ames, IA.

Lu, D., & Lutz, R.R. (2002). Fault Contribution Trees for Product Family. Proceedings of the 13th International Symposium on Software Reliability Engineering (ISSRE'02), November 12–15, Annapolis, MD.

Lutz, R.R., & Gannod, G. (2003). Analysis of a software product line architecture: An experience report. The Journal of Systems and Software, 66(3), 253–267.

Lutz, R.R., & Woodhouse, R.M. (1997). Requirements analysis using forward and backward search. Annals of Software Engineering, 3, 459–474.

Lutz, R.R., Helmer, G.G., Moseman, M.M., Statezni, D.E., & Tockey, S.R. (1998). Safety analysis of requirements for a product family. Proceedings of the Third International Conference on Requirements Engineering (ICRE '98), 24–31.

Military Standard (1980). Procedures for performing a failure mode, effects and critical-ity analysis, MIL-STD-1629A.

Raheja, D. (1991). Assurance technologies: Principles and practices. New York: McGraw-Hill.

Reifer, D.J. (1979). Software failure modes and effects analysis. IEEE Transactions on Reliability, R-28, 3, 247–249.

Shaw, M., & Garlan, D. (1996). Software architecture, perspectives on an emerging discipline. New York: Prentice Hall.

Sommerville, I. (2001). Software engineering (6th ed.). Harlow, UK: Addison-Wesley.


Chapter III: A Unified Software Reengineering Approach towards Model Driven Architecture Environment

Bing Qiao,,
De Montfort University, UK
Hongji Yang,,
De Montfort University,
UK
Alan O'Callaghan,,
De Montfort University,
UK

When developing a software system, there are a number of principles, paradigms, and tools available to choose from. For a specific platform or programming language, a standard way can usually be found to archive the ultimate system; for example, a combination of an incremental development process, object-oriented analysis and design, and a well supported CASE (Computer-Aided Software Engineering) tool. Regardless of the technology to be adopted, the final outcome of the software development is always a working software system. Ho wever, when it comes to software reengineering, there is rather less consensus on either approaches or outcomes. Shall we use black-box or white-box reverse engineering for program understanding? Shall we produce data and control flow graphs, or some kind of formal specifications as the output of analysis? Each of these techniques has its pros and cons of tackling various software reengineering problems, and none of them on its own suffices to a whole reengineering project. A proper integration of various techniques capable of solving a specific issue could be an effective way to unravel a complicated software system. This kind of integration has to be done from an architectural point of view. One of the most exciting outcomes of recent efforts on software architecture is the Object Management Group's (OMG) Model-Driven Architecture (MDA). MDA provides a unified framework for developing middleware-based modern distributed systems, and also a definite goal for software reengineering. This chapter presents a unified software reengineering methodology based on Model-Driven Architecture, which consists of a framework, a process, and related techniques.

Introduction

What are the requirements of software reengineering nowadays? The requirements for software reengineering arise when the increasing business value outpaced the deteriorating maintainability of its underlying software infrastructure. The complexity of software maintenance has been aggravated by the introduction of the Internet giving rise to a great many popular, similar, but ultimately incompatible techniques (the side product of flexibility and openness) and gigantic software systems on the Web. It is often either too expensive or technically impossible to replace working systems on which new technologies can no longer be applied. Software maintenance on such systems becomes effectively limited to bug fixes or small functional enhancements that do not effect major structural changes. It is also difficult and expensive to find human expertise in the older technologies required to maintain legacy systems, and the accumulation of small changes inevitably results, over time, in a big impact. For such software systems, software reengineering is the only way to extend their operational lifetime or even make them capable of accommodating changes in a brand new form.

The first challenge of software reengineering is to understand a legacy system by producing system views at different abstraction levels, a task often hampered by the lack of documentation, and the immense and growing amount of legacy code. Reverse engineering is employed to identify the components of a system and their interrelationships, creating representations of the system in another form that is often at a higher level of abstraction. Program understanding can be achieved via reverse engineering, too. The two forms of reverse engineering techniques are described as: black box and white box. The former emphasises the external interfaces of subsystems, whilst the latter stresses a deep understanding of individual modules (Weiderman, 1997). The two forms of reverse engineering could be used together or separately. If the main purpose is to integrate a large legacy application into a new system, it is neither feasible nor necessary to understand the legacy application deeply. The black box reverse engineering should suffice. If only the business logic needs to be uncovered from lines of code, the white box could be applied for program understanding. However, in order to extract business object from a legacy system and integrate it to a new system, both forms of reverse engineering will have to be adopted.

As to system views, software architecture aims at providing high level abstractions for a software system via coarser-grained elements and their overall interconnection structure. Software architecture design is not only the starting point for system design and development, but should be the outcome of reverse engineering.

The second challenge of software reengineering is the complexity of keeping consistency and providing interoperability throughout the whole reengineering process. First, different but consistent views of the transforming software system are required for different stakeholders to allow cooperation between software reengineers, developers and business experts. Second, the legacy system must not lose its business logic when transformed to a higher-level of abstraction. Finally, it should be able to communicate with various tools for producing such views and checking its consistency. Understanding the legacy system is followed by choosing the target platform and techniques, both of which have a wide choice of candidates each with its own pros and cons. This variety introduces further complexity. Middleware technologies aim to hide the heterogeneity of operating systems, which in turn hide the heterogeneity of hardware systems. The proliferation of middleware implementations, however, creates itself another level of heterogeneity, since it seems unlikely that any middleware solution could dominate the market.

Therefore, answering the original question, the requirements of software reengineering nowadays are:

  • understanding a legacy system,

  • keeping the consistency among different reengineering phases,

  • implementing interoperability with other powerful tools, and

  • providing visibility for the results.

As stated earlier, there is a great deal of diversity in approaches to developing software systems. At the same time, the effort for unification never stops. A number of standards for modeling, communication, and so forth, have been established and are becoming widely accepted across the whole software industry. There is no dominant middleware implementation, but there are de facto standards which are adopted by all those implementations. The Object Management Group's Model-Driven Architecture (MDA) is intended to exploit these commonalities through a metamodel for middleware. With the Unified Modeling Language (UML), Meta-Object Facility (MOF), Common Warehouse Metamodel (CWM), and the eXtensible Markup Language (XML), MDA has the power to build up a higher abstraction upon the heterogeneity of various middleware implementations. MDA aims at providing models which can be mapped into various different technical implementations. In our view, although a functioning middleware based system is the ultimate goal of the software reengineering effort, MDA-compliant models should be firstly established out of the recovered architecture of legacy system. It is necessary to develop a software reengineering approach that is capable of reengineering a legacy system with incomplete documentation to recover its architecture and integrate it with an appropriate middleware platform, while keeping in line with widely adopted standards.


Related Work

In Anquetil (2000), a cluster algorithm is given to classify files based on their names, which could be the very first step in architecture recovery, especially when handling a big system with hundreds of thousands of files. In Hassan (2002), an approach is presented to recover the architecture of Web applications by using a set of specialised extractors to analyse the source code and binaries. However, it does not elaborate on how to implement the extractors, which is actually the basis of the approach. In Ding (2001), an approach to architecture extraction is discussed on use cases. Although emphasising a lightweight method, it lacks an appropriate representation for the recovered information of large-scale systems. Most of the other existing approaches to architecture recovery are limited to the forward engineering only and do not consider the integration of standard technologies. In Sartipi (2003), Lakhotia (1997), and Siff (1999), different approaches to software architectural recovery are presented using software technologies such as data mining, approximate graph matching, clustering, programming language design, terminology and concept analysis. All of these approaches facilitate the understanding of software systems from an architectural viewpoint, raising the level of reverse engineering since interactions between programming constructs are of crucial importance for extracting modules and components. But as stated earlier, they do not satisfy all of the requirements of software reengineering.

Research on Architecture Description Languages (ADL) can also contribute to the architecture recovery, since ADLs provide a clear goal for reverse engineering. In addition to the traditional, specialist ADLs, which are designed to use specific terminologies and notation systems, more and more researchers are building XML- or UML-based ADLs. In Fuentes (2002), a UML profile is built for MultiTEL, a framework particularly well suited for the development of Internet-based multimedia and collaborative systems. In Dashofy (2002), an infrastructure is established for the rapid development of new Architecture Description Languages using an XML-based modular extension mechanism. UML has limitations for implementing a complete ADL (Garlan, 2000), whilst XML seems to be more powerful because of its flexibility. Nevertheless, a relatively limited UML-based ADL, which has a standard representation and uses the XMI (XML Metadata Interchange) interchangeable format would be superior to a proprietary XML-based ADL because of its accessibility (through UML) and portability (through XML/XMI).


Enabling Techniques

XML and UML in System Evolution

XML and UML have been heavily used throughout modern software development. Their use has become almost de rigeur for software practitioners and is increasingly seen as mandatory for a genuine evolvable system.

System Evolution

An evolvable system is capable of accommodating changes over an extended operational lifetime. Such systems are designed explicitly for change and there is no end to evolvable system development (Warren, 1999). An evolvable system is a target of modern software development.

So what, exactly, is a legacy system? How are we to judge the evolvability of a system? A software system built dozens of years ago seems undoubtedly a legacy system; then what about an application developed a month ago using up-to-date integrated development environment? Is it definitely an evolvable system? Most legacy systems were developed using procedural languages such as C, COBOL, or Pascal, whilst most modern systems are being written in object-oriented languages such as Java, C++, or C#. Using a specific programming language itself, however, is not bound to make a legacy system. For example, Web Services techniques allow a service to be built on either procedural or object-oriented languages.

Using system duration or implementing languages as a metric is therefore insufficient for defining a legacy system unambiguously. For the purposes of this discussion, a legacy system is referred to as any working system that firstly does not provide native support for XML (that is, the system cannot produce XML documents as output and consume XML documents as input), and secondly does not provide UML views at different levels. Under this definition, the process of transforming a legacy system to an evolvable one is thus a process of XML and UML enabling, which has three phases that include:

  • understanding a legacy system,

  • designing a target system, and

  • transforming between the two architectures.

XML for Exchange

One of the most favorite features of XML is its capability for information exchange. The popularity of using XML as interchangeable format comes from its inherent advantages such as separating content and representation, implementing validation and using stylesheets in XML format. The most important advantage is, however, that XML is the de facto standard for information exchange and has been adopted by almost all software products published recently. This XML role of exchanging information is a significant part of transforming a legacy system into an evolvable one.

For example, the Java 2 platform Enterprise Edition (J2EE) and B2B (Business to Business) are two popular platforms for evolving a legacy system that will meet the requirements of an evolvable system that we mentioned earlier. The B2B architecture supports widely distributed business objects loosely coupled with XML messages, whilst the J2EE architecture supports components that encapsulate business logic and resides in a container providing the runtime environment and other services such as transactional support. The core mechanism of the B2B architecture is an XML messaging system containing a set of business processes and the XML content describing the constituent transactions, a data dictionary description of the elements that make up the XML content, and a messaging service that specifies how the XML content is packaged, transferred, and routed. To make a distributed system that has its components loosely coupled and provide enterprise functionality, it makes sense to combine the two architectures by decomposing each business object using the J2EE architecture and connecting business objects using the XML messaging system of the B2B architecture (Seacord, 2003).

Figure 1 shows the relationship of business objects, where message-oriented middleware (MQSeries) is used to implement inherently loosely coupled, asynchronous communications, XML Messaging is used to implement business-to-business (B2B) and application-to-application (A2A) transactions, and for connecting internal systems, and J2EE defines a standard for developing multitier enterprise services that are highly available, secure, reliable, and scalable.

Click To expand
Figure 1: An evolvable system implemented in combined B2B and J2EE architecture

XML for Representation

Besides information exchange, XML can be used in a number of roles; for example, lightweight data storage, configuration script files, and electronic forms. A complex system could contain more than dozens of file formats, some of which might be outdated and would better be replaced by new formats when transforming the system into a new architecture. One way to transform legacy files into XML documents is to use a Pipes and Filters architecture. Pipes and Filters is an architectural pattern in which data in a standard format is passed through a series of components (filters) that transform it in some way. The output of one filter is connected to the input of another via a connector (pipe). The filters are independent of each other. There are two interfaces (in and out) on each component and a pipe is mandatory between each pair of filters that are ordered sequentially. The pipes could be files, in-memory data structures, or database tables. Figure 2 shows an example of using this pattern to convert X12 Electronic Data Interchange (EDI) standard to XML, then to Comma Separated Values (CSV) (Rawlins, 2003), which enables a system that only processes CSV files to handle EDI documents.

Click To expand
Figure 2: The pipe and filter pattern

UML for Representation

XML is, as we have stated, the de facto standard for information exchange and can be used to represent whatever you want. It is, however, designed for machine and not straightforward for human reading. On the other hand, UML is the de facto standard for representing design in a graphical way. UML has three important aspects, each of which is indicated by its name; that is, language, model, and unified. The three aspects are explained as follows (Alhir, 2003)

Language. The UML is a language for, either formally or informally, specifying, visualizing, constructing, and documenting the artefacts of a system-intensive process, which emphasises on a systematic view of the steps for producing or maintaining a system. Specifying is to create a model to describe a system. Visualising is to use diagrams made up of different notations to represent the model. Constructing is to transform a visual depiction of UML to an implementation of the system. Documenting is to use models and diagrams to record the requirements and the system throughout the system-intensive process.

Model. A model is a miniature representation or a pattern of something. It shows a subject in an abstract way and provides a common understanding of knowledge of a system and its requirements.

Unified. UML is a widely adopted standard throughout the software industry. It is a common platform to unify various software techniques, tools, and practices.

Although UML provides a set of notations, such as Class diagram, for representing object-oriented (OO) concepts, its use is not limited to OO systems. UML profiles (library extensions) enable customisation of the canonical core of UML syntax to represent systems in specific domains. Figure 3 shows a representation of a drainage system in which a UML profile has been used.

Click To expand
Figure 3: A drainage system represented in a UML profile

XML and UML

UML is therefore designed for readability by humans and XML for machine. They look quite different when used for representation. There is, however, a formalised mapping between them; that is, XML Metadata Interchange (XMI).

An OMG standard, the XML Metadata Interchange format (XMI), is used to represent UML specifications textually. It defines mapping rules that specify how to generate an XML Document Type Definition (DTD) or Schema from a class model. The generated DTD or Schema defines a format for representing instances of the classes in XML documents. Figure 4 shows the results of running the class model of Figure 3 through an XMI-generating tool. It shows XML DTD for the interface of Pump, namely IPump, and interface point, motor_safe and its direction Provided.

Start Figure
<?xml version="1.0" encoding="UTF-8"?>
<XMI xmi.version="1.0">
...
<XMI.content>
<Model_Management.Model xmi.id="xmi.1"
xmi.uuid="...">
...
<Foundation.Core.Namespace.ownedElement>
<Foundation.Core.Interface xmi.id="xmi.2"
xmi.uuid="...">
<Foundation.Core.ModelElement.name>
IPump
</Foundation.Core.ModelElement.name>
...
<Foundation.Core.Classifier.feature>
<Foundation.Core.Operation xmi.id="xmi.3"
xmi.uuid="...">
<Foundation.Core.ModelElement.name>
motor_safe
</Foundation.Core.ModelElement.name>
<Foundation.Core.ModelElement.visibility
xmi.value="public"/>
...
</Foundation.Core.Operation>
...
</Foundation.Core.Classifier.feature>
</Foundation.Core.Interface>
...
<Foundation.Extension_Mechanisms.Stereotype
xmi.id="xmi.8">
<Foundation.Core.ModelElement.name>
Provided
</Foundation.Core.ModelElement.name>
...
</Foundation.Extension_Mechanisms.Stereotype
>
</Foundation.Core.Namespace.ownedElement>
</Model_Management.Model>
</XMI.content>
</XMI>
End Figure

Figure 4: XMI representation for a drainage system

MDA

The OMG's MDA is language, vendor, and middleware-technology neutral. Most MDA related researches focus on the high-level model integration, design or forward transformation for building an application and its models from scratch. One way to integrate legacy systems that were not built in an MDA environment is to wrap them with a layer of code consistent with the MDA framework, which means that it is not necessary to delve into the legacy system for deep understanding of its internal implementation. Adding a layer of wrapping is, however, always at the price of extra communication cost and does not eliminate any shortcomings of the legacy system that otherwise could be redeveloped in modern techniques. The other way is to build MDA models from its code and redevelop the whole system in MDA environment, which is an incremental process of abstraction, understanding, and transformation.

The MDA Development Process

As stated in its name, MDA focuses on various models existing in different phases of software development. A model could be a Computation Independent Model (CIM) or a computational model (CM). Both of them describe a system in a logical way. The former, also known as requirements model, does not involve technical factors, whereas the latter does. The computational model in MDA presents its most distinguishing features and is the focus of this chapter. It consists of two forms: the Platform Independent Model (PIM) or Platform Specific Model (PSM). It is hard to describe the definite distinction between platform independent and platform specific without giving a specific context; that is, the involved platform technologies. The terms PIM and PSM are relative terms. They only make sense when comparing models within such a context where a model is either more independent or more specific to the referenced platform technologies. Source code might be regarded as the most specific PSM. A series of PIM and PSM models construct a hierarchy of abstraction levels. MDA models at different abstraction levels can be transformed automatically to each other according to transformation rules (Transformation rules and mechanisms are first class citizens of MDA modeling). Such transformation is carried out by automated tools that take a PIM as input and produce a specific PSM as output, and, theoretically at least, vice versa.

Click To expand
Figure 5: The MDA process

Figure 5 shows the process of applying MDA. In MDA development, the first step is to create the platform independent model (PIM), which is described in UML at different levels. The base PIM expresses only business functionality and behaviour, whilst the PIMs at the next level include some aspects of technology even though platform-specific details are absent. Secondly, the produced PIM is translated to a platform-specific model (PSM) using a UML Profile. This step will generate the application (e.g., J2EE, CORBA, or .NET) from the PSM using a platform-specific code generator.

Although there is no restriction to the languages used to represent models of MDA provided they are conformant to the MOF standard, UML is the favourite choice by far, especially for PIMs, for all the reasons just described (Frankel, 2003).

Bidirectional Transformation

Although MDA advocates automatic transformations between PIM and PSM, there is little discussion in the literature about the reverse transformations between PIM, PSM, and code models.

The difference in expressive power of source and target language, the difficulty in proving validity of bidirectional transformations, and the different abstract levels of source and target models result in the bidirectionality of transformations having a low priority in practice to date. All these concerns, however, are aggregated especially when considering a legacy system that was not developed in MDA environment. In such a case, it is almost impossible to recover MDA models by a set of predefined transformation rules. Current reverse engineering techniques are either too limited or not compatible with the requirements of MDA; that is, consuming and producing models written in formalised UML or its equivalent XMI. There thus exist two separate scenarios when dealing with reverse transformations in an MDA environment. One is concerned with systems that were developed using MDA techniques and have at least complete forward transformation rules. The other is concerned with systems that were developed without the concepts of models in mind and require reverse techniques to obtain these higher-level views.

Bidirectional transformations can be achieved in two ways (Kleppe, 2003):

  • both transformations are performed according to one transformation definition, or

  • two transformation definitions are specified such that they are the inverse of each other.

No matter what methods are taken, it is very difficult, if not impossible, to map constructs in the target system to those in the source system. Even though the two models in those languages are semantically equivalent, they exist at different levels of abstraction. Transformations between different abstraction levels always involve information loss, and when moving from a low level to higher level there are likely to be details which may not have their counterparts at all in the high-level model. To achieve complete bidirectional transformations between models is only possible if the expressive power of the source and target modeling language is identical, which means that the abstraction levels of both source and target model are equivalent. Since one of the essential characteristics for MDA is that PIM is at a higher level than PSM, making both kinds of models equivalent in expressive power is unacceptable.

It is therefore not easy to achieve bidirectional transformation even for a system built in MDA environment, and it is much more difficult to do so for a non-MDA system. There is often no need, however, to transform an MDA compliant system reversely, for it conforms to the requirements of an evolvable system and could be better understandable and maintainable as long as all the PIM documents are available. The application of bidirectional transformations is most relevant in situations where the original system was not developed in an MDA environment and is now required to be transformed into an evolvable system that conforms to the MDA. To achieve this goal, reverse engineering techniques have to be used to understand the legacy system enough to produce highlevel system views which could be then implemented in any appropriate language or platform, and which could eventually be transformed to a PIM of the legacy system (via formal UML diagrams). Figure 6 shows the process of software reengineering within MDA environment.

Click To expand
Figure 6: Software reengineering within MDA environment


Understanding Legacy Systems

Figure 7 shows a cubic model for understanding legacy systems, which goes through four activities (program translation, modules identification, components identification, and architecture recovery) for which corresponding patterns and representations are required. The four activities actually exist at four different abstraction levels and present accordingly different system views. The following sections explain these activities in detail.

Click To expand
Figure 7: A cubic model for understanding legacy systems

Program Translation

As the simplest form of reengineering, program translation converts a legacy program consistently between two or more programming languages. Source code translation often happens when porting a system written in an obsolete or proprietary language and aims to transform it equivalently into another system written in a well understood and supported language (Warren, 1999).

Sometimes the target of program translation is not a better language but an intermediate one. One typical intermediate language is Microsoft Intermediate Language (MSIL, or IL). IL, as an implementation of the Common Intermediate Language (CIL), is the internal format of all the .NET languages. It is therefore possible to make a single compiler supporting a multiple language development environment. The concept of an intermediate language is also applicable in reverse engineering where a reverse engineering approach is designed against a specific language, into which other languages can be translated via respective translators. Although source code translation will not improve the structure of the legacy program, it reduces complexity and workload, for only one language has to be handled for analysing a multilanguage system. In this way, program translation will be the first step in understanding a legacy system.

Source code translation is normally performed using automated tools, especially when the target language is an updated version of the source language. Otherwise human intervention is required where there is no counterpart in the target language for a construct in the source language. MSIL is, however, an exception, for all the .NET languages are defined in accordance with a Common Type System (CTS).

Modules Identification

Object oriented languages provide a well-defined interface to their objects through classes, each of which encapsulates a single design decision. As the building blocks of OO systems, objects represent a higher-level abstraction than procedures in structural systems. Actually, a general way to understand a structural system is to recover objects based on the relationships between variables and procedures. Therefore a well-built OO system can be regarded as a readily modularised one, whilst a structural system often has to be modularised first before going through the other activities of reverse engineering.

In a structural system, a complete function is implemented by a group of procedures, which are not independent on their own. For example, a procedure for returning a poster's information in a bulletin board system is called by many other procedures. Program modularisation gathers related procedures into modules, which makes it easier to identify and eliminate redundant code, optimise interactions between modules, and simplify interactions with the rest of the system (Seacord, 2003). Program modularisation is the second step in understanding a legacy system.

To find out the relationships between procedures, their internal behaviour must be understood, which means to get a higher-level view by applying a series of abstraction rules. Reverse engineering techniques are used to produce such views or specifications of individual procedures, which are then analysed together with a call graph to aggregate related procedures into an individual module.

Components Identification

The process of identifying design includes identifying encapsulated data and databases, identifying data and control flow, identifying encapsulated functions, and clustering the identified modules. The final step, clustering the identified modules, will produce component specifications based on the module identification. Components exist at a higher level of abstraction again than either modules or objects. Components are coarsegrained and have a wide range of intercommunication mechanisms with strictly defined interfaces.

When identifying components from a legacy system, both bottom-up and top-down strategies are adopted. Whilst individual components are understood by analysing the modules aggregated in them, the interactions between components need to be mapped onto a concept model proposed by domain experts. Included in such a model are any design patterns that likely exist in the legacy systems. The produced component specifications are then used as the initial building blocks of the legacy system architecture.

Architecture Recovery

Architecture recovery is an interpretive, interactive, and iterative process which requires the efforts of both reverse engineering experts and architects so that architectural constructs can be recovered by analysing diverse mechanisms in an implementation (Bass, 2003). Architecture recovery aims to produce a highest level of abstraction of a legacy system, which is built on the understanding of individual procedures, modules, and components. An appropriate description language is required to represent the recovered architecture, for such a high-level abstraction is used not only by technically literate developers, but also by managers and other stakeholders. The initial architecture, made up of identified components, is matched against an architectural pattern proposed by domain experts. This pattern gives a clue in the search of candidate architecture, whilst the identified components are used to update the initial architecture by interactions between components.


A Unified Software Reengineering Framework

The core of the Unified Software Reengineering (USR) framework that we propose is a Reengineering Wide Spectrum Language (RWSL) that is a formal language used to combine both reverse and forward engineering. Several studies (Liu, 2000; Yang, 1998; Chen, 1999; Qiao, 2003) address a series of reengineering technologies of RWSL. Figure 8 illustrates the framework of RWSL which consists of Interval Temporal Logic (ITL), Architecture Description for Software Reengineering (ADSR), Timed Guarded Command Language/Common Structural Language (TGCL/CSL) and Object-Oriented Temporal Agent Model/Common Object-Oriented Language (ObT AM/COOL).

Click To expand
Figure 8: The USR framework

ITL

Interval Temporal Logic (ITL) forms the most abstract and logical layer in our language. It is used to give specification-oriented semantics for TGCL, ObTAM, and ADSR. Furthermore, all transformation, object extraction, abstract and refinement relations and rules are precisely interpreted and proved within ITL. ITL is a flexible notation for both prepositional and first-order reasoning about periods of time found in descriptions of hardware and software systems. Unlike most temporal logics, ITL can handle both sequential and parallel composition and offer powerful and extensible specification and proof techniques for reasoning about properties involving safety, liveliness, and projected time.

TGCL/CSL

The Timed Guarded Command Language (TGCL) is an extension of Dijkstra's Guarded Command Language (Dijkstra, 1976) with the time and concurrency feature. The Common Structural Language (CSL) is a variation of TGCL with a more program-like format and diversity in statements. Both TGCL and CSL are at the code level, whilst in CSL operators and concepts are implemented in common programming elements, such as shunts.

ObTAM/COOL

Object-Oriented Temporal Agent Model is an extension of Temporal Agent Model (TAM) language (Scholefield, 1994) with object-oriented features. The most concrete layer of the objectoriented section is Common ObjectOriented Language (COOL), which provides structures like those in an ordinary OO language. The syntax of ObTAM is the same as the syntax of TGCL less the procedural part, but with additional object oriented portions.

ADSR

Architectural analysis plays a significant role during software evolution, for only analysis on the architectural level enables a real evolution of a system. Software architecture focuses on the structure and interrelationships between system components. Architecture Description Languages (ADLs) have been defined to model the architecture of a software system and facilitate the exchange between different phases of the evolution process. With an appropriate level, an ADL could be an effective way to implement discovery and reuse of architectural patterns. A general, three-part definition for ADL is given in (Medvidovic, 2000), where an ADL is stated to have a

  • Component, which is a unit of computation or data store.

  • Connector, which is architectural building blocks used to model interactions among components and rules that govern those interactions.

  • Configuration, which is connected graphs of components and connectors that describe architectural structure.

Most extant ADLs are either dedicated to a specific system or too complicated to be used to represent outcomes of reverse engineering. To address this issue, an Architecture Description for Software Reengineering (ADSR) is designed built on the core techniques of our reverse engineering tool. ADSR is structured similarly to generic ADLs and consists of components, connectors, and configuration.

Description of Components

Component is firstly identified by the natural factors such as physical location of the source code files and naming conventions. Some of those components are then aggregated through abstraction rules. It requires software engineers to define a threshold of when to stop combining subcomponents into a larger component. The composite component has attributes referencing its constituent components but hiding the specifications of them.

The most important attributes of a component are interface and semantics. Other attributes that are considered during the design phase include types, constraints, nonfunction properties, and so forth (Medvidovic, 2000). These, however, are not defined in ADSR and will be discussed in future research. In ADSR, the interface of the component is a collection of service ports provided or required, and the semantics of the component can be deduced easily from the extracted ITL specification. The concept of ports does not exist in UML 1.x (it has been added to the UML 2.0 specification), and is yet to be widely applied. Here it is implemented using UML profiles.

Description of Connector

Connectors intermediate between components and can be used to aggregate components by abstraction rules. A group of roles are used to bind the corresponding service points of components. In Shaw (1995), UniCon defines seven connector types: Pipe, FileIO, ProcedureCall, DataAccess, PLBundler, RemoteProCall, and RTScheduler. In ADSR, connector types are extended and classified into two categories according to the context in which a connection occurs: local and distributed.

Local connectors include some of those from UniCon. They can directly connect different components without relying on network protocols.

  • LocalCall represents procedure call (structural system) or method invocation (OO system).

  • File I O represents the file system operations.

  • SharedData represents global shared variables.

Distributed connectors implement interprocess communications across networks.

  • SocketCnn represents Socket connections, which is the abstraction of User Datagram Protocol (UDP) and Transfer Control Protocol (TCP) protocols.

  • RemoteCall represents RPC (Remote Procedure Call, structural system) or RMI (Remote Method Invocation, OO system) connections.

  • GroupCnn represents group connections.

  • MsgPassing represents message passing connections.

Description of Configuration

The operations on recovered connectors may result in the combination of connected components, which is a kind of architecture abstraction. The configuration presents interconnection relationships between components and connectors of the subsystem. It is the structure description of the whole architecture.

Description of Component Types in ADSR

Traditional ADLs have type systems, either extensible or predefined, for their constructs (Medvidovic, 2000). To date, the architecture description in RWSL only defines one type of component: general component. There are good reasons for this. To identify the particular type of the recovered component or connector relies on complex pattern recovery. As to components, it is difficult to solve the variants problem due to the diversity and complexity of their implementations. On the other hand, the types of connectors are presented more clearly in source code (e.g., a procedure call, stub and skeleton files, sending a message, and using shared resource) all of which can easily be identified during the initial abstraction process.

The traditional ADLs focus on the elaborate description of design and implementation, and the type systems are established to normalise such description. ADSR is, however, not a design or implementation oriented language, it is a description for understanding the existing system. It is therefore not necessary to have type system for components as long as the extracted architecture is capable of providing a pellucid high-level view of the existing system.

The appropriate way to visualise the recovered architecture is to present it in a UML model. Although a number of researches have been done on UML-based ADL (Medvidovic, 2002), the mapping of traditional ADLs with their heavily addressed type systems to UML is cumbered with insufficiency in the canonical core of UML or clumsy UML profiles (Garlan, 2000). In the circumstances, a relatively lightweight ADL, which can be mapped perfectly onto a UML profile, is enough for the reverse engineering phase of software reengineering.


A Unified Software Reengineering Process

A process is a series of activities bringing about the final result. The activities in the USR process fall into five such phases: initialisation, modules identification, components identification, architecture recovery, and reincarnation within MDA, which are shown in Figure 9.

Click To expand
Figure 9: A USR process

Firstly initial components are identified in a system through system decomposition techniques. The subsystems are then translated equivalently into RWSL via universal translators. Transformation rules are used to restructure the source code in RWSL. Thirdly, abstraction rules are applied on the restructured RWSL code to get the system architecture composed of interconnected components. Finally, in order to integrate with MDA environment, the recovered architecture is mapped onto UML diagrams which can be presented visually and translated into XMI for information exchange. The viability of the whole process depends on four techniques:

  • CSL/COOL Translation. Source code is translated into functionally equivalent description in RWSL, upon which the transformation and abstraction rules are carried out

  • RWSL Code Transformation. Transformation rules will be applied on CSL/COOL code for program restructuring

  • Architecture Recovery. The configuration, which presents the interconnections between components and connectors and system-level properties such as processing rates, end-to-end capacities, and overall performance, is recovered

  • MDA Integration. The recovered architecture information in ADSR will be represented in UML diagrams, which could be transformed into Platform Independent Model (PIM) of MDA

The outcome from CSL/COOL translation and transformation establishes an initial system layout, which can be abstracted to approximate the final architecture through abstraction rules. This step carries on iteratively and will be improved with the enrichment of pattern library based on abstraction rules. To be transformed into an evolutionary system, the recovered architecture is firstly analysed to establish the Platform Independent Model, which is obtained by revising the ADSR representation, and then mapped onto appropriate middleware implementations. The significant advantages of this approach come from its core technique RWSL which has been applied successfully in program translation, restructuring and abstraction, all of which have been verified mathematically (Liu, 1999). The full support for reverse engineering guarantees the correctness of following evolution phases; that is, integration with MDA, model establishment and implementation.

Initialisation

  • Propose Legacy Concept Model

  • Translate to CSL/COOL

  • Propose Use Case Model

The Initialisation phase aims to set a starting point by translating the legacy system to CSL/COOL by universal translators, proposing a legacy concept model, used to make such preliminary analyses as whether procedures should be divided into layers, and a use case model used to map identified components in the later Component Identification phase.

Modules Identification

  • Understand procedures

  • Modularise procedures

The approach used to understand the procedures of a structural system is also applicable when analysing the behaviour of an object in an OO system. Therefore only the process of understanding a structural system is depicted in Figure 10. There exist many ways to modularise a legacy system. After finishing understanding individual procedures, modularisation is carried out via iteratively absorbing the leaves of the call graph of all procedures. The level of modularisation is determined by the knowledge from the concept model. For example, procedures invoking no other procedures but system APIs will be absorbed into their callers, on which a further abstraction will be performed to update its specification.

Click To expand
Figure 10: The process of modules identification

Abstraction Rules

All abstraction rules are defined with ITL in production format; that is, the applicability condition is put as the premise, and the result as the action. They are classified into three categories: elementary abstraction rules, further abstraction rules, and architecture abstraction rules (Liu, 2000; Qiao, 2003). The first two are applied in the phase of modules identification for understanding procedures. The last one is applied in the phase of architecture recovery for aggregating components.

Abstraction Patterns

The effective application of abstraction rules is based on a successful recognition of abstraction patterns, which indicate the information that could be left out in a system representation at a higher level of abstraction. These abstraction patterns are classified into five categories in terms of their different forms in software systems: State Test and Exception Handling, User Interface Format, Semantic Core, Domain Function, and Efficiency-Improving Details (Liu, 1999).

Components Identification

  • Identify components.

  • Map components onto Use Case model

Although modularisation provides a higher level of abstraction than the original system, the produced modules are still finegrained and tightcoupled due to the nonemployment of design concerns during aggregating procedures. To address this issue, in the phase of components identification, top-down and bottom-up strategies are combined to recover the relationships between modules and thus aggregate them into components. Figure 11 shows the process of components identification.

Click To expand
Figure 11: The process of components identification

Relationships between Modules

In the phase of modules identification, the call graph is used for aggregating procedures by absorbing the leaves into callers. This time, however, the call graph will be combined with data analysis to build a Working Modules and Relations (M&R) database that has tables with four columns: Module A, Module B, Relation and Belief. Although Module A and Module B are input for module aggregation, the Relation represents the possible relationship between them within a certain design pattern and the Belief denotes the possibility of this relationship.

Setting beliefs requires handling uncertainty, where a number of factors, including procedure calls, global variables, and data accessing could affect a belief value. An appropriate uncertainty description is therefore necessary to address this issue. The Certainty Factor approach overcomes the heaviness of other uncertainty descriptions, such as Machine Learning techniques represented by Artificial Neural Networks, Nonmonotonic Descriptions represented by Default Reasoning and Minimalist Reasoning, and Statistics-based uncertainty description represented by Bayesian Networks (Li, 2002). To balance the accuracy and complexity, Certainty Factor is employed in this phase to set beliefs for relations between modules in respect to a possible design pattern.

Abstractions in the phase of modules identification can help understand individual modules, but in the meantime less relevant statements are left out. To be complete and accurate, the call graph for component identification must be constructed from the source code rather than abstracted modules.

Design Patterns

Design pattern describes a commonly recurring structure of communicating components that solves a general design problem within a particular context (Gamma, 1995). Patterns are usually described using a format including the following information (Grand, 2001),

  • a description of the problem that includes a concrete example and a solution specific to the concrete problem,

  • a summary of the forces that lead to the formulation of a general solution,

  • a general solution,

  • the consequences, good and bad, of using the given solution to solve a problem, and

  • a list of related patterns.

Design patterns are represented as a group of M&R records with predefined beliefs. During the process of identifying components, a design pattern is matched against the Working M&R database. Every successful matching may lead to revision of the beliefs of the relevant records in the Working M&R database. A design pattern will be recovered when the related beliefs reach a predefined level. At this point, all the modules participating in this design pattern can be grouped by their respective roles into components. For example, when

an abstracted module with a given belief is considered to be inside a component that plays a role in a design pattern, such as a client in client/server architecture, all the other modules interacting with it will be checked to see if they should be inside the same component and their beliefs will be revised accordingly.

Architecture Recovery

  • Identify architecture

  • Reincarnation within MDA

An identified component represents a functional, relatively independent part of the legacy system that is the building block for the final architecture description. Similar to components identification, architecture recovery is performed by combining top-down and bottom-up strategies; that is, analysing the relationships between components and their connectors against architectural patterns proposed by domain experts. For integration with MDA process, a Platform Independent Model will be produced from the components and connectors architecture.

An ADLR (ADL for Reengineering) is used to map detailed implementation to abstract architecture, whilst UML is the core technology of MDA. Since ADSR is designed with a corresponding UML representation, there exists a mapping between ADSR and UML. Therefore, RWSL achieves the evolution vision of MDA, serving as the liaison between reverse and forward phases of the whole evolution process and presenting a unified view for system developers. Figure 12 shows the process of architecture recovery.

Click To expand
Figure 12: The process of architecture recovery

Relationships between Components

Relationship analysis in this phase is still based on the call graph of components produced from the components identification phase. The call graph is combined with component specifications to build a Working Components and Connectors (C&C) database that has tables with four columns: ‘Component A’, ‘Component B’, ‘Connector’ and ‘Belief’. Whilst ‘Component A’ and ‘Component B’ are input for component aggregation, the ‘Connector’ represents the possible connection between them within a certain architectural pattern, and the ‘Belief’ denotes the possibility of this connection. Setting beliefs for the C&C database is similar to that for the M&R database where Certainty Factor is employed to handle uncertainty.

Architecture Abstraction Rules

Architecture abstraction rules are basic principles for architecture recovery. Some of them are shown in the following list.

Point: Interface Point.

Frame: Let W be a set of state variables then frame(W) denotes that only the variables in W can possibly change, that is, the variables outside the frame do not change.

  1. Primitive Component

    Initial component is defined as primitive component which can be source file, program module, and subsystem.

  2. Component Composition

    Component composition is the combination of two components which have direct connectors, such as procedure call or shared variable that may be combined into one component.

  3. Trivial Component

    If a part of the system's functionality is considered too ‘trivial’ to be kept in high-level abstraction, the components related to this part of functionality are identified as ‘trivial components’, which should be abstracted away in architecture description.

  4. Primitive Connector

    Initial connector is defined as direct connector which can be shared resources, function or procedure call, interprocess call, and so forth.

  5. Connector Composition

    Connector composition is the combination of two connectors connecting the same component set into one connector.

  6. Trivial Connector

    If all the components connecting to a connector are trivial components, this connector is considered a trivial connector and should be abstracted away in architecture description.

Architectural Patterns

An architectural pattern provides a system template in a specific domain and typically consists of several design patterns. In Frankel (2003) architectural patterns are divided into four categories by the characteristics of the systems in which they are most applicable:

  • Structure: Layers, Pipes and Filters, and Blackboard

  • Distributed Systems: Broker

  • Interactive Systems: Model-View-Controller and Presentation-Abstraction-Control

  • Adaptable Systems: Reflection Microkernel

Such classification can be more detailed. For example, a Web-based system is only one form of distributed systems. Architectural patterns are represented as a group of C&C records with predefined beliefs. During the process of architecture recovery, an architectural pattern is matched against the Working C&C database. Every successful matching between the records of them may lead to revision of the beliefs of the relevant records in the Working C&C database. An architectural pattern will be recovered when the related beliefs reach a predefined level. At this point, all the components participating in this architectural pattern can be grouped by their respective roles to produce a complete architecture description.


Implementation of the Unified Software Reengineering Approach

RWSL is initially implemented in LISP where all the abstraction rules, CSL/COOL code, and abstracted specifications are stored in a LISP database. With the increasing popularity of XML, it is, however, reasonable to use XML-based representations and develop a compiler based on available XML parsers.

Description of Components

In Figure 13, a component description is implemented using an XML element COMPONENTof type ComponentType, which consists of an Attribute NAME and one or more elements SPECS, representing the semantics of the component. A SPECS is an element of ComSpecsType, which has two elements, INTERFACE and ITLSPECS, and an attribute NAME.

Start Figure
<?xml version="1.0"?>
<xsd:schema
xmlns:xsd="http://www.w3.org/2001/XMLSchema
">
...
<xsd:simpleType name="PortDirection">
<xsd:restriction base="xsd:string">
<xsd:enumeration value="REQUIRED"/>
<xsd:enumeration value="PROVIDED"/>
</xsd:restriction>
</xsd:simpleType>
</xsd:complexType name="ParamType">
<xsd:sequence>
<xsd:element name="PARAM" type="xsd:string"/>
</xsd:sequence>
</xsd:complexType>
<!-- Definition for PortType that represents an
interface point or player of an interface -->
<xsd:complexType name="PortType">
<xsd:sequence>
<xsd:element name="PARAMETER"
type="ParamType" minOccurs="O"
maxOccurs="unbounded"/>
</xsd:sequence>
<xsd:attribute name="NAME" type="xsd:string"/>
<xsd:attribute name="DIRECTION"
type="PortDirection"/>
</xsd:complexType>
<!-- Definition for Interface Type that represents
interfaces used by components to communicate with
connectors -->
<xsd:complex Type name="InterfaceType">
<xsd:sequence>
<xsd:element name="PORT" type="PortType"
minOccurs="1" maxOccurs="unbounded"/>
</xsd:sequence>
<xsd:attribute name="NAME" type="xsd:string"/>
<xsd:complexType>
<!-- Definition for ComSpecsType that represents a
specification of an interface of a component -->
<xsd:complex Type name="ComSpecsType">
<xsd:sequence>
<xsd:element name="INTERFACE"
type="InterfaceType"/>
<xsd:element name="ITLSPECS"
type="xsd:string"/>
</xsd:sequence>
<xsd:attribute name="NAME" type="xsd:string"/>
</xsd:complexType>
<!-- Definition for ComponentType that represents
a component consisting of interfaces and
specifications -->
<xsd:complexType name="ComponentType">
<xsd:sequence>
<xsd:element name="SPECS"
type="ComSpecsType" minOccurs="1" maxOccurs="unbounded"/>
</xsd:sequence>
<xsd:attribute name="NAME" type="xsd:string"/>
</xsd:complex Type>
<!-- Definition for COMPONENT -->
<xsd:element name="COMPONENT" type="Component Type"/>
...
</xsd:schema>
End Figure

Figure 13: XML schema for a component

Description of Connector

In Figure 14, a connector description is implemented using an XML element CONNECTOR of type ConnectorType, which consists of two attributes, NAME and TYPE, and one or more elements SPECS, representing the semantics of the connector. A SPECS is an element of ConSpecsType, which has two elements, ROLE and ITLSPECS.

Start Figure
<?xml version="1.0"?>
<xsd:schema
xmlns:xsd="http://www.w3.org/2001/XMLSchema
">
...
<xsd:simple Type name="RoleDirection">
<xsd:restriction base="xsd:string"/>
<xsd:enumeration value="IN"/>
<xsd:enumeration value="OUT"/>
</xsd:restriction>
</xsd:simple Type>
<xsd:complex Type name="Role Type">
<xsd:attribute name="NAME" type="xsd:string">
<xsd:attribute name="DIRECTION" type="xsd:string"/>
</xsd:complex Type>
<!-- Definition for ConSpecs Type that represents a
specification of a connector-->
<xsd:complex Type name="ConSpecsType">
<xsd:sequence>
<xsd:element name="ROLE" type="RoleType"/>
<xsd:element name="ITLSPECS" type="xsd:string"/>
</xsd:sequence>
</xsd:complex Type>
<!-- Definition for Connector Type that represents
the types that a connector can belong to -->
<xsd:complex Type name="ConnectorType">
<xsd:sequence>
<xsd:element name="SPECS"
type="ConSpecsType" minOccurs="1"
maxOccurs="unbounded"/>
</xsd:sequence>
<xsd:attribute name="NAME" type="xsd:string"/>
<xsd:attribute name="TYPE" type="xsd:string"/>
</xsd:complexType>
<!-- Definition for CONNECTOR -->
<xsd:element name="CONNECTOR" type="ConnectorType"/>
...
</xsd:schema>
End Figure

Figure 14: XML schema for a connector

Description of Configuration

In Figure 15, a configuration description is implemented using an XML element CONFIGURATION of type ConfigurationType, which consists of any number of elements PROPERTY and one or more elements CONNECTION, and an attribute NAME. A CONNECTION is an element of type ConnectionType, which has five attributes, ROLE, CONNECTOR, PORT, INTERFACE, and COMPONENT.

Start Figure
<?xml version="1.0"?>
<xsd:schema
xmlns:xsd="http://www.w3.org/2001/XMLSchema
">
...
<xsd:complex Type name="ConnectionType">
<xsd:attribute name="ROLE"
type="xsd:RoleType"/>
<xsd:attribute name="CONNECTOR"
type="xsd:ConnectorType"/>
<xsd:attribute name="PORT"
type="xsd:PortType"/>
<xsd:attribute name="INTERFACE"
type="xsd:InterfaceType"/>
<xsd:attribute name="COMPONENT"
type="xsd:ComponentType"/>
</xsd:complexType>
<!-- Definition for ConfigurationType -->
<xsd:omplexType name="ConfigurationType">
<xsd:sequence>
<xsd:element name="PROPERTY"
type="xsd:string" minOccurs="0"
maxOccurs="unbounded"/>
<xsd:element name="CONNECTION"
type="ConnectionType" minOccurs="1"
maxOccurs="unbounded"/>
</xsd:sequence>
<xsd:attribute name="NAME" type="xsd:string"/>
</xsd:complexType>
<!-- Definition for CONFIGURATION -->
<xsd:element name="CONFIGURATION"
type="ConfigurationType"/>
...
</xsd:schema>
End Figure

Figure 15: XML schema for configuration

Modules and Relations Database

In Figure 16, the description of M&R database is implemented using an XML element MRDATABASE of type MRDatabaseType, which consists of any number of elements RECORD of type MRRecordType, representing a relationship between two modules.

Start Figure
<?xml version="1.0"?>
<xsd:schema
xmlns:xsd="http://www.w3.org/2001/XMLSchema
">
...
<xsd:complexType name="ModuleType"
mixed="true">
<xsd:attribute name="NAME" type="xsd:string"/>
<xsd:attribute name="TYPE" type="xsd:string"/>
<xsd:attribute name="LOCATION"
type="xsd:string"/>
</xsd:complexType>
<xsd:complex Type name="RelationType"
mixed="true">
<xsd:attribute name="NAME" type="xsd:string"/>
<xsd:attribute name="TYPE" type="xsd:string"/>
</xsd:complexType>
<xsd:complexType name="MRRecordType">
<xsd:sequence>
<xsd:element name="MODULE"
type="ModuleType"/>
<xsd:element name="MODULE"
type="ModuleType"/>
<xsd:element name="RELATION"
type="RelationType"/>
</xsd:sequence>
</xsd:complexType>
<xsd:complexType name="MRDatabaseType">
<xsd:sequence maxOccurs="unbounded">
<xsd:element name="RECORD"
type="MRRecordType"/>
</xsd:sequence>
</xsd:complexType>
<!-- Definition for MRDatabase -->
<xsd:element name="MRDATABASE"
type="MRDatabaseType"/>
...
</xsd:schema>
End Figure

Figure 16: XML schema for M&R database

Components and Connectors Database

In Figure 17, the description of C&C database is implemented using an XML element CCDATABASE of type CCDatabaseType, which consists of any number of elements RECORD of type MRRecordType, representing a relationship between two components.

Start Figure
<?xml version="1.0"?>
<xsd:schema
xmlns:xsd="http://www.w3.org/2001/XMLSchema
">
...
<xsd:complexType name="ComponentType"
mixed="true">
<xsd:attribute name="NAME" type="xsd:string"/>
<xsd:attribute name="TYPE" type="xsd:string"/>
<xsd:attribute name="LOCATION"
type="xsd:string"/>
</xsd:complexType>
<xsd:complexType name="ConnectorType"
mixed="true">
<xsd:attribute name="NAME" type="xsd:string"/>
<xsd:attribute name="TYPE" type="xsd:string"/>
</xsd:complexType>
<xsd:complexType name="CCRecordType">
<xsd:sequence>
<xsd:element name="COMPONENT"
type="ComponentType"/>
<xsd:element name="COMPONENT"
type="ComponentType"/>
<xsd:element name="CONNECTOR"
type="ConnectorType"/>
</xsd:sequence>
</xsd:complexType>

<xsd:complexType name="CCDatabaseType">
<xsd:sequence maxOccurs="unbounded">
<xsd:element name="RECORD"
type="MRRecordType"/>
</xsd:sequence>
</xsd:complexType>

<!-- Definition for CCDatabase -->
<xsd:element name="CCDATABASE"
type="CCDatabaseType"/>
...
</xsd:schema>
End Figure

Figure 17: XML schema for C&C database

Abstract Syntax Tree (AST)

Figure 18 shows a simplified grammar for CSL to demonstrate how the CSL code is processed.

Start Figure
<statement> := <assignment statement>
                     | <while statement>
                     | <duration statement>
                     | <delay statement>
                     | <if then else statement>
                     | <statement> <statement>
<assignment statement> := <variable> = <expression>;
<while statement> := while (<expression> ) {<statement>}
<duration statement> := duration (<expression>) {<statement>}
<delay statement> := delay <variable>;
<if then else statement> := if ( <expression> ) {<statement> } else {<statement>}
<expression> := <variable>
                     | <expression> + <expression>
                     | <expression> - <expression>
                     | <expression> * <expression>
                     | <expression> / <expression>
<variable> := a | b | c | ... | z
End Figure

Figure 18: A simplified grammar for CLS

Every statement defined by this grammar is represented by an abstract syntax tree made up of instances of these classes. Consider the duration statement as an example. In the text form, it could be as follows:

Duration (m + n) {x = a*b;}

The statement could be represented in a syntax tree as shown in Figure 19.

Click To expand
Figure 19: AST form of RWSL duration statement

In Figure 20a, the Duration statement is represented using XML. In Figure 20b, an XML schema is defined for an XML-based AST.

Start Figure
<DURATION_STATEMENT>
<ARGUMENT>
<EXPRESSION OPERATOR="ADDITION">
<ARGUMENT>
<VARIABLE NAME="M"/>
<VARIABLE NAME="N"/>
</ARGUMENT>
</EXPRESSION>
</ARGUMENT>
<BODY>
<ASSIGNMENT_STATEMENT>
<TARGET>
<VARIABLE NAME="X"/>
</TARGET>
<SOURCE>
<EXPRESSION
OPERATOR="MULTIPLICATION">
<ARGUMENT>
<VARIABLE NAME="A"/>
<VARIABLE NAME="B"/>
</ARGUMENT>
</EXPRESSION>
</SOURCE>
</ASSIGNMENT_STATEMENT>
</BODY>
</DURATION_STATEMENT>
End Figure

Figure 20a: Duration statement in XML-based AST
Start Figure
<?xml version="1.0"?>
<xsd:schema
xmlns:xsd="http://www.w3.org/2001/XMLSchema">
...
<xsd:element name="VARIABLE"
type="xsd:string">
<xsd:complexType>
<xsd:attribute name="NAME"
type="xsd:string"/>
</xsd:complexType>
</xsd:element>

<xsd:element
name="DURATION_STATEMENT"
type="DurationStatementType"/>

<xsd:element
name="ASSIGNMENT_STATEMENT"
type="AssignmentStatementType"/>

<xsd:element name="EXPRESSION"
type="ExpressionType"/>
<xsd:element name="ARGUEMENT">
<xsd:element name="EXPRESSION"
type="ExpressionType" minOccurs="1"
maxOccurs="unbounded"/>
</xsd:element>

<xsd:element name="BODY">
<xsd:sequence minOccurs="1"
maxOccurs="unbounded">
<xsd:choice>
<xsd:element
name="DURATION_STATEMENT"
type="StatementType"/>
<xsd:element
name="ASSIGNMENT_STATEMENT"
type="AssignmentStatementType"/>
</xsd:choice>
</xsd:sequence>
</xsd:element>
…
</xsd:schema>
End Figure

Figure 20b: XML schema for AST

Implementing Abstract Syntax Tree

The grammar defined for CSL is implemented as a set of classes, each of which corresponds to a specific grammar rule. This is actually an example of the Interpreter pattern (Gamma, 1995), which takes a set of grammar rules of a language to define a class hierarchy representing statements of that language. Symbols on the right-hand side of a grammar rule are instance variables of the classes representing the left-hand side of each rule. In the case of CSL, this simplified grammar would be represented by ten classes: Abstract Construct, Non Terminal Node, Terminal Node, Assignment Statement, While Statement, Duration Statement, DelayStatement, IfThenElseStatement, Expression, and Variable, the first three of which are abstract classes. Figure 21 shows the Interpreter and Visitor design patterns composed of these classes.

Click To expand
Figure 21: The Interpreter and Visitor design patterns

According to Interpreter pattern, an abstract Interpret() operation needs to be declared in the root class AbstractConstruct and implemented by both terminal and nonterminal subclasses respectively. To interpret a program, a client builds an Abstract Syntax Tree of terminal and nonterminal instances. Then it invokes the Interpret() operation passing a ‘Context’ object as parameter, which contains global information, to the interpreter. The Interpreter pattern is not limited to evaluating an expression. Other interpretations, such as pretty printing or type-checking, can be supported by adding new Interpret() operations, which means that different Interpret() operations exist in a node object. Whilst adding new operations in this way gives rise to changes of all the classes in the Abstract Syntax Tree, using Visitor pattern could obviate this need.

The Visitor pattern is useful when a polymorphic operation cannot be included in the class hierarchy for such reasons as the operation is not designed until finishing the class hierarchy or it would degrade the interface of the classes. In the CSL class hierarchy of nodes, every Abstract Construct can contain zero or more subAbstract Construct as children. They make up a Composite pattern where objects are composed into tree structures to represent part-whole hierarchies, and clients are able to treat individual objects and compositions of objects uniformly (Gamma, 1995). In this complex hierarchy, distributing all the interpretation-related operations across a class hierarchy results in a system that is hard to implement, change, and extend.

The Visitor pattern encapsulates related operations from each class in a separate object, and passes it to nodes of the Abstract Syntax Tree as it is traversed. When a node object accepts the visitor, the accept() method calls the visit() method of the visitor, passing itself as an argument. The visitor object receives a reference to each of the instances and can then call its public methods to access data, check types, evaluate expression, or generate abstraction code.

Implementing Abstraction Rules

In the following listings, a Further Abstraction Rule, Sequence Folding, is implemented in Java.

AbstractConstruct defines the abstract base class for all classes that define a RWSL statement:

public abstract class AbstractConstruct {
 protected String name;
 public AbstractConstruct() {
 }
 public void accept(Visitor v) {
  v.visit(this);
 }
 public void add(AbstractConstruct node);
 public void remove(AbstractConstruct node);
 public AbstractConstruct getChild(int n) {
  return null;
 }
}

The class Context defines an applicabilityTest() method to test if no contradiction is caused when substituting the sequential composition between two representations to conjunction composition. Context is defined as follows:

public class Context {
 public Context() {}
 public boolean applicabilityTest(AbstractConstruct ac1, AbstractConstruct ac2) {
  boolean test = false;
  ...
  return test;
 }
}

A NonTerminalNode class represents a statement such as WhileStatement, AssignmentStatement, and DurationStatement.

public class NonTerminalNode extends AbstractConstruct {
 Vector children;
 public NonTerminalNode() {
  children = new Vector();
 }
 public void add(AbstractConstruct node) {
  children.add(node);
 }
 public void remove(AbstractConstruct node) {
  children.remove(node);
 }
 public AbstractConstruct getChild(int n) {
  return (AbstractConstruct)children.elementAt(n);
 }
}

Each abstraction rule is implemented by a specific class that is the subclass of the Visitor class. For example, Sequence Folding is implemented by SequenceFolding Visitor.

public abstract class Visitor {
 Context context;
 public Visitor() {
 }
 public void setContext(Context ct) {
  context = ct;
 }
 ...
 public abstract void visit(NonTerminalNode var);
 ...
}

The Sequence Folding Abstraction Rule is implemented by checking the children of a NonTerminal Node to substitute the sequential composition to conjunction composition; that is, replacing semicolon separators with logic and separators.

public class AbstractionGeneratingVisitor extends Visitor {
 public SequenceFoldingVisitor() {
 }
 ...
 public void visit(NonTerminalNode node) {
  Vector children = node.getChildren();
  Iterator i = children.iterator();
  AbstractConstruct ac1 = (AbstractConstruct)i.next();;
  AbstractConstruct ac2;
  for (int index = 0; index < children.size()-1; index++) {
   ac2 = i.hasNext() ? (AbstractConstruct)i.next() : null;
   if (getContext().applicabilityTest(ac1, ac2)) {
     conjunction(ac1, ac2);
   }
   ac1 = ac2;
  }
 } ...
}

The visit() method of SequenceFolding Visitor class is invoked by the accept method of every nonterminal node that has substatements as children (tested by applicabilityTest() method of the Context class) and the Sequence Folding abstraction rule is applied on every two adjacent nonterminal nodes that can be related by conjunction without giving rise to contradiction.

Architecture Description in UML

Architecture description could be achieved using UML in many ways. The architecture description for the drainage system is represented in UML-class diagram with an architecture description UML profile. A profile is a collection of stereotype definitions, tag definitions, and constraints used to represent a specific domain or target. Although profiles could be used to easily extend UML, sometimes a more general way is preferred for better interoperability with other automatic tools.

Figure 22 shows the UML diagram for component description, consisting of three classes, one datatype, and one enumeration.

  • Interface: ADSR supports specification of component interfaces that consists of interface points, that is, ports, for participating in a specific connection. In ADSR, interface points have one of two properties: provided and required that represent the direction of the connection.

  • Type: As stated before, ADSR does not have predefined component types. It distinguishes components by their names.

  • Semantics: The semantics of ADSR components can actually be represented in any formal languages. Currently ITL is used as the semantics of ADSR constructs.

Click To expand
Figure 22: UML diagram for component

Figure 23 shows the UML diagram for connector description, consisting of three classes and one enumeration.

  • Interface: The connectors of ADSR have roles as counterparts of components. A connection between a component and a connector is established through the ports of the component and the corresponding roles of the connector. The only difference of interface between components and connectors is that a component could have as many as possible interfaces, whilst a connector has only a set of roles that make up one interface, which simplifies the architecture description to meet the requirements of representing the outcomes of reverse engineering.

  • Type: As stated before, ADSR has predefined connector types that are set by the attribute name of class ConnectorType.

  • Semantics: ADSR currently uses ITL to give connectors their semantics.

Click To expand
Figure 23: UML diagram for Connector

Figure 24 shows the UML diagram for configuration, consisting of two classes.

Compositionality. Most ADLs provide explicit features to support hierarchical composition of components by adopting similar syntax for specifying both composite components and configurations (Medvidovic, 2000). Although components and configurations in ADSR have different syntax, it is straightforward to compose multiple architectures by simply merging those configuration objects into a single one that consists of all the connections of those architectures.

Semantics. The semantics of configuration are obtained by analysing the semantics of its connections, which in turn rely on its connectors and components.

Figure 25 shows a complete architecture description using ADSR.

Click To expand
Figure 25: UML diagram for architecutre as Component & Connector

Tool Support

Universal Thinker (UT) is a semiautomatic tool that aims at assisting software engineers in the process of reengineering legacy systems. UT is a rule-based intelligent system, which reflects the architecture of USR in Figure 8. The legacy source code is firstly translated into CSL or COOL, and then the CSL/COOL code is parsed and displayed in the browser interface. Meanwhile, the internal M&R and C&C databases of the code are generated, through which transformation and abstraction can be performed conveniently. Software engineers could choose three different processes to reengineer the legacy system:

  • Program Transformer: CSL/COOL code is improved through the program transformer. New required extra functionalities can also be added.

  • Object Extractor: If the object-oriented paradigm is sought, object extraction is performed on the CSL code to obtain an equivalent COOL code.

  • Architecture Abstractor: To seek a high-level specification, the abstractor extracts it from CSL or COOL code. Abstraction taxonomy, rules, and abstraction patterns are implemented in the abstractor. The extracted specification could subsequently be used as a basis for re-specification, re-design, and forward engineering.

Click To expand
Figure 24: UML diagram for Configuration

The architecture abstractor is the most important part, acting as an inference machine. Abstraction rules for various domain applications are classified into profiles and implemented as inference rules. Abstraction patterns are identified and represented in USR as pattern assertions. The extracted ITL specification is stored in the M&R and C&C Databases, in a syntax tree structure specially designed for logic formulae. During the abstraction process, those databases provide the necessary data, the extracted specification is displayed in the Browser Interface, and the process information is displayed in the interactive window.


A Case Study

To demonstrate the USR approach, a case study is conducted on an online game, Noughts and Crosses, shown in Figure 26. The game allows a person to contact a game server and request a game of noughts and crosses. Once the system has two requests, it pairs the requestors off to play a game and will then wait for further requests, in the meanwhile allowing any existing games to proceed. The server maintains the status of the game and passes moves from one player to the next and also decides who has won the game (or whether it is a draw). It then passes the appropriate messages back to each player.

Click To expand
Figure 26: Noughts and crosses

Both the client and server are implemented in Java. Using a system written in Java as the subject of this case study to some extent obviates the need for modules and components identification given the object-oriented nature of Java language. There are two reasons for that. Firstly, it is a bit difficult to demonstrate those two phases in one specific example in a general way. Although an overall process and its related activities for those two phases are given in previous sections, there is often not a standard way of implementing those activities when applying that process in the real world. For example, different reverse engineers may have different views concerning which parts of the system should be classified as a component. Secondly, abstraction of individual procedures or methods of a class and the final representation of the whole architecture is the focus for this time, and those two phases could be implemented automatically without ambiguity.

The fully implemented system is quite complex. Here only one simplified class abstraction is presented, the process of which applies to other classes, too. Although MDA itself is developing rapidly and a number of products claim to be MDA compliant, reverse engineering a program into MDA models is still quite immature. To date, this research does not intend to present a full-fledged tool capable of reversing source code automatically, but to establish a reference model consisting of description languages, abstraction rules, and a reengineering process. The following example is well fit for that purpose. The final recovered architecture is represented using ADSR.

Source Code Translation

Server side class XOServer waits for two clients to connect and then starts a game between this pair of clients using a GameSession object to create a new thread before returning to wait for more clients. The source code of class XOServer is shown in Figure 27.

Start Figure
public class XOServer {
 public static final int DEFAULT_PORT = 3000;
 private Vector sessions;
 private ServerSocket server;
 private boolean switch = false;
 public XOServer() throws IOException {
  sessions = new Vector(10);
  try {
    server = new
ServerSocket(DEFAULT_PORT, 20);
   switch = true;
  }
  catch(IOException ioException) {
   ioException.printStackTrace();
   System.exit(1);
  }
 }
public void execute() {
 while (sessions.size()<10) {
  Socket players[] = new Socket[2];
  for (int i=0; i<2; i++) {
   try {
    if (switch) {
     players[i] = server.accept();
    }
   }
   catch(IOException ioException)
    ioException.printStackTrace();
    System.exit(1);
   }
  }
  sessions.addElement(new
GameSession(players[0], players[1]));
  }
 }
}
End Figure

Figure 27: Source code of the server side class XOServer

Before abstraction, a legacy system is translated into CSL for structural languages or COOL for object-oriented languages. The COOL code for class XOServer is shown in Figure 28.

Start Figure
public.XOServer = {
 DEFAULT_PORT : public.static.final.int :=
3000;
 sessions: Private.Vector;
 server: private.ServerSocket;
 switch = false: private.boolean:
 XOServer() {
  sessions := new.Vector (10);
  try{
    server :=
new.ServerSocket(DEFAULT_PORT,20);
   switch := true;
  }
  catch(IOException ioException) {
   ioException.printStackTrace();
   System.exit(l);
  }
 }
public.void.execute() = {
  while (sessions.size()<10) do
   Socket players[] = new Socket[2];
   for i: int :=0 to 2 step 1 do
    try {
      if switch then
       players[i] = server.accept();
      fi
     }
     catch(IOException ioException) {
      ioException.printStackTrace();
      System.exit(l);
     }
    od
    sessions.addElement(new
GameSession(players[0], players[l]);
  od
 }
}
End Figure

Figure 28: COOL code of the server side class XOServer

Abstraction of Individual Models

As stated before, class XOServer could be regarded as a module that implements specific functionality. We first extract a specification of the class through applying the elementary abstraction rules as shown in Figure 29.

Start Figure
public.XOServer {DEFAULT_PORT, sessions,
server, switch} : {
 XOServer {}: {
  try {
    server:=
new.ServerSocket(DEFAULT_PORT, 20);
   switch := true;
  }
  catch(IOException ioException) {
   ioException.printStackTrace();
   System.exit(l);
  }
 }
public.void.execute {}: {
 {players, i} : ((sessions.size()<10)
                 (
                  ((x<2)(try{
                              (switchOn)
(players[i] := server.accept());
                            }
                            catch(IOException
ioException) {

ioException.printStackTrace();
                           System.exit(l);
                          }
                          x := x + 1
                  ))*

sessions.addElement(new.GameSession(players[0
].players[l]));
               ))*
 }
}
End Figure

Figure 29: XOServer after applying elementary abstraction rules

State tests and exception handling are often used in programs to assure smooth execution. Although they might be important in system implementation, these details do not involve crucial functionality of a system and in high-level specification, these details are unnecessary and should be abstracted away. Therefore in the next step, these details are eliminated by applying a further abstraction rule (semantics weakening) as shown in Figure 30.

Start Figure
public.XOServer ≽ {DEFAULT_PORT, sessions, server, switchOn} : {
 XOServer ≽ {}: {
  server := new.ServerSocket(DEFAULT_PORT, 20);
  switchOn := true;
 }
 public.void.execute ≽ {} : {
  {players, i} : ((sessions.size()<10)
                  (
                     ((x<2)(
                                (switchOn) (players[i] := server.accept());
                                x := x + 1
                     ))*
                     sessions.addElement(new.GameSession(players[0], players[l]));
                 ))*
 }
}
End Figure

Figure 30: XOServer after applying further abstraction rules

In the next step, we make the specification more concise and professional by applying domain knowledge, such as patterns, to identify the domain function socket connection. This specification is an ITL formula that allows software engineers a better understanding of the program through it.

Architecture Representation

The final architecture of the Noughts and Crosses online game consists of three main connectors including two local calls and one socket connection. The configuration of this architecture is composed of three connections which connect their participants respectively. The ADSR representation of this architecture is shown in Figure 31.

Click To expand
Figure 31: Architecture description of noughts and crosses


Conclusion

Whilst software reengineering is a systematic approach to evolving a legacy system, this technology itself must keep evolving as well. At times, a new platform or a new implementing language is required as the targets of applying software reengineering. Could we make our software reengineering tools as evolvable as the systems that they are used to create? The answer is "Yes". It was the advent of Model-driven Architecture that really transformed not only the way to develop software, but the way to reengineer a legacy system. The evolvable approach to software reengineering is to integrate those traditional methods within MDA environment.

USR is a unified approach to achieving software reengineering, which has solid foundation: formal equivalent transformation and abstraction rules which have been proved mathematically (Liu, 1999) and applied successfully in system transformation and abstraction. The four requirements presented in the first section are addressed by this approach as follows:

  • Understanding a legacy system: USR is capable of representing both procedural and object- oriented legacy systems and has abstraction rules that are applied on RWSL code to produce specifications at different levels of abstractions.

  • Consistency among different evolution phases: Although in different phases, USR has different representations, such as TGCL/CSL for structural systems, ObTAM/COOL for OO systems, and DSR for architecture recovery. USR also has ITL as the core semantics for all the representations and rules support.

  • Interoperability with other powerful tools: The recovered architecture can be equivalently transformed into XML which is the de facto standard for data interchange format.

  • Visibility for easy understanding and operating: The recovered architecture can be equivalently transformed into UML representation which has been visualised by many commercial or open source tools.

Future work will focus on the way to build Abstract Syntax Tree by fully implementing an XML-based compiler, the way to access XML database, and the way to formalise abstraction rules using OCL.


References

Alhir, S. (2003). Learning UML. Cambridge, MA: O'Reilly & Associates.

Anquetil, N., & Lethbridge, T. (2000). Recovering software architecture from the names of source files. Journal of Software Maintenance: Research and Practice, 11, 201-221. New York: John Wiley.

Bass, L., Clements, P., & Kazman, R. (2003). Software architecture in practice (2nd ed.). Boston: Addison-Wesley.

Chen, Z., Zedan, H., Cau, A., & Yang, H. (1999). A wide-spectrum language for object-based development of real-time systems. International Journal of Information Sciences, 118, 15–35. Bethesda, MD: Cambridge Scientific Abstracts.

Dashofy, E., Hoek, A., & Talor, R. (2002). An infrastructure for the rapid development of XML-based architecture description languages. IEEE International Conference on Software Engineering, 266–276. Orlando, FL.

Dijkstra, E. (1976). A discipline of programming. Englewood Cliffs, NJ: Prentice Hall,

Ding, L., & Medvidovic, N. (2001). Focus: A light-weight, incremental approach to software architecture recovery and evolution. IEEE/IFIP Working Conference on Software Architecture. Amsterdam, The Netherlands.

Frankel, D. (2003). Model driven architecture applying MD A to enterprise computing. New York: John Wiley.

Fuentes, L., Troya, J., & Vallecillo, A. (2002). Using UML profiles for documenting Web-based application frameworks. Annals of Software Engineering, 13, 249–264. Dordrecht, The Netherlands: Kluwer Academic Publishers.

Gamma, E., Helm, R., Johnson, R., & Vlissides, J. (1995). Design Patterns: Elements of object-oriented software. Boston: Addison-Wesley.

Garlan, D., Cheng, S., & Kompanek, A. (2000). Reconciling the needs of architectural description with object-modeling notations. Science of Computer Programming, 44, 23–49. Amsterdam, The Netherlands: Elsevier North-Holland.

Grand, M. (2001). Java enterprise design patterns. New York: John Wiley.

Hassan, A. (2002). Architecture recovery of Web applications. International Conference of Software Engineering, 349–359. Orlando, FL.

Kleppe, A., Warmer, J., & Bast, W. (2003). MDA explained: The mode driven architecture: Practice and promise. Boston: Addison-Wesley.

Lakhotia, A. (1997). A unified framework for expressing software subsystem classification techniques. Journal of Systems and Software, 36(3), 211–231. New York: Elsevier Science.

Li, Y. (2002). Automating domain knowledge recovery from legacy software code. Doctoral dissertation, Software Technology Research Laboratory, De Montfort University, Leicester, UK.

Liu, X. (1999). Abstraction: A notion for reverse engineering. Doctoral dissertation, Software Technology Research Laboratory, De Montfort University, Leicester, UK.

Liu, X., Yang, H., Zedan, H., & Cau, A. (2000). Speed and scale up software reengineering with abstraction patterns and rules. IEEE International Symposium on Software Evolution, Kanazawa, Japan.

Medvidovic, N., & Taylor, R. (2000). A classification and comparison framework for software architecture description languages. IEEE Transactions on Software Engineering, 26(1), 70–93. Piscataway, NJ: IEEE Press.

Medvidovic, N., Rosenblum, D., Robins, J., & Redmiles, D. (2002). Modeling software architectures in the unified modeling language. A CM Transactions on Software Engineering and Methodology, 11(1), 2–57. New York: ACM Press.

Qiao, B., & Yang, H. (2003). Bridging legacy systems to model driven architecture. IEEE Conference on Computer Software and Application, Dallas, TX.

Rawlins, M. (2003). Using XML with legacy business applications. Boston: Addison-Wesley.

Sartipi, K., & Kontogiannis, K. (2003). On modeling software architecture recovery as graph matching. IEEE International Conference on Software Maintenance, Amsterdam, The Netherlands.

Scholefield, D., Zedan, H., & He, J. (1994). A specification-oriented semantics for the refinement of realtime systems. Theoretical Computer Science.

Seacord, R., Plakosh, D., & Lewis, G. (2003). Modernizing legacy systems: Software technologies, engineering processes, and business practices. Boston: Addison-Wesley.

Shaw, M., Deline, R., Klein, D. V., Ross, T. J., Young, D. M., & Zelesnik, G. (1995). Abstractions for software architecture and tools to support them. IEEE Transactions on Software Engineering, 21(4), 314–335. IEEE Computer Society.

Siff, M., & Reps. T. (1999). Identifying modules via concept analysis. IEEE Transactions on Software Engineering, 25(6), 749–768. IEEE Computer Society.

Warren, I. (1999). The renaissance of legacy systems, method support for software-system evolution. New York: Springer.

Weiderman, N., Northrop, L., Smith, D., Tilley, S., & Wallnau, K. (1997). Implications of distributed object technology for reengineering (Technical Report, CMU/SEI-97-TR-005 ESC-TR-97–005). Pittsburgh, PA: Carnegie Mellon University, Software Engineering Institute.

Yang, H., Liu, X., & Zedan, H. (1998). Tackling the abstraction problem for reverse engineering in a system reengineering approach. IEEE Conference on Software Maintenance, 284–293.


Appendix

Glossary of Terms

ADL
Architecture Description Language
ADSR
Architecture Description Language for Software Reengineering
CIM
Computation Independent Model
COOLL
Common Object-Oriented Language
CSL
Common Structural Language
CWM
Common Warehouse Metamodel
ITL
Interval Temporal Logic
MDA
Model-Driven Architecture
MOF
Meta-Object Facility
ObTAM
Object-Oriented Temporal Agent Model
PIM
Platform Independent Model
PSM
Platform Specific Model
TGCL
Timed Guarded Command Language
UML
Unified Modeling Language
XMI
XML Metadata Interchange
XML
Extensible Markup Language


Chapter IV: Towards the Integration of a Formal Object-Oriented Method and Relational Unified Process

Jing Liu,
United Nations University, Macau
Zhiming Liu,
United Nations University, Macau and University of Leicester,
UK
Xiaoshan Li,
University of Macau,
Macau
He Jifeng,
United Nations University,
Macau
Yifeng Chen,
University of Leicester,
UK

In this chapter, we study the use of a formal object-oriented method within Relational Unified Process (RUP). Our purposes are (a) to unify different views of UML models; (b) to enhance RUP and UML with a formal method to improve the quality of software; (c) to scale up the use of the formal method with the use-case driven, iterative and incremental aspects of RUP. Our overall aim is to establish a sound foundation of RUP and UML and scale up the use of formal methods in software-intensive system development.

Introduction

Nowadays, software, such as that used for health care, social security, or defence, is a model of part of the real world. The development of such software starts from the modeling of the real world. The model is then transformed into a series of refined models. Such refinement eventually reaches executable code. As the real world keeps changing, the software system needs to be constantly maintained, evolved, and upgraded to meet the changing requirements. To develop and maintain such evolving software is obviously difficult. A well-disciplined development process and a good modeling notation are essential to control the activities in constructing and documenting the different models.

Rational Unified Process (RUP) proposed in Jacobson, Booch, and Rumbaugh (1999) and Kruchten (2003) has emerged as a popular software development process. The modeling notation used in RUP is UML (Booch, Rumbaugh, & Jacobson, 1999), which is the defacto standard modeling language for software development in a wide range of applications. UML supports not only the early development stages of requirement analysis and specification but also the latter stages of design and implementation (Jacobson et al.; D'Souza& Wills, 1998).

RUP promotes several good practices in which the one that stands above the others is the idea of use-case driven, iterative and incremental development. In the iterative approach of RUP, development is organized as a series of short, fixed-length miniprojects called iterations; the outcome of each iteration is a tested/verified and executable integrated system. Each iteration includes its own requirements analysis, design, implementation, and testing/verification activities.

The iterative development approach distinguishes RUP from the traditional waterfall development process. In a waterfall process, the whole system is treated at every stage of requirements analysis, design, and implementation. Such a development process works well in a small-sized software development but is not feasible for a large-scale system development.

Although RUP and UML are popular in practice, they are not well founded with a formal method. On the other hand, being conceived and maturing in those years when structured analysis and design were dominant, formal methods have been mainly used to make the waterfall software development model more precise, rigorous, and easier to justify and understand. The research in formal methods has resulted in a number of formal theories for specification, verification, and refinement. These are useful in improving the quality of software systems and making software safer to use. However, formal methods have inherited the same disadvantages from the informal waterfall model of structured-analysis approach and suffer more seriously from these disadvantages, because the formal specification of the whole system, at any level, is too difficult to understand for most software engineers. Although modular and compositional approaches have been studied and indeed used, it is still not well understood how a system can be decomposed into components, which are then composed together to meet the whole system requirements.

The use of a formal method within RUP is therefore desirable for precise definition and rigorous reasoning about the consistency and relationships of the different UML models created in one particular cycle and across different cycles. We believe that formal methods can be improved to support use-case driven, iterative and incremental programming in order to scale up and become more widely used.

In this chapter, we present the first part of our work towards the integration application of a predicative formal object-oriented method and RUP. The whole formal object-oriented method will include:

  • an object-oriented specification language (OOL),

  • a predicative semantic model for OOL,

  • a calculus (COOL) that allows us to reasoning about object-oriented specifications and designs, and

  • a set of object-oriented refinement laws for transformations and manipulations of object-oriented designs.

The formal method will be able to provide a formalization of the UML models and formal justification of the activities in use-case driven, iterative and incremental development activities.

In this chapter, we will describe the syntax and semantics of OOL and show how to use them in the formalization of UML models of requirements and designs. We will focus on the iterative and incremental feature of RUP and try to answer the following questions:

  1. How to formalize a UML model of the requirements in an iteration and ensure the consistency between static and dynamic views of the model?

  2. How to formalize a UML model of the design in an iteration and ensure the consistency between the static and dynamic/interactive views?

  3. How to formally relate the UML models of the design and requirements in an iteration?

  4. How to preserve the established consistency and correctness in sequent iterations?

We are approaching these problems by first developing a calculus for object-oriented specification language (COOL). COOL includes an object-oriented specification language (OOL) (He, Liu, & Li, 2003; Liu, He, Li, & Liu, 2003) and a refinement calculus (He, Liu, & Li, 2002). It is based on Hoare and He's Unifying Theories of Programming (UTP) (Hoare & He, 1998). We will then study how UML models of requirements and designs can be formally represented and reasoned about in OOL (Liu, Li, & He, 2002; Liu, He, Li, & Chen, 2003).


RUP and UML

RUP is popular mainly because of its iterative and incremental nature. In each iteration, the main technical activities are requirement analysis, design, and implementation.

Requirement Analysis

The requirement analysis of an iteration is to create a UML model for the requirements RM = (CM, UM) that consists of a conceptual class model CM and a use-case model UM (Larman, 2001; Liu, Li, & He, 2002).

The use-case model consists of a use-case diagram and a textual description of the use case. The use-case diagram provides only static information about the use cases. The dynamic semantic aspects are described in textual descriptions of use cases as the sequences of interactions between actors of the use case and the system. A UML system sequence diagram is used to describe the order of the interactions between the actors, and the system is treated as a black box but it does not describe the change of the system state caused by such an interaction. Formalization of a use-case model should deal with both the order of interactions and the state changes caused by these interactions.

The conceptual model is a class diagram consisting of classes (also called concepts), and associations between classes. A class represents a set of conceptual objects and an association determines how the objects in the associated classes are related in the application domain. The reason we call the class diagram conceptual at this level is that it is not concerned with what an object does, how it behaves, or how an attribute is represented. The decisions on these issues will be made during the design phase when the responsibilities of a use case are decomposed and assigned to appropriate objects (Larman, 2001; Liu, Li, & He, 2002). The UML community says that the class model represents the static view, whereas the use-case model represents the dynamic view of the requirements. In our formal setting, the consistency between use-case model UM and conceptual model CM can be checked to ensure that the use cases in UM are realizable under the conceptual model CM. Therefore the conceptual model and use-case specification can be formally refined.

Design

A design is to transform the model of requirements to a model of design DM = (DC, SD) that consists of a design class diagram and a family of interaction (or sequence) diagrams. The interaction diagrams SD, representing the dynamic view of the design, show how objects of the system interact and collaborate with each other. The creation of the interaction diagrams mainly involves assignment of responsibilities to objects so that their interactions can correctly realize the use cases. Use-case decomposition and responsibility assignment are carried out according to the knowledge that the objects maintain. What an object can do depends on what it knows, though an object does not have to do all that it can do. What an object knows is determined by its attributes and associations with other objects (Larman, 2001; Liu, Li, & He, 2002).

After the responsibilities of the objects are decided, the directions of the associations (that is, navigation and visibility from one object to another) and the methods of classes can be determined. This will lead to the construction of the design class diagram DC, that shows the static view of the design, that is, how the concepts and associations of the conceptual class diagram are realized by software classes.

Assignment of responsibilities to objects in the creation of a collaboration diagram can be done by informally applying design patterns (Gamma, Helm, Johnson, & Vlissides, 1995). However, our formal model allows us to prove that the design is a refinement of the requirement, and to further refine a design, too.

Implementation

The implementation is to code the design in a programming language. In an OO programming language, this is to define the software classes in the design class diagram, as well as their methods based on the interaction diagrams. Once the interaction diagrams and the design class diagram are obtained, code can be easily generated from it.


Specification Notation

OOL is a class-based specification language with classes, reference types, visibility, dynamic binding, nested declaration, and mutual recursive method calls. Both class declarations and commands are as notion of designs in Hoare and He (1998). All the programming language constructions are defined in the same way as their counterparts in an imperative programming language. This makes the approach more accessible to users who are already familiar with imperative program design.

Syntax

A program specification is of the form cdecls • P, where cdecls is the declaration section, and P is a command.

Class Declarations

A declaration section cdecls is of the form cdecls ::= cdecl| cdecls; cdecl, where cdecl is a class declaration of the following form

where

  • N and M are names of classes, and M is called the direct superclass of N. A symbol with an underline represents the list of that symbol, such as U represents a list of U.

  • The private declaration declares the list of private attributes a of the class N and their types U, and similarly, the protected and public declarations for the lists of protected and public attributes. We define

    and similarly pro(N) and pub(N). We use attr(N) to denote the union of these three sets of attributes; and for an attribute a of N, we use dtype(N.a) to denote the type of a declared in N. Assume an attribute protected when it is not tagged with private or public.

The method declaration declares the methods mi's signatures with their parameters parasi which is of the form Ti1xi, Ti2yi, Ti3zi, where Ti1xi, Ti2yi and Ti3zi are the value-parameters, result-parameters and value-result parameters, denoted as val(N.mi), res(N.mi), and valres(N.mi). Each method mi has a body ci, denoted by body(N.mi).

Commands

Our language supports typical OO programming constructs:

where b is a Boolean expression, and le an expression which may appear on the left-hand side of an assignment and is of the form le ::= x | le:a | self where x is a simple variable and a is an attribute of an object. For C.New(x)[e], e creates a new object of class C and its attributes are initialized by a list of values. We use if {(bi → Pi) | l ≤ i ≤n}fi to denote the multiple-choice statement.

Expressions

Expressions, which can appear on the right-hand sides of assignments, are constructed according to the rules below.

where null represents the special object of the special class Null that is a subclass of all class and has null as its unique object. We can include more expressions, such as type casting (C)e and type test (e is C), but they are not needed in this chapter.

Semantics

Based on UTP (Hoare and He, 1998), the semantics of a program or a program command are defined as a design, which is represented by a pair (α, P), where

  • α denotes the set of variables of the program.

  • P is a predicate of the form

    where x and x' stand for the initial and final values of program variables x ∊ a, the predicate p, called the precondition of the program, characterizes the initial states in which the activation of the program will lead its execution to termination, and the predicate R, called the postcondition of the program, relates the initial states of the program to its final states. We describe the termination behavior of a program by the Boolean variables ok and ok', where the former is true if the program is properly activated and the later becomes true if the execution of the program terminates successfully.

A program command usually modifies a subset of the program variables α. Let β be a subset of α, the notation β : (p ⊢ R) denotes the (framed) design

For example, we can define the following program statements:

  • skip = df⊘ : true ⊢ true

  • chaos = df⊘ : false ⊢ true

  • x :=e= df{x}: true ⊢ x'=val(e)

  • {z} :(x,y ∊ N) ⊢ z' =gcd(x, y), where gcd is the greatest common division of x and y

  • P;Q = df∃m·P(s, m) ○Q(m, s')

Within this model, functional refinement between programs (or commands) can be simply defined as implication of designs. Formally speaking, let D2 defined as (a, P2) and D1 defined as (a, P1) be two designs on the same alphabet, we say D2 is a refinement of D1, denoted by D1 ⊆ D2, if P2 entails P1, that is,

where x, …, z are variables contained in α.

We say that D1 and D2 are equivalent, denoted by D1 ≡ D2, if and only if D1 ⊆ D2 and D2 ⊆ D1.

When the alphabets of the designs are different, we need the notion of data refinement by a state mapping. Let ρ be a mapping from α2 to α1. We say that D2 is a refinement of D1 under r, denoted by D1 ⊆ D2, if (ρ; P1) refined by (P2; ρ).

Here are a couple of simple examples of refinement:

  • chaos ⊆ P

  • skip; P ≡ P ≡ P; skip

  • chaos; P ≡ chaos ≡ P ; chaos

Values and Objects

A value is either a member of a primitive type or an object identity (or reference). We assume an infinite set REF of object identities, and null ∊ REF. An object o is an entity defined by the following structure:

where ref ∊ REF, and type is a class, and state is a mapping from attr(type) to objects. For an object o =< ref, C, σ >, we use Ref(o) to denote the identity ref of o, type(o) to denote the type C of the object o, state(o)(a) to denote the value σ(a) of an attribute a of class C.

Let O be the set of all objects, including null, such that for any o1 and o2 in O, Ref(o1) = Ref(o2) implies type(o1) = type(o2) and state(o1) = state(o2). We therefore can use identity of an object in O to refer to the object. In the rest of the chapter, an object o =< ref,C, σ > means one in O if there is no confusion, and will use ref.a to denote state(o)(a), and type(ref) to denote type(o).

Variables and States

Our model describes the behavior of an OO program by a design containing the following logical variables as its free variables.

  1. cn: its value is the set of class names which are declared so far, and it is modified by a class declaration.

  2. Each class N ∊ cn is associated with

    1. attr(N): the set of class N's (declared or inherited) attributes. We also use a ∊ attr(N) to denote that a is an attribute name of class N.

    2. op(N): the set of class N's (declared and inherited) methods.

      which states that each method mi has parasi as its formal parameters, and that the behavior of mi is defined by the design Di referred by (N.mi). These variables are modified by class declarations.

  3. For each N ∊ cn, Σ(N) is the set of objects of class N current existing in the execution of the program, and it will be changed by creating a new object (and destroying an existing object that we do not deal with in this chapter). Let

  4. super: the partial function maps a class to its direct superclass. This variable is also modified by a class declaration.

  5. var: its value is the set of variables which are known to the program. Since our language allows nested declaration, var associates each variable with a sequence of types

    where Til for i = 1,…,n is the most recently declared type of xi and denoted by dtype(xi). We will also use varT(x) to denote the sequence of types associated with x.

  6. visattr: its value is the set of attributes which are visible from outside the current class, that is, all its declared attributes plus the protected attributes of its superclasses and all public attributes. This value will be modified by the whole declaration of the program and by variable redeclarations.

  7. x~: this logical variable represents the state of variable x. Since a variable can be redeclared, its state is usually a nonempty finite sequence of values, whose first (head) element represents the current value of variable x. A variable of a primitive data type can take any member of that type as its value. However, an object variable can store an object name or identity as its value.

Notations

We introduce the following notations:

  • A class N is said to be a subclass of M, denoted by N ≪ M, if either N = M, or there exists a finite set {Ci | 0 ≤ i ≤ n} of classes such that

  • Let s =<s1,……,sk > be a non-empty sequence. We use head(s) to denote the first element s1 of s; tail(s) is defined as < s2,…,sk > that is, the sequence obtained from s by removing its first element (it can be the empty list < >); |s| the length k of s; and πi(s) the ith element si, for i: 1,…, k.

  • Let S and S1 be sets. is the set with the elements of S1 being removed from S, [image] .

  • For a mapping F : D ↦ E, d ∊ D and r ∊ E

    where

  • For an object o =< ref, C, σ >, an attribute a of C and an entity d which is either a member of a primitive type or an object in O,

  • For a set S ⊆ O of objects,

Evaluation of Expressions

The evaluation of an expression e determines its type type(e) and its value. The evaluation makes use of the state of Σ(C) for each class C ∊ cn. We use D(e) to denote the well-defined expression e.

  • A variable x is well-defined if it is declared in var, its type is either primitive and then its current value is a member of this type, or a class in cn and in this case its current value is an identity of an object.

    where D(x) denotes that variable x is well-defined.

  • The null object expression,

  • self is a special variable whose type has to be a class in cn, and it is evaluated in the same way as other variables,

  • An attribute le.a is defined only when le is of type of a class and attached to a non-null object, and a is an attribute name. An attribute is thus defined inductively as follows:

  • The following exemplifies the well-definedness and evaluation of built-in expressions

  • The semantics of the equality e1 = e2 is the reference equality:

Semantics of Commands

A typical aspect of an execution of an OO program is about how objects are to be attached to program variables (or entities [Meyer, 1989]). An attachment is made by an assignment, the creation of an object, or passing a parameter in a method invocation.

When we define the semantics [[μ]] of an element μ of the language, we will use μ itself to denote its semantics in a semantic-defining equation.

Assignments: There are two cases of assignments. The first is to (re)attach a value to a variable. This can be done only when the type of the object is consistent with the declared type of the variable. The attachment of values to other variables is not changed.

The second case is to modify the value of an attribute of an object attached to a variable. This is done by finding the attached object in the system state S and modifying the state accordingly. Thus, all variables that point to the identity of this object will be changed.

Object creation: The execution of C.New(x)[e] (re-)declares variable x, creates a new object, attaches the object to ,x and attaches the initial values e of the attributes to the attributes of x too.

Variable declaration: declares a variable and initializes it:

Variable undeclaration: terminates the block of the permitted use of a variable:

Method call: Let v, r, and vr be lists of expressions. The command le.m(v, r, vr) assigns the values of the actual parameters v and vr to the formal value and value-result parameters of the method m of the object o that le refers to, and then executes the body of m. After it terminates, the value of the result and value-result parameters of m are passed back to the actual parameters r and vs.

where x, y, and z are the value, result, and value-result parameters of the method of class type(le), and N.m stands for the design associated with method m of class N.

All other programming constructs will be defined in exactly the same ways as their counterparts in a procedural language (Hoare & He, 1998). For example, the sequential composition corresponds to relational composition:

Semantics of Class Declarations

A class declaration cdecl given in Section 3.1.1 is well-defined if the following conditions hold.

  1. N has not been declared before, N and M are distinct, and the attribute names of N are distinct.

  2. The initial values of the attributes match their corresponding types.

  3. The method names are distinct.

  4. The parameters of every method are distinct.

Let D (cdecl) denote the conjunction of the above conditions. The class declaration cdecl adds the structural information of class N to the state of the following up program, and this role is characterized by the following design:

where the dynamic behavior of the methods cannot be defined before the dependency relation among classes is specified. At the moment, the logical variable op(N) binds each method mi to code ci rather than its definition which will be calculated in the end of the declaration section.

The Semantics of Declaration Sections and Programs

A class declaration section cdelcs comprises a sequence of class declarations. Its semantics are defined from the semantics of a single class declaration given in the previous subsection, and from the semantics of sequential composition. However, the following well-definedness conditions need to be enforced:

D1: | All class names used in the variable, attribute, and parameter declarations are defined in the section.
D2: | The function super does not induce circularity.
D3: | No attributes of a class can be redefined in its subclasses.
D4: | No method of a class is allowed to redefine its signature in its subclass.

Let cdecls be a class declaration section and P a command, the meaning of a program (cdecls • P) is defined as the composition of the meaning of class declarations cdecls (defined in Section 3.2.4), the design init, and the meaning of command P:

where the design init performs the following tasks:

  1. to check the well-definedness of the declaration section.

  2. to decide the values of attr and visattr from those of pri, pro, and pub.

  3. to define the meaning of every method body c.

The design init is formalized as:

where the family of designs ψ (N.m) is defined by a set of recursive equations. It contains for each class N ∊ cn, each class such that N << M, and every method m ∊ op(M) and equation

where super(N = M and ψ is constructed according to the following rules:

  • Case (1) m is not defined in N, but in a superclass of N, that is, m ∉ op(N) ○ m ∊ ∪ {op(M) | N << M}. The defining equation for this case is simply

  • Case (2) m is a method defined in class N. In this case, the behavior of the method N.m is captured by its body and the environment in which it is executed

    where the design Set(N) finds out all attributes visible to class N, whereas Reset does it for the main program:

    The function FN renames the attributes and methods of class N in the code body(N.m) by adding object reference self:


Specification of UML Models

When formalizing a UML model RM=(CM, UM) of requirements, we describe the conceptual model CM as a declaration section cdeclsUM and the use-case model UM as a program command specification PUM. Therefore, RM is defined as an OO program specification cdeclsCM • PUM. The semantics of cdeclsCM, PUM and their composition · are given in the semantics of OOL. This formalization captures both the syntax and semantics of CM and UM and the consistency between them.

Similarly, for a UML model of design DM= (DC, SD) consisting of a design class diagram DC and a family SD of sequence diagrams, we formalize the design class diagram DC with a declaration section cdeclsDC in OOL. Classes in this declaration section now have methods and a method of a class may call methods of other classes. Therefore, the specification of these methods describes the object interactions in the sequence diagrams. However, methods are still to be activated by commands in the main program Pd. Therefore, a UML model of design (DC, SD) is also specified as the composition of a declaration section and a main program: cdeclsDC · Pd. The consistency between the class diagram DC and the object sequences diagrams SD is captured by the semantics of cdeclsDC and the semantics of method calls in the OOL. The correctness of the design model (DC, SD) w.r.t the requirements model (CM, UM) is defined by the refinement relation

Such an integration of the refinement calculus with RUP makes the use of the design calculus more effective in an iterative and incremental manner so that only a small model will be treated at each stage of an iteration.

Requirement Model

Conceptual Model

A conceptual model CM= <▵, F> where ▵ is a class diagram and F is a state assertion. For giving out a formal definition of a class diagram, assume CN, AN and AttrN are three disjointed sets, denoting class names, associations, and attributes respectively.

Definition 1
Start example

A conceptual class diagram is a tuple: ▵ = <C, Ass, Att, ◃— >, where

  • C is a nonempty finite subset of CN, called the classes or concepts of ▵.

  • Ass is a partial function Ass : such that

    where N denotes the set of natural numbers and [image] is the powerset of N. If Ass(C1)(A) = <M1, M2, C2>, then A is called an association between C1 and C2, M1 and M2 are called the cardinalities of C1 and C2, in A. An association A is in general denoted by A : (C1,M1,M2, C2). We use AssN(C1, C2) to denote the set of all the associations between C1 and C2.

  • Att is a partial function [image] . We use C.a : T to denote Att(C)(a) = T, and call a an attribute of C and T the type of a. We use attV(C) to denote the set {a : T | Att(C)(a) = T} of all the attributes of C.

  • ◃– ⊆ C × C is the direct generalization relation between classes. We use C1 ◃– C2 to denote (C1, C2) ∊ ◃– and say that C1 is a direct superclass of C2, and C2 is a direct subclass of C1.

End example
Definition 1
Start example

allows more than one association between two classes, a same name for associations between two different pairs of classes, and a same attribute name for attributes of different classes.

With OOL, we can specify a class diagram D as a class declaration section cdcleD, in which

  • a class in ◃ is specified as a class in OOL;

  • an association A is declared as a class with the roles of the association as the attributes of A (an associative class (Larman, 2001; Liu, He, Li, & Chen, 2003) may have primitive attributes too);

  • the super-sub class relation in D is described by extends in a class declaration;

  • multiplicities (and UML comments) are described as state invariants to be preserved by methods in the design.

End example

A simple library system: Now consider a simple library system. There are various kinds of publications in the library and each kind of publication has some copies. Only members registered to the library are allowed to borrow copies of publications. Reservation service is also provided to members. In the first iteration we are only concerned with one use case Record Copy which records copies of some publications to the library, as shown in Figure 1. We can specify it as the following class declaration section and denote this declaration section as CM1. The command of creating new object C.New(obj)[e] is expressed as obj := C New(e) in the following illustration, in order that the programmer is easy to understand.

Click To expand
Figure 1: Requirement model of a library system

  • Class Lib {String name, String address, String id};

  • Class Publication {String id, String title, String author, String isbn};

  • Class Copy {String id};

  • Class Owns {Lib lib = l, Publication p}; // Association Class

  • Class Contains {Publication p, Copy c}; // Association Class

We assume the system initial state is:

Use-Case Model

A use-case model consists of a use-case diagram and a textual description of each use case in the use-case diagram. As we said earlier, a use-case diagram provides only static information about the use cases. The dynamic semantic aspects are described in the textual descriptions of the use cases as sequences of interactions between actors and the system. Therefore, for a formal design it is more important to formalize the textual description.

An actor of a use case can be any entity external to the system. It interacts with the system by calling a system operation to request a service of the system. A UML system sequence diagram is used to describe the order of the interaction between the actors in a use case and the system treated as a black box, but it does not describe the change of the system state caused by such an interaction. A system sequence diagram does not and should not provide information about interaction among objects inside the system (D'Souza & Wills, 1998; Larman, 2001). The main task in the system design is in fact to realize the use cases by interactions among objects inside the system. This is done by decomposing the responsibilities of the use cases and assigning them to objects as methods.

System operations: When an actor calls a system operation to carry out a step of a use case, the execution of the called operation changes the system state, by creating new objects, deleting existing objects; forming or breaking links between objects; or modifying attributes of objects. We therefore treat the system under consideration as a component and a system operation a provided method of the component (Cheesman & Daniels, 2001). We model this component as a usecase handler class (Larman, 2001) that encapsulates the classes in the conceptual model:

System specification: To specify a use case H, we specify its handler H-Handler by Spec(H). Suppose that for the design of a system S we have identified the use cases H1, …, Hl, and constructed a conceptual model CM. We combine the specification of the conceptual model CM, the use-case handlers and the actors

to form the structural specification of the system, that is, the conceptual model, the use-case handlers, and its environment that consists of the actors classes.

A use case is specified by an OOL command U that calls the use-case handler's operations in a certain order (shown in the system sequence diagram). Let Service = {H1, …, Hl}, UHi be OOL command for use case Hi, and P the command

h.op is called in UH. The system requirement specification S is then of the canonical form

In the case for a sequential program, only one instance h of a use-case handler H-Handler is needed. Then each use case UH is a piece of a sequential program, and the whole program P is an iterative deterministic choice among the use cases.

A system requirement specification is consistent if the system requirement canonical specification is not equal to chaos.

In particular, the static consistency of a requirement specification is captured by the well-definedness condition of the declaration section of Spec(S).

The library system: Consider the use case RecordCopy that adds a new copy of a publication to the library. We specify this use case by introducing a static use-case handler class RCH:

Then following the declarations of CM1 and the use-case handler, we define the system specification by defining the main method:

where the type Services denotes the set of names of services that library system will provide.

Design Model

This section discusses how a UML model of design DM= (DC, SD) is specified in OOL.

Definition 2
Start example

A design class diagram is a tuple < CN, Ass, Att, ◃–, Meth > where Meth is a mapping from CN to a set of methods.

An association in a design class diagram is now directed and can be represented as an attribute of the source class, and each class N in CN is now associated with a set of methods. As the multiplicity of the target role in an association is more than one in general, such that an attribute is of type of the powerset of the target class. However, when the multiplicity is {1} or {0,1}, we only represent it as an attribute with the class as its type. Therefore, a class diagram can be formally specified as a sequential composition of class declarations of the form:

where D is either a class C or its powerset PC for each association ass from N to C. A sequence diagram consists of objects and messages that describe how the objects communicate. An interaction occurs when one object invokes a method of another.

End example
Definition 3
Start example

A message is a tuple: Msg =< Ns, Action, M t, Ord >, where

  • N s is an object s of class N called source of the message and can be denoted by a function source(Msg).

  • M t represents the target object t of the message and its type M, can be denoted by target(Msg).

  • Action, denoted by action(Msg), is a guarded method call of the form g → act, where g is a Boolean expression of attributes of source(Msg) that are not associations, and act is either a command without method calls (an internal action) or a method name m.

  • Ord is a natural number representing the order of the message in the sequence diagram, denoted by order(Msg).

A guarded command g → act is defined as g ○ act. We require that if action (Msg) is a guarded command without a method call then source(Msg) = target(Msg), that is, interactions between objects can only be carried out via method invocation.

End example
Definition 4
Start example

A sequence diagram is a tuple SD = < Actor a, Start, MSG >

  • Actor is the initiating (actor) object that calls the message Start;

  • Start is the starting such that source(Start) = Actor a.

  • A set of messages MSG contains Start, order(Start) < order(Msg) for any other message in MSG, and if order(Msg1) = order(Msg2) only if source(Msg1) = source(Msg2).

We say that messageMsg2 directly follows message Msg1 in a sequence diagram if order(Msg1 < order(Msg2), but there is no message Msg in the diagram such that order(Msg1) < order(Msg) < order(Msg2).

End example

Usually, the target object in the starting message is a use-case handler and the operation is a method (i.e., a use case) call of the handler. For simplicity, we do not deal with loops in a sequence diagram, by assuming the design ensures the termination of a loop, or reference to another sequence diagram proposed in UML2.0.

Definition 5
Start example

Given the specification of a design class diagram DC and a family of sequence diagram SD. DC and SD are consistent if

  1. For each message Msg =< Ns, Action, Mt, Ord > in the SD, the target object M t is declared as an attribute of the class N of source object N s.

  2. If action(Msg).is g → m and m is a method name then m is a defined method in the class of target(Msg).

  3. The corresponding class declaration section cdeclsd obtained from DC is well defined.

End example

The library system: Assume for each type PC, methods add(), delete(), and find() are declared for adding, deleting, and finding an object of C in a set. The sequence diagram and its corresponding design class diagram in Figure 2 are specified by the following program. Assume classes Pub and Cp have declared these methods. The design model DM1 is constructed as:

Click To expand
Figure 2: Design model of a library system

Let StringList be the type of the list of strings of the attributes of Library. In design phase, main() program is almost the same as that in the conceptual model.

The correctness of the design is captured by the refinement relation defined in He, Liu, and Li (2002).

Iterative and Incremental Development

The output of the iteration cdecls1 • P1 will be reused in the next iteration cdecls2 • P2, and it preserves the correctness of the previous one, that is, we require cdecls1 • P1 ⊆ cdecls 2 • P2. In particular, we require the declaration refinements to hold:

It means that conceptual and design class diagrams (declarations) of the new iteration are refinement of those in the previous iteration respectively. Such an integration of the refinement calculus with RUP makes the use of the design calculus more effective in an iterative and incremental manner, so that only a small model will be treated at each stage of an iteration.

Conceptual model: In the second iteration, we add use case RegisterM, which is used to register a member to the library, as shown in Figure 3. The new extended model is described as

Click To expand
Figure 3: Requirement model in the second interation

Use case: The use-case handler for RegisterM is then specified as: let StringList be the type of the list of strings of the attributes of Member:

Assume the initial state is: MemberM = ⊘

Like use case RecordCopy, use case RegisterM can be verified or tested alone. Then the main program will be enlarged into the following one by adding RegisterM as a service:

Design model: Design model, in turn, is expanded as follows. The interaction diagrams and associated class diagram are shown in Figure 4.

Click To expand
Figure 4: Design model of the second iteration

The main program is almost the same as that in the requirement model of the second iteration. The difference is in the creation of a new object of Library.

Without any change to the conceptual model CM2, we can also specify and design use cases SearchMember, SearchPublication and SearchCopy on search functionality. The software system is then enlarged iteration by iteration.


Conclusion and Related Work

Conclusion

We have given a formal model for object-oriented programming. The model is compositional, where the well-definedness of a class is determined independent of its constituents. Incremental code changes, which often happen in OO programming, require revising only the affected parts of the model and not the model as a whole. We then proposed a way of using the model within RUP. The important nature of the integrated method is that each iteration is only concerned with a small part of the system functionality and a small model at a time. Instead of using a traditional compositional approach, we decompose the system informally according to use cases. We obtain formal models in each iteration and compose them to form a larger system step by step.

The integrated approach enhances RUP for OO software development in the following steps:

  • writing a use case informally,

  • constructing a conceptual model based on the use case,

  • drawing a system sequence diagram and identifying the methods of the use-case handler class,

  • transforming the conceptual model and the use cases into their formal specification in OOL and check their consistency,

  • refining the conceptual model and the use-case specification if they are not consistent,

  • for an executable specification 1, testing it by running it on some input values, and

  • and finally, taking this specification into the design, implementation, verification and/or testing.

This completes an iteration. Then new use cases can be specified, analyzed, and the existing conceptual model is refined to support the newly added use cases. During the design of a new use case, one can reuse the methods of classes that have already been designed.

The formalism is based on the design calculus in Hoare and He's Unifying Theories of Programming (Hoare & He, 1998). The Java-like syntax of the specification language forms a pragmatic solution to the problems of representing name spaces and (the consequences of) inheritance in a notation such as CSP.

In this chapter, we focus on only conceptual aspects of object orientation. Most syntactic and semantic consistency conditions defined in this chapter have straightforward algorithms for checking, and thus relevant automated tools become applicable. For example, the transformation of a class diagram to a declaration section is obvious and the well-definedness conditions for declaration section is clearly consistent with the well-formedness conditions of UML defined in terms of OCL. Other constraints of a class model, such as multiplicities of associations, the properties of an aggregation associations, and characteristics of an abstract class and associative classes, can be specified as state invariants that need to be preserved by use-case commands (Liu, He, Li, & Chen, 2003).

Related Work

Models of OO Programs

There are a large number of publications on models for OO programming (Abadi & Cardelli, 1996; Abadi & Leino, 1997; Bonsangue, Kok, & Sere, 1998; America, 1991; Carrington et al., 1989;Naumann, 1994). It is difficult to give a fair account of their relation to this chapter. However, a large body of work on modeling OO programming is based on type theories or operational semantics. Our approach is among those that are state-based and use a simple predicate logic.

State-based formalisms have been used in conjunction with OO techniques, for example, in languages such as Object-Z (Carrington et al., 1989), and V DM++ (Durr & Dusink, 1993), and methods such as Syntropy (Cook & Daniels, 1994) (which uses the Z notation), and Fusion (Coleman et al., 1994) which is related to VDM. Whilst these formalisms are effective in modeling data structures as sets and relations, they are not ideal for capturing more sophisticated OO mechanisms, such as dynamic binding and polymorphism.

Naumann(1994) introduced an OO programming language with subtype and polymorphism using predicate transformer. Mikhajlova and Sekerinski (1997) designed a rich OO language by using a type system and predicate transformers as well. However, neither reference types nor mutual dependency between classes is allowed in those approaches. Leino (K. Rustan & M. Leino, 1998), has extended an existing calculus with OO features, but the inheritance mechanism is restricted, and classes and visibility are not supported.

In our model, a program is represented as a predicate called a design in UTP (Hoare & He, 1998). So the refinement relation between programs is defined as implication between their designs.

Another advantage of our approach is that writing a specification in relational calculus is straightforward, and relational specifications are easy to understand. Although we have not dealt with concurrency, the power of UTP for describing different features of computing including concurrency and communication, timing, and higher-order computing (Hoare & He, 1998; Woodcock, 2002; Sherif & He, 2002) allows our approach to be further extended to support other features of OO programming.

Formal Support to UML

The research of formal support for UML modeling is currently very active (Evans, et al., 1998; Back, Petre, & Paltor, 1999; Engels, Kuster, Heckel, & Groenewewegen, 2001; Egyed, 2001; Harel & Rumpe, 2000; Reggio, Cerioli, & Astesiano, 2001). There has been a large body of work in UML formalisation and UML tool support that focuses on models for a particular view (e.g., class models, statecharts, and sequence diagrams), and the translation of them into an existing formal formalism (e.g., Z, VDM, B, and CSP) (Engels, Kuster, Heckel, & Groenewewegen, 2001; Egyed, 2001; Ng & Butler, 2003; Miao, Liu, & Li, 2002). In contrast to those works and most work of the precise UML consortium (see http://www.puml.org), we concentrate on use cases and combination of different UML models. This is the most imprecise part of UML and the majority of existing literature on the UML formalisation often avoids them. Our methodology is directed towards improved support for requirement analysis and transition from requirements to design models in RUP. Our aim is to combine different views in a unified formal language, and our formal language provides built-in facilities to capture the object-oriented features of UML, rather than using a traditional formalism which was not designed for object-oriented systems to derive the definitions of classes, objects, inheritance, and so forth. For example, our choice of a Java-like syntax for the specification language is a pragmatic solution to the problems of representing name spaces and (the consequences of) inheritance in a notation such as CSP.

Instead of taking a process view, as was done in Fischer, Olderog, & Wehrheim (2001) and Davies and Crichton (2002), we keep an object-oriented and state-based approach and the specification in a Java-like style. We specify consistency between the models in the preconditions in terms of well-formedness conditions of use cases.

Our work (Liu, Li, & He, 2002) establishes the soundness and (implicitly) the completeness of the action systems for both conceptual and use-case modeling. In this chapter, we extend that work with aformal notation for the specification. Our related work (Li, Liu, & He, 2001; Liu, He, Li, & Chen, 2003) demonstrates that our method supports stepwise refinement and reflects the informal way of using UML for requirement analysis. Use-case refinement can be carried out using the traditional refinement calculus of imperative programs, and can be done by refining the methods provided in the use-case handlers one by one (He, Liu, & Li, 2002). We have advanced the work in formalizing UML (Liu, Liu, He, & Li, 2004;Li, Liu, & He, 2004) by defining the semantics of UML models for OO designs and the link between UML models of requirements and designs.

Another paper (Harel & Rumpe, 2000) also treats a class as a set of objects and an association as a relation between objects, but it does not consider use cases. This model of associations can also be used in the specification of connectors in architecture models (Fiadeiro & Maibaum, 1996; Selic, 1998; Aguirre & Maibaum, 2002). Our work also shares some common ideas with Back, Petre, and Paltor (1999) in the treatment of use cases. However, our treatment of use cases is at the system-interface level without referring to the design details about how internal objects of the system behave, or what methods that a class of the system provides. We believe our model is simpler and addresses the tight relationships among different models more clearly. Also in general, actors in our model (Liu, He, Li, & Chen, 2003) are not only users of the system but also service providers. We will carry out the design of the system by decomposing the methods in the use-case handlers, in turn one by one, and assign the decomposed responsibilities to classes of the conceptual model. This is the main task in the creation of UML interaction diagrams, that is, sequence diagrams or collaboration diagrams.

Future Work

The aim of the work is to scale up the application of the formal method for large software development. The smooth integration of the formal method and RUP shows that we can create and manipulate one small model at a time and put small models together iteratively to form the model of a system. However, the example is too simple to indicate this feature. Future work includes the application of the method to larger case studies, extension of this method to component-based software development (e.g., D' Souza & Wills, 1998, and Clemens Szyperski, 1998) so that components can be developed in parallel, and the application of this framework to formal treatment of patterns (Gamma, Helm, Johnson, & Vlissides, 1995). In addition, tool support, for example, in the direction of Harel, et al. (2002), for formal OO methods is an area of considerable significance for further industrial acceptance of these methods.


Acknowledgments

We would like to thank our colleagues Chris George, Bernhard Aichernig, and Dan Van Hung for the discussions and their useful comments on the work, and the referees of our papers related to this chapter for their comments. We also thank Dines Bjornerat Technical University of Denmark, Kim Larsen and Anders Ravn from Aalborg University of Denmark, and Uday Reddy from Birmingham University of the UK for their helpful comments and discussions at and after the seminars on parts of the works that the second author gave when he visited them. Our UNU-IIST fellows Quan Long, Bhim Upadhyaya, and Jing Yang also read and gave useful comments on earlier versions of the article. The second author would also like to thank the students at the University of Leicester and those participants of the UNU-IIST training schools and courses who took his course on Software Engineering and System Development for their feedback on the understanding of the use-case driven, incremental and iterative OO development and the design patterns.


References

Abadi, M., & Cardelli, L. (1996). A theory of objects. Springer.

Abadi, M., & Leino, R. (1997). A logic of object-oriented programs. In Proceedings TAPSOFT97. Springer-Verlag.

Aguirre, N., & Maibaum, T. (2002). A temporal logic approach to component-based system specification and verification. In Proceedings ICSE '02.

America, P. (1991). Designing an object-oriented programming language withbehavioural subtyping. In REXWorkshop, LNCS 489, pp. 60–90. Springer.

Back, R. J. R., Petre, L., & Paltor, I.P. (1999). Formalizing UML use cases in the refinement calculus (Technical Report 279). Turku, Finland: Turku Centre for Computer Science.

Bonsangue, M. M., Kok, J. N., & Sere, K. (1998). An approach to object-orientation in action systems. In J. Jeuring (Ed.), Mathematics of program construction, LNCS 1422, pp. 68–95. Springer.

Booch, G., Rumbaugh, J., & Jacobson, I. (1999). The Unified Modelling Language User Guide. Boston: Addison-Wesley.

Carrington, D., et al. (1989). Object-Z: An object-oriented extension to Z. North-Holland.

Cheesman, J., & Daniels, J. (2001). UML Components. Component Software series. Boston: Addison-Wesley.

Coleman, D. et al. (1994). Object-oriented development: The FUSION method. New York: Prentice-Hall.

Cook, S., & Daniels, J. (1994). Designing object systems: Object-oriented modeling with syntropy. New York: Prentice-Hall.

D'Souza, D., & Wills, A.C. (1998). Objects, components and framework with UML: The catalysis approach. Boston: Addison-Wesley.

Davies, J., & Crichton, C. (2002). Concurrency and refinement in the unified modelling language. In Preliminary Proceedings of REFINE '02: AnFME Sponsored Refinement Workshop in Collaboration with BCS FACS, Copenhagen, Denmark.

Durr, E., & Dusink, E.M. (1993). The role of VDM++ in the development of a real-time tracking and tracing system. In Proceedings of FME93, LNCS 670. Springer-Verlag.

Egyed, A. (2001). Scalable consistency checking between diagrams: The Viewintegra approach. In Proceedings of the 16th IEEE International Conference on Automated Software Engineering, San Diego, CA.

Engels, G., Kuster, J.M., Heckel, R., & Groenewegen, L. (2001). A methodology for specifying and analyzing consistency of object-oriented behavioral models. In Proceedings of International Conference on Foundation of Software Engineering, FSE10, Austria.

Evans, A. et al. (1998) Developing the UML as a formal modelling notation. In Proceedings UML98, LNCS 1618. Springer-Verlag.

Fiadeiro, J., & Maibaum, T. (1996). Design structures for object-based systems. In S. Goldsack and S. Kent (Eds.), Formal methods and object technology. Springer-Verlag.

Fischer, C., Olderog, E-R., & Wehrheim, H. (2001). A CSP view on UML-RT structure diagrams. In Fundamental Approaches to Software Engineering, 4th International Conference, FASE 2001, LNCS 2029, pp. 91–108. Springer-Verlag.

Gamma, E., Helm, R., Johnson, R., & Vlissides, J. (1995). Design Patterns. Reading, MA,: Addison-Wesley.

Harel, D. et al. (2002). Smart play-out of behavioral requirements. In Proceedings FMCAD02, pp. 378–398.

Harel, D., & Rumpe, B. (2000). Modeling languages: Syntax, semantics and all that stuff - part I: The basic stuff (Technical Report MCSOO-16). Israel: The Weizmann Institute of Science.

He, J., Liu, Z., & Li, X. (2002). Towards a refinement calculus for object-oriented systems. In Proceedings ICCI02, Alberta, Canada. IEEE Computer Society.

He, J., Liu, Z., & Li, X. (2003, May). Modelling object-oriented programming with reference type and dynamic binding (Technical Report UNU/IIST Report No 280), Macau, Taipa: UNU/IIST.

Hoare, C. A.R., & He, J. (1998). Unifying theories of programming. New York: Prentice-Hall.

Jacobson, I., Booch, G., & Rumbaugh, J. (1999). The unified software development process. Boston: Addison-Wesley.

Kruchten, P. (2003). The rational unified process - An introduction (3rd ed.). Boston: Addison-Wesley.

Larman, C. (2001). Applying UML and patterns. New York: Prentice-HallRustan, K, & Leino, M. (1998). Recursive object types in a logic of object-oriented programming. In LNCS1381. Springer-Verlag.

Li, X., Liu, Z., & He, J. (2001). Formal and use-case driven requirement analysis in UML. In COMPSAC01, pp. 215–224. Illinois: IEEE Computer Society.

Li, X., Liu, Z., & He, J. (2004). A formal semantics of UML sequence diagrams. In Proceedings of Australian Software Engineering Conference (ASWEC'2004), Melbourne, Australia: IEEE Computer Society.

Liu, J., Liu, Z., He, J., & Li, X. (2004). Linking UML models of design and requirement. In Proceedings of Australian Software Engineering Conference (ASWEC'2004), Melbourne, Australia: IEEE Computer Society. Workshop on Compositional Verification of UML, San Francisco, CA.and to appear in the final proceedings.

Liu, Z., He, J., Li, X., & Chen, Y. (2003). A relational model for formal requirements analysis in UML. In J.S. Dong and J. Woodcock (Eds.), Formal methods and software engineering, ICFEM03, LNCS2885, pp. 641–664. Springer.

Liu, Z., He, J., Li, X., & Liu, J. (2003). Unifying views of UML (Research Report 288), Macau, Taipa: UNU/IIST Presented at UML03.

Liu, Z., Li, X., & He, J. (2002). Using transition systems to unify uml models. In Proceedings of 4th International Conference on Formal Engineering Methods, LNCS2495. Springer-Verlag.

Meyer, B. (1989). From structured programming to object-oriented design: The road to EIFFEL. Structured Programming, 10(1), 19–39.

Miao, H., Liu, L., & Li, L. (2002). Formalizing UML models with object-Z. In Proceedings of 4th International Conference on Formal Engineering Methods, LNCS 2495. Springer-Verlag.

Mikhajlova, A., & Sekerinski, E. (1997). Class refinement and interface refinement in objectorient programs. In Proceedings ofFME97, LNCS. Springer.

Naumann (1994). Predicate transformer semantics of an Oberon-like language. In Proceedings ofPROCOMET'94. North-Holland.

Ng, M., & Butler, M. (2003). Towards formalizing UML state diagrams in csp. In Proceedings of Software Engineering and Formal Methods 2003. IEEE Computer Society.

Reggio, G., Cerioli, M., & Astesiano, E. (2001). Towards a rigorous semantics of UML supporting its multiview approach. In Proceedings FASE 2001, LNCS 2029. Springer-Verlag.

Selic, B. (1998). Using UML for modelling complex real-time systems. In Languages, compilers, and Tools for Embedded Systems, LNCS 1474, pp. 250–262. Springer-Verlag.

Sherif, A., & He, J. (2002). Towards a time model for circus. In Proceedings of 4th International Conference on Formal Engineering Methods, LNCS 2495. Springer-Verlag.

Szyperski, C. (1998). Component software beyond object-oriented programming. Boston: Addison-Wesley.

Woodcock, J.C.P. (2002). Unifying theories of parallel programming. IOS Press.


Chapter V: On the Co-Evolution of SSADM and the UML

Richard J. Botting,
California State University,
San Bernardino,USA

This chapter examines how a system developed using the Structured Systems Analysis and Design Methodology (SSADM) evolves to fit the UML and XML. As a vehicle, the chapter will consider the addition of a new user story to an existing SSADM system. SSADM developed in the early 1980's. It is still popular. It is similar to other Structured Analysis and Design methods. Evolving SSADM to use the UML and XML is important. This chapter argues that XML is an opportunity, not a problem. It also shows that the earlier UMLs did not support SSADM but the new UML 2.0 does.

Introduction

Perspective

This chapter considers the addition of a new user story to an existing system developed using the Structured Systems Analysis and Design Methodology (SSADM). The UK Civil Service developed SSADM in the early 1980's. It is still popular (Lejk & Decks, 2002). It is similar to other Structured Analysis and Design methods. Therefore, the question of evolving SSADM designs to use the UML (Unified Modeling Language) and XML (Extensible Markup Language) is important.

XML is an encoding of data that is independent of machine, platform, and application. XML is general enough to fit easily into SSADM. SSADM provides plugin rule sets for designing many types of databases. Existing rule sets can act as a basis for the rules for writing Document Type Definitions (DTDs). Tools can also encode SSADM documentation in the XML and it can so become metadata for the system. In summary, XML is an opportunity rather than a problem for SSADM. However, this chapter shows that the early UML did not support SSADM well. The new UML 2.0 does.

Methodologists developed SSADM and UML on opposite sides of a watershed in software methods. A joke defines it: Question: "How many object-oriented programmers does it take to screw in a light bulb?" Answer: "None! A well-designed light bulb object screws itself in." We could call this the Law of the Light Bulb: objects should know how to do things. However, anybody who has tried, while jet lagged, to fix a light bulb on the other side of the Atlantic will appreciate that real light bulbs do not know how to install themselves. SSADM studies real light bulbs. It would discover that light bulbs with bayonet fixtures do not screw in.

This fact would be documented. An object-oriented programmer can easily code a specialized class of light bulb that reacts to the install() operation by hooking itself in. Generalization in the UML expresses the polymorphism. SSADM has no problem with this solution to the problem. Robinson and Berrisford (1994) have written a handbook for developing object-oriented systems using the SSADM.

Objectives

This chapter explores ways to map SSADM to the UML. Figure 1 shows how some SSADM documents have counterparts in the UML. The chapter reviews SSADM and UML semantics and describes some traps. It suggests ways for both to evolve. This chapter will show how one SSADM diagram helps avoid errors mentioned in a UML handbook (Fowler & Scott, 2002). It will discuss how this diagram could be expressed in the UML 1.0. It shows that UML 2.0 (Object Management Group, 2004) offers a better alternative.

Click To expand
Figure 1: Proposed mappings from SSADM to UML


Background

SSADM

SSADM is capable of integrating database analysis and design (see Alhir, 1998, p. 45), systems analysis (similar to Alhir, p. 44), and dynamic analysis and design (Botting, 1986). The theory of SSADM is that it is valuable to abstract a logical model from the current situation, then propose improvements in abstract, then map the logical model into a physical system. A logical model is platform independent and a physical model is platform specific. Unlike most structured methods, SSADM does not say anything about how to code programs (Budgen, 2003, p.290). The SSADM team had the UK Civil Service Structured Design Method for converting specifications into clear, reliable, economical, amendable, tested, and elegant code. SSADM is about understanding and specifying components (data and executables) from the outside.

Running Example

For example, suppose we have a system developed using SSADM for a company whose customers place orders to buy products stocked in depots. The depot managers want to add a new function to the system: Every morning, they want to find out quickly what customer orders are currently unfulfilled at their depot. This is a query or retrieval function, so the SSADM analyst lists it in the function catalog and creates a logical function description. These function descriptions are scenarios. A function that changes any data would be added to the existing data flow diagrams ( Figure 8). The analyst then checks Entity Life Histories ( Figure 5) for ambiguities and difficulties. For example, while the depot works on an order, is it unfulfilled or fulfilled? The analyst checks the SSADM data model (Logical Data Structure, Figure 2) to see if the information is accessible and writes an access path as in Table 1.

Click To expand
Figure 2: A traditional example of an SSADM Logical Data Structure
Click To expand
Figure 5: A traditional entity life history
Click To expand
Figure 8: A traditional SSADM data flow diagram
Table 1: An example of a data access path
Function | Get Unfulfilled Orders for Depot |  |  |  | Frequency | Daily
Entity Name | Access | Read Path | Access Via | No. | Data Items | Comments
Order Status | Read | Direct |  | 1 |  | status=unfilled
Sales Order | Read | Sequential | Order Status | 100000 | customer | 20% unfilled, 5 per customer
Customer | Read | Master | Sales Order | 100000 |  |
Depot | Read | Master | Customer | 100000 | name | select orders for this depot
Sales Item | Read | Sequential | Sales Order | 1000 | prod id |
Product | Read | Direct |  | 1000 | name | of sales items

The analyst then works out a detailed plan for getting data from the physical database (a physical data access path) and estimates how long it will take to execute. For each database and file management system SSADM provides rules for estimating storage volume and execution speed. If the response will not be quick enough, the physical database may be refactored or the depot manager's expectations adjusted. SSADM now stops and programming starts.

Programming is not what SSADM is about. SSADM's goal is to reengineer a system so that it, as a whole, works better. The documentation is a high-level model of a complex system. Data Flow Diagrams (DFDs) are used in SSADM and nearly all analysis methods. These describe a system as a digraph with flows for arcs and with nodes labeled as functions, stores, and external entities. Some methodologies talk about sources and sinks for external entities. Some call functions processes. The syntax/iconography varies with methods in minor ways. Analysts can decompose processes into lower-level data flow diagrams or describe them on forms: logical function descriptions (scenarios) and logical data access paths. They link the data stores in the data flow diagrams to the entities in a specialized Entity-Relationship diagram called a Logical Data Structure (LDS). Work on data flow diagrams and logical data structures typically goes on in parallel.

An SSADM Logical Data Structure is a directed acyclic graph very like a class diagram in the UML. Figure 2 shows a sample based on handouts and manuals from the 1980's. Paths in this graph are Data Access Paths. Analysts document the entity's attributes on forms as Data Groups. Analysts must reify all many-to-many and n-ary relationships into entities (Rumbaugh et al., 1999, p. 159). This uncovers important entities. As a result, the arcs connecting entities always represent many-to-one mappings. Each mapping associates one master to many details. The master is always drawn above the detail. The arcs have a crow 's foot at the lower end. In CODASYL terminology, each defines a set.

Most sets have one master per detail. They are mandatory. Other masters are optional and have multiplicity of 0.1 masters per detail. Sets with optional masters can be reified into a new detail entity with multiplicity 0.1. The structures map easily to hierarchical, relational, and object-oriented data.

The cataloged functions validate the data structures. Each validation is recorded in a Data Access Path showing how the data for the function can be accessed using the data structure. For example, Table 1 was not a valid access path for the data structure in Figure 2. An Entity Name and an Access Via are missing from the data. Sales Status would have to be added to the model as an operational master for Sales Order if we plan to use Table 1 to implement the example query.

Forms also document data. Analysts normalize existing and proposed data to create Third Normal Form (TNF) data groups. The analysts also record the typical number of details for each master and the typical number of instances of each entity. The Pigeon Hole Principle checks the result. For example, if we had 10 depots and each had 100 customers then we have 1,000 customers. If each of these has five orders then we should have roughly 5,000 orders. If one fifth of these are unfulfilled, then we should have 1,000 unfulfilled orders. These numbers also help estimate the storage required and optimize performance.

Changes to the data are analyzed using Entity Life Histories (ELHs). They are extended Jackson Structure Diagrams (Budgen, 2003, pp. 147-152). They define possible and significant patterns of events impacting an entity. They use the three regular structures of sequence, selection, and iteration, plus two forms of parallel structure. Entity life histories are used to spot and resolve problems and to specify processing. Each life history adds a data item (a status or state) to the entity's logical data group.

The Composite Logical Design (CLD) is a data structure that unifies the normalized data groups, operational masters, and conceptual entities/relations in a single data model. Creating it is an intuitive but well-documented procedure in the SSADM. For example, relational tables become entities and foreign keys suggest many-to-one links in the composite structure.

The composite logical structure is the basis for a physical data design tuned to meet the client's cost and performance requirements. SSADM has specialized First Cut rules for mapping logical data structures into many different databases. The many-to-one constraint on associations eases the physical design of nonrelational data. SSADM also has procedures for estimating the volumes of data and the speed of access for many types of databases. This optimization often leads to redesigned access paths and lost normalization.

Discussion

SSADM is an engineer's approach to complex computer-based systems. Concepts are quantified. Performance is calculated. It provides two dozen techniques for understanding, describing, and evaluating systems and components. It specifies a set of feasible components. From the beginning, several processes were proposed. Some were iterative. A key selling point was that SSADM designs would easily evolve to new requirements and new technologies like XML. Can it adapt to the UML? I will take each SSADM diagram in turn.


Data Structures and Data Descriptions

Issues

Figure 3 shows the UML translation of Figure 2. The primary issue with SSADM data structure diagrams is whether database designs are also object-oriented program designs and if so whether physical, logical, or both structures should appear. Secondary issues include (1) should the UML notation replace the crow's foot notation or should the crow's foot be a stereotype of association, (2) can the UML also document data access paths, (3) how to record SSADM multiplicities and volumes in the UML, (4) how to hide attributes to simplify diagrams, and (5) how to model operational masters in the UML.

Click To expand
Figure 3: SSADM data structure ( Figure 2) in the UML

Solutions and Recommendations

SSADM data structure diagrams translate straightforwardly into UML Class diagrams. Items in SSADM data groups are attributes in the UML. SSADM documents database keys and the UML database profile (Larman, 2002, p. 541) provides the stereotypes «PK» and «FK» for primary and foreign keys, respectively.

Logical data should be connected with associations only. Designers could use composition and aggregation in physical design. They can use composition when details are placed inside a master and aggregation for the storage of logical or physical keys.

Showing all entities and attributes in one diagram may not be wise. UML tools resolve this issue by recording the details and letting the viewer select what they wish to see

An SSADM composite logical design often includes operational masters. These show necessary entry points into the database. They hold unchangeable data. Therefore, they show operational masters as classes with frozen attributes in the UML.

SSADM estimates the sizes, frequencies, and volumes of data. These numbers should be tagged values in the UML. For example, in Figure 3, Order could be tagged {size=30 bytes, frequency=5000, volume=150Kb}. Numeric multiplicities on links in SSADM give a typical number but in the UML they mean a fixed number. Using a UML range (minimum..maximum) is better. Hares (1990) suggests recording minimum, maximum, and typical values in SSADM. A tagged value {typical=5} could be added in the UML.

Logical Data vs. Object Classes

Much has been published on mapping database and domain models to object-oriented models. This section is an abstract of the cited works.

It is clearly a mistake to base classes on a tuned physical database. For example, the example database may be tuned so that it's Sales Items have been placed inside their Sales Order record and extra keys introduced to link Stock to Sales Item and vice versa. Instead, programmers should start from the composite logical data structure. SSADM data structures are domain models. It needs reworking to create good program designs (Larman, 2002, pp. 8, 9, 10, 287, and 345).

To return to the running example, Table 1 was not a valid access path for Figures 2 and 3. Table 2 is a valid one.

Table 2: An example of a valid data access path
Function | Get Unfulfilled Orders for Depot |  |  |  | Frequency | Daily
Entity Name | Access | Read Path | Access Via | No. | Data Items | Comments.
Depot | Read | Direct |  | 1 |  | for the manager's depot
Customer | Read | Sequential | Depot | 100 |  | read all
Sales Order | Read | Sequential | Customer | 1000 | status, name | read all, select status=unfilled
Sales Item | Read | Sequential | Sales Order | 1000 | prod Id | 20%. unfilled, 5 orders/customer
Product | Read | Direct |  | 1000 | name | of sales items

Suppose the query in Table 2 is deployed in a component that does nothing else. A simple function like this can be coded as a single SQL query and no classes or objects would be needed. If SQL is not used, the component still only uses five of the nine entity types in Figure 3. In practice, it could be 5 out of 100 classes. Software engineering principles demand that the component's class diagram only shows these five entities. So, in most components, programmers will start from parts of the composite domain model.

Each component will have different operations. Data access paths, function descriptions, and life histories determine the operations. Operations should be assigned to classes using collaboration and sequence diagrams. Figure 4 is an example. Larman's GRASP and other patterns give guidance here. Further, object-oriented classes are determined by behavior, not attributes. So, different abstractions, interfaces, and specializations will be needed in different components. Some generalizations will appear in the logical model as a detail that has multiplicity of 0..1 and with a master that is both mandatory and fixed. In contrast, optional details with dynamic masters often indicate different states of a single object. Robinson and Berrisford (1994) show how to add other generalizations.

Click To expand
Figure 4: A sequence diagram for the sample query

Next, objects should hide how they access data. Since Parnas's work in the 1970s, logical and physical structures have been placed in separate modules. Further, the SSADM Standard Template (Robinson & Berrisford, 1994), Ambler's Class Type Architecture (1996a, 1996b), Larman's (2002) Layers pattern (pp. 450-474), Jacobsen's method, the Model-View-Controller pattern, and so on, all point to a layered architecture separating user interface (boundary/view), business logic(control), and persistence (entity/model) layers. To these, Ambler adds system classes (Larman's technical services) that know how to use the database du jour. Commonly the physical database is hidden behind a Facade object (Larman, pp. 369, 479). Clearly, SSADM work products need much rework to become object-oriented models.

Access Paths in the UML?

Access paths (like Table 2) could be put in a UML scenario, but scenarios should be about the user's interaction with the system not its internal operations (Larman, 2002). UML interaction diagrams are attractive alternatives. A sequence diagram ( Figure 4) makes the sequence more visible than a collaboration diagram (Rumbaugh et al., 1999). So, it looks like the natural UML diagram to replace SSADM access paths. However, UML sequence diagrams omit the frequencies in Table 2. Worse, they do not show the sequence of database accesses. Each step shows one object calling another object: A depot calls a customer and the customer knows how to return a collection of unfulfilled sales orders.

These objects hide the sources of their data. To show the access path one has to add a database facade object that knows how to handle the physical database. So, interaction diagrams seem a clumsy replacement for SSADM data access path forms.

Constraints and Techniques to Keep

The UML notation for classes is a simpler notation than SSADM data structures. The UML also has extra notations and fewer constraints. For example, the UML allows many-to-many associations and association classes. The SSADM rules force analysts and designers to reify them. The result is easier to map to different platforms. Further, the SSADM validation rules and calculations correct many errors. These constraints should be included in a UML profile for the SSADM.


Entity Life Histories

Issues and Problems

A life history shows the possible and meaningful patterns of events that impact an entity. Figure 5 is an example. They are important for predicting and solving subtle problems of timing and recognition difficulties (Budgen, 2003, p. 303). Without life histories, these become bugs discovered after the system has been tested. Robinson and Berrisford (1994, pp. 239-242) describe other advantages life histories have over state-based models. Life histories are an initial work product leading to states. All sequential entity life histories have state machines. Their states become new data items for their entity. In 1994, Robinson and Berrisford advocated optimizing the original one-elementary-box-per-state mapping from life histories to states. Figure 6 shows the state machine derived from Figure 5 using their technique. Re-expressing life histories as state charts can lose information. Higher-level boxes in life histories represent sets of sequences of events. State charts have states for boxes. The events are transitions between states. So, the higher-level structures in a life history do not match sets of states in its state chart and so can not be shown as superstates.

Click To expand
Figure 6: A state chart derived from Figure 5

UML2.0 Sequence Diagrams ( Figure 7) have the power to express everything that SSADM life histories do. However, life histories are a higher-level abstraction. Details must be added when they become sequence diagrams. Events become messages. Messages need a sender and a receiver (Rumbaugh et al., 1999). Figure 7 includes objects invented to model Figure 5. So, sequence charts may need changing more than life histories when requirements change. They may not help with recognition difficulties.

Click To expand
Figure 7: UML2.0 sequence diagram modeling Figure 5

Solutions and Recommendations

The main controversy about entity life histories is the notation. Learning it is not easy (Budgen, 2003, p. 149, p. 173). State charts do not replace them. But, some of the benefits of life history analysis can be obtained using a UML 2.0 message sequence diagrams.


Data Flow Diagrams

Issues, Controversies, and Problems

Introduction

A Data Flow Diagram (DFD) pictures a part of the world as a collection of loosely coupled communicating sequential processes. They show the movement of objects in a system. This can include both goods and documents (sticky notes, email, forms, files, Internet packets, memos, and so on). Data flows are abstracted from these. They are natural models of real organizations where things move from place to place. In reality, objects are not active but passive. Indeed, an active object in email is often a virus!

Figure 8 shows an SSADM data flow diagram. Arrows do not transfer control. Arrows to and from data stores are updates and queries. Other arrows show a stream of objects passing from one process to another. They may be delayed. For example, when a delivery arrives, the paper work may wait in an in-tray until payments are made. Processes execute in parallel. As Hares puts it "SSADM Data Flow Diagrams do not support the concept of time — process A occurring before process B. […] Where processes are connected by data flows they are intrinsically causally related […] Such processes are connected in time in that they occur together." (Hares, 1990, p. 35).

SSADM uses data flow diagrams to describe, analyze, and validate communication. Visible end-to-end paths are vital. SSADM does not use them for flows inside executable components. Other methods attempt this. SSADM uses forms and life histories to define executable components. The best use of data flow diagrams is to give a synoptic end-to-end model of the flows through real (non-object-oriented) systems. Fowler (Fowler & Scott, 2000, p. 46) remarks that by focusing on just the interactions between the system and the user, the analyst can fail to spot necessary or useful changes to a business process. This is where data flow diagrams help. They should be part of the UML.

In the SSADM, data flow diagrams are not flow charts. Flow charts were thought to constrain the programmer too much. The data flows represent First-In-First-Out (FIFO) queues connecting parallel processes. This is a natural model of real systems. In UML1 a FIFO can be defined by a parameterized collaboration. A FIFO class has two interfaces: In and Out. Objects can be put In and taken Out. The sequence of objects taken out is always a subsequence of the sequence of objects put in. Expressed in the Object Constraint Language, if o is the sequence of items output and i the items input, there must be a sequence q of objects such that

Object-oriented methodologists abandoned data flows in the 1990s. Apparently, drawing a data flow diagram is now an evil activity (Fowler & Scott, 2000, p. 137). The Object Management Group (2003, p. 3) wrote: "Simply put, data-flow [… ] do not fit cleanly into a consistent object-oriented paradigm. Activity diagrams and collaboration diagrams accomplish much of what people want from Data Flow Diagrams, and then some." However, they have now introduced Information Flows in a supplement to the new UML 2.0 specification (Object Management Group, 2004). This chapter will now analyze the options.

Activity Diagrams

Drawing a Data Flow Diagram as an activity diagram with similar topology seems OK. Processes become states and data become objects. But, the result will be a flow chart not a DFD: The arrows show sequences of actions (Fowler & Scott, 2000, p. 138). Even an object flow ( Figure 9) defines an implicit control flow (Rumbaugh et al.,1999, p. 139; Alhir, 1998).

Click To expand
Figure 9: An object flow from an activity diagram

p.208). We must use UML 2.0 streaming parameters (Bock, 2003). A translation of part of the sample is shown in Figure 10. The data stores become objects with stereotype «entity» because they are persistent and store information about the real world. Notice that actors cannot be used in activity diagrams, so external entities become swim lanes containing new states describing external activities. In a data flow diagram, all processes execute in parallel and never stop. In activity diagrams this must be made explicit. The final effect is that translating an SSADM data flow diagram into an activity diagram doubles the size of the diagram. Alternative translations are better.

Click To expand
Figure 10: UML 2.0 activity diagram modeling half of Figure 8

Use Case Diagrams

Data flows are a business-modeling tool. King (2003) recommends use cases and collaboration diagrams for business modeling. A use case diagram shows the interactions either between the system and users or between the clients and the organization. External entities become actors. Nesting use cases to model the decomposition of processes into data flow diagrams is possible (Rumbaugh et al., 1999, p. 491; Alhir, 1998, p. 162 and pp. 72-75) but is not well defined in the standards (Object Management Group, 2003, 2004; Kobryn, 1999) unlike the rules for decomposing and leveling data flow diagrams.

Figure 11 shows a use case model of the example in Figure 8. Use case rules force significant changes. Processes (functions) have become use cases. Each use case must have a primary actor that gets something of value out of it. This added two actors in Figure 11. The names of processes must be changed to reflect the primary actor's viewpoint. Use case diagrams may not show data or communication between use cases. They include queries that are omitted in data flow diagrams. So, adding the example function complicates the use case diagram. As a tool for making usable systems, use cases are excellent. One gains actors and use cases but loses connectivity. Connectivity is needed to diagnose and solve systemic problems. Use case diagrams in the UML can be visual function catalogs and improve user value as a side effect. Perhaps SSADM function descriptions should follow a use case template (e.g., Larman, 2002).

Click To expand
Figure 11: Use Case translation of Figure 8

Interaction Diagrams

Collaboration diagrams are close to low-level data flow diagrams. These could be used for Robinson and Berrisford's (1994) User Function Definitions. Normally they show one operation or one use case. An association shows the possibility of communication between objects. Rumbaugh et al. (1999, p. 200) state that a set of use cases can be expressed in a single collaboration diagram if no messages are shown, since messages require sequencing and sequences are only meaningful in a single use case. Actors can be shown and match external entities (sources and sinks) in the data flow diagram. Processes can be mapped to «control» classifiers and stores to «entity» classifiers. Classifiers with a «boundary» stereotype show flows in and out of the system. These stereotypes are well known but nonstandard. Figure 12 shows the example modeled this way. It cannot show the direction of flow. An arrow on an association shows visibility! Object movements are shown by value flows. But, value flows must be attached to messages (Kobryn, 1999). When messages are placed on collaborations, a sequence is chosen (Kobryn), so the diagram can only show a single use case or operation (Rumbaugh et al.).

Click To expand
Figure 12: Collaboration diagram for half of Figure 8

Solutions and Recommendations

Some differences between SSADM data flow diagrams and the UML are easily resolved by using tagged values, stereotypes, or tools. For example, all parts of SSADM data flow diagrams are given a short unique identifier to link diagrams together. Tools that link separate diagrams make this redundant. Similarly, stereotypes can show that an item appears in multiple places, or is defined elsewhere. UML2.0 has introduced Information Flows and Information Items (Object Management Group, 2004). These are close to the data flows in a data flow diagram. UML 2.0 also has «entity» and «process» stereotypes. Figure 13 shows how they could be used.

Click To expand
Figure 13: The UML2.0 component diagram of Figure 8

Further, deployment diagrams with artifacts are vital tools for designing Web-based and client-server systems. Therefore, they should be added to the SSADM as a new kind of diagram for expressing and evaluating physical designs.


Future

Emerging Trends

C. Farquhar (personal communication, November 2003) attended the debate at the <<UML>> 2003 conference (San Francisco, CA, USA, October 20-24,2003). It asked if UML had a future. The key question was how UML models would be used: as a designer's sketch, an engineer's blueprint, or as a programming language? UML 2.0 changes UML into a programming language. But many methodologists stress its use as a sketching tool for analyzing systems. Much of the tension between SSADM and the UML comes from trying to resolve these two opposed forces. This chapter showed that the UML 2.0 is a better analysis tool than UML 1.5

Viability of Proposals

My proposals follow the standards. They are practical and cost little to implement. Replacing SSADM diagrams by UML 2.0 equivalents is attractive. This chapter eliminates the most risky replacements. An SSADM profile would reduce the risk of error by including the constraints missing in the UML. Replacing SSADM life histories by sequence diagrams is the least viable change. Sequence diagrams are easier to learn than SSADM life histories, but may lead to extra work when requirements change.

Further Research

It would be worth testing, in an experiment, whether life histories or sequence charts are better notations. But laboratory-style experiments will not test if suggestions work well in practice. They must be tried on real projects and the results reviewed: Are sequence diagrams too detailed when compared to life histories? Do UML class diagram rules encourage analysts to break SSADM constraints? Are there bad consequences of ignoring SSADM rules? Work also needs to be done to relate SSADM to the disciplines of the Rational Unified Process and to find out how the UML is being used in practice. This would open the way to defining a profile that would integrate the SSADM and the UML. This would include stereotypes, tagged values, and constraints.


Conclusion

Summary

SSADM discovers and solves problems in the user's world. It adapts easily to new technologies like XML. SSADM produces specifications for components that the UML can help realize. More, UML class diagrams can replace SSADM data structures. UML diamonds could, perhaps, standardize SSADM physical design notation. However, SSADM data structures must be reworked, using published methods, to give good object-oriented programs. Use-case diagrams improve on function catalogs. Scenarios correspond to logical function descriptions. Deployment and component diagrams should be adopted as new SSADM diagrams. Entity life histories could, perhaps, be drawn as UML 2.0 sequence diagrams. The new UML 2.0 concept of an Information Flow in a component diagram encompasses the correct semantics for data flows. It should make systems analysis and business process modeling with the UML easier.


References

Alhir, S. S. (1998). UML in a nutshell: A desktop quick reference. Sebastopol, CA: O'Reilly.

Ambler, S. (1996a, March). An ounce of prevention: Class type architectures. Software Development Magazine, 4(3), 45–61.

Ambler, S. (1996b, October). Object-relational mapping. Software Development Magazine, 4(10), 47–50.

Bock, C. (2003, September/October). UML 2 activity and action models Part 2: Actions. Journal of Object Technology, 2(5), 41–56. Retrieved 4/9/2003 from http://www.jot.fm/issues_2003_09/column4

Botting, R. J. (1986, April). Into the fourth dimension: An introduction to dynamic analysis and design, ACM SIGSOFT Software Engineering Notes, 11(2), 36–48.

Budgen, D. (2003). Software Design (2nd ed.). Harlow, Essex, UK: Pearson Education Ltd.

Fowler, M., & Scott, K. (2000). UML distilled: A brief guide to the standard object modeling language (2nd ed.). Reading, MA: Addison-Wesley.

Hares, J. S. (1990). SSADM for the advanced practitioner. Chichester, West Sussex, UK: Wiley.

King, G. (2003). Business modeling with the UML and rational suite AnalystStudio. Retrieved August 11, 2003, from http://www.rational.com/uml/resources/docu-mentation/2707OBusinessModeling.pdf

Kobryn, C. (1999). UML abstract syntax 1.3. Retrieved January 8,1999, from the Object Management Group's Web site, http://www.omg.org/docs/

Larman, C. (2002). Applying UML and patterns: An introduction to object-oriented analysis and design and the Unified Process. Upper Saddle River, NJ: Prentice Hall.

Lejk, M., & Deeks, D. (2002). An introduction to system analysis techniques (2nd ed.). Harlow, UK: Addison-Wesley.

Object Management Group (2003). UML Summary (Chapter. 1).UML 1.5 Specification. Retrieved August 11,2003, from http://www.omg.org/cgi-bin/doc?formal/03-03-08

Object Management Group (2004). UML 2.0 Superstructure final adopted specification (Part III, Section 17.2 ). Information Flows. Retrieved January 14,2004, from http://www.omg.org/cgi-bin/doc?ptc/2003-08-02

Robinson, K., & Berrisford, G. (1994). Object-oriented SSADM. New York: Prentice Hall.

Rumbaugh, J., Jacobson, I., & Booch, G. (1999). The Unified Modeling Language reference manual, Reading, MA: Addison-Wesley.


Chapter VI: Software Evolution with XVCL

Weishan Zhang,,
Tongji University, P.R.
China
Stan Jarzabek,,
National University of Singapore,
Singapore
Hongyu Zhang,,
RMIT University,
Australia
Neil Loughran,,
Lancaster University,
UK
Awais Rashid,,
Lancaster University,
UK

This chapter introduces software evolution with XVCL (XML-based Variant Configuration Language), which is an XML-based metaprogramming technique. As the software evolves, a large number of variants may arise, especially when such kinds of evolutions are related to multiple platforms as shown in our case study. Handling variants and tracing the impact of variants across the development lifecycle is a challenge. This chapter shows how we apply XVCL to handle variants that arise during software evolution. It also shows how we can maintain different versions of software in a reuse-based way.

Introduction

Software systems evolve and there can be many kinds of changes (Mens et al., 2003), such as porting to a new platform or enhancing user requirements. During evolution, multiple versions of a system arise differing in variant requirements. For example, in the evolution to a new platform, we have to handle large numbers of platform-related variants that have a local and sometimes global impact on the system. At times, we have to refine software architecture to mitigate the architecture erosion problem (Hoek et al., 1999). To facilitate evolution, it is essential to ensure traceability from variants in high-level software models, to architecture and to code components, test cases, and so forth. Another important issue is to maximize reusability across system versions emerging during evolution in order to save costs.

Metaprogramming techniques can help in software evolution by automating some of the tedious and error-prone tasks. In this chapter, we investigate the evolution with an XML- based metaprogramming technique of XVCL (XML-based Variant Configuration Language) (Jarzabek & Zhang, 2001; Soe, Zhang, & Jarzabek, 2002; Jarzabek et al., 2003). We apply XVCL on top of programs designed using traditional design techniques for enhanced maintainability and reusability. In the remaining part of the chapter, we will first give a brief introduction to XVCL. Then, an experiment of reengineering an existing PC-based system into a product line is described. After the case study, we discuss literature review of software evolution techniques and variability mechanisms. Finally we give some concluding remarks and discuss the future work.


Overview of XVCL

A Brief Introduction to XVCL™

XVCL is a metaprogramming technique and tool that provides effective reuse mechanisms. Being a modern and versatile version of Bassett's frames, a technology that has achieved substantial gains in industry (Bassett, 1997), the underlying principles of XVCL have been thoroughly tested in practice. The basic building block in XVCL is called a metacomponent, which is an XML file instrumented with XVCL commands for ease of change and evolution. XVCL uses composition with adaptation rules to generate custom artifacts (code, documents, models, etc.) from a compact base of generic, reusable metacomponents. Metacomponents are component building blocks, designed for ease of adaptation and reuse. XVCL can successfully manage a wide range of variants for all software assets, which can be represented as textual content. For the more detailed description of XVCL, please refer to its homepage at http://fxvcl.sourceforge.net.

While designing a frame architecture is not trivial, subsequent productivity gains and maintenance savings often repay the effort many times over. An independent analysis showed that frames can reduce large software project costs by over 84% and their times-to-market by 70%, when compared to industry norms (Bassett, 1997). By reusing skillfully structured frame architectures, you need to focus on only the 5%-15% of a solution that is unique; the other 85%-95% is reused. These gains are due to the flexibility of the resulting architectures and their evolvability over time (Jarzabek et al., 2003)

How Does XVCL™ Work?

XVCL works on the principle of adapting generic, reusable metacomponents into specific components – for clarity, assume they are components of custom programs. Any location or structure in a metacomponent can be a designated variation point (extension point), available for adaptation by ancestor metacomponents. Program generation is transparent to the programmer, who can fine-tune and regenerate artifacts without losing prior customizations.

XVCL commands, designed as XML tags, control metacomponent composition and adaptation, select predefined options, and iterate metastructures to generate customized assets. Metavariables and metaexpressions provide powerful parameterization mechanisms. Values of metavariables are propagated across metacomponents using scoping rules designed to enhance adaptive reuse in novel contexts.

The metacomponents are organized into a layered metacomponent architecture called an x-framework in XVCL context. An x-framework is a hierarchy of metacomponents interrelated by <adapt> command and values of XVCL variables. It is also normalized to eliminate redundancies. Metacomponents at lower levels are relatively context-free building blocks to be adapted for reuse by the higher level metacomponents. The topmost metacomponent, called the specification frame (SPC for short), controls the whole composition and customization process. An x-framework forms a base of reusable assets, such as a product line architecture.

In practical experience, we usually design some template metacomponents. A template metacomponent is a special type of metacomponent that facilitates generation of a group of related components. It defines a composition of the lower metacomponents. You will see some template metacomponent examples in our case study.

Starting with the SPC, the XVCL processor traverses an x-framework, executing XVCL commands embedded in metacomponents and conducting necessary adaptation and composition in order to produce custom components. This process is shown in Figure 1. A simple example is given in section "XVCL Processor" which shows the interpretation and customization process for an x-framework.

Click To expand
Figure 1: Component construction with XVCL

A Uniform Variability Mechanism to Achieve Traceability

Variants in a domain may have different impacts on a system. For example, in software product line development, in order to accommodate some variants, we need to change many product line assets, such as domain models, product line architecture, code components, and others. The same problem can happen for a single system during the software evolution, where variants can affect the design, UML models, program, documentation, and so forth.

To effectively manage variants, it is essential to ensure traceability of their impact across all software assets throughout the software development lifecycle. This is illustrated in Figure 2.

Click To expand
Figure 2: Tracing variants' impact across software assets

Traceability is easier to achieve if we apply a uniform variability mechanism across all software assets. A uniform variability mechanism also facilitates the customization of the existing software assets when there are new requirements during the process of software evolution. The uniform variability can help make UML models, code components, documentation, and so on evolve in a synchronized manner. This will reduce the error of having inconsistent customization of software assets, for the same system or another evolved system which runs on a different platform. As XVCL is capable of configuring variants to all kinds of textual contents, it is natural to address this tracing problem with XVCL.

The nontextual assets that cannot be directly manipulated by XVCL will be converted into an equivalent textual representation, and then we instrument the text with XVCL commands. For example, we convert UML diagrams into the equivalent XMI (OMG, 1999) format. By introducing XVCL to various models, our method enhances the manipulation of these models. Rather than working with models manually, which is time-consuming and error-prone, XVCL automates the process of producing customized models for selected variants.

XVCL Processor

We use JDOM[1] to translate a metacomponent to its tree view. JDOM is an open source, pure Java API for parsing and manipulating XML documents. Like DOM, JDOM represents an XML document as a tree composed of elements, attributes, comments, text nodes, CDATA sections, and so forth.

The XVCL processor interprets each XVCL command in metacomponents and gathers the emitted result of each XVCL command as output. In the tree view, this concept can be translated as "a Node interprets itself, and then gathers output from both itself and its children as its output" (Li, 2002). To make the JDOM tree parse itself, we extend it to XVCL command tree. We create a class for each XVCL command and create a JDOM factory for returning XVCL command class's objects as JDOM tree nodes. Figure 3 shows the class diagram of XVCL commands.

Click To expand
Figure 3: Class diagram of the XVCL commands

The XVCL processor checks whether metacomponents are valid or not according to the XML specification and the grammar definitions in DTD before processing the x-framework. If so, the processor traverses x-framework with traversal order dictated by <adapt>, interprets XVCL commands embedded in visited metacomponents, and assembles the output (e.g., a custom program) into one or more files. This customization process of the x-framework is directed by instructions contained in SPC and also other XVCL commands embedded in every metacomponent.

To facilitate understanding, the metacomponents are denoted with a tabular view (the same style as the one used by XMLSpy[2]). Figure 4 illustrates the customization process where metacomponents A (an SPC), B, C, D, E, and F form an x-framework as follows:

Click To expand
Figure 4: Example of an x-framework and SPC

  • metacomponent A adapts metacomponents B and C;

  • metacomponent B adapts D and E;

  • metacomponent C adapts E and F.

B and C are roots of their respective sub x-frameworks. The <adapt> command tells the processor to customize the specified metacomponent and assemble the customized result into the output. Figure 5 shows the traversal path of the XVCL processor and custom result for the example. <adapt> command may also contain customization commands. In such a case, part of the output will be a customized version of the <adapt>ed metacomponent. More such examples will be given in our case study.

Click To expand
Figure 5: Example of metacomponent processing

Metavariable Scoping Rules

Given an x-framework and SPC, for any two metacomponents X and Y, we say that X is an ancestor of Y, if X <adapt>s (directly or indirectly) Y in the processing flow defined by the SPC; we call Y a descendant of X.

Metavariable scoping rules remains the same for both single-value and multivalue metavariables. The <set> command(s) in the ancestor metacomponent takes precedence over <set> commands in its descendent metacomponents. That is, once a metacomponent X sets the value of metavariable v, <set> commands that define the same metavariable v in descendent metacomponents (if any) visited by the processor will not take effect.

However, the subsequent <set> commands in metacomponent X can reset the value of metavariable v.

Metavariables become undefined as soon as the processing level rises above the metacomponent that effectively set metavariable values. (Note: metavariables that are set within <insert> commands become undefined when the processing level rises above the metacomponent containing the <break>.) This makes it possible for other metacomponents to set and use the same metavariables and prevents interference among metavariables used in two different sub x-frameworks in the x-framework.

Figure 6 is a simple example which shows some of the scoping rules. A direct reference to metavariable C is written as '@C'.

Click To expand
Figure 6: A metavariable scoping rule example

The <set> command in metacomponent A is inserted to the break b1 in metacomponent B. Metacomponent B also has the <set> command that set the metavariable VA1 as XB1. The value of VA1 is XB1 before the break b1 in metacomponent B. After the break b1 in metacomponent B, the value of VA1 becomes XA1 because the <insert> command in metacomponent A has inserted the <set> command that sets the metavariable VA1's value to XA1.

When <set> commands are inserted into a <break> these commands behave as if they are written in the place of <break> command. It is very important to note that ANY XVCL COMMANDS that are inserted to a break b1 in B will be processed as if they are originally written inside metacomponent B in place of break b1.

In the case of <insert-before> command, the <set> will behave as if it is originally written just before the break b1 in metacomponent B, whereas, in the case of <insert-after> the <set> command will behave as if it is originally written just after the break b1 in metacomponent B.

Metavariable VA1 cannot be referenced outside the <insert> in A because it is out of scope. And VB1 could not be referenced either as it was defined in A's descendent metacomponent.

These scoping rules are facilitating reuse across many systems. Lower-level metacomponents are usually generic, meaning that they contain metavariables, <break>s, and <select>s. Such metacomponents use <set> commands to define default values of metavariables to produce a default output text. When an ancestor metacomponent needs to adapt such a metacomponent to its context, it can use <set> commands to override one or more of the defaults, thereby customizing the output text.

Metacomponent Design Guidelines

We can apply the concept of separation of concerns at construction time during the process of the development of metacomponents. Our goals are to minimize the impact of changes, to facilitate the understanding of metacomponents, and to achieve high reusability and maintainability.

XVCL allows arbitrary decomposition of the underlying asset. For example, for the code-level design of metacomponents, the typical candidates are largely OO classes, but could also be control flow abstractions, aspects as in the sense of AOP (Kiczales et al., 1997), data structures, and so forth. We will try to eliminate redundancies brought on by the weakness of OO languages as we mentioned before (Jarzabek & Li, 2003). This means we may have some code patterns which occur repeatedly as candidates for metacomponents.

The design of metacomponents is an incremental process. We start by a small set of variants, then gradually incorporate more variants into the defaults until all variants are addressed. The initial choice of a combination of variants may consider the following factors:

  • architectural structure of the underlying system. The software architecture will affect how the hierarchy of the metacomponents are organized and their relationships;

  • complexity to handle the impact of a certain variant. The first-cut of metacomponents usually will not be tangled with many variants having large impact on the system; and

  • skills of the developers, like the normal programming.

The actual variants that be covered first usually is a trade-off among these factors. In order to incorporate new variants into metacomponents, we need to:

  • introduce XVCL metavariables to represent generic parameters;

  • apply <select>/<ifdef>/<ifndef> command to address variants whose implementation are known;

  • use <break> and <insert>/<insert-before>/<insert-after> commands to address variants whose implementation are uncertain;

  • iterate with <while> command to generate contents that have similar patterns; and

  • split large components into several smaller metacomponents, composing them by using <adapt> command.

[1]JDOM homepage: http://www.jdom.org

[2]XMLspy homepage: http://www.xmlspy.com/


Reengineering a PC-Based City Guide System into a Product Line

Team LiB

Reengineering a PC-Based City Guide System into a Product Line[3]

Mobile devices (such as Pocket PC, mobile phones, etc.) are widely used now and becoming more powerful. Naturally, there is a growing demand to port existing PC-based software systems to mobile devices of which there are many differing aspects. For example, a mobile device can run on various operating environments, including a compact version of Windows and Linux, as well as those that are not available on desktop computers, for example, Symbian. Pocket PCs can have up to 64M memory or higher which supports J2SE[4] applications, while most of the mobile devices are only J2ME[5] enabled because of the limited resources available (less than 100kb memory, for instance). These variations make the systems running on mobile devices look and behave differently, for example, different user interfaces, different cache management strategies, and so forth. As the PC-based system should be adapted accordingly in order to accommodate different hardware and software platforms when porting to mobile devices, naturally all these different systems (together with the existing system) form a typical software product line.

"A software product line is a set of software-intensive systems that share a common, managed set of features satisfying 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" (Clements & Northrop, 2001). While sharing some common characteristics, a product line member distinguishes itself from the others through the satisfying of variant requirements (variants). Software product lines are an effective approach to achieve high reusability, quality, and productivity.

The reengineering process provides opportunities to improve maintainability, portability, evolvability, reusability, and so forth where these quality attributes were more or less ignored during development of the existing system. Reengineering an old system often assures better return of investment than development from scratch, as the improvements can be made based on the previous work, and some software assets can be reused.

Though Stoermer et al. (2002) briefly mentioned the problem of reengineering an existing system to a product line, there are no serious technical issues presented on how to achieve this goal. There is a distinct scarcity of published work on this topic, even though it is very promising and worthy of efforts, and would provide opportunities to bring the merits of product line to reengineering process.

This motivates us to investigate the problem of how to make an existing PC-based City Guide System (GS-PC for short, based on the Lancaster GUIDE[6] project) function on a wide range of mobile devices in a cost-effective way. In our experiments, we have applied "reengineering into the product line architecture" approach based on the metaprogramming technique provided by XVCL. This solution provides the following important benefits:

  • custom systems running on various mobile devices can be built through the customization of a common base of generic, adaptable, and reusable metacomponents, rather than implementing each system separately from scratch;

  • maximized reusability can be achieved to some degree by reusing as much as possible of existing software assets to build that common base of generic, adaptable, and reusable metacomponents;

  • minimized maintenance work by only maintaining a small number of metacomponents;

  • all software assets can be evolved in synchronization, which makes them remain consistent;

  • variants of small and large impact on system could be handled efficiently; and

  • quality attributes, for example maintainability, can be preserved during the customization of the product line architecture.

A City Guide System

The PC-based City Guide System ( Figure 7) helps users find information about the places of interest in a city. Working like a customized Web browser, it can guide and navigate users using backward, forward, refresh, and other similar functions. Other features include history storage and bookmark services, and a cache for efficiency. More advanced functions such as physical location awareness and instant messaging are also provided but not considered in our experiments. The original GS-PC was developed with JDK1.4 (J2SE).

Click To expand
Figure 7: A snapshot of City Guide system (GS-PC)

An Overview of the Reengineering for Product Line Process

The process of reengineering the GS-PC into the City Guide product line architecture involves the following stages as depicted in Figure 8.

Click To expand
Figure 8: The main stages in "reengineering into the product line architecture"

Firstly, we analyzed the GS-PC code and its documentation as the usual reengineering process does to understand the system, then the system's runtime component architecture and mappings of requirements to components were analyzed according to the identified use cases. With our understanding of the goal, some components that are potentially useful in building the City Guide System product line architecture were identified.

Secondly, we analyzed the City Guide domain (taking into account both PC-based and mobile device-based systems) as we are targeting the whole City Guide System product line. The objectives were to identify requirements common to all (or most) of the systems in this product line, as well as variant requirements for a specific product line member. The domain analysis process was guided by business needs — the City Guide Systems should run on a variety of devices, customizable to the needs of many customers. The commonality and variability across various City Guide Systems were reflected in a domain feature model.

Once enough information was obtained on the GS-PC and the whole domain, we began to restructure the existing code according to Frame concepts in the third stage. The x-framework defines "has-a" relationships among metacomponents, while in OO solution, the typical inheritance defines "is-a" relationships for classes. Therefore we would remove the unnecessary inheritance relationships and use composition instead. This followed the Frame concepts (composition with adaptation) which were used to reorganize and restructure the code components. Some of the code may be discarded or rewritten in this stage. The restructuring also involved the work to reorganize and modify the related documentation, models, and so on, according to the Frame concepts.

Components of the existing GS-PC were then positioned for reuse in the future product line architecture. The variants will be incorporated into the metacomponents incrementally. We addressed mainly variants across PC-based City Guide Systems when creating first-cut metacomponents as these variants may be universal across all City Guide Systems, hence this also helped us address variants related to mobile devices.

In the fifth stage, metacomponents were refined, more variants were incorporated, and more metacomponents were created. Finally all of the identified variants will be included in the corresponding metacomponents. At the end of this stage, we obtained the product line architecture for the City Guide Systems. A common base of metacomponents was built for both PC-based and mobile device-based City Guide Systems.

We finished the actual reengineering in the sixth stage. This stage was a process of forward engineering, and at the same time it was a process of application engineering to build a specific product line member by customizing the product line architecture obtained from the stages mentioned above. The common code base was reused; metacomponents were customized to build concrete components which meet specific requirements for a certain City Guide System.

Analysis and Understanding of the Existing GS-PC

As the first step to conducting a successful reengineering process, we examined all the related documents for GS-PC and analyzed its code. We tried to distill the use cases from the related code and documents as shown in Figure 9. These use cases will help us to understand the system and group the related components together. Use cases were also used in the restructuring phase to help organize the related code and documents.

Click To expand
Figure 9: Use cases for GS-PC

Having understood both functional and nonfunctional requirements for the GS-PC, we analyzed its runtime software architecture (Shaw & Garlan, 1996) described as a set of interacting components. The GS-PC runtime architecture is depicted in Figure 10 as a UML component diagram.

Click To expand
Figure 10: GS-PC runtime architecture

The GS-PC has a typical two-layered runtime architecture including presentation layer (user interface) and business logic layer. All City Guide Systems running on both PC and mobile device have the similar two-layered structure of runtime architecture.

During analysis, we documented mappings among use cases and components. Some of the metacomponent candidates were identified and marked for future use, but the result of the analyzing helped the restructuring work when most of the metacomponent candidates were to be identified.

Domain Analysis of the City Guide Domain

The commonalities among all City Guide Systems are

  • Basic navigation service-forward, backward, refresh, stop, and so forth.

  • Event-driven mechanism. When an event occurs, a dispatcher is responsible for invoking event handlers, which register an interest in the event, to process the event.

Some of the variants in the City Guide domain are:

  1. Caching Mechanism variant. This includes a number of small variants.

    • Cached or not cached. A system may or may not have cache facilities.

    • Cache size. Different systems may need different cache size because of the resource limits.

    • Caching scheme. One City Guide System may require that the most-often or most-recent accessed page should be cached. This will also affect the decision on how to add or delete cached items.

    • Record deletion amount. Different percentages of (cleared cache) and (total cache), for example, 10%, 20%, or 50%, can be used for different systems.

  2. User interface variants, such as look and feel, icons, layout, and so forth. The PC-based City Guide Systems have graphical user interface (GUI) while most of the mobile device-based systems can only use a simple textual user interface (TUI) because of the platform and resource limits.

  3. A system may or may not need a bookmark mechanism.

  4. Application models. An application model defines how to manage an application and how management responsibilities are divided between the application and the underlying operating system (or other system-level software) (Giguere, 2002). J2ME currently supports four different application models while J2SE supports only one.

    • Traditional Application Model. This is the only application model that is used in J2SE. The entry point to the application is a static method called main().

    • Applet Model. The main class in an applet extends java.applet.Applet and defines four life-cycle notification methods: init(), start(), stop(), and destroy().

    • MIDlet Model. A MIDlet's main class extends javax.microedition. midlet.MIDlet. Three life-cycle notification methods are defined: startApp(), pauseApp(), and destroyApp().

    • Xlet Model. An Xlet's main class implements the javax.microedition.xlet.Xlet interface, which also declares four life-cycle notification methods as the Applet model: initXlet(), startXlet(), pauseXlet(), and destroyXlet().

Feature Model for the City Guide System Domain

It is important to clearly understand the range of common and variant requirements for a product line architecture and relationships among the variants.

Interdependencies among variants are very common. Taking the previously mentioned caching mechanism as an example, if the Cache option is not chosen, then variants associated with the Cache (such as Cache size, deletion algorithm, etc.) cannot be selected.

The configurations of variants must be legal, otherwise they are meaningless. For instance, if the "cache most-often accessed pages" variant was chosen, then you could not use the cache management mechanism based on date stamp, which is used for most-recent accessed caching scheme.

According to the nature of the product line, various kinds of requirements may be modeled as categorized by the FURPS+ requirement model (Grady, 1992), such as functionality, reliability, and so forth. The domain engineering will deal with most if not all of these requirements depending on the objectives determined during product line scoping.

Feature diagrams ( Figure 11) are used to represent common and variant requirements in a domain in an easily understandable way (Kang et al., 1990; Czarnecki & Eisenecker, 2000). It can help us decide which configurations of variants are legal and which are not. A legal configuration of variants can be accommodated in a single product line member and therefore defines this member. It is important that application engineers work with customers to select the variants that the customers really want. At this stage, we shall be careful about the decisions made, as not all configurations of variants are valid or "good" with respect to the functional and quality requirements.

Click To expand
Figure 11: Feature diagram for the City Guide domain

Restructuring GS-PC with Frame Concepts

An XVCL x-framework can achieve the same functionalities carried by an inheritance hierarchy. The x-framework defines the has-a composition relationship among the metacomponents which are more evolvable and maintainable than plain code components. Therefore, during this phase, most of the inheritance, especially those not necessary, would be removed and composition will be the primary technique to fulfill functionalities. All the related documents and models would be updated to reflect these restructurings.

Redundancy may cause serious maintenance problems, making inconsistent modifications which could bring bugs to the system. During restructuring, the existing redundancy in the old system, including identical fragments of code and nearly identical fragments of code, similar recurring code patterns, and so forth, were identified. These redundancy parts were potential candidates for future metacomponents. XVCL can effectively eliminate redundancies introduced by object-oriented technology (Jarzabek & Li, 2003).

During restructuring, the components' and fragments' potential for the future product line was evaluated, taking into account (Bergey et al., 2000):

  • portability of components and fragments across the J2SE and J2ME platforms

  • the amount of rework required to adapt a component or fragment for the intended product line architecture

Some candidates for metacomponents in the future product line architecture could be easily identified. For example, all the navigation service (backward, forward, and so on) must be provided by all the City Guide Systems. Therefore, the existing navigation components should be reengineered into the metacomponents for reuse across the product line members. Also, user interface elements (such as windows, buttons, etc.) can be reused for product line members running on the same platform (J2SE or J2ME). They are also candidates for metacomponents.

Positioning of the Existing GS-PC for Reengineering

As we discussed before, one component can be affected by many variants, and one variant may affect many components. We started this stage by evaluating the impact of variants on system components. Some variants have localized impact on one component only, especially those variants for user interface elements. For example, the font size of a menu item only affects the menu items. Other variants may have architecturally significant impacts that affect many components. Take the Cache mechanism mentioned above as an example: if you make your decision that the City Guide System should use the most-recent strategy to handle cache, then the related cache handling components should be developed; user interface may also be needed to fine tune some cache options, such as cache size, delete amount when cache is full, and so forth.

The ways to deal with impact of a variant may range from setting a component's parameters or making changes to component's code and adding new code, to creating new components, modifying component interfaces, and so forth. To facilitate the management of variants and the evolution of components, we will use the metarepresentation of components: metacomponents implemented with XVCL.

Metacomponents in XVCL are organized into an x-framework. An x-framework is an implementation of the product line architecture concept in XVCL. It unifies the conceptual organization structure and implementation architecture, and as can be seen in the forthcoming sections, the x-framework evolves with future evolutions. This helps to remedy the architectural erosion problem (Perry & Wolf, 1992; Hoek et al., 1999).

Figure 12 depicts some of the metacomponents identified and developed so far based on analysis and restructuring of the GS-PC. The metacomponents were developed according to the design guidelines presented in the section on Metacomponent Design Guidelines. We started from the developing of metacomponents for common services of the City Guide System: backward, forward, and so on. Initially, we considered only the J2SE variants, then we created other metacomponents and incorporated other variants including J2SE and J2ME variants, into the City Guide System product line architecture incrementally until all variants had been addressed, as can be seen from the following sections.

Click To expand
Figure 12: An x-framework for the GS-PC

The top-most metacomponent (SPC) specifies a legal variant combination, which will control how to construct the code components for a specific City Guide System. Template metacomponents are used to organize and manage metacomponents hierarchy. In Figure 12, GuideMain and BookMark are template metacomponents for GS-PC. Template metacomponents are designed according to the following pattern: for each screen, usually there is a template metacomponent that plays the role of a container for the adapted metacomponents. For example, as in Figure 10, part (a) and part (b) will have a corresponding template metacomponent as each part has his own user interface (screen).

The Guide.spc is shown in Figure 13. The XVCL processor traverses this x-framework starting with Guide.spc, and generates source code for the customized components of the City Guide System after adaptation and composition according to the XVCL commands embedded in metacomponents.

Click To expand
Figure 13: SPC for J2SE Guide system

Flags can be defined to indicate processing conditions. In this example, metavariable BookMark is a flag that controls the processing result of <select>/<option> command: only when BookMark is <set> to Yes, the related bookmark metacomponents will be <adapt>ed and the corresponding bookmark code components will be generated for the City Guide System. The <select> command selects zero or more from the listed option clauses. The XVCL processor processes each of the selected option clauses immediately upon selection. Options are selected based on the value of control-variable specified in the option attribute. CacheSize is another flag indicating whether the City Guide System have cache facility or not. Cache facility will be <adapt>ed into the system if CacheSize is defined (with <ifdef>). In this way <select>/<option>/<otherwise> (an <otherwise> example is shown in Figure 14) and <ifdef>/<ifndef> commands can accommodate anticipated variants.

Click To expand
Figure 14: Menubar metacomponent

Values of metavariables in Guide.spc are propagated to the descendent metacomponents according to the metavariable scoping rules of XVCL as introduced in the section on Metavariable Scoping Rules.

Generic names increase flexibility and adaptability and play an important role in building generic, reusable programs. XVCL metavariables and metaexpressions provide powerful means for creating generic names and controlling the x-framework customization process. This includes parameterization via metavariables and metaexpressions, loop with multivalue variable(s), and so forth. Figure 14 is the menubar metacomponent used to create menus.

All menu items are built with two while loops. Metavariables used in this Menubar metacomponent are defined in SPC ( Figure 13) and their values are propagated down to this metacomponent. A direct reference to metavariable, such as @Menubar, is replaced by the metavariable's respective value during processing; its value will be concatenated with Items and multivalue variables: Items Application, ItemsBookMark, ItemsEvaluation, and ItemsLog will be constructed. These variables are then used as the inner-loop variable to create its own corresponding menu items. Name Expression[7] @Items@Menubar is computed from right to left as follows:

        value-of (Items | value-of (Menubar))

where ‘|’ means string concatenation. Menubar is treated as a variable name, while Items is treated as strings.

In each of the inner loops, the value of @Items@Menubar will be evaluated when it is referred, and one value accepted from its value list in sequential order. Then this value will be concatenated with a menu item name prefixed m to generate a menu item name. In this way, all of the menu items corresponding to a menu are created according to the list of values in SPC.

For the BookMark menu, as an example, when the outer loop comes to the second round, BookMark will be referenced for the @Menubar metavariable and menu BookMark is created; then BookMark is concatenated with Items, so we get metavariable @ItemsBookMark, which is now used as the control variable for the inner loop; in the inner loop, values of @ItemsBookMark will be referenced and concatenated with m, and menu items mAdd and mOrganize are created.

As the system evolves, there may be unexpected changes to the existing system. In XVCL, inserting code and specifications at designated break points is a simple yet powerful means to handle these unexpected variants. For instance, menus should support keyboard alternatives: mnemonics and accelerators. Also, menus may be required to have icons; these requirements are not predictable in advance. We solve this kind of problem with <insert>/<insert-before>/<insert-after> and <break> commands in XVCL. Inside the inner <while> loop in Figure 14, there is a <break> point named Keyboard that can be used for injecting new code to change the default implementation. For example, we can insert mnemonics to this break point by <insert-before>/<insert-after> commands.

These mechanisms, which deal with changes, make the metacomponents easily adaptable, evolvable and robust to both expected and unexpected changes. This is illustrated in Figure 15 where, in the context of application2, metacomponents are adapted to meet the evolution requirements. For example, metacomponent X1' may have exactly the same content as X1, but a different code component will be produced because of the different option value (defined with <select>/<option>/<otherwise> and <ifdef>/<ifndef>). Additionally, the processing results of X2' and X2 may be different because we inserted some extra content into a break point defined in X2' (X2).

Click To expand
Figure 15: Metacomponents evolution

In summary, XVCL can easily deal with all three kinds of changes: local, nonlocal, and architectural (as identified by Bass et al., 2003). Metacomponents implemented with XVCL are more generic, flexible, evolvable, and reusable than code components. Adaptations and evolution of metacomponents can be achieved by means of parameterization via metavariables and metaexpressions, insertions of extension contents (including XVCL commands) at designated break points, selection among predefined options based on conditions, code generation by iterating over certain sections of metacomponents, and so forth.

Design and Implementation of the City Guide System Product Line Architecture

A product line architecture reduces the complexity and cost of developing and maintaining a product line member by reusing common assets and streamlining all the related work, such as documentation, testing, and so on. It must be evolvable, reusable, extendable, and configurable to accommodate variant requirements to product line members. With regard to the City Guide System product line architecture, it must accommodate both the J2SE and J2ME variants we have identified in the domain analysis phase.

J2ME Platform versus J2SE Platform

The first difference is the application model used for different platforms: we use the MIDlet Application Model for J2ME City Guide, and on the other hand, the Traditional Application Model is used for J2SE City Guide Systems.

As a subset of J2SE, J2ME targets consumer electronics and embedded devices. The whole java.awt Abstract Window Toolkit (AWT) and javax.swing Swing package hierarchies that define the J2SE graphical user interface (GUI) APIs are absent from Mobile Information Device Profile (MIDP), which defines the MIDlet Application Model. This means J2SE GUI components could not be used in J2ME MIDlet City Guide System where only textual user interface (TUI) can be used.

All City Guide Systems (J2SE and J2ME platforms) are event-driven systems, but each platform uses a slightly different mechanism for the event listening of GUI components. For the J2SE City Guide System, listeners are registered with the application's components, and then the event handlers are invoked when the relevant event occurs; in the MIDlet application model of the J2ME platform, the event is created based on the label of a component ( Figure 16).

Event listening in J2SE

Event listening in J2ME MIDlet application

public void actionPerformed(ActionEvent e)
{
   String event=e.getActionCommand();
   ......
}

public void commandAction(Command c, Displayable d)
{
    String event=c.getLabel();
    ......
}

Figure 16: Event listening in J2SE and MIDlet application

However, apart from the differences in user interfaces (GUI and TUI) and event listening as shown above, the majority of the business logic code remains exactly the same on both J2ME and J2SE platforms, and thus can be reused across the City Guide Systems running on both platforms.

Based on this analysis we can conclude that it is feasible to support both J2ME and J2SE versions of the City Guide System by a single product line architecture.

Design of the X-Framework for J2ME Platform

After considering these differences between J2ME and J2SE platforms, it is rational that we should design different template metacomponents for the J2ME version of the City Guide System. Because the event-driven mechanism is common across all City Guide Systems, we can reuse the event handling metacomponent HandleEvent.xvcl. Other common navigation services, such as the deleteURL, storeURL, backward and forward actions, can also be reused by the J2ME x-framework. The text-based interface contains two command elements (backward and forward), and a list for managing the favorites. The new template metacomponent J2MEGuide.xvcl is responsible for generation of the MIDlet City Guide System. Therefore, we can design the following x-framework for the J2ME City Guide System as shown in Figure 17.

Click To expand
Figure 17: X-framework for the J2ME City Guide System

Implementation of the J2ME Related Metacomponents

For different event listening mechanisms in J2SE and J2ME platforms, we can use <select> and <option> commands to separate the J2SE and J2ME specific code as shown in Figure 18. An event listening mechanism for a specific platform will be processed according to the selected value of metavariable Platform, which is a high-level control metavariable defined in SPC. Multivalue metavariable Events controls the generation of code for dispatching events in a while loop.

Click To expand
Figure 18: Portable event handling metacomponent

Metacomponent MobileGuideService composes all the mobile Guide services together as shown in Figure 19.

Click To expand
Figure 19: MobileGuideService metacomponent

Other metacomponents are related to textual user interfaces, the mobile version of the component for request information from server (MobileRequestInfo), and so on.

Realizing a GS Product Line Architecture as an X-Framework

By now all metacomponents for both J2ME and J2SE platforms are finished. The domain common and variant requirements are incorporated into these metacomponents. These metacomponents can now be merged together to form an x-framework for the City Guide System product line ( Figure 20). Guide.spc is a generic SPC that can be designed to cater to the needs of both platforms. We can build a City Guide System meeting specific requirements by customizing this general x-framework, no matter which platform is targeted.

Click To expand
Figure 20: X-framework for the whole City Guide system product line

Customizing the X-Framework: Forward Engineering for New Systems

The domain engineering tasks in the steps above were accomplished according to Domain Specific Software Architecture (DSSA) (Foreman, 1996) software product line approach. Now we can start the application engineering, which is a process of customization of the product line architecture to build new products through the reuses of metacomponents we have built. This is the process of forward engineering.

We demonstrate this with two mobile City Guide Systems running on Pocket PC and a high-end mobile phone by customizing the general x-framework ( Figure 20) described in previous sections. To develop a specific City Guide System, we first examine the feature diagram ( Figure 11) to select a legal combination of variants according to the requirements. Then we record the configuration of these variants for the target system in the SPC, which also specifies some important high-level customization at the same time.

City Guide System on Sony Ericsson P800

Sony Ericsson P800 is a high-end mobile phone with 12M internal memory which is J2ME enabled. This City Guide System will have no cache facility and no BookMark facility. An SPC for such a City Guide System is shown in Figure 21.

Click To expand
Figure 21: An SPC for City Guide system on P800

Metavariable Platform is responsible for the generation of platform specific components for different platforms. In this example, J2ME version City Guide System components will be generated. Figure 22 shows the runtime architecture of the City Guide System, and a snapshot of the running result.

Click To expand
Figure 22: Runtime architecture (a) and running result (b) of the City Guide system on P800

City Guide System on Pocket PC

Pocket PC is powerful enough to run J2SE (with third party Java Virtual Machine); therefore a City Guide System running on it is a J2SE application. Suppose a City Guide System on Pocket PC with bookmark facility, less cache compared to GS-PC, and no toolbar icons because of the limit of the display. Figure 23 shows the SPC for this City Guide System.

Click To expand
Figure 23: An SPC for City Guide system on Pocket PC

The runtime architecture for this City Guide System is exactly the same as the one in Figure 10. As we explained in the section on Metavariable Scoping Rules, we can overwrite the default content inside a <break> point by <insert>ing some other contents. This is exemplified in the SPC above. In order to delete the default toolbar icons, we inserted blank content with command <insert break= "icon"/>. Although the named <break> point Icon does not really exist in metacomponent J2SEGuide, the <insert>ed blank content will be propagated down to the descendent metacomponents where Icon is defined, that is the Toolbar metacomponent as shown in Figure 24.

Click To expand
Figure 24: Toolbar metacomponent

Handling Variants for UML Models

Variants for all of the textual assets can be handled in the same way as shown above for the code components. In this section we just show how to achieve traceability of the variants' impact for the high-level use case model as shown in Figure 9. After the UML models were converted into XMI representation, metacomponents for the models could be developed in the same manner as mentioned above. The use case metacomponent is depicted in Figure 25. When there is no bookmark required by a specific system, all the related information for bookmark use case will be excluded in the use case model metacomponent as depicted in Figure 26.

Click To expand
Figure 25: A use case metacomponent
Click To expand
Figure 26: A use case model without BookMark

In this way, a configuration of variants in SPC can be propagated to all the related assets. Tracing the impacts of variants across multiple assets is greatly simplified throughout the whole lifecycle.

Discussion

In our experiments, we illustrated reengineering of a PC-based system into a product line with a metaprogramming technique of XVCL. Firstly, we built a simple product line architecture for PC-based systems, then the architecture was evolved to accommodate mobi le device features. Finally the original architecture was developed incrementally into a full-fledged product line architecture that can accommodate both PC-based and mobile device based systems. A specific system (either platform) can be generated easily from the common base of metacomponents.

A metacomponent is a generic component. An x-framework is an implicit implementation of the software architecture for the underlying system. Therefore we can consider our evolution approach as a simple implementation of an architecture-based variant configuration mechanism (Hoek et al., 1999). The architecture erosion problem is mitigated because the x-framework evolves together with the evolution process.

There are 36 generic metacomponents which form the product line architecture, comprising 594 LOC (Lines of Code). Although you can generate an infinite number of desired City Guide Systems for either platform, you can get an idea of the effectiveness of our approach from the case study shown in Figure 27.

City Guide System | LOC
Original version | 401
P800 version | 210
Pocket PC version | 392
TOTAL | 1003

Figure 27: LOC for our case study

Instead of having to maintain 1003 LOC for all the systems, we need maintain only 594 LOC covering features of both platforms. With the approach presented here, we can manage a product line from a common base of generic metacomponents, without complicating programs in any significant way.

[3]This section is based on the paper "Reengineering a PC-Based system into the mobile device product line", published on "Proceedings of Sixth International Workshop on Principles of Software Evolution (IWPSE'03)"

[4]Java™ 2 Platform Standard Edition, http://java.sun.com/j2se

[5]Java™ 2 Platform Micro Edition, http://java.sun.com/j2me

[6]Lancaster GUIDE project homepage, http://www.guide.lancs.ac.uk/

[7]A simple Name Expression may contain just a variable reference, such as: @C or @@C. More complex (but more useful) Name Expressions can be written as: @A@B@C.


Related Work

Related Work on Software Evolution

Reengineering involves both reverse engineering and forward engineering (Holger et al., 1999). There are success stories of reverse engineering (e.g., Sneed, 1995) and many tools exist (e.g., Rock-Evans & Hales, 1992; Biggerstaff, 1989; Canfora et al., 1992; Jarzabek & Ling, 1996), but further experimentation is needed to make the automated reverse engineering practical because of the limits of the tools; for example, only a small portion of useful information for forward engineering is recovered, tools are not flexible and easily tailorable in new operating environment, and so on.

The reengineering targeted for improving reusability (Caldiera & Basili, 1990) is an interesting research topic. Thomson et al. (1994) used domain knowledge to maximize reuse but did not address component adaptability. It is hard to accommodate unexpected changes with Canfora's approach (Canfora et al., 1995) where the software architectural level issues are not addressed. Addressing the reengineering issues at architectural level, such as use case based (Bojic & Velasevic, 2000) or scenario-based (Bengtsson & Bosch, 1998) approach, or the approach to combine both static and dynamic views for architecture reconstruction (Riva & Rodriguez, 2002), is the right direction in order to improve the reusability in reengineering for a single system, but these approaches are inflexible in handling the large number of variants during the reengineering to a product line where adaptability and variability play much more important roles.

Reengineering or evolution using design patterns (Masiero & Braga, 1999; Cagnin et al., 2000) is attractive because design patterns can help to improve the system design, but they also have their demerits (Wendorff, 2001). There are two main shortcomings to design patterns: lack of extensibility, and performance degradation because they incur additional runtime overhead (Bromling et al., 2002). The same limits happen to wrapper approach in object-oriented evolution. The OO approach is very rigid, and it will bring a lot of redundant code about the class relationships. As performance is crucial to mobile devices where available resources are very limited, object-oriented methods are ill suited to deal with the multiple platform evolution situations because they lack the desired features.

Two other formal approaches for software evolution, for example, are graph data model (Luqi, 1990) and hypergraph model (Harn et al., 1999). When compared to these approaches, we argue that the XVCL approach is more practical and easier to use. The deriving of the x-framework for the PC-based system shares similarities to the work on architecture recovery (Duenas, 1998) with some major differences as we still add variants to the design and implementation so that the requirements, design, model, and implementation evolve in a synchronized way.

Typical software configuration management (SCM) systems provide matured functions such as version management and change management (Do, 1999; Leon, 2000). The essence of SCM is version management. While metacomponents capture component variability in a same-as-except manner, there is no need to keep different versions for different property combinations. With this implicit version control mechanism, one will be unconcerned with finding the correct version for components during building and distribution, and avoid possible version conflicts. Change control and version management is still required during the early stages of the metacomponent development. However, this is alleviated by the strength in the flexibility of variant configuration and capability of adaptation.

Related Work on Variability Mechanisms

Conditional Compilation

Conditional compilation (macros) in C or C++ is an old variability mechanism. Preprocessing directives (#include, #ifdef, #else, and #endif) mark the variation points in a C or C++ program and enable desired code segments to be included or excluded into or from a program. These preprocessing commands have more or less similar meanings to the corresponding XVCL commands, but are more rigid to deal with variants.

The directive #include would only be able to cater for expected variants, which is much less powerful than the <adapt> command in XVCL. Unlike XVCL, conditional compilation does not support metavariable references, expressions, and scoping rules. The actual affecting range of old macros cannot be controlled, which is all global scope. It does not respect scope including C++ namespace scope. Conditional compilation does not support breakpoints that indicate slots where additional code can be inserted for unexpected variants.

Template Metaprogramming

Template metaprogramming (Czarnecki & Eisenecker, 2000) is a generative programming technique which is largely based on the C++ template mechanism. Template mechanism is C++'s implementation of the concept of genericity (parameterized types or parametric polymorphism). Template metaprogramming is tightly coupled with a programming language such as C++.

While XVCL supports template-like parameterization and template-like metaprogramming, it can also accommodate unexpected changes, which template metaprogramming does not support. Metacomponents can be considered as highly configurable templates with Breakpoints in order to accommodate variants.

Object-Oriented Inheritance

Inheritance is the primary variability mechanism of object-orientation, but has some intrinsic problems (Bassett, 1997; Jacobson et al., 1997). The so-called "granularity problem" brings many redundancies to code. The subtyping mechanism depends too heavily on units that are too large to handle fine variations and changes, let alone unexpected changes; for example, if you want to override only one line instead of a whole method. If the number of variants increases, the class hierarchy will expand quickly, causing maintenance and scaling problems.

XVCL handles variants at construction time. It supports arbitrary decomposition and composition of the underlying assets. The metacomponents can be built at any granularity level, such as attributes, class, method, data structures, and so forth, or even parts of a textual description of the software requirements. Concrete assets can be constructed from the composition and adaptation of metacomponents. The Java Buffer Library experiments showed that Buffer x-framework contains less than 32% of code that we find in the original Java Buffer classes (Jarzabek & Li, 2003).

Delegation

In object-oriented languages, delegation is a technique that enables objects to handle a request by delegating operations to its delegate. In most of OO programming languages, delegation is realized as object composition, keeping a reference to a delegated object in the delegating object. To accomplish a task, the delegating object invokes operations in the delegated object.

Delegation is an alternative to inheritance. The delegating object can contain common behaviors, while the delegated objects support variant behaviors. Once the delegating object receives a request it cannot satisfy, it forwards the request to corresponding delegated objects. Delegation is widely used in many design patterns (Gamma et al., 1995) to handle variability. Examples of these patterns include the State, Strategy, and Visitor patterns. Wrapping (Bosch, 2000) can be also considered as a special use of delegation.

Like x-frames, the delegating objects contain reusable knowledge and are extensible. The difference is that delegation composes behaviors at runtime, whereas XVCL supports adaptation and composition at program construction time. Being a runtime mechanism, delegation makes software more flexible. However, when thé number of variants increases, especially when the interdependencies of the variants are considered, the number of required delegated and delegating objects may grow quickly. There are also runtime inefficiencies with delegation.


Conclusions and Future Work

As software evolves, a large number of variants may arise, especially when such kinds of evolutions are related to multiple platforms as shown in our case study. Handling variants and tracing the impact of variants across the development lifecycle is a challenge. To ease the task, we developed a uniform variability mechanism, called XVCL, to handle variants within and across all assets.

  • Strengths: XVCL allows us to evolve the system in a systematic and cost-effective way. It provides traceability from source of change to all the affected assets that can be represented as text. XVCL supports reuse at any granularity level, which is hard to achieve with other approaches. XVCL is based on a mechanism of composition with adaptation. We can reuse the compact metacomponent base to build the needed custom system easily. The metacomponents tend to be more evolvable than raw code components. As the system evolves, the implementation of the architecture also evolves.

  • Weaknesses: It is relatively hard to understand programs heavily instrumented with macros (e.g., Karhinen et al., 1997). This problem in XVCL is mitigated by the fact that XVCL is a full-fledged design method supported by tools, such as IXP (Chen, 2003), an Interactive XVCL Processor that serves as a debugging environment, and BP (Peng, 2003), a Backward Propagation tool that propagate changes in the generated code back to the related metacomponents. XVCL metacomponents are first-class design concepts that facilitate change. Metacomponents are organized into a layered architecture that strives to achieve separation of concerns. The XVCL adaptation mechanism is in sync with the design method. All this enhances understanding. As XVCL is designed to be a construction time reuse technology, it cannot handle binary components and dynamic configuration.

As for the supporting tools, we will improve the existing tools and develop a number of new tools. For example, we are developing a smart editor which hides the complexity of XVCL from the end user and helps to "think in XVCL" and "work with XVCL".

We also explored the evolution experiments with AspectJ[8], a popular AOP (aspectoriented programming) (Kiczales et al., 1997) tool. While AOP is very strong for separation of concerns and addressing the crosscutting concerns, it has relatively weak configurability and reusability, which are vital to a product line. The solution is to combine AOP and Frame technology, which means producing framed aspects (Loughran et al., 2003) which possess advantages from both approaches. We believe that framed aspects can alleviate many of the problems associated with both crosscutting code and evolution issues in a product line.

[8]AspectJ Home Page, http://aspectj.org/


References

Bass, L., Clements, P., & Kazman, R. (2003). Software architecture in practice (2nd ed.). Boston: Addison-Wesley.

Bassett, P. (1997). Framing software reuse - Lessons from real world. Yourdon Press, Prentice Hall.

Bengtsson, P., & Bosch, J. (1998, June). Scenario-based software architecture reengineering. Proceedings of Fifth International Conference on Software Reuse, 308–317.

Bergey, J., O'Brien, L., & Dennis, S. (2000). Mining existing assets for software product lines (Technical Report CMU/SEI-2000-TN-008). Carnegie Mellon University, Software Engineering Institute.

Bojic, D., & Velasevic, D. (2000, February). A use-case driven method of architecture recovery for program understanding and reuse reengineering. Proceedings of the Fourth European Software Maintenance and Reengineering, 23–31.

Bosch, J. (2000). Design and use of software architectures: Adopting and evolving a product-line approach. Boston: Addison-Wesley.

Bromling, S., et al. (2002, August). Pattern-based parallel programming. Paper submitted to the 2002 International Conference on Parallel Programming (ICPP-02), Vancouver, British Columbia.

Cagnin, M.I., Penteado, R., Braga, R.T. V., & Masiero, P.C. (2000). Reengineering using design patterns. Proceedings of Seventh Working Conference on Reverse Engineering, 118–127.

Caldiera, G., & Basili, V. (1990, February). Reengineering existing software for reusability (Technical Report UMIACS-TR-90-30, CS-TR-2419).

Canfora, G., Cimitile, A., & de Carlini, U. (1992). A logic-based approach to reverse engineering tools production. IEEE Transactions on Software Engineering, 18(12), 1053–1064.

Canfora, G., Fasolino, A.R., & Tortorella, M. (1995, October). Towards reengineering in reuse reengineering processes. Proceedings of International Conference on Software Maintenance, 147–156.

Chen, L. (2003). Debugging meta-programs in XVCL. Honours Year Project Report. Singapore: National University of Singapore, Department of Computer Science.

Clements, P., & Northrop, L. (2001). Software product lines: Practices and patterns. Boston: Addison-Wesley.

Czarnecki, K., & Eisenecker, U. (2000). Generative programming: Methods, tools, and applications. Boston: Addison-Wesley.

Do, A.G. (1999). The impact of configuration management during the software product's lifecycle. Proceedings of 18th Digital Avionics Systems Conference, C.2–7, vol.1, pp. 1. A.4–1-1. A.4–8.

Duenas, J. C., de Oliveira, W. L., & de la Puente, J. A. (1998). Architecture recovery for software evolution. Proceedings of 2nd Euromicro Conference on Software Maintenance and Reengineering and 6th Reengineering Forum.

Foreman, J. (1996, April). Product line based software development- Significant results, future challenges. Proceedings Software Technology Conference (STC'96), Salt Lake City, UT.

Gamma, E., Helm, R., Johnson, R., & Vlissides, J. (1995). Design patterns: Elements of reusable object-oriented software. Boston: Addison-Wesley.

Giguere, E. (2002, October). Under standing J2ME application models. Retrieved August 2003 from http://wireless.java.sun.com/midp/articles/models/

Grady, R. (1992). Practical software metrics for project management and process improvement. New York: Prentice-Hall.

Harn, M., Berzins, V., Luqi, & Mori, A. (1999). Software evolution process via a relational hypergraph model. Proceedings of IEEE/IEEJ/JSAI International Conference on Intelligent Transportation Systems, 599–604.

Hoek, A., Heimbigner, D. H., & Wolf, A. L. (1999). Capturing architectural configurability: Variants, options, and evolution (Technical Report CU-CS-895-99). University of Colorado at Boulder, Department of Computer Science.

Holger, et al. (1999, October). The FAMOOS object-oriented reengineering handbook. Retrieved from http://www.iam.unibe.ch/famoos/handbook/

Jacobson, I., Griss, M., & Jonsson, P., (1997). Software reuse architecture, process and organization for business success. Boston: Addison-Wesley.

Jarzabek, S., & Li, S., (2003, September). Eliminating redundancies with a "composition with adaptation" meta-programming technique. Proceedings of European Software Engineering Conference and ACM SIGSOFT Symposium on the Foundations of Software Engineering (ESEC-FSE'03), Helsinki.

Jarzabek, S., & Ling, T.W. (1996, May). Model-based support for business reengineering. Journal of Information and Software Technology, 38(5), 355–374.

Jarzabek, S., & Zhang, H. (2001, August). XML-based method and tool for handling variant requirements in domain models. Proceedings of 5th IEEE International Symposium on Requirements Engineering (RE '01), 166–173. Toronto: IEEE Press.

Jarzabek, S., Bassett, P., Zhang, H., & Zhang, W. (2003, May). XVCL: XML-based variant configuration language. Proceedings of 24th International Conference on Software Engineering (ICSE 2003), Portland, OR.

Kang, K., et al. (1990). Feature-oriented domain analysis (FODA) feasibility study (Technical Report CMU/SEI-90-TR-21). Pittsburgh, PA: Carnegie Mellon University, Software Engineering Institute.

Karhinen, A., Ran, A., & Tallgren, T. (1997). Configuring designs for reuse. In Proceedings International Conference on Software Engineering (ICSE'97), 701–710. Boston, MA.

Kiczales, G., Lamping, J., Mendhekar, A., Maeda, C., Lopes, C. V., Loingtier, J.-M., et al. (1997). Aspect oriented programming. Proceedings European Conference on Object-Oriented Programming (ECOOP), Finland.

Leon, A. (2000). A guide to software configuration management. Artech House.

Li, S. (2002, June). JDOMbasedXVCL Processor. Research paper presentation. Singapore: National University of Singapore, Department of Computer Science.

Loughran, N., Rashid, A., Zhang, W., & Jarzabek, S. (2003, November). Supporting product line evolution with framed aspects. ACP4IS workshop, AOSD 2004. Lancaster, UK.

Luqi (1990). A graph model for software evolution. IEEE Transactions on Software Engineering, 16(8), 917–927.

Masiero, P.C., & Braga, R.T.V. (1999). Legacy systems reengineering using software patterns. Proceedings ofSCCC '99. XIX International Conference of the Chilean, 160–169.

Mens, T., et al. (2003, April). Towards ataxonomy of software evolution. Proceedings of Second International Workshop on Unanticipated Software Evolution (USE2003), Warsaw, Poland.

OMG (1999, October). XML metadata interchange (XMI) 1.1 RTF. OMGDocument ad/ 99–10-02.

Peng, C. (2003). BP tool (Backward propagation of changes). Research Presentation. Singapore: National University of Singapore, Department of Computer Science.

Perry, D.E., & Wolf, A.L. (1992, October). Foundations for the study of software architecture. Sigsoft Software Engineering Notes, 17(4), 40–52.

Riva, C., & Rodriguez, J. V. (2002). Combining static and dynamic views for architecture reconstruction. Proceedings of Sixth European Conference on Software Maintenance and Reengineering, 47–55.

Rock-Evans, R., & Hales, K. (1992). Reverse engineering: Markets, methods and tools. Ovum Report vol. 1, London: Ovum Ltd.

Shaw, M., & Garlan, D. (1996). Software architecture: Perspectives on an emerging discipline. New York: Prentice-Hall.

Sneed, H. (1995). Reverse engineering as abridge to CASE. Proceedings 2nd Working Conference on Reverse Engineering (WCRE '95), 300–313. Los Alamitos, CA: IEEE Computer Society Press.

Soe, M.S., Zhang, H., & Jarzabek, S. (2002, July). XVCL: A tutorial. Proceedings of 14th International Conference on Software Engineering and Knowledge Engineering (SEKE'02), 341–349. Italy: ACM Press.

Stoermer, C., O'Brien, L., & Verhoef, C. (2002). Practice patterns for architecture reconstruction. Proceedings of Ninth Working Conference on Reverse Engineering, 151–160.

Thomson, R., Huff, K.E., & Gish, J.W. (1994, November). Maximizing reuse during reengineering. Proceedings of Third International Conference on Software Reuse: Advances in Software Reusability, 16–23.

Wendorff, P. (2001). Assessment of design patterns during software reengineering: Lessons learned from a large commercial project. Proceedings of Fifth European Conference on Software Maintenance and Reengineering, 77–84.


Endnotes

  1. JDOM homepage: http://www.jdom.org

  2. XMLspy homepage: http://www.xmlspy.com/

  3. This section is based on the paper "Reengineering a PC-Based system into the mobile device product line", published on "Proceedings of Sixth International Workshop on Principles of Software Evolution (IWPSE'03)"

  4. Java™ 2 Platform Standard Edition, http://java.sun.com/j2se

  5. Java™ 2 Platform Micro Edition, http://java.sun.com/j2me

  6. Lancaster GUIDE project homepage, http://www.guide.lancs.ac.uk/

  7. A simple Name Expression may contain just a variable reference, such as: @C or @@C. More complex (but more useful) Name Expressions can be written as: @A@B@C.

  8. AspectJ Home Page, http://aspectj.org/


Appendix - Summary of Basic XVCL Commands

We describe some basic XVCL commands in this appendix. The reader can find the full XVCL specification at http://fxvcl.sourceforge.net

Each metacomponent (called an x-frame in XVCL) is represented as a table where the first row specifies the metacomponent's name (e.g., xyz.xvcl), followed by optional attributes such as outfile.

XVCL command names are in bold, in the rows' left-most position, followed by command attributes in italics. Most of the attributes are assigned values, specified on the right-handside of the symbol "=". For example, command c1 in the previous table has two attributes, a1 and a2, which are set values v1 and v2, respectively.

We use indentation to indicate the nesting structure of XVCL commands. The commands at the same nesting level appear in the same column in the table. For example, in the table above, commands c1, c2, and c4 are at the same nesting level, and command c3 is nested in command c2. The XVCL processor processes the commands in the depth-first order.

In this section, we explain the basic XVCL commands.

The set command assigns a "value" to variable var-name.

The set-multi command assigns a list of values (one or more) to a multivalue variable var-name. Multivalue variables are mainly used to control iterations of while commands.

The while command iterates over the XVCL commands contained in its body. In the ith iteration, we use the ith value of each of the multivalue variables listed in using-items-in attribute. Therefore, all the multivalue variables listed in using-items-in attribute must have the same number of values. The body of while command may contain a mixture of textual content and XVCL commands.

The adapt command instructs the XVCL processor to include a metacomponent (in this example a metacomponent named xyz.xvcl) after possible customizations, as specified in the rows below adapt. The processor emits the customized contents of a metacomponent to the output. The customizations of a metacomponent are done by inserting the body of insert-before/insert/insert-after commands at specific break points.

The insert command replaces the break point break-name with the insert-body in the adapted metacomponent. The insert-before command inserts the insert-body before the break point break-name in the adapted metacomponent. The insert-after command inserts the insert-body after the break point break-name in the adapted metacomponent. The insert-body may contain a mixture of textual content and XVCL commands.

The customizations may propagate from metacomponent xyz.xvcl down to metacomponents adapted (directly or indirectly) by xyz.xvcl. Once the processing of the adapted metacomponent is completed, the XVCL processor resumes processing of the metacomponent that contains a given adapt command.

The break command defines a break point at which changes can be made to the metacomponent's content. These changes are specified by insert-before/insert/insert-after commands in metacomponents that adapt this metacomponent directly or indirectly. The break command body usually contains the default content that may be replaced by an insert command or extended by insert-before and insert-after commands. The default content of break command may contain a mixture of textual content and XVCL commands.

The select command selects from a list of options based on the value of variable var-name. The XVCL processor processes the selected option immediately upon the selection. Each option may contain a mixture of textual content and XVCL commands.

If variable varname is defined (that is, if the variable has been assigned value in a set or set-multi command), the XVCL processor processes the command's body contained in the rows below. Otherwise, the command's body is not processed. The body of the ifdef command may contain a mixture of textual content and XVCL commands.

If variable var-name is NOT defined (that is, if the variable has NOT been assigned value in a set or set-multi command), the XVCL processor processes the command's body contained in the rows below. Otherwise, the command's body is not processed. The body of the ifndef command may contain a mixture of textual content and XVCL commands.


Chapter VII: UML- and XML-Based Change Process and Data Model Definition for Product Evolution

Ping Jiang,
University of Bradord,
UK
Quentin Mair,
Glasgow Caledonian University,
UK
Julian Newman,
Glasgow Caledonian University,
UK
Josie Huang,
Glasgow Caledonian University,
UK

This chapter presents a software architecture and implementation to support in-service product configuration management applicable to both the automotive and aerospace industries. In both these industry sectors it is now feasible, with emerging technologies such as telematic systems and OSGi, to implement a. distributed and integrated information system to support product evolution over its entire life cycle. For this area we demonstrate the definition of an exchangeable multidomain enterprise data model defined as an XML DTD. We also present a UML process model for configuration change management defined using a familiar industry-standard tool and develop a framework to show how exported XMI definitions can be translated into WfMC XPDL, whilst preserving the process model's semantics. The chapter goes on to describe an evolution process for in-service embedded software using the OSGi Framework.

Introduction

For complex products such as cars or aircraft, the electronic and telematic hardware and software are designed to be both modular and flexible. This is so that their configuration can quickly adapt to any unforecasted evolution that takes place during the product's life cycle. New telematic technologies allow in-service products to communicate with external information systems and are creating many new opportunities to develop new added value customers' services. This requires that the customer services design and engineering must be concurrent to the product design and engineering. Product Configuration Management (PCM) must be extended to in-service products through telematic networks to facilitate remote after-sales maintenance and software evolution.

Software evolution relates to the activity and phenomenon of software change (Lehman & Belady, 1985). Current approaches to software evolution usually establish an abstract software model and provide mechanisms to model change management in order to maintain the traceability and consistency of the change, for example, through hierarchical hypergraphs (Kahl, 2001) based on graph theory (Cabrera, Fortiz, & Llorca, 2001). Software component models are often used for the purpose of software evolution (e.g., EMPRESS consortium, 2002; Aniorte, 2003). A software component is a closed module which encapsulates functionality of arbitrary complexity, maintains internal state information, potentially utilizes multiple threads of control, and may be implemented in any programming language (Oreizy, Medvidovic, & Taylor, 1998). Component-based software supports dynamic upgrade and evolution for augmenting system functionalities (Ketfi, Belkhatir, & Cunin, 2002; Oreizy et al., 1998; Kramer & Magee, 1990). In 1999 the Open Services Gateway Initiative (OSGi) was founded and has created an infrastructure to enable remote component-based evolution via wide area networks and therefore facilitates product evolution in after-sales (OSGi Alliance, 2000).

Together with software components, a product consists of physical components, electrical components, equipment components, and associated documents. All of these exhibit interrelated dependencies and are involved in product evolution. Because today more than 60% of complex product content is delegated to system suppliers or OEMs, the product evolution or correction depends on skilled developers and requires heterogeneous subsystem integration. A tighter management control is necessary for managing projects and data within the context of a virtual enterprise. Virtual enterprises are characterised by the necessity to support multiple work team coordination and data integration across different domains. Support for PCM within the context of a virtual enterprise must integrate processes and data from PDM (Product Data Management), EDM (Electrical Data Management) and SCM (Software Configuration Management) to support complex product evolution or reconfiguration. There are standards or Commercial-Off-The-Shelf (COTS) products to support configuration management in individual domains but there has been no integration configuration environment to trace the progress of product evolution across all domains from any stage of the product life cycle. In order to drive the integration of heterogeneous domain tools, a generic business model must be defined in a form that is independent from any specific process modeling tool. Work undertaken in the AdCoMS (AdCoMS consortium, 1998) and the VISCOUNT (Mair & Haag, 2001) projects have used UML and PSL (Lubell, 1999) to define configuration management processes with supporting prototype tool and test scenarios. However, the results of these projects were based very much on feasibility studies, and further work is needed to investigate fully how complete these results are at describing virtual enterprise processes in general. There is also a requirement to define a unified metadata format to describe all PCM data in a consistent manner. Today the ideal candidate is a solution based on XML; this has been used to represent PDM data in EXPRESS/STEP (Coverpages Technology Reports, 2002). Products are increasingly complex and developed across several domains. Historically the PDM and SCM domains have evolved in parallel with no or little communication; meanwhile, EDM and PDM cultures are more alike. To make integration possible, the PDM, SCM, and EDM users need a common metadata model with a unified terminology and information flow description.

This chapter presents the DIECoM solution to support in-service product evolution. It consists of both Centralized Integration Configuration and Embedded Software Component Configuration. The IT architecture of the DIECoM project integrates PDM, SCM, and EDM domain tools and uses the OSGi Framework (OSGi Alliance, 2000) for remote component management with the aid of (1) a process model with coordinated activities across different domains; (2) a common data model providing integrity, correctness, and traceability of product configuration. A configuration change management process is presented for the purpose of product evolution. UML is used as the modeling language for the definition of processes across the different domains; then the resultant process model is translated into WfMC XPDL (Workflow Management Coalition, 2002) for evolution management enactment via a workflow engine. A product metadata model in the form of UML class diagrams is defined as an XML DTD to ensure the traceability and maintainability of a product. In terms of remote Embedded Software Component Configuration, a configuration model built on the OSGi Framework is proposed. The model introduces a configuration bundle to manage the bindings between components and to achieve smooth switchover during component upgrade. This mechanism is governed by an XML configuration file extracted from the XML product model. As a result the PCM system is able to support flexible reconfiguration and dynamic update during runtime.


Background

There is noticeable life cycle asymmetry between complex products in different industry sectors. For example, for cars/automobiles life cycle is about 10 to 15 years; for aircraft it is about 10 to 50 years; for embedded electrical, electronic, and telematic subsystems it is about one to three years; and for new software it is every six months to one year. Embedded subsystems should therefore have the ability to evolve easily and flexibly during a long product life cycle, especially in in-service products. Advanced communication and computer technologies can now facilitate bug corrections and provide new added-value services remotely for embedded subsystems. In a car, as shown in Figure 1, there is a trend to include an increasing number of Electronic Control Units (ECUs) which make up its electronic systems. Each ECU contains a microcomputer which is connected to a certain number of sensors and actuators. Each ECU contains some software consisting of on average 50 Kbytes of code with the availability of many parameters which have to be set up at the end of the production line (e.g., calibration activities) and in some cases in after-sales. ECU software is increasingly based on components developed using various Java-based technologies.

Click To expand
Figure 1: Example of some key electronic/Telematic functions in a car

In terms of traditional development, embedded software components are often implemented in an ad hoc way and the ability to support maintainability and evolution are often sacrificed for speed and efficiency. After deployment into a product it is difficult to upgrade or add new functions for the purposes of evolution. Detection of a critical problem for a batch of product often causes after-sale product call back at extremely high cost.

The current development of telematic and other emerging computer technologies facilitate Collaborative Configuration Management for product evolution. In Figure 1, a telematic subsystem called the Telematic Control Unit (TCU) (used by Renault for cars) is introduced into a product, which is internally connected to the bus of Control Area Network (CAN) for connection with ECUs. It is also connected to a multimedia bus such as bluetooth for connection to Man Machine Interface devices; for example, as shown by the two monitors in Figure 1, which can be navigation screens, small 16/9 video screens, voice recognition systems, and so forth. Externally, the TCU is connected to a WLAN (Wireless Local Area Network, for example IEEE 802.11b) or wireless WAN (Wide Area Network) such as the GPRS (General Packet Radio Service) or UMTS (Universal Mobile Telecommunication System). As a result, a TCU bridges the local network of a product to the external world and provides an innovative opportunity for complex product evolution, that is, remote Services Configuration Management. These services could be, for example, telediagnosis, configuration, customisation, navigation, and entertainment. Increasingly systems have an increasing number of downloadable embedded components. Together with new network technologies this makes it feasible to quickly evolve such systems whilst minimizing any impact on customers.


A Distributed and Integrated Information System for Product Evolution

DIECoM's mission was to model, validate, and provide tool support for cross-organizational PCM within the context of a virtual enterprise. Its results support product evolution in all areas and cover the entire product life cycle. A product goes through different steps that constitute this product life cycle: feasibility study, early definition, development, certification, production, and in-service support. A request for evolution dealing with change may happen at any stage triggered by:

  • Corrective (Mandatory) modification related to a problem correction.

  • Evolution of services (e.g., a new customer service using an on-board Internet connection) or improvement of the product (e.g., a new optimisation of an ECU for reducing fuel consumption).

In terms of these two triggers, two scenarios were implemented in the DIECoM project. The first is the change of the software/calibration of an Engine Control Unit of a car. It is based on a real problem in which a batch of cars exhibited a particular engine malfunction, leading to an urgent correction need for safety reasons. To solve such problems design/engineering experts and after-sales experts need to work together to identify which vehicles have to be recalled and how to resolve the issue. Ideally the new engine control software and calibration should be downloaded into the relevant vehicles via the Internet to avoid the necessity of customers bringing their vehicles to a garage to undertake the software correction and/or parameter value changes.

The second scenario is to offer a new customer service facilitated by the deployment of new broadband wireless Internet networks (e.g., UMTS, IEEE 802.11). In this case, the origin of the change is the availability of new communication capabilities consecutive to the deployment of new wireless communication networks. These new capabilities will lead the car manufacturers to develop new customer services in cooperation with its partners in the value chain. The new services will be put in the manufacturer's service catalogue and can be bought by any customer who wants to add the service to his service bundle. Adding a service to a service bundle will lead to change of the car's configuration. It is expected that such telematic changes will be achieved either by downloading new software (e.g., Java components) or by updating some existing parameters if the software is already embedded on board.

Product evolution in terms of the scenarios can be achieved by an elaborated evolution life cycle as shown in Figure 2.

Click To expand
Figure 2: DIECoM evolution life cycle

In Figure 2, the entire evolution life cycle is controlled by the centralised management of Change Control. Once a trigger of change happens, the Change Control unit will coordinate the teams involved from the different domains to go through the life cycle outlined in the following steps:

  • Change Early Definition for evaluation of a Change Request and investigation of its repercussions.

  • Change Development for detailed definition of the Engineering Change Request and Integration Tests.

  • Change Certification for certification of the product by relevant authorities.

  • Change Deployment for updating all necessary databases and sending all necessary information to perform the Change.

  • Change Application for the implementation of change and applying change on new manufactured products and in-service products.

To support this multidisciplinary and multidomain development, an IT infrastructure was implemented in the DIECoM project as shown in Figure 3. This is a distributed integration management system connecting various applications from different domains and further connecting with many instances of in-service products via the Internet. As a result the whole distributed system exhibits dynamic and mobile properties, where the in-service products maintain a relatively loose relation with the manufacturer; for example, the owner of a vehicle may change the car configuration without informing the car manufacturer.

Click To expand
Figure 3: IT infrastructure

On the manufacturer side, the DIECoM system is organized on top of the DIECoM Integration Framework using IBM WebSphere. It is structured to conform to IBM's Framework for e-business which defines an e-business as an organization that interacts with its customers, suppliers, business partners, and employees using Web technologies. There are five elements in the Integration Framework: Portal Server, Application Server, Workflow Server, Integration Broker, and Connector. Of these, the Connector enables the access to the various DIECoM Application Environments. In the DIECoM Pilot Demonstrator, the following COTS (Commercial-Off-The-Shelf) tools are integrated:

  • ENOVIA LCA V5R11 from Dassault-Systemes implementing PCM and PDM

    Product Configuration Management

    Product Data Management

  • CATIA V5 Electrical Products from Dassault-Systemes implementing EDM

    3D Electrical design

    2D and 3D Electrical Data Management (linked to ENOVIA LCA)

  • PVCS Dimensions from Merant implementing SCM

    Software Configuration Management

The Workflow Server is used to distribute, route, and track PCM-level enquiries and changes according to a business process model. The model is defined in UML using a CASE (Computer-Aided Software Engineering) tool (Rational Rose) and is transformed into WfMC XPDL for workflow execution (as presented in the next section). As a result, product evolution is driven by the UML process model across different domains to maintain product models and track changes; these are identified through domain databases (Manufacturing Bill Of Material, Software Database, and Hardware Database) and further integrated into the Product Database as a product configuration skeleton in the PCM system. The Portal Server allows users to buy software components through the Internet for in-service product evolution, for example, a new service for a car is advertised through a marketing portal through which users can update their cars' embedded software remotely. The ASCM (After Sales Configuration Management) system maintains a catalogue of available services and defines sales rules (who is permitted to buy the services) and installation conditions (the compatibility with already installed components).

On the in-service product side, the Telematic Control Unit (TCU) constitutes the telematic gateway of an embedded system in a product. Through a wireless network (GPRS, IEEE 802.11b), the product can be connected to the Internet and can be installed with new services remotely using the OSGi Framework. In the OSGi Framework a component is called a bundle. Bundles register their services and utilize the services provided by the other bundles. There are two types of bundles registered in the framework: one is a ConfigurationBundle responsible for managing the evolution process, and the others are Application Bundles, consisting of InterfaceBundles and Implementation Bundles, corresponding to changeable software components. The ConfigurationBundle controls the new component installation, old component removal, and component bindings based on a configuration file in XML. The configuration file is an XML fragment extracted from the in-service product model which defines the software component version, start sequence, component bindings, and so forth. Once evolution is requested, a new configuration file is generated by the ASCM system and downloaded into a product; the ConfigurationBundle can then control the evolution of the software components accordingly.

Note that the DIECoM system is an integration environment of off-the-shelf domain tools. It not only addresses the changes defined in the scenarios but it can also deal with change requests from any domain that we have a domain tool for. How many configuration items can be managed by the DIECoM system is mainly dependent on the scalability of the selected domain tools.

The physical deployment platform implemented in the DIECoM Pilot Demonstrator is shown in Figure 4. The main server platform is an IBM AIX Server V4.3.3. The AIX Server Platform hosts all of the DIECoM Application Environment (ENOVIA LCA and PVCS Dimensions) and Integration Framework Software Components (WebSphere). A Windows 2000 Workstation is used as Portal Server. Another Windows 2000 Workstation is used as the Device Management machine hosting WebSphere Everyplace Manager for after-sales product management. The WebSphere Everyplace Connection Manager enables a secure and reliable connection with the embedded device, using Ethernet, WiFi, or GPRS. Windows clients are allowed to access data and services anywhere in the network for cross-domain cooperation. On the product side, the TCU (Telematics Control Unit) has an embedded Java infrastructure, which is OSGi based and communicates with the WebSphere Everyplace components.

Click To expand
Figure 4: DIECoM deployment platform


UML Process Model for Configuration Change Management

Product evolution requires an executable process model to control the change life cycle outlined in Figure 2 and a traceable product model to record the evolution process. Many techniques exist for business process modeling (Saven, in press). Currently UML is a natural choice to support business process modeling because it supports multiple viewpoints and extensibility. Incorporating with XVCL(XML-based Variant Configuration Language), UML can handle variant domain models (Jarzabek & Zhang, 2001). UML also has widespread acceptance in industry. While UML has merits in that it is both versatile and flexible, its semantics have been left largely unspecified or unclear for process automation or workflow definition (Bruno et al., 2002). How to organize these diagrams and how to specify the fundamental characteristics of workflows in a machine interpretable way is unclear. Simply defining a process by using, for instance, activity diagrams in UML cannot include the complete, precise information necessary for workflow execution. Bastos et al. (2002) extended UML activity diagrams for use in workflow modeling. It associated activity diagram elements with the C-Wf classes using stereotypes and defined some new properties to provide information for workflow definition. Lubell (1999) pointed out that no single type of UML diagram captures all of the information needed to describe a process.

Several parallel standards exist today for workflow modeling, and these are promulgated by different consortia or standards bodies for different application fields; for instance, WfMC Workflow Process Definition (XPDL) for distributed workflow, NIST Process Specification Language (PSL) for business process, and IBM/Microsoft Business Process Execution Language (BPEL) for Web services. A feasible way to integrate business process modeling in UML with workflow modeling, possibly for more than one of the standards above, is to provide UML diagrams with clear semantics based on a metamodel for workflow definition and then to export the executable UML models into XMI. After that, a properly designed XSL (eXtensible Stylesheet Language) stylesheet for transforming XMI to a target workflow definition standard could tightly link business process models with various workflow templates. As XPDL from WfMC is a widely accepted standard that covers most of the features necessary for workflow definition, the WfMC metamodel for workflow process definition is a reasonable target workflow definition language. To achieve this the multiple diagram types of UML need to be well-organized and their semantics clarified so that business process models in UML can be designed in accordance with the WfMC metamodel as shown in Figure 5:

  1. Actor Definition Use case Diagram: Defines actors involved in the product life cycle and provides organizational aspects about which actors are involved in workflow execution.

  2. Metadata Model Class Diagram: Defines product structure and dependencies. The instances of the metadata model describe precise components and compositions of any products and provide informational aspects about what data is passed in workflow execution.

  3. Tool Definition Class Diagram: Defines details of the dedicated software tools used from different domains, that is, PCM, PDM, SCM, and EDM. It provides operational aspects about which tools are used to implement workflow execution.

  4. Use Case Diagram: Defines static relationships between use cases, actors and the relevant tools involved in a business process. Provides functional aspects about the relations among use cases, actors and tools.

  5. Statechart Diagram, Sequence Diagram, and Activity Diagram: Define dynamic behaviours or workflow of a business process utilizing information defined in (1) to (4). Provide detail of behavioural aspects that is, what/how will be done during workflow execution.

Click To expand
Figure 5: Organization of the DIECoM business process

In Figure 5 the dynamic behaviours of each use case diagram could be defined using statechart diagrams, sequence diagrams, and activity diagrams. However, all three diagram types are related to each other and aim to describe the business from different viewpoints in different detail. We need to clarify the semantics of each individual diagram type and to form a unified modeling methodology. Sequence diagrams are used for defining typical scenarios of a use case as a midway description of a modeling process. Then a workflow model will be extracted from the collected scenarios into a form of statechart diagram and further detailed by activity diagrams. Collectively they define a complete workflow model. The modeling process using different diagrams can be summarized in the following steps:

  1. Analysis of each use case to find all discrete states of the process then design of a statechart diagram according to the corresponding life cycle. In terms of the evolution life cycle in Figure 2, in total six independent states are identified, that is, Change Control, Change Early Definition, Change Development, Change Certification, Change Deployment, and Change Application, where Change Control is a root process that coordinates different states to manage the entire change life cycle. A statechart is then used to describe these states, state change relationships, and the input/output data of a state/process as shown in Figure 6. Therefore, a statechart is a high-level abstraction of a business process.

    Click To expand
    Figure 6: Statechart of change process

  2. Manual collection of workflow instances in terms of each state into sequence diagrams. In this stage a thorough investigation of workflow instances in terms of every identified state is conducted, by scenarios analysis, considering existing business processes and by appraisal of international standards recommendations, for example, ISO 10007 for product configuration management. Sufficient instances are expected to reflect all aspects of a state and each instance will result in a sequence diagram as a formal description.

  3. Workflow extraction from the instances of each state to form an executable activity diagram. In this stage, the sequence diagrams representing state instances are merged into a unique activity diagram using, for example, the inducing method proposed by Herbst & Chrysler (1999) and the discovery method proposed by Hwang & Yang (2002). The generated activity diagram describes the flow body of an identified state and covers all activity instances described by the collected sequence diagrams.

Following this modeling process and the proposed organization of UML diagrams in Figure 5, we can define a one-to-one mapping between the UML diagrams and the WfMC XPDL concepts as shown in Table 1.

Table 1: Relationship between UML diagrams and XPDL concepts
UML diagram | XPDL Concept
Use Case Diagram | Package
Statechart Diagram | Workflow processes
Activity Diagram | Workflow process
Instance of Class Diagram of metadata model | Workflow relevant data
Instance of Use Case Diagram for actor definition | Workflow participant
Instance of Class Diagram for tool definition. | Workflow application

After clarifying the organization of the UML diagrams, we need to further specify the workflow entities of WfMC XPDL in an activity diagram using stereotypes or attributes, for example, transitions, relevant data, and participants. A general concept mapping between activity diagram elements and XPDL workflow entities is proposed in Table 2.

Table 2: Activity diagram elements mapping to XPDL
Activity Diagram elements in UML | XPDL entities
Activity | Workflow process activity
Transition | Transition information
Swimlane | Workflow participant
Activity with "Tool" stereotype | Workflow application declaration
On Entry "IN" action and On Exit "Out" action of an activity | Workflow relevant data

The details of UML implementation of the mapping can be found in Jiang, Mair, and Newman (2003). An example of an activity diagram refining the state of the Change Control state is shown in Figure 7. As the main process of the entire change life cycle once a change is initiated, the Change Control state coordinates all the different domain work teams through the change life cycle.

Click To expand
Figure 7: Activity diagram of change change control process

The Change Control process is started upon reception of a change request (CR). When a CR is received, the first action will be the evaluation of this request. This activity is led by the Change Request Management Committee (CRMC) to decide if the request has grounds for being developed. If the CR is accepted, the Change Control process starts a sequence of subflows and an Engineering Change Request is initiated by the CRMC in order to study the technical impact of the Change Request. In the activity diagram of Figure 7, we use swimlanes for workflow actor definition, On_Entry action and On_Exit action for input and output data definition, and a transition guard condition for transition condition definition. In addition to the manual implementation indicated by the <<No>> stereotype, stereotypes of <<Subflow>> and <<Loop>> have been used in this diagram to support the hierarchical decomposition of a process model, corresponding to a subflow call and loop activity, respectively. An activity in <<Subflow>> specifies a subflow call. The body of this subflow is defined using the UML actual parameters attribute, for example, the Change Development subflow is defined in an XPDL file named AC_Change Development XPDL.xml. The activity of the Change Early Definition Loop has a <<Loop>> implementation type. We use the events of an activity to aid the definition of the associated attributes of <<Loop>>, that is, a REPEAT…UNTIL loop with a Loop Body definition of Change Early Definition Loop Body. The Loop Body is defined as a subdiagram of an activity called Change Early Definition Loop Body.

A UML process model has thus been organized in compliance with XPDL and includes precise information covering all the necessary features of a workflow for the purpose of its execution. A business process manager can therefore analyse business properties and define running details using UML and in an environment supporting UML model development, for example, Rational Rose. The defined UML process model can be exported into XMI for integration with workflow engines. As XML defines a standard syntax and thus simplifies tool implementation, most workflow engines can accept one or more workflow standards defined in XML. As a result, the integration of business analysis with workflow engines becomes a process of XML translation as shown in Figure 8, from XMI to an XML-based target language for workflow definition, for example, XPDL, BPEL, DAML-S. For a given target workflow language, an XSL stylesheet can be developed for this purpose. The details about UML to XPDL transformation can be found in Jiang, Newman, Mair, Valfre, et al. (2004).

Click To expand
Figure 8: Design executable business processes in UML


UML Metadata Model for Product Evolution

A product model with integrity, correctness, and traceability in terms of product configuration forms the basis of product evolution. The DIECoM project defines the product model from the following two perspectives:

  1. From the view of business analysis in order to define a metadata model by means of a UML Class Diagram;

  2. From the view of IT implementation to instantiate the metadata model for product representation, data exchange, and integration using XML.

The DIECoM metadata modeling definition process started with the collection of information about the enterprise data to be represented. A set of basic virtual classes that are used to derive all the necessary metadata is obtained first, defined as ConfigItem, Document, and Change:

  • The ConfigItem class provides a way to manage the product breakdown structure and supports different relations between elements. The Document and Change classes are strongly related to ConfigItem;

  • The Change class defines the life cycle of a change impacting the configuration items, starting from an Engineering Request to an Engineering Change Order;

  • The Document class is used for tracking all the definitions of the configuration items and changes. Documents provide details of configuration items and changes, and are instantiated for each domain.

Based on these basic classes, the metadata model in UML is obtained by analysing the functional and technical requirements that refer to and put constraints on the data. By studying the interactions occurring between enterprise objects, the messages they exchange and the information each of them requires can also be defined. These interactions were mainly captured from project scenarios and are represented by the following notations in UML:

  • Inheritance: a data element is a specialisation of another one. The derived data element inherits all the attributes of its ancestor and additionally may define its own attributes.

  • Association: a data element has an instance of another element. Each instance of that data element may refer to one or more instances of the associated element.

  • Composition: the related objects are owned by value, not by reference.

A simplified product metadata model is shown in Figure 9. It provides an organizational schema of product data across different domains. Product evolution is achieved by a change to product components and product structures based on the metadata model. The basic unit of the metadata model is the ConfigItem that can be various items from different domains, for example, Physical ConfigItem from PDM, Software ConfigItem from SCM, Electrical ConfigItem, Equipment ConfigItm from EDM, or a compound Product as a part of other products. During a product life cycle, it should be able to maintain a product model to track changes, retrieve document references, and identify configuration effectivity. The self-associations of ConfigItem define hierarchical compositions of parts. The class of Effectiveness defines a view for enabling the distinction between the aggregation of parts through product range, date range, and so forth. In this simplified version of the metadata model, only the class of Software Configitem is further broken down.

Click To expand
Figure 9: An example of enterprise metadata model

XML provides a standard metasyntax simplifying the creation of domain-specific grammars to represent hierarchical data components; its versatility has made it the standard data format in the e-business domain. The metadata model in UML defines the classes and their relationships in a virtual enterprise from the view of a business analyst. For the implementation of a PCM system, the metadata model in UML has been instantiated in an XML format in order to make business documents interpretable and exchangeable. This process of instantiating the metadata is depicted in Figure 10.

Click To expand
Figure 10: From class diagram to XML implementation

Transforming the UML model to XML is a common problem which arises when taking UML as a schema language on the one hand and using XML for serialization on the other; how to transform from one to the other is nontrivial. The main problems are that (1) the logical structure of an XML document comprises properly nested XML elements but UML metamodels are not necessarily tree structures; and (2) structuring an XML tree to reflect the exact meaning of a UML model needs some domain-specific knowledge. The XML Metadata Interchange (XMI) specification is based on the Meta Object Facility (MOF) from the OMG and is defined for the purpose of the exchange of metamodels and models. A particular example of its use is to serialize UML models using XML, where the properties, associations, and compositions of classes are mapped to independent XML elements in addition to the classes themselves. As a result, XMI preserves all the semantic relations in its own way. However, it is often expected that the XML file can be organized in an application-oriented way based on some domain knowledge. For instance, the meaning of the association between Product and ConfigItem in Figure 9 is that a Product consists of 1 to n ConifigItems. We hope the target XML tree can maintain this nested form for easy access by domain tools. A transformation (based on XSL) to an application-specific XML format is generally required if an XMI file is adopted as has been done in this work for UML to XPDL transformation.

In terms of the two main problems for UML to XML transformation, this chapter

  1. uses the IDREF and XLink mechanisms for representing a UML graph as nested XML trees;

  2. defines three simple mapping rules for transferring the relations of inheritance, association, and composition into a nested structure, in order to reflect the implied semantics of the UML metadata model.

The idea for (1) is from XMI and uses xmi.id, xmi.label, and xmi.uuid to identify XML elements so that the XML elements can refer to others using IDREF or XLink mechanisms. Using this approach, a nested tree structure of XML can represent a graph of UML. The DIECoM.Id entity is defined as an attribute to identify each class in UML:

<!ENTITY%DIECoM.Id
'id ID #IMPLIED
name CDATA #IMPLIED
uuid CDATA #IMPLIED'>

For the purpose of element reference, the DIECoM.link entity is defined to allow XML elements to act as simple XLinks or to use the IDREF mechanism:

<!ENTITY%DIECoM.link
'xml:link CDATA #IMPLIED
href CDATA#IMPLIED
idref IDREF#IMPLIED
uuidref CDATA #IMPLIED'>

The first two attributes, declared xml:link and href, enable an XML element to act as a linking element consistent with the XLink and XPointer specifications. The idref attribute allows an XML element to refer to another XML element within the same document that has a corresponding id attribute. The uuidref attribute is used to refer to an XML element that has a corresponding uuid attribute.

An XML element has an identity, may have attributes, and has a content model. These correspond to a class, attributes, and other relations in a class diagram. Corresponding to the three relations between classes in UML, three mapping rules are defined to convert a metadata model represented in a UML class diagram (for example, that in Figure 9) into a nested tree structure (as described in Figure 11). The resulting XML DTD must ensure that any XML document completely preserves UML semantics:

Click To expand
Figure 11: Part of XML DTD tree for Figure 9

  1. Association relation: the target class is translated as an XML element that is referenced by an element nested in the source class through DIECoM.link

    For example, the association relation (0..n) between Change and ConfigItem in Figure 9 implies that a Change may have impact on 0 to n ConfigItems where Change is the source class and ConfigItem is the target class. Based on this rule, the corresponding XML elements of Change and ConfigItem in the XML DTD tree could be generated as shown in Figure 11. The Change class as the source class nests 0..n Impacted_Items elements that use DIECoM.link for reference to the impacted ConfigItem elements (illustrated using the dashed arrows in Figure 11). Once a class is represented as a nested tree, an XML DTD can be generated easily; for example, Rational Rose provides an XML DTD add-in for automatic generation:

    <!ELEMENT Change (Impacted_Items*)> <!--- 0..n nested impacted_Items--->
<!ATTLIST Change
%DIECoM.Id;
>
<!ELEMENT ImpactedItems EMPTY>
<!ATTLIST ImpactedItems
%DIECoM.link; <!--- reference to the impacted ConfigItem elements--->
>

    In conclusion, an association reflects a weaker relation and the source element includes references to the target elements using DIECoM.link instead of nesting the target elements.

  2. Inheritance relation: all the specialized classes of an ancestor class are referenced through elements of DIECoM.link that are nested elements of the ancestor class through choice grouping.

    For example, in Figure 9, Physical ConfigItem, Electrical ConfigItem. Equipment ConfigItem, Software ConfigItem, and Product are all specialized classes of the ConfigItem (ancestor class) in different domains. Applying this rule, these relations can be defined in the ConfigItem element using choice grouping as shown in Figure 11 that uses an OR relation among domain item references, that is, any ConfigItem is one of Physical ConfigItem, Electrical ConfigItem, Equipment ConfigItem, Software ConfigItem, or Product. The definitions of domain items are referenced using DIECoM.link, for example, Product_Ref in the choice group refers to a Product element definition as indicated by the dashed arrow in Figure 11.

    In conclusion, an inheritance relation in UML defines specialized classes of an ancestor class, and the specialized classes can be represented by the ancestor class using the OR selection.

  3. Composition relation: any contained class becomes an independent element inside the element of the composing class.

    For example, the composition relation between ConfigItem and Effectivity in Figure 9 can be represented as a tree structure as shown in Figure 11 where the dedicated element of Effectivity is nested into the ConfigItem element. In fact, composition is a stronger relation than association.

By applying these three rules to the UML class diagram in Figure 9, XML trees can be obtained which are partially illustrated in Figure 11. In Figure 11 all elements are organized in a nested structure and the relations between elements are preserved. By using the Rational Rose XML DTD add-in, the XML DTD can be produced automatically to define the valid XML format of XML document instances. Note that the Rational Rose XML DTD add-in can only be used for XML DTD generation in terms of nested tree diagrams as Figure 11. Therefore, organizing UML class diagrams in a tree structure is necessary for XML definition. Taking the ConfigItem as an example, its XML DTD can be obtained from Figure 11 as:

<!ELEMENT
ConfigItem(Product_Ref|Physical_ConfigItem_Ref|Software_ConfigItem_Ref|
Electrical_ConfigItem_Ref|Equipment_ConfigItem_Ref|,
                                         <!---Applying Rule 2--->
ConfigItem_Child*,                       <!---Applying Rule 1--->
Effectivity,                            <!---Applying Rule 3--->
Document_Ref*)>                          <!---Applying Rule 1>
<!ATTLIST ConfigItem
%DIECoM.Id;
%DIECoM.link;
>
<!ELEMENT Product_Ref EMPTY>
<!ATTLIST Product_Ref
%DIECoM.link;      <!---Applying Rule 2 and pointing to a Product element--->
>
.......

The generated XML DTD is issued to various domain tools for XML file definition, interpretation, and validation. As a result, heterogeneous system information integration can be achieved through a common XML format for tracking and controlling the progress of product evolution. Based on the XML DTD for ConfigItem, an XML example to define an Engine Control Module used in a car, as shown below, that is initially defined in ENOVIALCA and later used by other applications such as PVCS as an SCM domain tool:

<?xml version="1.0" encoding="ISO-8859-1" ?>
       <ConfigItem id="C2371072" name="Engin Control Module 08" uuid="uuid-
0017A448-EB27-47E3-AC09-9655CEF46A01"> <!---%DIECoM.Id--->
              <Equipment_ConfigItem_Ref idref="ECM6800" />
<!---An Equipment ConfigItem--->
<ConfigItem_Child uuidref="uuid-0017A448-EB27-47E3-AC09-9655CEF46A10"/>
 <!---A child ConfigItem using the uuid for reference--->
<ConfigItem_Child
xml:link="simple"
href="http://www.DIECoM.org/scm.xml#xpointer( id(SCM7680))" />
<!---Another child ConfigItem in SCM domain using XLink and XPointer mechanism for
reference--->
    ......
                   <EFFECTIVITY>1 -999</EFFECTIVITY>
<!---This configuration is for batch products with Effectivity range from 1-999--->
         <Document_Ref uuidref="uuid-0017A448-EB27-47E3-AC09-9655CEF46A98"
/>
<!---the related documents can be referred using the uuid--->
......
</ConfigItem>

In this example, two kinds of reference to child ConfigItem, that is, IDREF and XLink, are illustrated where XLink links to an SCM file defining which software baselines will be installed into this Control Module.


Evolution Process for In-Service Embedded Software

Thus far, an executable change process model in XPDL and an exchangeable data model in XML have been generated from UML to support product evolution. In terms of inservice products, there are two different triggers for a change, that is, corrective change and service evolution. The change process is started by receipt of a change request (CR) from

The Quality or Customer Support Division of the Manufacturer or in special cases directly from the customer himself or one of suppliers for Corrective Change Requests;

The Marketing Division of the Manufacturer or directly from the Customer for innovative evolutions of the products and/or services.

This process goes through Change Early Definition, Change Development, Certification, and Change Deployment. Change Notes defining completely how/which and what products/services are impacted are obtained and transferred to the departments concerned (Production Units, Marketing, In-service, etc.) for Change Application. After the Change Note is deployed to in-service support, the ASCM system shown in Figure 3 starts the on-board configuration process for a batch of products or all products manufactured from a given date (i.e., depending on their Effectivity). This includes the sending of messages to the impacted customers about corrective change instructions or publishing new services catalogues through the PCM portal. Accordingly, a customer can require the installation of a new configuration (hardware and software) for the product. When the configuration change requests the replacement or adding of hardware, such an operation may be achieved by accredited professionals or by the customer himself. If the configuration change is just requesting the addition of some software components, this can be achieved by the remote downloading of the software into a vehicle using an on-board configuration management (OCM) system built on the OSGi framework. The OCM system is an application enabling the local management (configuration audit, configuration change and configuration check) of an embedded system. When adding new services, the OCM is responsible for ensuring that the new added application will not affect existing services. When updating an old service, the OCM is responsible for ensuring a smooth switchover of replacement. The OCM system consists of a ConfigurationBundle and a Configuration DB as shown in Figure 3.

For each TCU embedded in a product, there are three types of bundles on top of the OSGi framework as shown in Figure 12. All the application-related implementations are called Implement Bundles. Their interfaces are separated from the implementations and packed into a new bundle called the InterfaceBundle Wich contains all the common interfaces and classes to be exported to the OSGi framework. The ConfigurationBundle is specifically designed to achieve lightweight evolution management based on an XML configuration file obtained from the ASCM system and provides mechanisms to:

Click To expand
Figure 12: On-board configuration model

  • Manage crossreferences between bundles: any Implement Bundles register their services into the OSGi framework but, if they request services from the framework, they must get the service references from the ConfigurationBundle. That means a runtime selection of implementations for a given interface can be achieved by the ConfigurationBundle;

  • Manage service change events: the ConfigurationBundle receives all service change events from the OSGi framework and then manages the corresponding reference relations involved in the changed services according to the desired configuration described in XML. Then it can decide whether to publish an event to a particular application and when to publish it. This makes smooth updating on-the-fly possible. When a new service implementation is registered, it will not affect the existing system. When an old service implementation is unregistered, the client bundle will not realise it, either;

  • Manage state transfer: the critical object state in a bundle can be kept and transferred into a new bundle to achieve a smooth switchover;

  • Make remote monitor and diagnosis available: the ConfigurationBundle keeps all service references to log the communication information between bundles and remotely diagnose bindings.

Consequently, the ConfigurationBundle is responsible for monitoring the service change events and managing cross-references between bundles based on an XML configuration file. These relations are shown by the arrows in Figure 12. If an in-service product needs to be evolved or corrected, the ConfigurationBundle downloads the XML configuration file from the ASCM into the Configuration DB and updates the onboard bundles according to the description of the configuration file. The XML configuration file is an SCM relevant fragment extracted from the product model defined in Figure 9. The Software Configltem can be a:

  1. CSCI (Computer Software Configuration Item): this is a software component that realises a complete task. Each CSCI may be a bundle in the OSGi framework available for remote downloading. Its execution could require services provided by other bundles. In order to ensure integrity and compatibility of evolution, the services used are defined by the composition of the Service Used class in Figure 9.

  2. Software Baseline: this is the set of approved, configured CSCIs. This class is managed by SCM tools directly. A software baseline can be an operating system, a framework, or application software that is composed of CSCIs (bundles) and will be loaded on an embedded computer system, such as the navigation device of a car.

  3. SBL (Software Baseline List): this is a Software Configuration Item that aggregates all the Software Products (SoftwareBaselines) that have to be installed simultaneously on one vehicle (car or aircraft, i.e., one for the whole vehicle).

As an illustration, consider a car managed by the PCM system as shown in Figure 13.

Click To expand
Figure 13: Product structure

The car has a unique SBL1 which is composed of all the software components in a car, that is, OSGi Framework, SW1 and SW2. There is an Equit1 in the car, which is a TCU, requiring the OSGi Framework and SW1 that includes a list of bundles. Note that the structure is defined in XML. The sequence of the XML elements determines the installation sequence; for instance, the installation of SW1 requires the installation of OSGi Framework in advance. Suppose a change request is received from the Customer Support Division for product retrofit with effectivity range from 100-999 and an SW1 is required to be updated. It triggers the change process which results in a new SBL2 with SW1 in version 2.0. A new product structure is generated as shown in Figure 14 and the associated Change Note is sent to the Customer Support Division. Based on the metadata model in Figure 9, each SoftwareBaseLine is composed of CSCIs that are downloadable bundles and further composed of Service Used elements to define service references. As a result, an XML configuration file attached to the Change Note defines the details of SW1, such as the composed bundles (CSCIs) and download locations, start sequence, services references, and so forth:

Click To expand
Figure 14: Updated product structure

<?xml version="1.0" encoding= "UTF- 8"?>
       <!--- a sample configuration file --->
       <Software Baseline id="SW35276" name= "SW1" Version= "2.0">
<CSCI id= "CSCI765" name= "interfaceBundle" Version= "1.0"
  xml:link= "simple" href= "http://www.DIECoM.org/osgi/interfaceBundle.jar">
 </CSCI>
<CSCI id="CSCI766" name= "implementBundle" Version= "2.0"
  xml:link= "simple" href= "http://www.DIECoM.org/osgi/implementBundle.jar">
</CSCI>
  <CSCI id= "CSCI767" name= "serviceClientBundle" Version= "1.0"
   xml:link= "simple" href= "http://www.DIECoM.org/osgi/client Bundle.jar">
  <Service Used name= "Service1" Class= "implementBundle. service1>
                        <Service Filter>
                                <FilterName>version</FilterName>
                                <FilterValue>2.0</FilterValue>
                        </Service Filter>
                 </Service Used>
 <Service Used name= "Service2" Class= "implementBundle.service2">
                        <Service Filter>
                               <FilterName>version</FilterName>
                               <FilterValue>2.0</FilterValue>
                        </Service Filter>
               </Service Used>
</CSCI>
</Software Baseline>

This configuration file declares that there are three components in SW1, that is, interfaceBundle, implementBundle, and serviceClientBundle; it declares where to download the jar file through the URL defined in the href attribute of Xlink. The element sequence in the XML file indicates the bundle start sequence, that is, starting from interfaceBundle, then implementBundle, and finally the serviceClientBundle that uses services from other bundles. The interfaceBundle defines the interface of all bundles and is a skeleton of SW1. It exports the service interface package into the OSGi framework but does not implement the Bundle Activator interface. Thus, the corresponding bundle manifest file does not include the Bundle Activator header. In contrast, Implement Bundle implements the Bundle Activator interface but does not export the package into the Framework. As a result, the other bundles on the framework cannot access the service implementation directly. The ConfigurationBundle will select which implementation for which interface based on the binding relations defined in the configuration file. The ServceUsed element defines the service binding relationships, that is, which services are required for running a bundle. These binding relations will be used for pinpointing the correct implementations through LDAP queries that are supported by the OSGi framework according to the filter defined in the ServiceFilter element of each used service.

The on-board configuration change process is shown in Figure 15. If a customer buys a new software component, he downloads a configuration file into the embedded DB. If it represents a new version of the SoftwareBaseline, the ConfigurationBundle will automatically download the bundles and activate them in the framework according to the new configuration definition. After the system is updated, the ConfigurationBundle will decide if the old bundle will be uninstalled. For this purpose, the ASCM system will ask the on-board system to enter a configuration Check State. The ASCM sends test instructions to the ConfigurationBundle and a validation of the new services is carried out. The customer may be involved in this validation to check the correct operation of the downloaded applications. The ConfigurationBundle sends an acknowledgement message to the ASCM system. If it is a successful update, the ASCM system will update the in-service DB and the ConfigurationBundle will remove the old system resources to end the update process. Otherwise, the ConfigurationBundle will restore the old configuration.

Click To expand
Figure 15: On-board configuration change

In this process, there are two ways to update a system, that is, batch and individually. For batch updating, the customer just needs to install and activate the ConfigurationBundle. The ConfigurationBundle will automatically download all involved bundles and install and activate them according to this configuration file. Because the service implementation binding information has been defined in the configuration file, the bindings between the service interface and the service implementation can be changed easily, that is, changing the service bindings and associated bundles can be achieved by changing the configuration file. The configuration file keeps a record of each individual product's configuration, which is stored in the embedded database. During the entire product life cycle, the offboard PCM system can retrieve the bundles and their configuration relationships based on this XML file. Working in this batch way, customers need not install the bundles and do not need to start them manually following instructions from a manufacturer. No matter how many bundles are involved in a product, customers just need a single bundle: the ConfigurationBundle and the associated configuration file in XML. For uninstalling an application, removing the ConfigurationBundle will remove all bundles in a product.

For a new configuration, sometimes we would like to download only the new bundles of the affected baseline but not all the bundles so as to reduce the time and the cost of the communication. In this case, individual updating can be used and only the changed bundles are updated. The ConfigurationBundle is able to check its references on the framework and download the appropriate services according to the binding relations defined in the Service Used elements. This is achieved by a Service Binding object in the ConfigurationBundle that controls service references of Implement Bundles. Each Implement Bundle registers its services into the OSGi framework but, for any required services from the framework, it creates an instance of a Service Binding object and passes this object to the ConfigurationBundle. In terms of a new configuration file, the ConfigurationBundle is able to change the Service Binding object to a new implementation and update the bindings between the service interface and the service implementation accordingly. For critical applications, the object states in a bundle can be transferred into the new bundle with the aid of a Critical State object to achieve a smooth switchover. The service bindings are defined using the XML file and managed by the ConfigurationBundle, facilitating agile and smooth updating at runtime, for example, in order to fix a software bug the user needs only to update the relevant Implement Bundles and provide new binding relations in XML and the bundles on the framework will be switched to use the new implementations without any awareness of the change. However, in the OSGi framework, the service bindings are usually precompiled and fixed in a java class file and not easy to change unless the new source code is recompiled. In addition, the ConfigurationBundle can log the information exchange between the bundles and support remote diagnosis because it maintains all the service crossreferences and can record the exchange messages.

The process of replacement of an old bundle is shown in Figure 16. If a new bundle, for example, a bug-fixed bundle, is activated and the new service implementation is registered into the framework, the ConfigurationBundle is aware of such an event and searches the service binding cache. If the old implementation exists in the framework, it will get new binding information from the configuration file and update the service bindings accordingly. During updating, the ConfigurationBundle notifies the old bundle to store the critical object state into a Critical State object and passes it to the ConfigurationBundle. Then, the ConfigurationBundle initiates the new bundle state and changes the service reference to the new implementation. After that, the ConfigurationBundle verifies whether the old bundle can be uninstalled. If no client is using any of the services of the old bundle, the ConfigurationBundle will uninstall it from the framework.

Click To expand
Figure 16: The dynamic updating process

In this update process, when a new bundle is activated in the framework, two service implementations exist with the same class name and the same filter. This may confuse a client bundle that is using the relevant services. In the OSGi framework, a bundle knows about another implementation registered in the framework through a service change event. Thus, a bundle will not be aware of the new service implementation registration if it is not notified. In the proposed model, the ConfigurationBundle manages all the service change events and the cross-references. If a service change event happens, the ConfigurationBundle will decide whether and when to notify clients in order to achieve a smooth switchover. In the demonstrator, the ConfigurationBundle is developed to deal with the service change event based on the service binding definition in the XML configuration files. The affected clients of the registration of a new bundle will be identified and new bindings will be updated only after the important states are restored from the old bundle and instantiated in the new bundle as shown in Figure 14. As a result, the registration of a new service will not affect the existing system and the bundles will not be aware of the deregistration of an old service.


Conclusions and Future Work

As a case study for product evolution in the automotive and aerospace industries, this chapter presented a software architecture and implementation to support in-service product management as part of the DIECoM project. DIECoM focuses on product configuration management throughout all its constituent areas (PDM, SCM, and EDM) and on the entire product life cycle (from early design to product recycling). The system consists of an offboard PCM system but much functionality is implemented in mobile configuration management systems on board. Through advanced communication technologies, configuration management is extended to in-service products potentially opening new markets. For example, the vehicle fleet market, the after-sales service market, and the after-sales replacement market. The methodologies of distributed integration and UML-based process and metadata modeling can be extended to other complex product management systems to support product evolution.

In the application proposed in this chapter, the feasibility of automated reconfiguration was achieved by careful analysis of the change process and the complete definition of the product metadata model. Both the change process and metadata were modeled in UML from a business analyst's viewpoint and then transformed into XML for Information Technology (IT) implementation. The UML process model of the change life cycle was elaborated and organized in accordance with the WfMC XPDL standard. Built on top of the DIECoM environment, the PCM system executes the distributed change processes in the form of XPDL workflow templates to support product evolution and problem correction. Each process interacts with product data models and generates relevant configuration information in the form of XML as a standard interface between heterogeneous tools and between the PCM system and distributed products. The method of transformation from UML models including the business process model and the product metadata model to the corresponding XML formats was presented. This shows how a view change from business analysis to IT implementation can be achieved automatically if some semantics of UML can be clarified to the business analysts in advance.

An on-board configuration management model built on top of the OSGi framework was proposed to support remote embedded software evolution. A ConfigurationBundle was introduced to manage the life cycle of an in-service product based on an XML configuration file that is extracted from the product XML tree. It supports service binding reconfiguration and dynamic evolution at runtime. The proposed model simplifies software development, facilitates the reuse of the old bundles, and makes it possible to diagnose and reconfigure a product remotely.

From the practices derived in DIECoM, system design of configuration management to support product evolution goes through several steps. A use case study was carried out to capture essential relationships between actors and to analyse the functionality of each individual actor from the user's perspective. Then, all processes and metainformation throughout the product life cycle was documented using UML. Subsequently, the distributed management system was implemented in an integration framework to meet the requirements of all actors. These kinds of systems tend to be monolithic information management systems which reside in several servers, for example, Portal Server, Application Server, Workflow Server, Integration Broker, and so forth. Organizational theory has shown that structure and change in organizations are inextricably linked (Orlikowski & Robey, 1991). A centralized development process makes little sense. Explicit knowledge is mostly local to work teams. Global knowledge is only implicitly available from workflow practice and feedback loops; developing an in-depth, overall model of the organization would not only be very expensive but also be subject to rapid aging as the units and their interactions evolve (Jarke, Jersfeld, Peters, & Pohl, 1997).

As a future direction, an actor-oriented distributed management structure based on multiagent theory may give such a management system more flexibility, changeability, and interoperability; each actor would be a simple element involved in product management, manufacturing, or customer service. Usually the actor is task-related, for example, a manager for product development, a programmer for a driver program development, a customer getting services from a manufacturer, or even a conveyor system, or a proximity sensor in the product life cycle. Each actor in the virtual enterprise has two roles, that is, the service provider in one community and the service seeker in another. As a service provider, the actor describes and advertises its ability with the intention to be discovered by other actors who are seeking partners for a task in their own local community. As a service seeker, the actor is able to decompose the task into a series of subtasks and attempts to find competent partners based on its mental model about the community. Therefore such a virtual enterprise consists of a series of small communities. Each small community has a set of actors involved as a work team, either as service providers or service seekers. A multiagent system can then be constructed to achieve collaborative work between actors during product life cycles. We expect that a distributed PCM system could exhibit the unsupervised learning ability, adaptive ability, competitive ability, and self-organizational ability that often exist in human society.

In the DIECoM project, we have implemented an automatic process model transformation from UML to XPDL based on an XSL stylesheet. As discussed, today there exist several alternative workflow languages. One of the fundamental premises of virtual enterprises is that they must leverage existing methodologies and integrate existing toolsets to have viable uptake. Another significant area for future work is to address automatic model transformation using UML as a Platform Independent Model and to use an XSL stylesheet as a mapping definition to generate any target language. The Model-Driven Architecture (MDA) proposed by OMG (Soley, 2000) is a potential methodology for this purpose. It intends to facilitate the view change from high-level models to variable middleware platforms and enhance model exchangeability. It uses MOF as a metamodel definition standard and defines a metametamodel and a general framework for the integration of various metamodels. The software development process becomes the definition of Platform Independent Models and a mapping from the Platform Independent Models (PIM) to Platform Specific Models (PSM). In terms of its application to business process development, the PIM could be the high-level business model in UML and the PSM could be a workflow model in any target language.


Acknowledgment

This work was funded in part by the European Commission under Framework 5 Project IST 2000-28270 DIECoM. We acknowledge the contribution of all the DIECoM partners, and particularly of our colleagues at Renault. The members of the DIECoM consortium are Alenia, Dassault Systemes, EADS CCR, Glasgow Caledonian University, IBM, Renault, and SIA.


References

AdCoMS consortium (1998). AdCoMS object model, AdCoMS deliverable D4.1.3. Retrieved February 3, 2002, from http://adcoms.finmeccanica.it/nuova_pagina_l.htm

Aniorte, P. (2003). A distributed adaptable software architecture derived from a component model. Computer Standards & Interfaces, 25(3), 275–282.

Bastos, R., Dubugras, D., & Ruiz, A. (2002), Extending UML activity diagram for workflow modeling in production systems. 35th Annual Hawaii International Conference on System Sciences (HICSS'02) 9. Big Island, Hawaii.

Bruno, G., Torchiano, M., & Agarwal, R. (2002). UML enterprise instance models. Proceedings of International Conference on Information Technology (CIT2002). Bhubaneswar, India.

Cabrera, L.G., Fortiz, M.R., & Llorca, J.P. (2001). Formal foundations for the evolution of hypermedia systems. In Technique report UNL-DI-1-2001 ofUniversidade Nova deLisboa, Departamento de Informatica. Retrieved August 6, 2003, from http://prog.vub.ac.be/poolresearch/FFSE/Workshops/FFSE-submissions/Garcia-CabreraEtAl.pdf

Coverpages Technology Reports (2002). STEP/EXPRESS andXML. Retrieved January 15,2004, from http://xml.coverpages.org/stepExpressXML.html

EMPRESS consortium (2002). The EMPRESS Web-site. Retrieved June 10,2003,from http://www.empress-itea.org/

Herbst, J., & Chrysler, D. (1999). Inducing workflow models from workflow instances. In Proceedings of the 6th European Concurrent Engineering Conference, 175–182.

Hwang, S., & Yang, W. (2002). On the discovery of process models from their instances. Decision Support Systems, 34, 41–57.

Jarke, M., Jersfeld, M. A., Peters, P., & Pohl K. (1997). Coordinating distributed organizational knowledge. Data & Knowledge Engineering, 23(3), 247–268.

Jarzabek, S., & Zhang, H. (2001). XML-based method and tool for handling variant requirements in domain models. In Proceedings of5th IEEE International Symposium on Requirements Engineering(RE '01). Toronto, Canada.

Jiang, P., Mair, Q., & Newman, J. (2003) Using UML to design distributed collaborative workflows: From UML to XPDL. In Proceedings of IEEE 12th International Workshop on Enabling Technologies: Infrastructure for Collaborative Enterprises. Linz, Austria.

Jiang, P., Newman, J., Mair, Q., Valfre, E., Calm, J.F., Wiles, C., et al. (2004). Workflow implementation of change lifecycle for product configuration management. 2004 Workflow HandBook, 81–101. Future Strategies, Inc.

Kahl, W. (2001). Software evolution via hierarchical hypergraphs with flexible coverage, In Technique report UNL-DI-1-2001 of Universidade Nova de Lisboa, Departamento de Informatica. Retrieved August 6, 2003, from http://prog.vub.ac.be/poolresearch/FFSE/Workshops/FFSE-submissions/Kahl.pdf

Ketfi, A., Belkhatir, N., & Cunin, P. (2002). Adapting applications on the fly. In The 17th IEEE International Conference Automated Software Engineering. Edinburgh, UK. Retrieved August 6,2003, from http://www-adele.imag.fr/Les.Publications/intConferences/ASE2002Ket.pdf

Kramer, J., & Magee, J. (1990). The evolving philosophers problem: Dynamic change management. IEEE Transactions on Software Engineering, 16(11), 1293–1306.

Lehman, M. M., & Belady, L.A. (1985). Soft evolution: Principles of software change. London: Academic Press.

Lubell, J. (1999). XML representation of process descriptions. Retrieved May 25,2002, from http://ats.nist.gov/psl/xml/process-descriptions.html

Mair, Q., & Haag, Z. (2001) Process model integration in Internet-based virtual software corporations. 4th ICSE Workshop on Software Engineering over the Internet, 23rd International Conference on Software Engineering. Toronto.

Oreizy, P., Richard, M., & Taylor, N. (1998). Architecture-based runtime software evolution. In The International Conference on Software Engineering 1998 (ICSE'98). Retrieved August 6,2003, from http://www.isr.uci.edu/architecture/paperslICSE98.pdf

Orlikowski, W., & Robey, D. (1991). Information technology and the structuring of organizations. Information Systems Research, 2(2), 143–169.

OSGi Alliance (1999). OSGi service gateway specification, release 1.0. Retrieved June 6, 2002, from http://www.osgi.org/

Saven, R.S.A. (in press). Business process modelling: Review and framework. International Journal Production Economics.

Soley, R. (2000). Model-driven architecture. White Paper, Draft 3.2. Retrieved August 6, 2003, from http://www.omg.org

The Workflow Management Coalition (2002). Workflow process definition interface -XML process definition language (Document Number WFMC-TC-1025). Retrieved April 20, 2002, from http://www.wfmc.org/standards/docs/TC-1025_10_xpdl_102502.pdf


Chapter VIII: Rapid Pattern-Oriented Scenario-Based Testing for Embedded Systems

Wei-Tek Tsai,,
Arizona State University,
USA
Ray Paul,,
Department of Defense,
USA
Lian Yu,,
Arizona State University,
USA
Xiao Wei,,
Arizona State University,
USA

Systems change often, and each change requires reverification and revalidation. Modern software development processes such as agile process even welcome and accommodate frequent software changes. Traditionally, software reverification and revalidation are handled by regression testing. This chapter presents a pattern-oriented scenario-based approach to rapidly reverify and revalidate frequently changed software. Key features of this approach are (1) classifying system scenarios into reusable patterns; (2) application of a formal completeness analysis to identify missing scenarios; (3) identifying scenario patterns (SPs) and corresponding verification patterns (VPs) and robustness patterns (RBPs); (4) rapid test script generation by reusing test script templates. This approach is also compatible with formal approaches such as model checking. This approach has been used at industrial sites to test safety-critical medical devices with significant savings in cost and effort. The chapter presents several examples to illustrate the effectiveness and efficiency of this approach.

Introduction

Software systems are subject to changes throughout development, maintenance, and evolution, due to a variety of reasons such as requirement changes (both functional and nonfunctional), technology changes, and hardware or software platform changes (Eick, 2001; Hartmann, 1988; Lehman, 1985; Sugden, 1996; Tsai, 2000; and Wang, 1996). These changes bring risks to the software system because change propagations may introduce new bugs, sometimes even fatal ones. When the software is updated, it is necessary to reverify and revalidate the software with respect to the changed features as well as those features that are supposed to remain unchanged.

Regression testing is often used to reverify and revalidate software systems, and it has been immensely useful (Onoma, 1998). However, it is limited as follows:

  • Regression testing reuses test cases, but existing test cases may not be applicable to verify new features unless the existing test cases are modified.

  • Regression testing is most useful when changes are relatively minor, in other words, there are no structural changes in the program. If the concerned program's structure is drastically changed, many of the existing test cases must be updated before they can be reused for regression testing.

Thus, regression testing may not be suitable for agile software development such as Extreme Programming where the concerned software is still under constant and frequent structural changes (Beck, 1999).

This chapter presents a new pattern-oriented scenario-based approach to rapid and adaptive testing software, even if the software is under constant structural changes as in an agile software development. This approach also complements regression testing; in other words, it can be used together with regression testing. This approach is called Verification Pattern (VP) (Zhu, 2002) and it has been experimented with at several industrial system development sites with significant results. This approach is especially suitable for testing safety-critical and mission-critical embedded systems.

The key concept of VP is that system scenarios can be classified into patterns, and for each scenario pattern (SP), a test script template can be developed for that pattern to test all the scenarios belonging to the same pattern. In other words, test script templates can be reused to verify a large number of system scenarios with minimum incremental cost and effort. Furthermore, if the system is changed, one can use a three-step process to verify the changed system:

  1. identify new and/or changed scenarios in the system;

  2. for each new scenario, see if it can be classified into the existing SPs. If yes, the existing test script template can be reused to test the new scenario. If the new scenario cannot be matched into the existing patterns, either a new pattern can be recognized and/or a new test script needs to be developed; and

  3. for each changed scenario, remove the corresponding existing test script as it is no longer valid, treat the changed scenario as the new scenario, and follow step 2 above.

Thus, this VP approach can potentially save significant cost and effort in verifying systems because test script templates can be reused over and over again, and even during agile development where changes are constant and extensive. However, the critical issue is: For a large industrial application, how many SPs are needed to reasonably cover the system? If it has thousands of patterns, this approach will not be profitable because the cost of identifying patterns, maintaining test script templates, and customizing test script templates for each scenario will make this approach uneconomical. Fortunately as well as surprisingly, for many industrial applications we encountered, especially real-time, safety-critical, mission-critical embedded systems, a large complex system may need only a few patterns! This is true even for a complex industrial system with hundreds of thousands of scenarios. For example,

  • Eight scenarios patterns cover 95% of system scenarios for an industrial safety-critical implantable medical device (Zhu, 2002).

  • Four SPs cover 75% of a real-time ultrareliable communication processor.

Thus, the saving from using this VP approach can be enormous as only a few patterns are needed to cover a significant portion of the system.

This VP approach to testing is also significantly different from the object-oriented (OO) test framework approach popularized by JUnit (JUnit), Cactus (Cactus), and Http Unit (Http Unit). These test frameworks use a lot of design patterns such as Template Method, Strategy, and Composite. However, these design patterns are used in the design of the framework. The patterns used in the VP are identified from system scenarios, and they are not related to OO design patterns. Because SPs are identified from system requirement scenarios only, this approach of testing and verification is actually black-box testing as no design information is used to generate test scripts.

Note that system scenarios describe its intended behavior of the system, and thus test script developed based on these scenarios tests the positive aspect of the system, that is, given a correct input, does the system behave as it is specified? However, it is also necessary to address the negative aspect of the system, that is, given an incorrect input, what does the system do? Is the system robust enough to handle these incorrect inputs? Fortunately, the concept of VP can be reused here:

  • specify the negative aspect of system scenarios;

  • classify these negative scenarios into patterns (called robustness patterns or RBPs); and

  • for each pattern, develop the corresponding test script that can be used to test all the scenarios belonging to the same pattern.

By using both VPs and RBPs, a tester can thoroughly test the system rapidly not only the positive aspects but also negative aspects of the system.

One key issue of software quality via VPs and RBPs is that system scenarios must be reasonably complete. The reason is obvious because this approach will generate a test script for each system scenario, positive or negative, and if a scenario is missing, its corresponding VP or RBP will be missing. To address this problem, this chapter presents a formalized completeness analysis by analyzing relationships in scenarios to identify missing scenarios. This will be described in the section on Completeness Analysis.

Another unique feature of this approach is that system scenarios are formalized, and each scenario has six elements: Actors, Condition, Data, Actions, Timing, and Events (ACDATE). Scenarios formalized in this way can be analyzed by various analyses such as dependency analysis (Tsai, 2003a; Tsai, 2001; Tsai, 2002; Tsai, 2003b; and Tsai, 2003c). This will be presented in the section on Scenario Modeling.

The proposed approach is also compatible with formal model checking [Muller-Olm, 1999; Dwyer, 1999; and SPIN). The scenarios specified can be used to generate the state model automatically (Tsai, 2003), and properties to be checked can be specified using scenarios, and these scenarios can be classified into patterns as well. Each pattern can then be mapped into temporal logic for model checking. This will be presented in the section on Scenario Patterns and Modeling Checking. In this way, the semiformal testing can be combined with formal model checking to ensure the system in a development process if needed.


Pattern-Oriented Work

Pattern-oriented approaches have been popularized by OO design patterns (Gamma, 1994), and a variety of patterns have been proposed such as analysis patterns (Fowler, 1997), architecture patterns (Buschmann, 1996), design patterns (Gamma, 1994), idioms (Coplien, 1992), test patterns, process patterns (Ambler, 1998), event patterns (Luckham, 2002), and testing timing patterns (Vishnuvajjala, 2002).

  • Analysis Patterns. Martin Fowler (Fowler, 1997) defined analysis patterns as "…groups of concepts that represent a common construction in business modeling", and documented several analysis patterns such as Type, Observation, and Measurement patterns.

  • Architecture Patterns. An architecture pattern expresses a fundamental structural organization schema for software systems. It provides a set of predefined subsystems or components, specifies their responsibilities, and includes rules and guidelines for organizing the relationships between them (Buschmann, 1996). The Broker, Blackboard, and Filters and Pipes are examples of patterns in this category. Architectural patterns are a means of documenting architecture for complex and heterogeneous systems, thus helping to manage the application complexity.

  • Design Patterns. A design pattern provides a schema for refining the subsystems or components of a software or the relationship between them (Gamma, 1994). It describes a commonly recurring structure of communicating components that solves a general design problem within a particular context. The Strategy, State, and Proxy patterns are examples from this category.

  • Idioms. An idiom is a low-level pattern specific to a programming language. An idiom describes how to implement particular aspects of components or the relationship between them using the features of a given programming language such as C++, Java, or Smalltalk. An example idiom is Counted Pointer (Coplien, 1992).

  • Test Patterns: Test patterns can be either a commonly practice of testing strategies and design techniques in an OO test framework. For example, regression testing has the following test patterns: Retest all, and Retest Changed Code based on Dependency Analysis. OO test frameworks such as JUnits, Catcus, and Http Unit have numerous test patterns, and one such pattern is to embed test scripts as methods of an object so that they can be called at runtime.

  • Process Patterns: Process pattern describes a collection of general techniques, actions, and/or tasks for developing object-oriented software. It describes what one should do but not the exact details of how one should do something. Ambler (1998) identified three types of process patterns in order of increasing scale: Task process patterns, Stage process patterns, and Phase process patterns.

  • Event Patterns: An event pattern is a template that matches certain sets of events (Luckham, 2002). An event template is an event with variables or constants as parameters. A STRAW-EPL language can be used to specify patterns with three relational operators: and, or, → (causes). A pattern in STRAW-EPL must declare four elements: (1) a list of variables; (2) a list of types of events; (3) a pattern that is a set of event templates together with relationships between the event templates; and (4) a condition on the context of any match.

  • Testing Timing Patterns: Testing timing in real-time embedded systems is difficult because testing must be performed in real time while test events may be generated in a simulated model or replayed from a database. Events may arrive too quickly for the system to react, arrive too slowly (say once every ten years) to test in real time, or arrive out of sequence to confuse the system. Testing timing patterns facilitates testing timing aspects. Patterns such as Peek and Poke pattern (i.e., storing timing information in registers, later retrieved for timing analysis) and Event Tracker pattern (i.e., tagging a unique ID for each event can be used to verify out-of-sequence events) are two example patterns commonly used in testing telecommunication applications (Vishnuvajjala, 2002).

The patterns in this chapter are different from the patterns just described. Even though the patterns in this chapter are used to verify and validate systems, they are not test patterns because these patterns are derived by examining system scenarios directly.


Testing Process

The overall process of applying VPs and RBPs using scenarios is shown in Figure 1. Further details are shown in the following list.

Click To expand
Figure 1: Test process for agile development

  1. Specify scenarios from system requirements. The proposed approach is driven by scenarios, and in this step system requirements are expressed as formalized scenarios. This will be described in the section on Scenario Modeling.

  2. Perform completeness analysis on scenario specifications. This step is critical because the entire process is scenario-driven and the system quality depends critically on the completeness of system scenarios. The results of completeness analysis are missing scenarios or alternative paths of existing scenarios, and they must be added into the specification to ensure completeness. This will be presented in the section on Scenario Modeling.

  3. Classify scenarios into positive scenarios and negative scenarios depending on correctness of input.

  4. Map positive scenarios into scenarios patterns. Even though a system has hundreds of thousands of scenarios, most of these scenarios can be classified into few patterns (Tsai, 2003a; Tsai, 2003b; Zhu, 2002). The section on Scenario Patterns, Verification Patterns, and Robustness Patterns will illustrate the classification of SPs.

  5. Map positive SPs to VPs. The normal execution paths correspond to VPs representing the required functionality of systems under normal situations. The section Scenario Patterns, Verification Patterns, and Robustness Patterns illustrate the VPs.

  6. Generate verification code or test scripts. By reusing the existing test script template for each VP, one can rapidly generate new scripts to test the needed feature. Section on Tool Support and Example show this idea.

  7. Map negative scenarios into negative scenario patterns. It is observed that negative SPs can share the same logic and expression as the positive SPs, except that negative SPs are used to reflect the robustness of the systems. The section Scenario Patterns, Verification Patterns, and Robustness Patterns will illustrate the classification of SPs.

  8. Map negative SPs to RBPs. Scenarios have normal execution paths and abnormal/ exception execution paths. The abnormal/exception execution paths correspond to RBPs. Differentiating VPs and RBPs helps analyze the capability of system robustness, such as responding to abnormal inputs, although both share the same logic. The section on Robustness Patterns illustrates the RBPs patterns.

  9. Generate robustness testing code or test scripts. By reusing the existing test script template for each RBP, one can rapidly generate new scripts to test the abnormal/ exception capability. The section on Tool Support and Example show this idea.


Scenario Modeling

System requirements are usually written in a natural language, which is flexible but difficult to specify in rigorous ways. This chapter uses the ACDATE model to analyze the system requirements and formalize scenarios. The idea is to decompose the system requirements into elements (i. e., Actors, Conditions, Data, Actions, Timing, and Events), and identify the relationships among them.

ACDATE Model

Definition 8.1
Start example

An Actor is a model element that represents a system or environment component with a clear boundary that interacts with other components.

End example

An actor can be a physical or conceptual entity (such as a person, a device, or a customer account) that can initiate an action when receiving external events sent by other actions.

In an OO model, an actor may be an object. A high-level actor can be constructed by composing other actors. An actor often appears as a noun in the system requirements, such as a subject or an object.

Table 1 lists the system requirements for a sample car alarm system. The system monitors and protects the parts of the vehicle: trunk, doors (the driver's door and front passenger's door), engine, and ignition. The inputs to the system include remote controller and car key; the outputs include alarm and actuator (to lock doors automatically). In the requirement SR2 (The alarm system can be turned off by the remote controller), the alarm and remote controller are actors, because the remote controller performs the action turn off, and the alarm is the receiver of an event (turn off signal) sent by the action.

Table 1: Derived scenarios from the system requirement
ID | System Requirements | Pattern[*]
SR 1 | The remote controller can arm the alarm system (Upon triggering the alarm, an alarm horn will sound one "beep", and the alarm is armed) | KDSP
SR 2 | The alarm system can be turned off by the remote controller | BSP
SR 3 | If both doors, trunks and hood are closed, and the driver's door and passenger's door get locked 0.5 second after the alarm is armed | BSP
SR 4 | The alarm horn will not be triggered if the trunk is opened with the key. | BSP
SR 5 | If either of the doors is opened, turning on the alarm makes the alarm horn beep three times (at this time, the operations by the remote controller/car-key are invalid). | KDSP
SR 6 | If either of the doors is opened, switch on the ignition with the car key makes the alarm horn beep three times (at this time, the operations by the remote controller/car-key are invalid) | KDSP
SR 7 | If the doors are closed but unlocked, 10 seconds later, the alarm system will be armed automatically. | BSP
SR 8 | If either one of the doors is open, the alarm won't be armed. | BSP
SR 9 | The alarm system is disarmed by the remote controller, at the same time both driver's and front passenger's doors are unlocked. | BSP
SR 10 | When the driver's door and passenger's door are locked, pressing "unlock" for the first time on remote controller unlocks the driver's door; the second time unlocks the front passenger's door. | ILSP
SR 11 | The alarm system does not sound if one uses the car key to unlocked and open the door. | BSP
SR 12 | The alarm system does not sound if one uses the car key to unlock and open the trunk. | BSP
SR 13 | When the doors are closed but the trunk is opened, if the alarm system is armed, the alarm horn will beep. | KDSP
SR 14 | When the alarm system is turned off (i. e. disarmed) and the engine is started without a key then alarm horn will beep. | KDSP
SR 15 | The alarm horn will be triggered if either one of the doors is unlocked without the key or remote controller. | BSP
SR 16 | The alarm horn will be triggered if the hood is opened without the key. | BSP
SR 17 | The alarm horn will be triggered if the trunk is opened without the key. | BSP
SR 18 | The alarm horn will be triggered if the ignition is switched on while the trunk is open. | BSP
SR 19 | The alarm horn will be triggered if the ignition is switched on while the hood is open. | BSP
[*]The pattern classification will be discussed in details in the section on Scenario Patterns, Verification Patterns and Robustness Patterns.
Definition 8.2
Start example

A condition is a model element that represents an observable state of an actor.

End example

A condition is often used in the decision points in a scenario. In the requirement SR3 ( Table 1) (If the driver door and passenger door, trunk, and hood are closed, the driver's door and passenger's door get locked 0.5 second after the alarm is armed.), "the status of driver door and passenger door, trunk, hood are closed,", and "alarm is armed" are conditions, and they are the decision point for the actors "driver's door" and "passenger's door" to trigger the action "get locked."

Definition 8.3
Start example

A data is a model element that represents variables or constant information for computing or processing.

End example

Data can be continuous or discrete, textual messages, images, voice, or video stream. In SR3 requirement, the first condition involves four kinds of data: "driver door status," "passenger door status," "trunk status," and "hood status," while the second condition only involves data "alarm status."

Definition 8.4
Start example

An action is a model element that represents an operational process to change the internal status of an actor.

End example

An action is triggered by an event under certain conditions (collectively called the precondition of the action). In a functional model, an action is a process, while in an OO model, it is a method.

Requirement SR 10 has two actions: "unlocks the driver's door" and "unlocks the front passenger's door."

Definition 8.5
Start example

Timing is a model element that describes timing attributes of other model elements. Timing constraints is a model element that represents a constraint related to timing.

End example

Specifically, timing is specified on the actions and events of a scenario. Timing constraints on an action include the minimum delay time, deadline, and maximum interval, and timing constraints on events include minimum and maximum delay on event arrivals. Requirement SR 3 specifies the timing constraint "0.5 second."

Definition 8.6
Start example

An event is a model element that represents an observable occurrence with no time duration.

End example

An event may carry data, and it can trigger an action of an actor. Events may be external or internal. External events are those that pass between the system and its environment, whereas internal events are among internal actors of a system. There are four kinds of events: signals, messages, a time of significance, or a state change.

Requirement SR7 "If the doors are closed but unlocked, 10 seconds later, the alarm system will be armed automatically" has an event "10 seconds later," which is a time of significance.

Table 2 and Table 3 show the ACDATE of the car alarm system with 14 actors, 15 conditions, 7 data, 15 actions, 22 events and five timing constraints.

Table 2: Identified events, conditions and actions
Events | Actions | Condition
E1: Turn on the alarm by remote controller E2: Turn off the alarm by remote controller E3: Open the driver's door E4: Close the driver's door E5: Open the passenger's door E6: Close the passenger's door E7: Lock the driver's door with the car key E8: Unlock the driver's door with the car key E9: Lock the passenger's door with the car key E10: Unlock the passenger's door with the car key E11: Lock the doors with the remote controller E12: Unlock the driver's door with the remote controller E14: Unlock the passenger's door with the remote controller E15: Open the trunk with the car key E16: Open the hood with the car key E17: Switch on the ignition with the car key E18: Switch on ignition with car controls E19: Open driver door with car controls E20: Open hood with car controls E21: Open trunk with car controls E22: Open passenger door with car controls | A1: Turn on the alarm A2: Make the horn beep A3: Check the timer A4: Lock driver door A5: Lock passenger door A6: Unlock driver door A7: Unlock passenger door A8: Turn off the alarm A9: Invalidate read operations on remote controller A10: Invalidate read operations on car key A11: Open Driver Door A12: Open Passenger Door A13: Open trunk A14: Open hood A15: Turn on ignition | C1: The driver's door is closed (not locked). C2: The driver's door is open. C3: The driver's door is locked. C4: The passenger's door is closed (not locked). C5: The passenger's door is open. C6: The passenger's door is locked. C7: The trunk is open. C8: The trunk is closed C9: The hood is open. C10: The hood is closed. C11: The alarm is on. C12: The alarm is off. C13: The ignition is on. C14: The ignition is off. C15: The horn is triggered.
Table 3: Timing specification — Constraints
Timing Conditions | Timing
TC1: Time taken to lock driver door | T1: C1 & C4 & C8 & C10 & C11 (0.5 seconds)
TC2: Time taken to lock passenger door | [] A4 & A5
Status of the data is checked in some of the conditions | T2: TC1 || TC2 > 0.5 seconds [] A2
 | T3: C1 & C4 (10 seconds) [] A1

The semantics of ACDATE can be represented as a state transition: if an actor is in the pre-condition, and it receives a triggering event that satisfies the guard condition, it will perform an action and change its state to the post-condition. The action performed may generate events sent to other actors. This is illustrated in Figure 2.

Click To expand
Figure 2: Decomposition of scenario specification

A scenario "when driver door is locked and passenger door is locked, if remote controller is pressed unlock, then the driver door is open" can be specified using Scenario Specification Language as in Figure 3.

Click To expand
Figure 3: Scenario specification language

Scenario Relationship

Identifying the relationships among the ACDATE elements helps perform completeness and consistency (C&C) analysis. Let CAPre be the pre-condition of actor A; E be the event(s). The following relationships may exist, thereafter called "related" relationship:

  • Conditions belonging to the same pre-condition: If two conditions are in the same scenario, they are related to each other.

  • Mutually exclusive conditions: Two conditions are mutually exclusive if they cannot be satisfied at the same time. For example, if the conditions represent values of a data variable, they are mutually exclusive. Usually, the mutually exclusive conditions are in different paths of a scenario.

  • Precondition and triggering events: The relationship between the precondition CAPre and the events E exists. The transition in Figure 2 will be fired when CAPre and E are evaluated to be true. Note that the pre-condition includes actor A's local conditions of actor A and guard conditions.


Completeness Analysis

The completeness analysis on scenario specification is based on the relationships in scenarios (Tsai, 2003). Another approach is based on automated simulation (Tsai, 2003), and this approach can be combined with relationship approach to identify missing scenarios. The completeness problem can now be stated: Given the combinations of conditions and events (representing the relationship on mutually exclusive, precondition-triggering events, and aggregated conditions/events), identify the missing C-E combinations regarding all the conditions and events.

This chapter introduces two algorithms to perform C&C analysis. The following symbols will be used in the algorithms:

  1. C: set of conditions.

  2. E: set of events;

  3. M: set of condition pairs that are mutually exclusive (such as C1 and ! C1);

  4. {C-E}s: set of condition-event combinations that have been specified. Assume {C-E}s has no mutually exclusive combinations.

Completeness Analysis Check Algorithm 1

Algorithm 1:

The algorithm of completeness analysis is as follows:

  1. Computer all the combinations of C, concatenate each event in E with each of the condition combination and obtain C-E combinations.

  2. Subtract the mutually exclusive combinations in C-E.

  3. Subtract {C-E}s from C-E, and obtain the missing C-E combinations: C-E\{C-E}s.

  4. Report the missing C-E combinations and calculate the coverage: |{C-E}s|/|C-E|.

Algorithm 1 Evaluation:

Algorithm 1 is applied to the Car Alarm example, which has five data variables, 12 conditions, and 13 events. It generated 547 missing C-E combinations out of 936 totals in 0.265 sec running on Windows XP on a PC. Algorithm 1 works well for small systems.

However, when it was applied to a large Industrial Control System (ICS) (which has 15 data variables, 16 conditions, and 24 events), it generated 392, 704 missing C-E combinations out of 786, 432 total and took 9.906 seconds for computation.

It is interesting to observe that the number of data variables increased only 3 times, but runtime increased 37.4 times. In other words, the increase is not linear.

Table 4 and Table 5 show the sample missing scenarios identified in the Car Alarm system.

Table 4: Missing scenarios (for normal situations)
ID | Requirement
.AS20 | When turn off the alarm by remote controller and at the same time unlock the doors with the remote controller, the alarm will be turned off and both doors will be unlocked.
AS21 | When turn on the alarm by remote controller and at the same time switch on the ignition with the car key, CAS should handle this case.
AS26 | When the driver's door is closed or locked and turn off the alarm by remote controller, CAS should handle this.
AS28 | When the passenger's door is closed or locked and turn off the alarm by remote controller, CAS should handle this.
AS29 | When the driver's door is open and switch off the ignition with the car key, the ignition should be switched off normally.
AS30 | When the driver's door is closed or locked and switch off the ignition with the car key, the ignition should be switched off normally.
AS31 | When the passenger's door is open and switch off the ignition with the car key, the ignition should be switched off normally.
AS32 | When the passenger's door is closed or locked and switch off the ignition with the car key, the ignition should be switched off normally.
Table 5: Missing scenarios (for abnormal/exceptions)
ID | Requirement
AS22 | When turn on the alarm by remote controller and at the same time switch off the ignition with the car key, CAS should report error.
AS23 | When turn off the alarm by remote controller and at the same time switch on the ignition with the car key, CAS should report error.
AS24 | When turn off the alarm by remote controller and at the same time switch off the ignition with the car key, CAS should report error.
AS25 | When the driver's door is open and turn off the alarm by remote controller, CAS should report error.
AS27 | When the passenger's door is open and turn off the alarm by remote controller, CAS should report error.

Completeness Analysis Check Algorithm 2

Algorithm 1 performs C&C analysis by enumerating all the C-E combinations. It is useful when a system has few C-E combinations. Algorithm 2 is a heuristic algorithm, and it is useful when a system is loosely coupled.

Algorithm 2:

  1. Partition {C-E}s into disjoint sets P1, P2,…Pk, (Pi ∩ Pj = Φ, 1 ≤ i, j ≤ k; i ≠ j) such that every condition or event that belongs to Pi cannot be in any other Pj.

  2. For each of the disjoint set Pi:

    1. Computer all combinations of Ci-Ei that are similar to the first step in Algorithm 1.

    2. Subtract the mutually exclusive combinations from Ci-Ei combinations.

    3. Use step 3 of Algorithm 1 to identify the missing C-E combinations.

  3. Ask the user to evaluate if Pi and Pj are indeed disjoint in terms of "related" relationship, if not, merge any Pi and Pj and repeat step 2 until all the evaluation is completed.

An important point of this algorithm is that a user must be involved to validate the results, because this is a heuristic algorithm. The heuristic used in this algorithm is that "If condition i is related to condition j, and condition j is related to condition k, then condition i is related to condition U". In this case, it is possible to partition the original C-E combinations into disjoint sets, and only identify those missing combinations in those disjoint sets; thus the number of missing scenarios can be greatly reduced. Note that if Algorithm 2 cannot partition the C-E combinations into disjoint components, Algorithm 2 and Algorithm 1 will produce the same results, and this is the worst case performance for Algorithm 2.

Algorithm 2 Evaluation:

Algorithm 2 is applied to the Car Alarm example, and initially two disjoint sets P1 and P2 are obtained; the number of missing C-E combinations (511 for P1, and one for P2) identified for each set is shown in Table 6. However, during validation, it is observed that the condition "AlarmIsOff" in P2 is related to condition "AlarmIsOn" in P1 Thus, P1 and P2 must be merged together. In this case, Algorithm 2 will produce identical results to Algorithm 1, and no saving was achieved by the heuristic. This is unfortunate but expected because the Car Alarm system is tightly coupled and it is difficult to decouple the system. It is also too small for the C-E combinations to be divided into disjoint components. This will not be true for large industrial applications.

Table 6: Iteration of completeness analysis
Iterations | Iteration 1 |  | Iteration 2
Partitions | P1 | P2 | P
# of Conditions | 11 | 1 | 12
# of Data Variables | 5 | 1 | 5
# of Events | 12 | 1 | 13
# of C-E Combinations | 864 | 2 | 936
# of Original C-E Combinations | 353 | 1 | 389
# of Missing C-E Combinations | 511 | 1 | 547
Table 7: Completeness analysis
 | Results
Partitions | P1 | P2 | P3 | P4 | P5 | P6 | P7 | P8
# of Conditions | 1 | 3 | 1 | 1 | 6 | 1 | 1 | 2
# of Events | 1 | 1 | 6 | 7 | 3 | 1 | 3 | 2
# of C/E Combinations | 2 | 8 | 12 | 14 | 192 | 2 | 6 | 8
# of Original C/E Combinations | 1 | 4 | 11 | 13 | 65 | 1 | 3 | 6
# of Missing C/E Combinations | 1 | 4 | 1 | 1 | 127 | 1 | 3 | 2

Algorithm 2 was then applied to a large industrial process control system. The number of C-E combinations produced by Algorithm 1 was 768,432, but the total number of C-E combinations produced by Algorithm 2 was reduced to 616 and partitioned into seven disjoint components. The user also validated that it is not necessary to merge any two disjoint components. Thus, Algorithm 2 reduced the C-E combinations significantly, or precisely (768432-616)/768432 = 99.92% reduction!

Another interesting fact is that Algorithm 2 will need less time to perform the computation. Specifically, for the Car Alarm example, Algorithm 2 needs about 135 milliseconds using a PC ( Table 6) for the Car Alarm example (compared with 265 milliseconds needed for Algorithm 1). For the ICS, Algorithm 2 needs 23 milliseconds, but Algorithm 1 needs 9.906 seconds, or ((9906-23)/9906) = 99.77%!


Scenario Patterns, Verification Patterns, and Robustness Patterns

The behavior specification of real-time systems often can be classified into patterns that include pre-conditions (or causes) and post-conditions (or effects) with timing constraints as an option. This section gives the definitions and examples of SP, VP, and RBS.

Scenario Patterns

A scenario pattern (SP) is defined as a specific temporal pattern or cause-effect relations that can be used in representing a number of requirements. A timeline is used to depict the temporal relations of the events involved in the SP.

Eight SPs that cover 95% of an implantable medical device are shown in the following table. SPs are used to classify requirements into groups. Each of the SPs will be further described in the following subsections.

Table 8: Scenario patterns and percentages
Pattern | Coverage
Basic SP (BSP) | 40
Key-event driven SP (KDSP) | 15
Timed key-event driven SP (TKDSP) | 5
Key-event driven time-sliced SP (KDTSSP) | 7
Command-response SP (CRSP) | 8
Lookback SP (LBSP) | 6
Mode-switch SP (MSSP) | 8
Interleaving SP (ILSP) | 6
Total Coverage | 95

In Table 1, the third column lists the scenario patterns identified in the car alarm system. The Basic scenario pattern covers 68% identified system scenarios, and three patterns (Basic pattern, Key-Event Driven pattern, and Interleave pattern) cover all the identified system scenarios.

An SP is described by four notations:

  • Description and purpose

  • Example/Attribute

  • Figure illustration

  • Remark (optional)

Verification Patterns

A VP is a pre-defined verification mechanism that can be used to verify a group of positive scenarios with identical control flow. Similarly, an RBP is a pre-defined verification mechanism that can be used to verify a group of negative scenarios with identical control flow. A VP or an RBP is described by three notations:

  • Description and purpose

  • Class diagram (for the requirement representation)

  • Verification State Machine (representing the verification logic)

Basic Scenario Pattern:

  • Description: Whenever pre-condition A holds, post-condition B becomes true within T period of time.

    Click To expand
    Figure 4: Basic scenario pattern

  • Example: "When a threshold test is initiated by command, the firmware shall request the TEMPORARY brady state within 4080ms."

  • Remarks: This pattern is used extensively in practice.

Basic Verification/Robustness Pattern:

  • Description: The basic VP is used to verify the requirements that can be represented using the basic SP. It is a common VP in the real-time requirement verification. It has a single pre-condition and post-condition, and an optional timeout.

Click To expand
Figure 5: Basic verification pattern
Click To expand
Figure 6: Verification state machine

Key-Event Driven Pattern Scenario Pattern:

  • Description: Whenever A occurs, Q1, Q2,…, Qi must occur sequentially before T1, and R1, R2, …, Rm must occur sequentially between T1 and T2.

  • Example: If a command is received to terminate an atrial burst in progress, then firmware shall perform the following sequence in order when the next cycle interrupt occurs:

    • Set the free_AV bit of reg_bpc_cmd to False,

    • Set reg_bpc_mode to OAO+ OVO if VVI backup pacing is disabled,

    • Set reg_bpc_mode to OAO+ VVI if VVI backup pacing is enabled,

    • Terminate the ATP burst when the next ventricular event occurs.

  • Remark: After the keyevent occurs, a pre-specified time interval is partitioned into many small slices (t1, t2, …, tn). Each of the post-conditions (Q1, …, Qi, R1, …,Tm) of this pattern is expected to see in a certain interval.

Key-Event Driven Verification/Robustness Pattern:

  • Description: In the key-event-driven VP, each requirement normally has a list of results that are expected upon the occurrence of the key event. The results in this list are checked one after another. If timed out during the checking of any result, the verifier will report fail. Only when all the result items are verified in the listed order, can one consider the requirement to be successfully verified.

Click To expand
Figure 7: Key-event driven scenario pattern
Click To expand
Figure 8: Key-event driven verification pattern
Click To expand
Figure 9: Verification state machine
Click To expand
Figure 10: Timed key-event driven scenario pattern

Timed Key-Event Driven Scenario Pattern:

  • Description: Within the duration t1 after the key event, if P event, then R event is expected before t2.

  • Example: If within the 30 second period required to change the TachyMode to OFF, SystemMagnetApplied becomes cleared for less than two seconds, the firmware shall still change Tachy Mode to OFF after the original 30 seconds have expired.

  • Remark: Timed key-event-driven requirement pattern requires a duration after the key event occurs. In this pattern, the pre-condition is a combination of the key event and the event P that occurred during the specified duration (t1).

Click To expand
Figure 11: Timed key-event driven verification pattern
Click To expand
Figure 12: Verification state machine

Timed Key-Event Driven Verification/Robustness Pattern:

  • Description: The timed key-event-driven VP is used to verify requirements that can be represented using the timed key-event-driven SP. It provides an interface to decide if the duration is expired.

Key-event Driven Time-Sliced Scenario Pattern:

  • Description: Whenever A occurs, Q1, Q2,…, Qi must occur sequentially before T1, and R1, R2, …, Rm must occur sequentially between T1 and T2.

  • Example: When a brady cardiac cycle occurs, the firmware shall perform the steps specified in the CARDIAC CYCLE PROCESSING table ( Table 9).

    Table 9: Scenario patterns and percentages

    Order

    Action Group

    Time Slice

    1

    Update brady work parameters

    10ms

    2

    Change brady state if required

    5ms

    3

    Update XL information

    10ms

    4

    Update behavioral and period assignment parameters

    10ms

    5

    Update sensing parameters

    5ms

    6

    Update hardware registers if required

    5ms

    7

    Reset the cardiac cycle event parameters

    5ms

  • Remark: After the keyevent occurs, a pre-specified time interval is partitioned into many small slices (t1, t2, …tn). Each of the post-conditions (Q1, …, Qi, R1,…., Tm) of this pattern is expected to see in a certain interval.

Click To expand
Figure 13: Key-event driven time-sliced scenario pattern

Key-event driven Time-sliced Verification/Robustness Pattern:

  • Description: The verification logic starts waiting for the keyevent of the requirement. When the keyevent occurs, it starts checking results for the time slices one by one. During the verification process, if timed out for any slice, the requirement is considered failed.

Command-Response Scenario Pattern:

  • Description: If a command A is not aborted by B within T1, then response C must be done before T2.

  • Example: The Commanded Shock Action commands shall be illegal and a defib_backup error response code returned if ‘BatteryStatus’ is EOL.

    Click To expand
    Figure 14: Key-event driven time-sliced verification pattern

    Click To expand
    Figure 15: Verification state machine

    Click To expand
    Figure 16: Command-response scenario pattern

  • Remark: A command can be aborted. The abortion should occur within the specified timeout to effectively abort the on-going command. Otherwise it would be too late.

Command-Response Verification/Robustness Pattern:

  • Description: The verification logic of the command-response pattern includes a composite state that contains two sub-states: Check for Command Validity and Check for Response. The verification process will exit to Check for Command state anytime it detects an aborting.

Click To expand
Figure 17: Command-response verification pattern
Click To expand
Figure 18: Verification state machine
Click To expand
Figure 19: Look-back scenario pattern
Click To expand
Figure 20: Look-back verification pattern

Look-Back Scenario Pattern:

  • Description: Prior to event K, condition C1, C2, … Cn must be met.

  • Example: Prior to charging for the first induction pulse the firmware shall

    • Set reg_hv_phlpw to Oxnn to setup for a x.x ms pulse (includes circuit delays),

    • Set waveform in reg_hv_dlvr_mode to mono,

    • Set fib in reg_hv_dlvr_mode.

Click To expand
Figure 21: Verification state machine

Look-Back Verification/Robustness Pattern:

  • Description: The verifier of the look-back pattern starts with checking whether the key event occurred. Once it sees the key event, it records its time and turns to the checking of those look-back conditions. The verifier reports success if all the look-back conditions occurred within the specified time constraint. Otherwise it will report failure.

Mode-Switch Scenario Pattern:

  • Description: Whenever A occurs, B and C must become true before T.

  • Example: For example, in maintenance mode, an elevator could reach certain floors for maintenance that it would not go to during normal operation mode. A pacemaker only delivers therapy in therapy mode, not in monitor mode.

    Click To expand
    Figure 22: Mode-switch scenario pattern

    Click To expand
    Figure 23: Mode-switch scenario pattern

    Click To expand
    Figure 24: Verification state machine

  • Remark: Mode is a most commonly used technique in real-time embedded systems to categorize functionalities that apply in certain application contexts. With mode specified in a requirement, the designer of the system can easily find out what rules are applicable or what functions are available to each mode.

Mode-Switch Verification/Robustness Pattern:

  • Description: For the mode switch, the verification process verifies the applicability and availability of each of the features in the list. The requirement is considered verified when all the features in the list are verified.

Interleave Scenario Pattern:

  • Description: Whenever A occurs, if C doesn't occur, B must become true; otherwise, D must become true.

  • Attributes: Three important attributes of the interleaving pattern are

    • Verification intervals of the requirements of an interleaving pattern always intersect with each other.

    • The pre-conditions of the requirements are independent of each other.

    • The post-condition of at least one of the requirements is dependent on the occurrence of the pre-condition and post-condition of another requirement.

  • Remark: Interleaving requirement pattern allows us to verify requirements that have pre-conditions and post-conditions interleaved with each other.

Interleave Verification/Robustness Pattern:

  • Description: Whenever a pre-condition occurs, the verification process moves to the state that verifies the corresponding post-condition and the pre-condition of another requirement.

Click To expand
Figure 25: Interleave scenario pattern
Click To expand
Figure 26: Interleave verification pattern
Click To expand
Figure 27: Interleave verification pattern


Robustness Patterns

Robustness Patterns

Note that scenarios illustrated in the section on Scenario Patterns, Verification Patterns, and Robustness Patterns specify the positive aspects of the system requirements; that is, the expected functionality of the systems under specified situations; for example S1: "If either of the doors is opened, turning on the alarm makes the alarm horn beep three times". However it is necessary to check what the system will do if an incorrect input is given, for example, "When the passenger's door is open and turn off the alarm by remote controller, CAS should report error." Using the symbols, the two scenarios can be written as:

  • S1: [C1 (driver's door is opened) OR C2 (passenger's door is opened)] AND E1 (turning on the alarm) then A1 (make the horn beep three times)

  • S2: [C1 OR C2] AND !E1 (turning off the alarm) then A2 (report error)

Table 10 summarizes all the combinations of the premise. Combinations 1, 3, 5, and 7 are positive scenarios; the rest are negative. S1 covers 1, 3, and 5; S2 covers 2, 4, and 6; while 7 and 8 should be covered by other scenarios. It is observed from Table 24 that S2 can be obtained by negating elements of the premise of if-then. S1 can be classified into Key-event -driven SP. S2 has the same logic as S1 except that in S2, the key event is an abnormal one in Figure 19 and Figure 9.

Table 10: Combination of elements in premise
 | C1 | C2 | E1 | Positive/Negative | Scenarios
1 | T | T | T | Positive | S1
2 | T | T | F | Negative | S2
3 | T | F | T | Positive | S1
4 | T | F | F | Negative | S2
5 | F | T | T | Positive | S1
6 | F | T | F | Negative | S2
7 | F | F | T | Positive | Other Scenario
8 | F | F | F | Negative | Other Scenario

The RBP corresponding to negative SP in Figure 28 is expressed using state machine and is shown in Figure 29. It is observed that the RBP shares the same logic as corresponding VP except that the key-event is an abnormal event, and it verifies if the abnormal event handlings work correctly.

Click To expand
Figure 28: Negative scenario pattern
Click To expand
Figure 29: Robustness pattern for negative key-event driven scenario pattern

Table 11 summarizes the eight RBPs corresponding to the negative SPs.

Table 11: Robust scenario patterns
Basic RBP | It shares the same logic as the Basic VP, except that the precondition is an abnormal situation regarding to the requirement. The post-condition reflects the capability to handle the invalid precondition. For example, the exception-handling scenarios identified in Table are all classified into Basic RBP.
Key Event Driven RBP | It shares the same logic as the Key-event driven VP. Upon the abnormal event occurrence, a series of exception handling events (R1,…,Rn) are expected to happen with the pre-specified order.
Timed key-Event Driven RBP | It shares the same logic as the Timed key-event driven VP, except that the key-event K and the event P are either or both abnormal regarding to the requirement; and event R is the exception handler.
Key-event Driven Time-sliced RBP | It shares the same logic as the key-event driven time-sliced VP. After the abnormal event occurs, a pre-specified time interval is partitioned into many small slices (t1, t2, … tn). Each of the post-conditions (Q1, …, Qi, R1, …, Tm) that handle the exceptions is expected to see in a certain interval.
Command-Response RBP | It shares the same logic as the command-response VP. An abnormal command can be aborted. The abortion should occur within the specified timeout to effectively abort the on-going abnormal command. Otherwise it would be too late and be handled by R.
Look-back RBP | It shares the same logic as the look-back VP. When abnormal event occurs, check back a series of conditions beforehand.
Mode-Switch RBP | It shares the same logic as the Mode-Switch VP. When the system is in abnormal mode, check the handling applicability and availability
Interleave RBP | It shares the same logic as the Interleave VP. Normal pre-conditions of one scenario and abnormal post-conditions are interleaved with each other, check the exception handling.

The Relationship between Completeness Analysis and Pattern Classification

This section summarizes the relationship between completeness analysis and pattern classification. Based on the completeness analysis, each scenario belong to three groups: (1) in the original set of scenarios; (2) originally missing, but identified by completeness analysis, and are positive; and (3) originally missing, but identified by completeness analysis, and are negative. The first two groups of scenarios are both positive scenarios.

  • The positive scenarios are mapped to SPs and further to VPs for verification test script generation.

  • The negative scenarios are mapped to SPs as well and further to RBP for robustness test script generation.

Table 12 and Table 13 show the missing intended scenarios and missing negative scenarios, which are classified into SPs, VPs, and RBP, correspondingly.

Table 12: Missing intended scenarios
ID | Requirement | SP Matching | VP Matching
AS 20 | When turn off the alarm by remote controller and at the same time unlock the doors with the remote controller, the alarm will be turned off and both doors will be unlocked. | Basic SP | Basic VP
AS 21 | When turn on the alarm by remote controller and at the same time switch on the ignition with the car key, CAS should handle this case. | Key-event Driven SP | Key-event Driven VP
AS 26 | When the driver's door is closed or locked and turn off the alarm by remote controller, CAS should handle this. | Key-event Driven SP | Key-event Driven VP
AS 28 | When the passenger's door is closed or locked and turn off the alarm by remote controller, CAS should handle this. | Basic SP | Basic VP
AS 29 | When the driver's door is open and switch off the ignition with the car key, the ignition should be switched off normally. | Basic SP | Basic VP
AS 30 | When the driver's door is closed or locked and switch off the ignition with the car key, the ignition should be switched off normally. | Basic SP | Basic VP
AS 31 | When the passenger's door is open and switch off the ignition with the car key, the ignition should be switched off normally. | Key-event Driven SP | Key-event Driven VP
AS 32 | When the passenger's door is closed or locked and switch off the ignition with the car key, the ignition should be switched off normally. | Key-event Driven SP | Key-event Driven VP
Table 13: Missing negative scenarios
ID | Requirements | SP Matching | RBP Matching
AS 22 | When turn on the alarm by remote controller and at the same time switch off the ignition with the car key, CAS should report error. | Basic SP | Basic RBP
AS 23 | When turn off the alarm by remote controller and at the same time switch on the ignition with the car key, CAS should report error. | Basic SP | Basic RBP
AS 24 | When turn off the alarm by remote controller and at the same time switch off the ignition with the car key, CAS should report error. | Basic SP | Basic RBP
AS 25 | When the driver's door is open and turn off the alarm by remote controller, CAS should report error. | Key-Event Driven SP | Key-Event Driven VP
AS 27 | When the passenger's door is open and turn off the alarm by remote controller, CAS should report error. | Key-Event Driven SP | Key-Event Driven VP


Tool Support and Example

This section illustrates test script generation from scenarios using VPs and RBPs. This process is now supported by a tool E2E. Table 16 shows four scenarios with two triggering events:

  • E1 — "turn on the alarm by remote controller"

  • E2 — "switch on the ignition with the car key"

The first two scenarios S1 and S2 are positive as they represent intended features of the system, but the last two scenarios S3 and S4 are negative as they address incorrect inputs and the handling of these incorrect inputs. The four scenarios can be specified with the ACDATE model using the E2E tool ( Figure 30).

Click To expand
Figure 30: Scenario specification

The four scenarios were actually mapped to Basic VP and Basic RBP as shown in Figure 31. The tool provides the SP description (the left side screenshot) and the figure illustration (the right side screenshot).

Click To expand
Figure 31: Description and illustration of Basic scenario pattern

Figure 32 shows the code templates for Basic SP and the VP. Instead of developing the test scripts line-by-line, the tester needs only to replace the parameters ce1 and ce2 in the template with actual parameter, for example, S1 with E1 and !E2, and S2 with !E1 and E2. This can be done similarly for RBPs.

Click To expand
Figure 32: Code templates for Basic scenario pattern and verification pattern


Evaluation of Verification Patterns

The VP and RBP approach to rapidly test embedded systems has many advantages over conventional verification approaches, namely:

Table 14: Examples of basic pattern
ID | Scenarios | Input | Positive/Negative | SP | VP/RBP
S1 | When turn on the alarm by remote controller and at the same time switch off the ignition with the car key, the ignition should be switched off and the alarm should be turned on | E1 and !E2 | Positive | Basic Pattern | Basic VP
S2 | When turn off the alarm by remote controller and at the same time switch on the ignition with the car key, the alarm should be turned off and the ignition is turned on | !E1 and E2 | Positive | Basic Pattern | Basic VP
S3 | When turn on the alarm by remote controller and at the same time switch on the ignition with the car key, horn will beep three times | E1 and E2 | Negative | Basic Pattern | Basic RBP
S4 | When turn off the alarm by remote controller and at the same time switch off the ignition with the car key, CAS should handle this exception | !E1 and !E2 | Negative | Basic Pattern | Basic RBP

  • A complex system can be rapidly tested by using few VPs and RBPs. This leads to a significant reduction in the cost and effort of verification.

  • Testers can take advantage of verification framework to handle requirement changes even if the rate of changes is high.

  • The VPs and RBPs can be used to test timing bugs when timing constraints are incorporated into the VPs.

  • The VPs and RBPs can be applied in both online and off-line basis.

  • The VPs and RBPs, like OO design patterns, can be catalogued and used in different projects even in different application domains.

This pattern-based approach has been used at Guidant with significant results. It reduced testing effort from 25% to 90% depending on the experience level of engineers involved and the kind of changes ( Table 15).

Table 15: Case study
 |  |  | Experienced |  |  | Not experienced
Data contributor |  |  | Group A | Group B | Group C | Group D | Group E
 |  |  | Experienced in existing testing system | Experienced in the verification framework | Experienced in existing testing system and migrating to the frame work | Learning existing testing system | Learning the verification framework
Process used |  |  | Process X | Process Y | Process Y | Process X | Process Y
Learning curve | Domain knowledge |  | Proficient | Proficient | Proficient | Novice | Novice
 | Testing Techniques |  | Proficient | Proficient | Novice | Novice | Novice
Productivity | New Requirement |  | 40(10 ∼ 50) | 10(4∼50) | 16(4∼50) | 90(80∼100) | 66(50∼100)
 | Requirement Changes | Timing Change1 | 6(2∼10) | 4(2∼8) | 6(2∼10) | 20(8∼40) | 14(8∼20)
 |  | Action Change2 | 30(10∼50) | 20(4∼50) | 25(4∼50) | 54(30∼100) | 36(20∼100)
 |  | Sequence Change1 | 27(10∼40) | 8(4∼20) | 10(4∼20) | 42(20∼60) | 20(10∼40)

Another evidence of productivity gain is in terms of test code needed to test the same system. The VP approach reduced on average the code size from 1380 lines of code (LOC)/scenario to 143, or about 89.6% reduction ( Table 16). For example, if the system under test has only 100 scenarios (a small system), the test code using the existing approach will have 138K LOC, but using the VP approach, the test code will have only 14.3K. Assuming an average test engineer needs one week to develop a test code of 1,000 LOC, the existing approach will need about 34.5 person-months to complete the task, but the VP approach will need only about 3.5 person-months to complete the same task, a saving of 30.9 person-months. Table 16 shows the efforts of using VP versus the conventional approach. If the system has 1,000 scenarios, the saving will be 309 person-months. The saving will be even more significant for large applications. Figure 33 shows that the productivity gain and saving in cost and effort are significant, especially for middle and large software systems.

Table 16: Verification framework effectiveness
 | Feature Group 1 (BdyPCNG) | Feature Group 2 (DiagACPT)
No. of Requirement Items | 99 | 114
Use Verification Framework | No | Yes
Lines of Code (.h) | 60211 | 6200
Lines of Code (.cpp) | 76412 | 10100
Total Lines of Code | 136623 | 16300
LOC/Requirement | 1380 | 143
Click To expand
Figure 33: Effort savings due to application of verification patterns

Furthermore, the test code developed using the conventional approach will vary from one scenario to another depending on the engineers involved, whereas the design using VP will be much more consistent because the same verification code tests all the scenarios belonging to the same SP. The consistency in the test code will save significant time in debugging, and we observed that 70% of system testing effort is actually spent on debugging test code during embedded system testing.


Scenario Patterns and Modeling Checking

Current trends in formal specifications and verification have included model checking using finite-state models. Model checking typically checks properties on a state model using temporal logic. Common model checking involves three activities:

  1. development of a state model for the concerned system;

  2. specification of properties to be checked using temporal logic;

  3. checking the specified properties using the state model.

It is possible to generate a state model from system scenarios directly by simulation (Tsai, 2003), and SPs can be used to quickly map into temporal logic such as Linear Temporal Logic (LTL). Specifically, Table 17 shows how various scenario patterns can be mapped into LTL. In this way, it is possible to generate the LTL formula for model checking quickly by using VPs and RBPs.

Table 17: LTL formula for the scenario patterns
Scenario Patterns (SP) | LTL Formula
Basic SP: whenever pre-condition A holds, post-condition B becomes true within T period of time | [](A →∼ B∪T)
KD SP: whenever pre-condition A holds, post-condition B and C becomes true within T period of time | [](A →∼ T∪(B& ∼ T & o(∼ T ∪ C)))
TKD SP: Within the duration T1 after the key event, if P then R is expected (before T2). | [](A → (∼ T1 ∪ P)& o(∼ T2 ∪ R))
KDT SP: After the key-event occurs, a pre-specified time interval is partitioned into many small slices (t1,t2,…tn). Each of the post-conditions (Q1,…,Qi,R1,…,Rm) is expected to see in a certain interval. |
CR SP: After a command A does not be aborted B within T1, then response C must be done before T2. | [](A → (∼ T1 ∪ B) ⊕ (T2 ∪ C))
LB SP: Prior to event A, condition C1, C2, … Cn must be met. | [](A → (∼ A ∪(C1& ∼ A & o(∼ A ∪ C2))))
MS SP: whenever mode-switch event A occurs, applicability B and availability C become true within T period of time. | [](A →∼ T ∪ (B& ∼ T & o(∼ T ∪ C)))
IL SP: If pre-condition A holds, post-condition B becomes true only if event C does not occurs, otherwise, post-condition D becomes true. |


Conclusion

This chapter presents rapid pattern-oriented scenario-based testing for agile software development. The approach overcomes the difficulties that regression testing cannot handle, such as new features and systems that are under frequent and structural changes. By using a pattern-oriented approach, it is possible to generate test scripts rapidly to test large and complex systems efficiently and effectively. The proposed techniques have been used at industrial sites to test safety-critical medical devices with significant reduction of test effort and cost while even maintaining and improving the test efficiency and effectiveness.


References

Active Database Central, URL: http://www.ida.his.se/ida/adc/

Agrawal, H., Morgan, J.R., Krauser, E.W., & London, S.A. (1993). Incremental regression testing. Proceedings of the Conference on Software Maintenance, 348–357.

Ambler, S.W. (1998). Process patterns: Building large-scale systems using object techniques. Cambridge University Press/SIGS Books.

Bai, X., Tsai, W.T., Paul, R., Feng, K., & Yu, L. (2001). Scenario-based modeling and its applications to object-oriented analysis, design, and testing. IEEE Proceedings of Enterprise Distributed Object Computing Conference (EDOC). 140–151.

Bates S., & Horwitz, S. (1993). Incremental program testing using program dependence graphs. Proceedings of 20th ACM Symposium of Principles of Programming Languages, 384–396.

Beck, K. (1999). Extreme programming explained: Embrace change. Addison-Wesley.

Binkley, D. (1997). Semantics guided regression test cost reduction. IEEE Transactions on Software Engineering, 23(8), 498–516.

Booch, G., Rumbaugh J., & Jacobson, I. (1999). The unified modeling language user guide. Addison Wesley.

Buschmann, F., Meunier, R., Rohnert, H., Sommerlad, P. & Stal, M. (1996). Pattern-oriented software architecture: A pattern system. Boston: Addison-Wesley.

Cactus project, http://jakarta.apache.org/cactus/index.html

Chen, Y.F., Rosenblum, D.S., & Vo, K.P. (1994). TestTube: A system for selective regression testing. Proceedings of 16* International Conference on Software Engineering, 211–222.

Coplien, J.O. (1992). Advanced C++programming styles and idioms. Addison-Wesley.

Dwyer, M.B., Avrunin, G.S., & Corbett, J.C. (1999). Patterns in property specifications for finite-state verification. Proceedings of the 21st Inter national Conference on Software Engineering.

Eick, S.G., Graves, T.L., Karr, A.F., Matron, J.S., & Mockus, A. (2001). Does code decay? Assessing the evidence from change management data. IEEE Transactions on Software Engineering, 27(1), 1–12.

Fowler, M. (1997). Analysis patterns: Reusable object models. Boston: Addison-Wesley.

Gamma, E., Helm, R., Johnson, R., & Vlissides, J. (1994). Design patterns: Elements of reusable object-oriented software. MA: Addison Wesley.

Gupta, R., Harrold, M.J., & Soffa, M.L. (1992). An Approach to regression testing using slicing. Proceedings of the Conference on Software Maintenance, 299–308.

Harrold, M.J., & Soffa, M.L. (1988). An incremental approach to unit testing during maintenance. Proceedings of The Conference on Software Maintenance, 362–367.

Hartmann, J., & Robson, D.J. (1988). Approaches to regression testing. Proceedings of the Conference on Software Maintenance, 368–372.

HttpUnit. http://httpu.nit.sourceforge.net/

Jones, C. (1996). Software change management. Computer, 29(2), 80–82.

JUnit.org. http://www.ju.nit.org/index.htm

Lehman, M.M., & Belady, L.A. (1985). Program evolution: Processes of software change. Academic Press.

Leung, H.K.N., & White, L. (1989). Insights into regression testing. Proceedings of the Conference on Software Maintenance, 60–69.

Luckham, D. (2002). The power of events: An introduction to complex event processing in distributed enterprise systems. Addison-Wesley.

Muller-Olm, M., Schmidt, D., & Steffen, B. (1999). Model-checking: A tutorial introduction. In A. Cortesi, & G. File (Eds.), Proceedings of Static Analysis Symposium (SAS'99), 1694, Venice, Italy, 330–354. Heidelberg: Springer-Verlag.

Onoma, A.K., Tsai, W.T., Poonawala, M., & Suganuma, H. (1998). Regression testing in an industrial environment. Communications of the ACM, 41(5), 81–86.

Rothermel, G., & Harrold, M. J. (1996). Analyzing regression test selection techniques. IEEE Transactions on Software Engineering, 22(8), 529–551.

SPIN: at http://spinroot.com/spin/whatispin.html

Sugden, R.C., & Stens, M.R. (1996). Tactics and methods for handling change. Proceedings of 1996 IEEE Symposium and Workshop on Engineering of Computer-Eased System, 457–463.

Tsai, W.T., & Paul, R. (2003). Adaptive scenario-based object-oriented test frameworks for testing embedded systems. International Test and Evaluation Association (ITEA) Journal.

Tsai, W.T., Bai, X., Paul, R., & Yu, L. (2001). Scenario-based functional regression testing. Proceedings of IEEE Annual International Computer Software and Applications Conference (COMPSAC), 496–501.

Tsai, W.T., Bai, X., Paul, R., Devaraj, G., & Agarwal, V. (2000). An approach to modify and test expired window logic. Proceedings of First Asia-Pacific Conference on Quality Software, 99–108.

Tsai, W.T., Mojedehbakhsh, R., & Zhu, F. (1998). Ensuring system and software reliability in safety-critical systems. Proceedings of 1998 IEEE workshop on Application-Specific Software Engineering Technology, ASSET, 98, 48–53.

Tsai, W.T., Paul, R., Cao, Z., Yu, L., Saimi, A., & Xiao, B. (2003). Verification of web services using an enhanced UDDI server. Proceedings of IEEE Workshop on Object-oriented Real-time Dependable Systems (WORDS), 131–138.

Tsai, W.T., Paul, R., Shao, W., Rayadurgam, S., & Li, J. (1999). Assurance-based Y2K testing. Proc. 4th IEEE International Symposium on High-Assurance Systems Engineering, 27–34.

Tsai, W.T., Paul, R., Yu, L., Saimi, A., & Cao, Z. (2003). Scenario-based web service testing with distributed agents. Institute of Electronics, Information and Communication Engineers (IEICE) Transaction, E86-D (10), 2130–2144.

Tsai, W.T., Yu, L., Liu, X., Saimi, A., & Xiao, Y. (2003). Scenario-based test generation tool for embedded systems. Proceedings of IEEE International Performance Computing and Communications Conference (IPCCC), 335–342.

Tsai, W.T., Yu, L., Paul, R., Fan, C., Liu, X., & Cao, Z. (2003). Rapid scenario-based simulation and model checking for embedded systems. Proceedings of 7th International Association of Science and Technology for Development (IASTED) International Conference on Software Engineering and Applications (SEA). 568–573.

Tsai, W.T., Yu, L., Paul, R., Liu, T., & Saimi, A. (2002). Developing adaptive test frameworks for testing state-based embedded systems. Proceedings of 6th World Conference on Integrated Design & Process Technology (IDPT).

Tsai, W.T., Yu, L., Saimi, A., & Paul, R. (2003). Scenario-based object-oriented test frameworks for testing distributed systems. Proceedings of IEEE Future Trends of Distributed Computing Systems, 288–294.

Tsai, W.T., Yu, L., Zhu, F., & Paul, R. (2003). Rapid verification of embedded systems using patterns. Proceedings of IEEE Annual International Computer Software and Applications Conference (COMPSAC), 466–471.

Tsai, W.T., Zhu, F., Yu, L., Paul, R., & Fan, C. (2003). Verification patterns for rapid embedded system verification. Proceedings of 2003 International Conference on Embedded Systems and Applications, 310–316.

Tsai, W.T., Zhu, F., Yu, L., Paul, R., & Fan, C. (2003). Verification patterns for rapid embedded system verification. Proceedings of International Conference on Embedded Systems and Applications (ESA), 310–316.

Vishnuvajjala, R. (2002). Software reuse in time-critical systems. Ph.D. Dissertation, Dept. of Computer Science and Engineering, University of Minnesota, Minneapolis, MN.

Wang, Y., Tsai, W.T., Chen, W.P., & Rayadurgam, S. (1996). The role of program slicing in ripple effect analysis. Proceedings of Software Engineering and Knowledge Engineering, 369–376.

White, L., & Leung, H.K.M. (1992). On the edge, regression testing. Proceedings of the 25th Annual International Symposium on Microarchitecture, 12(2), 81–84.

White L.J., Narayanswamy, V., Friedman, T., Kirschenbaum, M., Piwowarski, P., & Oha, M. (1993). Test manager: A regression testing tool. Proceedings of the Conference on Software Maintenance, 338–347.

Yau, S.S., & Kishimoto, Z.Z. (1987). Amethod for revalidating modified programs in the maintenance phase. IEEE Annual International Computer Software and Applications Conference (COMPSAC), 272–277.

Zhu, F. (2002). A requirement verification framework for real-time embedded systems. PhD dissertation, Department of Computer Science and Engineering, University of Minnesota, Minneapolis.


Chapter IX: Developing a Software Testing Ontology in UML for a Software Growth Environment of Web-Based Applications

Hong Zhu,,
Oxford Brookes University,
UK
Qingning Huo,,
Lanware, Ltd.,
UK

This chapter introduces the concept of software growth environments to support sustainable long-term evolution of Web-based application systems. A multiagent prototype system is designed and implemented with emphasis on software testing. In this environment, software tools are agents that cooperate effectively with each other and human testers through communications at a high level of abstraction. New tools can be integrated into the system with maximal flexibility. These are achieved through the design and utilisation of an ontology of software testing that represents the knowledge of software engineering and codifies the knowledge for computer processing as the contents of an agent communication language. The ontology is represented in UML (Unified Modeling Language) at a high level of abstraction so that it can be validated by human experts. It is also codified in XML (Extensible Markup Language) for computer processing to achieve the required flexibility and extendibility.

Introduction

The Internet and Web are becoming a distributed, heterogeneous, and hypermedia computation platform, which stimulates many new progresses in software applications, see, e.g., Crowder, Wills and Hall (1998). However, Web-based applications are complex and difficult to develop and maintain. In Zhu et al. (2000), we argued that most Web-based applications are by nature evolutionary, and we proposed a growth model of software process. To support the sustainable evolutionary development of Web-based systems, we designed a multiagent architecture of software development and maintenance environment, and developed a prototype system for testing Web-based applications. A key feature of the architecture and the prototype system is the use of an ontology of software testing to facilitate the communications between agents, human developers and testers. In this chapter, we report the development of the ontology of software testing and its representation in UML.

The remainder of the chapter is organised as follows. The next section, Background and Motivations, gives the motivation of our research and briefly outlines our approach to the development and maintenance of Web-based applications. The structure and features of the multiagent software environment are described. A prototype system for testing Web-based applications is presented. Then the section on, Ontology of Software testing, reports the ontology of software testing and its representation in UML. Then we discuss the uses of the ontology in the prototype systems. The final section concludes the chapter with a discussion of related works and directions for future research.


Background and Motivations

Characteristics of Web-Based Applications

According to Lehman and Ramil (2001), software systems can be classified into three types according to what correctness means to the system. An S-type program is required to satisfy a prestated specification. For such a system, correctness is the absolute relationship between the specification and the program. A P-type program is required to form an acceptable solution to a stated problem in the real world. The correctness of a P-type program is determined by the acceptability of the solution to the stated problem. An E-type program is required to solve a problem or implement an application in a real world domain which often has no clearly stated specification. Correctness here is determined by the program's behaviour under operational conditions and judged by the users. Obviously, many kinds of Web applications such as e-commerce, enterprise portal, Web-based CRM systems, e-government, e-science, and so forth, belong to the E-type, where problems are not clearly stated and the correctness of the system is judged by the users for its fitness to their purposes.

Different types of software systems tend to demonstrate different evolutionary behaviours because their development processes are dominated by different types of uncertainties. Generally speaking, there are three types of uncertainties associated with software development (Lehman, 1990). Gödel-like uncertainties arise because software systems and their specifications are models of the real world. The representations of such models and their relationships are Gödel incomplete. Consequently, the properties of a program cannot be completely known from the representations. Heisenberg-type uncertainties result from the processes of using the system that may change the user's perception and understanding of the application. A common phenomenon in the development of software systems is that the users are uncertain about the requirements, but they are often certain that "I'll know it when I see it" (Boehm, 2000). Uncertainties of this type exhibit themselves in the form of changing requirements either in the form of unsatisfactory of implemented or to be implemented functional or non-functional requirements, or the emergence of new requirements. Pragmatic uncertainties are due to the problems in actually performing the development activities. Software development is still a process that relies on human performance. During this process, errors are made and faults are introduced. Many types of risks in software development are caused by this type of uncertainty. For example, the adaptation of a new development method, the use of a new software tool or programming language, the use of a new library of software code, and so on, may introduce uncertainties to the quality of the product and the development process.

Although these sources of uncertainties are associated with all software development projects, Gödel and Heisenberg types of uncertainties have strong impact on E-type software in general and Web-based applications in particular. However, pragmatic uncertainty also plays a significant role in the development of Web-based applications as Web technology has been changing rapidly in the past few years. Consequently, Web based applications commonly demonstrate a clear evolutionary life cycle. During the evolution process, uncertainties are clarified through developing and adjusting the model of the problem, revising the representation of the models, updating users' requirements, and correcting errors of development activities. In the meantime, new uncertainties may emerge and require further development and maintenance. Lehman characterised E-type systems' evolution processes by eight laws of evolution (Lehman & Ramil, 2001), which are summarised in Table 1. These laws should be equally applicable to Web-based applications. In addition, in the investigation of Web-based applications, we also observed a common phenomenon of Web-based systems; that is, Web-based systems commonly contain components developed using different technology, such as component codes written in different languages and executed on different platforms, data represented in different formats, interfaces designed to comply with different standards, interactions proceeded in different protocols, and so forth. We call this phenomenon the law of diversity, which is also listed in Table 1 together with Lehman's laws.

Table 1: Laws of evolution of e-type systems
Law | Description
Continuing Change | E-type systems must be continually adapted else they become progressively less satisfactory in use.
Increasing Complexity | As an E-type system is evolved its complexity increases unless work is done to maintain or reduce it.
Self Regulation | Global E-type system evolution processes are self regulating.
Conservation of Organisational Stability | Unless feedback mechanisms are appropriately adjusted, average effective global activity rate in an evolving E-type system tends to remain constant over product lifetime.
Conservation of Familiarity | In general, the incremental growth and long-term growth rate of E-type systems tend to decline.
Continuing Growth | The functional capability of E-type systems must be continually increased to maintain user satisfaction over the system lifetime.
Declining Quality | The quality of E-type systems will appear to be declining unless they are rigorously adapted, as required, to take into account changes in the operational environment.
Feedback System | E-type evolution processes are multilevel, multiloop, multiagent feedback systems.
Diversity | An E-type system contains components that are developed using a diversity of techniques and integrated into the system at different times.

Lehman's laws were proposed on the bases of his observations on E-type software systems that had survived after a long evolutionary process. They can be considered as ‘survival guidelines’ for the evolutionary development of E-type software systems. Violating these laws in the development of an E-type software system may mean a death penalty to the system. Here, the death of a software system should be understood in Peter Naur' sense (1992) that the state of death become visible when demands for modifications of the program cannot be intelligently answered, although the program may continue to be used for execution and provide useful results.

Software Growth Process Model And Growth Environment

From Lehman's theory of software evolution, we can see that clarifying uncertainties is the driving force of E-type software evolution. Therefore, the development of an E-type software system is best to be a process of growth in functionality. Tool supports must be provided to manage the complexity and quality of the product during its whole lifetime. Figure 1 depicts a growth model of software life cycles of Web-based applications. As argued in Zhu et al. (2000), this process is suitable for the development of Web-based applications. It also has a number of advantages, which include reducing time pressure on the developers, minimizing development risks, offering learning opportunities to developers, improving communications between developers and users as well as various other stakeholders, and so forth.

Click To expand
Figure 1: The growth model of software life cycle

To support sustainable long-term evolutionary development of Web-based applications with a growth strategy, we proposed a new type of software environments and designed an architectural structure for their implementations.

Figure 2 depicts the architecture of software environments, which consists of a number of cooperative agents.

Click To expand
Figure 2: Architecture of software growth environment

The architecture of software growth environment consists of the following types of agents. Development service agents provide developers with various supports to the evolution of software systems in the growth strategy. They fulfil the functions that support evolutionary development of Web-based applications. Management agents are agents that manage agents and are responsible for the following tasks.

  1. Registration. When a new agent is added into the system, information about its functionality, capability, execution environment, and so forth, is registered with a management agent. When an agent is deleted from the system, its registration information is updated.

  2. Task allocation. A management agent receives service requests as well as development and maintenance task requests. When such a task is requested, it searches for an appropriate agent and assigns the task to the agent through a task allocation protocol.

  3. Monitoring and recording behaviours of agents and the system. The management agents will monitor the progress of each task and record the state and outcomes of each task. They will also monitor and record the behaviour of each service agent for the optimisation of future task allocation.

These agents may also interact with the application system and its components to obtain data and knowledge of the application and their evolution histories in order to support their future evolutions. The interactions between human developers and the agents may also be through a set of interface agents that provide assistance to each individual developer to communicate with the development tools and to access the data and knowledge of the application system at a high level of abstraction. Ideally, the application system consists of a number of application service agents that provide the services and functionality of the application system to its users.

This architecture significantly differs from existing software development environments such as CASE (Computer Assisted Software Engineering) tools and run-time support environments such as middleware due to the following two features. Because of these features, it is called software growth environment.

First, tools that support the development and maintenance of a system run in the same environment as the software system. They coexist with the system monitoring the evolution process of the system and supporting the modifications of the system. Moreover, they grow with the system as new tools are integrated into the environment when new functional components of the application are developed using new technology and integrated into the system. The relationship between the tools and the system is similar to the relationship between a tree and its natural environment where it is growing, and between a human and his/her social environment that changes as the person is growing up.

Second, the tools (that is, agents) in the environment collect, store, and process the information about the system and the knowledge of software development, and present such knowledge to human beings or other software tools at a high level of abstraction when requested. Such information and knowledge includes: (a) the structure of the system, the functionality, versions, evolution history, and configurations of the system components, and so forth; (b) the capability, performance, and operational conditions of each development and application service agent, as well as interrelationships between them; (c) the knowledge about software development processes, logical and temporal relations between development tasks and how tasks are decomposed into subtasks, and so forth.

Obviously, the key to the success of such a software growth environment is the mechanisms that enable software tools flexibly integrated into the system gradually and enables tools to cooperation with each other effectively. This can only be achieved by using agent technology and a well-developed ontology and representing the ontology in a highly flexible and extendable format to enable the collaboration between the agents.

A Prototype System for Testing Web-Based Applications

To demonstrate the feasibility and advantages of the proposed approach, we designed and implemented a prototype with emphasis on quality assurance and testing.

As shown in Figure 3, the environment consists of a number of agents to fulfil various testing tasks for Web-based applications. These agents can be distributed to different computers, for example, as in Figure 3, on an application server, a test server, and a client. In fact, agents can be freely distributed according to any specific configuration. They can also be mobile and change their location at runtime. The agents that have been implemented for testing Web-based applications are described briefly here. More details can be found in Huo, Zhu, and Greenwood (2003).

Click To expand
Figure 3: Structure of the prototype system for testing Web-based applications

GWP (Get Web Page) agents retrieve Web pages from a Web site. Two agents of this type have been implemented. One is GWP-No-Cache, whose function is to fetch the Web page of a given URL, and return the page's contents. Another is GWP-Cache. which has the same functionality as GWP-No-Cache, but with cache ability. It uses a knowledge base to store downloaded Web pages, and uses the last modification time to determine whether the Web page is updated on the cached copy.

WPI (Web Page Information) agents analyse the source code of a Web page and extract various useful information from the source code. The information includes the page title, metainformation, hyperlinks, and so forth. They also store the information about the Web page's structure in a knowledge base. When a Web page's structural information is requested, a message is sent to a GWP agent with an HTML source file as the content of the message. It runs an HTML parser on the file and extracts information of the structure of the file from the parser. If the input page is unmodified since last retrieval, the WPI agent just uses the cached data in the knowledge base.

WSS (Web Site Structure) agents analyse the hyperlink structure of a Web site and generate a directed graph to describe the structure. This structure is also stored in a knowledge base to share with other agents.

TCG (Test Case Generator) agents generate test cases to test a Web site according to certain testing criteria. Currently, three agents are implemented for node coverage, link coverage, and linear independent path coverage criteria, respectively. Details of these test criteria for hypertext applications can be found in Jin, Zhu, and Hall (1997).

TCE (Test Case Executors) agents execute test cases and generate execution results. Two TCE agents are implemented. One is to run the test cases interactively in front of the human tester with the aid of a testing assistant agent. The other is to play back a recorded test sequence. This is often used in regression testing.

TO (Test Oracles) agents verify whether a test result matches a specification. Different types of test results require different kinds of oracles. For each type of result data, one agent is designed and implemented. Some simply compare the test output with the results from previously recorded tests. Some examine whether or not the test output satisfies a certain condition, such as if the structure matches a certain pattern. These patterns can be predefined, or generated automatically from previous tests, or defined by software engineers.

TA (Testing Assistants) agents are user interface agents that assist human testers in the process of testing. They communicate at a high level of abstraction and in a language that is understandable by human testers based on the ontology. They provide help to human testers on various testing tasks. For example, they get test requirements from the human users, send correctly formatted messages to TCG to generate test cases, present the generated test cases to the user, guide the user to walk through the links in a Web site to test each Web page on the test cases, collect human tester's feedback on the validity of tested pages, record testing history, and generate testing reports.

WSM (Web Site Monitor) agents monitor the changes on Web sites and generate new testing tasks according to these changes.

An ontology of software testing is developed and codified in XML for the communications between agents. The following section gives details of the ontology and its uses in the prototype system.


Ontology of Software Testing

Generally speaking, ontology defines the basic terms and relations comprising the vocabulary of a topic area as well as the rules for combining terms and relations to define extensions to the vocabulary (Uschold & Gruninger, 1996). It is widely recognised that ontology can be used where domain knowledge specification is useful (Staab & Maedche, 2001). For example, ontology can be used in the communications between people and information systems. It can also be used to improve interoperability between systems, such as translation of modeling methods, paradigms, languages, and software tools. It can also be used in systems engineering, for example, to achieve reusability, shareability, search, reliability, specification, and knowledge acquisition (Neches et al., 1991; Uschold & Gruninger, 1996; Staab & Maedche, 2001). Ontology can be used in a multiagent system as a means for agents to share knowledge, to transfer information and to negotiate their actions. For example, Fox and Gruninger (1994) proposed using ontology to represent agent activities in a cooperative information system. The advantage of using ontology in such a system is that ontology provides a standard specification of concepts in the specific domain. All agents that understand the ontology can participate in the system. Although ontology has been an active research area in the past decade, there is no ontology reported in the literature for software engineering purposes. In this section, we report our work on designing an ontology of software testing (Huo, Zhu, & Greenwood, 2002).

A number of ontology modeling methods have been proposed in the literature. The most widely used traditional approaches include the Knowledge Interchange Format (KIF) (National Committee for Information Technology Standards), description logic, and object-oriented modeling, as in UML (Cranefield, Haustein, & Purvis, 2001). In recent years. XML is more and more used as the format to represent ontology and as a format of agent communication languages. XML has a very simple syntax. It is customisable, extensible, and most importantly, suitable for Web-based applications. The users can define the tags and formats to represent both simple concepts and complex structures.

These tags and formats form a formal knowledge representation language. For these reasons, XML is used in our system to codify the ontology for computer processing. However, an XML representation of ontology is at a rather low level of abstraction. It does not support the validation of the ontology by domain experts. Therefore, we need a representation of ontology at a higher level of abstraction. As a powerful modeling language, UML has the advantage of representing the concepts and relationships at a high level of abstraction that are readable and understandable to human beings so that the knowledge represented in the ontology can be validated by domain experts. Therefore, in addition to the representation of the ontology in XML at the machine processing level, we also represent the structure and relationships of the concepts and relations of the ontology in UML. In this chapter, we focus on the UML representation. The XML Schema Definition (XSD) of the XML representation is given in the Appendix.

Taxonomy of Testing Concepts

Taxonomy is a way to specify and organize domain concepts. We divide the concepts related to software testing into two groups: the basic concepts, and compound concepts. As shown in Figure 4, there are six types of basic concepts related to software testing, which include testers, context, activities, methods, artefacts, and environment.

Click To expand
Figure 4: Basic concepts of software testing

For each basic concept, there may be a number of subconcepts. For example, a testing activity can be the generation of test cases, the verification of test results, the measurement of test adequacy, and so forth. A basic concept may also be characterized by a number of properties, which are the parameters of the concept. For example, a software artefact is determined by (a) its format, such as HTML file, JavaScript, and so forth, (b) its type, such as a program, or a test suite, and so forth, (c) its creation and revision history, such as who and when created the artefact, and who and when revised it, and the version number of the artefact, and so forth, (d) the location where the artefact is stored, and (e) the data, that is, the contents, of the artefact. The following briefly discusses each type of the basic concepts.

  1. Tester. A tester refers to a particular party who carries out a testing activity. A tester can be a human being, a software tool (including software agents), or a team, which consists of one or more testers. This structure is represented in UML as shown in Figure 5.

    Click To expand
    Figure 5: The concept of testers

    A tester team contains a number of testers, which can be individuals or subteams, and has a leader, which is an attribute that gives the name of the leader of the team. An important attribute of tester is capability, which describes what a tester can do. The concept of capability is a compound concept that must be defined on the bases of other basic concepts of software testing. It is discussed in the next subsection.

Example 9.1
Start example

The following is an example of a human tester named Howard represented in XML.

<TESTER TESTER_TYPE="HUMAN" TESTER_NAME="Howard" />

The following is an example of a test team that consists of Joe as the leader and a software agent as a member.

<TESTERTESTER_TYPE="TEAM"TESTER_NAME="ATEAM"TESTER_LEADER="JOE">
   <TESTER TESTER_TYPE="HUMAN" TESTER_NAME="JOE" />
   <TESTER TESTER_TYPE="SOFTWARE"TESTER_NAME="ANAGENT" />
<TESTER>
End example

  2. Context. Software testing activities occur in various software development stages and have different testing purposes. For example, unit testing is to test the correctness of software units at the implementation stage. Integration testing is to verify the interface between software units at the integration stage. The context of testing in the development process determines the appropriate testing methods as well as the input and output of the testing activity. Typical testing contexts include unit testing, integration testing, system testing, regression testing, and so on.

  3. Activity. There are various kinds of testing activities, including test planning, test case generation, test execution, test result validation and verification, test coverage measurement, test report generation, and so on.

    Click To expand
    Figure 6: The concept of test context

    Click To expand
    Figure 7: The concept of test activity

  4. Method. For each testing activity, there may be a number of testing methods applicable. For instance, applicable unit testing methods include structural testing, fault-based testing, and error-based testing. Each test method can also be classified into program-based and specification-based. There are two main groups of program-based structural testing methods: control-flow methods and data-flow methods.

    The control-flow methods include statement coverage, branch coverage, and various path coverage criteria, and so forth; see Zhu, Hall, and May (1997) for a survey of research on software testing methods. These concrete testing methods are instances of various subclasses of testing methods. The structure of the concept of testing methods is shown in UML in Figure 8.

    Click To expand
    Figure 8: The concept of test method

  5. Artefact. Each testing activity may involve a number of software artefacts as the object under test, intermediate data, testing result, test plans, test suites, test scripts, and so on. There are different types of objects under test, such as source code in programming languages, HTML files, XML files, embedded images, sound, video, Java applets, JavaScript, documents, and so forth. Testing results include error reports, test coverage measurements, and so forth. Each artefact is also associated with a location where the artefact is stored, the data, that is, the contents, of the artefact, and a history of creation and revision, which includes the creator, update-time, version numbers, and so forth.

    Click To expand
    Figure 9: The concept of artefact

  6. Environment. The environment in which testing is performed is also an important issue in software testing. Information about the environment includes hardware and software configurations. For each hardware device, there are three essential fields, including the device category, the manufacturer, and the model. For the software component, there are also three essential fields: the type, product name, and version.

    Click To expand
    Figure 10: The concept of test environment

Compound Concepts

Compound concepts are those defined on the bases of basic concepts, for example, testing tasks and agent's capability. They are defined as follows:

  1. Capability. The capability of a tester is determined by the activities that a tester can perform together with the context for the agent to perform the activity, the testing method used, the environment to perform the testing, the required resources (i.e., the input) and the output that the tester can generate.

Example 9.2
Start example

The following is an example of capability description in XML. The agent is capable of doing node coverage test case generation in the context of system testing of hypertext applications represented in HTML.

<CAPABILITY>
      <CONTEXT CONTEXT_TYPE="SYSTEM_TEST"/>
      <ACTIVITY ACTIVITY_TYPE="TEST_CASE_GENERATION"/>
      <METHOD METHOD_NAME="NODE_COVERAGE_TESTING"/>
      <CAPABILITY_DATA CAPABILITY_DATA_TYPE="INPUT">
            <ARTEFACT ARTEFACT_TYPE="OBJECT_UNDER_TEST"
                              <ARTEFACT_FORMAT="HTML"/>
      </CAPABILITY_DATA>
      <CAPABILITY_DATA CAPABILITY_DATA_TYPE="OUTPUT">
            <ARTEFACT ARTEFACT_TYPE="TEST_SUITE"
                        ARTEFACT_FORMAT="NODE_SEQUENCES"/>
      </CAPABILITYDATA>
</CAPABILITY>
End example
Click To expand
Figure 11: The compound concept of capability
Click To expand
Figure 12: The compound concept of task

  2. Task. A testing task consists of a testing activity and related information about how the activity is required to be performed, such as the context to give the purpose of the testing activity, the specific testing method to use, the environment in which the activity must be carried out, the available resources, and the requirements on the test results. It can be represented by the following UML class diagram.

Notice that the class diagram for the concept of task is very similar to the diagram for the concept of capability. However, the semantics of the concepts are different.

Example 9.3
Start example

The following is an example of testing task that requires generating test cases according to the node coverage criterion for the HTML pages at the URL http://www.brookes.ac.uk.

<TASK>
<CONTEXT CONTEXT_TYPE="SYSTEM_TEST"/>
<ACTIVITY ACTIVITY_TYPE="TEST_CASE_GENERATION"/>
<METHOD METHOD_NAME="NODE_COVERAGE_TESTING"/>
 <TASK_DATA TASK_DATA_TYPE="INPUT">
  <ARTEFACT ARTEFACT_TYPE="OBJECT_UNDER_TEST"
      ARTEFACT_FORMAT="HTML">
        <ARTEFACT_LOCATION>http://www.brookes.ac.uk
      </ARTEFACT_LOCATION>
     </ARTEFACT>
   </TASK_DATA>
</TASK>
End example

Notice that not all combinations of basic concepts make sense. For example, the node coverage method cannot be applied to a media file, such as images, sound or videos. A weakness of XML is that it provides very limited power to restrict such illegal combinations.

Basic Relations

Relationships between concepts play a significant role in the management of testing activities in our multiagent system. We identified a number of relationships between basic concepts as well as compound concepts.

Basic relations between basic concepts form a very important part of the knowledge of software testing. They must be stored in a knowledge-base as basic facts. This type of knowledge is listed below.

  1. Subsumption relation between testing methods. A testing method A subsumes method B, if the application of method A always achieves a test adequacy that is adequate according to method B. The subsumption relation has been intensively investigated in software testing literature; see Zhu, Hall, and May (1997) for a survey.

  2. Compatibility relation between artefacts' formats. An artefact format A is compatible with artefact format B, if they are of the same type and the format of A is compatible with B in the sense that if a tester understands the format of A, it implies that the tester also understands the format of B.

  3. Enhancement relation between environments. An environment A is an enhancement of environment B if a testing task can be performed in environment B, it implies that it can also be performed in environment A. Assume that an enhancement relation is defined on software and hardware components. The enhancement relation between environments can be defined formally as follows. Let environments A and B consist of sets {a1, a2,…an} and {b1, b2,…bm} of hardware and software components, respectively. A is an enhancement of B, if and only if, for all bp i=1, 2, …, m, there is one component aj ∊ {a1, a2,…, an} such that ai is an enhancement of bj.

  4. Inclusion relation between test activities. A test activity A may include a number of more basic activities. For example, the test execution activity may include the derivation of test driver and/or test stubs, the installation of test tools, and so forth. A test activity can be completed only if all the subactivities are completed.

  5. Temporal ordering between test activities. To fulfil a test task, a number of test activities must be carried out in certain temporal order. For example, the generation of test cases must be carried out before test execution.

These relations are all partial orderings. That is, they are transitive and reflexive. Figure 13 summarises these basic relations.

Click To expand
Figure 13: Basic relations on testing concepts

Based on these basic facts and knowledge, more complicated relations can be defined and used through knowledge inferences. The following are definitions of the most important ones.

The MorePowerful Relation on Capability

The relation MorePowerful is defined between two capabilities. Let C represent the set of all capabilities. For all c1, c2 ∊ C, we say that c1 is more powerful than c2, write MorePowerful(c1, c2), if and only if all of the following statements are true:

  1. c1 and c2 have the same context,

  2. c1 and c2 have the same activity,

  3. The method of c1 subsumes the method of c2,

  4. The environment of c2 is an enhancement of the environment of c1,

  5. For all input artefacts a1 of c1, there is at least one input artefact a2 of c2 that a1 is compatible with a2, and

  6. For all output artefacts a2 of c2, there is at least one output artefact a1 of c1 that a2 is compatible with a1.

Informally, MorePowerful(c1, c2) means that a tester has capability c1 implies that the tester can do all the tasks that can be done by a tester who has capability c2. In UML, the MorePowerful relation is an association class; see Figure 14 for its structure.

Click To expand
Figure 14: Compound relations

It is easy to prove that the MorePowerful relation is also a partial ordering.

Theorem 9.1: (Reflexiveness)
Start example

∀c∊C. MorePowerful(c, c).

End example
Theorem 9.2: (Transitiveness)
Start example

∀c1, c2, c3 ∊ C. MorePowerful(c1, c2) ○ MorePowerful(c2, c3) →; MorePowerful(c1, c3).

End example

The Contains Relation on Test Tasks

The relation Contain is defined between two tasks. Let T represent the set of all tasks. For all t1 and t2 ∊ T, we say that task t1 Contains t2, write Contain (t1, t2), if and only if all of the following conditions are true.

  1. Task t1 and t2 have the same context;

  2. The activity of t1 includes the activity of t2,

  3. The method of t1 subsumes the method of t2;

  4. The environment of t1 is an enhancement of the environment of t2;

  5. For all input artefacts a2 of t2, there is at least one input artefact a1 that a2 is compatible with a1;

  6. For all output artefact a2 of t2, there is at least one output artefact a1 of t2 that a2 is compatible a1.

Informally, Contain(t1, t2) means that accomplishing task t1 implies accomplishing task t2. Similar to the relation MorePowerful on capabilities, the Contains relation is also an association class and can be similarly represented in UML; see Figure 14.

The Contain relation is also a partial ordering. That is, we have the following property of the relation.

Theorem 9.3: (Reflexiveness)
Start example

∀ t ∊ T, Contain(t, t).

End example
Theorem 9.4: (Transitiveness)
Start example

∀ t1, t2, t3 ∊ T, Contain(t1, t2) ○ Contain(t2, t3) → Contain(t1, t3).

End example

The Matches Relation Between Tasks And Capabilities

In the assignment of a testing task to a tester, a broker agent must answer the question whether the task matches the capability of the tester. For example, assume that an agent is registered as capable of generating statement coverage test cases for Java Applets and a test task is requested for structural testing a Java Applet. The broker agent needs to infer that the agent is capable of fulfilling the task. Therefore, it is necessary to define the following Matches relation between a capability and a task.

For any c∊ C and t∊ T, we say that capability c matches task t, write Match(c, t), if and only if all of the following conditions are true.

  1. Capability c and task t have the same context;

  2. The activity of c includes the activity of t;

  3. The method of c subsumes the method of t, or the method of t is an instance or a subclass of the method of c;

  4. The environment of t is an enhancement of environment of c;

  5. For all artefacts ac in the input artefact set of C, there exists at least one artefact at in the input artefact of t, such that a1 is compatible with ac;

  6. For all artefact at in the output artefact set of t, there exists at least one artefact ac in the output artefact of c, such that ac is compatible with at.

Match(c, t) means that a tester with capability c can fulfil the task t. The following properties of the relations form the foundation of the inferences that the broker agent requires in the assignment of testing tasks.

Theorem 9.5
Start example

∀ c1, c2 ∊ C, ∀ t ∊ T, MorePowerful(c1, c2)○ Match(c2, t) → Match(c1, t).

End example
Theorem 9.6
Start example

∀ c ∊ C, ∀ t1, t2 ∊ T, Contain(t1, t2) ○ Match(c, t1) → Match(c, t2).

End example

Figure 14 shows the structures of compound relations.


Uses of the Software Testing Ontology

In this section, we discuss how the ontology is used in our multiagent system.

Communication Protocols and Task Scheduling

In a multiagent system, many agents can play a similar role but with different specialities. As discussed in the previous section, in our system, agents that play the same role may have different capabilities, are implemented with different algorithms, execute on different platforms, and are specialised in dealing with different formats of information. The agent society is dynamically changing; new agents can be added into the system and old agents can be replaced by a newer version. This makes task scheduling and assignment more important and more difficult as well. Therefore, management agents are implemented as brokers to negotiate with testing service agents to assign and schedule testing activities to testing service agents. Each broker manages a registry of agents and keeps a record of their capabilities and performances. Each service agent registers its capability to a broker when joining the system. Tests tasks are also submitted to the brokers. For each task, the broker will send it to the most suitable agent using the Match relation as a means of inferences. The following paragraphs describe the communication protocols and mechanisms for capability registration and testing task submission.

Combining Ontology with Speech-Act

In a multiagent society, a clearly defined semantics is necessary for agents to express their intensions and commitments to tasks. For example, when an agent sends a message to a broker, it must make the intension of the message clear to register their capabilities or to submit a test job request, or to report a test result, and so forth. Such intensions can be represented as illocutionary forces of the message. As in Singh (1993, 1998), illocutionary forces can be classified into seven types: assertive, directive, commissive, permissive, prohibitive, declarative, and expressive.

To incorporate illocutionary forces in our agent communications, we associate each message with a speech-act parameter. Hence, messages have the following structure in UML.

The following example is a typical scenario of using the ontology in agent communication.

Click To expand
Figure 15: Message structure
Example 9.4
Start example

The following is a sequence of messages between agents A1 and A2 and a broker B.

  1. Agent A1 sends an ASSERTIVE message with a <capability> parameter to the broker B. This means the agent A1 wants to register to the broker B and claims its capability.

  2. Agent A2 sends an EXPRESSIVE message to the broker B, with a <task> parameter describing a testing task. This means that the agent wants to find some agent to perform the testing task.

  3. The broker B searches its knowledge about registered agents, and finds that agent A1 is the best match for the task. It then sends a DIRECTIVE message with the <task> parameter to agent A1.

  4. When agent A1 finishes the task, it sends an ASSERTIVE message with an <answer> parameter to the broker. The <answer> parameter describes the status of the task and output of the task if it is successful, or the reason of failure or error messages if it is not successful.

  5. The broker B may forward the message to agent A2, or try to find another agent to carry out the testing task in case the output of agent A1, is not successful.

End example


Conclusion

This chapter presents an ontology of software testing and discusses its uses in a multiagent software environment to support the evolutionary development and maintenance of Web-based applications. The prototype system consists of a number of software testing and quality assurance agents. Each testing task is assigned to an agent in the system, which either performs the requested task or decomposes it into smaller tasks for other agents to perform. In this way, agents cooperate with each other to carry out complicated testing tasks.

As Jennings and Wooldridge (1998) pointed out, agent techniques benefit in application areas that involve diverse platforms and information formats and in dynamic environments. Our experiment supports this claim. In particular, for the following reasons, agent technology is suitable for testing Web-based systems.

The dynamic and evolutionary nature of Web-based applications requires constantly monitoring the changes of the system and its environment. Sometimes, the changes in the system and its environment may require changes in testing strategy and method accordingly. Agents are adaptive, and they can adjust their behaviours based on environment changes. These changes can be integrated to the system dynamically.

Web-based information systems often operate on a diversity of platforms and use various different formats of media and data. This demands a wide variety of test methods and tools to be used in testing a single system. Multiagent systems can provide a promising solution to this problem. Different agents are built to handle different types of information, to implement different testing methods and to integrate different tools. Thus, each individual agent can be relatively simple while the whole system is powerful and extendible.

The distribution of large volumes of information and functionality over a large geographic area requires testing tasks carried out at different geographic locations and to transfer information between computer systems. The agents can be distributed among many computers to reduce the communication traffic.

Agents also provide a nice way that human testers interact with testing tools. The relationship between human testers and agents are no longer a commander/slave relation. Instead, the human tester and the agents form a testing team and cooperate with each other. In particular, when a part of a complicated testing task cannot be performed by the tools, the testing will not fail completely. Instead, the agent can pass the unsolvable task to the human tester and ask for help. This feature is of particular importance for testing Web-based applications, because they are often extended by integrating into the system new components developed with new technology that may have no ready made testing tools at the beginning. The collaborative relationship not only release human testers from routine work, which is performed by the agents, but also enables the human testers to participate in the testing process by taking the most intellectually challenging tasks so that the whole testing job can be performed more efficiently and effectively.

In the design and implementation of the prototype system, we realised that the key issue is the mechanism that enables the flexible integration of agents into the environment and the effective communications between agents and between the human testers and agents. Our solution is the ontology of software testing. It is used as the content language for software agents to register into the system with a capability description, for human testers and agents to make testing requests and report testing results, and for management agents to allocate tasks to agents. This chapter reports how the concepts of the ontology and the relations between them are defined in UML. Their properties are also analysed. Speech-act theory is incorporated in the system and combined with the ontology to define communication protocols and to facilitate collaborations between agents. Our experience in the development of the ontology further confirmed the advantages and benefits of using ontology in tool integration that have already been observed in other application domains such as those mentioned in the Introduction, but have not been explored in software engineering research as far as we know.

The ontology is designed based on the domain knowledge of software testing to mediate the communications between the agents. It was represented in XML to codify the knowledge of software testing for agents' processing of messages. The representation in XML for run-time communications between agents achieved a flexibility of modification and extendibility very well. However, during the testing and validation of the prototype system, we realised that XML representation is at a rather low level of abstraction. It is not very readable for domain experts to validate the ontology. Our first attempt to represent the ontology at a higher level of abstraction was the uses of BNF to describe the syntax structure of XML expressions (Huo, Zhu, & Greenwood, 2003). For example, the following is the BNF definition of tester.

<tester> ::=      "<TESTER" {<tester parameter>}">" {<tester>} "</TESTER>"
<tester parameter> ::= <tester type> | <name> | <capability> | <leader>
<name> ::= "NAME =" <string>
<leader> ::= "LEADER =" <name>
<tester type> ::= "TYPE =" ("HUMAN" | "SOFTWARE" | "TEAM")

BNF descriptions of the XML syntax are significantly shorter than the corresponding XML Schema definitions. For example, the XML Schema definition of the XML representation of the concept tester in the next example is three times longer than the BNF expressions. BNF is more suitable to human readers. Moreover, software engineers and computer scientists, who are the domain experts of software testing, are more familiar with BNF than XML Schema.

<!---TESTER--->
<xs:element name="TESTER">
 <xs:complexType>
  <xs:sequence>
   <xs:element minOccurs="O" maxOccurs="unbounded" ref="TESTER"/>
  </xs:sequence>
  <xs:attribute name="TESTER_TYPE" use="required">
   <xs:simple Type>
    <xs:restriction base="xs:token">
     <xs:enumeration value="HUMAN"/>
     <xs:enumeration value="SOFTWARE"/>
     <xs:enumeration value="TEAM"/>
    <xs:restriction>
   </xs:simpleType>
  </xs:attribute>
  <xs:attribute name="TESTER_NAME" use="required"/>
  <xs:attribute name="TESTER_LEADER"/>
 </xs:complexType>
</xs:element>

However, the BNF representation is still not good enough for end users of the prototype system, who communicate with the agents in the ontology of software testing to request testing tasks and receive testing results. BNF is still at the syntax level. It does not properly represent some important concepts of ontology, such as the concept of subclass, and so forth. Therefore, we also developed the representation of the ontology in UML. It is at a suitable level of abstraction for both validation by human experts and communication with the end users.

Representing the ontology in two notations at different abstraction levels raised the question how to validate the consistency between the UML and XML representations. Recently, standard XML representations of UML models and tools though XMI have emerged to enable the automatic translation of UML models into XML representations. Using such techniques will result in completely rewriting the whole prototype system. It is unclear and worth further investigation whether the automatic technique of translation from UML to XML can be applied to our ontology. It seems that our ontology is significantly more complicated than the examples and case studies conducted in the development of such techniques and reported in the literature.

We are also further investigating the methodology of developing ontology at a wider context of software engineering and further developing the prototype of software growth environment. The automatic translation technique will be beneficial to our further research. A difficult problem is the development of a model of the whole system, including definitions of the organizational structure, functionality, and dynamic behaviours of the agents. It seems that an agent-oriented modeling language such as the CAMLE (Shan & Zhu, 2003a, 2003b) or AUML (FIPA Modeling TC) is necessary to catch the agents' autonomous and social behaviours. In our design and implementation of the ontology in UML and XML, we noticed that UML does not provide adequate support to the formal specification and analysis of the relations between concepts, although OCL can be partially helpful. For example, we have to use first-order logic formulas for the definitions and proofs of the properties of compound relations.


References

Bennett, K., & Rajlich, V. (2000). Software maintenance and evolution: A roadmap. Proceedings of the Conference on the Future of Software engineering, 73–87. ACM Press.

Boehm, B. (2000, July). Requirements that handle IKIWISI, COTS, and rapid change. IEEE Computer, 99–102.

Cranefield, S., Haustein, S., & Purvis, M. (2001). UML-based ontology modelling for software agents. Proceedings of Ontologies in Agent Systems Workshop, August 2001, Montreal, 21–28.

Crowder, R., Wills, G., & Hall, W. (1998). Hypermedia information management: A new paradigm. Proceedings of 3rd International Conference on Management Innovation in Manufacture, July 1998, 329–334.

FIPA Modelling Technical Committee (2004). Agent UML. Retrieved from A UML Website at http://www.auml.org/

Fox, M. S., & Gruninger, M. (1994). Ontologies for enterprise integration. Proceedings of the 2nd Conference on Cooperative Information Systems, Toronto.

Huo, Q., Zhu, H. & Greenwood, S. (2002). Using Ontology in Agent-based Web Testing. Proceedings of International Conference on Intelligent Information Technology (ICIIT'02), Beijing, China.

Huo, Q., Zhu, H., & Greenwood, S. (2003). A multi-agent software environment for testing Web-based applications. Proceedings of the 27th IEEE Annual Computer Software and Applications Conference (COMPSAC'03), 210–215. Dallas, TX.

Jennings, N. R., & Wooldridge, M. (Eds.). (1998). Agent Technology: Foundations, Applications, and Markets. Springer-Verlag.

Jin, L., Zhu, H., & Hall, P. (1997). Adequate testing of hypertext applications. Journal of Information and Software Technology, 39(4), 225–234.

Lehman, M. M. (1980, September). Programs, life cycles and laws of software evolution. Proceedings of IEEE, 1060–1076.

Lehman, M. M. (1990). Uncertainty in computer application. Communications of ACM, 33(5), 584–586.

Lehman, M. M., & Ramil, J. F. (2001). Rules and tools for software evolution planning and management. Annals of Software Engineering, Special Issue on Software Management, 11(1), 15–44.

National Committee for Information Technology Standards. Draft proposed American national standard for Knowledge Interchange Format. Retrieved September, 2003, from http://logic.stanford.edu/kif/dpans.html

Naur, P. (1992). Programming as theory building, in Computing: A Human Activity, pp. 37–48. ACM Press.

Neches, R. et al. (1991). Enabling technology for knowledge sharing. AI Magazine, Winter issue, 36–56.

Rajlich, V., & Bennett, K. (2000). A staged model for the software life cycle. IEEE Computer, July 2000, 66–71.

Shan, L., & Zhu, H., (2003a) Modelling cooperative multi-agent systems. Proceedings of The Second International Workshop on Grid and Cooperative Computing (GCC'03), Shanghai, China, 1451–1458.

Shan, L., & Zhu, H. (2003b) Modelling and specification of scenarios and agent behaviour. In Proceedings ofIEEE/WIC Conference on Intelligent Agent Technology (IAT'03), pp. 32–38. Halifax, Canada.

Singh, M.P. (1993). A semantics for speech acts. Annals of Mathematical and Artificial Intelligence, 8(11), 47–71.

Singh, M. P. (1998) Agent communication languages: Rethinking the principles. IEEE Computer, December 1998, 40–47.

Staab, S., & Maedche, A. (2001). Knowledge portals - Ontology at work. AIMagazine, 21(2).

Uschold, M., & Gruninger, M. (1996). Ontologies: Principles, methods, and applications. Knowledge Engineering Review, 11(2), 93–155.

Zhu, H., Hall, P., & May, J. (1997). Software unit test coverage and adequacy. ACM Computing Survey, 29(4), 366–427.


Appendix. XML Schema (XSD) Definition of XML Representation of the Ontology of Software Testing

The following is the complete XML Schema definition (XSD) of the XML representation of the ontology of software testing.

<?xml version="1.0" encoding="UTF-8"?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
        elementFormDefault="qualified">
<!-- TESTER -->
<xs:element name="TESTER">
  <xs:complex Type>
    <xs:sequence>
      <xs:element minOccurs="0" maxOccurs="unbounded" ref="TESTER"/>
    </xs:sequence>
    <xs:attribute name="TESTER_TYPE" use="required">
     <xs:simpleType>
      <xs:restriction base="xs:token">
       <xs:enumeration value="HUMAN"/>
       <xs:enumeration value="SOFTWARE"/>
       <xs:enumeration value="TEAM"/>
      </xs:restriction>
     </xs:simpleType>
    </xs:attribute>
    <xs:attribute name="TESTER_NAME" use="required"/>
   <xs:attribute name="TESTER_LEADER"/>
  </xs:complex Type>
 </xs:element>
<!-- CONTEXT -->
 <xs:element name="CONTEXT">
  <xs:complex Type>
   <xs:attribute name="CONTEXT_TYPE" use="required">
    <xs:simpleType>
     <xs:restriction base="xs:token">
      <xs:enumeration value="UNIT_TEST"/>
      <xs:enumeration value="INTEGRATION_TEST"/>
      <xs:enumeration value="SYSTEM_TEST"/>
      <xs:enumeration value="REGRESSION_TEST"/>
     </xs:restriction>
    </xs:simpleType>
   </xs:attribute>
  </xs:complex Type>
 </xs:element>
<!-- ACTIVITY -->
 <xs:element name="ACTIVITY">
  <xs:complex Type>
   <xs:attribute name="ACTIVITY_TYPE" use="required">
    <xs:simpleType>
     <xs:restriction base="xs:token">
      <xs:enumeration value="TEST_PLANNING"/>
      <xs:enumeration value="TEST_CASE_GENERATION"/>
      <xs:enumeration value="TEST_CASE_EXECUTION"/>
      <xs:enumeration value="TEST_RESULT_VERIFICATION"/>
      <xs:enumeration value="TEST_COVERAGE_MEASUREMENT"/>
      <xs:enumeration value="TEST_REPORT_GENERATION"/>
     </xs:restriction>
    </xs:simpleType>
   </xs:attribute>
  </xs:complex Type>
 </xs:element>
<!-- METHOD -->
 <xs:element name="METHOD">
  <xs:complex Type>
   <xs:attribute name="METHOD_NAME" use="required">
    <xs:simpleType>
     <xs:restriction base="xs:token">
      <xs:enumeration value="CONTROL_FLOW_TESTING"/>
      <xs:enumeration value="DATA_FLOW_TESTING"/>
      <xs:enumeration value="STATEMENT_COVERAGE_TESTING"/>
      <xs:enumeration value="BRANCH_COVERAGE_TESTING"/>
      <xs:enumeration value="PATH_COVERAGE_TESTING"/>
      <xs:enumeration value="NODE_COVERAGE_TESTING"/>
      <xs:enumeration value="LINK_COVERAGE_TESTING"/>
      <xs:enumeration value="LIP_COVERAGE_TESTING"/>
     </xs:restriction>
    </xs:simpleType>
   </xs:attribute>
   <xs:attribute name="METHOD_TECHNIQUE">
    <xs:simpleType>
     <xs:restriction base="xs:token">
      <xs:enumeration value="STRUCTUAL_TESTING"/>
      <xs:enumeration value="FAULT_BASED_TESTING"/>
      <xs:enumeration value="ERROR_BASED_TESTING"/>
     </xs:restriction>
    </xs:simpleType>
   </xs:attribute>
   <xs:attribute name="METHOD_APPROACH">
    <xs:simpleType>
     <xs:restriction base="xs:token">
      <xs:enumeration value="PROGRAM_BASED_TESTING"/>
      <xs:enumeration value="SPECIFICATION_BASED_APPROACH"/>
      <xs:enumeration value="RANDOM_TESTING"/>
     </xs:restriction>
    </xs:simpleType>
   </xs:attribute>
  </xs:complex Type>
 </xs:element>
<!-- ARTEFACT -->
 <xs:complex Type name="ARTEFACT">
  <xs:sequence>
   <xs:element ref="ARTEFACT"/>
  </xs:sequence>
 </xs:complex Type>
 <xs:element name="ARTEFACT">
  <xs:complex Type>
   <xs:sequence>
    <xs:element minOccurs="0" ref="TESTER"/>
    <xs:element minOccurs="0" ref="ARTEFACT_DATA"/>
    <xs:element minOccurs="0" ref="ARTEFACT_LOCATION"/>
   </xs:sequence>
   <xs:attribute name="ARTEFACT_TYPE" use="required">
    <xs:simpleType>
     <xs:restriction base="xs:token">
     <xs:enumeration value="OBJECT_UNDER_TEST"/>
      <xs:enumeration value="TEST_PLAN"/>
      <xs:enumeration value="TEST_SCRIPT"/>
      <xs:enumeration value="TEST_RESULT"/>
      <xs:enumeration value="TEST_SUITE"/>
      <xs:enumeration value="TEST_COVERAGE"/>
      <xs:enumeration value="ERROR_REPORT"/>
      <xs:enumeration value="SPECIFICATION"/>
     </xs:restriction>
    </xs:simpleType>
   </xs:attribute>
   <xs:attribute name="ARTEFACT_FORMAT" use="required">
    <xs:simpleType>
     <xs:restriction base="xs:token">
      <xs:enumeration value="PROGRAM"/>
       <xs:enumeration value="HTML"/>
       <xs:enumeration value="XML"/>
      <xs:enumeration value="TEXT_FILE"/>
      <xs:enumeration value="WORD_FILE"/>
      <xs:enumeration value="PDF_FILE"/>
      <xs:enumeration value="POSTSCRIPT_FILE"/>
       <xs:enumeration value="BMP_IMAGE"/>
       <xs:enumeration value="JPEG_IMAGE"/>
       <xs:enumeration value="CD_SOUND"/>
      <xs:enumeration value="MPEG_VIDEO"/>
       <xs:enumeration value="VCD_VIDEO"/>
      <xs:enumeration value="DVD_VIDEO"/>
      <xs:enumeration value="JAVA_APPLET"/>
      <xs:enumeration value="JAVA_SCRIPT"/>
      <xs:enumeration value="NODE_SEQUENCES"/>
      <xs:enumeration value="LINK_SEQUENCES"/>
      <xs:enumeration value="LIP_SEQUENCES"/>
       <xs:enumeration value="DATA"/>
      </xs:restriction>
     </xs:simpleType>
    </xs:attribute>
   </xs:complex Type>
  </xs:element>
 <xs:element name="ARTEFACT_DATA" type="any"/>
 <xs:element name="ARTEFACT_LOCATION" type="any"/>
<!-- ENVIROMENT -->
 <xs:element name="ENVIRONMENT">
  <xs:complex Type>
   <xs:sequence>
    <xs:element minOccurs="0" maxOccurs="unbounded" ref="HARDWARE"/>
    <xs:element minOccurs="0" maxOccurs="unbounded" ref="SOFTWARE"/>
   </xs:sequence>
  </xs:complex Type>
 </:xs:element>
 <xs:element name="HARDWARE">
  <xs:complex Type>
   <xs:attribute name="HARDWARE_DEVICE" use="required"/>
   <xs:attribute name="HARDWARE_MANUFATURER" use="required"/>
   <xs:attribute name="HARDWARE_MODEL" use="required"/>
  </xs:complex Type>
 </xs:element>
 <xs:element name="SOFTWARE">
  <xs:complex Type>
   <xs:attribute name="SOFTWARE_TYPE" use="required">
    <xs:simpleType>
     <xs:restriction base="xs:token">
      <xs:enumeration value="OS"/>
      <xs:enumeration value="DATABASE"/>
     <xs:enumeration value="COMPILER"/>
     <xs:enumeration value="WEB_SERVER"/>
     <xs:enumeration value="WEB_BROWSER"/>
    </xs:restriction>
   </xs:simple Type>
  </xs:attribute>
   <xs:attribute name="SOFTWARE_PRODUCT" use="required"/>
   <xs:attribute name="SOFTWARE_VERSION" use="required"/>
  </xs:complex Type>
 </xs:element>
<!-- CAPABILITY -->
 <xs:element name="CAPABILITY">
  <xs:complex Type>
   <xs:sequence>
    <xs:element minOccurs="0" maxOccurs="1" ref="CONTEXT"/>
    <xs:element minOccurs="1" maxOccurs="1" ref="ACTIVITY"/>
    <xs:element minOccurs="1" maxOccurs="1" ref="METHOD"/>
   <xs:element minOccurs="0" maxOccurs="1" ref="ENVIRONMENT"/>
    <xs:element minOccurs="0" maxOccurs="unbounded"
                 ref="CAPABILITY_DATA"/>
   </xs:sequence>
  </xs:complex Type>
 </xs:element>
<xs:element name="CAPABILITY_DATA">
 <xs:complex Type>
  <xs:complexContent>
   <xs:extension base="ARTEFACT">
    <xs:attribute name="CAPABILITY_DATA_TYPE" use="required">
     <xs:simpleType>
      <xs:restriction base="xs:token">
       <xs:enumeration value="INPUT"/>
       <xs:enumeration value="OUTPUT"/>
      </xs:restriction>
     </xs:simpleType>
    </xs:attribute>
   </xs:extension>
  </xs:complexContent>
 </xs:complex Type>
</xs:element>
<!-- TASK -->
<xs:element name="TASK">
 <xs:complex Type>
  <xs:sequence>
   <xs:element minOccurs="0" maxOccurs="1" ref="CONTEXT"/>
   <xs:element minOccurs="1" maxOccurs="1" ref="ACTIVITY"/>
   <xs:element minOccurs="1" maxOccurs="1" ref="METHOD"/>
  <xs:element minOccurs="0" maxOccurs="1" ref="ENVIRONMENT"/>
   <xs:element maxOccurs="unbounded" ref="TASK_DATA"/>
  </xs:sequence>
 </xs:complex Type>
</xs:element>
<xs:element name="TASK_DATA">
 <xs:complex Type>
  <xs:complexContent>
   <xs:extension base="ARTEFACT">
    <xs:attribute name="TASK_DATA_TYPE" use="required">
     <xs:simpleType>
      <xs:restriction base="xs:token">
       <xs:enumeration value="INPUT"/>
       <xs:enumeration value="OUTPUT"/>
      </xs:restriction>
     </xs:simpleType>
    </xs:attribute>
   </xs:extension>
  </xs:complexContent>
 </xs:complex Type>
</xs:element>
<!-- REPLY -->
 <xs:element name="REPLY">
  <xs:complex Type>
   <xs:attribute name="REPLY_STATUS" use="required">
    <xs:simpleType>
     <xs:restriction base="xs:token">
      <xs:enumeration value="SUCCESSFUL"/>
      <xs:enumeration value="FAILED"/>
     </xs:restriction>
    </xs:simpleType>
   </xs:attribute>
  <xs:attribute name="REPLY_REASON"/>
 </xs:complex Type>
</xs:element>
<!-- MESSAGE -->
 <xs:element name="MESSAGE">
  <xs:complex Type>
   <xs:choice>
    <xs:element ref="CAPABILITY"/>
    <xs:element ref="TASK"/>
    <xs:element ref="REPLY"/>
   </xs:choice>
   <xs:attribute name="MESSAGE_ACT" use="required">
    <xs:simpleType>
     <xs:restriction base="xs:token">
      <xs:enumeration value="ASSERTIVE"/>
      <xs:enumeration value="DIRECTIVE"/>
      <xs:enumeration value="COMMISIVE"/>
      <xs:enumeration value="PERMISSIVE"/>
      <xs:enumeration value="PROHIBITIVE"/>
      <xs:enumeration value="DECLARATIVE"/>
      <xs:enumeration value="EXPRESSIVE"/>
     </xs:restriction>
    </xs:simpleType>
   </xs:attribute>
  </xs:complex Type>
 </xs:element>
 <xs:complex Type name="any" mixed="true">
  <xs:sequence>
    <xs:any minOccurs="0" maxOccurs="unbounded" processContents="strict"/>
  </xs:sequence>
 </xs:complex Type>
</xs:schema>


Chapter X: Abstracting UML Behavior Diagrams for Verification

MaríAa del Mar Gallardo,
University of MáAlaga,
Spain
JesúAs MartíAnez,
University of MáAlaga,
Spain
Pedro Merino,
University of MáAlaga,
Spain
Ernesto Pimentel,
University of MáAlaga,
Spain

UML (Unified Modeling Language) and XML (Extensible Markup Language) related technologies have matured, and at present many novel applications of both languages are frequently appearing. This chapter discusses the combined use of both UML and XML in the exciting application domain of software abstraction for verification. In particular, software development environments that use UML notations are now including verification capabilities based on state exploration. This method is effective for many realistic problems, although it is well known that it is affected by the state explosion problem for many complex systems and that some kind of abstraction is needed. This is the point where XML can be used as a powerful technology, due to its features for program transformation. We describe how to use XML-related standards like DOM or XMl in order to extend UML verification tools with automatic abstraction.

Introduction

The increasing demand of reliable software for critical control and communication systems is the reason why many CASE (Computer-Aided Software Engineering) tools include some kind of automatic verification facility. This is the case of academic- or research-oriented tools like SPIN (Holzmann, 2003) and commercial tools like SDL Suite (Telelogic, 2003). All these tools implement variants of model checking (Clarke, Emerson, & Sistla, 1986) as the verification method. Following this approach, the software being verified is described (modeled) with executable domain-specific languages like PROMELA or SDL, respectively. In addition, designers can specify desired or nondesired properties using notations like temporal logic (Manna & Pnueli, 1992), automata (Vardi & Wolper, 1986) or Message Sequence Charts (MSC) (ITU-T, 2000). Model checking algorithms perform an exhaustive analysis of all the possible execution paths produced by the model to check whether the properties are satisfied.

Nowadays, UML has become the standard language to model complex software. It is being widely used in earlier stages of system design and, recently, UML-based CASE tools are trying to incorporate verification facilities like model checking. This has motivated the development of new research-oriented tools (VUML [Lilius & Porres, 1999] or HUGO [Schafer, Knapp, & Merz, 2001]), and commercial environments like STATEMATE (I-Logix, 2002) or Visual State (IAR, 2003). As verification requires an executable description of the software (the model), all these tools employ UML behavior diagrams (statecharts) as their input format. These diagrams represent the activation or deactivation of activities, data manipulation and event generation. It is worth noting that there exist different semantics for these diagrams, because original statecharts were introduced by Harel, Pnueli, Schmidt, and Sherman (1987) with a slightly different meaning from the one proposed in recent UML standard documents (Object Management Group, 2002b). Therefore, current verification tools for UML may use different semantics.

Although current verification tools have been effectively used to analyze real systems, they may fail for many complex systems due to the so-called state explosion problem. This problem is even more important in UML commercial environments, because they are oriented to developing final applications, considering richer descriptions of the software in order to allow automatic code generation.

Abstraction techniques are a good option to deal with the state explosion problem in model checking (Clarke, Grumberg, & Long, 1994; Dams, Gerth, & Grumberg, 1997). In this context, abstraction consists of replacing the model to be analyzed with another simpler description that produces a smaller state space and preserves enough information to decide about the satisfaction of the properties.

Abstraction can be implemented working with an internal representation of the model or by transforming the textual description. In previous works, we have defended the transformation approach as an effective choice to implement automatic techniques for abstraction in both academic (Gallardo & Merino, 1999; Gallardo, Martinez, Merino, & Pimentel, 2003) and commercial tools (Gallardo & Merino, 2000; Gallardo, Merino, & Pimentel, 2002). One major benefit of our approach is the possibility of completely reusing the model-checking tool, without modifying its internal code. In particular, we developed the tool αSPIN (Gallardo et al., 2003), which incorporates abstraction into the model checker SPIN using XML. The good results obtained with αSPIN have motivated our work of applying the abstraction-by-transformation method to systems described using UML behavior diagrams. As the verification tools for this notation are more recent, there is still a lack of tool extensions to perform automatic abstraction. This chapter is devoted to the use of XML technology for extending UML verification tools with abstraction capabilities.

Regarding the implementation of abstraction techniques, efforts focused on reimplementing or building new tools from scratch are discouraging. The evolution of many CASE tools makes it now possible to extend the tools themselves via Open APIs, including full access to internal object formats and options. This approach allows embedding automatic verification plug-ins in the CASE tool. On the other hand, existing verification tools are really complex standalone applications that benefit from continuous research and upgrades but have poor object-oriented capabilities or extension features. Therefore, efforts focused on data interchange among existing tools (design-abstraction-verification) should be reasonable enough in terms of cost and management.

Fortunately, UML models, along with their functional behavior, are prepared to be expressed in XML format using the XMI/MOF specifications (Object Management Group, 2002a, 2002c). The XML Model Interchange (XMI) interface provides application developers with a common language for specifying, visualizing, constructing, and documenting models. This allows tools to communicate with other model-based tools which conform to the XMI standard for model interchange. STATEMATE, for example, is able to import statecharts from XMI documents, in order to verify them. Therefore, the XMI representation of the statecharts is suitable for the fully automatic transformation of the original into the abstract model, as shown in Figure 1. The figure depicts a typical scenario where the UML verification tool has been extended using model interchange. The abstraction tool incorporates features to perform data and event abstractions. Data abstractions will also consider a repository with abstract libraries, to be discussed later in this chapter.

Click To expand
Figure 1: Our abstraction approach

The chapter is organized as follows. The first three sections give an overview of the application domain, including verification of UML, abstraction techniques, and transformation approaches, respectively. Another section will describe the use of XML technology to perform abstraction of UML behavior diagrams along with clear guidelines to implement experimental prototypes reusing a new Java abstraction API. Finally, we indicate some future work and conclusions.


Verification of UML Statecharts

Current tools for analyzing UML statecharts incorporate important verification capabilities, but they do not support flexible abstractions. This fact constitutes the basis to design novel abstraction prototypes as extensions to those verifiers. Most of the work focused on verifying the dynamic behavior of software described with UML reuses academic tools. In particular, the proposals in Latella, Majzik, and Massink, (1999); Mikk, Lakhnech, Siegel, and Holzmann (1998); Lilius and Porres (1999); Schfer et al. (2001) consider the use of the tool SPIN as the basis to verify statecharts, translating these into its input language, PROMELA. It is a nondeterministic language that borrows some concepts and syntax elements from Dijkstra's guarded command language, Hoare's CSP language, and C programming language. Processes may share global variables or channels. Thus, it is possible to represent both shared-memory and distributed-memory systems. Communication via channels may be synchronous, when the size of the channel is zero, or asynchronous, using channels as bounded buffers. Additionally, processes may have local variables storing their local state.

Using SPIN, a PROMELA model may be analyzed against general and critical properties such as deadlock absence. In addition, users may specify other particular properties for the system using Linear Temporal Logic (LTL). Typical LTL formulas represent liveliness properties such as □p (p is always true), ⋄p (eventually p will be true), p U q (q will be true, and p will be true in all previous states) or ○p (p will be true in the next state), p being any kind of proposition or even another temporal formula.

The works in Latella et al. (1999); Mikk et al. (1998); and Schmidt and Varró (2003) use temporal logic to define desirable (or undesirable) scenarios in a given statechart (which is translated into PROMELA). These works employ different semantics for statecharts. The first one describes a new semantics, while the second one uses the statechart semantics implemented by the commercial tools of I-logix (Harel & Naamad, 1996). In Schmidt and Varró (2003), any semantics could be used because the authors consider the tool CheckVML as very independent of the modeling language.

The tool VUML (Lilius & Porres, 1999) keeps PROMELA hidden from the user, but only supports the verification of general properties of statecharts, like deadlock absence. The authors employ collaboration diagrams to create the PROMELA configuration to be analyzed, but not as a notation for properties.

HUGO (Schafer et al., 2001) also employs PROMELA and SPIN as the core verification technology, but its users work with UML descriptions. HUGO verifies whether or not the desirable behavior described by a collaboration diagram is feasible for a set of UML state machines (equivalent to the verification against Sequence Diagrams described in Gallardo et al. (2002)). The tool has been recently extended to HUGO/RT (Knapp, Merz, & Rauh, 2002) in order to consider timed State Machines using the model checker UPPAAL (Pettersson & Larsen, 2000) as the basis.

VisualState (IAR, 2003) and STATEMATE (I-Logix, 2002) are two well-known commercial tools with notable capabilities that include verification of UML.

VisualState implements reachability analysis to check many properties, like searching for conflicting behavior, unreachable transitions, or dead ends, but it does not consider any specific property language.

STATEMATE integrates modelchecking within its ModelCertifier package for both synchronous and asynchronous time models defined by its semantics (Harel & Naamad, 1996). Users may use some predefined analysis proofs or define the properties to be held in the design. The predefined proof set includes the analysis of nondeterminism, range violations, or race conditions regarding variables. In addition, the reachabilitydriven analysis must check whether or not it is possible to reach a state (or a set of states, including AND-states). Finally, the user-defined analysis determines if a property holds in a state of the system. Properties may be specified using parameterized property patterns. The package also allows the definition of environment assumptions. Figure 2 shows a ModelCertifier verification scenario for a CD player system. Users define their own proof dictionary with properties to be analyzed. Each proof is configured using a dialog window to introduce the selected pattern, its parameters and some additional verification options. The proof dictionary also informs users about each proof status (executed, in queue) along with its corresponding result (true or false).

Click To expand
Figure 2: The STATEMATE ModelCertifier package

Only STATEMATE offers some reduced data abstraction capabilities, which are focused on two main targets: (a) reducing the huge variable range of reals and integers, and (b) bounding the length of time steps embedded in a super-step one, when the asynchronous time model was chosen (I-Logix, 2003). There are only two abstraction functions available for variables. The free abstraction eliminates the correlation of variable valuations of consecutive steps; that is, its values are considered randomly. The strong abstraction function considers that the variable, in every step, can have any possible value of its range. Therefore, expressions involved will always become true in order to catch that imprecision.


Abstracting for Verification

The main problem of model checking for verification is how to deal with very large state space systems. Although there are many real examples where the verification can be done with standard exhaustive verification, fortunately current tools also implement several optimization techniques to analyze complex systems with more than 100,000 states. The efficiency of these techniques can be further augmented with the more recent Abstraction method (Clarke et al., 1994). In general, abstracting the model of a system entails constructing a simpler specification which is equivalent to the initial one with respect to the properties to be verified. Therefore, abstraction techniques produce a smaller representation of a program (or a model) containing only the relevant details for a specific application. In the context of modeling languages like statecharts, abstraction can be done to reduce data or events. However, abstractions should always be done in such a way that results can be applied to the initial model.

Abstracting Statecharts: The Theoretical Basis

In this section, we briefly describe the key aspects of the application of the abstract interpretation technique (Cousot & Cousot, 1977) to correctly abstract systems to be analyzed by model checking. More details may be found in Clarke et al. (1994); Dams et al. (1997); and Gallardo, Merino, and Pimentel, (2002).

Let us assume that the model to be abstracted is represented by a labelled transition system such as S = 〈Σ;, L, →, s0〉, where

  • S is the set of concrete configurations. Each configuration s ∊ Σ includes information about the actual content of the system variables and event queues, along with the state of every control statechart.

  • L is the set of observable operations, that is, the instructions (actions) executed by the processes.

  • so is the initial configuration.

  • → ⊆ Σ×L×Σ is the transition relation. We write [image] for (s,a,s')∊ →. indicates that the execution of action a transforms configuration s into s'.

In order to abstract a transition system S = 〈Σ, L, →, s0〉, we must consider a lattice of abstract configurations (Σα, ⊆) and an abstraction function β: Σ → Σα which relates every concrete configuration with its most precise representation in Σα. Each abstract configuration is intended to approximate a set of concrete configurations sharing some characteristic which is abstracted. The partial order ⊆ represents the degree of precision of every abstract configuration, that is, β(s) ⊆ sα means that sα is a safe abstraction of s and s1α ⊆ s2α indicates that s1α is more precise than sα2.

Given two transition systems S = 〈Σ, L, →,s0〉 and Sα = 〈Σα, Lα,→α,sα0〉, where Σ and Σα relate each other as explained above, we say that Sα is a correct abstraction of S iff β(s0) ⊆ sα0 and for all configurations s1, s2 ∊ Σ and sα1 ∊ Σα, if [image] and β(s1) ∊ sα1 then there exists sα2 ∊ Σα such that [image] and β(s2) ⊆ sα2, that is, all transitions in S are mimicked by transitions in Sα.

when implementing abstraction by source-to-source transformation, the previous correctness criterion may be read as follows. For each action a, an abstract action aα must be defined such that if [image] and β(s1) ⊆ sα1 then there exists sα2 ∊ Σα such that [image] and β(s2) ⊆ sα2. This means that we use the standard transition relation → to manipulate the abstract model. That is, we use current verification tools, but redefining the way in which actions are executed.

Note that the use of abstract domains (Σα) diminishes the size of the state space, but, in contrast, the loss of information inherent in the abstraction introduces a source of nondeterminism in the abstract models. This means that these models potentially exhibit more behaviors than the original ones, and therefore only universal properties are naturally preserved by the abstraction process (dually abstract models may be also used to refute existential properties). However, abstract models may have the so-called spurious traces which may make them useless to analyze existential properties.

In the two following subsections, we clarify the previous description giving examples about how to abstract data, events, and actions in statecharts.

Abstracting Data

In Gallardo and Merino (1999) and Gallardo et al. (2003), we described a method based on the source-to-source transformation to perform data abstraction. The main idea in this work is that in order to abstract models, it suffices to replace the original access definitions of some selected variables so that the range of their possible values is shrunk—in such a way that the control part of the program (actions in statecharts) remain unchanged. From a practical point of view, this observation is very important because it allows us to isolate the program points that must be changed when abstracting a model, independently of the complexity of the language constructions.

For instance, Figures 3 and 4 show part of the UML design representing a CD player system (partially extracted from Gallardo et al. (2002). Let us assume that the system includes a variable track, an integer number in the range 1.. 12. To reduce the model size, consider the lattice COUNTER illustrated in Figure 5 and the so-called abstraction function

Click To expand
Figure 3: Class diagram for a CD player
Click To expand
Figure 4: State machines for CD_PLAYER and CD_DEVICE
Click To expand
Figure 5: Lattice COUNTER

defined as

The lattice definition includes the loss of information which occurs when the abstract variables change their values in the abstract model. For instance, the abstract value noLast approximates any track different from the Last one: thus noLast is an abstract value less precise than both First and Middle. Value Any is the least precise abstract data since it represents any track. Finally, value ⊥ is used to represent Illegal values.

The redefinition of values for track involves the redefinition of the actions on this variable. For instance, the code in Figure 6 shows CNT_INCR, a possible implementation of the abstract version of increment by one. The notation used here is similar to the one employed in the STATEMATE tool. The function shown in Figure 6 follows the correctness criterion noted in the previous subsection. This means that the result of CNT_INCR must simulate all possible results of the concrete increment by one operation. This is why CNT_INCR(Middle) is defined as noFirst representing both the case of incrementing j, with j < Last -1, and incrementing Last-1. With this definition, the code for actions in statecharts like track := track + 1 should be replaced with CNT_INCR(track).

Start Figure
Function: CNT_INCR
Input/Output Argument: x:integer
Body:  if x=First then x:= Middle
     else if x=Middle then x:= noFirst
        else if x=noLast then x:= noFirst
           else if x=noFirst then x:=noFirst
             else if x=Any then x:=noFirst
               else x:=lllegal
               end if
             end if
           end if
        end if
     end if
End Figure

Figure 6: The abstract increment by one function

Similar conversions are needed to deal with guard conditions. Let us, for instance, consider the code for the action ActFORWARD depicted in Figure 7(a). This code could be executed when passing to the next track, updating the variable continue. If we abstract the variable track as explained above, then the conditions should be changed as shown in Figure 7(b).

Click To expand
Figure 7: FORWARD actions for the (a) original and (b) abstract versions

The new syntax for the selection sentence is nondeterministic. The C point can proceed by any branch that satisfies the guard, in such a way that the loss of information due to abstraction (e.g., noFirst represents other values than) is compensated by allowing more execution branches.

The operations CNT_LT and CNT_GE are the abstract versions for < and >=, respectively. All these operations should be defined to verify that the abstract model correctly simulates the original one (they should be true if some value for the nonabstracted variable produces true). For instance, consider the test CNT_LT defined as shown in Figure 8. Following the correctness criterion, CNT_LT(x,y) must be true when a<b holds for some concrete data a and b abstracted by x and x, respectively. The abstraction function always takes into account the introduced imprecision. This explains why, for instance, CNT_LT(Middle,Middle) is true, though there exist concrete data a and b abstracted by x and y for which the relation does not hold (i.e., a = 3, b = 2). It is worth noting that these definitions can be automatically obtained from the definition of the lattice. This mechanism was implemented in α SPIN with the PROMELA language, and could also be used to introduce data abstraction in actions associated with UML statecharts.

Start Figure
Function: CNT_LT
Input Arguments: x,y:integer
Body:   ((x=First)and(y=Last))   or ((x=First)and(y=Middle))   or
        ((x=First)and(y=noFirst)) or ((x=First)and(y=noLast))   or
        ((x=First)and(y=Any))    or ((x=Last)and(y=Any))     or
        ((x=Middle)and(y=Last))   or ((x=Middle)and(y=noFirst))  or
        ((x=Middle)and(y=noLast))  or ((x=Middle)and(y=Middle))   or
        ((x=Middle)and(y=Any))    or ((x=noFirst)and(y=Middle))  or
        ((x=noFirst)and(y=Last))  or ((x=noFirst)and(y=noLast))   or
        ((x=noFirst)and(y=Any))   or ((x=noLast)and(y=Middle))   or
        ((x=noLast)and(y=noFirst)) or ((x=noLast)and(y=noLast))   or
        ((x=noLast)and(y=Last))   or ((x=noLast)and(y=Any))    or
        ((x=Any)and(y=Middle))    or ((x=Any)and(y=Last))     or
        ((x=Any)and(y=noLast))    or ((x=Any)and(y=noFirst))   or
        ((x=Any)and(y=Any))
End Figure

Figure 8: The abstract less than function

Abstracting Events

Abstracting events consists of using a single name of event to represent a set of real ones. For example, the abstract event request could represent all the events due to actor requests (power, load, play, forward and back), and the abstract event effect could represent the answers from the CD_PLAYER statechart. If we make an abstraction of events, then we have to transform the statecharts to work with the abstract ones. Fortunately, as before, this work can be done fully automatically. For example, Figure 9 shows an abstract version of a CD_PLAYER with the two abstractions of events described above. Note that now the statechart exhibits more nondeterministic behaviors. For example, two transitions starting at state CLOSED can be fired with the same event request. This is due to the loss of precision introduced by the abstract event request; how do we know if request is representing play or load to fire the correct transition? Again, we need to introduce nondeterminism in order to preserve at least the same potential execution sequences as in the initial statechart. This is a key point in order to obtain useful verification results.

Click To expand
Figure 9: Abstract state machine for the CD_PLAYER

The benefits of using this kind of abstraction can be demonstrated after verifying a safety property in STATEMATE using both the real and abstract CD_PLAYERs from Figures 4 and 9. Using the pattern library included in the ModelCertifier package, we have defined the property there is no MUSIC without PLAY as

The abstract version of the property, used with the abstract statechart depicted in Figure 9 is now defined as

Our experience enables us to assert that both kinds of abstraction for UML State Machines (event and data abstraction) can be implemented by transforming the specification. The next section describes different approaches for transforming UML as a previous step to dealing with automatic transformations for abstraction using XML.


Transformation in UML

Program transformation has usually been a research field associated to graph theories (Ehrig, Engels, Kreowski, & Rozenberg, 1997, 1999). However, in the last years there has been a growing interest in the adoption of standards for object modeling (as those proposed by the Object Management Group), along with transformation methodologies applied to these recommendations.

The OMG Meta-Object Facility (MOF) Specification defines an abstract language and a framework for specifying and managing metamodels (see Figure 10). A metamodel is an abstract language for some kind of metadata. UML has its corresponding metamodel, as well as the MOF itself (the meta-metamodel). In addition, MOF defines a way to implement repositories for holding model instances (described by the metamodels) that can be manipulated using programming APIs, like CORBA or Java interfaces. These libraries are generated following the mapping recommendations included in the MOF specification. MOF also defines an interchange format called XML Metadata Interchange (XMI) suitable to transport models and metamodels.

Click To expand
Figure 10: MOF metadata architecture

Thus, the MOF meta-metamodel (M3 in Figure 10) has constituted the basis for the design of the recent UML metamodels (versions 1.3, 1.4, and 1.5 are available at the moment).

Recent works in transformation focus on model transformation, and are related with some of the levels defined in the MOF Metadata Architecture ( Figure 10). In order to classify the approaches, we can distinguish between metamodeling or model-to-model approaches. The former change the origin and destination metamodels that represent the transformed model. These approaches correspond to the M2 level. The latter transform within the same metamodel context,that is, performing model refinement, abstraction, or refactoring. These approaches correspond to the M1 level. A similar classification is proposed in Pollet and Vojtisek (2002), referring to them as exomorphic or endomorphic proposals, respectively.

Model-to-Model Approaches

Regarding endomorphic proposals, the recent work in Pollet and Vojtisek (2002) extends the Object Constraint Language (OCL) (Object Management Group, 2001) for UML, in order to constitute the core transformation language to perform UML refactorings. Though OCL is not able to modify a model because it is restricted to being a mere expression language, that paper proposed to extend the language with action features (i.e., creating or deleting). Similarly, the abstraction approach introduced in this chapter can also be considered as an endomorphic transformation.

Metamodeling Approaches

In modeling languages, the exomorphic transformation is usually referred to as mapping. Frequently, UML models are converted to a formal language in order to perform some kind of analysis, and researchers try to develop frameworks or mapping rules in order to identify and automate this process (Dominguez, Rubio, & Zapata, 2002; Gerber, Lawley, Raymond, Steel, & Wood, 2002; Peltier, Bezivin, & Guillaume, 2001).

In Dominguez et al. (2002) there is an informal description of the transformation process; however, the proposal in Gerber et al. (2002) introduced a full transformation method based on the authors' previous experience with XSLT and logic programming. The resulting definition of transformation rules seems to be based on the extended OCL approach (Pollet & Vojtisek, 2002).

The MTRANS tool, introduced in Peltier et al. (2001), also constitutes a general framework to express model transformations. This approach applies the metamodeling approach to all MOF-compliant models. The first version of the framework relies on XSLT to perform the transformation in an automatic way, taking advantage of the fact that both source and destination models are expressed in XMI. In order to avoid the direct manipulation of XSLT templates, the authors have defined the MTRANS language. This notation can be seen as a flexible mechanism to define rules according to source and destination metamodels. Therefore, the MTRANS rules are compiled into their corresponding XSLT stylesheet.

Some examples of exomorphic transformation of UML or XMI models into other languages are SQL (Demuth & Obermaier, 2001), Calculus for Communicating Systems (ccs) (Stevens, 2003), and to terms in the Maude formal language (Saez, Toval, & Fernandez, 2001).

Finally, the graph theory for transformations is recovered in Varró, Gyapay, and Pataricza (2001). First of all, the source model in XMI is converted into a graph. The transformation rules are also defined using UML, and converted again into graphs. After completing the graph transformation, the resulting graph is translated into an XMI model. The last step consists of transforming the model to timed Petri nets to perform dependability analysis.

Evaluation

The first conclusion after reviewing all these new transformation approaches indicates that more tool support is needed. The main feature of such new tools should be the automatic transformation process, and the use of XML and MOF technologies seems to be the best way to develop rapid prototypes. In fact, the most innovative proposals are those that deal with UML models as XMI documents.


Abstracting UML/Statechart Events or Data Using XML

In order to implement the abstraction by transformation within the XML domain, we have evaluated some mature technologies which are able to carry out transformations in an XMI document: XSL, XMI.difference, or the ones used in our tool prototype, DOM and JMI programming APIs.

Direct Abstraction in XML

Traditionally, XML-related technologies have included some kind of mechanisms in order to support document transformation. The W3C XSL family of recommendations defines XPath, which allows locating XML elements, and XSLT for transforming an XML document into a new one. These recommendations treat transformations as a single controlled process using a set of stylesheet modules (templates), supplied in the form of XML documents. XSLT processors are the software programs responsible for such transformation. One of the main problems regarding XSL templates is that all the process will be carried out in sequential order. This fact does not scale well when the XML vocabulary elements are related with others using references (in the form of IDREFs or XPointers). Every element transformation will force the update of all existing elements that were previously referencing it.

The normal procedure with XSLT 1.0 is to perform a second transformation pass with the resulting (temporary) XML document using a new specialized stylesheet. Unfortunately, this approach implies using the hard disk for writing and reloading that document, which is a more time-consuming task. Furthermore, it causes some additional problems because the information that guides the update has to be embedded in some way within the temporal document and needs to be erased when the updating process has finished.

Perhaps the future adoption of the new XSLT 2.0 recommendation will help to solve these problems: XSLT 2.0 brings an enhanced data model with a most complete type system. Variables may contain a full element tree that can be evaluated in the same manner as the document tree. Therefore, with this tree the update step can be done completely in memory, avoiding the disk use. Figure 11 shows an example of the new approach. The code includes a skeleton intended to be the basis for the abstraction of events Event1 and Event2 by a new one called AbstractEvent (lines 5 to 9). The four templates depicted are responsible for calling the abstraction routines (included from a different file in line 4) when matching appropriate elements. The first thing to do is to insert the new abstract event (line 18). The next step will analyze existing events, searching for those that must be eliminated. Their ID (line 22) will be used in the update mode (line 25), which is responsible for fixing and updating IDREFs with respect to the new changes introduced.

Start Figure
1  <xsl:stylesheet version="2.0"
2   xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
3   xmlns:UML="org.omg.xmi.namespace.UML">
4    <xsl:include href="abstractionEngine.xsl"/>
5    <xsl:variable name="signalsToAbstract">
6     <UML:Signal name="Event1"/>
7     <UML:Signal name="Event2"/>
8   </xsl:variable>
9    <xsl:variable name="abstractSignal" select="AbstractEvent"/>
10    <xsl:variable name="absRoot">
11       <xsl:apply-templates select="/" mode="abstracting"/>
12   </xsl:variable>
13   <xsl:template match="/">
14      <xsl:apply-templates select="$absRoot" mode="updating"/>
15   </xsl:template>
16     <xsl:template match="UML:Namespace.ownedElement" mode="abstracting">
17     <xsl:copy>
18         <xsl:call-template name="insertAbstractSignal"/>
19        <xsl:apply-templates/>
20     </xsl:copy>
21    </xsl:template>
22    <xsl:template match="UML:Signal" mode="abstracting">
23      <xsl:call-template name="analyzeSignal"/>
24    </xsl:template>
25     <xsl:template match="UML:SignalEvent.signal" mode="updating">
26      <xsl:call-template name="updateReferences"/>
27    </xsl:template>
28  </xsl:stylesheet>
End Figure

Figure 11: An XSLT 2.0 stylesheet example

The main disadvantages of XSLT stylesheets are their readability and reusability, due to XSL syntax verbosity and the fact that there is no way to separate the transformation rules from the embedded structure of the output XML document. Nonetheless, this approach was the one chosen in Peltier et al. (2001) and Demuth and Obermaier (2001).

The XMI format includes a high-level mechanism to define transformations as differences between two documents, through the XMI. difference element. The objective is to only transmit the changes made to a model (differences between the new and the original one) together with all necessary information needed to apply these changes to the original model. Although the difference facility only incorporates basic editor functionalities (adding a model element, removing or replacing one), as stated in Wagner (2002), this may constitute a pragmatical framework to carry out easy transformations and a way to have the pattern rules (in XMI) easily available to CASE tools. The example in Figure 12 shows how a signal can be deleted from a model.

Start Figure

  1. XML fragment of the original UML model

    <UML:Signal xmi.id = 'a2'
 name = 'no_cd_detected'>
  <UML:Signal.sendAction>
   <UML:SendAction xmi.idref = 'a3'/>
  </UML:Signal.sendAction>
</UML:Signal>

  2. The XMI.difference part

    <XMI.content>
  <XMI.difference href="original.xml">
    <XMI.delete href="original.xml|a2"/>
  </XMI.difference>
</XMI.content>
End Figure

Figure 12: A simple transformation using XMI. difference

Abstracting with Programming Libraries

Our previous experience with Java and XML in the development of αSPIN has been very valuable. The tool provides full support for data abstraction in the XML representation of PROMELA models, and it is mainly composed of a graphical environment and an abstraction engine. αSPIN users select variables in the model along with the corresponding abstraction library to apply. Then, the abstraction engine uses the W3C standard Document Object Model to load an XML model, transforming it and then generating the resulting abstract version.

Our abstraction API (see Figure 13), includes specialized data structures for managing Variables and Operations existing as XML elements in the model. This is the goal of the VarManager and OperationManager container classes. Every Variable object includes references to all the Operations in which it is involved. The Operation object also stores the unary/binary/ternary structure of the operation itself, containing references to operands.

Click To expand
Figure 13: The extended abstraction engine API

Along with these classes, the abstraction API incorporates containers to manage abstraction libraries. These are a collection of abstract operations that will substitute the original ones after the abstraction process. The abstraction libraries are also stored in XML format, and may be validated using its corresponding Document Type Definition (DTD).

Compared with XSLT-based transformations, the use of an object-oriented language to perform abstractions is a very flexible option; the abstraction engine consecutively selects variables to be abstracted from a list supplied by the user. For each variable, the (concrete) operations in which it appears are analyzed and substituted by their corresponding abstract versions extracted from a library. As a collateral effect, if an operation relates another variable with the one being considered at the moment, that will be included in the list for later abstraction. The abstraction engine also benefits from the use of popular design patterns (Gamma, Helm, Johnson, & Vlissides, 1995).

All these changes are made with the DOM Document tree in memory. The dom4j open-source API (Dom4j, 2003) has been used. Among other features, we want to emphasize its performance and full Xpath capabilities.

An alternative way to manipulate XMI/MOF-based models using programming facilities is the use of Java JMI (Java Metadata Interface). The JMI Specification implements a dynamic infrastructure to manage MOF metadata. JMPI is based on the Meta Object Facility basic building blocks, and defines a generic programming mechanism that allows access to and manipulation of metamodel instances. Therefore, the semantics of any modeled system, like UML, are available to programmers. JMI defines standard Java interfaces to these modeling components. The interfaces are generated automatically from the MOF metamodels description. The specification also incorporates mechanisms to interchange metadata using XMI.

Perhaps the most employed implementation of the JMI specification is the MDR API from the NetBeans project (NetBeans, 2003). NetBeans MetaData Repository (MDR) provides a generic interface to deal with all types of MOF-based metamodels. Along with this approach, the use of JMI facilities allows the selection of a metamodel describing a particular modeling language, and then generates a specific API which provides programmatic means to handle and navigate model instances. We have used MDR to generate Java classes and interfaces to manipulate UML 1.3 and UML 1.4 models including UMLClass, UMLPackage, Association, Dependency, SignalEvent or StateMachine, among others.

These new facilities have motivated the extension of the abstraction engine in order to incorporate manipulations through JMI. The final version of this new abstraction API is partially depicted in Figure 13. The abstraction process has been decoupled from the main class. This makes it possible to quickly introduce different templates to perform abstractions; the UMLEvents Template is suitable to perform the abstraction of events as described before. At the same time, we have the PromelaVarsTemplate that encapsulates the transformation rules related to data abstraction in XML PROMELA models. The container classes have been slightly modified to be able to store many kinds of abstraction targets: EventTargets or VarTargets. The OperationManager now contains specialized objects derived from an AbstractOperation class. Finally, the AbstractionTemplate class defines a template pattern. The methods to be specialized by corresponding subclasses have to implement the analyzeModel, insertContents, abstractContents, and updateModel, which are executed in that order. This constitutes a clear and easy extension methodology for both data and event abstraction processes.

In order to illustrate the use of JMI, Figure 14 depicts part of the UMLEventsTemplate code, simplified for the sake of clarity. Lines 1 to 6 read an XMI model, creating its corresponding structure in memory. The process of iterating through the statechart is depicted from lines 10 to 19. This operation stores event definitions (Signals), along with the place in which these events are used (SignalEvents). Following lines perform the abstraction process, replacing selected signals by the corresponding abstract one (line 22). Finally, the update step is executed (lines 30 to 34), writing changes to an output XMI file (lines 35 to 40).

Start Figure
1     XmiReader xmireader =
2     (XmiReader)XMIReaderFactory.getDefault().createXMIReader();
3      try{ //reading statechart file
4       String uri = new File(FILE_IN).toURL().toString();
5       xmireader.read(uri,umlExtent);
6     }catch(Exception e){}
7     ...
8      List signalsRef = new LinkedList(); //signals to abstract
9      List signalEvents = new LinkedList(); // calls to signals
10     Iterator elements = namespace.getOwnedElement().iterator();
11     while(elements.hasNext()){
12      Object obj = elements.next();
13      if(obj instanceof Signal){
14       Signal sg = (Signal)obj;
15       if(concreteSignalNameList.contains(sg.getName()))
16           signalsRef.add(sg);
17      }else if(obj instanceof SignalEvent)
18         signalEvents.add(obj);
19     }
20     //Replacing the first signal by the abstract one, as example
21     Signal abstractSignal = (Signal)signalsRef.get(0);
22     abstractSignal.setName(ABSTRACT_SIGNAL);
23      signalsRef.remove(0);
24     Iterator it = signalsRef.iterator();
25     while(it.hasNext()){ //Deleting concrete signals
26      Signal signalToDelete = (Signal)it.next();
27      signalToDelete.refDelete();
28     }
29     it = signalEvents.iterator();
30     while(it.hasNext()){ //updating SignalEvents
31      SignalEvent sevnt = (SignalEvent)it.next();
32      if(sevnt.getSignal()==null)
33          sevnt.setSignal(abstractSignal);
34     }
35     Xm/Writer xmiwriter =
36     (Xmi/Writer)XMIWriterFactory.getDefault().createXMIWriter();
37     try{ //write changes to file
38      FileOutputStream fout = new FileOutputStream(FILE_OUT);
39       xmiwriter.write(fout,umlExtent,null);
40     }catch(Exception e){ ... }
End Figure

Figure 14: Part of the JMI-based code for XMI abstraction


Future Work

The αSPIN tool needs to abstract not only PROMELA models, but also those requirements to be verified (LTL formulas). In fact, data variables involved in the definition of such formulas are what determines the selection of a particular abstraction library.

By adapting this approach to the abstraction of events in UML models, we find that UML sequence diagrams may be employed to define verification scenarios (as a complement to the formal specification of properties in a tool-dependant logical formalism). Desirable (or nondesirable) execution scenarios are usually described using these kinds of diagrams. For example, a diagram like the one in Figure 15(a) represents a situation where the CD system plays music without the corresponding play request (see the last events in the sequence).

Click To expand
Figure 15: Sequence diagrams for an erroneous behavior: (a) original, (b) abstract version

Therefore, one future work will consist of implementing the proposal in Gallardo et al. (2002) to verify requirements expressed in UML sequence diagrams. It is worth noting that for any implementation of the new verifier (i.e., an extension of STATEMATE), abstraction capabilities would be helpful to reduce the state space (see Figure 15(b)). We plan to exploit the XMI representation, along with the abstraction API discussed in this chapter to deal with this new verification methodology.


Conclusion

This chapter has presented clear trends in the evolution of UML-based verification tools. The opportunity to employ XML-related technologies such as XMI makes it easy to extend these tools in order to incorporate novel optimization approaches. Abstraction for model checking is an exciting research field that could improve the verification of those complex systems modeled using UML behavior diagrams. Valid abstractions for industrial UML designs are currently an open problem that occurs in general for abstract model checking with other languages. Currently, some related projects are developing collections of abstraction functions (see, for instance, Hatcliff, Dwyer, Pasareanu, and Robby (2003) and Holzmann, (2003).

The XML approaches described in this chapter include XSLT stylesheets, XMI.differences, or programming APIs like the Document Object Model and the Java Metadata Interface. In particular, the use of the Java object-oriented language and some well-known design patterns have constituted the basis for the development of a flexible abstraction engine API. Our previous work with data abstraction applied to XML PROMELA models in αSPIN has been decisive in order to design a prototype for abstracting events in XMI UML statecharts.

We hope that tool suppliers will also consider the clear benefits of XML to describe and export their particular tool-associated action languages. This would be of great interest because it would allow combining the two abstraction methodologies described here (data and events) to improve the whole verification process, in particular when new abstraction functions become available. As a final conclusion, having CASE tools with model checking and abstraction capabilities should be considered a first step towards the verification of industrial (huge) UML designs.


Acknowledgments

The authors would like to thank the reviewers for their suggestions and useful comments. This work has been supported by projects TIC2002-04309-C02-02 and TIC2001-2705-C03-02.


References

Clarke, E., Emerson, E. A., & Sistla, A. (1986). Automatic verification of finite-state concurrent systems using temporal logic specifications. A CM Transactions on Programming Languages and Systems, 8(2), 244–263.

Clarke, E., Grumberg, O., & Long, D. (1994). Model checking and abstraction. ACM Transactions on Programming Languages and Systems, 16(5), 1512–1542.

Cousot, P., & Cousot, R. (1977). Abstract interpretation: A unified lattice model for static analysis of programs by construction or approximation of fixpoints. In ACM Symposium onPrinciples of Programming Languages, pp. 238–252.

Dams, D., Gerth, R., & Grumberg, O. (1997). Abstract interpretation of reactive systems. ACM Transactions on Programming Languages and Systems, 19(2), 253–291.

Demuth, B., & Obermaier, S. (2001). Experiments with XMI based transformations of software models. Workshop on Transformation in UML.

Dom4j. (2003). The dom4j XML library. Retrieved from http://dom4j.org

Dominguez, E., Rubio, A., & Zapata, M. (2002). Mapping models between different modelling languages. Workshop on Integration and Transformation of UML models.

Ehrig, H., Engels, G., Kreowski, H., & Rozenberg, G. (1997–99). Handbook on graph grammars and computing by graph transformation (1–3). Singapore: World Scientific.

Gallardo, M., & Merino, P. (1999). A framework for automatic construction of abstract PROMELA models. Theoretical and Practical Aspects of SPIN Model Checking, 1680, 184–199. Springer-Verlag.

Gallardo, M., & Merino, P. (2000). A practical method to integrate abstractions into SDL and MSC based tools. In Proceedings of the 5th International ERCIM Workshop on Formal Methods forlindustrial Critical Systems pp. 84–89. Berlin.

Gallardo, M., Martinez, J., Merino, P., & Pimentel, E. (2004). αSPIN a tool for abstract model checking. Software Tools for Technology Transfer, 4, 165–184. Springer-Verlag.

Gallardo, M., Merino, P., & Pimentel, E. (2002). Debugging UML designs with model checking. Journal of Object Technology, 1(2).

Gallardo, M. M., Merino, P., & Pimentel, E. (2002). Refinement of LTL formulas for abstract model checking. In 9th International Static Analysis Symposium SAS '02, pp. 395–410. Springer-Verlag.

Gamma, E., Helm, H., Johnson, R., & Vlissides, J. (1995). Design patterns. Boston: Addison-Wesley.

Gerber, A., Lawley, M., Raymond, K., Steel, J., & Wood, A. (2002). Transformation: The missing link of MDA. In Lecture notes in computer science (2505). Springer-Verlag.

Harel, D., & Naamad, A. (1996). The STATEMATE semantics of statecharts. ACM Transactions on Software Engineering and Methodology, 5(4), 293–333.

Harel, D., Pnueli, A., Schmidt, J., & Sherman, R. (1987). On the formal semantics of statecharts. In Proceedings of the 2nd IEEE Symposium on Logic in Computer Science, pp. 54–64. New York: IEEE Press.

Hatcliff, J., Dwyer, M., Pasareanu, C., & Robby, (2003). Foundations of the bandera abstraction tools. In The essence of compution, pp. 172–203. Springer-Verlag.

Holzmann, G. (2003). The SPIN Model Checker. Primer and Reference Manual. Boston: Addison-Wesley.

I-Logix. (2002). STATEMATE MAGNUM. Retrieved from http://www.ilogix.com

I-Logix. (2003). Model certifier user guide 2.2. Retrieved from http://www.ilogix.com

IAR. (2003). IAR Visual State. Retrieved from http://www.iar.com

ITU-T. (2000). Z.120 - Message sequence chart (MSC).

Knapp, A., Merz, S., & Rauh, C. (2002). Model checking timed UML state machines and collaborations. In Formal Techniques in Real-Time and Fault-Tolerant Systems, pp. 395–416. Springer-Verlag.

Latella, D., Majzik, I., & Massink, M. (1999). Automatic verification of a behavioural subset of UML statechart diagrams using the SPIN model-checker. Formal Aspects of Computing, 11(6), 637–664.

Lilius, J., & Porres, I. (1999). vUML: A tool for verifying UML models. In 14th IEEE International Conference On Automated Software Engineering (Ase'99), pp. 255–258.

Manna, Z., & Pnueli, A. (1992). The temporal logic of reactive and concurrent systems -Specification. New York: Springer-Verlag.

Mikk, E., Lakhnech, Y., Siegel, M., & Holzmann, G. (1998). Implementing statecharts in PROMELA/SPIN. In Proceedings of Workshop On Industrial-Strength Formal Specification Techniques (WIFT' 98).

NetBeans. (2003). The NetBeans Metadata Repository (MDR). Retrieved from http://mdr.netbeans.org

Object Management Group. (2001). UML 1.4, object constraint language specification.

Object Management Group. (2002a). Meta object facility specification (MOF) 1.4.

Object Management Group. (2002b). OMG unified language specification (Action Semantics), UML 1.4 with Action Semantics.

Object Management Group. (2002c). XML Metadata Interchange (XMI) 1.2.

Peltier, M., Bezivin, J., & Guillaume, G. (2001). MTRANS: A general framework, based on XSLT, for model transformations. Workshop on Transformation in UML.

Pettersson, P., & Larsen, K. G. (2000). Uppaal2k. Bulletin of the European Association for Theoretical Computer Science, 70, 40–44.

Pollet, D., & Vojtisek, D. (2002). OCL as a core UML transformation language. Workshop on Integration and Transformation of UML models.

Saez, J., Toval, A., & Fernandez, J. (2001). Tool Support for Transforming UML Models to a Formal Language. Workshop on Transformation in UML.

Schäfer, T., Knapp, A., & Merz, S. (2001). Model Checking UML State Machines and Collaborations. Electronic Notes in Theoretical Computer Science, 55(3).

Schmidt, A., & Varró, D. (2003). CheckVML: A tool for model checking visual modeling languages. In Uml 2003 - the unified modeling language: Modeling languages and applications, pp. 92–95. Springer Verlag.

Stevens, P. (2003). Small-scale XMI programming: A revolution in UML tool use? Journal of Automated Software Engineering.

Telelogic. (2003). SDL Suite. Retrieved from http://www.telelogic.com

Vardi, M., & Wolper, P. (1986). An automata-theoretic approach to automatic program verification. In Proceedings Symposium On Logic In Computer Science, pp. 332–344.

Varró, D., Gyapay, S., & Pataricza, A. (2001). Automatic transformation of UML models for system verification. Workshop on Transformation in UML.

Wagner, A. (2002). A pragmatical approach to rule-based transformations within UML using XMI.difference. Workshop on Integration and Transformation of UML models.


Chapter XI: Support for Architectural Design and Re-Design of Embedded Systems

Alessio Bechini,
Università di Pisa,
Italy
Cosimo Antonio Prete,
Università di Pisa,
Italy

The market pushes the continuous evolution of embedded appliances (cellular phones, hand-held games, medical machinery, automotive systems, etc.). The assistance of appropriate methodologies and tools for supporting system-level design of embedded systems has become necessary for the development of appliances with tight constraints on performance, cost, and safety. Moreover, it is crucial to be able to rapidly and effectively modify appliances in order to meet new possible requirements. This chapter addresses the architectural design and redesign of embedded systems from a methodological viewpoint, taking into account both the hardware and software aspects; the final goal is to figure out the most convenient structure for the investigated system. In this context, the employment of both UML and XML can be regarded as an important step to substantially improve the overall design process.

Introduction

An embedded system is a combination of computer hardware and software, and often of mechanical or other parts as well. It is designed to perform a specific function or range of functions, usually to control some physical system or to communicate information, providing a service to the end user (Wolf, 2000; Berger, 2001; Barr, 1999). Embedded systems contain a number of diverse components, each of them contributing to the overall system functionality. Frequently, an embedded system is itself a component within some larger system, and it is not perceived as a computer by the end user. For instance, modern cars contain many embedded systems: devices that control anti-lock brakes, others that monitor and control the emission of gases, and so forth. In the consumer electronics market, the basic components of cellular phones can be regarded as typical examples of embedded systems supporting telecommunication features. Actually, if an embedded system is designed well, the existence of both processor and software could be completely unnoticed.

The application software provides the basic functionality, and it represents one major part of the whole embedded system; sometimes it may rely on a simple operating system as well. Usually the software cannot be modified once it is deployed upon the target device. Among the strict requirements given for embedded systems, the low cost is one of the most critical, as its fulfillment may determine the success of the designed device in the market. Although a limited number of hardware and software resources must be employed for this purpose, the user-perceived quality of the final system has to be guaranteed anyway. Low power consumption is another important constraint, especially for hand-held devices, and this challenging issue is currently investigated by a larger and larger community of researchers. Finally, safety plays a crucial role in several categories of embedded systems, for example, control devices for industrial processes, automotive applications, surgical instrumentation, and so forth. Diversity of requirements within distinct application areas can be definitely regarded as the main cause for the large assortment of microprocessors and architectural solutions currently employed (Schlett, 1998).

Embedded software is becoming more and more computing-intensive because of the introduction of complex graphical user interfaces, new communication features, and so forth. Hence, the computing power of the underlying platforms must be accordingly improved (Nayfeh et al., 1996; Prete et al., 1997), and this is not a trivial goal, especially for hand-held devices. Any feasible solution for performance improvements must keep the power consumption low as well: for this reason, we cannot reasonably increase the CPU clock rate over and over, as it often happens for general-purpose systems. Low cost and low power consumption requirements have been the driving factors for the employment of multiple simple CPU cores on the same chipset: together, such cores are able to provide the required computing power (Prete et al., 1997; Bechini & Prete, 2001; Nayfeh et al., 1996; Lewis & McConnell, 1996). Nowadays, a whole complex system, encompassing CPU cores, peripheral controllers, buses, memories, and so forth, can be integrated on a single chip; such an IC is usually known as a SoC (System on Chip). Each specific basic module the chip is made of is usually referred to as an "IP" (Intellectual Property); that is each IP is a complete project for a single component (CPU, controller, etc.), and it can be purchased and incorporated in special-purpose chipsets. In particular, SoC multiprocessors are currently used in the market, and they possibly exploit heterogeneous CPU cores and also DSPs (digital special-purpose processors capable of fast integer/floating point operations for digital signal processing). We must emphasize also that software applications themselves must be properly organized, or reorganized, to keep pace with ever-increasing performance needs. Programmers of embedded applications are not used to leverage parallel hardware platforms, because usually in the past this kind of software has always been plainly sequential. A naive subdivision of activities among the underlying processors does not allow a satisfactory exploitation of the hardware parallelism. In this situation, a simple and precise methodology for the design space exploration and for the corresponding software organization may be of invaluable help, especially whenever multiprocessor platforms are involved.

Various methodologies aimed at guiding the design of software architectures have been proposed recently (Williams & Smith, 1998; Culler et al., 1999; Kazman et al., 1996), and they have been thought to deal with large-scale, possibly distributed software applications (e.g., information systems) running on a variety of different platforms. Furthermore, a wide variety of requirements such as modifiability, availability, security, and performance have been taken into consideration (Kazman et al., 1999). This kind of software system is also the ideal target for conceptual frameworks for object-oriented development like MDA (Model-Driven Architecture (Mellor et al., 2002; Raistrick et al., 2004). On the contrary, most of the systems addressed in this chapter may present a limited degree of parallelism. In this case, the software application must meet performance goals by exploiting the computational power of the underlying parallel platform, with a small number of CPUs; moreover, scalability issues are usually not fundamental in the embedded systems environment.

The selection of the system architecture generally requires a thorough work of performance prediction. Although many approaches are possible to carry out this job (Bernardo, 1999; Culler et al., 1993; Mehra et al., 1994), it has been found (also according to our experience, Prete et al., 1997; Bechini & Prete, 2001) that the use of simulations is appropriate in this setting. The execution environment for embedded software is typically very stable, as the hardware platform is dedicated to single applications: for this reason, the performance estimates are on average more accurate than those obtained for general-purpose systems.

The system architecture may be parallel both in the hardware and in the software components. Designing an efficient parallel application is not a trivial task. The prime point is the identification of all the application activities that are not tightly coupled among each other, and may be run in a mostly independent way. Then, it is crucial to understand which and what kinds of interactions are required for the coordination of such activities, how the system resources should be used, and how data have to be accessed by processes. In general, a parallel program can be structured according to several different solutions/templates (Culler et al., 1999). Most of the models, methods, languages, and programming environments proposed for parallel computing are not suitable to the development of embedded systems. The reuse of software components is commonly adopted in industry, as it is a particularly advantageous practice. If the source code is not available for third-party components, the designer is constrained to address application parallelism only at the architectural level (Shaw & Garlan, 1996), as the use of more traditional parallelization techniques at the source-code level is not feasible. Moreover, the need of reasoning in terms of software architecture rises whenever the embedded software application becomes considerably large, and it can definitely benefit from the adoption of the object-oriented paradigm (Laine, 2001). Williams and Smith (1998) openly point out the crucial role played by architectural design: "While a good architecture cannot guarantee attainment of quality goals, a poor architecture can prevent their achievement." The assistance of appropriate methodologies and tools for supporting system-level design of embedded systems has become necessary for the development of appliances with tight constraints on performance (Lee, 2000; Sangiovanni-Vincentelli & Martin, 2001; Laine, 2001; Barr, 1999). The next section of this chapter addresses the architectural design of embedded systems from a methodological viewpoint, taking into account both the hardware and software aspects; the final goal is to figure out the most convenient structure for the investigated system.

The market pushes the continuous evolution of embedded appliances (cellular phones, hand-held games, medical machinery, automotive systems, etc.) In this scenario, it is crucial to be able to rapidly and effectively modify the overall appliances, operating either on the supporting hardware or on the software applications, in order to meet new requirements. In the development process for an embedded appliance, designers are asked to deal with issues pertaining both to the hardware and to the software aspects of the whole system. In particular, some components may be already available or given, setting up tight constraints in the design exploration process. For example, most of the software application might be built using previous versions already developed and tested within the same enterprise, or the supporting hardware platform has to be chosen from those produced by a commercial partner industry. We can try to identify the possible operating conditions for designers who are asked to build up a new product:

  1. Nothing is given and everything must be developed from scratch. In this case, a viable methodology may proficiently be based on a co-design approach (Kumar et al., 1995; Wolf, 2003).

  2. The hardware platform is given, but a software application must be arranged upon it. We can distinguish a couple of subcases, corresponding to different degrees of freedom for the designer:

    1. The software application must be written from scratch.

    2. An existing software application must be retargeted to the new platform. In this case, it may be convenient to alter the software architecture and/or to rewrite specific application portions.

  3. The application is given, but the hardware platform must be chosen. Also in this operating condition, two different settings may be experienced:

    1. A number of different existing platforms must be evaluated, taking into account the effort and the result of the porting process for the software application.

    2. A new hardware platform can be designed from scratch (possibly with some constraints), thus we can choose to directly implement in hardware some of the most critical tasks, or to reuse and/or modify available IPs.

Another situation that is particularly worth being analyzed occurs whenever some kinds of improvements become necessary for an existing system. In this case the designer is asked to drive the evolution of an embedded device, through a process of redesign starting from what has been achieved so far. One of the following circumstances may take place:

  1. The software application must have new features added, or a performance improvement is required by some of the existing ones. This case is similar to what has been exposed in 2b above, but, a substantial difference occurs: the description of the hardware platform is already present, and the application model must only be properly modified. After an examination of the performance estimates for the redesigned system, it might also turn out that the old platform is not able to guarantee the fulfillment of the compulsory performance requirements. Then, the design space investigation possibly becomes trickier, as simultaneous changes in the hardware platform and in the application structure should be checked out. From a practical standpoint, it is often feasible and sensible to change the software first, and to choose the most convenient platform for it out of a set of eligible ones.

  2. Some improvements in the hardware peripherals must be introduced (e.g., a cellular phone must be equipped with a wider LCD display). This fact usually yields limited modifications to the software application (provided that it has been properly designed and implemented). The most unpleasant consequence, which can be easily predicted using the already available models for the system, is the violation of the performance requirements for the upgraded system. In case this would happen, we had to find a new appropriate structure for the system (operating on the hardware platform and/or on the software application).

One of the most significant novelties in the field of embedded systems development is the introduction of both UML and XML in the architectural design. The use of UML in the description, documentation, and design of any kind of systems has been recently adopted also by the embedded systems community: for example, one of the most popular educational texts in this field follows this main streamline (Wolf, 2000). In particular, it is possible to leverage the power of these two technologies in the modeling of a whole embedded system (which is a parallel system in the majority of cases), encompassing both the hardware and software aspects.

Models (expressed by means of UML and XML) are dealt with by simulation tools that, through performance estimations, are able to drive the designer's choices. The overall structure of a typical simulator that makes use of XML and UML models is shown in Figure 1. This kind of model gives us the opportunity to quickly deal with any modification that may become necessary for the system; in fact, the reuse, modifiability, and reengineering of the employed components is made easier by the adoption of UML and XML. Moreover, a large portion of modern embedded systems has to do with realtime constraints, and UML (or UML-related technologies) can be used to describe and design real-time systems as well (Gomaa, 2000). Thus, we can use a unique formalism to deal with many different aspects of the same device, making easier the management of the overall project.

Click To expand
Figure 1: Overall structure of the high-level simulator HL Perses

A possible alternative approach in the upcoming years might be based on xUML, that is, a UML profile that supports the execution of UML models (Mellor & Balcer, 2002; Mellor et al., 2002). The xUML language is an abstract thinking tool for formalizing solutions to software development problems, independent of the software organization. This last fact makes clear why at present xUML is not directly exploited in the field of embedded systems, whose hardware and software components are so tightly coupled. The capability to manage testable and verifiable xUML models is particularly important in addressing safety issues; this aspect might encourage its adoption, even in the framework of the methodology presented in this chapter.

The remainder of this chapter is organized as follows: a typical design (or redesign) methodology for embedded systems is outlined first, focusing on architectural issues; the following section presents the structure of a high-level simulation tool to be used in supporting the design methodology; afterward, a case study illustrates the application of both the proposed methodology and tool for the design of a digital cartographic system. Throughout the whole chapter, it is underlined how the use of UML and XML leads to a more manageable and efficient design and redesign process. Proper conclusions are finally drawn.


Architectural Design: A System-Level Approach

Design of embedded systems at the hardware architecture level usually follows either an approach (typically employed in co-design (Kumar et al., 1995)) in which a model of the whole system is refined into an actual architecture or an investigation on a set of possible eligible architectures, testing how each of them behaves in supporting the target software application (Bechini & Prete, 2001). The last method is often referred to as the Y-chart approach (Kienhuis et al., 2001; Pimentel et al., 2001), used at different levels of abstraction. The Y-chart approach tries to clearly state the roles of both the platform and the application, and it operates on a model for each of the two. Although this approach has been historically used in the field of hardware architectures (software is given, and hardware can be changed), its basic philosophy can be applied to investigate software architectures as well (hardware is given, and software structure can be changed).

Hereafter we show a simple extension of the Y-chart approach to be used in the design space exploration of architectural solutions for embedded applications. It relies upon performance estimates of a pool of architectures that apply different solutions in their internal computing-intensive activities. In modern embedded systems, different parallel software solutions may exploit the underlying hardware with different degrees of efficiency. The methodology, in its most abstract form, can be called Ψ-chart approach (see Figure 2 and notice the shape of the included diagram); it incorporates three preliminary tasks, intended for producing

Click To expand
Figure 2: The basic architectural design methodology (ψ-chart approach) illustrated by means of an UML Activity Diagram. Here, one single feedback path to the Software Application Characterization is shown, but also the execution environment can be possibly reworked out.

  1. a model of the platform that supports the software application;

  2. a model of the main behavioral aspects of the system, encompassing mainly a characterization of the software application, both in its structure and performance; and

  3. input test cases, aimed at driving the system into particularly meaningful operating conditions (e.g., under a typical or worst-case computational load).

Steps i) and ii) have to be applied for each architectural solution that must be evaluated. It should be clear that the two distinct models obtained in steps i) and ii) are not set to provide a sharp separation of the hardware and software features of the system; instead, they should emphasize the importance of both the behavioral aspects and the supporting platform. For example, a special-purpose ASIC like a graphical accelerator, although it physically belongs to the hardware support, can be modeled through the introduction of a CPU-like component in the platform description, and through an account of its own functionality in the behavioral model.

In the ψ-chart approach, one concluding task is in charge of working on these models and input test data (highlighted in Figure 2), deriving estimates of the system performance. Once such results are available, they can be evaluated against the system requirements; if they are not deemed satisfactory, then they must be accurately studied, trying to get hints on how to improve the overall system design in the next iteration of the described process. It is important to point out the central role played by the input test cases because current software applications in the embedded market are complex and input-sensitive, and might behave quite differently depending on the input data.

The ψ-chart approach can be followed also in redesign of an embedded system. The redesign process, as already discussed in the introduction, is triggered by the need to change something in the system specifications. The existing implementation must evolve towards a new product, possibly requiring modifications of the system architecture. The redesign process can proficiently take advantage of all the work that has been previously done: both the platform and the behavioral models are available, and they can be properly changed to explore new different architectures for the next-generation system. The steps of the Ψ-chart approach can be iterated until a satisfactory solution is found. It is clear that the efficacy and convenience of this way to cope with redesign mostly depend on the reliability, manageably, reusability, and flexibility of the technologies actually used for building and expressing the system models.

The ψ-chart approach, as presented so far, is quite simplistic and can be further detailed in order to directly tackle a number of specific design issues. First, it is important to identify all those software activities within the application that are worth being modeled. Moreover, the execution environment might encompass both the hardware platform and a possible simple operating system, and we should be able to capture their main features in the platform description. Another crucial problem is the selection of input test data: we should outline some criteria to carry it out properly. Finally, we have to specify the process used to obtain performance models of software architectures, a quantitative characterization of the performance models, and the mapping of different tasks onto processors.

A Refined ψ-Chart Approach

The software application characterization and the input domain analysis are closely related activities. The more computing-intensive some application portions are, the more they are worth being explicitly taken into account in the modeling of behavioral aspects, because of the potential performance problems they may raise. The input test cases should sensitize such portions, making the system run under critical conditions. We can observe that a first behavioral description at a very abstract level may provide useful information to the selection of input test cases, and it can be used also as a common starting point to delineate a number of different, more detailed, architectural solutions. This idea can be used in refining the ψ-chart approach, as shown in Figure 3.

Click To expand
Figure 3: The architectural design process envisioned by an UML activity diagram. In this scheme is shown a feedback path to the Refinement & Tuning Process, but the designer may choose to re-operate on other activities. No more reworking iterations are needed after the achievement of the desired results.

In this more detailed version of the methodology, two tasks have to be carried out first:

  • Coarse-grain application characterization. The system specifications are analyzed first, in order to accordingly draw a high-level account of the application structure (indicated as high-level behavioral description in Figure 3). Such a description is not required to precisely outline the internal arrangement of the main modules, but it must be accurate enough to uncover the most critical activities that influence the system performance (especially as it is perceived by the end user).

  • Execution environment characterization. This is the same activity already present in the simplistic Ψ-chart approach. The execution environment is quantitatively characterized, considering both the hardware aspects and the capabilities and settings of the operating system or runtime support (if any is present). The outcome of this operation is a platform description containing all the system details that might significantly affect the application performance: for example, the number of CPUs, the features of each CPU, the process/processor allocation strategy, the possible use of process preemption, the support for process migration, the scheduler policy, the time spent on average in a context switch, and so forth. A number of these details may be taken directly from the system specifications, and others can be gathered through measurements on the actual platform (Jain, 1991).

After these two preliminary activities, we have to obtain both input test cases and more detailed performance models for a number of specific architectural solutions (those we plan to evaluate). Thus, at this point, the high-level behavioral description can be used as an important tool to figure out the most critical activities. For the accomplishment of this task we need to know how end users usually operate the overall system. A proper conceptual tool in this setting is the notion of use case (Kazman et al., 1996). The application, under a given use case, works toward achieving specified goals, and exercises identifiable paths, exploiting portions of the modules it comprises. UML (Booch, Jacobson, & Rumbaugh, 1998) currently employs the notion of use cases. Thus, in the proposed methodology, we go on to carry out the following task:

  • Selection of use cases. This has to be carried out by means of a thorough inspection of both the high-level behavioral descriptions and user requirements. Often, in object-oriented design methodologies, use cases are pointed out at the very beginning, before any structural characterization of the application. In this situation, the described selection operation is considerably simplified. Among all use cases, we have to single out those that determine a significant computational load. Then we can focus only on specifying performance-critical portions of the application in a precise way; along with our interest in the architectural system design, the rest of the application does not deserve further attention.

As soon as the critical use cases have been told apart and the corresponding application portions have been determined, the following activity can take place:

  • Input domain analysis. This is aimed at finding out input data that sensitize the application portions exercised in the critical use cases. The outcome of this operation is a set of input test cases. Usually, we need to point out at least two input test cases for the selected use cases: one that generates the highest stress for the system, and another that contain the typical input data, likely to be requested by final users most of the time.

Until now, in the refined ψ-chart approach, we have not dealt with any actual description of architectures. Now, exploiting information from the high-level behavioral description, the selected use cases, and the platform description, we can outline a set of possible architectural solutions to investigate. All this is done in the following task:

  • Refinement & tuning process. This is aimed at producing a set of actual architectural solutions to be analyzed later on. This activity is organized in two steps. The first is the refinement of the high-level description into a set of candidate architectural solutions (possibly parallel solutions). Each candidate solution is characterized by a specific processing strategy in the system implementation. The refinement operation is typically applied only to performance-critical portions of the complete system. One candidate solution can be regarded as an abstract summary of multiple similar architectures, differing just in simple structural details (e.g., the number of processes employed for a well-defined operation). Therefore, the second step within the current task is the architecture tuning, that is, the choice of those instances of the candidate solutions that deserve further investigation. The end result is a set of tuned architectures, which represent different reasonable actual implementations of the selected candidate solutions. Besides, until now, no information has been provided about the performance behavior of the chosen architectures.

The operations described so far, and dealing with behavioral aspects of the system, can be carried out making use of UML (Booch et al., 1998; Conallen, 1999)[1]. Although other modeling languages may be chosen, and although in particular settings other specific tools might be preferable, a number of practical and sensible reasons advocate the adoption of UML:

  • It is simple to use for describing software applications and concurrent and real-time applications as well (Gomaa, 2000). At present, it is widely used in industry, and it is often possible to obtain UML specifications of third-party components used in assembling embedded applications.

  • It makes use of an object-oriented approach, which is commonly recognized to be suitable to improve the design and software neatness, and contribute to the software reusability and maintainability (object-oriented development is not currently as popular in the community of embedded systems developers as in other IT fields).

  • It is easily understandable, even by non-experts, and many of the diagrams produced in the design process can be reused for a detailed documentation of the final product.

  • In a number of commercial tools supporting the UML design process, it is possible to automatically obtain some simple product prototypes; moreover, specific UML profiles like xUML (Mellor& Balcer, 2002) can be used to get additional information about the system behavior by their direct execution.

  • It is a formal description language, and likely commercial tools will be available soon, aimed at supporting the refinement process (from the high-level behavioral description down to the tuned architectures). Additionally, formal models of this kind can also proficiently be used to address safety issues as well.

The behavior of all the just-selected tuned architectures has to be evaluated. In carrying out this operation, it is important to take into account those use cases that could determine performance problems. We shall name scenarios such particular instances of use cases upon tuned architectures. Hence, each architecture is evaluated according to the performance shown in the corresponding scenario(s). The quantitative description of the system behavior is carried out in the next steps:

  • Performance description and parameter inference. This activity is aimed at producing proper performance models for the chosen tuned architectures. It consists of two operations. (1) Performance description, whose outcome is a set of parametric models corresponding to the selected scenarios. The models summarize the computational activity, and parameters are used to increase their flexibility; a single parametric model expresses a whole class of solutions. Another important role for parameters is to express dependencies of performance behavior from input data. (2) Parameter inference, that is, the assignment of proper actual values to most of the parameters. The purpose of this setting is to make the models fit as well as possible the real performance behavior of the system under the selected scenarios and with every possible input data. At the end, performance of each selected architecture is characterized by a set of scenario performance models.

At the completion of the operations described above, enough material has been prepared to proceed towards the performance prediction activity, which requires, as input data, the scenario performance models, the input test cases, and the platform description. This activity can be carried out making use of an assortment of conceptual or actual tools; the possible approaches can be typically classified as analytical or simulative. Certainly, performance models must be consistent with the specific tool used for performance prediction. The outcome of this central activity is a collection of Performance Results (see Figure 3) about the performance behavior of scenarios under investigation. If such results are not satisfactory, the designer is required to go backward, with the purpose of working up a different overall system design, operating on the supporting platform and/or on the software architecture. The conclusion of this cyclic process is settled on the achievement of proper performance levels, according to levels stated by the system requirements. It must be underlined that the behavior of a specific architecture can be described by means of the results about all its related scenarios. The performance results are then used in the very last activity: the architecture selection.

In the framework of the proposed methodology, performance issues play a crucial role. Furthermore, performance prediction can be carried out by means of very different approaches, depending also on the operating abstraction level. Thus, in the following section we show a possible way to tackle performance modeling and prediction in the field of architectural design of embedded systems.

[1]Other suitable description formalisms can be found among formal methods (e.g., Petri nets, extended FSMs (Lewis & McConnell, 1996), process algebras (Bernardo, M., 1999), etc.), or ADLs (Medvidovic & Taylor, 2000).


High-Level Simulation of Embedded Systems

The ψ-chart approach can be successfully applied as long as a reliable performance prediction can be carried out. Although analytical methods can be used for this purpose, the employment of simulations is shown to be an appropriate and flexible solution in a large number of practical settings. The accuracy of simulations depends on the accuracy of the employed performance models as well. Classical approaches to system-level simulation use an extremely thorough description of the complete system behavior, considering low-level details of the hardware platform and a precise account of the computational activity (using either a trace of memory references or a specially compiled version of the program, as, for example, in the simulators ChARM (Prete et al., 1997) and SimpleScalar (Austin, Larson, & Ernst, 2002). Besides the fact that such kinds of simulation are typically long-running, the main drawback in this approach is that only completely specified solutions can be investigated, and thus an exhaustive search on all the solutions is not practically feasible. Otherwise, such classical tools are well suited to the last phases of the design process.

A viable solution to carry out the first steps in the design exploration task is the adoption of more abstract models of the system. As we have noticed earlier, the main challenge in building abstract models is to keep all the basic system features, throwing away any unnecessary detail. Recently, some languages for system-level modeling of embedded systems have been proposed; among them, SystemC (Panda, 2001; see the SystemC Website in the references) is currently finding favor with a growing number of designers in the industrial setting. Although in the beginning it was created to replace the use of VHDL (in order to provide a common language for low-level designers and application developers), later it was expanded to cover system-wide modeling (Groetker, T., et al., 2002). SystemC is based on C++, and basically it encompasses a set of classes to be used in the components description. The overall idea is to adopt an object-oriented modeling approach and to simulate the system behavior making use of a simulation engine, which is an integral part of the SystemC libraries.

If we decide to adhere to the outlined design methodology, we must provide the simulation environment with two different kinds of models: the first one for the hardware platform and the second one for the software applications (more generally, for the behavioral aspects of the system). Hereafter we refer to a particular high-level simulator called HL Perses, which has been developed and used by the authors keeping in mind its typical employment along with the ψ-chart approach.

HL Perses employs event-driven simulation for obtaining performance results (Jain, 1991), exploiting a simulation engine that operates on an internal representation of the system models that are supplied as input. HL Perses has been developed in C++, and it takes full advantage of the object-oriented features of the language. Particularly, a number of C++ classes have been developed to encapsulate both structural and state information on each component type in the system model, and to specify the interconnections among different components. The objects making up the system models are organized into dynamic data structures (from the STL library (Musser, Derge, & Saini, 2001)); they can be regarded as the core of the whole simulation environment. During every simulated execution of the complete system, the simulation engine interacts with such an object model, repeatedly invoking components' methods to obtain the required data, and updating state information as needed.

This way of representing the system under analysis by means of an object model is similar to what is typically done in SystemC, whenever it is used for system-level design (Groetker, T. et al., 2002). The main difference is the way the models are specified by the designer. The direct description of the object model in a complex language like C++ may be impractical; moreover, if we are interested in high-level modeling, we should avoid the employment of many sophisticated features of C++. As a consequence, we can think of more user-friendly formats to specify both the platform model and the behavioral model. Furthermore, another valuable feature for the description formats would be the opportunity to be possibly worked out by other design tools as well.

HL Perses supports multiple user-friendly formats to specify input data. This is due to the introduction of software modules that are able to get the model descriptions in the allowed input formats, and accordingly set up the internal object model for the simulation engine. These tasks are typically carried out by parsers. The parsing module of HL Perses is in charge of building up the object model after the inspection of the input files containing the description of (i) the hardware model, (ii) the software model, (iii) the mapping of software components onto hardware components, and (iv) the input data for the software application.

Figure 1 shows the overall structure of the tool. Notice that the parsing module is based on an XML parser, and that additional submodules deal with model descriptions in ancillary user-friendly formats. The simulation engine handles the object model and gives, as outcome, data about the system performance and behavior. A proper GUI allows the arrangement of model descriptions, the interaction with the simulation engine, and the inspection and/or analysis of results. Also the simulation outcome is given in XML files, and they present the values for performance indexes (first of all runtime, because of its basic role (Sahni & Thanvantri, 1996)) and data for characterizing the usage of every component as well.

Modeling Hardware Platforms: The Role of XML

Inside the simulator HL Perses, the hardware platform is modeled by a set of objects (instances of specific C++ classes, each of them dedicated to a particular component type). Although object-oriented approaches to the architectural modeling are becoming familiar also for the community of designers of embedded systems, in our belief it suffers from some disadvantages. In particular, the underlying object-oriented paradigm does not necessarily always represent the best way to tackle the hardware system modeling. Along with the ψ-chart approach, it might be useful to keep apart the characterization of the architectural and the behavioral aspects of the system; this happens, for example, whenever the designer must choose what existing platform is more suitable to host a given application, or how the software structure of a given program should be rearranged to best fit the target device (Bechini & Prete, 2002).

As a consequence we think that, although the representation by objects is a very convenient way to deal with system modeling inside the simulation environment, it is not always the best solution for a practical description of a hardware platform. Instead, a more schematic account of architectural components and interconnections may be provided, as is usually done in many trace-driven simulators (Prete et al., 1997; Li & Horgan, 2000) and in several languages developed for application architectural descriptions (known as ADLs, see for example, Medvidovic & Taylor, 2000). For this reason, we introduced a platform description formalism of this kind, based on XML (see XML Website in the Reference list); it precisely defines both the syntactic rules and the constraints on the proper components' parameters through an XML schema. Figure 5 shows an example of this kind of XML schema. A platform description document (PDD) must be compliant with such an XML schema[2], and it must contain all the information required for the hardware model. A specific software module of HL Perses is in charge of reading a platform description document, validating it, and subsequently building the corresponding internal object model.

The XML formalism has been chosen in this case (and in similar settings as well (Coffland & Pimentel, 2003)) for two main reasons:

  • It is an established vehicle for effortlessly exchanging data (i.e., hardware models) with other tools;

  • The simulator modules that deal with XML documents can be built upon efficient, reliable XML parsers, such as Xerces C++ Parser (see Xerces-C++ Website).

    Click To expand
    Figure 4: Example of the description of a hardware platform (including four CPUs) through an XML file, as rendered by a popular XML browser. Some of the document elements are shown in the collapsed format.

    Click To expand
    Figure 5: Example of an XML DTD for a Platform Description Document (shown in a user-friendly format by an XML browser)

A PDD may contain several sections, dedicated to cores (CPUs, microcontrollers, and DSPs as well), caches (data caches, instruction caches, or "unified" caches), memories (of assorted kinds), and buses. Figure 4 depicts the structure of a PDD, as shown by a popular XML browser; it is worth pinpointing the hierarchical organization of the document elements.

In the PDD, the section pertinent to cores is aimed to describe all the processors and all the CPU-like blocks included in the platform. In this category we can incorporate also DSPs, co-processors, any kind of accelerator, dedicated processing units, and so forth. They can be characterized mainly by their processing power. We need a parametric model for the processing power of the component blocks because we want to easily investigate the system performance in different operating conditions (e.g., at different clock rates) by just modifying the block parameters. A simple way to express it is to give the value of the CPI (Clocks Per Instruction) and the operating clock rate. The main nuisance with this choice is the typical dependence of the CPI index on the specific software application. This issue may be coped with by taking into account, whenever such information can be obtained/estimated, the specific value exhibited for the application running on the CPU block.

Besides, regardless of the individual parameters actually employed for each hardware component, it is crucial to be able to model the typical phenomena observed in the memory hierarchies, and to carefully characterize the role of the bus state in increasing the average accessing time at different memory locations. In fact, the actual bus/memory behaviors are crucial factors for the overall system performance, and they should be coped with even in models with a very high level of abstraction.

A useful feature that should be added to the description formalism is the possibility to directly import into the PDD the complete descriptions of subsystems already present in an auxiliary library. This is very practical when a commercial SoC is employed as part of a larger hardware platform (this characteristic is shown in Figure 6 by means of the XML element named LOAD_SOC).

Click To expand
Figure 6: An overall view of the functionality of a digital cartographic system, expressed by means of a use-case UML diagram

A key characteristic of a PDD is the possibility to describe the components with different levels of accuracy. Thus, in our approach, for each component in the model we can state as optional as many parameters as possible. If a parameter value is not definitely known, the designer can choose to not specify it, and a reasonable value will be assumed by the simulation environment. Hence, the accuracy and reliability of the simulation outcome is influenced also by how precisely the designer specifies the values for the system parameters.

Modeling Behavioral Aspects: the Help of UML, the Underlying XML

In the framework of the ψ-chart approach, performance of tuned architectures is characterized by a set of performance models for the corresponding selected scenarios.

Employing UML, scenarios can be described either by means of activity diagrams, or by sequence diagrams, or with statecharts (Booch et al., 1998). Unfortunately, none of such diagrams directly deals with performance issues.

A model for the correct evaluation of the execution time, as underlined, for example, by Mehra et al. (1994), may be very precise even without a faithful reproduction of the control flow; typically only the most important functions and the loops they are involved in are really significant. When we operate with components whose actual internal structure is not exactly known (because their source code is not provided by the vendor, or the component has not been entirely implemented yet), we cannot deal with all aspects related to memory and I/O accesses. Hence, there could be some loss of accuracy, basically due to lack of knowledge about the source code of the components; as a consequence, scenario models must be carefully verified.

For the performance models corresponding to the studied scenarios, the simulator HL Perses makes use of a schematic view of the system behavior. A similar approach has been adopted by Hu and Gorton (1997) and other authors in related fields. The fundamental idea is to identify basic sequential computational activities (called basic functions) within scenarios, and to estimate their execution time in terms of their input parameters. Each scenario is modeled by means of processes, communicating and synchronizing among each other. The use of processes in a software model allows also the characterization of concurrent programs running over parallel platforms. As we are possibly dealing with parallel embedded systems, which are typically tightly coupled, the interprocess communication has been based on access to shared variables, and synchronization on use of semaphores. Message passing can be used instead, giving the user an alternative technique for building up software models (message passing can be implicitly implemented using semaphores). A process body in the model has a sequential control flow, and can invoke basic functions, access shared variables, and use semaphores or messages.

A large number of embedded systems widely employ interrupts to interact with their operating environment, reacting in an asynchronous way to external events that may happen. Usually, the occurrence of a certain interrupt is handled by promptly executing a corresponding piece of code known as interrupt driver. Taking into account the importance of interrupt handling in this setting, it is convenient to include it in the modeling task as well. Thus, we can set up also a particular facility to let the user specify in a straightforward manner the interrupt drivers (modeled as processes), and the temporal distribution of the occurrences of the corresponding interrupts.

In the end, we can state that a model for a scenario is based on a number of basic functions, whose execution time is influenced by the parameters specified in the function definitions. In this particular case, the parameter inference operation corresponds to determining actual values in the basic function definitions. Parameter inference on available (already implemented) components can be proficiently carried out making experiments and measurements, using different input data. Subsequently, verification of basic function models is based on comparison of actual and predicted execution time for available components, under input data not previously used in the parameter inference operation. Whenever the presented methodology is used to build applications from scratch, some components might have not been implemented yet, hampering parameter inference. In this case, we can produce either simple prototypes or more precise descriptions with realistic execution timings. For this reason, the use of commercial tools supporting automatic early prototyping could be of valuable help.

Scenario performance models can be proposed to the simulator by means of XML documents, following the same approach used for the platform model. This formalism looks quite clumsy, and it is not very suitable to express the sequences of activities within each process. For this reason, a more workable syntax has been introduced for this purpose, and thus a software model can be expressed in a C-like language as well. A specific integrated tool automatically identifies a C-like input model for the simulator, and puts it in an XML format for the simulator parser.

Although writing behavioral models in a C-like language could be regarded as a significant step forward, a substantial improvement for the modeling task could be the adoption of UML descriptions. A convenient way to express software models is the employment of UML behavioral diagrams (Booch et al., 1998), and particularly activity diagrams. Recently, also in the field of research on performance prediction, UML-based tools have been developed to support simulation of system models (Arief & Speirs, 2000); the xUML profile is typically employed for this purpose (Mellor & Balcer, 2002; Raistrick et al., 2004). Proper tools could guide the user in enriching the UML scenario description with additional performance characterization, and then the tools themselves could accordingly produce the required performance models in the format accepted by the simulation environment. In particular, HL Perses has been equipped with a software module to make the simulator deal with software models expressed as UML activity diagrams. Such a module is in charge of transforming the representation of the UML diagram (expressed in an XML format) into the proper XML document as expected by the simulator. Anyway, even if an automatic support to model transformations is missing, UML gives us the possibility to conveniently express the system model in a clear, rigorous, and straightforward way; for this reason it is always reasonable to use UML in the behavioral modeling task.

The output data from the scenario simulator must allow the evaluation of architectural solutions under scrutiny, and must clearly detail the utilization of the hardware platform. For this reason, HL Perses has been designed to gather a number of different measures; for example, the overall scenario runtime, the runtime for each process, other details on the process execution (starting and completion point in time, number of synchronizations, processor utilization, number of calls to basic functions, etc.), the number of context switches (if any), and the overall utilization level for each processor.

Despite the coarse-grain descriptions in the models, the predicted execution times obtained with HL Perses, even on different environments, substantially correspond to the actual ones (provided that the high-level modeling work has been carried out properly, capturing the fundamental features of the system). One of the most critical aspects of the described simulation strategy is the determination of the CPI value. In cases where some application portions are available, an accurate estimation of the CPI values for them may be carried out with the help of SimpleScalar (Austin et al., 2002), a well-known toolset that directly analyzes programs compiled into a simulator-specific machine language. Once more, it is worth recalling that the simulation results must be used at a high level of abstraction, to compare different architectural solutions, and not necessarily to thoroughly predict the system performance; this task can be accomplished in a more advanced phase of the design-space exploration, with traditional cycle-accurate simulators.

[2]In this particular setting, the expressive power of DTDs (see the XML Website in the references) is usually sufficient to describe the structure of a PDD. Anyway, any actual technology for XML schemas (in the more general meaning) can be adopted for this purpose (in particular, XML Schemas by W3C as well, see the XML Schema technology Website in the references).


Case Study: A Digital Cartographic System

The case study presented in this section relates to a digital cartographic system, which is deployed on hand-held devices equipped with an LCD display. As shown in Figure 6, the cartographic application exposes the following capabilities to the end user:

  • determination of the geographical position, exploiting data provided by a GPS receiver (Elliot, 1996),

  • exploration of maps stored on a persistent storage, and

  • search for general information.

The user can visualize a map centered on the current geographical position, and can interact with the system, exploring the available digital charts, changing the central position of the map and the zooming ratio. Moreover, one can find objects on maps and access a simple database.

Such an embedded system is built upon a hardware platform based on the SPP multicore chipset (Bechini & Prete, 2001; Bechini et al., 2003). For this chipset, a simple architecture based on two ARM[3] cores has been designed, taking into account strict requirements of cost, power consumption, and computational power for graphical cartographic applications. The main characteristic of the hardware platform is its capability to support a wide variety of peripherals, and to interface a large number of memory chips currently present on the market.

In the presented case study, we first suppose to make use of the hardware platform as it is, and to investigate how to arrange the existing cartographic software (plainly sequential) over it. Later, we shall try to evaluate the benefits from some enhancements to the SPP chipset.

At first glance, we observe that the information search feature does not depend on the others, and it does not reasonably impose strict performance requirements on the system (since it is only occasionally used). On the other hand, the GPS and plotting features may be used concurrently, and this observation pushes us to further investigate them. For cost and performance reasons, a full-featured operating system cannot be adopted for supporting the cartographic application. Furthermore, we must keep in mind that the GPS algorithms are triggered in a cyclic way, and they are supported by an interrupt-driven procedure. The structure of digital maps deeply affects the architectural design of the application; in fact, the organization of the map displaying procedure is definitely shaped by such a structure. In digital cartographic systems, as well as in geographical information systems (DeMers, 1999), maps are represented through several distinct layers. We can tell apart two distinct categories: geographical layers, containing data about pictorial features (coastlines, rivers, mountains, lakes, etc.), and symbolic layers, with data about locations represented by standard symbols (hospitals, hotels, information points, lighthouses, etc.). A map is drawn following precise constraints on the ordering of elaboration and plotting of different layers. Depending on the zoom level, some features can be shown or not on the displayed map.

After these preliminary observations on the studied application, we can go on applying the ψ-chart approach. In the first place, the hardware platform has to be properly modeled, and it will not be modified any more (complying with the design constraint on keeping it untouched). The operations required for the software application are a little bit lengthier, and deserve being detailed in the following subsections.

Application Characterization

The design process for the specific case study starts up with the coarse-grain application characterization. The high-level structure of the cartographic software can be described using the UML statechart diagram in Figure 7. It presents a hierarchical view of the system, by means of states and transitions; a state may correspond to ongoing activity, and such activity is expressed as a nested state machine (Booch et al., 1998). After the initialization phase, the system concurrently executes two activities: the position calculation and the map displaying. The position calculation is a cyclic activity, made of a single computation triggered by a signal from an external GPS device; likely, this specific computation is worth being modeled, as it is continuously performed during the whole system operation, regardless of the other ongoing activities.

Click To expand
Figure 7: High-level behavioral description of the cartographic software by means of UML statechart diagrams. It is worth pointing out that the cyclic GPS activity for position calculation is always carried out, independent of the other activities.

Further investigation is required to single out additional critical activities within the map displaying. This last job, as shown in Figure 7, is made of an unpredictable interleaving of two different activities, namely GPS drawing and interactive drawing. A more detailed vision of them is presented in Figure 8. Both require a common job named map redrawing; because of its widespread use throughout the system runs, the map redrawing can be deemed a critical activity, possibly worth being modeled.

Click To expand
Figure 8: High-level behavioral description of the activities within the map-displaying task. The map redrawing is exercised repeatedly, and its most time-consuming activity is the picture composition, whose implementation affects the user-perceived performance of the whole system.

There are two distinct activities that can request the map redrawing: the GPS drawing activity and the interactive drawing activity. In the former, the central position for the map is obtained from the GPS system, in the latter directly from the user. Within the map redrawing, any further composition of the map picture is avoided (as shown in Figure 8); for this purpose, the current geographical position is checked first, and then some trick is possibly applied, for example, clipping a portion of a larger picture previously prepared. If the picture composition activity cannot be got around, it has to be carried out after picking the proper map, among those available on persistent storage. Thus, it comes out that picture composition is the most performance-critical job for the system, and we need to take particular care of it in our modeling effort. In picture composition, the geographical and the symbolic layers are treated in a slightly different manner, because several kinds of symbols maintain their size regardless of the zooming level. Moreover, the required layers are processed according to the actual setting and to the preferences expressed by the user.

The map redrawing activity definitely deserves special attention for the two following reasons: (i) it is repeatedly called in many scenarios within different use cases; (ii) the user-perceived quality of the whole system is expected to suffer from low efficiency in this activity. Following the ψ-chart approach, we chose a typical map redrawing activity (executing picture composition as well) as the use case to be employed for performance prediction. Once the refining, tuning, and parameter inference phases have taken place, this use case can be carefully described by scenarios for different solutions, possibly making use of UML sequence diagrams. Each scenario can be simulated for different input data (i.e., map portions, in this particular case); the system behavior under a typical map redrawing activity, and under the most computing-demanding workload, must be accurately delineated.

Towards Tuned Architectures

The high-level behavioral description is the direct input for the refinement process, which is in charge of finding different promising architectures with different structures, possibly parallel structures. The picture composition can employ different strategies in leveraging the layered structure of digital maps. Table 1 summarizes the refined architectures studied in this section. The first one, named SP, adopts a sequential solution for the picture composition job. It represents the actual sequential solution adopted in the commercial application that has to be retargeted to the described hardware platform. The timings of the picture composition job can be possibly improved making use of multiple processes over different map portions. To assess this task, these processes can be assigned to processors either in a static way, or dynamically; the corresponding solutions are indicated by SA and DA in Table 1. The flexibility of dynamic assignment of tasks to processors can also be exploited by treating layer elaborations as distinct tasks. Map layers can be classified in two or more categories (geographical, symbolic, etc.); thus, another kind of job partitioning is achieved by dedicating a process to each layer category, that is, each process is assigned a specific role. Of course, for the last two cases, a limitation on fully parallel executions is given by precedence constraints in drawing different layers. The architectures obtained following the two previous approaches are indicated as DL and RA in Table 1. The picture composition job can be thought of as made of three main phases: projection, clipping, and plotting. Projection takes care of transforming the coordinates in the map from polar to Cartesian. Clipping is used to cut off the shape portions out of borders. Plotting is the operation to actually draw down shapes on a discrete plane. All these operations must be done for every layer. Therefore, in the architecture named PL in Table 1 we adopted a pipelined solution based on these last considerations.

Table 1: Possible parallel solutions for behavioral models of the target cartographic system
ID | Description
SP | Chart plotting in sequential fashion
SA | Map portions assigned to CPUs according to a static schedule
DA | Dynamic assignment of map portions
DL | Dynamic assignment of map layers
RA | CPUs are assigned different roles
PL | Map layers processed through a pipeline

It is sensible to assume that, although the pool of possible architectural solutions is presented now as a definite set, in practice it is incrementally populated and polished through successive iterations of the proposed methodology. Moreover, each specific solution can be specified and described using behavioral UML diagrams.

Some details on the architecture of the hardware support (e.g., the number of processors) are useful for the following tuning phase; such details are already available in the platform description previously obtained. Within architectures SA and DA, the main parameter to decide on is the number of screen portions. Both of these two architectures require four processes: the first is the setup process, which finds out the layers to draw; the second supports the cyclic GPS activity; the last two are identical, one on each processor and each implements the map drawing on a screen portion. Architecture SA operates better with two screen portions, whereas DA gives its best results with four parts. For architecture DL, it is important to understand whether the setup and GPS processes must be either assigned to predetermined processors or scheduled onto different CPUs in a dynamic fashion; it has been found that the second solution gives better results. The same applies to architecture RA, getting its best performance with dynamic assignment of all the application processes. Finally, the pipelined handling of map layers is made of a setup process and three stage-processes. The strategy for the assignment of process priorities must be chosen in the tuning phase. Assigning an increasing priority from the first to the last stage process produced a little gain in the overall redrawing time.

Performance Estimation

The parameter inference is in charge of characterizing the execution time of the basic functions in terms of their input parameters. This operation can be considered as one of the most critical in the described methodology. In our case study, the structure of the original sequential application can give us precious hints to proficiently tackle this problematic task; we know that the most important functions in plotting geographical layers are drawings and fillings of polygons (of known complexity), and moreover we can make some measurements on the available cartographic software. By means of experiments operating on different input maps, we can go on characterizing each basic function in the selected scenarios. A scenario can be simulated with the typical and the worst-case inputs, providing the proper corresponding values to the basic functions. The input domain exploration allows us to find out both the typical and worst-case input data; we have selected a map of Elba Island (Italy) and a chart of the Southern Norway coastlines.

Using the simulator HL Perses, the execution time of the map redrawing activity has been predicted for each architectural solution reported in Table 1. We have also taken into account the ongoing GPS activity, dedicating to this job a process that is independent from the other processes that are in charge of the picture composition and displaying. The first diagram of Figure 9 presents the redrawing time for the map of Elba Island. We notice that at least three parallel software architectures, SA, RA, and PL, are not suitable to exploit the platform parallelism. Among the other two, DL seems the better one.

Click To expand
Figure 9: Simulated redraw time for different software architectures. The diagram on the left shows the timings relative to a map of average complexity. The diagram on the right reports the predicted speedups for architecture DL, with an increasing number of CPUs.

The modeling and the parameter inference activity can introduce a number of inaccuracies, and for this reason it is not possible to definitely assert that one solution is better than another only if, according to the simulation results, the former performs slightly better than the latter. It is clear that, whenever the values of performance indexes for different solutions are very similar, the choice among the architectures should depends on other factors. In the presented case study, it appears likely that the most appropriate architecture for the cartographic application is DL; this choice may be sustained by the simplicity of the architecture, not only by the significant performance gain in comparison with the basic sequential software. Anyway, the final actual architecture (among the viable ones just selected) can be chosen on the basis of other factors such as the corresponding cost, power consumption, and safety guarantees; information on these issues can be obtained by more traditional system-level tools that operate with more detailed models of the overall system.

Keep the Software, Let the Platform Change

In case we were required to put on the market a new version of the cartographic appliance, exhibiting faster plotting time even for the most complex maps (or hosted on a helicopter or airplane, with higher velocity and thus with a higher refresh rate for the map plotting), we could take into consideration the possibility of changing the underlying hardware platform. A viable solution is the adoption of a more powerful chipset, including additional CPU cores. Albeit the software application must likely undergo very minor modifications, the reengineering process of the whole appliance is required anyway. Some fundamental questions have to be answered: What will be the application behavior in the new operating conditions? How many cores is it reasonable or convenient to add? Will the new platform be able to host either more computing-intensive versions of the application, or much more complex or detailed maps?

The reengineering process can take advantage of the flexibility and reusability of the XML/UML models previously employed. Thus, the behavior of the system making use of a different number of CPU cores can be easily investigated. The performance improvement due to the adoption of a platform with multiple CPUs can be roughly measured by a speedup index (Sahni & Thanvantri, 1996), which quantifies how much quicker a solution is, compared with the original one (in our case, with a single CPU core). For our purposes, we can use the index P_Speedup (M, P), which depends on the particular map M, and on the number of processors P in the parallel platform. The second diagram of Figure 9 presents the predicted values of P_Speedup for the architecture DL running on SPP platforms with different numbers of CPUs and redrawing a map of average complexity; it shows that DL yields a significant speedup only with up to three or four CPUs, that is, the typical number of CPUs for SoCs in embedded systems.

Some additional remarks are due. As we adopt a high-level architectural modeling, we deal with a coarse-grain description of applications, employing a limited number of processes[4]. This fact determines a low upper bound for possible speedups; anyway, this drawback becomes essential only with a number of CPUs usually not supported by SoC multiprocessors. Finally, it is worth pinpointing that in our approach we do not explicitly take into account benefits coming from better utilization of cache memories due to partitioning of data in the parallel application; this factor in actual computations usually determines a further speedup increase.

[3]ARM, designed by Advanced RISC Machines, Cambridge, UK, is a 32-bit microprocessor that uses RISC technology and fully static design approach to obtain both high performance and very low power consumption. These features, together with low cost and compact design, make ARM suitable for the embedded-products market.

[4]This fact is also often determined in actual applications by the need to use/reuse monolithic off-the-shelf components. Thus, such a modeling approach reproduces what happens in many real-world situations.


Conclusion

Most of the applications in computing-intensive software are turning to the field of embedded systems, and particularly to hand-held devices; hence, more powerful and complex hosting platforms have been introduced in the market. The employment of multiple CPU cores on the same chipset allows a good trade-off between the processing power required by the application, and cost and power consumption. The system design, including software as well, becomes the first crucial task and the selection of the architecture the first critical activity.

In this chapter, we have described the Ψ-chart approach, which addresses the architectural design of modern embedded systems. The proposed methodology is appropriate to assist the design-space exploration in its initial phases, through the adoption of high-level simulation. Moreover, it is suitable also for applications relying on multicore chipsets with a low degree of parallelism. Such a kind of simulation requires a preliminary modeling phase that, in our case, is carried out by characterising the architecture both in its hardware platform and in its behavioural description. A high-level simulator, able to deal with heterogeneous parallel platforms hosting concurrent applications made of several interacting processes, has been described in its fundamental components.

One of the most significant innovations in this kind of tool is the introduction of UML and XML in the architectural design. Starting up with a software description (possibly using UML diagrams), candidate software architectures (with different parallel solutions) are first defined and then evaluated, to end with the selection of the one yielding the highest performance gain. The flexibility and reusability of models expressed by UML and XML makes the high-level simulators really worth being adopted on the industrial scene.

The proposed methodology and tool can both be employed in the following conceivable settings:

  • Nothing is given and everything must be developed from scratch.

  • The hardware platform is given, and a software application must be arranged upon it. We can distinguish a couple of subcases, corresponding to different degrees of freedom for the designer:

    • The software application must be written from scratch;

    • An existing software application must be retargeted to the new platform. In this case, it may be convenient to alter the software architecture and/or rewrite selected application portions.

  • The application is given, and the hardware platform must be chosen. A number of different existing platforms must be evaluated, taking into account the effort and the result of the porting process for the software application.

We have shown the application of the proposed methodology to an embedded digital cartographic system, based on a simple SoC (System-on-Chip) multiprocessor. The results from the performance prediction process have lead to the selection of a software architecture that exploits parallel processing of map layers. This architecture has been chosen for the delivered speedup, for its simplicity, and for its flexibility in exploiting data parallelism. The effort spent in the modeling phase making use of both UML and XML allows us to promptly tackle any forthcoming redesigning task due to the need of releasing a new upgraded version of the product. In particular, both changes in the supporting hardware platform and in the software application structure can be easily and rapidly handled.


References

Arief, L.B., & Speirs, N. A. (2000). A UML Tool for an Automatic Generation of Simulations Programs. Proceedings of 2nd ACM Workshop on Software Performance, 71–76. ACM Press.

Austin, T.M., Larson, E., & Ernst, D. (2002, February) SimpleScalar: An infrastructure for computer system modeling. IEEE Computer 35(2), 59–67. IEEE CS Press.

Barr, M. (1999). Programming embedded systems in C and C++. O'Reilly.

Bechini, A., & Prete, C. A. (2001). Evaluation of on-chip multiprocessor architectures for an embedded cartographic system. Proceedings oflASTED Conference on Applied Informatics 2001. Innsbruck, Austria.

Bechini, A., & Prete, C. A. (2002). Performance-steered design of software architectures for embedded multicore systems. Software: Practice and Experience, 32(12), 1155–1173. John Wiley & Sons.

Bechini, A., Foglia, P., & Prete, C.A. (2003). Fine-grain design space exploration for a cartographic embedded soc multiprocessor. ACMSigArch Computer Architecture News, 31(1), 85–92. ACM Press.

Berger, A.S. (2001). Embedded systems design: An introduction to processes, tools, & techniques. CMP Books.

Bernardo, M. (1999, September). Let's evaluate performance, algebraically. ACM Computing Surveys, 31(3es), article no. 7. ACM Press.

Booch, G., Jacobson, I., & Rumbaugh, J. (1998). The Unified Modeling Language Users Guide. Boston: Addison-Wesley.

Coffland, J.E., & Pimentel, A.D. (2003). A software framework for efficient system-level performance evaluation of embedded systems, In Proceedings of 2003 ACM SAC (Track on Embedded Systems), 666–671. ACM Press.

Conallen, J. (1999). Modeling Web application architectures with UML. Communications ACM, 42(10), 63–70. ACM Press.

Culler, D.E., et al. (1993). LogP: Towards a realistic model of parallel computation. In Proceedings of ACM SIGPLAN Symposium on Principles & Practice of Parallel Programming (PPOPP) 1993, 1–12. ACM Press.

Culler, D.E., Singh, J.P., & Gupta, A. (1999). Parallel computer architecture: A hardware/software approach. Morgan Kaufmann.

DeMers, M.N. (1999). Fundamentals of geographic information systems. New York: John Wiley & Sons.

Elliot, D. (1996). Understanding GPS: Principles and applications. Kaplan.

Gomaa, H. (2000). Designing concurrent, distributed, and real-time applications with UML. Boston: Addison-Wesley.

Groetker, T., Liao, S., Martin, G., & Swan, S. (2002). System design withsystemC. Kluwer.

Hu, L., & Gorton, I. (1997). A performance prototyping approach to designing concurrent software architectures. Proceedings of 2nd International Workshop on Software Engineering for Parallel and Distributed Systems, 270–276. Boston: IEEE CS Press.

Jain, R. (1991). The art of computer systems performance analysis: Techniques for experimental design, measurement, simulation, and modeling. New York: John Wiley & Sons.

Kazman, R., Abowd, G., Bass, L., & Clements, P. (1996). Scenario-based analysis of software architecture. IEEE Software, Nov. 1996, 47–55. IEEE CS Press.

Kazman, R., Barbacci, M., Klein, M., & Carriere, S. J. (1999). Experience with performing architecture tradeoff analysis. In Proceedings of 21st International Conference on Software Engineering, pp. 54–63. Los Angeles: IEEE CS Press.

Kienhuis, B., Depettere, E.F., van der Wolf, P., & Vissers, K. (2001, November). A methodology to design programmable embedded systems, pp. 18–37. In LNCS Vol. 2268. Springer.

Kumar, S., Aylor, J.H., Johnson, B.W., & Wulf, W. A. (1995). The codesign of embedded systems: A unified hardware software representation. Kluwer.

Laine, P.K. (2001). The role of sw architectures in solving fundamental problems in object-oriented development of large embedded sw systems. In Proceedings of Working IEEE/IFIP Conference on Software Architecture, pp. 14–23. IEEE CS Press.

Lee, E.A. (2000, September). What's ahead for embedded software? IEEE Computer, pp. 18–26. IEEE CS Press.

Lewis, B., & McConnell, D.J. (1996, November). Reengineering real-time embedded software onto a parallel processing platform. Proceedings of 3rd Working Conference on Reverse Engineering, 11–19. Monterey, CA: IEEE CS Press.

Li, J. J., & Horgan, J.R. (2000, April). Simulation-trace-based component performance prediction. In Proceedings of3 3rd IEEE Annual Simulation Symposium. Washington, DC,: IEEE CS Press.

Medvidovic, N., & Taylor, R. N. (2000). A classification and comparison framework for software architecture description languages. IEEE Transactions on Software Engineering, 26(1), 70–94. IEEE CS Press.

Mehra, P., Scholbach, C.H., & Yan, J. C. (1994, May). A comparison of two model-based performance-prediction techniques for message-passing parallel programs. In Proceedings of ACM SIGMETRICS 94 Conference, pp. 181–190. Nashville, TN: ACM Press.

Mellor, S.J., & Balcer, M. J. (2002). Executable UML. Boston: Addison-Wesley.

Mellor, S.J., Scott, K., Uhl, A., & Weise, D. (2002). Model-driven architecture. In Proceedings ofOOIS Workshops 2002, LNCS 2426, 290–297. Springer.

Musser, D.R., Derge, G.J., & Saini, A. (2001). STL tutorial and reference guide: C++ programming with the standard template library (2nd ed.). Boston: Addison-Wesley.

Nayfeh, A., Hammond, L., & Olukotun, K. (1996). Evaluation of design alternatives for a multiprocessor microprocessor. In Proceedings of ISCA 1996, pp. 67–77. ACM Press.

Panda, P.R. (2001, October). SystemC -A modeling platform supporting multiple design abstractions. In Proceedings of 14th International Symposium on Systems Synthesis, pp. 75–80. IEEE CS Press.

Pimentel, A.D., Hertzberger, L.O., Lieverse, P., van der Wolf, P., & Deprettere, E. F. (2001). Exploring embedded-systems architectures with artemis. IEEE Computer 34(11), 57–63. IEEE CS Press.

Prete, A., Graziano, M., & Lazzarini, F. (1997). The ChARM tool fortuning embedded systems. IEEE Micro, 17(4), 67–76. IEEE CS Press.

Raistrick, C., Francis, P., & Wright, J. (2004). Model driven architecture with executable UML™. Cambridge, UK,: Cambridge University Press.

Sahni, S., & Thanvantri, V. (1996). Performance metrics: Keeping the focus on runtime. IEEE Parallel and Distributed Technology, 4 (1), 43–56. IEEE CS Press.

Sangiovanni-Vincentelli, A.L., & Martin, G. (2001). A vision for embedded software. In Proceedings of CASES 2001, pp. 1–7. ACM Press.

Schlett, M. (1998). Trends in embedded-microprocessor design. IEEE Computer 31(8), 44–49. IEEE CS Press.

Shaw, M., & Garlan, D. (1996). Software architecture: Perspectives on an emerging discipline. New York: Prentice Hall.

SystemC Website: http://www.systemc.org/

Williams, L. G., & Smith, C. U. (1998). Performance evaluation of software architectures. In Proceedings of 1st ACM Workshop on Software Performance, 164–177. Santa Fe, NM,: ACM Press.

Wolf, W. (2000). Computers as components: Principles of embedded system design. Morgan Kaufman.

Wolf, W. (2003). A decade of hardware/software codesign. IEEE Computer 36(4), 38–43. IEEE CS Press.

Xerces-C++ Parser (n.d.). Documentation at http://xml.apache.org/xerces-c/

XML Schema technology Website (introductory document): http://www.w3.org./TR/xmlschema-0/

XML Website: http://www.w3.org/XML/


Endnotes

  1. Other suitable description formalisms can be found among formal methods (e.g., Petri nets, extended FSMs (Lewis & McConnell, 1996), process algebras (Bernardo, M., 1999), etc.), or ADLs (Medvidovic & Taylor, 2000).

  2. In this particular setting, the expressive power of DTDs (see the XML Website in the references) is usually sufficient to describe the structure of a PDD. Anyway, any actual technology for XML schemas (in the more general meaning) can be adopted for this purpose (in particular, XML Schemas by W3C as well, see the XML Schema technology Website in the references).

  3. ARM, designed by Advanced RISC Machines, Cambridge, UK, is a 32-bit microprocessor that uses RISC technology and fully static design approach to obtain both high performance and very low power consumption. These features, together with low cost and compact design, make ARM suitable for the embedded-products market.

  4. This fact is also often determined in actual applications by the need to use/reuse monolithic off-the-shelf components. Thus, such a modeling approach reproduces what happens in many real-world situations.


Chapter XII: Describing and Extending Classes with XMI--An Industrial Experience

Team LiB

Chapter XII: Describing and Extending Classes with XMI—An Industrial Experience

Giacomo Cabri,,
Universita di Modena e Reggio Emilia,
Italy
Marco lori,,
OTConsulting, Italy Andrea Salvarani, OTConsulting,
Italy

This chapter reports on an industrial experience about the management and the evolution of classes in an automated way. Today's software industries rely on software components that can be reused in different situations,in order to save time and reuse verified software. The object-oriented programming paradigm significantly supports component-oriented programming, by providing the class construct. Nevertheless, already-implemented components are often required to evolve toward new architectural paradigms. Our approach enables the description of classes via XML (eXtensible Markup Language) documents, and allows the evolution of such classes via automated tools, which manipulate the XML documents in an appropriate way. To grant standard descriptions compliant with the UML (Unified Modeling Language) model, we exploit the XMI (XML Metadata Interchange) interchange format, which is a standard, defined by OMG (Object Management Group), that puts together XML, UML and MOF (Meta Object Facility).

Introduction

Today's information systems are quite complex, and software developers are eager for appropriate methodologies and tools to support their work. Object-oriented technology has been a milestone in programming, but we are still far from an effective and complete adoption of it. With no doubt the UML language has proposed a valid help for developers, but they still have to face different issues.

One of the scarcest resources in today's software development is, without a doubt, time. Customers want to have their products in a more and more short time, because they must accomplish the rhythms of today's life, which are very quick and do not allow any delay. In addition, sometimes developers have to reinvent the wheel, because they cannot reuse existing solutions; this may happen for different reasons, from the inexperience of the developers to the inadequacy of the supporting languages and tools, from the chance of a wrong analysis to the incompatibility of previous solutions. This means a waste of time. So, software developers must face this situation, and find an appropriate help.

A methodology that is helpful is the one based on components. A component is a software entity that provides services via well-defined interfaces (Szyperski, 1998). The analogy with electronic components is clear. The aim of this methodology is to provide developers with reusable and tested building blocks that can be assembled to construct applications. Even if the idea is quite clear, the practical exploitation of components is not always easy. The two challenges we are going to face in this chapter are software storage(Mili et al., 1998) and software evolution (Casais, 1995; Yang & Ward, 2003).

The former concerns the storing of classes in a repository, to keep track of the completed work and, of course, to reuse developed solutions. Even if this is not a new problem, and solutions do exist (Vitharana, 2003; Arnold & Stepoway, 1987; Devanbu et al., 1991; Lillie, 1991; Meling, 2000), our aim is to propose a solution that takes into account also the evolution of the software in an integrated and interoperable way. Interoperability can be useful because it allows us to manage classes in an independent format and even to translate them into different programming languages.

The latter challenge relates to the evolution of existing classes in terms of their extension. For instance, let us consider a component that provides a given service, say S. If such a component is bound to a given architecture, it becomes very hard to reuse it. Instead, it would be better to develop a "generic" component that provides the service S, and that can be adapted to different architectures, for instance Enterprise Java Beans (EJB Specifications) and Remote Method Invocation (RMI Specifications). Therefore, our aim is to define an appropriate model of component that enables an automatic evolution of the components in terms of extensions to fit specific architectures. At the logical level, we would like to obtain the situation depicted in Figure 1: the same service can be exploited in different architectures without the need of recoding the component.

Click To expand
Figure 1: The same service can be exploited (a) as an EJB or(b) as an RMI service

Of course this can be made by hand, but it becomes infeasible when a lot of classes are involved. Moreover, generally the extension does not require particular competencies, and can be fruitfully delegate to automatic tools.

OTConsulting (http://www.otconsulting.com) is a software industry that has been developing large-scale distributed object-oriented applications for several years. As a result, we have developed a lot of classes, and today we face the two main challenges described above. This chapter reports on our experience starting from the main motivations and explaining some details of the chosen approach.

Our main aim is to describe classes in an XML format using the most standard and abstract syntax as possible. Moreover, we need a general approach that also allows the evolution of classes in term of extensions. For our approach we have chosen XMI (XML Metadata Interchange) because it is standard and related to UML, which is able to represent an object-oriented programming language in an abstract way. In addition, our approach enables class evolution by extending class information on the basis of given patterns based on the MOF (Meta Object Facility) metamodel, which specifies future use of these classes; for instance, if they should be implemented as an EJB or an RMI. From an abstract point of view, we introduce the concept of Remote Proxy, which is an entity that enables the extension of existing classes to adapt them to different distributed architectures. From a concrete point of view, we exploit the extension's mechanisms of XMI along with appropriate DTDs that describe the chosen architecture patterns. Last but not least, we must take into account industrial requirements, such as production of code, feasibility, and usability of the approach.

The rest of the chapter is organized as follows. The second section introduces our work by presenting the literature about the problem and the motivations that have driven our choices. The third section briefly presents the XMI technology used to describe and to extend classes. The fourth section explains how classes are represented by XML documents. The fifth section proposes the Remote Proxy concept, and shows how it is exploited to extend classes. The last two sections report future trends and conclusions.


Background and Motivations

The first problem OTConsulting has faced is how to define our classes in a standard and interoperable way. This is needed both to store the developed classes in a repository and to manipulate them in order to extend them.

Literature Review

In the literature we can find some approaches to this problem.

Bryant (2000) exploits the theories of Two-Level Grammar (TLG) to support the development of software systems from a user's requirement specification in natural language to a complete OO implementation. His aim is to propose a methodology for requirement specification, which integrates the natural language requirement specification with the rest of the software, provides technology to automate the process of moving from requirements to design and implementation, and establishes the requirement specification as a formal yet understandable document. TLG seems to be a good choice because it is similar to the natural language and enables a formalism sufficient for the class definition. However, this approach mainly focuses on the requirement specification, while our need is in terms of designed and implemented classes.

Banerjee and Naumann (2002) propose an independent representation for classes of OO languages. To this end, they exploit a language with a syntax derived from Java, modified to use a more conventional notation for simple imperative constructs. The increasing of formalism can give more solid base to the specification, but from our point of view it makes the specification less feasible for our purposes; for instance, the proposed representation is hardly manageable by automatic tools.

In the literature we were able to find different projects, some good and interesting, such as JavaML from G.J. Badros (2000), to translate Java classes into XML, but all with a common lack: they are not standard and so are in contrast with one of the main purposes of XML, which is interoperability. Deveaux and Le Traon (2001) recognize the importance of having an interoperable language to support different phases of the software development. They propose a document type that captures all relevant information for classes, such as documentation, contracts, tests, and so on. This document is defined by an XML DTD and they call the resulting markup language OOPML: Object-Oriented Programming Markup Language. The proposal is very useful to support developers during the different phases of the development in an interoperable way.

Besides the specific drawbacks, all the previous approaches do not take into consideration the evolution of the software, and do not provide for appropriate constructs to manage class extensions. Only the OOPML consider "mutations" (i.e., changes of variables and methods) of the source code, which do not suit our idea of evolution in terms of extension.

Other approaches address the evolution of software in a specific way.

Jarzabek et al. (2001) exploit XML documents to represent domain models and their variant requirements. The isolation of common requirements of a domain from the variant requirements allows developers to reuse solutions (or, better, the common part of solutions) and to focus only on the variants of the specific problem inside the domain. The use of XML associated with the XMI technology grants interoperability in this process and compliance with UML.

Also, Keienburg and Rausch (2001) recognize the importance of exploiting XML and XMI for the definition of XML documents that describe UML models and their changes. In particular, they focus on the interfaces of components, and their aim is to describe the changes of such interfaces. They propose a UML metamodel of the possible changes, and appropriate XMI tags are defined to operatively describe the changes.

The XDoclet project addresses the management of the software and aims at helping developers in generating source code. The XDoclet engine processes the original Java files and produces XML descriptors and source files. XDoclet manages the evolution of software in the sense that developers can focus on the business logic (both creation and modification) and the engine produces updated source code, but it is hard to manipulate in an automatic way the metainformation about classes. Moreover, it does not follow the UML standard.

Finally, we can mention the Model Driven Architecture (MDA) effort at OMG, which relies on some existing standards (UML, MOF, XMI, and CWM) to enable developers to focus on application logic disregarding the platform-dependent issues.

Our Approach

Starting from the above-mentioned proposals, we have tried to extract from them the ideas of generality, standardization, and interoperability, and we propose a more general and standard approach.

Our approach works as depicted in Figure 2. Applying the XMI technology, a class (called the original class in the figure) is represented by an XML document, which describes the structure of the class, including attributes, methods, superclasses, and so on. The translation is performed by a tool that was developed at OTConsulting taking into account the metamodel, the project requirements, and how other tools – such as Rational Rose or Together – work. Via the XMI extension mechanism, the XML document can be manipulated, and a new XML document is created, which represents the evolved class on the basis of a given pattern derived from a specific MOF metamodel; this representation contains pieces of information about the given pattern. From this document, we can derive the code of the evolved class(es). This process is quite general and can be applied to different OO languages and patterns.

Click To expand
Figure 2: The evolution of classes via XML, XMI, and MOF

This approach has some advantages:

  • The XML document is compliant with the UML DTD, granting a standard and independent representation.

  • The manipulation of the XML documents is done following the XMI extension rules and in compliance with a metamodel defined inside the MOF framework, also in this case granting a standard and independent extension mechanism.

  • All the translations can be reversed because they follow well-defined rules. Actually, it is not exactly a "reverse process"; for instance, from the XML representation we can obtain the original class by an XML-code translation tool, not by the "reverse" XMI and the UML DTD.

Figure 3 shows two concrete examples of the above-mentioned process, which will be used later in the chapter. In this case, a Java class is represented by an XML document, which is manipulated to add EJB or RMI information. The concrete Java classes can be automatically derived from the extended XML documents. In the rest of the chapter we describe our approach in more details.

Click To expand
Figure 3: The process applied to Java classes and EJB/RMI architecture


Describing and Extending Classes

The specific problem we came to face was describing Java classes in an XML format by the most standard and abstract syntax (not bound to Java) as possible. To this purpose, we decided to study a more general approach, which not only can be adapted to object-oriented programming languages different from Java, but also allows the evolution of the classes in term of extensions.

For our approach we have chosen XMI because it is standard and related to UML, which is able to represent an object-oriented programming language like Java in an abstract way. Actually, we have faced the problem derived from the few Java features that UML does not represent (for example, the attributes native, strictfp, volatile, etc.); to this end we have exploited the extension's mechanism of UML (constraint and stereotype).

Another purpose of our approach is to enable the class evolution by extending class information on the base of given patterns based on MOF metamodel, which specify future use of these classes; for instance, they could be implemented as an EJB or an RMI. In this case we exploit the extension mechanisms of XMI (the tag XMI.extension) along with appropriate DTDs that describe the grammar of chosen patterns.

In the following, for the sake of being concrete, we consider Java classes and the Remote Proxy concept related to the distributed applications. Nevertheless, we remark that our approach is more general and can be applied to different languages and to different concepts that can be described by an appropriate MOF metamodel.

XMI Overview

In this subsection we briefly introduce XMI. Our aim is not to provide an XMI guideline, but only to give the flavour of this technology. Expert readers can skip this section, while interested readers can find more details in the official specifications and in the OMG Web site.

Today XMI is the main technology to integrate UML and XML. The main purpose of XMI is to enable an easy interchange of metadata between modeling tools (based on UML) and metadata repositories (based on MOF) in distributed and heterogeneous environments. Therefore, XMI integrates three standards:

  • XML, eXtensible Markup Language, a W3C standard;

  • UML, Unified Modeling Language, an OMG modeling standard; and

  • MOF, Meta Object Facility, an OMG metamodeling and metadata repository standard.

The MOF standard defines an extensible framework for describing metadata – which generally describe some information – and models – which are a collection of metadata, related to each other through rules that define their structure and consistency, using a common abstract syntax. The MOF is based on a four-layer metadata architecture, from the most concrete layer (MO-level) that represents objects of the real world, to the most abstract one (M3-level) that is constituted by the core of MOF, called the MOF Model. It is a meta-metamodel, a model that describes a common abstract syntax to define one or more metamodels, and it is the infrastructure for modeling architectures. This meta-metamodel defines the M2-level metamodel structure and has the capability of describing itself. One of the metamodels described by the M2-level is the UML metamodel; for example, at this level the concept of metaclass is present, that is, a class that describes a class, along with metaattribute, metaoperation, and so on. The M2-level defines an abstract language to define MI-level UML models (here there are user models, for instance the classes "Student", "Course", and so on). So, every level, except the M3-level that describes itself, is constituted by instances of data defined in the level immediately above.

There is a close relationship between the metamodeling concepts of MOF and the modeling concepts of UML: UML is in fact a rich, object-oriented modeling language, and the MOF model, even if with a different purpose (to describe metadata), is object-oriented, with metamodeling constructs that are aligned with UML's object modeling constructs, defined in the core of the UML metamodel.

XML is a markup language that enables us to represent structured information to support interchange of electronic data. XML has two important features:

  • It represents structured information by means of documents.

  • It enables us to express rules for the structure of the represented information by using a well-defined grammar (there are two kinds of documents used for this purpose: DTD, Document Type Definition, and XML Schema).

These two features allow an automatic separation between data and metadata, which enables us to validate XML documents on the basis of the adopted syntax. Other XML advantages are that it is platform independent, metamodel neutral, programming-lan-guage neutral, and API neutral.

XMI allows metadata to be interchanged as streams or files with a standard format based on XML and independent of middleware technology; this action can be done by any system capable of transferring ASCII text. Since MOF is a technology adopted by OMG to define metadata, it is natural that XMI enables us to interchange metadata conforming to MOF metamodels. To achieve its purpose, XMI uses two components (see Figure 4):

  • XML DTD Production Rules: defines a unidirectional mapping from an MOF metamodel to an XML DTD for metadata interchange documents.

  • XML Document Production Rules: defines a bidirectional mapping between an XML document (structured according to the above DTD) and an MOF-based metadata.

Click To expand
Figure 4: Parallel mapping which defines XMI

With regard to the first component, there is a significant analogy between the concept of MOF metamodel and XML DTD; both of them represent a structure and a syntax, respectively, of a metamodel and an XML document. Therefore XMI allows us to represent the grammar of an MOF metamodel in XML DTD so as to create a correct match between the MI-level model, which is an MOF-compliant metamodel, and the XML document conforms to XML DTD (each one representing metadata).

Moreover, XMI defines the XML Document Production Rules to realize a correct XML document. These rules could be applied to decode in a reverse way the XML document and to rebuild the related metadata.

Via XMI it is possible to interchange metadata that represent UML models defined by users, because UML metamodel is an MOF metamodel. This means that the XMI specification leads directly to a model interchange format for UML. To avoid confusion and incompatibility, OMG has published a standard XML DTD, which represents UML metamodel, so everyone can produce and validate XML documents with the correct syntax. There are several official versions of UML DTD as well as a working draft UML DTD released by OMG, either used by important software modeling tools. In our approach we chose to consider the DTD related to UML version 1.4 because it is the latest UML DTD produced so far. Being a working draft, it contains some faults about a few constructs (not illustrated here), but they are not relevant.


From Classes to XML Documents

After a brief XMI introduction, we define some fundamental rules to generate a DTD for any valid, XMI-transmissible and MOF-based metamodel. To better understand, readers can refer to XMI 1.2 specification (XMI Specifications). Moreover, we suggest to consider the Figure 8 (inserted afterwards), which shows the core of UML metamodel, in order to better understand the next examples representing some parts of UML 1.4 DTD.

First of all we need to explain the basic rules of XMI to understand the UML 1.4 DTD and how we realize the DTD of the metamodel about extensions illustrated later.

Each XML document containing metamodel data (metadata) conforming to XMI specification is composed of

  • XML elements required by the XMI specification.

  • XML elements containing metamodel data.

  • Not mandatory, XML elements containing metadata that represent metamodel extensions.

A full verification cannot be done through XML validation because currently it is not possible to specify all semantic and syntactical constraints of a metamodel in a DTD.

Each DTD used by XMI must satisfy the following requirements:

  • All XML elements defined by the XMI specification must be declared in the DTD.

  • Each metamodel construct (class, attribute, and association) must have a corresponding element declaration, which may be defined in terms of XML entity (the use of entity prevents errors in declarations of DTDs).

  • Any XML element that represents extensions to the metamodel must be declared in a DTD.

Now we are going to describe some of the XML elements included in the XMI DTD, which validates metadata conforming to the XMI specification. The XMI DTD is usually inserted in the metamodel DTD because currently there is not a way in XML to validate a document through more than one external DTD (its insertion inside an XML document as internal DTD has no benefit). All XML elements defined by the XMI specification have the "XMI." prefix to avoid name conflicts of XML elements that could be part of a metamodel.

The XMI specification defines three XML attributes to identify XML elements so that XML elements can be associated with each other. The aim of these attributes is to allow XML elements to refer other XML elements using XML IDREFs, XLinks, and XPointers. These attributes are declared in an XML entity called XMI.element.att. The declaration is the following:

<!ENTITY%XMI.element.att
    'xmi.id ID#IMPLIED
     xmi.label CDATA #IMPLIED
     xmi.uuid CDATA #IMPLIED'>

The value of the xmi.id attribute has to be unique within the XML document; however, the value is not required to be globally unique. This attribute may be used as the value of the xmi.idref attribute and it may also be included as part of the value of the href attribute in XLinks.

The attribute xmi.label identifies a string label related to an XML element, whereas xmi.uuid is a globally unique identifier not used in our approach.

The main purpose of linking attributes is to allow XML elements to act as simple XLinks (href attributes) or to hold a reference to an XML element placed in the same document using the XML IDREF mechanism. Even these attributes have to be included in the XMI DTD as XML entities, declared as follows:

<!ENTITY%XMI.Iink.att
    'href CDATA #IMPLIED
     xmi.idref IDREF #IMPLIED'>

The xmi.idref attribute can be used to specify a reference to an XML element within the current XML document; its value is the same value of ID defined in the xmi.id attribute of the pointed element.

We have not closely examined XLinks and XPointers because they are technologies not used in this approach for two main reasons: they are not official and there are no validation systems of XML documents that support them.

Once defined, the XMI elements needed to identify an XML element, we describe other XML elements that have to be declared within an XMI DTD. We mention only those used for this approach highlighting their function:

  • XMI is the root element for each XMI document;

  • XMI.header contains XML elements that identify the used model, metamodel, and meta-metamodel;

  • XMI.documentation contains information about the transmitted metadata, for instance, the owner and a description of the metadata, a contact person for the metadata, the exporter tool (with its version) that created metadata, legal notices, and copyright;

  • XMI.metamodel identifies the metamodel to which the transmitted metadata conform. There may be multiple metamodels if the metadata that are transferred conform to more than one metamodel. Including this XML element, it enables tools to perform more verification (in a similar way XMI specification defines XMI.metametamodel and XMI.model): and

  • XMI.content: it contains the metadata that are transferred and it may represent model or metamodel information.

Finally, we describe an important XML element for the extension mechanism called XMI.extension. It contains XML elements that represent metadata, which are an extension of the metamodel. This element can be directly included in XML elements in the content section of an XMI document to associate the extension metadata with a particular XML element.

For instance, this is the choice made for every element within the UML DTD, so that each XML element describing UML metamodel can be extended through XMI.extension.

Its declaration is:

<!ELEMENTXMI.extension ANY>
<!ATTLISTXMI.extension
%XMI.element.att;
%XMI.link att;
xmi.extender CDATA #REQUIRED
xmi.extender ID CDATA #IMPLIED>

As we can see from the element content, that is ANY, the XMI mechanism extension leaves a free choice with regard to the metamodel expansion and the elements that a modeler can include.

The xmi.extender attribute indicates which tool made the extension; it is useful when an application has to understand whether to process or not the specific extension. The xmi.extenderID is an optional internal identifier from the extending tool. Moreover, we highlight that XML elements inserted in XMI.extension must be declared in an internal or extenal DTD. In our approach XMI.extension contains metadata compliant to our metamodel that extends UML metamodel. Herewith we describe how to represent the information related to metamodel classes in a DTD conforming to XMI; this description is based upon precise rules for XML DTD production. For XMI specification they are also stated in EBNF notation, not mentioned in this chapter. As a matter of fact, either the description or the rules in EBNF notation indicate a way to represent classes, attributes, association, containment relationship, and inheritance of MOF metamodel in an XML DTD.

With regard to the use of multiplicity, in XMI 1.0 it was defined in a precise way for each element within the DTD (for example through ‘?,’+', etc.), but to enforce the multiplicity it was necessary to define an order to the XML elements corresponding to attributes and association ends in a metamodel. For exchanging data it is not necessary to specify an order, so that the OMG Revision Task Force, starting from XMI 1.1, decided to make it more flexible, ignoring the multiplicities from the metamodel when generating a DTD.

Class Specification

The representation of a metamodel class named C is shown right below for the simplest case where it does not have any attributes, association, or containment relationship:

<!ELEMENT C (XMI.extension)*>
<!ATTLISTC
    %XMI.element.att;
    %XMI.link.att; >

For instance, in the UML metamodel the Element class represents the most abstract class of the metamodel; it has no attribute (except for the ones mandatory in the XMI specification), nor association, and all the other classes of the metamodel are its descendants. It is declared in the UML DTD as follows:

<!ELEMENT UML:Element (%UML:ElementFeatures;)*>
<!ATTLIST UML:Element
          %UML:ElementAtts;>

where the entities are

<!ENTITY % UML:ElementFeatures 'XMI.extension'>
<!ENTITY % UML:ElementAtts '%XMI.element.att; %XMI.link.att;'>

As can be seen, in UML 1.4 DTD a metamodel class is not directly represented as the above class C, but it is represented through the use of XML entities with the following generic notation (considering xxx the name of the class):

<!ELEMENTxxx (%xxxFeatures;)*>
<!ATTLISTxxx
    %xxxAtts;>

We point out that, once processed the XML entities, the representation of the UML:Element class is equal to the representation of the metamodel class named C shown above.

The XML entity with the Feature subfix lists the content elements that describe a generic metamodel class, with the possible presence of another entity related to other XML elements of the immediate superclass. The XML entity with the Atts subfix lists the attributes which refer to the described class, with the possible presence of another entity related to other attributes of the immediate superclass.

Inheritance Specification

XML does not have a built-in mechanism to represent inheritance: for this reason, XMI manages it by copying every attribute, association, and containment relationship from the superclass to all the respective subclasses. The content model of the XML element declaration for a class contains XML elements representing the local and inherited attributes, references, and composition.

For example, consider a C1 class with attribute a1, reference r1, and composition comp1, that has a superclass named C0, with attribute a0, reference r0, and composition comp0.

The XML element declaration of C1 class includes both local and inherited features:

<!ELEMENT C1 (C0.a0 | C1 .a1 | XMI.extension | C0.r0 | C1 .r1 | C0.comp0 | C1 .comp1)*
>
<!ATTLIST C1
a0 CDATA #IMPLIED
a1 CDATA #IMPLIED
r0 CDATA #IMPLIED
r1 CDATA #IMPLIED
%XMI.element.att;
%XMI.link.att;>

When we have multiple inheritance, the inherited attributes, references, and composition that occur more than once in the inheritance hierarchy are only included once in their subclasses.

For the UML 1.4 DTD the inheritance follows the rules mentioned, but attributes, references, and composition are copied directly from superclasses to subclasses by means of the XML entity.

For instance, we consider GeneralizableElement class of UML metamodel that inherits the features of ModelElement class (see Figure 8):

<!ENTITY % UML:GeneralizableElementFeatures '%UML:ModelElementFeatures; |
  UML:GeneralizableElement.isRoot |
  UML:GeneralizableElement.isLeaf |
  UML:GeneralizableElement.isAbstract |
  UML:GeneralizableElement.generalization'>
<!ENTITY % UML:GeneralizableElementAtts '%UML:ModelElementAtts;
  isRoot (true|false) #IMPLIED
  isLeaf (true|false) #IMPLIED
  isAbstract (true|false) #IMPLIED
  generalization IDREFS #IMPLIED'>
<!ELEMENT UML:GeneralizableElement (%UML:GeneralizableElementFeatures;)*>
<!ATTLIST UML:GeneralizableElement
       %UML:GeneralizableElementAtts;>

As we can see, in the element declaration it uses only one entity for the content section and only one entity for the attributes of the described XML element.

The declaration of these entities first includes the entity related to the immediate superclass (ModelElement) and then the local attributes and references.

Like GeneralizableElement, the ModelElement class is related to the immediate superclass, named Element, through the %UML:ElementFeature and %UML:ElementAtts entities.

We point out that, after the entities are processed, the expanded DTD obeys the inheritance rules explained.

Attribute Specification

The representation of attributes of a metamodel class uses XML elements and XML attributes. If the metamodel attribute types are primitives or enumerations, XML elements are declared for them as well as XML attributes. One of the reasons for this encoding choice is that the values to be exchanged may be very various and unsuitable for XML attributes; therefore, they need a more exact representation by means of XML elements.

The declaration of an attribute a with nonenumerated type and referred to as class C is as follows:

<!ELEMENT c.a (type specification) >

The type specification for an element may come from the metamodel or be defined outside the metamodel. In the former case the type specification is the name of the type; in the latter case it is considered a string type. If the data are a string type, the declaration of XML element must be as follows:

<!ELEMENT c.a (#PCDATA|XMI.reference)*>

For string type attributes an XML attribute must also be declared in the attribute list of the XML element corresponding to the metamodel class (named c in the example), as follows:

a CDATA #IMPLIED

When a is an attribute with enumerated or boolean values, it uses a different declaration to allow an XML processor to validate the fact that the value of the attribute is one of the legal values of the enumeration

<!ELEMENT c.a EMPTY >
<!ATTLIST c.a xmi.value (enum1 | enum2 | ...) #REQUIRED >

where enum1, enum2, and so forth are possible values of the enumeration set that the attribute itself can assume. An attribute whose type is boolean or an enumeration has to be declared in the XML attribute list of XML elements corresponding to metamodel class, as follows:

a (enum1 | enum2 | ...) #IMPLIED

It is even possible to specify a default value for an attribute. If d is the default value, the last three declarations become:

a CDATA #IMPLIED d

a (enum1 | enum2 | ...) #IMPLIED d

<!ELEMENT a EMPTY >
<!ATTLIST c.a xmi.value (enum1 | enum2 | ...) #REQUIRED d >

Association Specification

Each association role is represented in an XML entity, an XML element, and an XML attribute. Even for this case, the multiplicity is not used (in the XML element declaration it is always "*"). The representation of an association role named r for a metamodel class c is

<!ELEMENT r (content)* >

The XML attribute is declared in the attribute list of the XML element corresponding to its metamodel class, as follows:

r IDREFS #IMPLIED

The content section is defined so that XML elements representing the classifier attached to the referenced associationEnd and any of its subclasses may be included in the XML element r.

For example, if class c1 is the classifier attached to the association end r, and it has three subclasses, c2, c3, and c4, the XML element r would be declared as follows:

<!ELEMENT r (c1 | c2 | c3 | c4)* >

And the XML attribute would be

r IDREFS #IMPLIED

In these declarations, we have always considered the role of an association; the rules are the same if a reference is used (this pseudo-attribute is often used in UML metamodels). In this case the name of the XML element is formed by the name of the class containig the pseudo-attribute followed by a dot and the name of the reference (c.r instead of r, if the c is the metamodel class and r is the reference).

In UML 1.4 DTD this annotation is always used, whereas the content section of XML element representing an association role (or a reference) includes only the classifier attached to the referenced associationEnd, but not its subclasses.

For instance, consider a Generalization class that is associated to a GeneralizableElement class through the association roles child and parent that define whether a class is ancestor or descendant in the generalization relationship. In DTD the declaration is

<!ELEMENT UML:Generalization.child (UML:GeneralizableElement)*>
<!ELEMENT UML:Generalization.parent (UML:GeneralizableElement)*>
<!ENTITY % UML:GeneralizationFeatures '%UML:RelationshipFeatures; |
  UML:Generalization.child |
  UML:Generalization.parent'>
<!ENTITY % UML:GeneralizationAtts '%UML:RelationshipAtts;
  child IDREFS #IMPLIED
  parent IDREFS #IMPLIED'>
<!ELEMENT UML:Generalization (%UML:GeneralizationFeatures;)*>
<!ATTLIST UML:Generalization
       %UML:GeneralizationAtts; >

We emphasize that the content section of XML elements representing the references do not include the subclasses of GeneralizableElement.

Containment Specification

Each association end that represents containment is represented by an XML entity and an XML element. The content section of the XML element representing the association end includes the XML element corresponding to the class, and the XML elements corresponding to each of the subclasses of the class. If there is an association link representing composition between a class c, at the container end, and a class c1 at the other end with a role r and a subclass c2, the representation in an XML DTD is as follows:

<!ELEMENT r (c1 | c2)* >

Also, for containment specification the rules are the same either for the association role or the reference. For instance, consider, in UML 1.4 DTD, the Classifier class which contains the Feature class through a composition; the declaration is

<!ELEMENT UML:Classifier.feature (UML:Feature | UML:StructuralFeature |
UML:Attribute | UML:BehavioralFeature | UML:Operation | UML:Method |
UML:Reception)*>
<!ELEMENT UML:Classifier.powertypeRange (UML:Generalization)*>
<!ENTITY % UML:ClassifierFeatures '%UML:GeneralizableElementFeatures; |
  UML:Namespace.ownedElement |
  UML:Classifier.feature |
  UML:Classifier.powertypeRange'>
<!ENTITY % UML:ClassifierAtts '%UML:GeneralizableElementAtts;
  powertypeRange IDREFS #IMPLIED'>
<!ELEMENT UML:Classifier (%UML:ClassifierFeatures;)*>
<!ATTLIST UML:Classifier
            %UML:ClassifierAtts; >

We point out that in the content section of <UML:Classifier.feature> there are all the subclasses of Feature (this is mandatory for containment association).

It is also important to underline that the XML representation of the containment association does not use the XML attribute to refer to another class because this class exists and therefore it is defined within the container class.

An Example of XML Representation for a Java Class

In this subsection we present an example of a Java class represented in XML and conforming to the UML 1.4 DTD. It is important to highlight that an XML document conforming to a DTD derived from the above-mentioned DTD production rules respects the XML document production rules, too.

The Java source code to be translated is the following (the chosen class is quite simple for exemplification purpose and to keep code small):

package currency.conversion;
//contains methods to convert several currencies
public class Converter {

  final double oneEuro = 1936.27;

  public double lira ToEuro(double lire) {
   return lire/oneEuro; }

  public double euro ToLira(double euro) {
   return euro*oneEuro; }
}

and its XML representation is

<?xml version="1.0 encoding="iso-8859-1"?>
<!DOCTYPE XMI SYSTEM "OTextension.dtd">
<XMI xmlns:UML="org.omg/UML1.4">
       <XMI.header>
              <XMI.metamodel xmi.name="UML" xmi.version="1.4"/>
       </XMI.header>
       <XMI.content>
              <UML:Model xmi.id="x.1" name="Project">
                    <UML:Namespace.ownedElement>
                          <UML:Package xmi.id="x.3" name="currency">
                                <UML:Namespace.ownedElement>
                                <UML:Package           xmi.id="x.4"
name="converter">
                                  <UML:Namespace.ownedElement>
<UML:Class xmi.id="x.6" name="Converter" visibility="public" isLeaf="false" isAbstract="false"
comment="x.5">
                                                     <UML:Classifier.feature>
              <UML:Attribute xmi.id="x.7" name="oneEuro" visibility="public"
changeability="frozen" ownerScope="instance" type="x.2">
                                  <UML:Attribute.initialValue>
                                    <UML:ProcedureExpression language="Java">
               <UML:Expression.body><![CDATA[ 1936.27;]]></UML:Expression.body>
                                    </UML:ProcedureExpression>
                             </UML:Attribute.initialValue>
                 </UML:Attribute>
                 <UML:Operation xmi.id="x.8" name="lira ToEuro" visibility="public"
ownerScope="instance" isLeaf="false" isAbstract="false">
                      <UML:BehavioralFeature.parameter>
       <UML:Parameter xmi.id="x.9" name="lire" kind="in" type="x.2"/>
       <UML:Parameter xmi.id="x.10" name="opReturn" kind="return" type="x.2"/>
                      </UML:BehavioralFeature.parameter>
                </UML:Operation>
                <UML:Method xmi.id="x.11" specification="x.8">
                     <UML:Method.body>
                          <UML:ProcedureExpression language="Java">
    <UML:Expression.body><![CDATA[ return lire/oneEuro;  ]]></UML:Expression.body>
                            </UML:ProcedureExpression>
                       </UML:Method.body>
                     </UML:Method>
  <UML:Operation xmi.id="x.12" name="euro ToLira" visibility="public" ownerScope="instance"
isLeaf="false" isAbstract="false">
                           <UML:BehavioralFeature.parameter>
          <UML:Parameter xmi.id="x.13" name="euro" kind="in" type="x.2"/>
          <UML:Parameter xmi.id="x.14" name="opReturn" kind="return" type="x.2"/>
                          </UML:BehavioralFeature.parameter>
                     </UML:Operation>
                     <UML:Method xmi.id="x.15" specification="x.12">
                          <UML:Method.body>
                              <UML:ProcedureExpression language="Java">
<UML:Expression.body><![CDATA[ return euro*oneEuro; ]]></UML:Expression.body>
                              </UML:ProcedureExpression>
                           </UML:Method.body>
                        </UML:Method>
                     </UML:Classifier.feature>
                   </UML:Class>
                  </UML: Namespace.ownedElement>
              </UML:Package>
           </UML:Namespace.ownedElement>
        </UML:Package>
        <UML:Data Type xmi.id="x.2" name="double"/>
          <UML:Comment xmi.id="x.5">
<UML:Comment.body><![CDATA[//contains methods to convert several currencies]]></UML:Comment.body>
         </UML:Comment>
      </UML:Namespace.ownedElement>
    </UML:Model>
   </XMI.content>
</XMI>

Even if the purpose of this chapter is not to closely examine the XML translation of classes, the above-mentioned example will be better understood by analysing, through the XMI rules, the correspondence between the UML 1.4 DTD and the core of UML metamodel reported in Figure 8 that shows the most important classes used for the translation.

For instance, in the UML metamodel the Class class extends the Classifier abstract class, which is associated to the Feature abstract class through a composition. Feature represents the structural and behavioral features of a class, which are, respectively, attributes (Attribute class) and operations (Operation and Method classes). So the element <UML:Operation> is defined within the element <Classifier.feature> (where feature is the reference referred to Feature in the containment association to Classifier), because there is a composition and Feature is a superclass of Operation. On the other hand, the element <UML:Operation> is related to the element <UML:Method> through an association represented by the XML attribute specification (in fact specification is the role of that association).

The simple class of the example will be used to provide a client the service of converting lira and euro by means of the technologies Enterprise JavaBeans and Remote Method Invocation. The information about methods that fulfill the service and about the client/server communication mode will be represented by a generic entity called Remote Proxy. It will be inserted in the XML document that extends the class of the example, through the XMI.extension element. In the next section we describe the concept of Remote Proxy necessary to understand the metamodel of extensions we will be defining later.


The Remote Proxy Concept

The Remote Proxy is an entity that contains information about the realization of an architecture for distributed computation. Even if it is not the aim of this chapter to closely examine the concepts related to the distributed computational model, they have to be briefly described to better understand the Remote Proxy role.

A software component may be defined as a unit with interfaces specified by contract and with dependencies expressed only following the context (Szyperski, 1998). Generally, a server component provides one or more services to its clients (which could be generally considered as other components).

Therefore a component is composed of operations (methods) that implement the services, of properties (states), and of some kind of events (for instance, asynchronous notifications).

The services, which a component offers, are provided to a client by means of an interface defined in a public way; when we try to invoke the methods of an object located somewhere else, we do not have a local implementation but we need to know the structure to access the methods (the signature of methods), that is the interface. An interface may be defined as an abstract description of accessibility to a specific component (generally a class), without any physical implementation of its functionality.

This means that the client does not worry about the management of a service either for communication with the component, or as the operation that fulfils the service is implemented; the client only knows that the needed service can be required by the public interface, and that the return value of the service component is supposed to be correct.

Generally, a component hides all the management details of its own internal state and this brings considerable advantages: For instance, a component can change the implementation of the service without modifying the structure of client communication

The set of interfaces that a component shows to its own client specifies a contract between the client and the component itself.

Another important concept is that a component can depend on other components to complete the services. So the answer received by the client might not be produced by the component with which it is communicating through the interface, but by a chain of operations among more software components, which are hidden to the client.

It is fundamental for such dependencies to be well expressed and documented, so as to quickly and correctly define which components get involved for a service and, if necessary, how to change them.

As mentioned, usually the components interact among themselves; an architecture, that is a general term, in this context can be defined as a set of correlated components and structures that help to describe dependencies among the components and the way they should react to the events during the life cycle of a specific application.

Furthermore, an architecture can be formed by two, three, or n levels, where a level is a set of software elements (and sometimes hardware elements), components, and services. The purpose of the levels is to allow the distribution of software components and services on different computers to improve scalability and security.

The Remote Proxy is an entity that describes a way to see and to implement the model of distributed computation and therefore it is composed of two parts as follows:

  • public interface: a set of the public methods, implemented within the server component, which define a service, so a client can use the service invoking these methods;

  • communication pattern: a model that describes the fundamental features to fulfill the client/server communication (which is based on the defined public interface) among all components.

Therefore the Remote Proxy (see Figure 5) is closely related to a class existence that provides a service through all (or some) of its public methods. They will be part of the public interface contained within the Remote Proxy.

Click To expand
Figure 5: Definition of the Remote Proxy

Two or more components can communicate in a distributed architecture in several ways: For instance, in this chapter we consider two of the most exploited technologies, RMI and EJB.

It is important to underline that the concept of the Remote Proxy is general and therefore it is not bound to the definition of a single and specific architecture.

In the XML document, the information represented by the Remote Proxy is referred to the class through the XMI.extension element which is inserted within the UML:Class XML element that represents the class itself. In fact, XMI.extension element contains XML elements that also represent metadata which are an extension of the metamodel. These XML elements have to be declared in an internal or external DTD.

At this point, our purpose is to create an MOF-based metamodel that represents the Remote Proxy, which describes information extending the class. Afterwards, we will apply the XML DTD production rules to this metamodel in order to produce its DTD, so that XML elements contained within the XMI.extension element are declared in that DTD.

Use of the Remote Proxy Metamodel

Before describing the Remote Proxy metamodel, we define in a general way the use of this metamodel, underlining that it will extend some of the concepts already modeled in the UML metamodel (as described in the next paragraph).

The Remote Proxy metamodel extends UML metamodel, and both are based on the MOF-model placed at the higher level (see Figure 6). So we expand the standard UML DTD, released by OMG, with the concepts represented by the Remote Proxy metamodel and translated following XMI rules.

Click To expand
Figure 6: Use of UML and Remote Proxy metamodels

At M1-level there are UML and Remote Proxy models that are instances of the metamodels at M2-level.

By means of XMI, these two metamodels will be merged in the corresponding XML document, creating the integration of the extended metamodel through XMI.extension element.

So we obtain an XML document that describes Java classes through the UML metamodel and the services related to these classes through the Remote Proxy metamodel.

The early XML document or the modified one, through the GUI described later, is the input for another application that automatically generates the source code of Java classes. These classes implement the client/server communication mode (EJB or RMI) on the basis of XML elements that describe the metadata of the extended model.

We point out that the classes, created on the basis of RMI or EJB pattern, do not directly provide the service, but they refer to the Java class that in the XML document contains the information about the corresponding Remote Proxy and therefore the real implementation of the service.

In fact, the EJB or RMI classes created are the means to reach the methods containing the source code that generates the right reply to the client request. For example, we consider a body method of a bean or of an RMI remote object, where the class, which is the one described in the XML document, is instanced and the corresponding method, that has of course the same signature, is invoked:

// object instance of the class described in the XML document
Converter obj = new Converter()
public double lira ToEuro(double lire) {
// invocation of the method that contains the real implementation of the sevice
   return obj.lira ToEuro(lire);
 }

The objects, that are instances of the created Java classes, belong to the real modeled system (where we discard the XML representation because it is useless and out of our aims) describing the same modeled system from two different points of view:

  • The objects that derive from Java classes of UML model describe the features of the modeled system.

  • The objects that derive from Java classes of extended model realize the services related to this system.

It is fundamental that the representation of information is in XML language because it significantly eases the automation and grants interoperability with the use of suitable tools and integrated parser; moreover, it grants portability.

Note that this approach can be easily reused with other object-oriented languages (or of another kind); in fact, the UML can be applied also to different programming languages, not only to Java, with the introduction of a few features of the considered language that are not modeled in UML (using constructs as stereotype, constraint, and tagged value).

In our work we have developed two tools that work on the XML document with the support of an XML parser:

  • a Java application provided with a GUI to navigate and manipulate classes defined in an XML document. It reads the XML document and visualizes in a user-friendly way the information about Java source code and communication patterns if present. The user is able to change the information represented by the patterns so as to choose either the client/server communication mode (EJB or RMI) or its features. It is possible to save changes in the same XML document or in a new XML file; Figure 7 is a snapshot of the application.

    Click To expand
    Figure 7: The interface of the application

  • the early XML document or the modified one through the GUI is the input for another application that automatically generates the source code of Java classes. These classes implement the client/server communication mode (EJB or RMI) on the basis of XML elements that describe the metadata of the extended model.

To manage the XML documents, we exploit an XML parser called ElectricXML 7.0 (the adopted way is DOM based) with very good results with regard to both performance and the creation of source code. ElectricXML is based on Java, not on standard interfaces, and it supports Xpath.

Now we explain how to create the Remote Proxy metamodel that extends the UML metamodel.

Definition of the Remote Proxy Metamodel

With regard to the creation of a metamodel that represents the Remote Proxy concept, we considered several solutions. At the end, even for the advantages explained later in this paragraph, we decided to define the Remote Proxy metamodel as an extension of UML metamodel used by means of its DTD to translate the Java classes in XML.

The main motivation that led us to this solution is that the Remote Proxy holds some concepts which are already modeled in the UML metamodel and therefore it would have been useless and disadvantageous to redefine such elements in an isolated metamodel.

In fact, the essential property of an extended metamodel is to exploit to the utmost the internal concepts of UML metamodel through the generalization mechanism, trying to avoid as far as possible the associations between the extended elements and the elements of UML metamodel. Since in this way we favour only the relationship among the extended elements, we isolate the Remote Proxy metamodel and produce a DTD that can be used for the metadata, placed inside the XMI.extension element, without affecting the definition of standard UML DTD.

The elements of the Remote Proxy metamodel extends with the generalization mechanism some of the classes of Core package, which is the backbone of the UML metamodel (see Figure 8).

Click To expand
Figure 8: The backbone of UML Core package

Herewith we briefly describe only the UML metamodel classes that we are going to extend; we invite readers interested in a more complete and detailed explanation to refer to the UML specification (UML Specifications).


Model Element

An abstract class that is a subclass of Element class and its main purpose is to name the entities represented in the model. It is the base for all modeling metaclasses in the UML that are either direct or indirect subclasses of ModelElement. Some of its attributes and associations are:

  • name, an identifier for the ModelElement within its containing Namespace;

  • constraint, a set of constraints affecting the ModelElement;

  • comment, a set of comments relating to the ModelElement;

  • visibility, specifies whether the ModelElement can be seen and referenced by other ModelElement.

The visibility related to the ModelElement can be as follows:

  • public, any outside ModelElement can see the ModelElement;

  • protected, only descendants of the ModelElement can see the ModelElement;

  • private, only the ModelElement itself, or the elements nested within it, can see the ModelElement;

  • package, only ModelElement declared in the same package (or a nested subpackage, to any level) of the given ModelElement can see the ModelElement.


Feature

A feature is a property, like operation or attribute that is placed within a Classifier. In the UML metamodel, a Feature is an abstract metaclass which declares a behavioral or structural characteristic of an instance of a Classifier or of the Classifier itself.

In this metaclass there is a new metaattribute, called ownerScope, which specifies whether the Feature appears in each instance of the Classifier or if there is just a single instance of the Feature for the entire Classifier. The ownerScope attribute can assume one of the following values:

  • instance, whether each instance of the Classifier holds its own value for the Feature;

  • classifier, whether there is only value of the Feature for the entire Classifier.

The definiton of visibility for the Feature is similar to that already defined in the ModelElement class. The Feature metaclass, as we can see in Figure 8, has two abstract subclasses that define the main characteristic of a Feature:

  • StructuralFeature, describes a structural and static feature of a model element, such as an attribute;

  • BehavioralFeature, describes a behavioral and dynamic feature of a model element, such as an operation or method.


Operation

An operation is a service that can be requested from an object to affect its behavior. An operation has a signature defined by some parameters (including arguments and the return value), and it describes the structure of the service but not the implementation, which is represented by the metaclass Method. In the UML metamodel, an Operation is a BehavioralFeature which can be applied to the instances of the Classifier that contains the Operation.

It is important to notice that an operation is related to its parameters through the composition between the BehavioralFeature class and the Parameter class. The Operation class inherits this association from the BehavioralFeature class.


Parameter

A parameter is a variable that can be changed, passed, or returned. A parameter may include a name, a type, and a direction of communication. In the UML metamodel, a Parameter is a declaration of an argument to be passed to, or returned from, an Operation, a Signal (the parameters are also related to messages and events), and so forth. The Parameter metaclass extends the ModelElement class (see Figure 8) and defines the following attributes:

  • defaultValue, an Expression whose evaluation yields a value to be used when no argument is supplied for the Parameter.

  • kind, specifies what kind of a Parameter is required, and the possibilites are in (an input Parameter that can not be modified), out (an output Parameter that may be modified to communicate information to the caller), inout (an input Parameter that may be modified) and return (a return value of a call).

The name of a Parameter, inherited from ModelElement, must be unique within its containing Parameter list.

In the following paragraph we describe the elements of the metamodel that extend the core of UML to include the Remote Proxy concept (see Figure 9).

Click To expand
Figure 9: Metamodel that describes the Remote Proxy

We point out that we have introduced a new DataType to describe some attributes of the elements of the extended metamodel. Such DataType, represented in Figure 10, are all enumerations, and their meaning can be understood later when we explain the attributes they are associated with.

Click To expand
Figure 10: Enumerations introduced in the extended metamodel

The RemoteProxy class extends ModelElement and is in charge of defining the Remote Proxy, and thus of representing the public interface and the client/server communication mode. The public interface is composed of a set of methods represented by the class RemoteOperation, which are contained (via a composition relationship) inside the RemoteProxy itself through the association role called publish. The different ways of communication are generalized by the abstract class CommunicationFeature, which is bound to the RemoteProxy class through a containment relationship represented by the reference communication.

The attributes and the references that describe the Remote Proxy are

  • name (of String type) defines the name of the Remote Proxy, and such a name is part of the name of the classes created to implement the client/server communication;

  • destination Package (String) is the name of the package that includes the classes created to implement the client/server communication;

  • comment (role of the association related to the Comment class) is a reference that expresses a possible comment related to the Remote Proxy.

Please, note that name and comment are inherited from the ModelElement superclass.

The abstract class CommunicationFeature has been introduced to generalize all the different patterns of communication, and to create a common container inside the RemoteProxy class. The introduction of such a class enables the future possibility of adding or removing patterns. We have chosen to extend the Feature class because CommunicationFeature always describes fundamental features of an entity, even if bound to the Remote Proxy rather than to a Classifier.

One may now ask why the Remote Proxy does not extend the Classifier class instead of ModelElement. We considered this choice, but we discarded it for two reasons related to our aim about the construction of the extended metamodel:

  • Classifier contains many attributes inherited from superclasses such as GeneralizableElement (which enables the generalization of an element) and NameSpace, which are not useful for the definition of Remote Proxy, whereas ModelElement, the highest element of the hierarchy, meets the requirements;

  • A Classifier subclass is placed deeply inside the UML class hierarchy, and is very bound to the other classes of the package. The Remote Proxy is the class that, more than others, creates associations in the extended model by communication operations and patterns; if it were a Classifier subclass, it would have substantially affected the UML standard DTD.

The classes derived directly from CommunicationFeature describe two different ways of client/server communication: RMI and EJB. It is not in the aim of this chapter to describe the RMI or EJB technologies; interested readers can find more details in the corresponding specifications (RMI Specifications; EJB Specifications).

RMI is a technology developed by SUN Microsystems, which enables the remote communication between Java applications. It is modeled by the Rmi class, which contains two attributes:

  • registry Name (String), which represents the name with which the server object is registered by the RMI registry;

  • clientCallType (CallKind), which says whether the RMI invocation is performed via HTTP (http value) or via socket (socket value).

Thanks to these two pieces of information and the methods of the public interface, it is possible to create the classes for the RMI implementation of the Remote Proxy class that we want to extend.

EJB represents a specification for the development of enterprise applications that is based on transactional and distributed components. Three kinds of EJB exist:

  • session bean represents an operative logic of the application usually composed of different computational steps that must result atomic;

  • entity bean represents specific data or data collection. This kind of persistent components usually provides methods for the interaction with the data they represent;

  • message bean has been proposed by the last version of EJB (the 2.0), and is exploited to manage the JMS (Java Message Service) messages in an asynchronous way.

The EJB pattern of our work aims at modeling only the session bean. To grant flexibility and to take into consideration also the other kinds of bean, we have chosen to create the Ejb class, which includes the attributes common to all three kinds of bean. Such attributes are:

  • name (String) inherited from ModelElement, it represents the name that the bean assumes in the deployment phase, where it is associated to the <ejb-name> tag;

  • jndiName (String) it represents the name that the bean assumes in the lookup phase;

  • remote (Boolean) it says whether the bean implements a remote interface;

  • local (Boolean) it says whether the bean implements a local interface.

The remote and local attributes are separated because a bean can be both remote and local at the same time. The EjbSession class extends the Ejb class specifying the features of a session bean. A session bean can be of two kinds:

  • stateless, the bean without state does not maintain any kind of information over different invocations of its methods by the client, and for this reason is usually exploited to perform atomic operations independent of the context where it lives;

  • stateful, the bean with state is instead capable of recording a state over two client invocations, and is tightly bound to the associated client.

The attributes of EjbSession are:

  • kind (SessionBeanKind) it assumes the value stateless if the bean is without a state, Stateful otherwise;

  • transactionType (TransactionManager) it assumes the value container if the transactions are managed by the bean container, as in most cases, the value bean if the transactions are managed by the bean developer.

Containers represent the execution environment of the EJB, and provide beans with basic services through the standard API defined in the EJB specifications. The container can manage the life cycle of the components, the transactions, the security, the persistence issues, and other services in a transparent way with respect to the clients and the EJB developer, which can focus on the implementation of the application logic of her/his components.

Now we describe the classes related to the Remote Proxy public interface. It is composed of a set of operations published by the class which it refers to, and for this reason the operations have features similar to those already defined in the corresponding operations of the class itself (in the XML document the element is UML:Operation). Therefore, it is natural that the class of the extended metamodel that represents an operation of the public interface, that is, RemoteOperation, has Operation as superclass. The only attribute of RemoteOperation different from those of Operation is transactionAttribute (of type TransactionKind), which represents the kind of transaction of the operation, in the case that the operation is part of a bean and the transactions are managed by the container. If, instead, the transactions are managed by the bean developer or the operation is not part of a bean (for instance, is part of an RMI service), the attribute is not included in the XML translation. According to the EJB specifications, transactionAttribute can assume one of the following values: required, requiresnew, notsupported, supports, mandatory, or never.

As explained in the following paragraphs, in the XML translation of the Remote Proxy the published operations represent only information useful to define the method signature in the chosen context; that is, the attribute name and visibility inherited from UML:Operation (of course, the visibility is always public) and possibly the just-mentioned transactionAttribute. Nevertheless, other pieces of information about the operation can be included, thanks to the further attributes inherited from UML:Operation. The signature of a class method is completed by specifying the parameters (we recall that the type of the return value of a method is the type of a parameter of kind return). In the extended metamodel, the class RemoteParameter is a subclass of Parameter and adds the passage attribute of type ParameterPassageKind. It says whether the parameter is passed by copy (byValue value) or by reference (byReference value).

Now let us give the reasons why the RemoteOperation specifies its own parameters via a composition toward RemoteParameter, made explicit by the role remoteParameter and not via BehavioralFeature.parameter as UML:Operation does. The reason is the same we mentioned when discussing about the Classifier and RemoteProxy classes: that is, we have chosen to not modify the UML standard DTD. In fact, RemoteOperation could have referred to RemoteParameter via BehavioralFeature.parameter, but only if, according to the XMI rules, the UML DTD were modified and the element RemoteParameter had been added to the composition relationship that already included the Parameter superclass. In that case, there would have been a clear fusion of the two metamodel, and so we have decided to create an association between the RemoteOperation and RemoteParameter elements, similar to that presented in the corresponding superclass of the UML metamodel.

The chosen approach implies important advantages:

  • The exploitation of concepts already modeled in UML has allowed us to not redefine completely the Remote Proxy metamodel, and to create a logical and structural binding between the two metamodels;

  • The fact that extending the UML metamodel on the one hand, and of isolating the extended metamodel thanks to the associations described above on the other hand, has created a binding between the two metamodels and at the same time has kept them separated. This has permitted us to not modify the UML standard DTD and thus to reuse it also when new versions are available, because the core package is likely to not change. Moreover, the metamodel of the extensions can evolve (for instance, by adding new patterns) without modifying the UML metamodel.

A drawback of this approach concerns the incorrect application of the XMI rule that translates the composition relationships of the metamodel. Such a rule says that the XML element of the DTD that specifies the role of the composition must refer to the contained class and to all its subclasses. Although for the extended metamodel the rule is respected, with regard to the UML DTD all the new classes of the extended metamodel that become subclasses of the already existing UML classes should be included in the compositions; for example, the classes CommunicationFeature, Ejb, EjbSession, and Rmi should be included in the element <UML:Classifier.feature>. Anyway, we must underline that, according to the structure of our approach, the new elements of the extended metamodel never interact directly with the UML elements (except for the relationships inherited from superclasses), which, in turn, do not need to specify the extended classes because they never use them.

DTD of the Extended Metamodel

In this subsection we apply the DTD production rules to the Remote Proxy metamodel described in the previous subsection. We obtain the DTD reported in the following paragraphs, which describe the extended metamodel. Please note that the DTD of the UML 1.4 metamodel is considered as an external resource, included into the Remote Proxy DTD by means of an external parametric entity. This choice makes the DTDs of the two metamodel s more readable and manageable; moreover, the UML DTD does not risk being modified, and the original version of it is kept. By means of external parametric entities, it would be possible to integrate more than two metamodels in a clean way. To further distinguish the XML elements compliant to the extended metamodel DTD, we have chosen to declare the EXT namespace.

<?xml version="1.0" encoding="UTF-8"?>
<!---dtd OTextension version 2.0 (september 2003) --->
<!---definition of a parametrical external entity that allows to include an external DTD
(the one of the UML metamodel) in the current DTD --->
<!ENTITY % UML14dtd SYSTEM "uml14.dtd">
%UML14dtd;
<!---definition of the namespace associated to the metamodel of the Remote Proxy; the
XMI element is declared in the imported UML DTD --->
<!ATTLIST XMI
       xmlns:EXT CDATA #IMPLIED>
<!---elements of the metamodel that describes the Remote Proxy --->
<!--- =========EXT:RemoteProxy ========= --->
<!ELEMENT EXT:RemoteProxy.destinationPackage (#PCDATA | XMI.reference)*>
<!ELEMENT EXT:RemoteProxy.publish (EXT:RemoteOperation)*>
<!ELEMENT EXT:RemoteProxy.communication (EXT:CommunicationFeature |
EXT:Rmi | EXT:Ejb | EXT:EjbSession)*>
<!ENTITY % EXT:RemoteProxyFeatures '% UML:ModelElementFeatures; |
       EXT:RemoteProxy.communication |
       EXT:RemoteProxy.publish |
       EXT:RemoteProxy.destinationPackage'>
<!ENTITY % EXT:RemoteProxyAtts '% UML:ModelElementAtts;
         destination Package CDATA #IMPLIED'>
<!ELEMENT EXT: RemoteProxy (%EXT:RemoteProxyFeatures;)*>
<!ATTLIST EXT:RemoteProxy
       %EXT:RemoteProxyAtts;>
<!--- =========EXT:CommunicationFeature =========--->
<!ELEMENT EXT:CommunicationFeature.remoteOwner (EXT:RemoteProxy)*>
<!ENTITY % EXT:CommunicationFeatureFeatures '%UML:FeatureFeatures; |
          EXT:CommunicationFeature.remoteOwner'>
<!ENTITY % EXT:CommunicationFeatureAtts '%UML:FeatureAtts;
          remoteOwner IDREFS #IMPLIED'>
<!ELEMENT EXT: CommunicationFeature (%EXT:CommunicationFeatureFeatures;)*>
<!ATTLIST EXT:CommunicationFeature
       %EXT:CommunicationFeatureAtts; >
<!--- =========EXT:Rmi =========--->
<!ELEMENT EXT:Rmi.registryName (#PCDATA | XMI.reference)*>
<!ELEMENT EXT:Rmi.clientCallType EMPTY>
<!ATTLIST EXT:Rmi.clientCallType
       xmi.value %EXT:CallKind; #REQUIRED>
<!ENTITY % EXT:RmiFeatures '%EXT:CommunicationFeatureFeatures; |
       EXT:Rmi.clientCallType |
       EXT:Rmi.registryName'>
<!ENTITY % EXT:RmiAtts '%EXT:CommunicationFeatureAtts;
       clientCallType %EXT:CallKind; #IMPLIED
       registryName CDATA #IMPLIED'>
<!ELEMENT EXT:Rmi (%EXT:RmiFeatures;)*>
<!ATTLIST EXT:Rmi
       %EXT:RmiAtts;>
<!--- =========EXT:Ejb =========--->
<!ELEMENT EXT:Ejb.jndiName (#PCDATA | XMI.reference)*>
<!ELEMENT EXT:Ejb.remote EMPTY>
<!ATTLIST EXT:Ejb.remote
       xmi.value (true | false) #REQUIRED>
<!ELEMENT EXT:Ejb.local EMPTY>
<!ATTLIST EXT:Ejb.local
       xmi.value (true | false) #REQUIRED>
<!ENTITY % EXT:EjbFeatures '%EXT:CommunicationFeatureFeatures; |
       EXT: Ejb. local |
       EXT: Ejb. remote |
       EXT: Ejb.jndiName'>
<!ENTITY % EXT:EjbAtts '%EXT:CommunicationFeatureAtts;
       local (true | false) #IMPLIED
       remote (true | false) #IMPLIED
       jndiName CDATA #IMPLIED'>
<!ELEMENT EXT:Ejb (%EXT:EjbFeatures;)*>
<!ATTLIST EXT:Ejb
       %EXT:EjbAtts;>
<!--- =========EXT:EjbSession =========--->
<!ELEMENT EXT:EjbSession.kind EMPTY>
<!ATTLIST EXT:EjbSession.kind
       xmi.value %EXT:SessionBeanKind; #REQUIRED>
<!ELEMENT EXT:EjbSession.transactionType EMPTY>
<!ATTLIST EXT: EjbSession.transaction Type
       xmi.value %EXT:TransactionManager; #REQUIRED>
<!ENTITY % EXT:EjbSessionFeatures '%EXT:EjbFeatures; |
       EXT:EjbSession.transactionType |
       EXT: EjbSession.kind'>
<!ENTITY% EXT:EjbSessionAtts '%EXT:EjbAtts;
       transactionType %EXT:TransactionManager; #IMPLIED
       kind %EXT:SessionBeanKind; #IMPLIED'>
<!ELEMENT EXT:EjbSession (%EXT:EjbSessionFeatures;)*>
<!ATTLIST EXT:EjbSession
       %EXT:EjbSessionAtts;>
<!--- =========EXT:RemoteOperation =========--->
<!ELEMENT EXT:RemoteOperation.remoteOwner (EXT:RemoteProxy)*>
<!ELEMENT EXT:RemoteOperation.transactionAttribute EMPTY>
<!ATTLIST EXT:RemoteOperation.transactionAttribute
       xmi.value %EXT:TransactionKind; #REQUIRED>
<!ELEMENT EXT:RemoteOperation.remoteParameter (EXT:RemoteParameter)*>
<!ENTITY % EXT:RemoteOperationFeatures '%UML:OperationFeatures; |
  EXT:RemoteOperation.transactionAttribute |
  EXT:RemoteOperation.remoteParameter |
  EXT:RemoteOperation.remoteOwner'>
<!ENTITY % EXT:RemoteOperationAtts '%UML:OperationAtts;
       transactionAttribute %EXT:TransactionKind; #IMPLIED
       remoteOwner IDREFS #IMPLIED'>
<!ELEMENT EXT:RemoteOperation (%EXT:RemoteOperationFeatures;)*>
<!ATTLIST EXT:RemoteOperation
       %EXT:RemoteOperationAtts;>
<!--- =========EXT:RemoteParameter =========--->
<!ELEMENT EXT:RemoteParameter.remoteOperation (EXT:RemoteOperation)*>
<!ELEMENT EXT:RemoteParameter.passage EMPTY>
<!ATTLIST EXT:RemoteParameter.passage
       xmi.value %EXT:ParameterPassageKind; #REQUIRED>
<!ENTITY % EXT:RemoteParameterFeatures '%UML:ParameterFeatures; |
  EXT:RemoteParameter.passage |
  EXT:RemoteParameter.remoteOperation'>
<!ENTITY % EXT:RemoteParameterAtts '%UML:ParameterAtts;
       passage % EXT:ParameterPassageKind; #IMPLIED
       remoteOperation IDREFS #IMPLIED'>
<!ELEMENT EXT:RemoteParameter (%EXT:RemoteParameterFeatures;)*>
<!ATTLIST EXT:RemoteParameter
       %EXT:RemoteParameterAtts; >
<!--- =========entities used for the enumerations of the metamodel of the Remote
Proxy =========--->
<!ENTITY % EXT:ParameterPassageKind '(byValue | byReference)'>
<!ENTITY % EXT:TransactionKind '(required | requiresnew | notsupported | supports
| mandatory | never)'>
<!ENTITY % EXT:CallKind '(http | socket)'>
<!ENTITY % EXT:SessionBeanKind '(stateful | stateless)'>
<!ENTITY % EXT:TransactionManager '(container | bean)'>

Finally, we consider the example class of this chapter, with the aim of making it a remote service by means of a Remote Proxy; it has a public interface, composed of both of the public methods of the class, and the communication mode is a stateless session bean with transactions managed by the container. Such information is represented by XML elements of the extended metamodel, compliant to the above DTD, included in the <XMI.extension> element associated to the class. Due to limitation of space, we do not report the whole XML translation of the class; the omitted parts can be found in the previous XML document.

<?xml version="1.0" encoding="iso-8859-1"?>
<!DOCTYPE XMI SYSTEM "OTextension2.dtd">
<XMI xmlns:UML="org.omg/UML1.4" xmlns:EXT="OTconsulting/extension">
       <XMI.header>
              <XMI.metamodel xmi.name="UML" xmi.version="1.4"/>
              <XMI.metamodel xmi.name="EXT" xmi.version="2.07"/>
       </XMI.header>
       <XMI.content>
       ........model and package.............................

<UML:Class xmi.id="x.6" name="Converter" visibility="public" isLeaf="false" isAbstract="false"
comment="x.5">
  <XMI.extension xmi.extender="OTextension">
      <EXT:RemoteProxyxmi.id="16"name="ConverterRp"destinationPackage="currency.service">
                       <EXT:RemoteProxy.publish>
  <EXT:RemoteOperationxmi.id="x.17"name="liraToEuro "visibility="public"transactionAttribute="supports">
      <EXT:RemoteOperation.remoteParameter>
           <EXT:RemotParameterxmi.id="x.18"name="lire"kind="in"type="x.2"passage= "byReference">
           <EXT:RemoteParameter xmi.id="x.19" name="opReturn" kind="return" type="x.2">
                      </EXT:RemoteOperation.remoteParameter>
       </EXT:RemoteOperation>
  <EXT:RemoteOperation xmi.id="x.20" name="euroToLira" visibility="public"
   transactionAttribute="required">
          <EXT:RemoteOperation.remoteParameter>
                <EXT:RemoteParameterxmi.id="x.21"name="euro"kind="in"type="x.2"passage=
                 "byReference">
                   <EXT:RemoteParameterxmi.id="x.22"name="opReturn"kind="return"type="x.2">
         </EXT:RemoteOperation>.remoteParameter>
            </EXT:RemoteOperation>
           </EXT:RemoteProxy.publish>
  <EXT:RemoteProxy.communication>
  <EXT:EjbSession xmi.id="x.23" name="ConverterEjbS" jndiName="ConverterEjbS"
remote="true" local="false" kind="stateless" transactionType="container"/>
    </EXT:RemoteProxy.communication>
  </EXT:RemoteProxy>
</XMI.extension>
                        <UML:Classifier.feature>
                     ........attributes, operations and methods............

                            </UML:Classifier.feature>
                    </UML:Class>
            .......datatype and comment.......................

     </XMI.content>
</XMI>


Future Trends

Besides refining the commercial version of the tools, OTConsulting aims at carrying on the research presented in this chapter.

An interesting direction of research is the modeling of the method body; this implies a more general approach, since we would not have to include the actual code of the method in the XML documents. The same XML document could be used with different programming languages compliant to the modeling. This modeling is not trivial and must be carefully explored.

A second direction is the integration of our approach with existing modeling tools, which can manage our XML documents. For example, an interesting compliance that we have verified is with Together (a Borland tool to project software). We are going to deeply investigate a possible integration of our tool with Together by the creation of suitable plug-ins relying on Together Open API. Currently, we have developed a prototype plugin composed of four modules, which enables the use of the Remote Proxy concept in Together. This plug-in can support different architectures (currently EJB and RMI). However, at the time of writing, if a developer wants to add a new architecture, the plug-in must be extended (better, the class of a module must be subclassed); this is due to keeping compliance with the XML management of Together, but we are exploring the development of a more general plug-in, which obtains the information about the desired architecture from the XML documents. Moreover, other existing commercial and open-source tools will be considered to study possible integrations.


Conclusion

In this chapter we have reported on an experience about class evolution carried out at OTConsulting. Our main aims were to describe classes in an abstract and interoperable way, and to enable class evolution in terms of extension. We have presented our approach that exploits interoperable standards such as XML, UML, and XMI, and relies on the MOF metamodels. A class is described by an XML document that is compliant with the UML model. Exploiting the Remote Proxy concept, classes can be extended to fit different (or future) distributed architectures. Such an extension can be performed by automated tools that manipulate the XML description. From the manipulated XML document it is easy to obtain the needed Java classes.

The main advantage of our approach is that we define the Remote Proxy as a model at MOF level M2, instead of an instance at level M1 as could be done by using available tools; this has several positive effects:

  • The concept of Remote Proxy has an adequate description in terms of model, which is also kept unbroken and is easier to manage;

  • We work at a higher abstraction level, exploiting XMI to the utmost by defining an appropriate DTD of the Remote Proxy;

  • Having a DTD enables the validation, the extension, and the automatic manipulation of XML documents;

  • Stereotypes, constraints, and tagged values could be exploited to define extensions, but they are not bound to the DTD, loosing the previously mentioned advantages; and

  • Finally, stereotypes, constraints, and tagged values lead to more verbose documents, which imply lower performances.

We outline some other important issues.

First, the aim of this approach is to define a process to let evolve a generic class described in UML and represented via XML documents. Thus, this process can be applied to other OO programming languages compliant with UML (using constructs such as stereotype, constraint, and tagged value), to other communication patterns such as those of CORBA (CORBA Components) or .NET components (.NET Framework), and in general to whatever metamodel deriving from the UML and compliant to MOF, independently of the Remote Proxy concept.

Second, we emphasize that an important issue in our work has been the trade-off between rigorousness and feasibility. In fact, on the one hand, we had to respect the rules of the UML and the programming languages, to grant interoperability and a correct code generation; on the other hand, our aim was to produce a commercial application, reducing complexity and granting usability.

Finally, we remark that we have implemented the mentioned tools and GUI (which are not publicly available because they are owned by OTConsulting) in Java, and have tested them with XML files of different sizes, ranging from a few kilobytes to some tenth of megabytes. They demonstrate that our study has produced usable results. Also the performance results were quite good; after the initial loading of the file, which takes from less than a second to about a minute, the navigation through classes and their manipulation does not imply intolerable delays. In particular, the chosen XML parser (EXML 7.0) is quite fast in the navigation of the DOM tree.


References

.NET framework. Microsoft. Retrieved from http://msdn.microsoft.com/netframework/

Arnold, S.P., & Stepoway, S.L. (1987). The reuse system: Cataloguing and retrieval of reusable software. Proceedings of IEEE Spring COMPCON '87, San Francisco, 376–379.

Badros, G. J. (2000). Javaml: A markup language for java source code. Proceedings of the ninth International World Wide Web Conference. Amsterdam, NL.

Banerjee, A., & Naumann, D. A. (2002). Representation independence, confinement, and access control. Proceedings of the 29th SIGPLAN-SIGACT Symposium on Principles of Programming Languages. Portland, OR.

Bryant, B. R. (2000, January). Object-OrientedNatural Language Requirements Specification. Proceedings of the Australasian Computer Science Conference. Canberra, Australia.

Casais, E. (1995). Managing class evolution in object-oriented systems. In D. Tsichritzis (Ed.), Object-Oriented Software Composition, 133–195. New York: Prentice Hall.

CORBA Components. OMG. Retrieved from http://www.corba.org

Devanbu, P., Brachman, R., Selfridge, P., & Ballard, B. (1991). LaSSIE: A knowledge-based software information system. Communication of the ACM, 34(5), 34–49.

Deveaux, D., & Le Traon, Y. (2001). XML to manage source engineering in object-oriented development: An example. Proceedings of the workshop XML Technologies and Software Engineering, Toronto, Canada.

Enterprise Java Beans (EJB) Specification. JavaSoft. Retrieved from http://www.Javasoft,com

Jarzabek, S., Basset, P., Zhang, H., & Zhang, W. (2003). XVCL: XML-based variant configuration language. Proceedings of the International Conference on Software Engineering, ICSE' 03. Portland, OR.

Keienburg, F., & Rausch, A. (2001). Using XML/XMI for tool supported evolution of UML models. Proceedings of the 34th Annual Hawaii International Conference on System Sciences.

Lillie, C. (1991). Now is the time for a national software repository. AIAA Computing Aerospace. Baltimore, MD.

Meling, R., Montgomery, E.J., Ponnusamy, P.S., Wong, E.B., & Mehandjiska, D. (2000). Storing and retrieving software components: A component description manager. Proceedings of the Australian Software Engineering Conference.

Meta Object Facility (MOF) Specification, Version 1.4. Object Management Group.

Mili, A., Mili, R., & Mittermeir, R. (1998). A survey of software components storage and retrieval. Annals of Software Engineering, 5, 349–414.

Model Drive Architecture (MDA). OMG. Retrieved from http://www.omg.org/mda/

Remote Method Invocation Specification. JavaSoft. Retrieved from http://www.Javasoft.com

Szyperski, C. (1998). Component software: Beyond object-oriented programming. Boston: Addison-Wesley.

Unified Modeling Language (UML) Specification, Version 1.4. Object Management Group.

Vitharana, P., Zahedi, F.M., & Jain, H. (2003). Knowledge-based repository scheme for storing and retrieving business components: A theoretical design and an empirical analysis. IEEE Transactions on Software Engineering, 29(7), 649–664.

XDoclet project, retrieved from http://xdoclet.sourceforge.net/

XML Metadata Interchange (XMI) Specification, Version 1.2. Object management Group.

Yang, H., & Ward, M. (2003). Successful Evolution of Software Systems. Artech House.


Index

A

abstraction techniques 297
activity diagram 146
ADLs 336
agent communication language 264
application-to-application (A2A) 60
architectural design 324
architecture evaluation 31
ATM 9
automatic verification 297


Index_B

Team LiB

Index

B

behavioral description 329
bidirectional transformations 65
branch coverage 274
business-to-business (B2B) 60


Index_C

Team LiB

Index

C

capability of a tester 276
CASE (computer-aided software engineering) tools 297
change propagation 4
change-based versioning 5
class diagram 10, 137
classes 353
co-evolution 6
collaboration diagrams 147
common warehouse metamodel (CWM) 57
communication protocols 282
compatibility 278
completeness analysis 225
component 353
component-based software 191
computation independent model (CIM) 63
control area network (CAN) 193
control-flow 274
cooperative agents 267
cooperative information system 271
CPI 337


Index_D

Team LiB

Index

D

data flow diagram (DFD) 136, 143
data model 136
data-flow 274
database analysis and design 136
description logic 1, 271
design critics 6
development risks 267
DSPs 323
dynamic analysis and design 136


Index_E

Team LiB

Index

E

e-commerce 265
e-govermment 265
e-science 265
e-type program 264
Enterprise Java Beans 353
enterprise portal 265
entity life histories (ELHs) 138
entity-relationship diagram 137
error-based testing 274
evolution 263
evolution support techniques 3
evolutionary behaviours 265
evolvable system 59
evolving UML models 2
eXtensible markup language (XML) 57
extension 353


Index_F

Team LiB

Index

F

fault-based testing 274
formal method 101
formal specification 102


Index_G

Team LiB

Index

G

geographical information systems 341
Gödel-like uncertainties 265
GPS 340
growth model of software process 264


Index_H

Team LiB

Index

H

Heisenberg-type uncertainties 265
horizontal traceability 4
hyperlinks 270
hypertext applications 270


Index_I-J

Team LiB

Index

I-J

illocutionary forces 282
impact analysis 4
inconsistency management 1, 7
input domain analysis 331
input test cases 328
integration environment 197
integration testing 273
intellectual property 322
interaction diagrams 147
interface agents 268
interval temporal logic (ITL) 69


Index_K

Team LiB

Index

K

knowledge interchange format 271


Index_L

Team LiB

Index

L

law of diversity 265
laws of evolution 265
legacy program 66
linear independent path coverage 270
link coverage 270
low cost 322


Index_M

Team LiB

Index

M

metadata model 192
metainformation 270
metavariables 159
microsoft intermediate language (MSIL) 66
model checking 297
model refactoring 1
model-driven architecture (MDA) 57
MOF (meta object facility) 354
multiagent 263
multiagent system 271
multicore chipset 340


Index_N

Team LiB

Index

N

node coverage 270
normal form 138


Index_O

Team LiB

Index

O

object-oriented (OO) 62, 101
object-oriented method 101
object-oriented modeling 271
object-oriented program designs 139
object-oriented programmers 135
off-the-shelf domain tools 197
ontology 263
open services gateway initiative 191


Index_P-Q

Team LiB

Index

P-Q

P-type program 264
path coverage criteria 274
performance improvement 346
performance prediction 323
physical database 136
platform description 329
platform independent model (PIM) 63
platform specific model (PSM) 63
power consumption 322
pragmatic uncertainties 265
product configuration management (PCM) 191
product evolution 194
product line 153
program translation 66
program understanding 56
program-based 274
programming language 191
property patterns 300


Index_R

Team LiB

Index

R

rapid and adaptive testing 223
refactoring 5
registration 268
regression testing 270
relational unified process 101
reliable software 297
remote method invocation 353
remote proxy 354
response 136
restructuring 5
robustness patterns 222, 224
round-trip engineering 5
RUP 101


Index_S

Team LiB

Index

S

S-type program 264
safety 322
safety-related requirements 32
scenario patterns 222
sequence diagram 10, 141
service agents 268
services configuration management 194
software architecture 57, 323
software artefact 272
software classes 105
software components 191
software development process 2
software evolution 1, 2, 152, 353
software failure mode and effect analysis (SFMEA) 32
software fault tree analysis (SFTA) 33
software growth environment 263
software reengineering 55, 56
software restructuring 5
software storage 353
software testing 263
specification-based 274
speech-act 282
speedup 347
SSADM 134
stakeholders 267
state charts 143
state diagrams 10
statement coverage 274
structural testing 274
structured analysis and design 134
structured systems analysis 134
subsumption relation 278
system decomposition 31
system on Chip 322
system testing 273
system-level simulation 333
SystemC 333
systems analysis 136


Index_T

Team LiB

Index

T

task allocation 268
task scheduling 282
taxonomy 272
telematic control unit (TCU) 193
template metacomponents 154
test case generation 273
test case generator 270
test coverage measurement 273
test execution 273
test oracles 270
test planning 273
test plans 274
test report generation 273
test result validation 273
test script templates 223
test scripts 274
test suites 274
testers 272
testing activity 272
testing assistants 271
testing criteria 270
testing methods 274
testing task 277
time pressure 267
trace-driven simulators 335
traceability 1


Index_U

Team LiB

Index

U

UML (Unified Modeling Language) 1, 32, 57, 134, 264, 297
UML 1.4 DTD 361
UML design models 3
UML models 101
UML profile 15
UML strategies 299
uncertainties 265
unified software reengineering (USR) 68
unit testing 273


Index_V

Team LiB

Index

V

variability mechanisms 153
verification pattern (VP) 222
version control 5, 6
vertical traceability 4
virtual enterprises 191


Index_W

Team LiB

Index

W

Web-based application 263
Web-based CRM systems 265


Index_X

Team LiB

Index

X

XMI (XML metadata interchange) 354
XML 8, 60, 134, 264, 299
XML parsers 337
XML schema 272, 336
XSLT 20
xUML 326
XVCL 153


Index_Y-Z

Team LiB

Index

Y-Z

Y-chart approach 327


List of Figures

Chapter I: A Framework for Managing Consistency of Evolving UML Models

Figure 1: Tool support for evolving UML models
Figure 2: Horizontal and vertical traceability relationships
Figure 3: Tool setup for managing inconsistencies in UML with description logics
Figure 4: Class diagram for the ATM example
Figure 5: Sequence diagram for ATM example
Figure 6: State diagram for the PrintingATM class
Figure 7: Three types of consistency between UML models
Figure 8: UML metamodel changes for enabling model consistency
Figure 9: ATM class hierarchy, version 1
Figure 10: Sequence diagram for deposit transactions in the ATM class
Figure 11: Sequence diagram for deposit transactions in the PrintingATM class

Chapter II: Deriving Safety-Related Scenarios to Support Architecture Evaluation

Figure 1: A sample software fault tree (Sommerville, 2001)
Figure 2: The overview of the process
Figure 3: The four views system decomposition
Figure 4: A Sample utility tree
Figure 5: The outline of the process
Figure 6: The activities within each view
Figure 7: The conceptual view of the insulin delivery system (Sommerville, 2001)
Figure 8: Portion of the module view of the insulin delivery system (Sommerville, 2001)
Figure 9: The fault tree of "insulin overdose" in the module view (Sommerville, 2001)
Figure 10: The utility tree of the insulin delivery system
Figure 11: The use case diagram of misuse cases UC1 and UC2
Figure 12: The sequence diagram of misuse scenario MSM1

Chapter III: A Unified Software Reengineering Approach towards Model Driven Architecture Environment

Figure 1: An evolvable system implemented in combined B2B and J2EE architecture
Figure 2: The pipe and filter pattern
Figure 3: A drainage system represented in a UML profile
Figure 4: XMI representation for a drainage system
Figure 5: The MDA process
Figure 6: Software reengineering within MDA environment
Figure 7: A cubic model for understanding legacy systems
Figure 8: The USR framework
Figure 9: A USR process
Figure 10: The process of modules identification
Figure 11: The process of components identification
Figure 12: The process of architecture recovery
Figure 13: XML schema for a component
Figure 14: XML schema for a connector
Figure 15: XML schema for configuration
Figure 16: XML schema for M&R database
Figure 17: XML schema for C&C database
Figure 18: A simplified grammar for CLS
Figure 19: AST form of RWSL duration statement
Figure 20a: Duration statement in XML-based AST
Figure 20b: XML schema for AST
Figure 21: The Interpreter and Visitor design patterns
Figure 22: UML diagram for component
Figure 23: UML diagram for Connector
Figure 25: UML diagram for architecutre as Component & Connector
Figure 24: UML diagram for Configuration
Figure 26: Noughts and crosses
Figure 27: Source code of the server side class XOServer
Figure 28: COOL code of the server side class XOServer
Figure 29: XOServer after applying elementary abstraction rules
Figure 30: XOServer after applying further abstraction rules
Figure 31: Architecture description of noughts and crosses

Chapter IV: Towards the Integration of a Formal Object-Oriented Method and Relational Unified Process

Figure 1: Requirement model of a library system
Figure 2: Design model of a library system
Figure 3: Requirement model in the second interation
Figure 4: Design model of the second iteration

Chapter V: On the Co-Evolution of SSADM and the UML

Figure 1: Proposed mappings from SSADM to UML
Figure 2: A traditional example of an SSADM Logical Data Structure
Figure 5: A traditional entity life history
Figure 8: A traditional SSADM data flow diagram
Figure 3: SSADM data structure ( Figure 2) in the UML
Figure 4: A sequence diagram for the sample query
Figure 6: A state chart derived from Figure 5
Figure 7: UML2.0 sequence diagram modeling Figure 5
Figure 9: An object flow from an activity diagram
Figure 10: UML 2.0 activity diagram modeling half of Figure 8
Figure 11: Use Case translation of Figure 8
Figure 12: Collaboration diagram for half of Figure 8
Figure 13: The UML2.0 component diagram of Figure 8

Chapter VI: Software Evolution with XVCL

Figure 1: Component construction with XVCL
Figure 2: Tracing variants' impact across software assets
Figure 3: Class diagram of the XVCL commands
Figure 4: Example of an x-framework and SPC
Figure 5: Example of metacomponent processing
Figure 6: A metavariable scoping rule example
Figure 7: A snapshot of City Guide system (GS-PC)
Figure 8: The main stages in "reengineering into the product line architecture"
Figure 9: Use cases for GS-PC
Figure 10: GS-PC runtime architecture
Figure 11: Feature diagram for the City Guide domain
Figure 12: An x-framework for the GS-PC
Figure 13: SPC for J2SE Guide system
Figure 14: Menubar metacomponent
Figure 15: Metacomponents evolution
Figure 16: Event listening in J2SE and MIDlet application
Figure 17: X-framework for the J2ME City Guide System
Figure 18: Portable event handling metacomponent
Figure 19: MobileGuideService metacomponent
Figure 20: X-framework for the whole City Guide system product line
Figure 21: An SPC for City Guide system on P800
Figure 22: Runtime architecture (a) and running result (b) of the City Guide system on P800
Figure 23: An SPC for City Guide system on Pocket PC
Figure 24: Toolbar metacomponent
Figure 25: A use case metacomponent
Figure 26: A use case model without BookMark
Figure 27: LOC for our case study

Chapter VII: UML- and XML-Based Change Process and Data Model Definition for Product Evolution

Figure 1: Example of some key electronic/Telematic functions in a car
Figure 2: DIECoM evolution life cycle
Figure 3: IT infrastructure
Figure 4: DIECoM deployment platform
Figure 5: Organization of the DIECoM business process
Figure 6: Statechart of change process
Figure 7: Activity diagram of change change control process
Figure 8: Design executable business processes in UML
Figure 9: An example of enterprise metadata model
Figure 10: From class diagram to XML implementation
Figure 11: Part of XML DTD tree for Figure 9
Figure 12: On-board configuration model
Figure 13: Product structure
Figure 14: Updated product structure
Figure 15: On-board configuration change
Figure 16: The dynamic updating process

Chapter VIII: Rapid Pattern-Oriented Scenario-Based Testing for Embedded Systems

Figure 1: Test process for agile development
Figure 2: Decomposition of scenario specification
Figure 3: Scenario specification language
Figure 4: Basic scenario pattern
Figure 5: Basic verification pattern
Figure 6: Verification state machine
Figure 7: Key-event driven scenario pattern
Figure 8: Key-event driven verification pattern
Figure 9: Verification state machine
Figure 10: Timed key-event driven scenario pattern
Figure 11: Timed key-event driven verification pattern
Figure 12: Verification state machine
Figure 13: Key-event driven time-sliced scenario pattern
Figure 14: Key-event driven time-sliced verification pattern
Figure 15: Verification state machine
Figure 16: Command-response scenario pattern
Figure 17: Command-response verification pattern
Figure 18: Verification state machine
Figure 19: Look-back scenario pattern
Figure 20: Look-back verification pattern
Figure 21: Verification state machine
Figure 22: Mode-switch scenario pattern
Figure 23: Mode-switch scenario pattern
Figure 24: Verification state machine
Figure 25: Interleave scenario pattern
Figure 26: Interleave verification pattern
Figure 27: Interleave verification pattern
Figure 28: Negative scenario pattern
Figure 29: Robustness pattern for negative key-event driven scenario pattern
Figure 30: Scenario specification
Figure 31: Description and illustration of Basic scenario pattern
Figure 32: Code templates for Basic scenario pattern and verification pattern
Figure 33: Effort savings due to application of verification patterns

Chapter IX: Developing a Software Testing Ontology in UML for a Software Growth Environment of Web-Based Applications

Figure 1: The growth model of software life cycle
Figure 2: Architecture of software growth environment
Figure 3: Structure of the prototype system for testing Web-based applications
Figure 4: Basic concepts of software testing
Figure 5: The concept of testers
Figure 6: The concept of test context
Figure 7: The concept of test activity
Figure 8: The concept of test method
Figure 9: The concept of artefact
Figure 10: The concept of test environment
Figure 11: The compound concept of capability
Figure 12: The compound concept of task
Figure 13: Basic relations on testing concepts
Figure 14: Compound relations
Figure 15: Message structure

Chapter X: Abstracting UML Behavior Diagrams for Verification

Figure 1: Our abstraction approach
Figure 2: The STATEMATE ModelCertifier package
Figure 3: Class diagram for a CD player
Figure 4: State machines for CD_PLAYER and CD_DEVICE
Figure 5: Lattice COUNTER
Figure 6: The abstract increment by one function
Figure 7: FORWARD actions for the (a) original and (b) abstract versions
Figure 8: The abstract less than function
Figure 9: Abstract state machine for the CD_PLAYER
Figure 10: MOF metadata architecture
Figure 11: An XSLT 2.0 stylesheet example
Figure 12: A simple transformation using XMI. difference
Figure 13: The extended abstraction engine API
Figure 14: Part of the JMI-based code for XMI abstraction
Figure 15: Sequence diagrams for an erroneous behavior: (a) original, (b) abstract version

Chapter XI: Support for Architectural Design and Re-Design of Embedded Systems

Figure 1: Overall structure of the high-level simulator HL Perses
Figure 2: The basic architectural design methodology (ψ-chart approach) illustrated by means of an UML Activity Diagram. Here, one single feedback path to the Software Application Characterization is shown, but also the execution environment can be possibly reworked out.
Figure 3: The architectural design process envisioned by an UML activity diagram. In this scheme is shown a feedback path to the Refinement & Tuning Process, but the designer may choose to re-operate on other activities. No more reworking iterations are needed after the achievement of the desired results.
Figure 4: Example of the description of a hardware platform (including four CPUs) through an XML file, as rendered by a popular XML browser. Some of the document elements are shown in the collapsed format.
Figure 5: Example of an XML DTD for a Platform Description Document (shown in a user-friendly format by an XML browser)
Figure 6: An overall view of the functionality of a digital cartographic system, expressed by means of a use-case UML diagram
Figure 7: High-level behavioral description of the cartographic software by means of UML statechart diagrams. It is worth pointing out that the cyclic GPS activity for position calculation is always carried out, independent of the other activities.
Figure 8: High-level behavioral description of the activities within the map-displaying task. The map redrawing is exercised repeatedly, and its most time-consuming activity is the picture composition, whose implementation affects the user-perceived performance of the whole system.
Figure 9: Simulated redraw time for different software architectures. The diagram on the left shows the timings relative to a map of average complexity. The diagram on the right reports the predicted speedups for architecture DL, with an increasing number of CPUs.

Chapter XII: Describing and Extending Classes with XMI—An Industrial Experience

Figure 1: The same service can be exploited (a) as an EJB or(b) as an RMI service
Figure 2: The evolution of classes via XML, XMI, and MOF
Figure 3: The process applied to Java classes and EJB/RMI architecture
Figure 4: Parallel mapping which defines XMI
Figure 5: Definition of the Remote Proxy
Figure 6: Use of UML and Remote Proxy metamodels
Figure 7: The interface of the application
Figure 8: The backbone of UML Core package
Figure 9: Metamodel that describes the Remote Proxy
Figure 10: Enumerations introduced in the extended metamodel


List of Tables

Chapter I: A Framework for Managing Consistency of Evolving UML Models

Table 1: Two-dimensional inconsistency table
Table 2: Summary of UML profile for model evolution

Chapter II: Deriving Safety-Related Scenarios to Support Architecture Evaluation

Table 1: The entries of SFMEA
Table 2: The safety factors
Table 3: The impact levels of the overall safety factors
Table 4: The resulting module view SFMEA table of the insulin delivery system
Table 5: The derived misuse scenarios

Chapter V: On the Co-Evolution of SSADM and the UML

Table 1: An example of a data access path
Table 2: An example of a valid data access path

Chapter VII: UML- and XML-Based Change Process and Data Model Definition for Product Evolution

Table 1: Relationship between UML diagrams and XPDL concepts
Table 2: Activity diagram elements mapping to XPDL

Chapter VIII: Rapid Pattern-Oriented Scenario-Based Testing for Embedded Systems

Table 1: Derived scenarios from the system requirement
Table 2: Identified events, conditions and actions
Table 3: Timing specification — Constraints
Table 4: Missing scenarios (for normal situations)
Table 5: Missing scenarios (for abnormal/exceptions)
Table 6: Iteration of completeness analysis
Table 7: Completeness analysis
Table 8: Scenario patterns and percentages
Table 9: Scenario patterns and percentages
Table 10: Combination of elements in premise
Table 11: Robust scenario patterns
Table 12: Missing intended scenarios
Table 13: Missing negative scenarios
Table 14: Examples of basic pattern
Table 15: Case study
Table 16: Verification framework effectiveness
Table 17: LTL formula for the scenario patterns

Chapter IX: Developing a Software Testing Ontology in UML for a Software Growth Environment of Web-Based Applications

Table 1: Laws of evolution of e-type systems

Chapter XI: Support for Architectural Design and Re-Design of Embedded Systems

Table 1: Possible parallel solutions for behavioral models of the target cartographic system


List of Definitions

Chapter IV: Towards the Integration of a Formal Object-Oriented Method and Relational Unified Process

Definition 1
Definition 1
Definition 2
Definition 3
Definition 4
Definition 5

Chapter VIII: Rapid Pattern-Oriented Scenario-Based Testing for Embedded Systems

Definition 8.1
Definition 8.2
Definition 8.3
Definition 8.4
Definition 8.5
Definition 8.6

Chapter IX: Developing a Software Testing Ontology in UML for a Software Growth Environment of Web-Based Applications

Example 9.1
Example 9.2
Example 9.3
Theorem 9.1: (Reflexiveness)
Theorem 9.2: (Transitiveness)
Theorem 9.3: (Reflexiveness)
Theorem 9.4: (Transitiveness)
Theorem 9.5
Theorem 9.6
Example 9.4

Team LiB
Previous Section