Component-Based Software Engineering : Putting the Pieces Together

by Heineman, George T.; Councill, William T.

• ISBN13: 9780201704853
• ISBN10: 0201704854
• Format: Hardcover
• Copyright: 2001-01-01
• Publisher: Addison-Wesley Professional

Summary

Software components are increasingly central to efficient, cost-effective software development. In this book, the world's leading experts on component software development come together to present the field's state of the art, and to offer new insights into the key challenges of component architecture and reuse. With original contributions by leaders such as Ivar Jacobson, Martin Griss, Len Bass, Paul Clements, Don Reifer, and Will Tracz, this carefully edited book is the "first word" on components: a tool for helping practitioners get the most out of all their component-based resources. It offers new insight for deciding whether and how to implement component-based development strategies; as well as a clear understanding of the obstacles to successful component development, and "best practices" responses. The contributors review diverse approaches to component development, present state-of-the-art processes for building component-based systems, and introduce new research directions that will impact component development in the coming decade. For software developers, designers and architects; business analysts; technology executives; computer science and software engineering researchers; project managers; QA specialists, and other professionals.

Table of Contents

Foreword	xiii
Introduction	xvii
Methodology and Organization	xxv
Preface	xxxiii
Acknowledgments	xli
PART I: COMPONENT DEFINITION	1	(74)
Definition of a Software Component and Its Elements	5	(16)
Bill Council
George T. Heineman
The Component Industry Metaphor	21	(12)
Hedley Apperly
Component Models and Component Services: Concepts and Principles	33	(16)
Rainer Weinreich
Johannes Sametinger
An Example Specification for Implementing a Temperature Regulator Software Component	49	(26)
Janet Flynt
Jason Mauldin
Summary	65	(6)
References	71	(4)
PART II: THE CASE FOR COMPONENTS	75	(96)
The Business Case for Components	79	(20)
John Williams
COTS Myths and Other Lessons Learned in Component-Based Software Development	99	(14)
Will Tracz, Ph.D.
Planning Team Roles for CBD	113	(18)
Paul Allen
Stuart Frost
Common High-Risk Mistakes	131	(12)
Wojtek Kozaczynski
CBSE Success Factors: Integrating Architecture, Process, and Organization	143	(28)
Martin L. Griss, Ph.D.
Summary	161	(6)
References	167	(4)
PART III: SOFTWARE ENGINEERING PRACTICES	171	(68)
Practices of Software Engineering	175	(14)
George T. Heineman
From Subroutines to Subsystems: Component-Based Software Development	189	(10)
Paul C. Clements
Status of CBSE in Europe	199	(14)
Barry McGibbon
CBSE in Japan and Asia	213	(26)
Mikio Aoyama
Summary	227	(6)
References	233	(6)
PART IV: THE DESIGN OF SOFTWARE COMPONENT INFRASTRUCTURES	239	(128)
Software Components and the UML	243	(20)
Kelli Houston
Davyd Norris
Component Infrastructures: Placing Software Components in Context	263	(22)
Steve Latchem
Business Components	285	(22)
James Carey
Brent Carlson
Components and Connectors: Catalysis Techniques for Designing Component Infrastructures	307	(14)
Alan Cameron Wills
An OPEN Process for Component-Based Development	321	(20)
Brian Henderson-Sellers
Designing Models of Modularity and Integration	341	(26)
Kevin J. Sullivan
Summary	355	(8)
References	363	(4)
PART V: FROM SOFTWARE COMPONENT INFRASTRUCTURES TO SOFTWARE SYSTEMS	367	(64)
Software Architecture	371	(18)
Judith A. Stafford
Alexander L. Wolf
Software Architecture Design Principles	389	(16)
Len Bass
Product-Line Architectures	405	(26)
Martin L. Griss
Summary	421	(4)
References	425	(6)
PART VI: THE MANAGEMENT OF COMPONENT-BASED SOFTWARE SYSTEMS	431	(122)
Measurement and Metrics for Software Components	435	(18)
Jeffrey S. Poulin
Implementing a Practical Reuse Program for Software Components	453	(14)
Donald J. Reifer
Selecting the Right COTS Software: Why Requirements Are Important	467	(12)
Cornelius Ncube
Neil Maiden
Building Instead of Buying: A Rebuttal	479	(6)
George T. Heineman
Software Component Project Management	485	(14)
Bill Councill
The Trouble with Testing Components	499	(14)
Elaine J. Weyuker
Configuration Management and Component Libraries	513	(14)
Hedley Apperly
The Evolution, Maintenance, and Management of Component-Based Systems	527	(26)
Mark Vigder
Summary	541	(8)
References	549	(4)
PART VII: COMPONENT TECHNOLOGIES	553	(116)
Overview of the CORBA Component Model	557	(16)
Nanbor Wang
Douglas C. Schmidt
Carlos O'Ryan
Overview of COM+	573	(16)
Tim Ewald
Overview of the Enterprise JavaBeans Component Model	589	(18)
David Blevins
Bonobo and Free Software GNOME Components	607	(14)
Michael Meeks
Choosing Between COM+, EJB, and CCM	621	(20)
Andy Longshaw
Software Agents as Next Generation Software Components	641	(28)
Martin L. Griss
Summary	659	(4)
References	663	(6)
PART VIII: LEGAL AND REGULATORY COMPONENT ISSUES	669	(70)
Component-Based Software Engineering As a Unique Engineering Discipline	673	(20)
John Speed
Bill Councill
George T. Heineman
The Future of Software Components: Standards and Certification	693	(16)
Janet Flynt
Manoj Desai
Commercial Law Applicable to Component-Based Software	709	(10)
Stephen Y. Chow
The Effects of UCITA on Software Component Development and Marketing	719	(20)
Stephen Y. Chow
Summary	731	(6)
References	737	(2)
PART IX: CONCLUSION	739	(38)
Summary	741	(12)
Bill Councill
George T. Heineman
The Near-Term Future of Component-Based Software Engineering	753	(24)
Hedley Apperly
Grady Booch
Bill Councill
Martin Griss
George T. Heineman
Ivar Jacobson
Steve Latchem
Barry McGibbon
Davyd Norris
Jeffrey Poulin
References	775	(2)
Glossary and Acronyms	777	(10)
About the Editors	787	(2)
About the Authors	789	(12)
Index	801

