Advances in Computers, Volume 54: Trends in Software Engineering

Advances in COMPUTERS VOLUME 54 This Page Intentionally Left Blank Advances in COMPUT RS Trends in Software Engin...

Author: Marvin Zelkowitz

65 downloads 1186 Views 15MB Size Report

This content was uploaded by our users and we assume good faith they have the permission to share this book. If you own the copyright to this book and it is wrongfully on our website, we offer a simple DMCA procedure to remove your content from our site. Start by pressing the button below!
Report copyright / DMCA form

DOWNLOAD PDF

Advances

in COMPUTERS VOLUME 54

This Page Intentionally Left Blank

Advances in

COMPUT RS Trends in Software Engineering EDITED B Y

M A R V I N V. ZELKOWITZ Department of Computer Science and Institute for Advanced Computer Studies University of Maryland College Park, Maryland

V O L U M E 54

ACADEMIC PRESS A Harcourt Science and Technology Company

San Diego

San Francisco

London Sydney Tokyo

New York

Boston

This book is printed on acid-flee paper. Copyright ~ 2001 by ACADEMIC PRESS All Rights Reserved. No part of this publication may be reproduced or transmitted in any form or by any means, electronic or mechanical, including photocopying, recording, or any information storage and retrieval system, without permission in writing from the publisher. The appearance of the code at the bottom of the first page of a chapter in this book indicates the Publisher's consent that copies of the chapter may be made for personal or internal use of specific clients. This consent is given on the condition, however, that the copier pay the stated per copy fee through the Copyright Clearance Center, Inc. (222 Rosewood Drive, Danvers, Massachusetts 01923), for copying beyond that permitted by Sections 107 or 108 of the U.S. Copyright Law. This consent does not extend to other kinds of copying, such as copying for general distribution, for advertising or promotional purposes, for creating new collective works, or for resale. Copy fees for pre-2000 chapters are as shown on the title pages. If no fee code appears on the title page, the copy fee is the same as for current chapters./00 $35.00 Explicit permission from Academic Press is not required to reproduce a maximum of two figures or tables from an Academic Press chapter in another scientific or research publication provided that the material has not been credited to another source and that full credit to the Academic Press chapter is given. Academic Press A Harcourt Science and Technology Company 525 B Street, Suite 1900, San Diego, California 92101-4495, USA http://www.academicpress.com Academic Press A Harcourt Science and Technology Company Harcourt Place, 32 Jamestown Road, London NW1 7BY, UK http://www.academicpress.com International Standard Book Number 0-12-012154-9 Typeset by Mathematical Composition Setters Ltd, Salisbury, UK Printed in Great Britain by MPG Books Ltd, Bodmin, UK 01 02 03 04 05 06 MP 9 8 7 6 5 4 3 2 1

Contents CONTRIBUTORS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . PREFACE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

ix xiii

An Overview of Components and Component-Based Development Alan W. Brown 1. 2. 3. 4. 5. 6. 7. 8.

Introduction ...................................... The Goals of Component Approaches .................... Why Component-Based Development? .................... W h a t is a C o m p o n e n t ? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . W h a t is the E x e c u t i o n E n v i r o n m e n t for C o m p o n e n t s ? . . . . . . . . . H o w are A p p l i c a t i o n s A s s e m b l e d u s i n g C B D ? . . . . . . . . . . . . . . W h a t is the C u r r e n t P r a c t i c e in C B D T o d a y ? . . . . . . . . . . . . . . . Summary ......................................... References ........................................

2 3 3 5 13 20 24 32 33

Working with UML: A Software Design Process Based on Inspections for the Unified Modeling Language Guilherme H. Travassos, Forrest Shull, and Jeffrey Carver 1. 2. 3. 4. 5. 6.

Introduction ...................................... The Unified Modeling Language (UML) .................. Software Process Activities . . . . . . . . . . . . . . . . . . . . . . . . . . . . The Example ...................................... Maintenance or Evolution ............................. The Road Ahead ................................... References ........................................

36 40 43 64 86 94 95

Enterprise JavaBeans and Microsoft Transaction Server: Frameworks for Distributed Enterprise Components Avraham Left, John Prokopek, James T. Rayfield, and Ignacio Silva-Lepe 1. 2. 3. 4. 5. 6.

Introduction ...................................... Component Evolution ............................... Object Transaction Monitors ........................... Enterprise JavaBeans and Microsoft Transaction Server ....... Parallel Evolution .................................. Sample Application ................................. V

100

101 114 120 128 136

vi

CONTENTS

7. C o n t i n u e d E v o l u t i o n . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8. C o n c l u s i o n . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . References ........................................

142 147

151

Maintenance Process and Product Evaluation Using Reliability, Risk, and Test Metrics Norman F. Schneidewind 1. 2. 3. 4. 5. 6. 7. 8.

Introduction ...................................... Related Research and Projects ......................... Concept of Stability ................................ M e t r i c s for L o n g - T e r m A n a l y s i s . . . . . . . . . . . . . . . . . . . . . . . M e t r i c s for L o n g - T e r m a n d S h o r t - T e r m A n a l y s i s . . . . . . . . . . . Data and Example Application ........................ Relationships among Maintenance, Reliability, and Test Effort Shuttle Operational Increment Functionality and Process Improvement ..................................... 9. U n i t e d S t a t e s A i r F o r c e G l o b a l A w a r e n e s s ( G A ) P r o g r a m Application ...................................... 10. C o n c l u s i o n s . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Acknowledgments .................................. References .......................................

.

154 155 157 160 160 160 163 175 177 180 180 180

Computer Technology Changes and Purchasing Strategies Gerald V. Post 1. 2. 3. 4. 5. 6. 7. 8. 9.

Introduction ...................................... Moore's Law: The Beginning .......................... M a i n f r a m e s to P e r s o n a l C o m p u t e r s : P r i c e / P e r f o r m a n c e Personal Computers ................................. Laptops .......................................... Centralization, Decentralization, and TCO ................. Demand ......................................... The Future ....................................... Conclusions ....................................... References ........................................

.......

184 185 187 191 202 205 206 208 210 211

Secure Outsourcing of Scientific Computations Mikhail J. Atallah, K.N. Pantazopoulos, John R. Rice, and Eugene Spafford 1. I n t r o d u c t i o n . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2. G e n e r a l F r a m e w o r k . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3. A p p l i c a t i o n s . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4. S e c u r i t y A n a l y s i s . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

216 223 236 247

CONTENTS

vii

5. C o s t A n a l y s i s . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6. C o n c l u s i o n s . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . References ........................................

265 268 270

AUTHOR INDEX ......................................

273

SUBJECT I N D E X . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

279

C O N T E N T S OF V O L U M E S IN T H I S SERIES . . . . . . . . . . . . . . . . . . . .

287


Contributors Mikhail J. Atallah received a BE degree in electrical engineering from the American University, Beirut, Lebanon, in 1975, and MS and PhD degrees in electrical engineering and computer science from Johns Hopkins University, Baltimore, Maryland, in 1980 and 1982, respectively. In 1982, Dr. Atallah joined the Purdue University faculty in West Lafayette, Indiana, where he is currently a professor in the computer science department. In 1985, he received an NSF Presidential Young Investigator Award from the US National Science Foundation. His research interests are information security and algorithms (in particular for geometric and parallel computation). Dr. Atallah is a fellow of the IEEE, and serves or has served on the editorial boards of SIAM Journal o17 Computing, Journal of Parallel and

Distributed Computing, hzformation Processing Letters, Computational Geometry: Theory Applications, hTternational Journal of Computational Geometry Applications, Parallel Processing Letters, Methods of Logic in Computer Science. He was Guest Editor for a Special Issue of Algorithmica on Computational Geometry, has served as Editor of the Handbook of Parallel and Distributed Computing (McGraw-Hill), as Editorial Advisor for the Handbook of Computer Science and Engineering (CRC Press), and as Editor for the Handbook of Algorithms and Theory of Computation (CRC Press). Alan W. Brown, PhD is a Senior Technical evangelist at Catapulse, Inc., a Silicon Valley start-up company leveraging the Internet to create a new generation of software development services and tools. Previously Alan was vice president of R&D for Computer Associates' Application Development products where he was responsible for advanced technology activities across the organization. Alan joined Computer Associates on their acquisition of Sterling Software in April 2000. Prior to joining Sterling Software, he was director of software research for Texas Instruments Software (TIS), which was acquired by Sterling Software in 1997. Alan also led the Object Technology Branch for Texas Instruments, Inc.'s corporate software research labs in its investigation of advanced research and development products. Previously Alan spent five years at the Software Engineering Institute (SEI) at Carnegie Mellon University in Pittsburgh, Pennsylvania. There he led the CASE environments project advising on a variety of US government agencies and contractors on the application and integration of CASE technologies.

ix

X

CONTRIBUTORS

Jeff Carver is a graduate research assistant in the Experimental Software Engineering Group at the University of Maryland. He received his BS in Computer Science from Louisiana State University. He is currently pursuing a PhD degree. His research interests include software inspections, reading techniques, and process improvement. Avraham Left has been a Research Staff Member in the Intelligent Object Technology group at IBM since 1991. His research interests include distributed components and distributed application development. He received a BA in Computer Science and Mathematical Statistics from Columbia University in 1984, and an MS and PhD in Computer Science from Columbia University in 1985 and 1992, respectively. Dr. Left has been issued two patents, and has five patents pending. Konstantinos N. Pantazopoulos received a BE degree in computer and informatics engineering from The University of Patras, School of Engineering, Patras, Greece, in 1991 and MS and PhD degrees in Computational Science from Purdue University, West Lafayette, Indiana, in 1995 and 1998 respectively. In 1998 Dr. Pantazopoulos joined Goldman, Sachs Inc. in New York and later moved to London where he is currently in the Fixed Income Markets division. His research interests include numerical algorithms with applications in finance and information security. Gerald Post is a professor of Management Information Systems (MIS) at the University of the Pacific. He has a PhD from Iowa State University in international economics and statistics, and postdoctoral work in MIS at the University of Indiana. He has written textbooks on MIS and database management systems. He has published articles on decision-making, information technology, computer security, and statistical analysis. His research has appeared in leading journals such as MIS Quarterly,

Communications of the A CM, Journal of Marketing Research, Decision Sciences, Journal of MIS, and Information & Management. He buys his own computers so he has a vested interest in purchasing strategies. John Prokopek is a Senior Development Engineer at Instinet, a Reuters Company, providing Institutional and Retail Investment services. His areas of specialization include object-oriented and component technologies and Microsoft NT Technologies. He received a BS in Chemistry from Siena College, Loudonville, NY in 1980.

James T. Rayfield is a Research Staff Member and manager in the Intelligent Object Technology group. He joined IBM in 1989. His research interests include object-oriented transaction-processing systems and database systems. He received an ScB in 1983, an ScM in 1985, and a PhD in

CONTRIBUTORS

xi

1988, all in Electrical Engineering from Brown University. Dr. Rayfield has two patents issued and five patents pending. John R. Rice studied mathematics at the California Institute of Technology,

receiving his PhD in 1959. He came to Purdue University in 1964 as Professor of Mathematics and Computer Science. He was Head of Computer Sciences from 1983 through 1996 and in 1989 he was appointed W. Brooks Fortune Distinguished Professor of Computer Sciences. His early research work was mostly in mathematics (approximation theory) but over the years his research shifted to computer science and now he is working in the areas of parallel computation, scientific computing, problem solving environments, solving partial differential equations and computer security. His professional career includes terms as Chair of the ACM Special Interest Group on Numerical Mathematics (1970-73) and Chair of the Computing Research Association (1991-93). He was founder and Editorin-Chief of the A C M Transactions on Mathematical So[t~l'are (1975-1993). Professional honors include the 1975 Forsythe Distinguished Lectureship, Fellow of the AAAS, Fellow of the ACM, and election to the National Academy of Engineering. Norman F. Schneidewind is Professor of Information Sciences and Director

of the Software Metrics Research Center in the Division of Computer and Information Sciences and Operations at the Naval Postgraduate School, where he teaches and performs research in software engineering and computer networks. Dr. Schneidewind is a Fellow of the IEEE, elected in 1992 for "contributions to software measurement models in reliability and metrics, and for leadership in advancing the field of software maintenance." He is the developer of the Schneidewind software reliability model that is used by NASA to assist in the prediction of software reliability of the Space Shuttle, by the Naval Surface Warfare Center for Trident software reliability prediction, and by the Marine Corps Tactical Systems Support Activity for distributed system software reliability assessment and prediction. This model is one of the models recommended by the American National Standards Institute and the American Institute of Aeronautics and Astronautics Recommended Practice for Software Reliability. He has published widely in the fields of software reliability and metrics. Forrest Shull is a scientist at the Fraunhofer Center for Experimental

Software Engineering, Maryland. He received his doctorate degree from the University of Maryland, College Park, in 1998. His current research interests include empirical software engineering, software reading techniques, software inspections, and process improvement. Contact him at fshull@ fc-md.umd.edu.

xii

CONTRIBUTORS

Ignacio Silva-Lepe is a Research Staff Member in the Enterprise Middleware Group. He joined IBM in 1997. His research interests include distributed component middleware, message-oriented middleware, and networked virtual environment servers. He received a BS in Computer Systems Engineering from Universidad ITESO, Guadalajara, Mexico in 1985, and an MS and PhD in Computer Science from Northeastern University, Boston, Massachusetts in 1989 and 1994, respectively. Dr. Silva-Lepe has one patent pending.

Gene Spafford's current research interests are focused on issues of computer and network security, computer crime and ethics, and the social impact of computing. Spaf's involvement in information security led, in May of 1998, to Purdue University establishing the Center for Education and Research in Information Assurance and Security with Dr. Spafford as its first Director. This university-wide center addresses the broader issues of information security and information assurance, and draws on expertise and research across all of the academic disciplines at Purdue. Among many professional activities, Dr. Spafford is a member of the Computing Research Association's Board of Directors, the US Air Force's Science Advisory Board, and he is chair of ACM's US Public Policy Committee. In 1996, he was named a charter recipient of the Computer Society's Golden Core, for his past service to the Society, in 1997 he was named as a Fellow of the ACM, and in 1999 he was named as a Fellow of the AAAS. Dr. Spafford is the Academic Editor of the journal Computers & Security, and on the editorial and advisory boards of the Journal of Artificial Life, ACM's Transactions on Information and System SecuriO', and Network Security. Guilherme H. Travassos is an Associate Professor of Computer Science at the COPPE-Federal University of Rio de Janeiro, Brazil. He received his doctorate degree from the C O P P E / U F R J in 1994. His current research interests include empirical software engineering, software quality, software engineering environments, and process improvement. He is a former faculty researcher in the Experimental Software Engineering Group at the Department of Computer Science, University of Maryland from 1998 until 2000. Contact him at ght@,cos.ufrj.br.

Preface

As we enter the 21st century, the Advances in Computers remains at the forefront in presenting the new developments in the ever-changing field of information technology. Since 1960, the Advances has chronicled the constantly shifting theories and methods of this technology that greatly shapes our lives today. In this 54th volume in this series, we present six chapters on the changing face of software engineering--the process by which we build reliable software systems. We are constantly building faster and less expensive processors, which allow us to use different processes to try and conquer the "bug" problem facing all developments--how to build reliable systems with few errors at low or at least manageable cost. The first three chapters emphasize components and the impact that object oriented design is having on the program development process. The final three chapters present other aspects of the software development process. In the first chapter, "An overview of components and component-based development," Alan W. Brown describes the virtues of building systems using a component-based development strategy. The goal is to reuse existing software artifacts without the need to rebuild them, by building them initially within a common infrastructure framework. The chapter discusses various approaches toward these framework infrastructures. In Chapter 2, "Working with UME: A software design process based on inspections for the Unified Modeling Language," the authors Guilherme Travassos, Forrest Shull, and Jeffrey Carver build upon the ideas in the first chapter. The Unified Modeling Eanguage (UML) has been proposed as a notation for building object oriented (OO) systems. OO design is one of the approaches that allow one to effectively build the reusable components referred to in the first chapter. In this chapter, the authors discuss ways to ensure that the UML description of a new product is both correct and easily implementable. "Enterprise JavaBeans and Microsoft Transaction Server: Frameworks for distributed enterprise components" by Avraham Left, John Prokopek, James T. Rayfield, and Ignacio Silva-Lepe, the title of Chapter 3, is a specialization of the ideas in the first two chapters. This chapter examines a specific type of component, the distributed enterprise component, that provides business function across an enterprise. Distributed enterprise

xiii

xiv

PREFACE

components require special functions such as distribution, persistence, and transactions, which are achieved by deploying the components in an object transaction monitor. Recently, distributed enterprise components and object transaction monitor technology have standardized into two competing frameworks: Sun's Enterprise JavaBeans and Microsoft's Transaction Server. Maintaining a system is often half or more of the life-cycle costs of a large software system. In Chapter 4, "Maintenance process and product evaluation using reliability, risk, and test metrics" by Norman F. Schneidewind, the author discusses maintenance issues on the NASA Space Shuttle Program, a software system first used in 1981 and expected to evolve until at least 2020. Dr. Schneidewind has been investigating an important facet of process capability--stability--as defined and evaluated by trend, change, and shape metrics, across releases and within a release of a software product. Integration of product and process measurement serves the dual purpose of using metrics to assess and predict reliability and risk and to evaluate process stability. Although computers have gotten faster, and paradoxically much cheaper, over the past 30 years, they still represent a significant investment for most people. In Chapter 5, Gerald Post in "Computer technology changes and purchasing strategies" discusses various strategies for when and how to purchase a computer. Since machines are constantly getting both faster and cheaper, waiting for the next faster machine to replace an older machine will always be cost effective. However, since this improvement cycle does not seem to be changing, the result is to always wait and never replace an old slow machine. If in need of a new machine, then, when do you do the "non-cost effective" action of actually buying a machine? Dr. Post discusses various strategies depending upon the use of the new machine. In the final chapter, Mikhail J. Atallah, K.N. Pantazopoulos, John R. Rice, and Eugene E. Spafford in "Secure outsourcing of scientific computations," present a different approach to the computer replacement issue of the previous chapter. With machines being relatively inexpensive today, many of them are both connected to the Internet and also remain idle much of the time. That provides a rich source of computing power not being used. A customer needing computing services could "outsource" the problem to one of these idle machines. The problem that the authors address in this chapter is security. For security or proprietary business reasons, how can the customer use another machine to perform needed calculations without the owner of the donor machine knowing the true nature of the data being processed? (For a discussion of basic outsourcing concepts, see "Resource-aware meta-computing" by

PREFACE

xv

J. Hollingsworth, P. Keleher, and K. Ryu in Advances in Computers, volume 53, 2000.) I hope that you find these chapters of interest. If you would like to see a specific topic covered by these Advances, let me know at [email protected]. MARVIN V. ZELKOWITZ College Park, Maryland


An Overview of Components and Component-Based Development ALAN W. BROWN Rational Software 5 Results Way Cupertino, CA 95014 USA [email protected]

Abstract Components and component-based development are important technology advances in use by many organizations around the world. This chapter examines the main concepts and current practices involving these technologies. In particular, the chapter offers an analysis of the current state of componentbased development as practiced and supported in the software industry today.

1. 2. 3. 4.

5.

6.

7.

8.

Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . The Goals of C o m p o n e n t Approaches . . . . . . . . . . . . . . . . . . . . . . . W h y Component-Based Development? . . . . . . . . . . . . . . . . . . . . . . . What is a Component? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.1 Components and Objects . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.2 Components and Distributed Systems . . . . . . . . . . . . . . . . . . . . 4.3 Elements of a C o m p o n e n t . . . . . . . . . . . . . . . . . . . . . . . . . . W h a t is the Execution Environment for Components? . . . . . . . . . . . . . . . 5.1 C o m p o n e n t Infrastructure Services . . . . . . . . . . . . . . . . . . . . . . 5.2 Component Infrastructure Implementations . . . . . . . . . . . . . . . . . . H o w are Applications Assembled using CBD? . . . . . . . . . . . . . . . . . . . 6.1 Sources of Components . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.2 Interface-Focused Design . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.3 Applications and C o m p o n e n t Architecture . . . . . . . . . . . . . . . . . . W h a t is the Current Practice in C B D Today? . . . . . . . . . . . . . . . . . . . 7.1 Component Software Vendors . . . . . . . . . . . . . . . . . . . . . . . . 7.2 C o m p o n e n t Software Portals . . . . . . . . . . . . . . . . . . . . . . . . . 7.3 C o m p o n e n t Infrastructure Vendors . . . . . . . . . . . . . . . . . . . . . . Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

2 3 3 5 6 8 11 13 13 14 20 21 23 23 24 25 26 28 32 33

I This paper is a substantially extended version of Chapter 4 in A. W. Brown, Large-scale by Prentice-Hall in May 2000. It is provided here with permission of Prentice-Hall.

Component-BasedDevelopment published

ADVANCES IN COMPUTERS, VOL. 54 ISBN 0-12-012154-9

Copyright ~ 2001 by Academic Press All rights of reproduction in any form reserved.

2

ALAN W. BROWN 1.

Introduction

Complex situations in any walk of life are typically addressed by applying a number of key concepts. These are represented in approaches such as abstraction, decomposition, iteration, and refinement. They are the intellectual tools on which we rely to deal with difficult problems in a controlled, manageable way. Critical among them is the technique of decomposition--dividing a larger problem into smaller, manageable units, each of which can then be tackled separately. This technique is at the heart of a number of approaches to software engineering. The approaches may be called structured design, modular programming, or object orientation, and the units they produce called modules, packages, or components. However, in every case the main principle involved is to consider a larger system to be composed from welldefined, reusable units of functionality, introduce ways of managing this decomposition of a system into pieces, and enable its subsequent reconstruction into a cohesive system. While the concepts are well understood, most organizations struggle to apply these concepts to the provisioning of enterprise-scale solutions in the Internet age. However, driven by the challenges faced by software engineers today, many organizations are beginning to reassess their approach to the design, implementation, and evolution of software. This stems from growing pressure to assemble solutions quickly from existing systems, make greater use of third-party solutions, and develop reusable services for greater flexibility. Consequently, renewed attention is being given to reuse-oriented, component-based approaches. This in turn is leading to new componentbased strategies being defined, supported by appropriate tools and techniques. The collective name for these new approaches is componentbased development (CBD) or component-based software engineering (CBSE). For developers and users of software-intensive systems, CBD is viewed as a way to reduce development costs, improve productivity, and provide controlled system upgrade in the face of rapid technology evolution [1,2]. In this chapter we examine the renewed interest in reuse-oriented approaches, and define the goals and objectives for any application development approach able to meet the needs of today's software development organizations. Armed with this knowledge, we examine the major principles of CBD, and the characteristics that make CBD so essential to software developers and tool producers alike. We then consider the major elements of any CBD approach, and highlight the main concepts behind them. Finally, we assess the current state of CBD as practiced today.

COMPONENTS AND COMPONENT-BASED DEVELOPMENT

3

2. The Goals of Component Approaches Recently there has been renewed interest in the notion of software development through the planned integration of pre-existing pieces of software. This is most often called component-based development (CBD), component-based software engineering (CBSE), or simply componentware, and the pieces called components. There are many on-going debates and disagreements concerning what exactly are and are not components [3]. Some authors like to emphasize components as conceptually coherent packages of useful behavior. Others concentrate on components as physical, deployable units of software that execute within some well-defined environment [4]. Regardless of these differences, the basic approach of CBD is to build systems from welldefined, independently produced pieces. However, the interesting aspects of CBD concern how this approach is realized to allow components to be developed as appropriate cohesive units of functionality, and to facilitate the design and assembly of systems from a mix of newly and previously developed components. The goal of building systems from well-defined pieces is nothing new. The interest in CBD is based on a long history of work in modular systems, structured design, and most recently in object oriented systems [5-9]. These were aimed at encouraging large systems to be developed and maintained more easily using a "divide and conquer" approach. CBD extends these ideas, emphasizing the design of solutions in terms of pieces of functionality provisioned as components, accessible to others only through well-defined interfaces, outsourcing of the implementation of many pieces of the application solution, and focusing on controlled assembly of components using interface-based design techniques. Most importantly, these concepts have been supported by a range of products implementing open standards that offer an infrastructure of services for the creation, assembly, and execution of components. Consequently, the application development process has been re-engineered such that software construction is achieved largely through a component selection, evaluation, and assembly process. The components are acquired from a diverse set of sources, and used together with locally developed software to construct a complete application [10].

3. Why Component-Based Development? Many challenges face software developers today to provision enterprisescale solutions. By reviewing and distilling the challenges being faced, we

4

ALAN W. BROWN

obtain the following goals and objectives for enterprise-scale solutions in the Internet age: 9 Contain complexity. In any complex situation there are a few basic techniques that can be used to understand and manage that complexity. These are the techniques of abstraction, decomposition, and incremental development. Any solution to application development must provide ways to support these techniques. 9 Reduce deliver), time. The ability to deliver solutions in a timely manner is an essential aspect of any software development project. With the increased rate of change of technology, this aspect is even more critical. This need for reduced delivery time for software-intensive systems is often referred to as working at "Internet speed." 9 Improve consistency. Most software-intensive systems share significant characteristics with others previously developed, in production, or yet to be produced. It must be possible to take advantage of this commonality to improve consistency and reduce development expense. 9 Make use of best-in-class. In a number of areas there are well-developed solutions offering robust, best-in-class functionality and performance. Taking advantage of these solutions as part of a larger development effort is essential. 9 Increase productiviO'. The shortage of software development skills is causing a major backlog for systems users. Any new approaches must improve the productivity of skilled employees to allow them to produce quality results at a faster rate. 9 Improve quality. As the economic and human impact of failure of software-intensive systems increases, greater attention must be turned to the quality of the deployed systems. A goal must be to support the building of systems correctly the first time, without extensive (and expensive) testing and rewriting. 9 Increase visibility into project progress. Managing large software projects is a high-risk undertaking. To help this, greater visibility must be possible throughout the software life-cycle. This requires an incremental approach to development, delivery, and testing of software artifacts. 9 Support parallel and distributed development. Distributed development teams require approaches that encourage and enable parallel development of systems. This requires specific attention to be given to manage complexity due to the need to partition and resynchronize results. 9 Reduce maintenance costs. The majority of software costs occur after initial deployment. To reduce maintenance costs it must be possible to


5

more easily identify the need for change, scope the impact of any proposed change, and implement that change with predictable impact on the rest of the system. This list represents a daunting set of challenges for any approach. Yet it is components and component-based approaches that offer the most promising attempt to meet the challenges head-on, and provide the basis of a new set of techniques supporting the next generation of software-intensive solutions.

4.

W h a t is a C o m p o n e n t ?

The key to understanding CBD is to gain a deeper appreciation of what is meant by a component, and how components form the basic building blocks of a solution. The definition of what it means to be a component is the basis for much of what can be achieved using CBD, and in particular provides the distinguishing characteristics between CBD and other reuse-oriented efforts of the past. For CBD a component is much more than a subroutine in a modular programming approach, an object or class in an object oriented system, or a package in a system model. In CBD the notion of a component both subsumes and expands on those ideas. A component is used as the basis for design, implementation, and maintenance of component-based systems. For now we will assume a rather broad, general notion of a component, and define a component as:

An independently deliverable piece of functionali O, providing access to its services through interfaces. This definition, while informal, stresses a number of important aspects of a component. First, it defines a component as a deliverable unit. Hence, it has characteristics of an executable package of software. Second, it says a component provides some useful functionality that has been collected together to satisfy some need. It has been designed to offer that functionality based on some design criteria. Third, a component offers services through interfaces. To use the component requires making requests through those interfaces, not by accessing the internal implementation details of the component. Of course, this definition is rather informal, and provides little more than an intuitive understanding of components and their characteristics. It is in line with other definitions of a component [11, 12], and is sufficient to allow us to begin a more detailed investigation into components and their use.

6

ALAN W. BROWN

However, it is not sufficient for in-depth analysis of component-approaches when comparing different design and implementation approaches. Consequently, more formal definitions of a component are provided elsewhere [ 10, 13, 14]. To gain greater insight into components and component-based approaches, it is necessary to explore a number of topics in some detail. In particular, it is necessary to look at components and their use of object oriented concepts, and view components from the perspective of distributed systems design. Based on such an understanding, the main component elements can then be highlighted.

4.1

Components and Objects 2

In discussions on components and component-based approaches there is much debate about components in relation to the concept of objects and object oriented approaches. Examining the relationship between objects and components provides an excellent starting point for understanding component approaches [13, 14]. For over 30 years there have been attempts to improve the design of programming languages to create a closer, more natural connection between the business-oriented concepts in which problems are expressed, and the technology-oriented concepts in which solutions are described as a set of programming language statements. In the past decade these attempts have led to a set of principles for software structure and behavior that have come to be called object oriented programming languages (OOPLs). There are many variations in OOPLs. However, as illustrated in Fig. 1, there are a number of concepts that have come to characterize OOPLs [15]. The commonly identified principles of object orientation are: 9 Objects: A software object is a way of representing in software an idea, a thing, or an event according to a chosen set of principles, these principles being the following five. 9 Encapsulation: A software object provides a set of services and manipulates data within the object. The details of the internal operation and data structures are not revealed to clients of the object. 9 Identity: Every object has a fixed, unique ~'tag" by which it can be accessed by other parts of the software. This tag, often called an object identifier, provides a way to uniquely distinguish that object from others with the same behavior. 2This discussion components [13].

is based

on John

Daniels" excellent short

paper

on objects and


7

FIG. 1. Basic concepts of object-oriented approaches.

9 Implementation: An implementation defines how an object works. It defines the structure of data held by the object and holds the code of the operations. In object oriented languages the most common form of implementation is the class. It is possible for an implementation to be shared by many objects. 9 Interface: An interface is a declaration of the services made available by the object. It represents a contract between an object and any potential clients. The client code can rely only on what is defined in the interface. Many objects may provide the same interface, and each object can provide many interfaces. 9 Substitutability: Because a client of the object relies on the interface and not the implementation, it is often possible to substitute other object implementations at run-time. This concept allows late, or dynamic binding between objects, a powerful feature for many interactive systems. For the last decade, object oriented principles have been applied to other fields, notably databases and design methods. More recently they have been used as the basis for a number of advances in distributed computing as an approach to support the integration of the various pieces of a distributed application. Based on this analysis, a component can be seen as a convenient way to package object implementations, and to make them available for assembly into a larger software system. As illustrated in Fig. 2, from this perspective a component is a collection of one or more object implementations within the context of a component model. This component model defines a set of

8

ALAN W. BROWN

FIG. 2. The relationship between components and objects.

rules that must be followed by the component to make those object implementations accessible to others. Furthermore, it describes a set of standard services that can be assumed by components and assemblers of component-based systems (e.g., for naming of components and their operations, security of access to those operations, transaction management, and so on). Organizations can define their own component models based on the needs of their customers and the tools they use to create and manipulate components (e.g., Computer Associates' proprietary CS/3.0 standard for components developed using the COOL:Gen product). Alternatively, a number of more widely used component model standards is now available, notably the Enterprise JavaBeans (EJB) standards from Sun Microsystems, and the C O M + standard from Microsoft. In summary, we see that in comparing components to objects, a component is distinguished by three main characteristics" 9 A component acts as a unit of deployment based on a component model defining the rules for components conforming to that model. 9 A component provides a packaging of one or more object implementations. 9 A component is a unit of assembly for designing and constructing a system from a number of independently created pieces of functionality, each potentially created using an OOPL or some other technology.

4.2 Components and Distributed Systems The 1980s saw the arrival of cheap, powerful hardware together with increasingly sophisticated and pervasive network technologies. The result was a move toward greater decentralization of computer infrastructures in most organizations. As those organizations built complex networks of


9

distributed systems, there was a growing need for development languages and approaches that supported these kinds of infrastructures. A wide range of approaches to application systems development emerged. One way to classify these approaches is based on the programming level that must be used to create distributed systems, and the abstract level of transparency that this supported. This is illustrated in Fig. 3. Initial approaches to building distributed systems were aimed at providing some level of hardware transparency for developers of distributed systems. This was based on technologies such as remote procedure calls (RPC) and use of message oriented middleware (MOM). These allow interprocess communication across machines independent of the programming languages used at each end. However, using RPCs still required developers to implement many services uniquely for each application. Other than some high-performance real-time systems, this expense is unnecessary. As a result, to improve the usability of these approaches a technique was required to define the services made available at each end of the RPC. To allow this, the concepts of object orientation were introduced as described above. By applying these concepts, application developers were able to treat remote processes as a set of software objects. The independent service providers can then be implemented as components. They are structured to offer those services through interfaces, encapsulating the implementation details that lie behind them. These service providers have unique identifiers, and can be substituted for others supporting the same interfaces. Such distributed object technologies are in widespread use today. They include Microsoft's Distributed

FIG. 3. Different levels of transparency for distributed systems.

10

ALAN W. BROWN

Component Object Model (DCOM) and the Object Management Group's Common Object Request Broker Architecture (CORBA). This approach resulted in the concept of an Interface Definition Language (IDL). The IDL provides a programming language neutral way to describe the services at each end of a distributed interaction. It provides a large measure of platform independence to distributed systems developers. The services are typically constructed as components defined by their interfaces. The interfaces provide remote access to these capabilities without the need to understand many of the details of how those services are implemented. Many distributed computing technologies use this approach. However, many implementations supporting an IDL were not transportable across multiple infrastructures from different vendors. Each middleware technology supported the IDL in its own way, often with unique valueadded services. To provide a middleware transparency for applications, bridging technologies and protocols have been devised (e.g., the Internet Inter-Orb Protocol (IIOP)). These allow components greater independence of middleware on which they are implemented. Of course, what most people want is to assemble solutions composed of multiple components--independently deliverable pieces of system functionality. These components interact to implement some set of business transactions. Ideally, developers would like to describe the services offered by components, and implement them independently of how those services will be combined later on. Then, when assembled into applications for deployment to a particular infrastructure, the services can be assigned appropriate characteristics in terms of transactional behavior, persistent data management, security, and so on. This level of service transparency requires the services to be implemented independently of the characteristics of the execution environment. Application servers based on the C O M + and EJB specifications support this approach. These standards define the behavior a component implementer can rely upon from the "container" in which it executes. When being deployed to a container, the application assembler is able to describe the particular execution semantics required. These can change from one container to another without impact on the component's internal logic, providing a great deal of flexibility for upgrade of component-based solutions. Finally, in many domains it is possible to imagine common sets of services that would frequently be found in many applications within that domain. For example, in areas such as banking and financial management it is possible to construct a common list of services for managing accounts, transfer of funds between accounts, and so on. This is the goal of application transparency. Groups of experts in an industry domain have


11

attempted to define common services in the form of a library, or interacting framework of components and services. As a result, application designers and implementers in that domain can use a pre-populated set of components when designing new application behavior. This increases the productivity of developers, and improves the consistency of the applications being produced. In summary, from the perspective of distributed systems, components provide a key abstraction for the design and development of flexible solutions. They enable designers to focus on business level concerns independently of the lower-level component implementation details. They represent the latest ideas of over two decades of distributed systems thinking.

4.3

Elements of a Component

As a result of these analyses, the elements of a component can now be discussed. Building on object oriented concepts and distributed systems thinking, components and component-based approaches share a number of characteristics familiar to today's systems designers and engineers. However, a number of additional characteristics must also be highlighted. These are shown in Fig. 4. As illustrated in Fig. 4, there are five major elements of a component: 9 A specification. Building on the interface concept, a component requires an abstract description of the services it offers to act as the

FIG.

4. What is a component?

12

ALAN W. BROWN

contract between clients and suppliers of the services. The component specification typically defines more than simply a list of available operations. It describes the expected behavior of the component for specific situations, constrains the allowable states of the component, and guides the clients in appropriate interactions with the component. In some cases these descriptions may be in some formal notation. Most often they are informally defined. 9 One or more implementations. The component must be supported by

one or more implementations. These must conform to the specification. However, the specification will allow a number of degrees of freedom on the internal operation of the component. In these cases the implementer may choose any implementation approach deemed to be suitable. The only constraint is on meeting the behavior defined in the specification. In many cases this flexibility includes the choice of programming language used to develop the component implementation. In fact, this behavior may simply be some existing system or packaged application wrapped in such a way that its behavior conforms to the specification defined within the context of the constraining component standard. 9 A constraining component standard. Software components exist within a

defined environment, or component model. A component model is a set of services that support the software, plus a set of rules that must be obeyed by the component in order for it to take advantages of the services. Established component models include Microsoft's C O M + , Sun's JavaBeans and Enterprise JavaBeans (EJB), and the OMG's emerging CORBA Component Standard. Each of these component models address issues such as how a component makes its services available to others, how components are named, and how new components and their services are discovered at run-time. Additionally, those component models concerned with enterprise-scale systems provide additional capabilities such as standard approaches to transaction management, persistence, and security. 9 A packaging approach. Components can be grouped in different ways

to provide a replaceable set of services. This grouping is called a package. Typically, it is these packages that are bought and sold when acquiring components from third-party sources. They represent units of functionality that must be installed on a system. To make this package usable, some sort of registration of the package within the component model is expected. In a Microsoft environment, for example, this is through a special catalog of installed components called the registry.

COMPONENTS AND COMPONENT-BASEDDEVELOPMENT

13

9 A deployment approach. Once the packaged components are installed in an operational environment, they will be deployed. This occurs by creating an executable instance of a component and allowing interactions with it to occur. Note that many instances of the component can be deployed. Each one is unique and executes within its own process. For example, it is possible to have two unique instances of an executing component on the same machine handling different kinds of user requests.

5.

W h a t is the Execution Environment for Components?

To support a component-based approach, it is common to use some form of component infrastructure (sometimes also called "component oriented middleware") to handle all of the complex details of component coordination [16]. Essentially, the component infrastructure provides a common set of component management services made available to all components interested in using that infrastructure. The component infrastructure imposes constraints on the design and implementation of the components. However, in return for abiding by these constraints, the component developer and application assembler is relieved from the burden of developing many complex services within their application. To understand component infrastructures, it is necessary to understand the kinds of services the infrastructure can make available, and the different competing infrastructure implementations currently available.

5.1

Component Infrastructure Services

The use of a component infrastructure arises as a result of a simple premise: the services common to many components should be extracted and provided once in a consistent way to all components. This provides greater control and flexibility over those common services, and allows component developers to concentrate on the specification and implementation of business aspects of the component. There are many kinds of services that the component infrastructure may offer. However, the component infrastructure is typically responsible for at least the following categories of services: 9 Packaging. When developing a component it is necessary to provide some description of that component in a form that is understandable to the component infrastructure. At a minimum the component

14

ALAN W. BROWN

infrastructure needs to know what services the component makes available, and the signatures of the methods which invoke those services. Requests for external component services must also be made in some standard form so that they can be recognized by the component infrastructure. 9 Distribution. The distribution services are responsible for activating and deactivating component instances, and for managing the allocation of component instances to remote host processes on which they execute. Once a client of a component service makes a request, the component infrastructure is responsible for routing that request to the appropriate component instance, which may involve activating a component instance to service the request. This provides location transparency between clients and servers of requests--the client does not need to know where the component instance servicing the request resides, and the component instance does not need to have knowledge of the origin of possible requests. 9 Security. In distributed systems there must be services for authenticating the source of requests and responses to requests, and for privacy of connections when information is transmitted. The component infrastructure may provide various levels of privacy to ensure secure, trusted connections between components can take place. 9 Transaction management. As each component may manage its own persistent data, a single high-level function may require many interactions among components affecting many individually managed pieces of data. As a result, partially completed functions have the potential for leaving this collection of data in an inconsistent state. Distributed transaction management is provided by the component infrastructure to manage and coordinate these complex component interactions. 9 Asynchronous communication. It is not always necessary or possible to communicate synchronously between components. Because components may be distributed across multiple host processes, there is always the possibility that some components will be unavailable to respond to requests. The component infrastructure supports asynchronous communication among components, typically through some form of queuing system for requests. 5.2

C o m p o n e n t Infrastructure

Implementations

In the world of component infrastructure technologies, a number of solutions are now in use. Currently, there are three dominant component


15

infrastructure choices possible: The Object Management Group's (OMG's) Object Management Architecture, Microsoft's distributed computing architecture, and Sun's Java-based distributed component technology. In each of these there is a vision for building enterprise-scale component-based applications supported by a set of standards and products. Here, we briefly review the main elements of these approaches.

5.2. 1 OMG's Object Management Architecture The need for a widely agreed component infrastructure led to the formation of the Object Management Group (OMG), a large consortium of over 900 companies attempting to come to agreement on an appropriate component model and services for building component-based distributed systems. The OMG is a large and complex organization, with many special interest groups, focus areas, and task forces. It attempts to provide standards for building component oriented applications, and encourages those standards to be followed by vendors of component infrastructure products and developers of component oriented applications. There are many OMG standards under development, a number of them currently being supported by products. OMG's vision for component-oriented applications is defined in its Object Management Architecture (OMA) [17]. This consists of a specification of the underlying distributed architecture for component communication providing the packaging services and some of the distribution services. The remaining component infrastructure services are developed to make use of those services. The main component infrastructure standard provided by OMG is the Common Object Request Broker Architecture (CORBA) [18]. This defines the basic distribution architecture for component oriented applications. There are three major aspects of CORBA: 9 The OMG's Interface Definition Language (IDL), which describes how business functionality is packaged for external access through interfaces. 9 The CORBA component model describing how components can make requests of each other's services. 9 The Internet Inter-ORB Protocol (IIOP), which allows different CORBA implementations to interoperate. Together with the CORBA standard, a set of additional capabilities is defined in the CORBA Services standards [19]. A wide range of services has been defined, or is currently under investigation. However, the following

16

ALAN W. BROWN

services are those that are most often found in currently available implementations: 9 Life-cycle services, which control the creation and release of component instances. 9 Naming services, which allow identification and sharing of component instances. 9 Security services, which provides privacy of connection between a client and provider of services. 9 Transaction service, which allows a user to control the start and completion of distributed transactions across components. Recently the O M G also released a request for proposals for a component model for CORBA [20]. This is intended to extend the CORBA model to allow CORBA components to be defined through extensions to the IDL. This would allow server-side components to be created and their relationships to be described. The proposal under consideration draws many of its design ideas from Sun's Enterprise JavaBeans (EJB) specification (discussed later). It is expected that this proposal will be accepted as an O M G standard early in 2000. A number of implementations conforming to the various O M G standards are now available on a variety of platforms. For distributed applications executing across heterogeneous platforms, the O M G approach to component infrastructure has been shown to be a viable way to build componentbased applications. There are a number of examples of successful component-based implementations in applications domains such as banking, telecommunications, and retail.

5.2.2

Microsoft" s COM+

As can be expected, Microsoft, the largest software company in the world, has had a major influence in how people think about components and component oriented approaches. As Microsoft shifts its focus from desktop applications to enterprise-scale commercial solutions, it has described its vision for the future of application development as a component oriented approach building on Microsoft's existing dominant desktop technologies [21]. To enable sharing of functionality across desktop application, Microsoft developed the Component Object Model (COM) as the basis for interapplication communication [22]. Realizing the value of COM as a generic approach to component interoperation, Microsoft defined its strategy of component-based applications to consist of two parts. The first


17

is its packaging and distribution services, Distributed COM (DCOM), providing intercomponent communication. The second is currently referred to as Microsoft's Distributed interNet Applications (DNA) architecture, providing the additional categories of component infrastructure services making use of DCOM. Collectively these ideas are referred to as Microsoft C O M + [231. The packaging and distribution services implemented in DCOM consist of three major aspects: 9 The Microsoft Interface Definition Language (MIDL), which describes how business functionality is packaged for external access through interfaces. 9 The COM component model describing how components can make requests of each others' services. 9 The DCOM additions to COM providing support for location transparency of component access across a network. Additional component infrastructure services are provided by Microsoft via two products, both making extensive use of the underlying packaging and distribution services: 9 The Microsoft Transaction Service (MTS), which provides security and transaction management services. 9 The Microsoft Message Queue (MSMQ), which provides support for asynchronous communication between components via message queues. The Microsoft component infrastructure services offer significant functionality to builders of component-based applications for Windows platforms. For anyone building a distributed Windows NT or Windows 2000 solution, these services provide essential capabilities to greatly reduce the cost of assembling and maintaining component-based applications. Many Windows-based applications make significant use of the C O M + technologies, including many of Microsoft's own desktop applications such as the Microsoft Office Suite. Furthermore, a wide range of Microsoftfocused components is available from third-party software vendors (for example, there are hundreds of COM components listed at Microsoft's site--see ht tp : I/www. mi c r o s o f t. c o m l c o m p o n e n t resources).

5.2.3

Sun's Java-based Distributed Component Environment

One of the most astonishing successes of the past few years has been the rapid adoption of Java as the language for developing client-side

18

ALAN W. BROWN

applications for the web [24, 25]. However, the impact of Java is likely to be much more than a programming language for animating web pages. Java is in a very advantageous position to become the backbone of a set of technologies for developing component-based, distributed systems. Part of this is a result of a number of properties of Java as a language for writing programs: 9 Java was designed specifically to build network-based applications. The language includes support for distributed, multithreaded control of applications. 9 Java's run-time environment allows pieces of Java applications to be changed while a Java-based application is executing. This supports various kinds of incremental evolution of applications. 9 Java is an easier language to learn and use for component-based applications than its predecessors such as C + + . Many of the more complex aspects of memory management have been simplified in Java. 9 Java includes constructs within the language supporting key component-based concepts such as separating component specification and implementation via the interface and class constructs. However, Java is much more than a programming language. There are a number of Java technologies supporting the development of componentbased, distributed systems. This is what allows us to consider Java as a component infrastructure technology [26]. More specifically, there are a number of Java technologies providing packaging and distribution services. These include [27]: 9 JavaBeans, which is the client-side component model for Java. It is a set of standards for packaging Java-implemented services as components. By following this standard, tools can be built to inspect and control various properties of the component. 9 Remote Method Invocation (RMI), which allows Java classes on one machine to access the services of classes on another machine. 9 Java Naming and Directory Interface (JNDI), which manages the unique identification of Java classes in a distributed environment. An additional set of technologies support the remaining component infrastructure services. These are necessary to allow Java to be used for the development of enterprise-scale distributed systems. These technologies are defined within the Enterprise JavaBeans standard. Enterprise JavaBeans (EJB) is a standard for server-side portability of Java applications [28]. It provides the definition of a minimum set of services that must be available on any server conforming to the specification. The services include: process


19

and thread dispatching, and scheduling; resource management; naming and directory services; network transport services; security services; and transaction management services. The goal of the Enterprise JavaBeans specification is to define a standard model for a Java application server that supports complete portability. Any vendor can use the model to implement support for Enterprise JavaBeans components. Systems, such as transaction monitors, CORBA run-time systems, COM run-time systems, database systems, Web server systems, or other server-based run-time systems can be adapted to support portable Enterprise JavaBeans components. Early in 2000 all leading platform middleware vendors (except Microsoft) will have delivered (or claimed) support for the EJB standard. It is considered the primary alternative to Microsoft's C O M + model. As illustrated in Fig. 5, the EJB specification describes a number of key aspects of a system. In particular, a user develops an Enterprise JavaBean implementing the business logic required. The user also defines a Home interface for the bean defining how the EJB objects (i.e., instances of the EJB) are created and destroyed, and a remote interface for clients to access the bean's behavior. An EJB executes within an EJB container. Many EJB containers can operate within a given EJB server. The EJB server provides many of the basic services such as naming, transaction management, and security. The EJB specification was made available early in 1999. However, by the end of 1999 over 25 vendors already offered EJB-compliant containers. These implement the component infrastructure services that any application developer can rely on when designing a component-based application in

FIG. 5. E l e m e n t s o f a n E J B server.

20

ALAN W. BROWN

Java. The strong support for EJB from both Sun and IBM provides significant impetus to the case for EJB as an important player in the future of component infrastructure services. Toward the end of 1999, Sun Microsystems announced a new initiative aimed at bringing together a number of existing Java initiatives to provide a standard platform on which to build distributed applications in Java. This initiative, known as the Java 2 Enterprise Edition (J2EE) standard, builds on the Java 2 standard, and adds most of the important programming interfaces in an application server [29]. For example, J2EE includes the EJB specification for server-side components, together with the necessary application programming interfaces (APIs) necessary for building clients and connecting them to these server-side components (e.g., the Java Server Page (JSP) API for dynamically generating web pages, and the Java Naming and Directory Interface (JNDI) for locating and accessing distributed Java objects). To fulfill the promise of making the development of component-based systems in Java easier, the J2EE augments this collection of standards and interfaces with [30]: 9 A programming model for developing applications targeting the J2EE platform. This provides an outline approach to distributed application development, and highlights a number of key design heuristics for creating efficient, scaleable solutions in Java. 9 A compatibility test suite verifying J2EE platform implementations conform to the J2EE platform as defined by the collection of standards and APIs. This encourages portability of solutions across different vendors' implementations of the J2EE platform. 9 A reference implementation that offers an operational definition of the J2EE platform. This demonstrates the capabilities of the J2EE platform, and supplies a base implementation for rapid prototyping of applications. By collecting these elements together under a single umbrella, Sun aims to simplify the creation of distributed systems development for Java.

6.

H o w are Applications A s s e m b l e d using CBD?

Having described the basic component concepts and the main aspects of component execution environments, we now consider how these concepts are embodied in supporting a component oriented approach to application assembly. In particular, we identify the key elements on which any CBD approach is based.


21

While much of the technology infrastructure for component oriented approaches is in place, of equal importance to its success are the methods for developing component oriented applications. Faced with the wealth of technology, software developers must be able to answer the key question of how to effectively design solutions targeting that technology. The software industry is only just beginning to offer guidance in this regard. Fortunately, the latest wave of software development methods is beginning to rise to the challenge of supporting the development of distributed, Web-based systems involving reuse of legacy systems and packaged applications. A number of organizations have begun to publicize their methods and best practices for developing enterprise-scale systems from components. The three most prominent of these are: 9 Rational's unified process. This is a broad process framework for software development covering the complete software life-cycle. In architecting the solution a component-based approach is encouraged, heavily influenced by the constraints of the Unified Modeling Language (UML) notation [31]. 9 The Select Perspective method. A general component design approach is supported, targeted at the Select Component Manager. General component design principles target UML as the component design notation [32]. 9 Computer Associates' Enterprise-CBD approach. Influenced by the Catalysis approach to component development, Computer Associates' approach encourages a strong separation of component specification from implementation using an extended form of UML [33]. This allows technology-neutral specifications to be developed and then refined into implementations in a number of different implementation technologies.

These approaches differ in many details. However, the abstract method that they encourage for component-based design is fundamentally the same. As illustrated in Fig. 6, three key elements provide the focus of these methods: a diverse set of components stored in a component library, an interface-focused design approach, and application assembly based on a component architecture.

6.1

Sources of Components

A component has been informally defined as an independently deliverable piece of functionality providing access to its services through interfaces. This definition is important as much for what it doesn't say as for what it does

22

ALAN W. BROWN

FIG. 6. Elements of a component-oriented software process.

say; it does not place any requirements on how the components are implemented. Hence, valid components could include packaged applications, wrapped legacy code and data, previously developed components from an earlier project, and components developed specifically to meet current business needs. The diverse origin for components has led to a wealth of techniques for obtaining components from third parties, developing them in a variety of technologies, and extracting them from existing assets. In particular, many CBD approaches focus on wrapping techniques to allow access to purchased packages (e.g., enterprise resource planning (ERP) systems) and to mine existing legacy systems to extract useful functionality that can be wrapped as a component for future use. This approach leads to a view of CBD as the basis for enterprise application integration (EAI). Many vendors providing technologies for combining existing systems take a component view of the applications being assembled, and introduce specific integration technologies to tie the systems together. Often this is focused on the data flows in and out of the packages, and consists of transformers between the packages offering a broker-based approach. The sources of the components may be diverse and widespread, yet assembling solutions from these components is possible due to: 9 use of a component model as a standard to which all components can conform regardless of their heritage; 9 a component management approach, supported by appropriate tools, for the storage, indexing, searching, and retrieval of components as required;


23

9 a design approach that allows solutions to be architected from components by considering their abstract functionality, and ignoring peculiarities of their implementation for a later date. This final aspect, a design approach targeting appropriate component architectures, is a key element to the success of component approaches in general. In particular, it is the motivation for interface-based design approaches.

6.2

Interface-Focused Design

Interfaces are the mechanism by which components describe what they do, and provide access to their services. The interface description captures everything on which the potential client of that component can rely since the implementation is completely hidden. As a consequence, the expressiveness and completeness with which the interfaces are described is a primary consideration in any component-based approach to software. Furthermore, during the early stages of analysis and design, the focus is on understanding the roles and responsibilities within the domain of interest as a basis for the interfaces of the implemented system. This gives rise to a new form of design method: interface-based design. Focusing on interfaces as the key design abstraction leads to much more flexible designs [34]. Designers are encouraged to consider system behavior more abstractly, define independent suppliers of services, describe collaborations among services to enact scenarios, and reuse common design patterns in addressing familiar situations. This results in more natural designs for systems with a greater independence from implementation choices. Such thinking is an essential part of new application provisioning approaches in the Internet age. To target rapidly evolving distributed computing technologies requires an approach to design that can evolve as the technology changes. Familiar, rigid approaches to design are unsuitable. Interface-based design approaches represent a significant step forward in reducing the cost of maintenance of future systems.

6.3 Applications and Component Architecture Interfaces and interface-based design provide the techniques necessary for a component assembly view of software-intensive solutions. Component assembly concerns how an application is designed and built from components. In a component-based world, an application consists of a set of components working together to meet the broader business needs. How this is achieved is often referred to as the component architecture--the

24

ALAN W. BROWN

components and their interactions. These interactions result in a set of dependencies among components that form an essential part of a software solution. Describing, analyzing, and visualizing these dependencies become critical tasks in the development of a component-based application. Typically, a candidate component architecture is proposed relatively early in a project. This consists of a number of known pieces of existing systems to be reused, familiar patterns of system interactions, and constraints based on imposed project and organizational standards. Consequently, at least two levels of component architecture become important. The first is a logical component architecture. This describes the abstract design of the system in terms of the major packages of functionality it will offer, descriptions of each collection of services in terms of its interfaces, and how those packages interact to meet common user scenarios. This is often called the component specification architecture. It represents a blueprint of the design of the system. Analysis of this architecture is essential to ensure that the system offers appropriate functionality, and can easily be modified as the functional requirements for the system evolve. The second is a physical component architecture. This describes the physical design of the system in terms of selected technical infrastructure products, distributed hardware and its topology, and the network and communication protocols that tie them together. This forms part of the component implementation architecture. This architecture is used to understand many of the system's nonfunctional attributes such as performance, throughput, and availability of services.

7.

W h a t is the Current Practice in CBD Today?

A number of organizations are practicing component-based approaches today using a variety of technologies. While many component approaches are limited to client desktop applications (via ActiveX controls, visual Java Beans, and so on), there are others that are beginning to address larger scale applications with significant business functionality. There are a number of very valuable lessons being learned by these pioneers of component approaches. Originally, many of these lessons were related to the vagaries and incompatibilities of specific component technologies. More recently, a number of published accounts discuss a much broader range of critical success factors for component approaches in areas such as organizational readiness, costs of component development, and management of deployed component-based applications. Much can be learned from these existing users of components, and by examining the strategies and directions of key organizations in the software


25

industry. To establish the current practice in CBD today we look at three key communities: component vendors creating a marketplace of third-party components, component portal providers offering information and discussion forums on component-related topics, and component infrastructure providers establishing the strategic direction for many of the key component technologies. 7.1

Component

Software Vendors

A number of companies now offer brokering services for components. Through their on-line presence they allow component suppliers to make their components available to a broader market, and provide a focal point for those organizations looking to acquire those components. Component software brokers offer services for the buying and selling of components, additional services for cataloguing and certifying components, and some form of auction or matching services to connect potential suppliers of components with those looking for solutions. To support and promote their brokering activities they additionally provide a source of information, guidance, and advice on components and component technologies. There are four major component software brokers: ComponentSource (w w w . c o m p o n e n t s o u r c e . c o m). This is the most widely used of the component software brokers, offering the largest selection of components. It has an extensive catalog of components for many technologies. The majority of the components are focused on user interface controls for Microsoft desktops (ActiveX, COM). There are some business-focused components, with some information to allow a detailed evaluation. Some attempt has been made to provide consistency across the component descriptions via white papers offering guidance for component providers. 9 FlashLine (www. f l ash l i ne. com). Many components are provided for both Java (some EJB) and COM. However, perhaps most interesting is the free component manager that is offered. It is a front-end navigation and search engine for components to be shared among teams. This can be used standalone, or as a plug-in to some of the popular IDEs. Other services offered include a component auction site, and a QA and certification lab where organizations can pay for a component to be certified against a set of basic criteria. 9 Objectools (www. ob j e c t oo l s . com). This offers a relatively small number of components, with rather terse descriptions of each

9

26

ALAN W. BROWN

component's attributes. Having started in early 2000, this is a growing company catching up with the other two component software brokers in terms of quantity of components, and services being offered. IntellectMarket (www. In t e L Lec tMark e t . corn). This is a fledgling component software exchange launched towards the end of 2000. It is supported by Tim O'Reilly, so may have significance in its association with the very successful O'Reilly education services, and the larger open-source community promoted by Tim O'Reilly. The component software brokers appear to be interesting first generation solutions to the component software market. Perhaps this is inevitable given the relative newness of the component technologies they are intended to support. However, they have a number of limitations. To have greater impact they are now beginning to turn their attention toward four key areas:

1. Increasing the depth of the information the)' provide on the components they offer. At present, this often consists of a high-level functional description provided by the vendor, with a summary of technical requirements. Real application of the components requires much more knowledge about the nonfunctional aspects (quality, robustness, performance, etc.). 2. Offering consistent information about the components. As an information service on components these companies can set standards for the way in which a component is specified and delivered. They offer the potential to have a major impact in component development and should drive the component description into more useful forms. 3. Becoming integral parts of the component technology vendors. Both infrastructure and tool vendors must recognize the importance of the services they offer, and form a partnership that provides benefit to component consumers. 4. Broadening the quality and range of the services offered. There is a great deal of variability in the quality of the on-line material offered. The balance between quantity and quality of information is always a difficult o n e - - b u t must be constantly in the forefront of any decision made.

7.2

Component Software Portals

Another aspect of the component software market is the availability of information services that provide suppliers and consumers of components with the information they need to be successful. This begins with in-depth


27

discussions of the technology, but concerns many other aspects required to make the component marketplace a success--economic, cultural, educational, political, and so on. Many information services are available for software organizations, addressing many levels of detail required across the organization. The software component market is certainly an integral part of the information provided by industry analyst organizations such as IDC, Forrester Research, Gartner Group, Hurwitz Group, Patricia Seybold Group, Giga Information Group, and many others. While many of these provide valuable coverage of the component software market, we are now seeing services dedicated to components, component technologies, and component-based development approaches. There are many interesting component software portals. Some of the more influential include: 9 CBDi Forum (www. c bd i f o r urn. com). This independent forum for information on CBD offers a range of free and subscription based services via the Internet. It has the support of a number of major software tool vendors. In particular, it seems to be creating a close relationship with Microsoft, and offers a number of articles on the component market in relation to Microsoft's D N A and .NET technologies. CBDiForum is a comprehensive information forum, and also runs conferences and workshops in addition to providing the on-line information. Much of the information is freely available, while more in-depth information requires a paid subscription. This is a 9 Component Software (www. C o m p o n e n t S o f t w a r e . n e t ) . more general news and information portal spawned from the CBDi Forum. It is intended to be a general component software information launching pad for product news and announcements. 9 The ServerSide (www.theserverside.com). This site focuses on the J2EE technologies. It is intended to provide a community service to EJB/J2EE developers offering discussion forums, documents, component directories, and other relevant information. It is maintained by Ed Roman and his company, The Middleware Company. 3 It is a comprehensive, interactive forum for EJB developers. 9 CBD HQ (www. c b d - h q , com). This site provides a broad range of white papers and articles on components and component-based development. The maintainers of this site gather articles and commission papers on business-focused software components. Much 3 Ed Roman has a very popular book on EJBs called Mastering EJB published by John Wiley.

28

ALAN W. BROWN

of it is based around the component consulting practices offered by Castek, but the papers are much broader in scope. Rather than a news service, this provides more in-depth insight into component technology and practices. 9 The

Open

Component

Foundation

(w w w . o p e n - c o m p o n e n t s .

c o m).

This is a general information portal for component software run by the Centre for Innovation and Technology. As can be seen, a broad range of component software portals already exists, offering a great deal of information and advice. Much of this information is interesting and useful, offering a broad mixture of product release information, reprints of vendor white papers, and expert commentary. To further improve the information they provide, these component software portals are attempting to create greater value and impact by moving in three key directions:

1. Focusing their content to a well-scoped audience. In many cases it is better to do one thing really well than do many things in a mediocre way. This appears to be particularly true for component software portals. As a result, these portals are continually refining their focus to meet the needs of a well-defined audience. 2. Providing greater interactiviO'. Many of the portal sites currently provide little opportunity for true community activities. They are now in the process of adding the necessary infrastructure for sharing ideas and information. 3. Increasing the practical utility of the information. In this stage of the maturity of the component software market the most pressing need is for simple, practical guidance and advice. These sites are looking to increase their value by categorizing the information into major themes for different audiences so that detailed technical help is available for developers, and strategic analyses are provided for managers and decision makers.

7.3

Component Infrastructure Vendors

To understand the current state of CBD it is important to understand and assess the approaches to component software being taken by the major technology infrastructure vendors. The four major players in this regard are Microsoft, IBM, SUN, and BEA. 4 4A lot more information on these vendors" initiatives can be found at their respective Web

sites.


7.3. 1

29

Microsoft

The dominance of Microsoft on the desktop has much to do with two things: 9 The way in which Microsoft has gradually improved the integration of the various tools and services to allow data to be moved across tools, application services to be started from within a variety of tools, and creation of a common desktop visual appearance across many tools and services. 9 The ease with which third-party tools and service providers can make use of Microsoft tools and services within third-party products, or use third-party products as plug-ins to Microsoft products. The underpinning for all of this is the Component Object Model (COM). As Microsoft's strategy has evolved (from OLE, COM, C O M + , and now into D N A and .NET) this core of component concepts and services has been at the heart of their approach. Moving forward, Microsoft's current strategy with respect to components and component technologies appears to focus on a number of key elements. While the COM specification remains central to their approach, Microsoft now is creating a broader environment in which COM can flourish. This includes: 9 XML, SOAP, and UDDI. Microsoft's response to the threat of Java and the EJB technology is to de-emphasize the languages used for creating component implementations, and instead focus on how components are assembled and connected using the Internet as the distribution medium. Their approach is a complete service-based initiative using the extensible Markup Language (XML), the Simple Object Access Protocol (SOAP), and the Universal Description, Discovery and Integration protocol (UDDI) 5 as the connection technologies. This is an attempt to diffuse the Java concerns and say that the components can be implemented in any language or technology. What matters is how the pieces communicate. Microsoft believes that XML, SOAP, and U D D I will provide the universal "glue" to make this happen. This philosophy forms the basis of Microsoft's .NET strategy. The Visual Studio development environment has changed from a Visual Basic environment to a COM environment, and now will be oriented toward developing component services integrated via XML and SOAP, for exchange via UDDI. 5XML provides a simple tag-based language for encoding many kinds of information; SOAP allows distributed component interactions to be encoded within XML. UDDI provides registry and service exchange facilities for accessing SOAP-based services across the Internet.

30

ALAN W. BROWN

9 Redefining MTS as an application server. The Microsoft Transaction Server (MTS) provides an essential element of large-scale distributed systems, forming the core set of capabilities of the middle tiers of an ntier solution. As the notion of an application server has matured in the market, Microsoft has started to describe MTS as "the application server for COM-based distributed systems for the enterprise." 9 Expanding the MSDN community. The Microsoft Developer Network (MSDN) is a large group of developers creating solutions for Microsoft infrastructure. Recognizing the important role they play, Microsoft is increasing its support for these developers and expanding MSDN towards a more powerful information and software distribution channel. This will involve greater use of Web technology for more dynamic, interactive content. 9 Creating a catalog of reusable COM components. The success of a component approach requires a market of available components. Microsoft has set up their component catalog to use the MSDN as a channel for providers and resellers of COM components ( h t t p : / / m s d n . mi c r o s o f t. c o m / c o m p o n e n t

7.3.2

r e s o u r ces).

IBM