Excerpts

This book is about the processes required to implement component-based development (CBD). Many software development organizations throughout the world have learned to recognize that software development is an engineering activity. Just as CBD is an evolutionary phase emerging from the programming paradigms that preceded it, component-based software engineering (CBSE) is both a subset, as well as an extension, of current software engineering practices. In the same way that civil engineers have established standardized, time-tested engineering principles to build bridges with reusable parts, component-based software engineers must define and describe processes to assure timely completion of high quality, complex software systems that are composed of a variety of pre-built software components. In the infancy of software development, programmers focused on structured techniques and procedural programming. Structured techniques defined a system through the information it received as input and the output it produced. Software development advanced with the advent of data modeling, which mapped the flow of complex data and information within a system, and presented a step towards "real world" modeling. Object-orientation showed developers how to design units of code based on the perceived metaphor of "real world" functionality. The latest advance in software development, CBD, promises the possibility of extending the real world approach to create well-specified parts and to incorporate legacy code "wrapped" as components. An edited text, our approach was to select well-respected authors and researchers in the field--throughout the world--and collectively determine the state-of-the-art of CBSE. Our goals are to establish The first state-of-the-art text on CBSE The degree of empiricism that drives CBSE endeavors The number of domain areas that comprise CBSE The depth and breadth of knowledge of each domain area The content of the domain areas in capsule format supported by considerable references and a Web site that continually is updated new material for chapters and new references A reference book that would be updated every two to three years, providing requested unpublished chapters about the state-of-the-art of CBSE with increasing emphasis on empiricism The issues that CBSE faces are reflected in the sections that encapsulate the most cohesive chapters. The issues in numerical order are: Component Definition:Many definitions have been offered and cited repeatedly; yet no definition we encountered in an exhaustive literature review met our criteria for rigor, as opposed to description; most purported definitions were circular in reference. The Case for Components:The transition from other forms of development, generally object-oriented design and development to CBD and CBSE must consider a variety of risks and how to mitigate the risks. Cultural, budgetary, process, and numerous other factors must be considered before undertaking CBD and CBSE. Success and failure stories should be considered before even implementing a pilot project. Software Engineering Practices:What software engineering practices impact positively on CBSE? What software engineering processes affect CBSE negatively? What can we learn from the history of the technical history of software development that applies to the design and implementation of components today? The history of software engineering emphasized engineering in the development of software; yet, 40 percent of software projects are not completed. What can engineering teach us about developing software as complex as components. What can we learn from the European Union and Japan that would positively affect the design and assembly of components in the United States and elsewhere throughout the world? The Design of Software Component Infrastructures:Numerous models are available for developing component infrastructures. The Unified Modeling Language (UML) is the prevalent model, or more appropriately, modeling language. Still, there are various methods for designing software component infrastructures, establishing metamodels to ensure comprehensive component tailorable processes, and integrating component models. From Software Component Infrastructures to Software Systems:While software component infrastructure is rigorously defined, the contributors to this section do not offer a rigorous definition of software architecture. Engineers recognize incremental and refined levels of design; software architects, whom have had little impact outside academia, offer differing perspectives of their field, most of which is descriptive only. The Management of Component-Based Software Systems:With 40 percent of software projects canceled before completion and 33 percent of the remaining projects affected by time and cost overruns, as well as changes in scope, the technologically more complex CBD and CBSE will require more technically and engineering management trained managers. Will Frederick Taylor''s "one best way" that influenced all disciplines of engineering and much of business, as well, have an impact on CBSE? That is, will the discipline accept that large problems can be broken into smaller problems, each with one and only one best solution? Component Technologies:A limited number of component technologies exist. COM+, CORBA, EJB, Bonobo, software agents all have a place depending on an organization''s short-term and long-term needs. Which component technology or technologies will benefit the development of your component-based application? How should you evaluate the technologies to assure your organization meets its needs and does not make a long-term mistake? Legal and Regulatory Issues:Probably one of the most important sections in the book, this section is not the dry, legal drivel you might expect. The issues of licensure and organizational certification are explored. The benefits for certification are likely greater for employers than you might think. Voluntary or business-to-business third-party certification is described. Are the advantages obvious? Commerce in software components are presented historically and currently. Methods of protection for Component producers Component consumers Purchasing end-users are presented. Since 99 percent of all businesses in the United States are small businesses many, if not most component producers and consumers are small businesses. How do you protect your company when conducting commerce with larger businesses? Because of the diversity of subjects that comprise current CBSE, we requested the most knowledgeable participants in CBSE''s various sub-disciplines to write concise chapters describing the essence of their field of endeavor or study. Therefore, this book is not a "how-to" book or a handbook. It is an edited text that clearly and concisely identifies the level of sophistication achieved by CBSE at the time of the book''s publication. Contributions Many software engineers contributed to the book. A simple glance through the table of contents shows the wide-ranging content presented by many educators, practitioners, and others who have been involved with component-based technology. To achieve consensus, we sought authors with highly divergent and often conflicting views to present their perspectives on CBSE; to provide diversity, we ensured that no author contributed more than three chapters. The authors'' writing assignments, despite their uniformly remarkable knowledge of the particular subject matter, were exceptionally difficult. Authors were asked to distill vast knowledge about a topic into no more than 10 book pages. It is generally easier to write a comprehensive journal article