As a large, diverse organization, there are many different threads to IBM's approach to the component software market. The past few years has seen IBM make a number of changes in its approach and philosophy in this area. These changes reflect the fast pace of change in this market, the challenge posed by Microsoft's desktop dominance, and the difficulties IBM has had in changing its approach from a mainframe/server organization to an e-commerce vendor. In the past few months IBM has presented a much more Web-centric image, and is amalgamating its middle tier e-commerce strategy under the WebSphere branding. This encompasses new software products (such as the application server WebSphere Enterprise Edition) and a repositioning of existing middleware products such as MQSeries and MQIntegrator. From a strategic standpoint, IBM has announced strong support for the Java technologies as the basis for competing against Microsoft. IBM believes that organizations gain more flexibility and openness through the Java language, virtual machine, and interface standards. As a result, IBM's component software approach consists of: 9 A component assembly environment for Java. VisualAge for Java (VA) has become a very popular tool for developing Java applications, JavaBeans, and now Enterprise JavaBeans (EJBs). It is a typical


31

interactive development environment (IDE) for Java, but also offers some elements of visual assembly of beans, and automatic deployment of EJBs to IBM's application servers. The WebSphere application server. IBM has developed a number of distributed object technologies over the past decade (e.g. S O M / DSOM). None of these has been particularly successful. These have now evolved into an application server product supporting the EJB standard as WebSphere. Although rather large and complex, it appears that WebSphere is gaining significant momentum in the market. A component framework. The IBM San Francisco Project began some years ago as an ambitious attempt to create a complex reusable set of objects as the basis for families of solutions in a wide number of domains. As this work was gathering pace, the Java explosion gained momentum and a different group in IBM was helping to create the EJB specification. The result is that the San Francisco Project has reoriented its work to be a set of reusable frameworks for creating EJB-based applications. The outcome of this work appears to be a set of reusable components for deployment to WebSphere, plus some guidance on assembling those components into enterprise-scale solutions focused on a number of important business domains (e.g., banking, insurance, retailing).

7.3.3

Sun

Although primarily a hardware company, Sun has been attempting to improve the software aspects of its business for some years. The latest attempts are based on Sun's prominent identification with the Java technologies. To capitalize on this, Sun is trying to build a substantial software-focused business around Java-based solutions for every kind of platform from Internet appliances and handheld devices to high-end enterprise solutions. A number of acquisitions have taken place to bring in the required technology. Sun's current strategy involves a number of elements: 9 An EJB application server. A number of acquisitions have resulted in application servers, including the iPlanet, NetBeans, and SynerJ servers. The result has been to consolidate on the iPlanet server. This is a J2EE compliant container for EJBs. 9 A set of development tools for Java. The development tools from NetBeans and Forte have been renamed to provide three different kinds of t o o l s - - F o r t e for Java Developer Edition is the NetBeans developer product, Forte for Java Internet Edition is the NetBeans Developer Pro product, and Forte for Java Enterprise is the Forte SynerJ product.

32

ALAN W. BROWN

Around these products Sun is creating a community of enterprise Java developers through its work on the Java standards. This is based on its standards activities such as the Java 2 Enterprise Edition (J2EE). J2EE provides architecture for enterprise Java solutions based on Java Server Pages (JSPs), Java Servlets and EJB. It also includes a reference EJB container, and guidelines for building distributed systems in Java. In addition, Sun manages a number of community activities, most notably the JavaOne conferences.

7.3.4

BEA

The past year or two has seen BEA rise quickly to be a key player in the component software market. Beginning as an infrastructure and middleware company, BEA has successfully extended its market reach to become the major provider of EJB application server solutions. This approach is based on the following elements: 9 A range of application servers. BEA offers three different application servers--WebLogic Express for simpler database-to-webpage systems, WebLogic Server for Java-based n-tiered solutions, and WebLogic Enterprise for high transaction distributed solutions (based on the Tuxedo middleware). 9 A set of development and deployment tools. Through various acquisitions, BEA has major ownership of WebGain, offering WebGain Studio as the main environment for developing WebLogic applications. It also provides Visual Cafa as a Java based IDE, and the TopLink tool for persistence management (including object to relational mappings). 9 A set of business components. The acquisition of The TheoryCenter provided BEA with a useful set of about 80 business components aimed at building e-commerce applications for deployment to WebLogic Server. These components are marketed as a BEA Weblogic Commerce Server. Additionally, BEA offers some application-focused solutions built on the WebLogic platform. This includes an e-commerce server, and a personalization server.

8.

Summary

Component-based development of software is an important development approach for software solutions which must be rapidly assembled, take


33

advantage of the latest Web-based technologies, and be amenable to change as both the technology and users' needs evolve. One of the key challenges facing software engineers is to make CBD an efficient and effective practice that does not succumb to the shortcomings of previous reuse-based efforts of the 1970s and 1980s. Fortunately, the past few years has seen a number of major advances in both our understanding of the issues to be addressed to make reuse successful and the technology support available to realize those advances. These are embodied in the rapidly growing field of component-based software engineering. This approach encourages a new way of application development that focuses on the following: 9 separation of component specification from component implementation to enable technology-independent application design; 9 use of more rigorous descriptions of component behaviors via methods that encourage interface-level design; 9 flexible component technologies leveraging existing tools and standards. This chapter has identified the key concepts underlying a componentbased approach to software engineering. These have been explored in the context of improving our understanding of CBD, assessing the current state of CBD technology, and improving an organization's software practices to enhance the effectiveness and viability of large-scale software development through the reuse of components. This will help to lead organizations toward an interface-based approach to application development and design that encourages the creation of systems that are more easily distributed, repartitioned, and reused. These attributes are essential to improve the future effectiveness of organizations in their development and use of largescale software systems in the Internet age. REFERENCES Brown, A. W. (2000). Large-scale Component-Based Development. Prentice Hall. Cheesman, J. and Daniels, J. (2000). UML Components. Addison-Wesley. Brown, A. W. and Wallnau, K. C. (1998). "'The current state of CBSE". IEEE Software. Allen, P. (2000). Realizing e-business with Components. Addison-Wesley. Garlan, D., Allen, R. and Ockerbloom, J. (1995). "'Architectural mismatch: why it's hard to build systems out of existing parts". Proceedings o./ the hTternational Conference on Software Engineering. [6] Parnas, D. (1972). "On the criteria for decomposing systems into modules". CACM, 15, 12, 1053-1058. [7] Parnas, D. (1976). "On the design and development of program families". IEEE Transactions on Software Eng&eering, 7, 1, 1-8.

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

34

ALAN W. BROWN

[8] Prieto-Diaz, R. and Freeman, P. (1987). "'Classifying software for reusability". IEEE Software. [9] Cox, B. (1986). Object Oriented Programming--An Evolutionary Approach. AddisonWesley. [10] Brown, A. W. and Wallnau, K. C. (1996). "Engineering of component-based systems". Proceedings of the 2nd IEEE International Conference on Complex Computer Systems, October. [11] Kara, D. (1996). "Components defined". Application Development Trends. [12] Allen, P. (1999). "Using components to improve your business". Component Strategies. [13] Daniels, J. (1999). Objects and Components. An internal whitepaper of Computer Associates. [14] Szyperski, C. (1998). Component So[tware." Beyond Object-Oriented Programming. Addison-Wesley. [15] Meyer, B. (1999). Object-Oriented Software Construction. Second Edition. Prentice Hall. [16] Sessions, R. (1998). "'Component-oriented middleware". Component Strategies. [17] OMG, (1998). "The object management architecture (OMA) guide". Available from http'//www.omg.org.

[18] [19] [20] [21] [22] [23] [24] [25] [26] [27]

Siegel, J. (1998). CORBA Fundamentals and Programming. Wiley. OMG, (1999). "CORBA services". Available from h t t p - / / w w w . o m g . o r g . Siegel, J. (2000). "What's coming in CORBA 3?". Java Developers Journal. Sessions, R. (1997). COM and DCOM: Microsoft's Visionjor Distributed Objects. Wiley. Box, D. (1997). Essential COM. Addison-Wesley. Platt, D. S. (1999). Understanding COM+. Microsoft Press. Flanagan, D. (1999). Java in a Nutshell. O'Reilly Press. Horstmann, C. (1999). Core Java 2, Volume 1." Fundamentals. Prentice Hall. Asbury, S. and Weiner, S. R. (1999). Developing Java Enterprise Applications. Wiley. Austin, C. and Powlan, M. (1999). "Writing advanced applications for the Java platform". Sun Microsystems. Available at h t t p- / / j a v a. s u n. c o m, December. [28] Sun Microsystems, (1999). "Enterprise JavaBeans Standard" Version 1.1. Available at h t t p " 1/j ava. sun. c o m

[29] Roman. E. (1999). Mastering Enterprise JavaBeans and the Java 2 Platform, Enterprise Edition. Wiley. [30] Flurry, G. (1999). "'The Java 2 Enterprise Edition". Java Developers Journal. [31] Booch, G. et al., (1999). The Uni.fied Modeling Language User Guide. Addison-Wesley. [32] Allen, P. and Frost, S. (1998). Conlponent-Based Development for the Enterprise." Applying the Select Perspective. Cambridge University Press. [33] D'Souza, D. and Wills, A. C. (1998). Objects, Components, and Frameworks with U M L - the Catalysis Approach. Addison-Wesley. [34] Coad, P. and Mayfield, M. (1999). Java Design. Building Better Apps and Applets. Second Edition. Yourdon Computing Press.

Working with UML: A Software Design Process Based on

Inspections for the Unified Modeling Language GUILHERME H. TRAVASSOS COPPE/PESC Federal University of Rio de Janeiro P.O. Box 68511 Rio de Janeiro, RJ 21945-970 Brazil 55 21 562 8712 [email protected]

FORREST SHULL Fraunhofer Center u Maryland University of Maryland 4321 Hartwick Road, Suite 500 College Park, MD 20742 USA 301-403-8970 fshull@fraunhofer, org

JEFFREY CARVER Experimental Software Engineering Group Department of Computer Science University of Maryland College Park, MD 20742 USA 301-405-2721 [email protected]

Abstract This text describes a simple and effective object oriented software design process template having UML as the modeling language and extensively using inspections to support the construction and maintenance of software products. This software design process uses a sequential organization, based on the waterfall approach, for two reasons: to simplify the explanation of design activities in the context of ADVANCES IN COMPUTERS, VOL. 54 ISBN 0-12-012154-9

35

Copyright ~; 2001 by Academic Press All rights of reproduction in any form reserved.

36

GUILHERME H. TRAVASSOS ETAL. this text and to make available a standard process that can be continuously improved by developers. The component phases of this design process are described in a way that gives developers the freedom to reorganize the overall process based on their own needs and environment. I n a d d i t i o n , a survey is provided of specific literature regarding important aspects of UML and the object oriented paradigm.

1.

Introduction

2.

The Unified Modeling Language ( U M L ) . . . . . . . . . . . . . . . . . . . . 2.1 Different Perspectives to Improve Design Modeling . . . . . . . . . . . . Software Process Activities . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.1 Development Activities . . . . . . . . . . . . . . . . . . . . . . . . . . Quality Assurance and Verification and Validation Activities . . . . . . . . 3.2 The Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.1 Requirements Activities . . . . . . . . . . . . . . . . . . . . . . . . . . 4.2 High-Level Design Activities . . . . . . . . . . . . . . . . . . . . . . . . 4.3 Low-Level Design Activities . . . . . . . . . . . . . . . . . . . . . . . . Maintenance or Evolution . . . . . . . . . . . . . . . . . . . . . . . . . . .

3.

4.

5.

6.

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

36

.

40

.

41

.

43

.

44

.

47

.

64

.

67

.

70

.

84

.

86

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

87

5.1

Process

5.2

Understanding

5.3

Example

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

88

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

91

The Road Ahead References . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

94

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

95

1.

Introduction

This chapter describes a simple and effective object oriented (OO) software design process template having UML as the modeling language and extensively using inspections to support the construction and maintenance of software products. In addition, a survey of specific literature regarding UML and the object oriented paradigm is presented. This software design process uses a sequential organization based on the waterfall approach for two reasons: to help with the explanation of design activities in the context of this chapter and to make available a standard process that can be continuously improved by developers. This process does not result in a loss of generality in this discussion because after developers understand the process they have freedom to reorganize all of the component phases. The activities that were considered for such a software process template are requirements specification, high- and low-level design, coding, and testing. However, we have inserted inspection activities at various points in the life-cycle to help address quality issues, as explained in Section 3.2.2.

WORKING WITH UML

37

We have concentrated on describing only activities that specifically use the OO paradigm and make use of UML. So, elicitation of requirements [1], an important task in the context of software development, is not considered here in detail. Different techniques and methods can be used for requirements elicitation and description [2]. Requirements descriptions are paradigm-independent and must be chosen based on customer needs [3]. System scenario descriptions (use cases) are part of the requirements specification and are produced after the problem is described. We consider this as part of the OO design, because the way that scenarios are described can impact future design solutions. Use cases are a good mechanism to help identify basic concepts and give an indication of the functionality of the system. The functional requirements and problem domain concepts described by the requirements and use cases arrange the information used to produce the high-level design, a set of UML artifacts. Then, these design artifacts are evolved to include nonfunctional requirements and the features that deal with the computational side of the problem, or the solution domain. These evolved artifacts are the low-level design. The result of this process will be a set of models ready for coding and testing. Generally, a software development process defines the way real-world concepts should be represented, interpreted, and transformed into a working software system. Typically, the software development process is guided by a strategy or paradigm. There are some paradigms, such as structured (or functional) and data oriented [4] that are well established. Although these paradigms can be used to specify and design systems for different types of problems, their use impacts the quality and productivity of software development. In these paradigms, developers do not use a consistent notation throughout the software life-cycle. This reduces their freedom to reorganize these activities to fit the software life-cycle models of their organization. The object oriented (OO) paradigm has emerged to address such issues. Although no "perfect" development paradigm exists (since effective software development also addresses issues beyond tailoring the software process), the OO paradigm has demonstrated its capability for supporting software process improvements in situations where other models were not suitable [5]. The OO paradigm's use of the logical constructs [6] of class, object, inheritance, polymorphism, aggregation, composition, and message to describe concepts and build artifacts across the software lifecycle improves the software process, because it: 1. allows developers to use a consistent notation with a common set of constructs across phases, increasing their communication throughout different development phases;

38

GUILHERME H. TRAVASSOS ETAL.

2. deals with well-defined components, protected by encapsulation (data and functionality) and displaying their corresponding interfaces, which allows the organization of the development activities using different software life-cycle models [7], and; 3. can be used as a criterion to identify possible parallel development tasks, speeding up the full development process.

OO design is a set of activities (scenario description, high- and low-level design) concerned with the representation of real-world concepts (as described by the requirements descriptions) as a collection of discrete objects that incorporate both data structure and behavior. These concepts must be somehow extracted from the requirements 1 to guide the construction of the artifacts that represent system scenarios, and high- and low-level design [8]. The technical literature describes several OO notations. A notation when associated with a software development process is called a methodology. For instance, methodologies such as OMT [9], BOOCH [10], OOSE [11], and FUSION [12] have been suggested. All of these methodologies are based on a specific software development process and use their own syntax and notation in trying to define a broad-spectrum software development methodology. However, it is not easy to define a software development methodology which is general enough to fit all software development contexts and domains. Each of these methodologies is suitable for specific systems (or problem domains), but not for all systems. Because different methodologies use different design representations it is difficult to compare information among projects that used different methodologies, even if those projects are from the same problem domain. These kinds of difficulties can be avoided by using a homogeneous notation (modeling language) and a standard software design process. One of the perceived benefits of the object oriented paradigm is that developers can use it for different software processes and life-cycles. Regardless of the paradigm and the software life-cycle used to plan the software process, a common set of activities is present, namely requirements specification, design (including high- and low-level issues), coding, and testing. Using this basic set of activities a template for OO design can be created, showing how the activities can be represented using a homogeneous notation. Additionally Kitchenham et al. [13], argued that software maintenance processes are similar to software development processes, which 1Requirements can be specified using a number of notations, from natural language to formal specifications. In the context of this work we consider that requirements are organized and described using natural language. It does not result in any loss of generality of our discussion, since OO design is concerned with translating the meaning of system requirements regardless of their notation.

WORKING WITH UML

39

makes this template with slight modification also suitable to software evolution and maintenance. Developers can tailor this software process to their specific development context while continuing to use the same modeling language. These modeling languages represent an interesting way of using OO constructs to describe problem domain concepts. By providing graphical representation for these constructs, these languages simplify the representation and allow developers to highlight important information about the problem domain. Moreover, they provide a well-specified and homogeneous set of constructs to capture the different object perspectives (static and dynamic) making the representation of the information consistent and reusable across different projects. The Unified Modeling Language (UML) is an example of such a language. Several companies and organizations around the world have used it and it has been adopted as an Object Management Group (OMG) standard [14]. Developers are using UML for more than just representing design diagrams. Several tasks concerned with software architecture modeling [15], pattern descriptions [16], design formalization [17], measurement supporting [18], and OO software inspection [19] have been accomplished using UML artifacts or extended UML artifacts. UML can also be used to represent high-level abstraction concepts, such as software process models [20], metamodels [21], and domain analysis models [22] or physical concepts, such as resources [23] and correlated engineering fields [24]. UML does not have a software process associated with it. Several software life-cycles and processes using UML exist for different contexts and domain applications. Some software process models can be used as frameworks to organize and configure design activities. A few examples are Catalysis [25], RUP [26], Unified Software Process [27], and Open [28]. Although strong, most of these models impose a high cost, as they are based on automated tools and require some training and detailed planning. Moreover, their weakness in providing techniques or guidance for defect detection in artifacts and the difficulty of adapting them to specific classes of problems, such as e-commerce or real-time systems, make the decision of whether to adopt them a complicated and risky task. This chapter has six sections, including this introduction. Section 2 deals with a short description of UML and how the artifacts are classified. Section 3 describes the design activities and a process for applying them. In Section 4 a small example is described and used to illustrate the use of UML, including requirements, high-level and some of the low-level design issues. In Section 5, maintenance is considered along with proposals on how the basic development process discussed in Section 3 can be modified to support software evolution and maintenance. Section 6 concludes this text.

40

GUILHERME H. TRAVASSOSET AL. 2.

The Unified Modeling Language (UML)

In recent years, the use of the OO paradigm to support systems development and maintenance has grown. Unlike other paradigms, such as structured or data-oriented development where developers are able to use several different methodologies and notations [7], the unification of different techniques provided a standard way to represent the software artifacts. One of these standards, representing a notation and modeling language, used by several companies and developers around the world, is U M L i t h e Unified Modeling Language. As stated by Booch [29] ~the UML has found widespread use: it has been applied successfully to build systems for tasks as diverse as e-commerce, command and control, computer games, medical electronics, banking, insurance, telephony, robotics, and avionics." In 1995, the first UML proposal was produced by combining work by Grady Booch [10] and James Rumbaugh [9] and released as version 0.8. Subsequently, Ivar Jacobson's contributions [11] were integrated into releases 0.9 and 0.91 in 1996. Since then, developers and companies around the world have been working together on its improvement. By integrating different techniques and mechanisms proven effective on industrial projects, the draft evolved through multiple versions. These efforts resulted in the development of UML 1.1, which was added to the list of technologies adopted by the Object Management Group (OMG) in November of 1997. OMG has assumed the responsibility of organizing the continued evolution of the standard [30]. In this text the OMG UML standard version 1.3, released in 1999, has been used [14]. Four objectives guided the development of UML [14] and are reflected in version 1.3: 1. Enable the modeling of systems (and not just software) using object oriented concepts. The UML artifacts explore basic software development concepts, such as abstraction, information hiding, and hierarchy, as well as object oriented paradigm constructs, such as class, inheritance, composition, and polymorphism [6]. Additionally, they provide techniques to support development, organization, and packaging, and mechanisms to represent the software architecture and deployable components. These features cover different aspects of software development and enable UML to represent not only systems but also software models. 2. Establish an explicit coupling to conceptual as ~t'ell as executable artifacts. By describing the problem using different perspectives (e.g., static and dynamic views), UML allows developers to capture all the relationships and information structures as well as all the behaviors and object

WORKING WITH UML

41

state modifications. Also, specific object constraints and features can be formalized and explicitly connected to the concepts, making the models reliable and able to be verified and validated. 3. Address the issues oflscale inherent in complex, mission-critical systems. Because UML does not have standard techniques and processes and can be used in different approaches (top-down and bottom-up) engineers are able to deal with different levels of abstraction and formalism, which is required when modeling and building software for different application domains. Moreover, the syntax of the modeling language makes available a homogeneous set of constructs supported by a well-defined set of techniques and that can be organized throughout the software development process to break down and reduce problem representation complexity. 4. Create a modeling language usable by both humans and machines. Although the intention is not to provide a standard framework to implement and integrate CASE tools, UML guarantees the same semantics and understanding for its constructs. This normalization of the representation plays an important role when developers are recognizing and describing problem domains, allowing the same information to be interpreted by different developers. It also stimulates different vendors to provide CASE tools for supporting the language, by defining a consistent and standard set of models to specify and build integration mechanisms for sharing information among different tools. This section will not discuss all the definitions of UML and its possible uses. Instead, it gives an overview of the different artifacts that can be created and the relationships among them. In Section 4, concepts and artifacts will be used to build an example application. The reader who desires a more complete view of UML may find some of the following works useful: An introductory text about UML can be found in Fowler and Scott [31]. It describes basic concepts and gives small examples on how the artifacts can be used to represent different projects situations. Rumbaugh [32] prepared a UML reference manual and Booch [10b] developed a tutorial describing how developers can use UML while performing different design activities. However, if more information is still necessary, the complete set of definitions and formalized concepts can be found in [14]. Object oriented concepts and definitions can be found in [6] and [10].

2.1

Different Perspectives to Improve Design Modeling

Although UML artifacts can be classified in different ways (e.g., the UML draft 1.3 describes the different types of documents, including use case

42


diagrams, class diagrams, behavior diagrams, and implementation diagrams) this text classifies UML software artifacts into three general categories: static, dynamic, and descriptive. There is a strong connection among these three categories. Each one of them captures or represents a different system perspective. In this way they are complementary; each describing a specific aspect of a system and together describing all relevant points of view. The classification of these is summarized in Table I. Static artifacts capture the information that is constant for one version of the software or system. This information is always true regardless of the functionality and state of the system. It includes classes, their structural organization (attributes and behaviors) and interface (visibility of behaviors), relationships with other classes (inheritance, aggregations, generalizations, and acquaintances), and interdependent packages. Moreover, the physical structure and organization of the software or system, including the components and processors that developers identified during implementation, can be classified as static. Artifacts that represent the static information are the class, package, component, and deployment diagrams. By representing all the relationships among classes and pieces of the system, developers are able to visualize important features of the model, such as interdependence, that will cause the coupling and structural complexity of the model to increase, impacting the cost and quality of the whole design. Dynamic artifacts describe information about communication (message exchanging) among objects and how these objects can be put together to accomplish some service or functionality. Important events in the problem can lead objects to change their states and need to be represented. These state changes can determine the correct behavior, services, and even functionalities that must be performed based on the different scenarios that have be~n modeled. The dynamic artifacts are use cases, interaction (sequence and collaboration diagrams), statecharts, and activities diagrams. These artifacts enhance TABLE I UML ARTIFACT CATEGORIES Category

Artifacts

Static

Class, package, component, and deployment diagrams

Dynamic

Use cases, interaction (sequence, collaboration), statecharts, and activities diagrams

Descriptive

Class descriptions and OCL

WORKING WITH UML

43

the problem description represented in the static view. While static information represents "who" will take part of the solution, dynamic information describes "when". However, the symbiosis between static and dynamic views is still not enough to describe all the details developers need. Descriptive artifacts describe some of the concepts that cannot be represented by static and dynamic artifacts or need a better formalization. They are classified as descriptive because, regardless of the formalism, they use basically a textual format to describe the concepts. The class descriptions, which are similar to data dictionaries of conventional methods, are an example of this type of artifact. They contain complementary information about artifacts and the formalization for some of the objects features (e.g., constraints, conditions, assertives) using the object constraint language--OCL [33]. Although all these artifacts can be produced during design, UML does not impose any order or precedence among them. Rather, developers have the freedom to decide the most affordable configuration. Descriptive artifacts are normally used with the other diagrams to support the description of information represented in the different perspectives. The following section shows a design process that can be used to build UML artifacts. Readers can find further information and examples for all of these artifacts in Section 4.

3.

Software Process Activities

A framework for the basic software life-cycle using UML is shown in Fig. 1. The process begins with a set of requirements for a new system and ends when the executable files exist. In between, the process proceeds through a number of activities, represented here by rectangles. The horizontal arrows show the sequence of development activities and curved arrows represent inspections, in which the software artifact being produced during a specific activity is reviewed and potentially improved before the next activity can begin. 2 Throughout the life-cycle, process tracking, management, and quality assurance activities proceed in parallel with development activities, as determined by the project plan. This figure shows the information produced throughout the software life-cycle being stored in a repository, which we recommend to allow for reusing this information. In this section we look in more detail at the process activities involved in the high- and low-level design activities, drawing connections where relevant 2 Although inspections are applicable at many stages of the life-cycle, in this chapter we will concentrate on two phases in particular: requirements and high-level design.

44


I Project ~>[ P.... ss tracking . . . . . " I Perspectivebased reading O b ~ r e a d i n g New ~!::::~

I Requi..... ts I ~ l H idesign g h-level specification

g. . . .

t and quality. . . . . . . . . .

I ~ l .... level[[ ~ ~ design

FIG. 1. The basic software life-cycle.

to the other activities in the life-cycle that influence, or are influenced by, the design.

3.1

Development Activities

Entire books have been written describing development processes that use UML. Some recommended examples are by D'Souza and Wills [25], Eriksson and Penker [34], Douglass [35], and Jacobson et al. [27]. In this chapter, we describe a high-level outline of the process, identifying important design steps and dependencies between artifacts. Our goal is not to provide a complete and definitive life-cycle process, but to enable the reader to understand the various process dependencies in sufficient detail that they can reorganize the activities, if desired, into a development process that suits their environment. Fig. 2 represents the activities within and leading up to high-level design (HLD). Before HLD can begin, a set of requirements, at some level of detail, using some notation, is produced during the requirements phase. We recommend the use of a requirements inspection, before beginning HLD, to ensure that the requirements specified are as correct and complete as possible, and adequately represent the needs of the customer. Although a choice of inspection methods exists, Fig. 2 illustrates the use of PBR, a particular approach to performing requirements inspections in which reviewers produce initial artifacts as they look for requirements defects from different points of view. (PBR is described in more detail in Section 3.2.2.) Using PBR has the advantage of producing an initial set of test cases, which can be used later in the life-cycle, and some information about potential classes, which leads into HLD activities. PBR also produces a representation of system functionalities, which contain important information for HLD. In this example, we have chosen use cases as a functional representation, although other choices are possible. In other environments,

WORKING WITH UML

45

FIG. 2. High-leveldesign activities, using artifacts created during the requirements phase and during PBR requirements inspections.

use cases can be produced without PBR, and indeed may be the only representation used for specifying requirements. H L D activities themselves typically begin with the creation of a first draft of the class diagram. Based on an understanding of the requirements, the designers first identify candidate classes in the design space, i.e., the important real-world entities and their associated behaviors, that should be modeled by the system in order to solve the problem specified in the requirements. Use cases also contain important information for identifying potential classes since they help identify the set of functionality of the system, and the actors and other systems that participate in it. A process such as CRC cards [36] may be used (either as part of the PBR inspections or as a separate design activity) to start the process. It is important not to engage in over-analysis at this point, as classes will almost surely be discarded, added, or modified over time as the domain is better understood. At this step of the design, as in others, the class description is continually changed to reflect changes in the way the classes themselves are defined. The next set of activities (step 2 in Fig. 2) is to construct the interaction and state diagrams, describing in more detail the behavior of the classes (as identified in the class diagram) to achieve the system functionality (as described in the requirements specification and use cases). While accomplishing this, the designer typically gains new insights about the set of necessary classes and their internal structures. Thus a new version of the

46


class diagram is produced (step 3) as the classes are updated with information about their dynamic behavior. As a last step, the class diagram is scrutinized with an eye to implementation. If the diagram is large enough that describing an overall implementation approach is unwieldy, it may be divided into packages that reflect the logical groupings of the system classes, allowing it to be broken into chunks for easier communication and planning. Similarly, activity diagrams may be created, using the use cases to suggest the high-level business processes in the system to provide a more concise overview of system functionality. At the end of HLD, a set of artifacts has been produced (consisting of the class description and class, interaction, and state diagrams, and possibly including package and activity diagrams) that describes the real-world entities from the problem domain. An inspection of the HLD is recommended at this point in the process to ensure that developers have adequately understood the problem before defining the solution. (That is, the emphasis of the inspection should be on high-level comprehension rather than low-level details of the architecture.) Since low-level designs use the same basic diagram set as the high-level design, but adding more detail, reviews of this kind can help ensure that low-level design starts from a highquality base. To provide a concrete discussion of the inspection process, we introduce OORT inspections, described further in Section 3.2.2. Unlike PBR, OORT inspections do not produce new artifacts, but result solely in updated versions of the existing HLD artifacts. These HLD artifacts are further refined in low-level design (LLD), in which details regarding system implementation are added. The first step of LLD is to adjust the set of design artifacts to the implementation domain. It is at this point that classes are introduced into the model that represent entities in the software-based solution but not the real world, such as abstract data types or screen displays. New methods and attributes may be introduced that reflect how objects will communicate with one another in the programming language chosen, not how high-level messages will be exchanged to achieve the solution. A second step is to design the system's specific interfaces, such as user interfaces and database solutions (if necessary). Also at this stage, an approach to task management is defined. Any changes necessary to the system classes in order to use these interfaces are reflected in the class description, which is used as input to the next step, in which all of the design artifacts are updated to be consistent with the new implementation details and interfaces specified. Based on these updated artifacts, a number of final activities are undertaken before coding starts, such as developing a test plan and undertaking coding preparation.

WORKING WITH UML

3.2

47

Quality Assurance and Verification and Validation Activities

Verification and validation (V&V) activities check whether the system being developed can meet the requirements of the customer. To do this, a typical V&V activity focuses on some artifacts produced during the software life-cycle to ascertain if they are correct in themselves (verification) and accurately describe the system that should be produced (validation). V&V activities are often known as "quality assurance" activities since they are concerned with ensuring the quality of the system being developed, either directly by evaluating the system itself, or indirectly by evaluating the quality of the intermediate artifacts used to produce the system [7]. At a high level, there are three types of V&V activities. Measurement activities attempt to assess the quality of a design by assessing certain structural characteristics. The challenge lies in finding appropriate and feasible metrics for the qualities of interest. For example, designers might be interested in evaluating the modifiability of their design, perhaps because several later versions of the system are expected and it would be worthwhile to minimize the effort required for maintenance in each case. A quality attribute such as this one cannot be measured directly, so the designers instead might choose to measure some other attribute that is measurable and yet provides some insight into the ease of making modifications. Using product metrics in this way requires some kind of baseline data or heuristic information, so that the resulting values can be evaluated. Measurement in the U M L / O O paradigm is discussed in Section 3.2.1. In contrast, inspection and testing, two other V&V activities, attempt to ensure software quality by finding defects from various artifacts produced during the life-cycle. Inspection activities require humans to review an artifact and think about whether it is of sufficient quality to support the development of a quality system. There are different types of inspection techniques that represent different strategies for organizing people's roles during the inspections for keeping reviewers focused on the important aspects of the artifact they are inspecting. Inspections are discussed in more detail in Section 3.2.2, in which the discussion is illustrated by two specific inspection approaches: perspective-based reading, which is tailored to inspections of requirements documents, and object oriented reading techniques, which are tailored for OO design inspections. Testing is a V&V activity that is appropriate for evaluating software artifacts for which some dynamic behavior or structural feature can be studied. Testing attempts to understand the quality of the artifact, for instance, by comparing the observed behavior to that which is expected. Typically, testing is applied to code, which can of course be compiled or

48


interpreted and run directly. However, testing can also be applied to other artifacts; for example, requirements and design represented in a formal language can be "run" using simulation and the results studied [37]. In this discussion, we will confine ourselves to discussing code testing and how it can be affected by design decisions. In Section 3.2.3, we will also look briefly at some of the different types of testing techniques that face particular challenges in the O O / U M L paradigm. These different types of V&V activities are not in competition. Rather, some combination is necessary for the production of quality software. Unfortunately, too often development efforts rely entirely on code testing and do not invest in other V&V activities, notably inspections, on artifacts earlier in the life-cycle. Relying exclusively on testing in this way means that defects are not found until the end of the life-cycle, when they are most expensive to fix. Additionally, over-reliance on testing often feeds a tendency of developers to pay less attention to careful design and code production (on the assumption that testing will catch any of the resulting problems). Such an approach can lead to difficulties since it is rarely possible to "test in" quality; low-quality code with multiple patches does not often end up being high-quality code in the end [38]. In contrast, augmenting testing with other V&V activities earlier in the life-cycle means that misconceptions about the system can be caught early. For example, requirements inspections can help identify problems with the way a planned system would address customer needs before an inappropriate design has been created. Design inspections can identify problems with the system architecture or design before significant effort has been invested in coding, which may have to be redone if problems are detected later. Inspections cannot replace testing but are an investment that helps "build-in" quality from the beginning and avoid later rework.

Defects in Software Artifacts Both inspection and testing have the same goal: to find defects in the particular software artifact under review. To get an operational definition of what exactly a "defect" is, we introduce some terms based on the IEEE standard terminology [39]: 9 An error is a defect in the human thought process made while trying to understand given information, to solve problems, or to use methods and tools. In the context of software design, an error is a basic misconception concerning how the system should be designed to meet the needs of a user or customer. 9 A f a u l t is a concrete manifestation of an error within a software artifact. One error may cause several faults and various errors may cause identical faults.

WORKING WITH UML

49

9 A failure is a departure of the operational software system behavior from user expected requirements. A particular failure may be caused by several faults and some faults may never cause a failure. For the sake of convenience, we will use the term defect as a generic term, to refer to a fault or failure. However, it should be clear that when we discuss the defects found by software inspections, we are really referring to faults. A fault in some static artifact, such as a system design, is important insofar as it can lead to a system implementation in which failures occur. Defects found by testing, on the other hand, are always failures of the software that can then be traced back to faults in a software artifact during debugging. When we look for a precise definition of a defect, capable of guiding a V&V activity, we face the problem that what constitutes a defect is largely situation-dependent. For example, if there are strong performance requirements on a system, then any description of the system that might lead to those performance requirements being unfulfilled contains a defect; however, for other systems with fewer performance constraints the same artifacts could be considered perfectly correct. Similarly, the types of defects we are interested in for a textual requirements document could be very different from what we would look for in a graphical design representation. We can avoid this difficulty by identifying broad classes of defects and then instantiating those classes for specific circumstances. For our own work on developing inspection processes, we have found a useful classification that is based on the idea of the software development life-cycle as a series of transformations of a system description to increasingly formal notations. For example, we can think of a set of natural-language requirements as a loose description of a system that is transformed into high- and low-level designs, more formal descriptions of the same basic set of functionality. Eventually these designs are translated into code, which is more formal still, but still describes the same set of functionality (hopefully) as was set forth in the original requirements. So what can go wrong during such transformations? Fig. 3 presents a simplified view of the problem, in which all of the relevant information has to be carried forward from the previous phase into a new form, and has to be specified in such a way that it can be further refined in the next phase. The ideal case is shown by arrow 1, in which a piece of information from the artifact created in the previous phase of development is correctly translated into its new form in the artifact in the current phase. There is, however, the possibility that necessary information is somehow left out of the new artifact (arrow 2) or translated into the new artifact but in an incorrect form (arrow 3). In the current phase artifact, there is always the possibility that

50


Previous development phase

Current

phase

Next phase

~NN

FIG. 3. Representation of various defect types that can occur during software development.

extraneous information has been entered (arrow 4), which could lead to confusion in the further development of the system, or that information has been specified in such a way as to make the document inconsistent with itself (arrow 5). A related possibility is that information has been specified ambiguously, leading to multiple interpretations in the next phase (arrows 6), not all of which may be correct or appropriate. 3 These generic defect classes can be made more specific, to guide V&V activities for various circumstances. Examples of this are given for specific inspections in Section 3.2.2. Table II, summarizes these defect classes. It is important to note that the classes are not orthogonal (i.e., a particular defect could possibly fit into more than one category) but are intended to give an idea of the set of possible defects that can occur.

3.2. 1

Measurement

Software development projects desiring some insight into the product being produced and the process being applied use metrics to measure important information about the project. Many companies have full-scale 3 Of course, Fig. 3 is a simplified view. In reality, many of the implied one-to-one mappings do not hold. There may be multiple artifacts created in each stage of the life-cycle, and the information in a particular phase can influence m a n y aspects of the artifact created in the next phase. For example, one requirement from a requirements specification can impact many components of the system design. When notational differences are taken into account (e.g., textual requirements are translated into a graphical design description) it becomes apparent why performing effective inspections can be such a challenging task.

WORKING WITH U M L

51

TABLE II TYPES OF SOFTWARE DEFECTS, WITH GENERIC DEFINITIONS Defect

General description

Omission

Necessary information about the system has been omitted from the software artifact.

Incorrect fact

Some information in the software artifact contradicts information in the requirements document or the general domain knowledge.

Inconsistency

Information within one part of the software artifact is inconsistent with other information in the software artifact.

Ambiguity

Information within the software artifact is ambiguous, i.e., any of a number of interpretations may be derived that should not be the prerogative of the developer doing the implementation.

Extraneous information

Information is provided that is not needed or used.

measurement programs that operate alongside software development activities, collecting a standard set of metrics across multiple projects to facilitate the tracking of development progress. The most sophisticated of these use some sort of measurement framework to ensure that the metrics being collected are tied directly to the business goals of the company. For example, the GQM paradigm [40] makes explicit the connection between overall goals, specific questions that must be answered to achieve the goals, and the metrics that collect information capable of answering the questions. Developers and project managers have found metrics useful for: 9 evaluating software quality (e.g., by measuring system reliability); 9 understanding the design process (e.g., by measuring how much effort is being spent, and on what activities); 9 identifying product problems (e.g., by identifying overly complex modules in the system); 9 improving solutions (e.g., by understanding the effectiveness of design techniques and how they can be better tailored to the users); and 9 acquiring design knowledge (e.g., by measuring the size of the design being produced). Two of the most often measured attributes of an OO design are coupling and cohesion. Coupling refers to the degree of interdependence between the parts of a design. One class is coupled to another class when methods declared in one class use methods or attributes of the other class. High

52


coupling in a design can indicate an overly complex or poorly constructed design that will likely be hard to understand. This measure can also indicate potential problems with maintenance since changes to a highly coupled class are likely to impact many other classes in the design. Cohesion refers to the internal consistency within parts of the design. Semantically, cohesion is measured by whether there is a logical consistency among the names, methods, and attributes of classes in the design. Syntactically, cohesion can be measured by whether a class has different methods performing different operations on the same set of attributes, which may indicate a certain logical consistency among the methods. A lack of cohesion can also indicate a poorly constructed design since it implies that classes have methods that would not logically be expected to belong to them, indicating that the domain may not have been modeled correctly and pointing to potential maintenance problems [41]. Size metrics are also used often. Projects undertake size measures for a variety of reasons, such as to produce an estimate of the implementation effort that will be necessary [42]. However, no one definitive size metric is possible since each involves some level of abstraction and so may not completely describe all attributes of interest; for example, measuring the number of classes is at best a rough estimate of system size since not all classes are at the same level of complexity. Lorenz and Kidd [43] identified a number of size metrics for requirements, high- and low-level design: 9 Number of scenarios scripts (NSS): counts the number of use cases that are necessary to describe the system. Since this is a measure of functionality it is correlated to the size of the application and, more directly, to the number of test cases that will be necessary. 9 Number of key classes (NKC): counts the number of domain classes in the HLD, giving a rough estimate of the amount of effort necessary to implement the system and the amount of reuse that will be possible. 9 Number of support classes (NSC): counts the number of classes in the LLD, giving rough predictions of implementation effort and reuse. 9 Average number of support classes per key class (ANSC): measures the degree of expansion of the system from H L D to LLD, giving an estimate of how much of the system is necessary for implementationlevel details. 9 Number of subsystems (NSUB): a rough size measure based on larger aggregates of system functionality. 9 Class size (CS): for an individual class, this metric is defined as the total number of operations plus the number of attributes (both including inherited features).

WORKING WITH UML

53

9 Number of operations overridden by a subclass (NO0). 9 Number of operations added by a subclass (NOA). 9 Specialization index (SI): defined as (NOO x level in the hierarchy)/ (total methods in the class). Metrics exist to measure other attributes of designs besides size. Often, these metrics attempt to somehow measure design complexity, on the assumption that more complex designs are harder for human developers to understand and consequently harder to develop and maintain. Perhaps the most well known of these metrics sets was proposed by Chidamber and Kemerer [44]: 9 Weighted methods per class (WMC): measures a class by summing the complexity measures assigned to each of the class's methods, motivated by the idea that the number and complexity of a class's methods are correlated with the effort required to implement that class. Another use of this metric is suggested by the heuristic that classes with large numbers of methods are likely to be more application specific, and hence candidates for reuse. 9 Depth of inheritance (DIT): measures the depth at which a class appears in an inheritance hierarchy. Classes deeper in the hierarchy are likely to inherit a larger number of methods and attributes, making their behavior more difficult to predict. 9 Number of children (NOC): measures the number of subclasses that directly inherit from a given class. A high NOC value typically indicates that a class should be tested more extensively, since such classes may represent a misuse of subclassing, but definitely have an extensive influence on the design. 9 Coupling between objects (CBO): measures the number of other classes to which a class is coupled. Extensive coupling indicates higher complexity (and hence suggests more testing is necessary) but also signals a likely difficulty in reusing the class. 9 Response for a class (RFC): measures the number of methods belonging to the class that can be executed in response to a message. The higher the value, the more complex testing and debugging of that class are likely to be. 9 Lack of cohesion in methods (LCOM): measures the degree to which the methods of a class make use of the same attributes. More overlap among the attributes used is assumed to signal more cohesiveness among the methods. A lack of cohesion increases complexity, increasing the likelihood of development errors, and typically indicates that this class should be split into two or more subclasses.

54


The popularity of the Chidamber and Kemerer metrics for describing designs has led to a few extensions to be proposed, so that the range of measures could be tailored to particular needs. For example, Lie and Henry [45] introduced two new metrics that were useful for the commercial systems (implemented in an OO dialect of Ada) they were studying: 9 Message passing coupling (MPC): calculated as the number of "send" statements defined in a class. 9 Data abstraction coupling (DAC): calculated as the number of abstract data types used in the measured class but defined in another class of the system. And, Basili, Briand, and Melo [46] introduced a version of the Chidamber and Kemerer metrics tailored to C+4-: 9 WMC: redefined so that all methods have complexity 1 (i.e., the metric is a count of the number of methods in a class) and "friend" operators do not count. 9 DIT: measures the number of ancestors of a class. 9 NOC: measures the number of direct descendants for each class. 9 CBO: redefined so that a class is coupled to another if it uses its member functions a n d / o r attributes. 9 RFC: measures the number of functions directly invoked by member functions or operators of a class. 9 LCOM: defined as the number of pairs of member functions without shared instance variables, minus the number of pairs of member functions with shared instance variables. Table III summarizes the metrics discussed in this section and connects them with the life-cycle stages for which they are appropriate.

3.2.2 Inspections Software inspections are a type of V&V activity that can be performed throughout the software life-cycle. Because they rely on human understanding to detect defects, they have the advantage that they can be done as soon as a software work artifact is written and can be used on a variety of different artifacts and notations. Because they are typically done by a team, they are a useful way of passing technical expertise as to good and bad aspects of software artifacts among the participants. And, because they get developers familiar with the idea of reading each other's artifacts, they can lead to more readable artifacts being produced over time. On the other hand, because they rely on human effort, they are affected by nontechnical

WORKING WITH UML

55

TABLE III METRICS DISCUSSED IN THIS CHAPTER FOR EACH PHASE OF THE LIFE-CYCLE Requirements description Lorenz and Kidd NSS NKC NSC ANSC NSUB CS NO0 NOA SI

~

Chidamber and Kemerer WMC DIT NOC CBO RFC LCOM

High-level design

Low-level design

Coding

Testing

~r

~ ,~ ~ ;t

,~ ~ ,~ ~ ;t

X ,~ ;t

• ,~ ~

~r

x x

x

issues: reviewers c a n h a v e different levels o f r e l e v a n t expertise, c a n get b o r e d if a s k e d to review large artifacts, c a n h a v e their o w n feelings a b o u t w h a t is or is n o t i m p o r t a n t , or c a n be affected by political or p e r s o n a l issues. F o r this r e a s o n , t h e r e h a s b e e n a n e m p h a s i s o n d e f i n i n g p r o c e s s e s t h a t p e o p l e c a n use for p e r f o r m i n g effective i n s p e c t i o n s . M o s t o f the c u r r e n t w o r k o n i n s p e c t i o n s owes a large d e b t to the very i n f l u e n t i a l w o r k s o f F a g a n [47] a n d G i l b a n d G r a h a m [48]. In b o t h , the e m p h a s i s is o n the i n s p e c t i o n method, 4 in w h i c h the f o l l o w i n g p h a s e s are identified: 9 P l a n n i n g : In this p h a s e , the scope, artifact, a n d p a r t i c i p a n t s for the i n s p e c t i o n are decided. T h e r e l e v a n t i n f o r m a t i o n a n d m a t e r i a l s are d i s t r i b u t e d to e a c h i n s p e c t o r , a n d their responsibilities are e x p l a i n e d to t h e m , if necessary. 4 In this text we distinguish a "technique" from a "method" as follows: A technique is a series of steps, at some level of detail, that can be followed in sequence to complete a particular task. We use the term "method" as defined in [49], "a management-level description of when and how to apply techniques, which explains not only how to apply a technique, but also under what conditions the technique's application is appropriate."

56


9 Detection: The inspectors review the artifact on their own, identifying defects or other quality issues they encounter. 9 Collection: The inspectors meet as a team to discuss the artifact, and any associated problems they feel may exist. A definitive list of the issues raised by the team is collected and turned over to the author of the artifact. 9 Correction: The author updates the artifact to reflect the concerns raised by the inspection team. The methods do not, however, give any guidelines to the reviewer as to how defects should be found in the detection phase; both assume that the individual review of these documents can already be done effectively. Having been the basis for many of the review processes now in place (e.g., at NASA [50]), Fagan [47a] and Gilb and Graham [48] have inspired the direction of much of the research in this area, which has tended to concentrate on improving the review method. Proposed improvements to Fagan's method often center on the importance and cost of the meeting. For example, researchers have proposed: 9 introducing additional meetings, such as the root cause analysis meeting of Gilb and Graham [48]; 9 eliminating meetings in favor of straightforward data collection [51]. More recent research has tried to understand better the benefits of inspection meetings. Surprisingly, such studies have reported that, while they may have other benefits, inspection meetings do not contribute significantly to the number of defects found [51,52]. That is, team meetings do not appear to provide a significantly more complete list of defects than if the actual meeting had been dispensed with and the union of the individual reviewers' defect lists taken. This line of research suggests that efforts to improve the review technique, that is, the process used by each reviewer to find defects in the first place, could be of benefit. One approach to doing this is provided by software reading techniques. A reading technique is a series of steps for the individual analysis of a software product to achieve the understanding needed for a particular task [49]. Reading techniques increase the effectiveness of individual reviewers by providing guidelines that they can use, during the detection phase of a software inspection, to examine (or "read") a given software document and identify defects. Rather than leave reviewers to their own devices reading techniques attempt to capture knowledge about best practices for defect detection into a procedure that can be followed.

WORKING WITH UML

57

In our work we have defined the following goals for inspection techniques: 9 Systematic: Specific steps of the individual review process should be defined. 9 Focused: Different reviewers should be asked to focus on different aspects of the document, thus having unique (not redundant) responsibilities.

9 Allowing controlled improvement: Based on feedback from reviewers, specific aspects of the technique should be able to be identified and improved. 9 Tailorable: The technique should be customizable to a specific project and/or organization. 9 Allows training: It should be possible to train the reviewers to apply the technique. In this section, we look at reading techniques that directly support the production of quality software designs: PBR, which ensures that the artifacts input to HLD are of high quality, and OORTs, which evaluate the quality of the HLD itself.

A Requirements Inspection Technique: Perspective-Based Reading (PBR) A set of inspection techniques known as perspectivebased reading (PBR) was created for the domain of requirements inspections. PBR is designed to help reviewers answer two important questions about the requirements they are inspecting: 9 How do I know what information in these requirements is important to check? 9 Once I have found the important information, how do I identify defects in that information? PBR exploits the observation that different information in the requirements is more or less important for the different uses of the document. That is, the ultimate purpose of a requirements document is to be used by a number of different people to support tasks throughout the development life-cycle. Conceivably, each of those persons finds different aspects of the requirements important for accomplishing his or her task. If we could ask all of the different people who use the requirements to review it from their own point of view, then we would expect that all together they would have reviewed the whole document (since any information in the document is presumably there to help somebody do his or her job).

58


Thus, in a PBR inspection each reviewer on a team is asked to take the perspective of a specific user of the requirements being reviewed. His or her responsibility is to create a high-level version of the work products that a user of the requirements would have to create as part of his or her normal work activities. For example, in a simple model of the software life-cycle we could expect the requirements document to have three main uses in the software life-cycle: 9 As a description of the needs of the customer: The requirements describe the set of functionality and performance constraints that must be met by the final system. 9 As a basis for the design of the system: The system designer has to create a design that can achieve the functionality described by the requirements, within the allowed constraints. 9 As a point of comparison for system test: The system's test plan has to ensure that the functionality and performance requirements have been correctly implemented. In such an environment, a PBR inspection of the requirements would ensure that each reviewer evaluated the document from one of those perspectives, creating some model of the requirements to help focus their inspection: an enumeration of the functionality described by the requirements, a high-level design of the system, and a test plan for the system, respectively. The objective is not to duplicate work done at other points of the software development process, but to create representations that can be used as a basis for the later creation of more specific work products and that can reveal how well the requirements can support the necessary tasks. Once reviewers have created relevant representations of the requirements, they still need to determine what defects may exist. To facilitate that task, the PBR techniques provide a set of questions tailored to each step of the procedure for creating the representation. As the reviewer goes through the steps of constructing the representation, he or she is asked to answer a series of questions about the work being done. There is one question for every applicable type of defect. (The defect types, tailored specifically to the requirements phase, are given in Table IV.) When the requirements do not provide enough information to answer the questions, this is usually a good indication that they do not provide enough information to support the user of the requirements, either. This situation should lead to one or more defects being reported so that they can be fixed before the requirements need to be used to support that task later in the product life-cycle.

59

WORKING WITH UML TABLE IV

TYPES OF SOFTWARE DEFECTS, WITH SPECIFIC DEFINITIONS FOR THE REQUIREMENTS AND DESIGN Defect

Applied to requirements

Applied to design

Omission

(1) some significant requirement related to functionality, performance, design constraints, attributes or external interface is not included: (2) responses of the software to all realizable classes of input data in all realizable classes of situations is not defined; (3) missing sections of the requirements document: (4) missing labeling and referencing of figures, tables, and diagrams: (5) missing definition of terms and units of measures [53].

One or more design diagrams that should contain some concept from the general requirements or from the requirements document do not contain a representation for that concept.

Incorrect fact

A requirement asserts a fact that cannot be true under the conditions specified for the system.

A design diagram contains a misrepresentation of a concept described in the general requirements or requirements document.

Inconsistency

Two or more requirements are in conflict with one another.

A representation of a concept in one design diagram disagrees with a representation of the same concept in either the same or another design diagram.

Ambiguity

A requirement has multiple interpretations due to multiple terms for the same characteristic, or multiple meanings of a term in a particular context.

A representation of a concept in the design is unclear, and could cause a user of the document (developer, lowlevel designer, etc.) to misinterpret or misunderstand the meaning of the concept.

Extraneous information

Information is provided that is not needed or used.

The design includes information that, while perhaps true, does not apply to this domain and should not be included in the design.

60


More information, including example techniques for the three perspectives identified above, is available at h t t p : / / f c - m d . u m d . e d u / read i no/read

i no. h tm I.

Design Inspection Techniques: Object Oriented Reading Techniques (OORTs) In PBR, reviewers are asked to develop abstractions, from different points of view, of the system described by the requirements because requirements notations do not always facilitate the identification of important information and location of defects by an inspector. For an OO design, in contrast, the abstractions of important information already exist: the information has already been described in a number of separate models or diagrams (e.g., state machines, class diagrams) as discussed at the end of the previous section. However, the information in the abstractions has to be checked for defects, and reading techniques can still supply a benefit by providing a procedure for individual inspection of the different diagrams, although unique properties of the OO paradigm must be addressed. In an object oriented design we have graphical representations of the domain concepts instead of the natural language representation found in the requirements document. Another feature of object oriented designs that has to be accounted for is the fact that while the different documents within the design all represent the system, they present different views of the information. A set of object oriented reading techniques (OORTs) has been developed for this purpose, focused on a particular set of defects that was defined by tailoring the generic defect definitions from Table II to the domain of OO designs (Table IV). For example, the information in the artifact must be compared to the general requirements in order to ensure that the system described by the artifact matches the system that is supposed to be built. Similarly, a reviewer of the artifact must also use general domain knowledge to make sure that the artifact describes a system that is meaningful and can be built. At the same time, irrelevant information from other domains should typically be prevented from appearing in the artifact, since it can only hurt clarity. Any artifact should also be analyzed to make sure that it is self-consistent and clear enough to support only one interpretation of the final system. The PBR techniques for requirements are concerned mainly with checking the correctness of the document itself (making sure the document was internally consistent and clearly expressed, and whether the contents did not contradict any domain knowledge). A major difference in the OORTs is that for checking the correctness of a design, the reading process must be twofold. As in requirements inspection, the correctness and consistency of the design diagrams themselves must of course be verified (through

61

WORKING WITH U M L

"horizontal reading ''5) to ensure a consistent document. But a frame of reference is necessary in order to assess design correctness. Thus it is also necessary to verify the consistency between design artifacts and the system requirements (through "vertical reading"6), to ensure that the system design is correct with respect to the functional requirements. The OORTs consist of a family of techniques in which a separate technique has been defined for each set of diagrams that could usefully be compared against each other. For example, sequence diagrams need to be compared to state machines to detect whether, for a specific object, there are events, constraints, or data (described in the state machine) that could change the way that messages are sent to it (as specified in the sequence diagram). The advantage of this approach is that a project engaged in design inspections can select from this family only the subset of techniques that correspond to the subset of artifacts they are using, or that are particularly important for a given project. The full set of horizontal and vertical reading techniques is defined as illustrated in Fig. 4. Each line between the software artifacts represents a reading technique that has been defined to read one against the other. These techniques have been demonstrated to be feasible and helpful in finding defects [19,54]. More information about the OORTs, including a

Requirements specification

Requirements descriptions r .......

High-level design

-

-

Vert. reading Horz. reading

Class diagrams

Class descriptions

II -U

Use cases r r .......

State machine diagrams

........

Interaction diagrams

(Sequence)

FIG. 4. The set of OORTs (each line represents one technique) that has been defined for various design artifacts.

5 Horizontal reading refers to reading techniques that are used to read documents built in the same software life-cycle phase (see Fig. 4). Consistency among documents is the most important feature here. 6Vertical reading refers to reading techniques that are used to read documents built in different software life-cycle phases (see Fig. 4). Traceability between the phases is the most important feature here.

62


technical report describing how these techniques were defined, is available at h t tp : / / f c - m d . u m d . e d u / r e a d

i no/read

i ng. h tm I.

3.2.3 Testing Testing is a V&V activity that is performed toward the end of the lifecycle (or, more precisely, toward the end of some iteration through the development process), once executable code has been produced. It is a relatively expensive activity; it typically takes great ingenuity to exercise all of the important features of a system under realistic conditions and notice discrepancies from the expected results, not to mention tracing the system failures observed during execution back to the relevant faults in the code. Nevertheless, it remains an essential way of ensuring the quality of the system. Due to this expense, however, exhaustive testing is not feasible in most situations, and so it is important for development projects to have a well thought-out test plan that allocates time and resources in such a way as to provide effective coverage of the system. A number of general testing approaches have been developed and in this section we describe briefly how they map to systems developed using O 0 / U M L and what types of difficulties are introduced by the new paradigm. A test plan is a general document for the entire project that identifies the scope of the testing effort, the general approach to be taken, and a schedule of testing activities. Regardless of the paradigm by which a system has been developed, a good test plan will also include: 9 a test unit specification, listing the modules to be tested and the data used during testing; 9 a listing of the features to be tested (possibly including functionality, performance, and design constraints); 9 the deliverables resulting from the test activities (which might be a list of the test cases used, detailed testing results, a summary report, and/or data about code coverage); 9 personnel allocation, identifying the persons responsible for performing the different activities. Also independent of the development paradigm are the criteria for a good test plan: effectiveness (ideally, it should result in all of the defects in the product being fixed), a lack of redundancy (effort is spent efficiently), completeness (important features of the system are not missed during testing), and the right level of complexity. Planning a system-wide test plan should make use of three different test techniques. These techniques are complementary, meaning that no one

WORKING WITH UML

63

technique covers all the important aspects of a system; rather, effort should be allocated to testing of each type to a greater or lesser degree, depending on how much it meets the needs of the particular system being developed. These three techniques are: 9 Functional (black-box) testing [55]: Test cases are built based on the functionality that has been specified for the system, with the objective of ensuring that the system behaves correctly under all conditions. Because this technique is concerned with the system's behavior, not implementation, approaches developed for other programming paradigms can be used on OO systems without change, such as equivalence partitioning, boundary value analysis, and cause-effect graphing. 9 Structural (white-box) testing [38, 56]: Test cases are built based on the internal structure of the software, with the objective of ensuring that all possible execution paths through the code will produce correct results. The nature of OO programming, in which data flow can be distributed among objects, each of which maintains its own separate state, introduces some complexities which are described below, under "unit testing." Structural testing approaches can be based on control flow, data flow, or program complexity. There is ongoing research as to how these approaches can be adapted to O O / U M L [57] but there are no practical techniques as yet. 9 Defect-based testing: Test cases are built to target likely classes of defects. Approaches include defect seeding (in which a set of defects is seeded into the code before testing begins, to get some idea of the effectiveness of the testing activities), mutation testing for unit testing [58], and interface mutation for integration testing [59]. Although work has been done on identifying useful classes of defects for use in the testing of structured programs, little has been published as to which types of defects are most useful to focus on in OO development. Testing usually proceeds through multiple levels of granularity, and techniques from each of the above types may be applied at each level. Testing may proceed from unit testing, in which individual components of the system are tested in isolation, to integration testing, in which components are tested while working together, to system and acceptance testing, in which the system is tested as an operational whole. Development with O O / U M L does not change testing at the system level, because the goal there is to test functionality independent of the underlying implementation, but does affect testing at other levels: 9 Unit testing: Unit testing is complicated in O O / U M L , first and foremost because it is not generally agreed upon what the "unit"

64


should represent. In structured programming, the unit is generally taken to be a code module, but in O O / U M L it can be a method, a class, or some larger aggregation of classes such as a package. Aside from the matter of notation there are still significant technical difficulties. Inheritance and polymorphism introduce challenges because they allow many execution paths to exist that are not easy to identify from inspecting the class. Additionally, object states cause complications because the different states an object can be in, and how these states affect the responses to messages, must be taken into account during testing. Integration testing: No matter how the "unit" is defined, OO systems will typically have a higher number of components, which need to be integrated earlier in the development cycle, than a non-OO system. On top of that, managing integration testing in U M L / O O can be quite complex since typically a simple calling tree does not exist; objects do not exist statically throughout the life-time of the system but are created and deleted while responding to triggering events. Thus the number of interactions between components will be much higher than it would be for a non-OO system. It is important to remember that, for these reasons, some interaction problems will not be apparent until many objects have been implemented and activated, relatively late in the testing process.

4.

The Example

This section illustrates how developers can use the previously defined design process to build U M L artifacts, by describing the design of an example system. The example explains the development of a hypothetical system for a self-service gas station, from the completion of requirements to the beginning of coding. As we proceed through the example, we define and explain the various types of design diagrams created. The gas station in this example allows customers to purchase gas (selfservice), to pay for maintenance work done on their cars, and to lease parking spots. Some local businesses have billing accounts set up to receive a monthly bill, instead of paying at the time of purchase. There is always a cashier on duty at the gas station to accept cash payments or perform system maintenance, as necessary. The requirements we are concerned with for the purposes of the example are excerpts from the requirements document describing the gas station control system (GSCS), and describe how the system receives payment from the customer. A customer has the option to be billed at the time of purchase,

WORKING WITH UML

65

or to be sent a monthly bill and pay at that time. Customers can always pay via cash or credit card. Table V describes some concepts about this part of the problem. The functional requirements that were defined for the billing part of the gas station system are as follows. As in any other system development, the initial set of requirements obtained from discussion with the customer may contain some errors that could potentially impact system quality. 1. After the purchase of gasoline, the gas pump reports the number of gallons purchased to the GSCS. The GSCS updates the remaining inventory. 2. After the purchase of gasoline, the gas pump reports the dollar amount of the purchase to the GSCS. The maximum value of a purchase is $999.99. The GSCS then causes the gas pump interface to query the customer as to payment type. 2.1. The customer may choose to be billed at the time of purchase, or to be sent a monthly bill. If billing is to be done at time of purchase, the gas pump interface queries the customer as to whether payment will be made by cash or credit card. If the purchase is to be placed on a monthly bill, the gas pump interface instructs the customer to see the cashier. If an invalid or no response is received, the GSCS bills at the time of purchase. 3. If the customer has selected to pay at the time of purchase, he or she can choose to pay by cash or credit card. If the customer selects cash, the gas pump interface instructs the customer to see the cashier. If the customer selects credit card, the gas pump interface instructs the customer to swipe his or her credit card through the credit card reader. If an invalid or no selection is made, the GSCS will default to credit card payment. 4. If payment is to be made by credit card, then the card reader sends the credit card number to the GSCS. If the GSCS receives an invalid card number, then a message is sent to the gas pump interface asking the customer to swipe the card through the card reader again. After the account number is obtained, the account number and purchase price are sent to the credit card system, and the GSCS and gas pump interface are reset to their initial state. The purchase price sent can be up to $10 000. 5. The cashier is responsible for accepting the customer's payment and making change, if necessary. When payment is complete, the cashier indicates this on the cashier's interface. The GSCS and the gas pump interface then return to the initial state.

66

GUILHERME H. TRAVASSOS ETAL. TABLE V GLOSSARY

Concept

Description

Credit card reader

The credit card reader is a separate piece of hardware mounted at each gas pump. The internal operations of the credit card reader, and the communications between the GSCS and the card reader, are outside the scope of this document. When the customer swipes his or her credit card through the card reader, the card reader reads the credit card number and sends it to the GSCS. If the credit card number cannot be read correctly, an invalid token is sent to the GSCS instead.

Credit card system

The credit card system is a separate system, maintained by a credit card company. The internal operations of the credit card system, and the communications between the GSCS and the credit card system, are outside the scope of this document. The GSCS sends a credit card number and purchase amount to the credit card system in order to charge a customer's account; the credit card company later reimburses the gas station for the purchase amount.

Gas pump

The customer uses the gas pump to purchase gas from the gas station. The internal operations of the gas pump, and the communications between the gas pump and the GSCS, are outside the scope of this document. The gas pump is responsible for recognizing when the customer has finished dispensing gas, and for communicating the amount of gas and dollar amount of the purchase to the GSCS at this time.

Gas pump interface

The gas pump interface is a separate piece of hardware mounted at each gas pump. The internal operations of the gas pump interface, and the communications between the gas pump interface and the GSCS, are outside the scope of this document. The gas pump interface receives a message from the GSCS and displays it for use by the customer. The gas pump interface also allows the customer to choose from a number of options, and communicates the option chosen to the GSCS.

Cashier's interface

The cashier's interface is a separate piece of hardware mounted at the cashier's station. The internal operations of the cashier's interface, and the communications between the cashier's interface and the GSCS, are outside the scope of this document. The cashier's interface is capable of displaying information received from the GSCS. The cashier's interface is also able to accept input from the cashier, including numeric data, and communicate it to the GSCS.

Customer

The customer is the client of the gas station. Only registered customers can pay bills monthly. Name, address, telephone number, and account number are the features that will describe a registered customer.

WORKING WITH UML

67

6. If payment is to be made by monthly bill, the purchase price is displayed on the cashier's interface. The cashier selects an option from the cashier's interface, alerting the GSCS that the payment will be placed on a monthly bill. The GSCS then prompts the cashier to enter the billing account number. 6.1. The customer must give the billing account number to the cashier, who then enters it at the cashier's interface. If a valid billing account number is entered, then the billing account number, purchase price, and a brief description of the type of transaction is logged. If an invalid billing account number is entered, an error message is displayed and the cashier is prompted to enter it again. The cashier must also have the option to cancel the operation, in which case the cashier's interface reverts to showing the purchase price and the cashier can again either receive cash or indicate that monthly billing should be used. 7. To pay a monthly bill, the customer must send the payment along with the billing account number. The cashier enters monthly payments by first selecting the appropriate option from the cashier's interface. The GSCS then sends a message to the cashier's interface prompting the cashier to enter the billing account number, the amount remitted, and the type of payment. If any of these pieces of information are not entered or are invalid, payment cannot be processed; an error message will be displayed, and the cashier's interface will be returned to the previous screen. If the type of payment is credit card, the credit card account number must also be entered, and then the paper credit card receipt will be photocopied and stored with the rest of the year's receipts. 8. Unless otherwise specified, if the GSCS receives invalid input it will send an error message to the cashier's interface. The cashier will be expected to take appropriate action, which may involve shutting the system down for maintenance. Performance and extensibility, two nonfunctional requirements [60] that can influence decisions regarding low-level design, were also used: 1. The system must always respond to customer input within five minutes. 2. The system should be easy to extend, so that if necessary another payment option (e.g., bank card) can be added with minimal effort.

4.1

Requirements Activities

The problem description and requirements were generated first. Then, the requirements were inspected to ensure they were of high enough quality to

68


support high-level design and fully represented the functionality needed to build the system. This requirements inspection was done using PBR. For this system we used the customer and tester perspectives because during the inspection we were able to identify defects while producing artifacts capturing the system's functionalities (use cases) and information (test cases) that might be used later for application testing. The use cases in particular were felt to be a useful representation of the system functionality and worth the time required for their creation, since they provide a very understandable format for communication between system designers and the customers. Moreover, use cases feed into later stages of the life-cycle by helping identify objects, develop testing plans, and develop documentation. So, this representation was expected to provide additional benefits for developers as well as to be useful for validating whether the system met the customer's expectations. Applying PBR to the gas station requirements resulted in the identification of some defects. The two perspectives helped the readers find different kinds of defects. First, by using the tester perspective, an omission was found in requirement 5. Domain knowledge indicated that the cashier needs to know the purchase price if he/she is to handle the cash transaction. The tester perspective allowed the reader to see that because all inputs have not been specified, the requirement cannot be tested. Also using the tester perspective, a defect of extraneous information was found in requirement 7. The requirement states that receipts are copied and stored. However, such activity is clearly outside the scope of the system. It cannot be tested for during system test. Using the customer perspective, an incorrect fact was identified in requirement 3. By using domain knowledge the customer recognized that defaulting to credit card payment is an incorrect response. Because this functionality should not have been implemented the way it was described, the defect was categorized as an incorrect fact. Also, the customer perspective helped uncover that requirement 6.1 has an ambiguous description that could result in a number of different implementations. "A brief description of the type of transaction" seems like a reasonable requirement, but exactly what information is stored? What does "transaction type" mean? Purchase of gas/maintenance? Paid in full/partial payment? Paid by credit card/cash/monthly bill? The use cases produced by PBR were the first UML design artifact produced for this project. Figure 5 shows a use case diagram highlighting its components and corresponding description. (There is a wide variation among organizations and even projects as to how formally use cases are specified. In the example system, an English description was used for the system functionality.) The use case diagrams model the system's functionalities by showing descriptive scenarios of how external participants interact

WORKING WITH UML

69

Use case ~-~'~ Actor

~

~

/~

Parking ( ~ ~ ) +_....~z _ . . . S Maintenance

Billing services

Customer ~ Generalization ~

\('~ _~

,~ Credit card administration

Paying monthly bil / k Paying by cash

Paying by credit card Specific use case for "paying monthly bills":

Customer sends payment and account number to the cashier who selects the payment option and must inform the system of the account number, amount remitted, and type of payment. If any of this information is not entered, payment cannot be completed (cashier interface will display a message) and the operation will be cancelled. Types of payments: 1. by cash Cashier informs the system of the account number, and amount paid. 2. by credit card Cashier informs the system of the credit card, amount, and account number. Gas station ask credit card system to authorize payment. If authorization is OK payment is made. If payment is not authorized or failed, cashier receives a message describing that payment was not able to be processed. Cashier must repeat operation once more before canceling the operation. FIG. 5. A use case diagram and the specific description for one of the use cases identified.

with the system, b o t h identifying the events that occur and describing the system responses for these events. Use case d i a g r a m s can also represent relationships (association, extend, generalization, and include) a m o n g use cases or between actors and use cases. An association is the relationship between an actor and a use case. In the figure an example is the line between " c u s t o m e r " and "billing services". An extend relationship shows that one use case is being a u g m e n t e d by the behaviors of a n o t h e r use case. In the

70


figure an example of this is the relationship between '~parking" and "billing services". The generalization shows that one use case is a specialization of another, e.g., "paying monthly bills" in relation to ~paying by cash" while the include relationship shows that an instance of one specific use case will also include the sequence of events specified by another use case. This instantiation of PBR uses the equivalence partitioning technique [8] to read and produce test cases. Test cases help identify defects and provide a starting point for real test cases of the system (so developers don't have to start from scratch at that phase.) For example, the test cases in Table VI were produced for requirement 2. The same approach was used to build the test cases for each requirement and identify defects. When readers finished the requirements inspections, the potential defects were evaluated and fixed in the requirements. At this point, there is a choice as to whether the requirements should be re-inspected, depending on the number of defects and problems that were found. For this system, one inspection was deemed to be sufficient. At the end of this phase, a set of fixed requirements, corresponding test cases and use cases, was available to continue the design process.

4.2

High-Level Design Activities

At this point, all the concepts specified by the requirements have been reviewed and a high-level representation for the functionalities was identified and modeled by the use case diagrams. The next step was to organize those concepts and functionalities using a different paradigm. From this point until the end of integration testing, all the activities were driven by the object oriented paradigm. The main issue was: how problem

TABLE VI Requirement number:

2

Description of input: Valid Equivalent sets: Test cases:

Dollar amount of purchase Valid dollar amounts $100 $13.95 Instruct gas pump interface to query for payment type Negative dollar amounts Dollar amounts >$999.99 -$5.00 $1000.00 Display error at cashier interface

Test result: Invalid Equivalent sets: Test cases: Test result:

WORKING WITH UML

71

features (concepts and functionalities) could be classified and organized to allow developers to design an object oriented solution for the problem. The use cases and requirements descriptions are the basis for the highlevel design activities (see Fig. 2). They represent the domain knowledge necessary to describe the features and make them understandable to the development team. The static and dynamic properties of the system need to be modeled. Moreover, use cases and requirements descriptions are used in design inspection because they represent the truth about the problem, and allow the solution space to be limited for the developers. As we stated in Section 3, UML artifacts can be built in any order. Developers can tailor a development process to fit their needs. In our example development process, a draft class diagram was produced first in order to explore the organization of the domain concepts. Class descriptions were produced and enhanced through all the design activities, regardless of the type of artifact being built. Therefore, a first draft for the class description was also produced. Subsequent activities refined the class diagram and described the functionalities that had to be part of the solution. Doing so, developers explored a design perspective focused on the domain concepts rather than just the functionalities of the system. We have observed that the use of such an approach drives designers to model essential domain elements, independent of the solution, and being more suitable for future reuse. This initial picture of the basic elements of the problem gave designers the ability to model the functionalities and understand how external events impact the life-cycle of the objects and system. It was also possible to identify the different chunks of the problem, allowing the identification of different classes packages. Classes were grouped into packages by their structure or type of services they offered. By doing so, developers got some information that was used to improve the definition of the application architecture, for instance, grouping all classes that contain interfaces for external systems into one package. Next, the dynamic behavior of the system was modeled by creating the sequence and state diagrams. Using this information, the class diagram was then refined. All along the way, the class descriptions were updated to be consistent with the information in the other diagrams. Finally the package and activity diagrams were created. Each of these will be explained in more detail below. Once UML design artifacts are built, developers can apply inspections to verify their consistency and then validate them against the requirements and use cases used to define the problem. Object oriented reading techniques (OORTs) were used to support inspections of UML high-level design artifacts in the context of this design process.

72


After finding and fixing high-level design defects, which sometimes can imply some modifications in the requirements and use cases, developers had a complete set of quality design artifacts representing the framework to be used for continuing design. The next steps included dealing with low-level issues, such as decisions regarding support classes, persistence and user interface, and also restrictions imposed by the implementation environment. The models produced guided coding and testing activities. The following sections describe this process step by step, showing the artifacts that were produced and how inspections were applied to ensure quality and reduce the number of design defects.

4.2.1

Step I: Class Diagrams and Class Descriptions

Using the repaired requirements descriptions and use cases, the designers needed to identify and extract the different domain features that would compose the design model. At this point, there is always a choice of approaches for how to proceed. One option for developers is to apply an organized and systematic technique to capture such features. A first draft of the models is produced using linguistics instruments to identify the semantics and syntactics involved in such documents [61]. Another option is to use a more relaxed approach, where some linguistics issues are considered but without the level of detail or formalization [9]. In this example, designers used the Rumbaugh approach to look for nouns, verbs, and adjectives used in the requirements and use cases to get a first idea about the classes, attributes, and specific actions. Identifying the nouns gave designers initial candidates for the system classes. The class diagram was then created to model this initial class structure. This diagram captures the vocabulary of the problem. It defines the concepts from the domain that must be part of the solution and shows how they are related. The expected result is a model of the system information with all the features (attributes and behaviors) anchored to the right classes. These features delimit the objects' interface, acting like a contract for the class [6]. By identifying the actions for each object type and the visibility of those objects, the class diagram clearly defines how objects can communicate. Figure 6 shows an example of the initial class diagram for the gas station control system. 7 Identifications of the basic diagram elements were inserted to show some of the different types of information that can be modeled, such as 7The complete set of artifacts for this system, including requirements descriptions, can be found in httpz//www, cs.umd.edu/projects/SoftEng/ESEG.

WORKING

I

Services I IDiscount Rate:fl0at /

B e h a vi o rs -....-.....,..~ I lpric2!_!!"~

~-----------d,

~,

'~

/

,

I I I' !0::!. , I Parkin~l Spot Min_Quantity = 100 II ....... ~-v, Current_Quantity :float I | .......... IPrice : float = 1.09 i I--

ll

Gas ............

.

.

.

.

.

.

.

I I I I

Association /

~ I1

~

'-,,

#

/Class

I Purchase I 1..*~Purchase-Date : datel ~,

~ - - !

I 1

t_____J 1

I

i

Multiplicity

'\

name Attributes

..I

i RegisteredCust~ I I name: text I laddress:text I I Account_number: number ! IPhone_number: long I t "' /~,/ 0 / '

I Bi, I I Issue_Date : Date I I Payment Date: Date I l amount_paid: float I I "0 !

l t[~ ...... _:~1 t Gas- Ordenng inventory t 9 Parts_Ordenn ' System II. "1I inventory " ,q System p

/

I 1 I 0..* / ! pia i / I rt I / IPart- Code: long I / I Discount Rate float 9 I / I -" i /1..*

% /,I" I Product I I Min Quantity :int I I Current_auantity: float I I Price : flOat I

Aggregationl pnceO ;.

73

UML

I Parking II Car Maintenance] I IPrice I :float 1' =r 5.00 I I Price_float__ '""0 * 15010 '

0"*1

........-I" ...... Inher ......

WITH

O*

1" I Messagel I Text'"text I I " I " '~ ~k.

/i er,c_essa0esi I

I

Warnin,q Letters Delivery_date: date

FIG. 6. An example of a U M L class diagram.

classes, aggregations, associations, and simple inheritance. Classes (representing the object types) and their static relationships are the basic information represented by class diagrams. A class representation has a name, encapsulated attributes, and behaviors, together with their restrictions (constraints). The main static relationships for classes are subtype (e.g., Gas is a Product) and associations, which can be expanded to acquaintances (e.g., a Registered Customer makes a Purchase), aggregation (Inventory consists o f Products) and composition (e.g., a Purchase is part of a Bill). Subclasses (subtypes) are modeled by specialization. An inheritance mechanism asserts that a subclass inherits all the features from the superclass. This means that all the attributes (data structures), behaviors (services), and relationships described in one class (superclass) are immediately available for its subclasses. Single (one superclass) and multiple (more than one superclass) inheritances are both possible. In the example, because the class "Parking" is a subclass of "Services", it contains the attribute "Discount_Rate" and it also receives the ability to communication with the "Purchases" class. Abstract classes are used to improve the model by clarifying the classification and organization of the classes. However, abstract classes cannot be instantiated.

74


Associations represent the relationships among instances of a class (e.g., a Registered Customer makes a Purchase), but conceptually are shown as relationships among classes. Roles and the number of objects that take part in the relationship (association multiplicity) can be assigned for each side of the relationship. A Registered Customer can make 0 or more purchases, but each purchase can be made by only one customer. Relationships can also be used to represent the navigability perspectives (e.g., to give an idea about which object is the client) and specify the visibility to the objects. At this point in the design process, designers realized that the reasons behind their decision to create a Registered Customer class may be lost if more information about this class and its attributes was not captured. As a result, the class description was created and more information was inserted. This included the meaning of the class as well as behavior specifications and details about relationships and multiplicity. This could also include the constraints and restriction formalization using the object constraint language (OCL), specification of interfaces and communications such as defined by the CORBA standard and also the U M L models mapping to X M L provided by the XMI specifications [14]. Figure 7 shows the class description example generated for the Registered Customer class. Words in bold represent the template fields used on this project. Words in italic are types for the attributes. There is one description like this for each class in the class diagram.

Class name: Registered Customer Documentation: The customer is the client of the gas station. Only registered customer can pay bills monthly. External Documents defining the class: Glossary Cardinality: n Superclasses: none Interface: Attributes: Name: text. It represents the name of a customer. First + last name is the normal way that a name is represented address: text. This is the mail address for the customer. An address should be described using the following format: 1999 The Road Ave. apt. 101 Gas Station City--State--Zip Code account number: long: Customer account number is the numeric identification of the customer in the context of the gas station control system phone number: long: a phone number to the customer: (area code)-prefix-number Operations: none

FIG. 7. An example of a class description.

WORKING WITH UML

75

The class description artifact complements the information described by the other diagrams. It holds detailed descriptions for classes, attributes, behaviors, associations, and consequently all other important characteristics that need to be described but cannot be done by other diagrams. It acts as a data dictionary and it is not formally defined by the UML standard, because it is an implicit document produced during design. Because there is no standard template for this artifact, one can be derived directly from the diagrams to ensure consistency. The class description evolves throughout the design process and at the end must hold all the information necessary to begin low-level design.

4.2.2 Step 2: Interaction and State Diagrams At this point, developers already had a better view of the problem. They modeled the use cases and produced a first class diagram. The class diagram does not show how the behaviors can be put together to accomplish the functionality. Most behaviors are the basic functions for the classes. So, designers needed to understand the functionalities that are required and how to combine the behaviors to accomplish them. The relationships on the class diagram specify only which objects are related to one another, not the specific behavior or message exchanged between them. To continue development, it was necessary to show how information should flow among the objects, represented by the sequence of messages and the data they carry. The use cases contained the information the developers needed to describe system functionality. However, they described functionalities and events using an informal notation. They do not clearly represent how objects interact and which messages are exchanged, but merely describe the different scenarios. Aside from functionality, conditions and constraints are also described by use cases, and more explicitly, by the requirements descriptions. A condition describes what must be true for the functionality to be executed. A constraint must always be true regardless of the system functionality. Interaction diagrams met the needs of developers at this point because they represent system functionalities more formally. These diagrams model the use case scenarios including their conditions and constraints. Basically, interaction diagrams provide a way of showing which messages are exchanged between objects to accomplish the services and functionalities of the system. Typically, each use case has one associated interaction diagram. However, for complex use cases more than one interaction diagram can exist, breaking down the use case complexity while capturing the messages and services necessary to represent the whole functionality.

76


There are two forms of interaction diagrams: sequence and collaboration. Sequence diagrams show the flow of messages between objects arranged in chronological order. Normally, an actor or an event initiates a messages sequence. Some designers suggest that sequence diagrams are the best form of interaction diagrams to be used when modeling real-time specifications or complex scenarios [14]. Figure 8 shows an example of a sequence diagram for the scenario (pay by cash) represented in Fig. 5. Object life-lines, a box at the top of a dashed vertical line, represent objects. An object life-line holds all interactions over time in which the object participates to achieve a particular functionality. An object that shows up in different sequence diagrams has different lifelines, one for each sequence diagram. For example "Bill" could show up in this sequence diagram as well as "Paying by Credit Card". An arrow between object life-lines is a message, or stimulus (labeled with at least a name). An example is "get_bill()", where the origin is "Registered Customer" and the receiver is "Gas Station". Each message is usually associated with one behavior encapsulated by the receiving object's class. Additional modeling situations that can be captured include: Self-delegation (an object sends a message to itself such as IsClientRegistered(account number)), condition (to indicate conditions that must be observed to send or receive a specific message, such as [information is OK]), and iteration marker (that indicates a message can be sent several times to multiple i "Registered . Customer

" II Cashier-terminal

Gas 9 Station I

I

BillBill

]

pay_molethlybycash(accountn~unber, amount) / monthlybill_cash(a~~nt number, amount)

IsClientRegistered (account number)

I get_bill( )

update_bill

mount, payment date

1display_message(text) -

Object's life-line

I I;~176

I[inlormationis OKI Time

FIG. 8. An example of a sequence diagram.

WORKINGWITHUML

77

receiver objects). The order of messages in the sequence is represented by their position on the object life-line, beginning at the top. Collaboration diagrams are a combination of sequence diagrams with object diagrams and display the flow of events (usually associated with messages) between objects. They show the relationships among the objects and the different roles that objects play in the relationships. Figure 9 displays the collaboration diagram for the sequence diagram of Fig. 8. Objects, in this case, are represented as a box, for example "Gas Station". The arrows indicate the messages (events) sent within the given use case, for example "display_message(text)". Message order is shown by numbers instead of by position as used in sequence diagrams. So, "l:pay_monthlybycash" is followed by "2:monthlybill_cash", and so on. Interaction diagrams are adequate for capturing the collaboration among objects. Regardless of the form used, designers can see which objects and messages are used to capture the functionalities of the system. However, functionalities are represented in an isolated manner. By this we mean that this describes each scenario without considering the others. But, some systems are heavily affected by external events. For these systems, some classes have very dynamic instances. This dynamism occurs because of the changing states of the objects due to external events. The designers of this system decided that this system fell into this class. Because of this the designers found it difficult to understand each specific class by itself. Because the object states can impose constraints on the use of the object, they can affect the functionality of the system. In these cases, modeling of the different situations that change the state of the object is worthwhile. This model helps identify the events and the actions that cause state changes. It

3:IsClientRegistered(account number) f

l .m~8~8 6:display_message(text)"Cashier] Statior

terminal-I

i ~ 2:monthlybil_cash(ac'onumber, unt amount) 5:update_bil(amount, paym"~qtdate) ~i i~ "" 4 ~ men!hI'bycash(account number'am~ ! "Bill " : BIllI

I :~Reglstered FIG. 9. A collaboration diagram.

78

GUILHERMEH. TRAVASSOSETAL.

supports the comprehension of an object's life-cycle and specification of the constraints that will drive objects to be in a consistent state. The designers decided that this was necessary information for this system. So they created the U M L diagram that captures the states of an object and its events, called a statechart [62]. Figure 10 shows a statechart for the inventory class. This diagram describes the basic state information about the states themselves (the cumulative results of the object behavior, or the collection of attributes value for a specific instance, for instance "ordering gas" and "ordering parts") and transitions (a system event, or external occurrence that induces a system or object state change, for instance "gas delivery" or "parts delivery"). Actions can also be associated with states. Doing so, designers can specify which action is triggered when the object reaches a specific state, keeps the current state, or leaves the current state. For example, when the state "low gas" is reached the action of "order gas" should be triggered. Constraints (guards) are normally associated with transitions, showing when objects can change from one state to another. In this case, when the quantity is less than some minimum value, the "low gas" state is entered. Additionally, nesting can break down inherently complex states when necessary. It is common to find projects that do not make use of state diagrams. However, when these diagrams are used, their combination with interaction diagrams represent a way to identify testing scenarios and prepare complementary test cases for the system [63, 64].

4.2.3 Step 3: Refining Class Diagrams At this point, designers have a first draft for most of the diagrams and specifications for the functionalities. However, the models are not completely defined and specified since typically additional services or

~~ /(~ Finalstate

Initial state Event

State

.... ,ow,as L lowgas r oor a, s,oc 1 low arts Z ,ow 1 ,r,, j -L J [quantity[ Requi . . . . . ts [__[Hi~h-level I [ : ~ " [ specificat,on I I ae~;gn

ILow-level ]l_____%lCodingand

i==~ld~l~,, I---" Ite~t'ng

I's~urcecode]0

Ic::::~

IPBR ......................... cust . . . . ~" ................................... I ~O vertical reading I | ' ~........................................................ " ~ . . . . . ~ ..........................]r ......................... | ~" iperspectwe fo. . . . IvmgIIfo . . . . lvmg it 9 Integrat,on mismatches Idennficatlon I N~ .... I_ .............. _1.......... [iRequi . . . . . ts I I High-level lid.... iptions I Idesign artifacts [ _[2"2"~'"~_ ___ _..... ~

t ........... t .......... I I Lou,-level I 1' I Idesign artifacts I ~ ~ .

] ......

[

,Ill " " " -] Artifacts. ] obiectfiles, [ .- "" " k,,,~es

FIG. 16. Inserting maintenance activities in the software process.

I I

88


activities have been added to take into account the reusable assets when developing the new or evolved system. Before a developer can decide whether or not to use any of the reusable assets, they must first understand those assets. We have found that the U M L diagrams can be very useful in this process of understanding.

5.2

Understanding

As stated earlier, the goal of the understanding activities is to support the comprehension of the reusable assets. In order for a developer to effectively use the existing requirements or design, s/he must first understand the artifacts themselves, as well as what needs to be done. These understanding activities are important to developers because they allow for the identification of the important pieces from the set of reusable assets that can be (re)used for the new system. Understanding activities should be used for three tasks within the software life-cycle: (1) to understand the old requirements, (2) to understand the old design; and (3) to determine what the integration mismatches are. When a developer is evolving or maintaining a system, in general there will be more requirements retained from the old system than new ones added. Because of this, it makes sense to reuse as much of the existing requirements as possible. But before a developer can effectively reuse those requirements they must be understood. When examining the old requirements, developers strive to understand which domain level concepts are present in or absent from those requirements in the context of the new requirements that have been received. The main goal here is to determine, on a high level, if the old set of requirements is in conflict with the new requirements, or if the old requirements can simply be modified to include the new requirements. If the developer can efficiently reuse the existing requirements, it could have a positive effect on the cost and effort of the new system. Likewise, once the developers have created the new set of requirements, they must examine the existing design with the goal in mind of understanding that design. When developers examine the old design, they need to determine if the way that the domain was represented will allow the new requirements to be added. The old design must be understood from the point of view of whether the earlier design decisions conflict with a newly added requirement, or if the old design allows itself to be modified to include the new requirements. By reading the old design for understanding, the developers acquire enough knowledge to create a design for the new system, reusing as much of the old design as possible. Again, if this reuse is efficient, it could have a positive effect on the cost, effort, and complexity of the new system.

WORKING WITH UML

89

Integration mismatches are a way to describe problems that may be encountered when using commercial off-the-shelf software (COTS). In this case, the reusable assets can be viewed as a COTS. Therefore, the developers must determine if the new design and the reusable assets are compatible. For a more complete discussion of this topic see Yakimovitch et al. [70]. Although these types of understanding activities exist in most software life-cycles, developers traditionally have accomplished them with little or no guidance. This means that the developers normally examine the artifacts in an ad hoc fashion and try to identify the features which they consider to be important. From earlier research, we have seen that, in general, developers tend to be more effective at performing an inspection or reading task when using a technique rather than doing it in an unguided fashion. The reason for this is that the techniques help the reader to better focus on the task at hand, and accomplish the important steps necessary for its successful completion. Earlier in this text we mentioned two techniques, PBR and OORTs, that were designed for use in the process of defect detection. These techniques were defined to be useful with the U M L artifacts. As we began to look more closely at this issue and re-examine the techniques, we became aware that those techniques appeared, with slight modifications, to allow the developers to understand the document(s) being inspected, rather than to find defects in the document. In the following sections we will discuss how PBR and OORTs can be used in the process of understanding for evolving a system.

5.2. 1

PBR

The necessary starting point in this process is the requirements. This is because the requirements determine, at the highest level, what pieces of the reusable assets can be reused in the new system. When developing the next version of a system, two important artifacts are present: (1) the set of requirements describing what is to be added to the system, and (2) the requirements and use cases from the existing reusable assets. To begin determining how much of the reusable assets can be reused, the developer must examine these two sets of requirements and use cases to find out where potential discrepancies lie. This examination can be done by reading the documents. This reading is usually performed in some ad hoc manner. The perspective-based reading techniques that were discussed in Section 4.1 for examining a new set of requirements can also be used in this understanding process. A developer can take the new set of requirements and read these against the requirements

90


and use cases from the set of reusable assets to determine where the discrepancies lie. The goal of this is to come up with a new set of requirements that contains both the old and the new requirements. Here only the customer perspective of PBR is used. This is because the type of information that is gathered by this perspective most closely resembles the type of information that is necessary to evolve the requirements. The main task of the reader here is to determine what has to be "fixed" or changed so that the new requirement can be added to the existing system. There are many situations that the reader is looking for. Using the PBR's customer perspective, the reader first examines the participants. It must be determined whether the participants in the new system are the same as those in the old system. For example, new participants may need to be added, names of participants may need to be changed for consistency, or the way that a participant interacts with the system may change. The next thing that readers look at is product functionality. The reader will examine the existing use cases to determine if they cover the new functionality. If they do not, then either new use cases must be created, or the old use cases must be modified to handle the new functionality. The reader also needs to determine if the relationships between the participants, discussed above, and these product functions remain the same in the new system, or if changes must be made. The result of this process is a list of these discrepancies that aids the developers in integrating the new requirements and the set of requirements taken from the reusable assets.

5.2.200RT Once a developer has come up with a new set of requirements describing the new system, the next step is to create a design for this system. Again, this is typically done in some sort of ad hoc fashion. Here developers are interested in doing similar tasks to what was accomplished in the requirements phase. Now that a set of requirements has been created that includes the new requirements, the UML design documents from the set of reusable assets must be read against this set of requirements to determine where the discrepancies lie. When we speak of discrepancies here, we are referring, at an abstract level, to the information gap between the old and the new system. This may include the fact that new classes must be added to the design to support the new requirements; or, new attributes and behaviors may need to be added to existing classes to support the new functionality. The way that classes interact and pass messages may also need to be changed to support the structure of the new system.

WORKING WITH UML

91

The object oriented reading techniques, and more specifically, the vertical reading techniques discussed in Section 3.2.2, are well suited for this task. The reason that vertical reading can be used here is that when performing vertical reading, a reader examines a set of requirements against the U M L diagrams of a design. The main difference that arises when these techniques are used to understand the reusable assets is that the reader is looking for discrepancies between the new requirements and the reusable assets. At this point, the reader is not looking for defects, because the requirements and the design are describing two different systems. Rather, the reader is trying to determine what parts of the old design are inconsistent with the new requirements. Once this is determined, the designer can create the design for the new system by using as much of this old design as possible and augmenting or changing where necessary as dictated by the discrepancies. 5.3

Example

In this section, we will show how the process described above can be used to extend the example problem presented in Section 4. For the purposes of this example, assume that the gas station owner has decided that he now wishes to allow his customers to pay their monthly bills by credit card via the Internet as well as via mail. The new requirement can be seen in Fig. 17. The first step in creating the evolved system is to apply PBR in order to determine how the set of reusable assets (the old set of gas station requirements) can be used in conjunction with this new requirement. When PBR is applied, it was determined that the new requirement only requires a minor change to the reusable assets. We found that there is already a requirement that allows for the payment of monthly bills using a credit card. The old system only allowed this payment to be made by mail. So, the new requirement does not change the system, it only extends some functionality that is already present. To include the new requirement in the system we can

Monthly bill payments will now be accepted using a credit card over the Internet. The customer must access the gas station homepage. The customer will log in using his account number and password. The password is assigned by the gas station at the time of account creation. The customer is presented with the amount of his current bill. The customer then enters the amount they wish to pay and their credit card information. The credit card information is verified by the system. If verification succeeds, the bill is updated in the system. If it fails, the customer is presented with the reason for failure, and given a chance to try again.

FIG. 17. New gas station requirement.

92


Parking

~

~

Cashier/ Paying monthly A bills~

Paying by cash

rt~~

/

L~

Paying by credit card

Paying by mail

Paying over Internet

Specific use case for "Paying by Credit Card": Types of credit card payments:

1. Paying by mail Customer sends payment and account number to the cashier. Cashier selects the payment option and enters account number, amount remitted, and type of payment. If any of this information is not entered, payment cannot be completed (cashier interface will display a message) and the operation will be cancelled. Gas station asks credit card system to authorize payment. If authorization is OK payment is made. If payment is not authorized or failed, the cashier receives a message describing that payment was not able to be processed. The cashier must repeat the operation once more before canceling the operation. 2. Paying over the Internet Customer logs on to the homepage and enters account number and password. System prompts with bill amount. Customer enters amount to pay and credit card information. Gas station asks credit card system to authorize payment. If authorization is OK, payment is made. If authorization fails, the customer receives a message describing that payment could not be made. Customer may try one more time or cancel the operation. FIG. 18. E v o l v e d use cases.

WORKING

WITH

UML

93

leave a majority of the requirements unchanged and just add the new functionality. To do this, requirement 7 is the only one that has to change. In Fig. 18, it has been split into two parts, one dealing with payments by mail (l) and the other dealing with payments over the Internet (2). The next step is to examine the use cases to determine if modifications are necessary. Because a use case for paying monthly bills by credit card already exists, we can split that use case into two subcases: one for payment by mail, and one for payment on the Internet. The new use cases can be seen in Fig. 18. N o w that we have the evolved requirements and use cases, the next step is to modify the design so that it includes the new requirements. When applying O O R T s we determined that the only change to the class diagram that was needed was to add a new class to model the homepage. We also determined that a new sequence diagram was needed to model the new use case of "Payment over Internet". These new diagrams can been seen in Figs 19 and 20 respectively.

IDiscounts ...... Rate.

' '

I

I e ue I IGall~ : float I Ipdce0:fl~ I I1 Gas IMin_Quantlty = 100 Ic ....... Q..... ty:float

IPrice'fl . . . . !

1.09

\ I

II

float

I

I 1

prtceO'float .

~

0* pitar

I1' II I IPart Code : long I I D....... R. . . . float

II

I

/

/

o

ICurro~a.uantity:,oat ir-,,t.u. ,,ud~

i a eRte~Je,:teredC....... I:ddress ~ext

I

I'"

I I

/ o /

Gas S..... IN....... I Cod. . . . . ber I I ie ffuU:ll()clarge0 t0

/ Jget_CC .... ber() 1 *ilk ..~monthlyblll cash() / ' I....... b...... ed.... dO , 'v I' ...... ry[ ],sC,ientReg..... ed0 i OrdergaSu i lunt'UedO 1/I ~ ........... p.... 0

i

/,

'1

I

C M + 3 x SD, and CMI>0 R < C M - 3 x SD, and CM ~CM + 3 x SD = 1.563. Applying the highly unstable (HU) criterion, there is no M T T F < C M - 3 x SD = -1.683. Thus there are no critical transitions for M T T F . Similarly, HS for total f a i l u r e s / K L O C - 1 . 4 1 3 and H U - - 1 . 2 3 9 and there are no critical transitions. The large variability in CM is the case in this application due to the large variability in functionality across releases. Furthermore, it is not our objective to judge the process that is used in this example. Rather, our purpose in showing these and subsequent values of CM is to illustrate our model. We use these plots and the CM to assess the long-term stability of the maintenance process. We show example computations of CM for equations (1) and (2) in Table II.

7. 1.3

Total Test Time

We want total test time, normalized by K L O C change in code, as computed by equation (3), to show a decreasing trend across releases, indicating that test effort is decreasing with respect to code changes. Total test time

Total test time

KLOC

K L O C change in code on the OI

(3)

166

NORMAN

F. S C H N E I D E W I N D

TABLE II EXAMPLE COMPUTATIONS OF CHANGE METRIC (CM) Operational increment

A B C D E J O

MTTF ( day s)

Relative change

Total fail ures / K L OC

Relative change

179.7 409.6 406.0 192.3 374.6 73.6 68.8 CM

0.562 -0.007 -0.527 0.487 -0.805 -0.068 -0.060

0.750 0.877 1.695 0.984 0.568 0.238 0.330 CM

-0.145 -0.483 0.419 0.423 0.581 -0.272 0.087

We plot equation (3) in Fig. 3 against release time of OI, using actual values. The CM value for this plot is 0.116, with a standard deviation of 0.626, indicating 11.6% stability with respect to efficiency of test effort. HS = 1.994 and HU = - 1 . 7 6 2 and there are no critical transitions. We use this plot and the CM to assess whether testing is efficient with respect to the amount of code that has been changed.

7.2 7.2. 1

Reliability Predictions

Total Failures

Up to this point, we have used only actual data in the analysis. Now we expand the analysis to use both predictions and actual data but only for the 700

to 0 0 .._1

"o "~

600

500

4oo 300

200

~

loo

0

0

34

93

132

175

276

452614

70

81692110551185130414561545167.1

Months since release

OIA

B

C

D

E

F

G

H

1

J

of first OI

K

L

M

N

O

FIG. 3. Total test time per KLOC across releases.

P

Q

MAINTENANCE PROCESS AND PRODUCT EVALUATION

167

seven OIs where we could make predictions. Using the Schneidewind model described in American Institute of Aeronautics and Astronautics [15, 1720] and the S M E R F S software reliability tool developed by Farr and Smith [21], we show prediction equations, using 30 day time intervals, and make predictions for OIA, OIB, OIC, OID, OIE, OIJ, and OIO. This model or any other applicable model may be used as described in American Institute of Aeronautics and Astronautics [17] and Farr and Smith [21]. To predict total failures in the range [1,4] (i.e., failures over the life of the software), we use equation (4): ct F(cx;) =--'[-

Xs_ 1

(4)

where the terms are defined as follows: s:

starting time interval for using failure counts for computing parameters c~ and/3; c~: initial failure rate; /3: rate of change of failure rate; and Xs_ 1: observed failure count in the range [1, s - 1]. Now, we predict total failures normalized by K L O C change in code. We want predicted normalized total failures to show a decreasing trend across releases. We computed a CM value for this data of 0.115, with a standard deviation of 0.271, indicating 11.5% stability with respect to predicted normalized total failures. HS = 0.928 and H U - -0.698 and there are no critical transitions.

7.2.2 Remaining Failures To predict remaining failures r(t) at time t, we use equation (5) as described in American Institute of Aeronautics and Astronautics [17], Keller [18], and Schneidewind [20]: ,'(0 = F ( e c ) - X,

(5)

This is the predicted total failures over the life of the software minus the observed failure count at time t. We predict remaining failures, normalize them by K L O C change in code, and compare them with normalized actual remaining failures for seven OIs in Fig. 4. We approximate actual remaining failures at time t by subtracting the observed failure count at time t from the observed total failure count at time T, where T>> t. The reason for this approach is that we are approximating the failure count over the life of the software by using the

168

NORMAN

F. S C H N E I D E W I N D

failure count at time T. We want equation (5) and actual remaining failures, normalized by K L O C change in code, to show a decreasing trend over a sequence of releases. The CM values for these plots are 0.107 and 0.277, respectively, indicating 10.7% and 27.7% stability, respectively, with respect to remaining failures. The corresponding standard deviations are 0.617 and 0.715. HS = 1.958 and H U - - 1 . 7 4 4 for predicted remaining failures and there are no critical transitions. In addition, HS - 2.422 and HU = -1.868 for actual remaining failures and there are no critical transitions.

7.2.3

Time to Next Failure

To predict the time for the next FI failures to occur, when the current time is t, we use equation (6):

TF(t)---- log /3

o~ -/3(X,.. I + F,)

-- ( t - s + 1)

(from American Institute of Aeronautics and Astronautics The terms in TF(t) have the following definitions: t 9

Xs.

F,:

t 9

(6)

[17]1, 17, 18).

current time interval; observed failure c o u n t in the range [s, t]; and given number of failures to occur after interval t (e.g., one failure).

r-]

Predicted

0

3.4

OIA

B

~

Actual

m 0.8 m "-I C::

0.6

E -a 0.4

0

z 0.2

9.27 13.17 17.5 Months since release of first OI C

D

E

81.6

145.6

J

O

FIG. 4. Reliability of maintained software--remaining failures normalized by change to code.

MAINTENANCE PROCESS A N D PRODUCT EVALUATION

169

We want equation (6) to show an increasing trend over a sequence of releases. Predicted and actual values are plotted for six OIs (OIO has no failures) in Fig. 5. The CM values for these plots are -0.152 and -0.065, respectively, indicating 15.2% and 6.5% instability, respectively, with respect to time to next failure. The corresponding standard deviations are 0.693 and 0.630. HS = 1.927 and HU = -2.231 for predicted time to next failure and there are no critical transitions. In addition, HS = 1.825 and H U - - - 1 . 9 5 5 for actual time to next failure and there are no critical transitions. We predicted values of total failures, remaining failures, and time to next failure as indicators of the risk of operating software in the future: is the predicted future reliability of software an acceptable risk? The risk to the mission may or may be not be acceptable. If the latter, we take action to improve the maintained product or the maintenance process. We use actual values to measure the reliability of software and the risk of deploying it resulting from maintenance actions.

7.3

Summary

We summarize change metric values in Table III. The overall (i.e., average CM) value indicates 7.1% stability. If the majority of the results and the average CM were negative, this would be an alert to investigate the cause. The results could be caused by: (1) greater functionality and complexity in

['--] Predicted(Y1)

~

Actual(Y2)

20

15

10

0

Ol A

3.4 9.27 13.17 17.5 Months since release of first OI B

C

D

E

j]

81.6

J

FIG. 5. Reliability of maintained s o f t w a r e - - t i m e to next failure.

170

NORMAN F. SCHNEIDEWIND TABLE III CHANGE METRIC SUMMARY Metric

Actual

Mean time to failure Total test time per KLOC Total failures per KLOC Remaining failures per KLOC Time to next failure Average

-0.060 0.116 0.087 0.277 -0.065 0.071

Predicted

0.115 0.107 -0.152

the software over a sequence of releases, (2) a maintenance process that needs to be improved, or (3) a combination of these causes.

7.4

Metrics for Long-Term and Short-Term Analysis

In addition to the long-term maintenance criteria, it is desirable that the maintenance effort results in increasing reliability within each release or OI. One way to evaluate how well we achieve this goal is to predict and observe the a m o u n t of test time that is required to reach a specified number of remaining failures. In addition, we want the test effort to be efficient in finding residual faults for a given OI. Furthermore, number of remaining failures serves as an indicator of the risk involved in using the maintained software (i.e., a high value of remaining failures portends a significant number of residual faults in the code). In the analysis that follows we use predictions and actual data for a selected OI to illustrate the process: OID.

7.4.1

Total Test Time Required for Specified Remaining Failures

We predict the total test time that is required to achieve a specified number of remaining failures, r(h), at time tt., by equation (7) as described in American Institute of Aeronautics and Astronautics [17] and Schneidewind [20]: 1 t, - - log /3

+ (s - 1). /3[r(t,)]

(7)

M A I N T E N A N C E PROCESS A N D P R O D U C T E V A L U A T I O N

171

80 Operational increment OlD 9~ 9 Actual

e4~r

60

m 9

.c_

oq 4~ ~ 40 E ..,.., _

# 9149149

o 20

b-

..d .,q

I

0

Decreasing risk

I

1

I

I

I

2 3 4 Number of remaining failures

I

5

I

6

FIG. 6. T o t a l test t i m e to a c h i e v e r e m a i n i n g failures.

We plot predicted and actual total test time for OID in Fig. 6 against given number of remaining failures. The two plots have similar shapes and show the typical asymptotic characteristic of reliability (e.g., remaining failures) versus total test time. These plots indicate the possibility of big gains in reliability in the early part of testing; eventually the gains become marginal as testing continues. The figure also shows how risk is reduced with a decrease in remaining failures that is accomplished with increased testing. Predicted values are used to gauge how much maintenance test effort would be required to achieve desired reliability goals and whether the predicted amount of total test time is technically and economically feasible. We use actual values to judge whether the maintenance test effort has been efficient in relation to the achieved reliability.

7. 4.2

Failure Rate

In the short-term (i.e., within a release), we want the failure rate ( 1 / M T T F ) of an OI to decrease over an OI's total test time, indicating increasing reliability. Practically, we would look for a decreasing trend, after an initial period of instability (i.e., increasing rate as personnel learn how to maintain new software). In addition, we use various shape metrics, as defined previously, to see how quickly we can achieve reliability growth with respect to test time expended. Furthermore, failure rate is an indicator of the risk involved in using the maintained software (i.e., an increasing failure

172

N O R M A N F. S C H N E I D E W I N D

rate indicates an increasing probability of failure with increasing use of the software). Failure r a t e -

Total number of failures during test

(8)

Total test time We plot equation (8) for OID in Fig. 7 against total test time since the release of OID. Figure 7 does show that short-term stability is achieved (i.e., failure rate asymptotically approaches zero with increasing total test time). In addition, this curve shows when the failure rate transitions from unstable (increasing failure rate) to stable (decreasing failure rate). The figure also shows how risk is reduced with decreasing failure rate as the maintenance process stabilizes. Furthermore, in Fig. 8 we plot the rate of change (i.e., slope) of the failure rate of Fig. 7. This curve shows the percent of total test time when the rate of change of failure rate reaches its maximum negative value. We use these plots to assess whether we have achieved short-term stability in the maintenance process (i.e., whether failure rate decreases asymptotically with increasing total test time). If we obtain contrary results,

0,020 -

Unstable

0.018"

0.016"

~>~ (13 "tD I,., (D CL U') L

r LL

0,014-

0,012"

0.010"

0.0080.006"

Decreasing risk

0.004-

v-

0,002

0.000

,

5.9

.

6.29

.

7.41

.

9.67

.

.

12.7

.

16.56

.

,

22.76

30.82

Percent of total test time FIG. 7. O I D failure rate.

58.73

,

75.77

,

84.57

100

173

MAINTENANCE PROCESS AND PRODUCT EVALUATION 8.00 7.00 6.00 • 5.00 4.00 "0

3.00

$ t,~

2.00

o,m

1.00

Y.

0.00 [ -1.00

L Stable when negative 13 20

27

34

41

48

55

62

69

76

83

90

97

Percent of total test time FIG. 8. OID rate of change of failure rate.

this would be an alert to investigate whether this is caused by: (1) greater functionality and complexity of the OI as it is being maintained, (2) a maintenance process that needs to be improved, or (3) a combination of these causes. Another way of looking at failure rate with respect to stability and risk is the annotated failure rate of OID shown in Fig. 9, where we show both the actual and predicted failure rates. We use equations (8) and (9) as described in American Institute of Aeronautics and Astronautics [17] to compute the actual and predicted failure rates, respectively, where i is a vector of time intervals for i t> s in equation (9):

f(i)

= c~(exp(-/3(i- s + 1))).

(9)

A 30-day interval has been found to be convenient as a unit of Shuttle test time because testing can last for many months or even years. Thus this is the unit used in Fig. 9, where we show the following events in intervals, where the predictions were made at 12.73 intervals: Release time: 0 interval, Launch time: 13.90 intervals, Predicted time of maximum failure rate: 6.0 intervals, Actual time of maximum failure rate: 7.43 intervals,

174

NORMAN F. SCHNEIDEWIND

0.8

m

I

Actual 0.7

Predicted

e~

>, 0.6 Ce)

K

Launch

0.5

Decreasing risk

0.4

,.a

0.3 ~ 0)

Release

0. I , ~ , , l l m , , J ~ , ~

0

10

20

30

I

l l l l

40

l i ~ J

50

~ l i s | x s |

60

70

80

Total test time (30 day intervals) FIG. 9. O l D failure rate: predicted versus actual.

Predicted maximum failure rate: 0.5735 failures per interval, and Actual maximum failure rate: 0.5381 failures per interval. In Fig. 9, stability is achieved after the maximum failure rate occurs. This is at i = s (i.e., i = 6 intervals) for predictions because equation (9) assumes a monotonically decreasing failure rate, whereas the actual failure rate increases, reaches a maximum at 7.43 intervals, and then decreases. Once stability is achieved, risk decreases.

7.5

Summary

In addition to analyzing short-term stability with these metrics, we use them to analyze long-term stability across releases. We show the results in Table IV where the percent of total test time to achieve reliability growth goals is tabulated for a set of OIs, using actual failure data, and the change metrics are computed. Reading from left to right, the values of CM indicate 8.9% stability, 7.0% instability, and 10.1% instability; there are no critical transitions. Interestingly, except for OID, the maximum negative rate of


175

TABLE IV PERCENT OF TOTAL TEST TIME REQUIRED TO ACHIEVE RELIABILITY GOALS AND CHANGE METRICS (CM)

Operational increment A B C D E J O

One remaining failure (% test time) 77.01 64.11 32.36 84.56 83.29 76.88 46.49 CM STD DEV

Relative change

Stable failure rate (% test time)

0.168 0.495 -0.617 0.015 0.077 0.395 0.089 0.392

76.99 64.11 10.07 12.70 61.45 76.89 100.00 CM STD DEV

Relative change

Maximum failure rate change (% test time)

Relative change

0.167 0.843 -0.207 -0.793 -0.201 -0.231 -0.070 0.543

76.99 64.11 10.07 22.76 61.45 76.89 100.00 CM STD DEV

0.167 0.843 -0.558 -0.630 -0.201 -0.231 -0.101 0.544

change of failure rate occurs when failure rate becomes stable, suggesting that maximum reliability growth occurs when the maintenance process stabilizes.

ill

Shuttle Operational Increment Functionality and Process Improvement

Table V shows the major functions of each OI as reported in L o c k h e e d - M a r t i n [22] along with the release date and K L O C change repeated from Table I. There is not a one-for-one relationship between KLOC change and the functionality of the change because, as stated earlier, KLOC is an indicator of maintenance actions, not functionality. However, the software developer states that there has been increasing software functionality and complexity with each OI, in some cases with less rather than more K L O C as stated by Keller [16]. The focus of the early OIs was on launch, orbit, and landing. Later OIs, as indicated in Table V, built upon this baseline functionality to add greater functionality in the form of M I R docking and the Global Positional System, for example. Table VI shows the process improvements that have been made over time on this project, indicating continuous process improvement across releases. The stability analysis that was performed yielded mixed results: about half are stable and half are unstable. Some variability in the results may

176

NORMAN F. SCHNEIDEWlND

TABLE V SHUTTLE OPERATIONAL INCREMENT FUNCTIONALITY Operational increment

Release date

KLOC change

A B C D

9/1/83 12/12/83 6/8/84 10/5/84

8.0 11.4 5.9 12.2

E F G H I J

2/15/85 12/17/85 6/5/87 10/13/88 6/29/89 6/18/90

8.8 6.6 6.3 7.0 12.1 29.4

K

5/21/91

21.3

L M N O P Q

6/15/92 7/15/93 7/13/94 10/18/95 7/16/96 3/5/97

34.4 24.0 10.4 15.3 7.3 11.0

Operational increment function Redesign of main engine controller Payload re-manifest capabilities Crew enhancements Experimental orbit autopilot. Enhanced ground checkout Western test range. Enhance propellant dumps Centaur Post 51-L (Challenger) safety changes System improvements Abort enhancements Extended landing sites. Trans-Atlantic abort code co-residency Redesigned abort sequencer One engine auto contingency aborts Hardware changes for new orbiter Abort enhancements On-orbit changes MIR docking. On-orbit digital autopilot changes Three engine out auto contingency Performance enhancements Single global positioning system

be due to gaps in the data caused by OIs that have experienced insufficient failures to permit statistical analysis. Also, we note that the values of CM are small for both the stable and unstable cases. Although there is not pronounced stability, neither is there pronounced instability. If there were consistent and large negative values of CM, it would be cause for alarm and would suggest the need to perform a thorough review of the process. This is not the case for the Shuttle. We suspect but cannot prove that in the absence of the process improvements of Table VI, the CM values would look much worse. It is very difficult to associate a specific product improvement with a specific process improvement. A controlled experiment would be necessary to hold all process factors constant and observe the one factor of interest and its influence on product quality. This is infeasible to do in industrial organizations. However, we suggest that in the aggregate a series of process improvements is beneficial for product quality and that a set of CM values can serve to highlight possible process problems.


177

TABLE VI CHRONOLOGY OF PROCESS IMPROVEMENTS Year in which process improvement introduced 1976 1977 1978 1980 1981 1982 1983 1984 1985 1986 1987 1988 1989 1990 1992

ell

Process improvement Structured flows Formal software inspections Formal inspection moderators Formalized configuration control Inspection improvements Configuration management database Oversight analyses Build automation Formalized requirements analysis Quarterly quality reviews Prototyping Inspection improvements Formal requirements inspections Process applied to support software Reconfiguration certification Reliability modeling and prediction Process maturity measurements Formalized training Software metrics

United States Air Force Global Awareness (GA) Program Application

The change metric has also been incorporated into the decision support system (DSS) of the US Air Force Global Awareness (GA) program of the Strategic and Nuclear Deterrence Command and Control System Program Office for the purpose of tracking and evaluating various computer and communications resource and performance metrics as described by Schneidewind [23]. GA systems are ground-based radar and optical sensors, which provide warning to North America of attack from air, space, or missiles. Most of these sensors operate 24 hours per day, seven days per week. The system provides a variety of search and track operations to collect metric data and optical signature data on satellites (primarily deep space satellites) for the United States Air Force. These electro-optical sensors operate between sunset and sunrise. Sensor sites are in continual need of upgrade, modification, and changes to mission-critical hardware and software components. The development of a set of metrics, whereby managers can make informed decisions concerning the future of this system,

178

NORMAN F. SCHNEIDEWIND

is being accomplished to establish a set of statistically relevant data as described by Schneidewind [23]. The effort began in 1996 by identifying candidate forecasting metrics and instituting processes to collect and analyze forecasting data. The Metrics Engineering Team established a data repository to store metrics, including system status metrics and candidate forecasting metrics. The most recent team efforts include development of a process and an automated tool to integrate metrics collection and analysis--the DSS. The metric definitions are given below as reported in OAO Corporation [24]. These metrics are considered crucial to assessing operational performance. All metrics are reported monthly. Mean time between critical failures (MTBCF): Average time in hours between failures of critical components. The purpose of this metric is to identify the frequency of outages. The timing of replacement actions can also be determined through use of this metric.

MTBCF =

Time the system is available Number of critical failures

Mean time to repair (MTTR): Average time in minutes to restore the system to an operational state. The purpose of this metric is to identify the average time required to repair and return a sensor site from a critical failure to an operational status.

MTTR -

Total repair time for all outages Number of outages

System availability: Percentage of time that the system is available to meet mission needs. The purpose of this metric is to determine system health, determine how well the system is meeting mission requirements, and determine the probability that the system will be available at any given time for mission accomplishment.

System availability- (

Programmed operating t i m e - System downtime Programmed operating time

• 100. Software failure time loss: Total time lost in minutes from system operation due to software failures. The purpose of this metric is to assess operational


179

time lost due to software failures. Software failure time loss = Sum of all down time due to software failures. This application of CM involves using the same metrics on the same release but across different sites. An example is given in Table VII. Here CM is computed for each metric and each site over a number of time periods. Reading from left to right in Table VII, the best stability values are 4.2%, 0.7%, 7.0%, and 0.4%; the worst instability values are 0.1%, 6.4%, 0.6%, and 4.8%. The CM is used to identify sites that have low performance relative to other sites. Table VIII shows the CM ranking of the four sites, where "1" is the highest rank (most stable) and "4" is the lowest rank (most unstable). In addition, domain experts assess AF Base 2 to be the worst of the lot in overall performance; this is borne out by the rankings in Table VIII and Table IX, which show the average ranks considering all four metrics. For AF Base 1, there were two consecutive critical transitions of mean time between critical failures from 672 to 186 to 720 hours in February, March, and April 1999, respectively. In addition, for AF Base 3, there were two consecutive critical transitions of system availability from 81.01% to 50.28% to 83.88% in July, August, and September, 1997, respectively. These transitions were flagged by the HU and HS criteria, respectively. However, there is no information in the available data as to why these transitions occurred.

TABLE VII CHANGE METRIC VALUES Metric Mean time between critical failures Mean time to repair System availability Software failure time loss

A F Base 1

A F Base 2

A F Base 3

A F Base 4

-0.001 0.018 0.000 0.042

-0.011 -0.051 0.007 -0.064

-0.006 0.002 0.000 0.070

0.004 -0.048 -0.001 -0.018

A F Base 3

AF Base 4

,

TABLE VIII CHANGE METRIC RANKS Metric Mean time between critical failures Mean time to repair System availability rank Software failure time loss rank

A F Base 1

A F Base 2

2 1 2.5 2

4 4 1 4

3

1

2

3

2.5 1

4 3

180

NORMAN F. SCHNEIDEWIND TABLE IX AVERAGE RANK OF FOUR METRICS

AF Base 1 1.875

AF Base 2

AF Base 3

AF Base 4

3.25

2.125

2.75

10.

Conclusions

As stated in Section l, our emphasis in this chapter was to propose a unified product and process measurement model for both product evaluation and process stability analysis. We were less interested in the results of the Shuttle and US Air Force stability analysis, which were used to illustrate the model concepts. We have presented the concept of process stability related to product quality and we have shown how to compute the change metric (CM) that assesses process stability as a function of product metrics. One example involved applying CM across several releases of the Shuttle flight software. A second example involved applying CM across multiple sites of the US Air Force Global Awareness Program. The highly stable and highly unstable criteria are useful for flagging anomalous values of relative change. These values may signify significant changes in product or process. We conclude, based on both predictive and retrospective use of reliability, risk, and test metrics, that it is feasible to measure and assess both product quality and the stability of a maintenance process. The model is not domain specific. Different organizations may obtain different numerical results and trends than the ones we obtained for our example applications. ACKNOWLEDGMENTS We acknowledge the support provided for this project by Dr. William Farr, Naval Surface Warfare Center; Mr. Ted Keller of IBM" and Ms. Patti Thornton and Ms. Julie Barnard of United Space Alliance. REFERENCES [1] Hollenbach, C., Young, R., Pflugrad, A. and Smith D. (1997). "Combining quality and software improvement". Communications o[the ACM, 40, 41-45. [2] Lehman M. M. (1980). "Programs, life cycles, and laws of software evolution". Proceedings of the IEEE, 68, 1060-1076. [3] Schneidewind, N. F. (1997). '+Measuring and evaluating maintenance process using reliability, risk, and test metrics". Proceedings of the International Conference on Software Maintenance, IEEE Computer Society, 232-239.


181

[4] Schneidewind, N. F. (1998). "How to evaluate legacy system maintenance". IEEE Software, 15, 34-42. Also translated into Japanese and reprinted in: Nikkei Computer Books (1998). Nikkei Business Publications, Tokyo, Japan, 232-240. [5] Schneidewind, Norman F. (1999). "Measuring and evaluating maintenance process using reliability, risk, and test metrics". IEEE Transactions on Software Engineering, 25, 768-781. [6] Briand L. C., Basili, V. R. and Kim, Y.-M. (1994). "Change analysis process to characterize software maintenance projects". Proceedings of the International Conference on Software Maintenance, Victoria, IEEE Computer Society, 38-49. [7] Gefen, D. and Schneberger, S. L. (1996). "The non-homogeneous maintenance periods: a case study of software modifications". Proceedings of the International Conference on Software Maintenance, IEEE Computer Society, 134-141. [8] Henry, J., Henry, S., Kafura, D. and Matheson, L. (1994). "'Improving software maintenance at Martin Marietta". IEEE Software, IEEE Computer Society, 11, 67-75. [9] Khoshgoftaar, T. M., Allen, E. B., Halstead, R. and Trio, G. P. (1996). "Detection of fault-prone software modules during a spiral life cycle". Proceedings of the International Conference on Software Maintenance, IEEE Computer Society, 69-76. [10] Pearse, T. and Oman, P. (1995). "Maintainability measurements on industrial source code maintenance activities". Proceedings of the International Conference on Software Maintenance, IEEE Computer Society, 295-303. [11] Pigoski, T. M. and Nelson, L. E. (1994). "Software maintenance metrics: a case study". Proceedings of the International Conference on Software Maintenance, IEEE Computer Society, 392-401. [12] Sneed, H. (1996). "Modelling the maintenance process at Zurich Life Insurance". Proceedings of the International Conference on Software Maintenance, IEEE Computer Society, 217-226. [13] Stark, G. E. (1996). "Measurements for managing software maintenance". Proceedings of the International Conference on Software Maintenance, IEEE Computer Society, 152-161. [14] Billings, C., Clifton, J., Kolkhorst, B., Lee, E., and Wingert, W. B. (1994). Journey to a Mature Software Process". IBM Systems Journal, 33, 46-61. [15] Schneidewind, N. F. (1997). "Reliability modeling for safety critical software". IEEE Transactions on Reliability, 46, 88-98. [16] Keller, T. (1998). Private communication, IBM. [17] American Institute of Aeronautics and Astronautics (1993). Recommended Practice .for Software Reliability, ANSI/AIAA R-013-1992, Washington, DC. [18] Keller, T., Schneidewind N. F. and Thornton, P. A. (1995). "Predictions for increasing confidence in the reliability of the space shuttle flight software". Proceedings of the AIAA Computing in Aerospace 10, San Antonio, Texas, 1-8. [19] Schneidewind, N. F. and Keller, T. W. (1992). "Application of reliability models to the space shuttle". IEEE Software, 9, 28-33. [20] Schneidewind, N. F. (1993). ~'Software reliability model with optimal selection of failure data". IEEE Transactions on Software Engineering, 19, 1095-1104. [21] Farr, W. H. and Smith, O. D. (1993). "~Statistical modeling and estimation of reliability functions for software (SMERFS) users guide". NAVSWC TR-84-373, Revision 3, Naval Surface Weapons Center, Dahlgren, Virginia. [22] Lockheed-Martin (1998). "Software release schedules", Houston, Texas. [23] Schneidewind, N. F. (2000). "United States Air Force decision support system (DSS) panel discussion". International Conference on So.[?ware MahTtenance 2000 and International Symposium on Software Reliability Engineering 2000, Industry Day Proceedings, Reliable Software Technologies, Dulles, Virginia. [24] OAO Corporation Report (1997). "Identifying and proposing metrics for missile warning space surveillance sensors (MWSSS)", Colorado Springs, Colorado.


Computer Technology Changes and Purchasing Strategies GERALD V. POST Eberhardt School of Business University of the Pacific 3601 Pacific Ave. Stockton, CA 95211 USA

Abstract Driven by design and manufacturing improvements as well as competition, computer chips have doubled in capacity about every year and a half for over 35 years. This exponential rate of change requires careful analysis of purchasing strategies. Regardless of "need," some buying strategies are more valuable than others. F o r example, desktop PC replacement cycles of three years are preferred, but firms choose the level of technology that matches their needs. On the other hand, for laptops, it has been better to choose high-end computers, and then match the replacement cycle to the specific uses. Advances in information technology also affect the use of computers and the structure of the o r g a n i z a t i o n - - d r i v i n g firms towards decentralization.

1. 2. 3.

4.

5.

6. 7.

Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Moore's Law: The Beginning . . . . . . . . . . . . . . . . . . . . . . . . . . . Mainframes to Personal Computers: Price/Performance . . . . . . . . . . . . . . 3.1 Grosch's Law: Economies of Scale . . . . . . . . . . . . . . . . . . . . . . 3.2 Declining Prices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Personal Computers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.1 Buying Strategies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.2 Performance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.3 Comparing Strategies . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.4 Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.5 Interpretation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.6 Upgrade Strategy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Laptops . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.1 Buying Strategy Results . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.2 Absolute and Relative Dominance . . . . . . . . . . . . . . . . . . . . . . 5.3 Upgrades . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Centralization, Decentralization, and T C O . . . . . . . . . . . . . . . . . . . . . Demand . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

ADVANCES IN COMPUTERS, VOL. 54 ISBN 0-12-012154-9

183

184 185 187 188 189 191 192 194 194 196 200 201 202 203 203 204 205 206


184

GERALD V. POST

8. The Future . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8.1 Limitsto Lithography . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8.2 AlternativeMethodologies . . . . . . . . . . . . . . . . . . . . . . . . . . 9. Conclusions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

1.

208 208 209 210 211

Introduction

Anyone who purchases a computer quickly learns two basic rules: (1) the price of that specific computer will drop the next month and (2) a faster, more powerful computer will rapidly become available at the same or lower price. While most people observe this pattern in the purchase of personal computers (PCs), it also exists with larger machines. For example, IBM mainframe prices dropped from $100 000/MIPS in the early 1990s to $2000/MIPS in 2000 [1]. In fact, these price declines exist because of the rapid introduction of new technology at the fundamental chip level. Advances in design and manufacturing techniques produce increasingly powerful chips for processors and random access memory (RAM). These trends have profoundly affected computers and their application in business. One of the most direct questions involves purchasing strategies. When performance continues to improve, coupled with declining prices, it can be frustrating and difficult to choose a purchasing strategy. Continued hardware improvements ultimately drive new software applications. As technology improves, software vendors add new features that take advantage of this additional capacity. For example, improvements in the user interface such as speech recognition require high-speed processing with substantial memory capacity. Ultimately, the computers need to be replaced, so the question becomes one of the length of the replacement cycle, and the level of computer to buy. Another important consequence of advancing technology arises because the implementation of that technology is not uniform. For example, economics and competition have generally driven advances of technology in personal computers faster than its application in larger servers. These advances have resulted in PCs today that are faster than supercomputers of a decade ago. The availability of increasingly powerful machines at everlower prices has resulted in a substantial decentralization of computer hardware. This decentralization has generated conflicts in information systems management. For example, decentralization appears to increase management costs and reduce control. Some of these concepts became embodied in the term "total cost of ownership" (TCO). Proponents of the

COMPUTER TECHNOLOGY CHANGES AND PURCHASING STRATEGIES 185

TCO methodology attempted to measure management costs of decentralization, and used these costs to encourage a move to recentralize their operations. Many of these challenging management decisions and purchase issues arise because of the exponential improvements in manufacturing at the chip level. Exponential change is difficult to handle, but when it exists for over 35 years, change itself becomes entrenched. Ultimately, the next question is: how long can technology improve exponentially? Over the next 10 years, this question will become more important and more difficult to answer. Eventually, the industry will reach physical limits in terms of current technologies and manufacturing processes. Moving beyond that point will require new fundamental technologies with new manufacturing techniques.

2.

Moore's Law: The Beginning

In 1965, based on only three data points, Gordon Moore [2] predicted that integrated circuit density could double with each device generation (about 18 months). For over 35 years, this prediction has been fulfilled. Driven by competition, economics, and demand for new applications, chip manufacturers have created new technologies to stay on this exponential curve. The computer industry and society have come to rely on this continually increasing performance for DRAM and processors. Figure 1 uses a log scale to show this pattern has fit very closely at the chip level. Intel processor circuitry has lagged DRAM development slightly, but the overall growth of both has been very close to the predicted levels. Achieving this exponential growth carries a cost, in terms of design and manufacturing. With each generation, chip manufacturers are squeezed by these increasing costs. Manufacturers are particularly concerned about the increasing fabrication costs. In fact, while DRAM capacities have been expanding at the rate of about 1.8 times every generation (a year and a half), factory costs have increased by 1.17 times for each generation. These increasing costs of fabrication are known as Moore's second law: fabrication costs increase at a semi-log rate. Essentially, the economics force manufacturers to strive for a doubling of chip capacity with each generation. Smaller increases would not cover the design and capital costs of the new generation [3-6]. Chandra et al. [7] provide several other charts showing improvements in other components, such as disk drive capacities, CD-ROM speeds, and network transmission speed. Many of these other components and services have gained from the same technologies used to improve the chip capacities,

186

GERALD V. POST

FIG. 1. Moore's law at the chip level. The Moore line represents the pattern if chip capacities had completely doubled every 1.5 years. D R A M capacity increases averaged 1.8 times every year and a half. The corresponding rate for processors was 1.6 times. Source data from Intel.

densities, and performance. Some, like recent disk drives, have improved even more rapidly than the doubling defined by Moore's law [8]. Table I shows how Intel has been able to achieve the greater chip complexity through reduced transistor size and increasing wafer diameter. It also shows that through increased plant automation, Intel has been able to reduce costs by reducing defects. It is tempting to say that as long as the cost increase is at a lower rate than the capacity increase, then D R A M and processors can continue to improve at the same rate. But there is a catch to this statement: each generation requires substantially greater access to financial capital. For instance, by 1999, capital cost of a fabrication plant had exceeded $5 billion [10]. Manufacturers must be large and stable for investors to contribute the money needed to build each new generation. Consequently, the industry has continued to consolidate, and to explore joint manufacturing agreements.

COMPUTER TECHNOLOGY CHANGES AND PURCHASING STRATEGIES 187 TABLE I INTEL'S CHIP-MANUFACTURING PROGRESS. DATA SOURCE [9] (INTEL WEB SITE)

Chip complexity (index) Feature size (mm) Chip size (ram 2) Facility automation (%) Line yield (%)

1975

1997

2003 *

1 2 30 5 40

10 0.25 150 60 90

100 0.08 600 80 95

* forecasted values.

3.

Mainframes to Personal Computers: Price/Performance

The result of increased chip capacity has been significant price reductions for DRAM and processors, as well as increased performance. Since DRAM and processors are used in many devices, including components like disk drives, virtually all aspects of computers have improved substantially in terms of price and performance over the past 35 years. The increasing performance arises from the increased capacity of the chips. Capacity is improved through greater density, which also increases performance (and heat). Low prices are derived partly from the improved capacity. However, increased demand and economies of scale through standardization have been important factors as well. Measurement of performance is a challenge in the issues of computer price and performance. Particularly in the 1950s through 1980s, with disparate computer processors, diverse peripherals, and multiple configurations, it was difficult to compare the performance of machines [11-15]. With the standardization of microprocessors in the 1990s, the comparison issues were reduced, but never truly erased. Within a manufacturer's line, the differences are controllable. Across manufacturers, people have tried to compare MIPS (millions of instructions per second), or MFLOPS (millions of floating point operations per second), and occasionally benchmark times on standardized software tests [12, 14, 16-18]. While engineers could argue about these comparisons for years, they have all led to the same basic results: dramatic improvements in performance over time in all computers. The improved performance has also led to ever-smaller computers. As chips gain capacity, more functions are embedded, reducing the ultimate size of the computer. The pattern is clear from room-size mainframes to minicomputers to personal computers, laptops, and personal digital assistants. The unrelenting pressure of competition in the PC market has created problems for several manufacturers. Briody [19] reports that the average

188

GERALD V. POST

corporate PC purchase price dropped from $2453 in 1996 to $1321 in 1999. He also reported that IBM lost $1 billion in their PC division in 1998, which undoubtedly explains why IBM announced in 1999 that they would drop traditional retail sales of desktop PCs.

3.1

Grosch's Law: Economies of Scale

In the 1960s and 1970s, as detailed by Ein-Dor [20], several researchers observed a basic relationship in computer prices at a given point in time. Within a specific manufacturer's line (e.g., IBM computers), the price/ performance ratio tended to decline while progressing from smaller to larger computers. Researchers concluded these differences represented economies of scale, and often suggested that companies would be better off buying larger computers (instead of several smaller ones) because of this pattern. Herbert Grosch also stated that the economy of computing increases with the square root of speed. That is, to do a calculation 10 times as cheaply, it must be performed 100 times faster. Grosch explained the differential by observing that increasing processor performance was absorbed by increased software overhead. Several researchers examined data from the 1950s to the 1970s to prove Grosch's law [21-25]. Ein-Dor and Kang [26] eventually showed that this pattern did not hold when minicomputers and microcomputers were introduced. The new, small machines had considerably lower price/performance ratios than the larger mainframes. On the other hand, true economies of scale have evolved in the small-computer market: as demand and sales increase, per-unit costs decline dramatically. Today, price/performance ratios, along with absolute cost, are substantially lower for mass-produced personal computers than for other computers. Recent data provide the opportunity to once again test Grosch's law across a more homogeneous set of personal computers. Table II shows prices and performance for three systems introduced over four years. The performance change column is the ratio of the performance measure (Pt/Pt-1). The economy of computing is measured as the price/ performance ratio. The change column is similarly defined as the ratio of the economy from one system to the next. Grosch's law would imply that if performance improves by a factor of x (Pt = xPt- 1), then the economy ratio (cost/performance) should change by 1/v/-s (E, = 1,/v/-xEt_ 1). The next-tolast column holds the ratio of Et/Et_ 1. The last column displays the computation of 1/ v/P,/P, _ 1. Notice the substantial improvement in the economy ratio in the next-tolast column. Price/performance has improved considerably over the level postulated by Grosch's law. Note that Grosch claims an additional factor in

COMPUTER TECHNOLOGY CHANGES AND PURCHASING STRATEGIES

189

TABLE II SAMPLE TEST OF GROSCH'S LAW FOR PERSONAL COMPUTERS. COMPARE THE LAST TWO COLUMNS. IN TERMS OF HARDWARE ECONOMIES, PRICE-PERFORMANCE RATIOS HAVE DROPPED CONSIDERABLY FASTER THAN POSTULATED BY GROSCH'S LAW

System

Date

Intro price

P/200 PII/400 PIII/800

Jan 96 Jan 98 Jan 00

5664 3800 2900

CPUMark 99

Price/ performance

Performance change

Price/ performance change

Grosch square root

11.6 31.6 72.1

488.28 120.25 40.22

2.72 6.22

0.2463 0.0824

0.6059 0.4011

"economy" due to software [27], claiming that software changes will eat up the price/performance improvements. However, this claim is dubious in the current PC environment. For a given set of tasks (e.g., a standard benchmark), the performance levels show the improvements listed in the next-to-last column. On the other hand, it is true that software vendors continually add new features, and many of these new features require additional performance. For example, speech recognition demands considerably more advanced computers than basic word processing software. This observation holds the answer to the question: why not just buy one computer and use it forever? The basic answer is that computers have not yet reached the stage where they meet the demands being placed on them. Performance improvements open up new applications and improvements in the user interface.

3.2

Declining Prices

Figure 2 shows this effect of improved performance and declining price. Price/performance ratios of all computers declined substantially from the mid-1980s through the mid-1990s. While the MIPS values may not be strictly comparable across computers, the pattern is so strong that minor discrepancies from measurement error do not influence the result. Not only has relative price/performance improved, but absolute price and performance changes have been dramatic as well. For example, it is now possible to buy personal computers for a few thousand dollars with performance equal to or greater than the fastest supercomputers of 15 years ago--costing several million dollars. The consequences of this change are shown in Fig. 3, which hints at the effect on both the computer market and on society. In the 1960s and 1970s, mainframe computers dominated the market and the industry. Improving

FIG. 2. Declining prices. Lower chip prices and competition from personal computers drove down prices of all computers. Source data from manufacturers and industry publications. Reprinted with permission of McGraw-Hill from Mana~ement Information Systems (2000) by Post and Anderson.

FIG. 3. The changing use of computers. Although sales of all computers increased through 1995, the total shipment value of mainframes declined from 1995 to 1999. Reprinted with permission of McGraw-Hill from Managenlent h?/'ormation Systems (2000) by Post and Anderson.


technology and declining costs fostered the growth of minicomputers (particularly Digital Equipment Corporation) in the 1970s and early 1980s. The even more dramatic changes in the 1990s spread the use of personal computers throughout the world. The declining price of individual machines has emphasized the reduction in total revenue from these higher-end machines. Until the mid-1990s, sales revenue was generally increasing in all three categories of computers. So, although PC revenues were gaining a larger share, the entire industry was expanding. Since 1990, even that aspect changed--largely because manufacturers (notably IBM) were forced to reduce per-unit prices. While unit sales of large mainframes were increasing, the total revenue declined [28]. Yet, the worldwide PC market was not even close to saturation, so PC sales units and revenue continued to increase. Actually, the line between the machine classifications is increasingly blurred. Because of the increased capacity and performance of the chips, manufacturers altered the way that most computers are built. While their architecture differs from personal computers, many of today's servers and "mainframes" utilize relatively standard CMOS technology. From an economic, or purchasing perspective, computers have always been an interesting product [13]. They are relatively expensive, and as soon as you buy one, a newer model comes out that is more powerful and cheaper than the one you just bought. Over time, any computer you have must be replaced; partly from pressure by the manufacturer (in terms of maintenance contract costs) and partly because of technological obsolescence. In the 1970s, it was generally recognized that IBM strove for five-year product cycles, encouraging leading users to replace main computers every five years. However, the 1970s and 1980s were essentially on the relatively low-growth linear portion of the exponential performance curve. In contrast, the 1990s have exhibited more radical improvements. For example, doubling from 64 to 128 is substantially more noticeable than doubling from to 2 to 4. Consequently, the impact on buying strategies has been more pronounced in the last decade. Today, the issue of economies of scale (particularly Grosch's law) are more complex. From a hardware perspective, standardization and competition continue to drive personal computer price/performance trends--providing strong incentives for decentralization.

4.

Personal Computers

This section is an updated analysis based on a version by the author, printed and copyright 1999 by ACM: Post, G. V., 1999, How Often Should a Firm Buy New PCs?, Communications of the A CM, 42(5), 17-21.

192

GERALD V. POST

Several writers (e.g., Schaller [29], Mendelson [30], and Kang [16]) have examined and attempted to measure computer price trends. Today, the issue of server purchases and prices has changed only slightly. With only a limited number of manufacturers, and a long investment in software and development, companies generally have few choices in terms of switching, upgrading, or pricing of servers. The rapid rise of freeware-based operating systems (initialized by Linux) offers some future price competition, but those effects cannot yet be evaluated. Hence, several of the more interesting price questions arise in the personal computer arena. Faced with a vast array of choices, managers must analyze difficult decisions regarding the purchase of personal computers. As managers recognize (e.g., [31,32]), we all face the consequence of these trends when we purchase a computer. Should we wait? Should we buy a faster computer? Should we buy the cheapest computer available? The problem with answering these questions is that it is exceedingly difficult to estimate the "need" or demand for computers. If you ask a typical cost-cutting manager for a new computer, the first question you hear is: Why do you need a new computer? The level of "need" is often a contentious issue within organizations when deciding to purchase new computers. Even on a broader scale, researchers have found it challenging to identify the business impact of computers and IT spending. The productivity debate (e.g., [33-35]) illustrates these problems. A fundamental result of the performance and price changes is that organizations have to buy new computers every few years. A consequence of these trends is that organizations must adopt some purchasing strategy that specifies the level of machine and timeframe they will be held. Hence, the primary question is to identify which strategies are superior to others. It is important to reduce the issue of "need" in purchasing personal computers. Of course, it is not possible to eliminate it completely. But it is possible to defer the issue and focus on narrowing the choices--which makes the decision process much simpler.

4.1

Buying Strategies

Even a casual knowledge of the computer industry reveals the basic patterns shown in Fig. 4. The data represent prices from one company (Gateway 2000) from December 1990 through October 1998. Notice that at any point in time you have a choice of levels of machines. At the low end of the price scale, you can find a base machine with an older processor and base amounts of RAM and disk capacity. High-end machines generally boast the latest processors, substantial memory, and larger monitors. Most vendors also offer an intermediate-level machine historically priced around


FIG. 4. Note the stability of the pricing on the high-end and base systems. Over time, the configuration of the machines changes. For example, examine the falling prices portrayed by the three specific types of computers. Source data from manufacturer ads.

$2500. By tracing the life-cycle of a particular computer, Fig. 4 shows how a computer begins life at the high end, and moves down the ladder as new technologies are introduced. This pattern of changing configurations and declining prices leads to an important characteristic of the personal computer market: the computers must be replaced at regular intervals; which leads to the two ultimate questions: (1) how often should computers be replaced, and (2) what level of computers should be purchased? The answers to these questions create a purchasing strategy. The key is to evaluate the cost of each strategy and the average performance of the machine. For example, a strategy of buying high-end machines every year will be expensive. However, a strategy of buying low-end machines every four years will result in workers having machines with substantially lower average performance. Twelve basic strategies are created from hypothetical purchases of high, intermediate, and base machines and holding them for 12, 24, 36, or 48 months. When the ownership time period is completed, a new machine is purchased at the same level (but different configuration as technology changes). The objective is to evaluate these twelve strategies to see if the options can be reduced. The technique used is to simulate purchases with the twelve strategies using the historical data. Comparing strategies over time requires that costs be discounted to a common point in time. Hence, the purchase prices were expressed as

194

GERALD V. POST

amortized monthly costs at a 5% discount rate. For each strategy, a resale value was estimated based on the life of the processor and advertised prices from computer brokerage sites. In general, the resale values were unimportant--particularly when expressed at an amortized monthly rate. They make the high-end purchases slightly more attractive but do not really alter the decision points. To compensate for possible seasonal changes and random fluctuations, the strategies were started at each of the 12 months for the first year of data. The results were then averaged using the median. The average approach also mimics firms that purchase several machines over the course of a year.

4.2

Performance

It is well known in computer science that it is difficult to compare performance characteristics of various computers. It is slightly easier in this study because all of the systems use Intel processors. Consequently, the Intel iComp-2 rating is used to measure the performance of the processors. It also turns out that the iComp-2 rating is a good proxy measure for the other attributes (RAM, drive capacity, video system, and so on). A simple regression test shows that the iComp-2 rating over this data has a high correlation (0.94R 2) with these other features. iComp - 11.54 + 0.48 RAM + 17.25 Drive + 4.02 CD + 12.52 VideoRAM RAM is measured in megabytes, drive capacity in gigabytes, CD speed in the traditional multiplier factor, and video RAM in megabytes. All of the coefficients are significant at greater than a 99% level. The equation is highly accurate; so iComp is a good measure of performance for desktop computers. The equation also shows the relative importance of each component in determining the overall performance. Consider the contribution of each component evaluated at the average as shown in Table III. Interestingly, the capacity of the disk drive has the strongest correlation with the overall performance measure. This result means that the capacity of disk drives increased at about the same rate as the overall system performance. It does not mean that drive capacity has the strongest impact on overall performance; only that it had the same growth rate over time.

4.3

Comparing Strategies

Consider strategy A with a cost of $100 and a performance level of 50, versus strategy B that costs $120 and has a performance level of 40. No one

COMPUTER TECHNOLOGY CHANGES AND PURCHASING STRATEGIES 195 TABLE III PC PERFORMANCE BREAKDOWN. CONTRIBUTION TO OVERALL PERFORMANCE FROM EACH COMPONENT AT THE AVERAGE. THESE VALUES ARE REGRESSION COEFFICIENTS THAT DESCRIBE THE CONTRIBUTIONS OF EACH COMPONENT TO THE OVERALL PERFORMANCE MEASURE. HIGHER VALUES SIGNIFY A HIGHER WEIGHT FOR A COMPONENT Video Intercept

RAM

Drive

CD

RAM

11.54

10.99

32.34

23.97

23.45

would choose strategy B since it costs more and offers less average performance. Strategy A dominates strategy B. Now consider strategy C that costs $101 and has a performance level of 75. Compared to strategy A, C is substantially faster but costs more money. Would people choose strategy C over A? This answer is somewhat subjective since it depends on comparing performance to price. However, it is possible to make some general comparisons along these lines by examining the cost/performance ratio. Ultimately, when comparing the cost/performance ratio, some subjective decisions must be reached in terms of the tradeoff. While it is true that the decision is subjective, it is likely that there are some levels at which almost everyone would agree that one strategy is preferable to another. In the A - C example, strategy C results in a machine that is 50% faster than A yet costs only 1% ($1 per month) more. Most people would prefer strategy C. This relationship could be called relative dominance to indicate that there is some subjectivity involved in the decision. The question that remains is what cost/performance tradeoff levels would be acceptable to most people? One way to approach this issue is to identify the ratio involved with purchasing any type of system. Three levels of systems are analyzed: high-end computers, mid-range, and low-price; for each of four time periods: 12, 24, 36, and 48 months. The 12 combinations are labeled with a letter indicating the level and the number of months the machine is held before being replaced. For example, H12 is a high-end computer replaced every 12 months: while L48 is a low-price computer replaced every 48 months. Each strategy is compared to the choice of no computer (PB = C 8 - 0) and the resulting cost/performance ratio is computed. The results range from 1.15 (strategy I36) to 2.53 (strategy H12). It is also instructive to note that the least-cost a p p r o a c h - - b u y i n g a low-end computer every 48 months--yields a ratio of 2.20.

196

GERALD V. POST

By using data expressed in original (not percentage) terms, these ratios have a direct interpretation: to obtain a one-unit level of performance, buyers had to spend from $1.15 to $2.53 per month. And the purchase of the barest minimum computer required an average of $2.20 per month for each unit of processing power. This range of values identifies limits for the cost/performance tradeoff. Specifically, if strategy A results in a decrease in performance (PA < PB) then most people should agree that A is preferred to B if the ratio is greater than 3 (rounding up the 2.53). That is, many buyers would accept a decline in performance if it saved them at least $3 for each one-unit drop. Conversely, if performance and price are higher, the more expensive strategy should be acceptable to most people if the cost ratio is less than 1 (rounding down 1.15). Since any computer costs at least $1 per month for each unit of performance, and since people choose to buy computers, then they should be willing to accept an increased cost as long as the performance gain is higher. There are limits to extending these statements, but they will hold for comparisons of relatively similar choices (e.g., small changes). One important caveat exists: the relative comparisons do not directly include a budget constraint or a performance constraint. Some organizations may only be able to afford the absolute lowest price machine-regardless of the performance. Similarly, some organizations could make the argument that they need the absolute highest performance regardless of price. However, these two extremes are probably rare in practice. If an organization has trouble paying $30-$50 per month for a low-end computer, it has more serious issues to resolve. On the other end, if a company needs massive processing power, users might be better off with workstations or parallel processing machines. 4.4

Results

The basic results of the 12 strategies are shown in Fig. 5, which compares the cost and performance results. Note that the median performance for High-24 is relatively high (equal to that for High-12). The mean values (not shown) are slightly lower. In general, the High-24 values should be lower than those of the High-12 strategy. The current results arise because of slightly different timing in the starting purchase for the two strategies.

4.4. 1 A b s o l u t e D o m i n a n c e Both the chart and the numeric results indicate that three strategies are dominated by other options. For example, the L12 option (buy base machines every 12 months) would clearly never be chosen because it is


FIG. 5. Each of the values (cost, RAM, drive, processor) is expressed as a percentage of the corresponding value in the most expensive strategy (High-12). Be cautious of adopting strategies like 1-12 that have relatively high costs, but tend to have lower average performance (not shown).

dominated by the I36 strategy. Comparing the L12 to the I36 option generates a cost performance ratio o f - 3 . 3 0 . That is, a $36 decrease in costs for I36 provides an increase in performance of 11 points. In percentages, strategy I36 represents a 6% drop in costs and a 75% increase in performance. Similarly, the I12 option is dominated by the H24 strategy, with a ratio o f - 3 . 1 4 . The essence of dominance is important, because it means that regardless of the user "demands," a rational person would never choose the dominated strategy. There is a better strategy that provides higher average performance at a lower cost.

4.4.2

Relative Dominance

Absolute dominance is relatively clear, but it only rules out three options. Can we reduce the list further? The answer lies in looking at relative dominance. For example, most people would choose a strategy that provides a machine four times faster for a one percent increase in price. These analyses are presented in Fig. 6. The horizontal axis shows the strategy being examined. Strategies that dominate by providing substantially faster machines at slightly higher costs are shown in the top of the chart. For ease of comparison, these ratio values have been inverted so that a value greater than 1.0 signifies relative dominance. Strategies that are dominated absolutely are indicated with the letter " D " indicating that the strategy on the x-axis would not be chosen because another strategy offers faster performance at a lower price.

198

GERALD V. POST

FIG. 6. An x-axis strategy is dominated (less desirable) if (1) there is a D in the column (absolute dominance), (2) the bar in the top of the chart exceeds 1 (faster machine at slightly higher price), or (3) the bar in the bottom of the chart exceeds 3 (substantially cheaper option with slight decline in performance). Options above 1 are preferred because they provide substantially higher performance at a minor increase in price. Options below 3 are preferred because they are significantly lower in price with only a slight drop in performance. The four bars exceeding the bounds are truncated and have substantially larger values than indicated by the graph.

Strategies that d o m i n a t e by being substantially cheaper with a small decline in p e r f o r m a n c e are shown in the b o t t o m of the chart. These values are positive, and magnitudes greater than 3.0 indicate that the x-axis strategy is less preferred. In all cases of dominance, the d o m i n a t i n g strategy is listed at the top or b o t t o m of the chart. The numerical results are also s u m m a r i z e d in Table IV. N o t e that some of the bars were truncated in Fig. 6 to highlight the i m p o r t a n t details a r o u n d the critical values. The actual values are listed in Table IV. Table IV shows the strategies that would typically be preferred to the base option. F o r example, an organization thinking a b o u t buying high-end machines every 48 m o n t h s would be better off buying intermediate-level machines every 36 m o n t h s , which is substantially cheaper (22%) with only a slight decline in p e r f o r m a n c e (1%). A n o t h e r choice is to purchase high-end machines every 36 m o n t h s , which is slightly m o r e expensive (13%) but results in a substantial increase in p e r f o r m a n c e (41%).

r.~ Z ,.r

0

0 .
. .< Z 0

.
.

i

er

I

/

I

I

i,~l r162

~1- r

~ - - "

117

.-,

77

t,~l r

-~ 9

~

~

'

o

o

,,,~ ,,.~ ,,~ e~ ~

I

o

200

GERALD V. POST

Notice that all of the 12-month options are dominated by better strategies--in general they are absolutely dominated. The low end also presents an interesting situation. Clearly, there are no cheaper solutions. However, a relatively small increase in costs results in substantial performance gains. For example, it would not make sense to pursue the Low-48 strategy because a 12% ($4) increase in monthly costs provides an 84% increase in median performance. The next step up is not as dramatic, but it still provides substantial gains. In general, the I36 option is better than any of the low-end machine strategies. For example, although it costs twice as much as the Low-48 strategy ($67 versus $34 per month), it provides almost four times the level of performance. The I36 strategy is a substantially better alternative--unless the organization faces severe budget constraints.

4.5

Interpretation

In total, two strategies tend to dominate all the others: High-36 and Intermediate-36. Additionally, the Low-36 option is a viable option for organizations with extreme budget pressures, but not generally recommended. Likewise, the High-12 option may be necessary for organizations requiring the absolutely highest performance levels, but it would normally be better to accept the exchange of a slight performance drop for substantial cost savings and replace the high-end machines every 24-36 months. The most important practical conclusion is that if companies are going to buy personal computers on a regular basis, then two strategies dominate the rest: buy high-end machines every 36 months, or buy intermediate-level computers every 36 months. For organizations with severe budget constraints, buying low-end computers every 36 months is also a viable alternative. For individuals that require extreme high-end machines, purchasing the high-end machines more frequently can increase performance - - however, the costs are substantially higher. Note that the practical decision holds almost independently of the "needs" of the organization. That is, the dominance holds because of pricing trends, and because the two alternatives represent considerably better price/performance relationships. The issue of demand does play a final role in the decision--determining which of the two strategies should be adopted. Only the needs of the organization and individual can make the final determination. The high-end (H36) option costs 45% more ($97 versus $67 per month) and yields a 42% improvement in performance and feature attributes compared to the intermediate-level (I36) strategy.

COMPUTER TECHNOLOGYCHANGESAND PURCHASINGSTRATEGIES 201 4.6

Upgrade Strategy

Another possible option is to pursue a strategy with a lower-level machine, and then upgrade the machine later. This strategy can only succeed if (1) component prices drop fast enough and (2) the underlying architecture does not change very rapidly. Figure 4 indicates that condition (1)does not generally hold. Examine the price lines for the three specific processors. The decline in price within each machine is due to declining prices of components. Notice that the price decline is approximately linear (not exponential). In other words, you could save some money by delaying the purchase of some components, but you lose the use of the more advanced components over that time period. Additionally, the components are generally replacements (e.g., new drive or new processor), which means you end up paying twice: (1)the original component and (2)the replacement component. Since the rate of decline in price is linear, it is difficult to gain much with this strategy. For example, consider an upgrade strategy of buying low-end machines every three years. From Fig. 4 the average relative performance is 0.30 with a 0.17 average relative cost. Assume halfway through the three years you decide to upgrade. Using an average high-end performance rating of 0.88, the combined average performance rating over both halves would be 0.59. The actual cost is difficult to estimate, but consider the alternative. The three-year intermediate strategy yields a slightly higher average performance (0.62) with a relative cost of 0.28. The upgrade strategy would be beneficial only if the cost of the upgrades were less than 64% of the low-end machine cost (about $1000 in this scenario). The upgrade would consist of a high-end processor, an additional disk drive, and at least double the amount of RAM. Can these items be purchased for less than 64% of the cost? In 2000, the computations are close to equal since a high-end processor alone would cost around $700-$800, and RAM and a drive are not likely to be less than $200. Finally, changes in architecture often prevent complete upgrades. For example, the PC bus has changed several times, both in structure and in speed--which limits upgrading to newer components. Similarly, changes in video and disk interface subsystems result in more costly replacements. Even more difficult form-factor changes can completely prevent upgrades. The past 10 years have demonstrated that within three-four years of initial release, it will become infeasible to upgrade a computer. Choosing a strategy of purchasing a low-end machine and trying to upgrade it means initially buying a machine that is two years out from its release date, so you would have one or perhaps two years in which to make upgrades. Hence, the upgrade strategy can generally be approximated within the strategies already defined--e.g., choosing the intermediate strategy.

202

GERALD V. POST

At best, the upgrade strategy would enable you to spread the costs over time. The effective gain in the computer technology is minimal, compared to just buying a more powerful machine and keeping it longer. On the other hand, if you have perfect foresight, there have been some time periods in which it might have been beneficial to purchase a lower-end machine, and then upgrade a few components when the price dropped radically. On the other hand, with perfect foresight, you could have accomplished the same goal by scheduling new computer purchases to the point just after major price drops.

5.

Laptops

Laptop purchase strategies can be analyzed in approximately the same manner as the desktop machines. However, there is a significant difference in measuring performance. Specifically, manufacturers tended to reduce prices on the lower-end machines by reducing the RAM and drive capacities. Figure 7 highlights the difference between the relative processor and RAM/drive capacities. Harris et al. [36] examined component pricing in an earlier study. Mathematically, the difference can be seen by regressing the performance measure against the other component measures. Unlike the desktop situation, the laptop regression yields only an 80% R 2 value. Although this value is relatively high, it is not as good as the 94% value in the desktop

FIG. 7. Laptop strategy results. Because of the wide disparity between processor performance and the memory and drive values, the average of these three values is a more representative measure of system performance.


case. Even more importantly, relying solely on the processor to measure laptop performance distorts the value of the low-end machines. Instead, an average of the relative performance of the processor, RAM, and disk drive was used. Figure 7 shows how this value is a more realistic measure of overall performance than just the processor rating. In examining Fig. 7, remember that the values are expressed as percentages of the most expensive option (H12: buy high-end laptops every 12 months). These values cannot be compared directly to the desktop values in Fig. 5, because the base is different. Also, note that a slightly different timeframe was used to evaluate the laptops because the technology does not extend as far back as the desktops. Laptop data runs from January 1993 through December 1999. But the three levels (high, medium, and low) do not appear until January 1995.

5.1

Buying Strategy Results

As in the desktop situation, we need to examine the various strategies to see if some might be preferred to others. In particular, we want to rule out inferior strategies. Recall that a strategy is dominated if another option provides a better average computer at a lower price. Even a casual glance at Fig. 7 shows that some strategies are not very useful because they are expensive, particularly buying intermediate or low-level laptops every year.

5.2

Absolute and Relative Dominance

A strategy absolutely dominates another option when it offers greater performance at a lower price. In other words, no one would choose to pursue the dominated option because a clearly better choice exists. Absolute dominance can rule out some of the strategies. But other strategies also may be unappealing. The two examples are: (1) the ability to gain a substantial increase in performance for a slight increase in cost, and (2) the ability to save a substantial amount of money for only a minor performance penalty. Figure 8 presents the laptop results for both the absolute and relative dominance cases. The main eye-catching result is the large number of strategies (five) that are ruled out through absolute dominance. One additional strategy (I36) is clearly dominated by relative performance gains. The results for the laptop are fairly strong: almost all of the intermediate and low options are weak. A slight case could be made for buying intermediate or low-level laptops every four years. But in most situations the relative dominance indicates that you would be better off buying a high-end laptop and keeping it for four years. Since the dominance is not strong, there is still room to argue that a firm may prefer to save money with one of these

204

GERALD V. POST

FIG. 8. Note the many options that are ruled out through absolute dominance. The strategy listed on the x-axis is the one being tested. If a second strategy dominates it, the preferred strategy is listed above (or below) the position. For example, H48 dominates the I36 strategy by providing substantially better performance at a slight increase in price.

lower choices and simply tolerate the lower performance. The results show that most people would be better off buying a higher-end laptop and use their personal situation to determine how often it should be replaced.

5.3 Upgrades Just looking at the results in Fig. 8, it is tempting to argue that the three long-term (four year) strategies could benefit from upgrades. Since laptops carry a relatively high initial cost, and since each of the four-year replacement strategies are relatively close in price/performance, it should be possible to gain by upgrading the laptop after two years. While this upgrade option might work, complicating factors make it somewhat difficult and expensive. Specifically, laptops are much harder to upgrade than desktops are. The proprietary nature of the cases and motherboards makes it harder to find upgrade parts. The same proprietary aspect also tends to increase prices of upgrade components because of reduced competition. For example, R A M formats tend to change between manufacturers and even across a specific manufacturer's product lines. The strategy of buying a low-end laptop and expecting to upgrade it two years later is a particularly risky proposition. The low-end laptop is generally already a year or two out from its introduction. The laptop and its


components will not likely remain on the market two years later when you wish to upgrade. The high and intermediate options offer better potential to pursue this strategy.

6.

C e n t r a l i z a t i o n , D e c e n t r a l i z a t i o n , and T C O

One of the important impacts of declining hardware prices has been the ongoing debate over centralization versus decentralization of computing resources, e.g., Refs [37, 38]. Initially, all computing resources (hardware, software, data, and personnel) were centralized because of the environmental needs and the enormous costs. With declining prices and increased performance of smaller machines, hardware moved out to individual departments and users within organizations. As the hardware moved outwards, the pressure increased to decentralize the software, data, and occasionally the personnel. While decentralization has its advantages, some researchers and computer companies (notably Sun Microsystems) have been encouraging managers to focus on the management costs of decentralized computers, and the benefits of centralized controls. Emigh [39] summarizes these issues. King [40] observes that pressures for centralization and decentralization continually evolve over time because many of the underlying issues (e.g., political power) are irresolvable. One of the rallying cries was developed in 1996 and pushed by Forrester Research and the Gartner Group, two large IT consulting firms. The concept is known as total cost of ownership or TCO [41]. TCO was designed to measure management costs of decentralized computers. As summarized in Table V, in addition to purchase price, the studies typically include costs of installing software, management, maintenance, and training. The "results" vary widely, from $5000 to $7000 to $12 000 per computer [42]. The ultimate question the analysis poses is: do you need a fully configured PC for every task, or can workers perform the same job with a simple terminal or Web browser connected to a central server? Not surprisingly, most of the TCO proponents decide that centralized solutions could generate a lower TCO than decentralized systems. While the PCs generally have a lower capital cost, standardization of software, data, and management practices are hypothesized to produce lower management costs using centralized machines [43]. There is some debate over the validity of these figures (e.g., by Forrester Research) [44]. For example, all of the TCO calculations assume complete reliability of central servers and networks. But the ultimate question comes down to management issues of productivity: are users more productive

206

GERALD V. POST TABLE V COMMON MANAGEMENT COSTS UTILIZED IN TCO CALCULATIONS ,

Common elements of TCO Requirements analysis and order determination Hardware costs Software license costs Configuration and installation cost Repair and help desk support Move/add/change Refresh/replace Cost of user time

under a highly centralized, standardized system, or with individually tailored solutions [45, 46]? The second important aspect of the TCO issue is that the benefits of recentralization (reduced management costs) arise from tighter management controls, increased standardization, and less end-user flexibility. Consequently, firms interested in these "benefits" need to consider two important questions. First, could the same benefits be achieved with the lower-cost PC hardware using tighter management practices? Second, will the restrictions and control affect workers' productivity? In response to the first question, PC manufacturers, led by Intel and Microsoft, have been developing tools to reduce TCO by improving centralized management features. In particular, newer PCs can be monitored and configured remotely, even to the point of loading operating systems and software across a network (Windows 2000). The second (managerial) question is considerably more difficult to answer, and the answer will depend heavily on the specific work environment. From a hardware perspective, the costs of the processor, RAM, and drive storage are virtually zero. The management challenge is to create applications that can use this power to reduce the management costs, while still supporting user control over applications to improve worker productivity.

7.

Demand

Most of the comments and analysis to this point have focused on the supply side of the computer industry. The reasons are because (1)the production aspects are unique, and (2) the demand side is subjective and difficult to evaluate. Even in a specific situation--say one u s e r - - i t is hard


to determine the true "needs" for computer processing capabilities (e.g., [47, 48]). Everyone knows arguments that have arisen because some person or group felt they needed faster or newer computers, while an administrator with a close eye on costs disagreed. Because of these difficulties, this analysis has turned the question around to identify which purchasing strategies might be ruled o u t - - t h u s simplifying the demand discussion by reducing the number of options. While this approach is effective, it does not eliminate the role of demand. For example, some administrators are going to argue that they do not need to replace computers at all. Since their staff simply use them for word processing, a base machine is fine; and as long as it works, it never needs to be replaced. Note that the dominance results for desktops accept a version of this conclusion as a possibility. While a three-year cycle would produce substantially higher performance at slightly higher costs, a four-year cycle of low-end machines provides an extremely low-cost solution, which could be needed in some situations. On the other hand, it also provides the absolute lowest levels of performance. Often, the people who prefer the lowlevel option state that they only use the machines for word processing. Do people need increasingly powerful personal computers? The answer can be found in the answers to a slightly different question: what tools will users demand in the next few years? Even traditional tools like word processors continually gain new features that require more disk capacity, more RAM, and faster processors. Do users "need" these additional features? Do these features improve productivity? Maybe or maybe not, it is difficult to measure the impact. However, in terms of the near future, to many users, one of the most important answers to these questions is speech recognition software. Speech recognition software is one of the most performance-demanding applications run on PCs. Each new version demands increasingly powerful processors, more RAM, and faster drives. Yet, each new software version improves in performance and capabilities. Also, unlike some software, speech recognition is a tool that can significantly benefit computer novices. Will the demand for speech recognition software (and other high-end software applications) drive firms to replace their existing stock of PCs en masse? A more likely scenario is that they will defer implementing speech recognition until the more powerful machines drop in price. Once firms switch to speech recognition, the PC replacement cycle will be driven more tightly by improvements in the software. The trends highlighted in this analysis also provide a powerful commentary on the issue of decentralization. The chip-level trends clearly indicate that increasingly powerful computers will be available at lower prices. This trend will encourage the expanding use of powerful devices into

208

GERALD V. POST

decentralized applications. Ultimately, the discussion is not an issue of PC versus server, but a question of what processing is best performed at the user interface, and what parts of the application need to be handled centrally. Increasing processing capabilities create new applications, which in turn demand more capabilities, creating a cycle that leads to the necessity of replacing computers on a regular basis. From a managerial perspective, you have only limited choice over whether to follow this cycle. The short-term option of ignoring new applications could lead to long-term management issues and employee training problems. Once an organization commits to updating hardware on a regular basis, the strategies examined here provide a reliable means of evaluating and simplifying the choices. As long as the basic hardware trends continue, these techniques should be valid. Will these trends continue?

8.

The Future

Can Moore's law continue? Can chip-level technologies continue to double capacities every 18 months? This question is beginning to receive more attention. In particular, power consumption and heat generation, along with quantum level effects, are predicted to cause problems [3, 4,29, 49-55]. However, for good reasons, after 35 years, businesses have come to rely on improved performance and declining costs. If these trends continue, they will support more powerful uses of computers and more ubiquitous applications. If they do not continue, alternative solutions must be found to handle the ever-increasing demands.

8.1

Limits to Lithography

A special issue of Scient(fic American examined the underlying physics and engineering questions related to perpetuating Moore's law. In particular Stix [56] discussed the complications facing chip manufacturers as they try to reduce feature sizes to 0.1 micron. In 2000, common chips (Pentium III/800) were being developed at 0.18 microns using excimer lasers at 193 nanometer wavelength. The generation before that utilized 0.25 micron features, so the move to 0.1 micron is only a few generations (or years) away. Given the current chip manufacturing lithography methodologies, the most immediate problems involve the need for precision lenses to focus the etching lasers, and ultimately the need to reduce the wavelength. Reducing wavelength raises a challenging set of manufacturing issues on reaching the X-ray level.


Ultimately, current methodologies can only be pushed to a certain limit. Even if they can be created, heat becomes an increasingly difficult problem, and linewidths become so small that essential electrical properties begin to fail. Pushing even further, quantum effects will interfere with the desired schematics. Most researchers agree that current methodologies are ultimately limited. Moore discussed many of these issues in 1997, and reached similar conclusions [10]. Between the physical limits and the increasing costs, we eventually run out of expansion potential. Some pundits have suggested we may reach that point in 10-15 years. That would constitute about six more generations of chips. If Moore's law holds over that time, capacities would increase by 26 or 64 times current levels. Certainly an important feat, but not necessarily enough to satisfy the needs of a large population demanding personalized real-time video editing and transmission. Yet, earlier forecasts of the demise of Moore's law have proven wrong. So far, engineers and scientists have found new methods to overcome the limitations. 8.2

Alternative Methodologies

Ultimately, the only way to surmount the limits of lithography is to find another technology [57]. Along with improvements in lithographic and deposition techniques, more radical research is progressing in optics, quantum physics, and biology. The optical research is probably the farthest along of the three. For example, Jordan and Heuring [58] described some basic progress and capabilities a decade ago. A computer operating on light offers several advantages over electrically based computers. In particular, light travels faster than electricity, there is minimal attenuation over reasonable distances, there is no problem with heat, and there is no interference generated from neighboring lines. While these properties have been beneficial for communication, there is considerable work to be done in creating optic-based memory or processor devices. In terms of chip size, quantum research is intriguing. Several researchers [59-62] are working on stable bi-state, transistor-replacement devices that utilize quantum properties. While single-unit quantum devices have been demonstrated, physicists still need to resolve the connection issues to be able to build devices that can handle computations. A few people have experimented with biological components, but with only limited success at this point [63, 64]. Theorists keep pointing to human neurons arguing that it should be possible to integrate biological and electrical components to reduce the size and increase the complexity of computational devices.

210

GERALD V. POST

Less esoteric options are more likely--particularly for the immediate future. Moore outlined some of these technologies in an interview in 1997 [10]. By stretching current manufacturing technologies, it should be possible to produce chips with feature sizes down to 0.13 microns. Even if physical or implementation limits are reached with current technology, designers can improve performance with more sophisticated instruction sets and structure. Similarly, even if individual chips reach limits, overall computer performance could be improved through parallel processing-increasing the number of processors on a machine to spread the work. Simple tasks do not benefit much from massively parallel computing, but more complex jobs of the future such as speech recognition and video processing can still benefit from multiple processors.

9.

Conclusions

To date, computer performance and prices have been driven by Moore's law, where capacity has doubled about every 18 months. In this growth environment, prices have fallen while performance increases. For over 35 years, this trend has altered the industry, providing faster, smaller, cheaper machines every year. Sales have moved from mainframes to minicomputers to personal computers, laptops, and handheld devices. While this trend has benefited both the computer industry and its customers, it leads to some difficult purchasing decisions. The centralized economies of the 1970s and 1980s gave way to increasingly rapid introductions of faster personal computers in the 1990s. While it seems useful to be able to buy ever faster machines, the continual introduction of new machines, along with applications that require the new performance, forces managers to adopt a strategy for replacing computers on a regular basis. Conflicts often arise between users who believe they can improve their productivity through newer machines, and cost-conscious managers who want to avoid unnecessary expenditures. Comparing various purchasing strategies demonstrates that some options are preferred to others. That is, strategies that cost more, but yield lower performance are generally unacceptable. Analyzing the 12 major strategies reveals that for desktop computer purchases through the 1990s, it was generally best to replace personal computers every three years. Depending on application needs, businesses will choose high, intermediate, or low-end desktops. The process of analyzing laptop purchase decisions is similar, but the results are different. In this case, the best strategies are to purchase high-end laptops and replace them when you need to improve performance.


211

Since most of the performance gains have been driven by improvements in chip manufacturing, physical limits will eventually restrict the gains available through current production techniques. Researchers and manufacturers are searching for new technologies that will provide the next breakthrough in performance. Advances in optical computing are probably the leading contenders, but results in quantum and biological computing demonstrate some potential for new technologies.

REFERENCES [1] Vijayan, J. (2000). "Outrageous fortune?" Computerworld, Jan. 10. [2] Moore, G. E. (1965). "Cramming more components onto integrated circuits". Electronics Magazine, 38, April 19, 114-117. [3] DeTar, J. (1997). "Gigascale integration hitting the wall?" Electronic News, 43, 14-15. [4] Moore, G. E. (1995). "Lithography and the future of Moore's law". Optical~Laser Microlithography VIII." Proceedings o/the SPIE, Feb. 20, 2-17. [5] Ross, P. E. (1996). "Moore's second law". Forbes, 157, March 25, 116-118. [6] Studt, T. (1995). "Moore's law continues into the 21st century". R&D, 37, Nov., 33-35. [7] Chandra, J., March, S., Mukherjee, S., Pape, W., Ramesh, R., Rao, H. R. and Waddoups, R. (2000). "Information systems frontiers". Communications of the ACM, 43, 71-79. [8] Economist (1997). "Not Moore's law: magnetic storage". 344(8025), 72-4. [9] Meieran, E. S. (1998). "21st century semiconductor manufacturing capabilities". Intel Technology Journal, Fourth quarter 1998. h t t p : / / d e v e t o p e r . i n t e t . c o m/ technology/i

t j/q41998/arti

c les/art

1.htm).

[10] Miller, M. J. (1997). "Interview: Gordon Moore, Inter'. PC Magazine, March 25, 16, 236-239. [11] Bell, G. (1984). "The mini and micro industries". Computer, 17, 14- 33. [12] Cale, E. G., Gremillion, L. L. and McKenney, J. L. (1979). "Price/performance patterns of US computer systems". Communications of the ACM, 22, 225-233. [13] Chow, G. C. (1967). "Technological changes and the demand for computers". American Economic Review, 57, 1117-1130. [14] Cole, R., Chen, Y. C., Barquin-Stolleman, J. A., Dulberger, E., Halvacian, N. and Hodge, J. H. (1986). "Quality-adjusted price indexes for computer processors and selected peripheral equipment." Survey of Current Business, 66, 41-50. [15] Ein-Dor, P. and Feldmesser, J. (1987). "Attributes of the performance of central processing units: a relative performance prediction model". Communications of the ACM, 30, 308- 317. [16] Kang, Y. M. (1989). "Computer hardware performance: production and cost function analyses". Communications of the ACM, 32, 586-593. [17] Sircar, S. and Dave, D. (1986). "The relationship between benchmark tests and microcomputer price". Communications of the A CM, 29, 212-217. [18] Sharpe, W. F. (1969). The Economics of Computers. Columbia University Press, New York. [19] Briody, D. (1999). "PC at a crossroads", hTfoworld, June 19. ( h t t p : / / w w w . i n f o w o r l d . com/art i c les/hn/xml/99/06/21/990621

h n p c x , xm l).

[20] Ein-Dor, P. (1985). "Grosch's law re-revisited: CPU power and the cost of computation". Communications of the ACM, 28, 142-151. [21] Grosch, H. A. (1953). "High speed arithmetic: the digital computer as a research tool". Journal of Optical Society of America, 43, 306-310.

212

GERALD V. POST

Grosch, H. A. (1975). "Grosch's Law revisited". Computerworld 8, 24. Grosch, H. A. (1979). "'On Grosch's Law". Communications o[the ACM, 22, 376. Knight, K. E. (1966). "Changes in computer performance". Datamation, 12, 40-54. Solomon, M. B., Jr. (1966). "Economies of scale and the IBM System/360". Communications of the ACM, 9, 435-440. [26] Kang, Y. M., Miller, R. B. and Pick, R. A. (1986). ~'Comments on 'Grosch's Law rerevisited: CPU power and the cost of computation" "'. Communications of the ACM, 29, 779-781. [27] Metcalfe, R. (1996). "Computer laws galore, but one is holding back the information age". InfoWorld, May 6, 18, 52. [28] Churbuck, D. and Samuels, G. (1996). '~Can IBM keep it up?" Forbes, 157, June 30, 142-145. [29] Schaller, R. R. (1997). "Moore's Law: past, present and future". IEEE Spectrum, 34, June, 52-59. [30] Mendelson, H. (1987). "Economies of scale in computing: Grosch's Law revisited". Communications of the A CM, 30, 1066-1072. [31] Benamati, J., Lederer, A. L. and Singh, M. (1997). "'The problems of rapid information technology change". SIGCPR '97, Proceedhlgs of the 1997 Con[erence on Computer Personnel Research, 24- 29. [32] Rai, A., Patnayakuni, R. and Nainika, P. (1997). "'Technology investment and business performance". Communications of the A CM, 40, 89- 97. [33] Oosterbeek, H. (1997). "Returns from computer use: a simple test on the productivity interpretation". Economic Letters, 55, 273. [34] Lehr, W. and Lichtenberg, F. R. (1998). "'Computer use and productivity growth in US federal government agencies, 1987-92". The Journal of Industrial Economics, 46, June, 257. [35] DiNardo, J. E. and Pischke, J. (1997). "The returns to computer use revisited: have pencils changed the wage structure too?" Quarterly Journal of Economics, 112, 291. [36] Harris, A. L. and Dave, D. S. (1994). "'Effects of computer system components on the price of notebook computers". In[brmation & Management, 27 (Sept), 151-160. [37] Solomon, M. B. (1970). ~'Economies of scale and computer personnel". Datamation, 16, March, 107-110. [38] Oldehoeft, A. E. and Halstead, M. H. (1972). "Maximum computing power and cost factors in the centralization problems". Communications o[the ACM, 15, Feb, 94-96. [39] Emigh, J. (1999). "Business quick study: total cost of ownership". Computerworld, December 20. [40] King, J. L. (1983). "Centralized versus decentralized computing: organizational considerations and management options". ComputhTg Surve)'s, 15, 319-349. [41] Petreley, N. (1999). "Down to the wire: total cost of ownership reduction may just be another impossible dream", h~foWorld, 21, Oct 4, 126. [42] O'Donnell, D. (1998). "TCO: don't let hidden IT expenses hurt your company". Software Magazine, 18, August, 20-27. [43] Seymour, J. (1998). "TCO: magic, myth, or shuck?" PC Magazine, 17, May 5, 93-94. [44] Jacobs, A. (1998). "Users struggle with TCO models". Computerworld, 32, Sept 21, 61. [45] Dryden, P. (1998). "'Futz factor' measurement tough to pin down in TCO". Computerworld, 32, 6. [46] Lewis, B. (1997). "The winding road to TCO includes calculations that are both tricky and useless". InfoWorld, 19, Nov. 3, 113. [47] Stavins, J. (1997). "Estimating demand elasticities in a differentiated product industry: the personal computer market". Journal of Economics and Business, 49, July, 347.

[22] [23] [24] [25]


213

[48] Francalanci, C. and Maggiolini, P. (1994). ~'Justifying the information technology budget within changing environments". SIGCPR '94. Proceedings of the 1994 Computer Personnel Research Conference on Rehlventing IS. Managing In[brmation Technology in Changing Organizations, 23- 34. [49] Barsan, R. (1999). "Moore's Law 2000". Electronic News, 45, 8. [50] De, V. and Borkar, S. (1999). "Technology and design challenges for low power and high performance". Proceedings 1999 A CM International Symposium on Low Power Electronics and Design, 163-168. [51] Holden, D. (1993). "Statute of limitations on Moore's Law?" Electronic News, 39 April 5, 1-2. [52] Lammers, D. (1998). "Moore's Law, circa 2004"'. Electronic Engineering Times, July 13, 24. [53] Mann, C. C. (2000). "The end of Moore's Law?" Technology Review, 103, May/June, 42-51. [54] Messina, P., Culler, D., Pfeiffer, W., Martin, W., Oden, J. T. and Smith, G. (1998). "Architecture". Communications of the ACM, 41, 36-44. [55] Sawicki, J. (2000). "Enhancement deemed critical in maintaining Moore's Law". Electronic Engineering Times, August 7, 60. [56] Stix, G. (1995). "Toward 'Point One'". Scientific American, 272, February, 90-95. [57] Packan, P. A. (1999). "Device physics: pushing the limits". Science, 285, 2079-2080. [58] Jordan, H. F. and Heuring, V. P. (1991). "Time multiplexed optical computers". Conference on High Performance Networking and Computing, Proceedings of the 1991 Conference on Supercomputing, 370-378. [59] Sanders, G. D., Kim, K. W. and Holton, W. C. (1999). "Optically driven quantum-dot quantum computer". Physical Review, 60, 4146-4150. [60] Steane, A. and Rieffel, E. (2000). "Beyond bits: the future of quantum information processing". Computer, 33, January, 38-45. [61] Rotman, D. (2000). "Molecular computing". Technology Review, 103, May/June, 52-59. [62] Waldrop, M. M. (2000). "Quantum computing". Technology Review, 103, May/June, 60-69. [63] Garfinkel, S. L. (2000). "Biological computing". Technology Review, 103, May/June, 70-79. [64] Regalado, A. (2000). "DNA computing". Technology Review, 103, May/June, 80-87.


Secure Outsourcing Of Scientific Computations MIKHAIL J. ATALLAH, K. N. PANTAZOPOULOS, JOHN R. RICE, AND EUGENE E. SPAFFORD CERIAS: Center for Education and Research in Information Assurance and Security Purdue University West Lafayette, IN 47907 USA email: {mja, [email protected]

Abstract We investigate the outsourcing of numerical and scientific computations using the following framework: A customer who needs computations done but lacks the computational resources (computing power, appropriate software, or programming expertise) to do these locally would like to use an external agent to perform these computations. This currently arises in many practical situations, including the financial services and petroleum services industries. The outsourcing is secure if it is done without revealing to the external agent either the actual data or the actual answer to the computations. The general idea is for the customer to do some carefully designed local preprocessing (disguising) of the problem and/or data before sending it to the agent, and also some local postprocessing of the answer returned to extract the true answer. The disguise process should be as lightweight as possible, e.g., take time proportional to the size of the input and answer. The disguise preprocessing that the customer performs locally to "hide" the real computation can change the numerical properties of the computation so that numerical stability must be considered as well as security and computational performance. We present a framework for disguising scientific computations and discuss their costs, numerical properties, and levels of security. We show that no single disguise technique is suitable for a broad range of scientific computations but there is an array of disguise techniques available so that almost any scientific computation could be disguised at a reasonable cost and with very high levels of security. These disguise techniques can be embedded in a very high level, easy-touse system (problem solving environment) that hides their complexity.

1.

Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.1 Outsourcing and Disguise . . . . . . . . . . . . . . . . . . . . . . . . . .

216 216

1Portions of this work were supported by Grants DCR-9202807 and EIA-9903545 from the National Science Foundation, and by sponsors of the Center for Education and Research in Information Assurance and Security. ADVANCES IN COMPUTERS, VOL. 54 ISBN 0-12-012154-9

2 1 5


216

2.

3

4.

5.

6.

MIKHAIL J. ATALLAH ET AL.

R e l a t e d W o r k in Cryptography . . . . . . . . . . . . . . . . . . . . . . . Other Differences Between Disguise and Encryption . . . . . . . . . . . . . 1.4 Four Simple Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . General Framework . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.1 Need for Multiple Disguises . . . . . . . . . . . . . . . . . . . . . . . . . 2.2 Atomic Disguises . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.3 Key Processing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.4 Data-Dependent Disguises . . . . . . . . . . . . . . . . . . . . . . . . . . 2.5 Disguise Programs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.2

217

1.3

219

Applications

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

3.1

Linear Algebra

3.2

Sorting

220 223 223 224 232 232 233 236

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

236

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

242

Template Matching in Image Analysis . . . . . . . . . . . . . . . . . . . . String Pattern Matching . . . . . . . . . . . . . . . . . . . . . . . . . . . Security Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.1 Breaking Disguises . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.2 Attack Strategies and Defenses . . . . . . . . . . . . . . . . . . . . . . . . 4.3 Disguise Strength Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . Cost Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.1 Computational Cost for the Customer . . . . . . . . . . . . . . . . . . . . 5.2 Computational Cost for the Agent . . . . . . . . . . . . . . . . . . . . . . 5.3 Network Costs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Cost Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.4 3.3

243

3.4

246 247 247 248 252 265 265 265 268 268

Conclusions

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

268

References

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

270

1. 1.1

Introduction

Outsourcing and Disguise

Outsourcing is a general procedure employed in the business world when one entity, the customer, chooses to farm out (outsource) a certain task to an external entity, the agent. We believe that outsourcing will become the common way to do scientific computation [1-4]. The reasons for the customer to outsource the task to the agent can be many, ranging from a lack of resources to perform the task locally to a deliberate choice made for financial or response time reasons. Here we consider the outsourcing of numerical and scientific computations, with the added twist that the problem data and the answers are to be hidden from the agent who is performing the computations on the customer's behalf. That is, it is either the customer who does not wish to trust the agent with preserving the secrecy of that information, or it is the agent who insists on the secrecy so as to protect itself from liability because of accidental or malicious (e.g., by a bad employee) disclosure of the confidential information.

SECURE OUTSOURCINGOF SCIENTIFICCOMPUTATIONS

217

The current outsourcing practice is to operate '~in the clear", that is, by revealing both data and results to the agent performing the computation. One industry where this happens is the financial services industry, where the proprietary data includes the customer's projections of the likely future evolution of certain commodity prices, interest and inflation rates, economic statistics, portfolio holdings, etc. Another industry is the energy services industry, where the proprietary data is mostly seismic, and can be used to estimate the likelihood of finding oil or gas if one were to drill in a particular geographic area. The seismic data is so massive that doing matrix computations on such large data arrays is beyond the computational resources of even the major oil service companies, which routinely outsource these computations to supercomputing centers. We consider many science and engineering computational problems and investigate various schemes for outsourcing to an outside agent a suitably disguised version of the computation in such a way that the customer's information is hidden from the agent, and yet the answers returned by the agent can be used to obtain easily the true answer. The local computations should be as minimal as possible and the disguise should not degrade the numerical stability of the computation. We note that there might be a class of computations where disguise is not possible, those that depend on the exact relationships among the data items. Examples that come to mind include (a) ordering a list of numbers, (b) typesetting a technical manuscript, or (c) visualizing a complex data set, (d) looking for a template in an image. However, example (a) can be disguised [5], and disguising (d) is actually a (quite nontrivial) contribution of this chapter, so perhaps the others might be disguised also. To appreciate the difficulty of (d), consider the obvious choice for hiding the image, i.e., adding a random matrix to it: What does one do to the template so that the disguised version of the template occurs in the disguised version of the image? It looks like a chicken and egg problem: if we knew where the template occurs then we could add to it the corresponding portion of the image's random matrix (so that the occurrence is preserved by the disguise), but of course we do not know where it occurs--this is why we are outsourcing it in the first place. 1.2

Related W o r k in C r y p t o g r a p h y

The techniques presented here differ from what is found in the cryptography literature concerning this kind of problem. Secure outsourcing in the sense of [6] follows an information-theoretic approach, leading to elegant negative results about the impossibility of securely outsourcing computationally intractable problems. In contrast, our methods are geared towards scientific computations that may be solvable in polynomial time (e.g.,

218


solution of a linear system of equations) or where time complexity is undefined (e.g., the work to solve a partial differential equation is not related to the size of the text strings that define the problem). In addition, the cryptographic protocols literature contains much that is reminiscent of the outsourcing framework, with many elegant protocols for cooperatively computing functions without revealing information about the functions' arguments to the other party (cf. the many references in, for example, Schneider [7] and Simmons [8]. The framework of the privacy homomorphism approach that has been proposed in the past [9] assumes that the outsourcing agent is used as a permanent repository of the data, performing certain operations on it and maintaining certain predicates, whereas the customer needs only to decrypt the data from the external agent's repository to obtain from it the real data. Our framework is different in the following ways: 9 The customer is not interested in keeping data permanently with the outsourcing agent; instead, the customer only wants to use temporarily its superior computational resources. 9 The customer has some local computing power that is not limited to encryption and decryption. However, the customer does not wish to do the computation locally, perhaps because of the lack of computing power or appropriate software or perhaps because of economics. Our problem is also reminiscent of the server-aided computation work in cryptography, but there most papers deal with modular exponentiations and not with numerical computing [4, 7, 10-16] Our problems and techniques afford us (as will be apparent below) the flexibility of using one-time-pad kinds of schemes for disguise. For example, when we disguise a number x by adding to it a random value r, then we do not re-use that same r to disguise another number y (we generate another random number for that purpose). If we hide a vector of such x's by adding to each a randomly generated r, then we have to be careful to use a suitable distribution for the r's (more on this later). The random numbers used for disguises are not shared with anyone: they are merely stored locally and used locally to ~'undo" the effect of the disguise on the disguised answer received from the external agent. Randomness is not used only to hide a particular numerical value, but also to modify the nature of the disguise algorithm itself, in the following way. For any part of a numerical computation, we will typically have more than one alternative for performing a disguise (e.g., disguising problem size by shrinking it, or by expanding it, in either case by a random amount). Which method is used is also selected randomly.

SECUREOUTSOURCINGOF SCIENTIFICCOMPUTATIONS

219

Note that the above implies that, if our outsourcing schemes are viewed as protocols, then they have the feature that one of the two parties in the protocol (the external agent) is ignorant of which protocol the other party (the customer) is actually performing. This is the case even if the external agent has the source code, so long as the customer's seeds (of the generators for the randomness) are not known. Throughout this chapter when we use random numbers, random matrices, random permutations, random functions (e.g., polynomials, splines, etc., with random coefficients), etc., it is assumed that each is generated independently of the others, and that quality random number generation is used (cf. [17, Chap. 23]; [18, Chap. 12]; [19,20]). The parameters, types, and seeds of these generators provide the keys to the disguises. We show how to use a single key to generate multiple keys which are "independent" and which simplify the mechanics of the disguise techniques. This key is analogous to the key in encryption but the techniques are different.

1.3

Other Differences Between Disguise and Encryption

The following simple example further illustrates the difference between encryption and disguise. Consider a string F of text characters that are each represented by an integer from 1 to 256 (i.e., these are a byte string). Suppose that F1 is an encryption of F with one of the usual encryption algorithms. Suppose that F2 is a disguise of F that is created as follows: (1) choose a seed (the disguise key) for a uniform random number generator and create a sequence G of random integers between 0 and 128; (2) set ~ - F + G. Assume now that F is a constant (the single value 69) string of length N and the agent wishes to discover the value of this constant. It is not possible to discover from F1 the value 69 no matter how large N is. However, it is possible to discover 69 from F2 if N is large enough. Since G is uniform, the mean of the values of G converge to 64 as N increases and thus, as N increases, the mean of F2 converges to 133 + 64 + 69 and the rate of convergence is order 1 / v ~ . Thus, when 1/x/N is somewhat less than 1/2, we know that the mean of F2 is 133 and that the character is 69. An estimate of N is obtained by requiring that 128/x/N be less than 1/2 or N be more than about 60-70 000. The point of this example is that the encryption cannot be broken in this case without knowing the encryption k e y - - e v e n if one knows the encryption method. However, the disguise can be broken without knowing the key provided the disguise method is known. Of course, it follows that one should not use a simplistic disguise and we provide disguise techniques for scientific computations with security comparable, one believes, to that of the most secure encryptions.

220


1.4 Four Simple Examples The nature and breadth of the disguises possible are illustrated by the following.

1.4. 1 Matrix multiplication Consider the computation of the product of two n x n matrices M1 and M2. We use ~Sx,v to denote the Kronecker delta function that equals 1 if x = y and 0 if x -r y. The disguise requires six steps: 1. Create (i) three random permutations rVl, rr2, and 7r3 of the integers {1, 2, ..., n}, and (ii) three sets of nonzero random numbers {C~l, c~2, ..., c~,,}, {/31,/32, ...,/3,,}, and {71,72, ..., 7,,}. 2. Create matrices P1, P2, and P3 where P l ( i , j ) - oq~5~,{i),j, P2(i,j)--/3i~Srre(i).j, and P3(i,j)-Ti~5~3{i).j. These matrices are readily invertible, e.g. P l l ( i , j ) - (~j)-l~5~,/i).j. 3. Compute the matrix X - PIM1P21. We have X(i,j)(oq//3j)M1 (rrl (i), 712(J')). 4. Compute Y - P2M2P3- 1 9 5. Send X and Y to the agent which computes the product Z - X Y - (P1M1P]I)(P2M2P~ l) - PIM1M2Pj 1 and sends Z back. 6. Compute locally, in O(n 2) time, the matrix P~IzP3, which equals

M1M2. This disguise may be secure enough for many applications, as the agent would have to guess two permutations (from the (n!) 2 possible such choices) and 3n numbers (the c~i,/3i, 7i) before it can determine M1 or M2. This example is taken from Atallah et al. [5] where the much more secure disguise of Section 3.1.1 is presented. Both of these disguises require O(n 2) local computation, which is the minimum possible since the problem involves O(n 2) data. The outsourced computations require O(n 3) operations.

1.4.2

Quadrature

The objective is to estimate

SECURE OUTSOURCING OF SCIENTIFIC COMPUTATIONS

221

with accuracy e p s . The disguise is as follows: 1. Choose xl = a, x7 = b and five ordered, random numbers xi in [a, b] and seven values vi with min ] f (x) [ ~ M1 ~<M2 ~ max ] f (x) [. (M1 and M2 are only estimated roughly.) 2. Create the cubic spline g(x) with knots xi so that g(xi)= vi. 3. Integrate g(x) exactly from a to b to obtain 11. 4. Send g ( x ) + f ( x ) and e p s to the agent for numerical quadrature and receive the value 12 back. 5. Compute 1 2 - 11 which is the answer. All the computations made of e ps, and depend weakly of the previous example are One has to determine 12 disguise.

locally are simple, of fixed work, independent on f(x). The random vectors and matrices replaced by a " r a n d o m " smooth function. random numbers in order to break the

1.4.3 Edge Detection The objective is to determine the edges in a picture represented by an n x n array of pixel values p(x,y) between 0 and 100 000 on the square 0 ~<x, y ~< 1. This disguise is as follows: 1. Set xl, yl - - 0 , Xl0 , Yl0 = l, choose two sets of eight ordered, random numbers with 0 < x;, y; < 1, choose 100 random values 0 ~

Advances in Computers, Volume 54: Trends in Software Engineering

Advances in Computers, Volume 54: Trends in Software Engineering

Advances in Computers, Volume 54: Trends in Software Engineering

Advances in Computers, Volume 62: Advances in Software Engineering

Advances in Software Engineering

Advances in Software Engineering

Advances in Immunology Volume 54

Advances in Agronomy, Volume 54

Advances in Computers, Volume 49

Advances in Computers, Volume 55

Advances in Computers, Volume 56

Advances in Computers, Volume 19

Advances in Computers, Volume 12

Advances in Computers, Volume 43

Advances in Computers, Volume 28

Advances in Computers, Volume 31

Advances in Computers, Volume 9

Advances in Computers, Volume 11

Advances in Computers, Volume 7

Advances in Computers, Volume 3

Advances in Computers, Volume 17

Advances in Computers, Volume 34

Advances in Computers, Volume 47

Advances in Computers, Volume 29

Advances in Computers, Volume 14

Advances in Computers, Volume 18

Advances in Computers, Volume 80

Advances in Computers, Volume 20

Advances in Computers, Volume 2

Advances in Computers, Volume 8

Advances in Computers, Volume 38

Advances in Computers, Volume 54: Trends in Software Engineering