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) |
|
|
|
|
|
|
|
|
|
The Component Industry Metaphor |
|
|
21 | (12) |
|
|
|
|
|
Component Models and Component Services: Concepts and Principles |
|
|
33 | (16) |
|
|
|
|
|
|
|
|
|
An Example Specification for Implementing a Temperature Regulator Software Component |
|
|
49 | (26) |
|
|
|
|
|
|
|
|
|
|
65 | (6) |
|
|
71 | (4) |
PART II: THE CASE FOR COMPONENTS |
|
75 | (96) |
|
The Business Case for Components |
|
|
79 | (20) |
|
|
|
|
|
COTS Myths and Other Lessons Learned in Component-Based Software Development |
|
|
99 | (14) |
|
|
|
|
|
Planning Team Roles for CBD |
|
|
113 | (18) |
|
|
|
|
|
|
|
|
|
Common High-Risk Mistakes |
|
|
131 | (12) |
|
|
|
|
|
CBSE Success Factors: Integrating Architecture, Process, and Organization |
|
|
143 | (28) |
|
|
|
|
|
|
161 | (6) |
|
|
167 | (4) |
PART III: SOFTWARE ENGINEERING PRACTICES |
|
171 | (68) |
|
Practices of Software Engineering |
|
|
175 | (14) |
|
|
|
|
|
From Subroutines to Subsystems: Component-Based Software Development |
|
|
189 | (10) |
|
|
|
|
|
|
199 | (14) |
|
|
|
|
|
|
213 | (26) |
|
|
|
|
|
|
227 | (6) |
|
|
233 | (6) |
PART IV: THE DESIGN OF SOFTWARE COMPONENT INFRASTRUCTURES |
|
239 | (128) |
|
Software Components and the UML |
|
|
243 | (20) |
|
|
|
|
|
|
|
|
|
Component Infrastructures: Placing Software Components in Context |
|
|
263 | (22) |
|
|
|
|
|
|
285 | (22) |
|
|
|
|
|
|
|
|
|
Components and Connectors: Catalysis Techniques for Designing Component Infrastructures |
|
|
307 | (14) |
|
|
|
|
|
An OPEN Process for Component-Based Development |
|
|
321 | (20) |
|
|
|
|
|
Designing Models of Modularity and Integration |
|
|
341 | (26) |
|
|
|
|
|
|
355 | (8) |
|
|
363 | (4) |
PART V: FROM SOFTWARE COMPONENT INFRASTRUCTURES TO SOFTWARE SYSTEMS |
|
367 | (64) |
|
|
371 | (18) |
|
|
|
|
|
|
|
|
|
Software Architecture Design Principles |
|
|
389 | (16) |
|
|
|
|
|
Product-Line Architectures |
|
|
405 | (26) |
|
|
|
|
|
|
421 | (4) |
|
|
425 | (6) |
PART VI: THE MANAGEMENT OF COMPONENT-BASED SOFTWARE SYSTEMS |
|
431 | (122) |
|
Measurement and Metrics for Software Components |
|
|
435 | (18) |
|
|
|
|
|
Implementing a Practical Reuse Program for Software Components |
|
|
453 | (14) |
|
|
|
|
|
Selecting the Right COTS Software: Why Requirements Are Important |
|
|
467 | (12) |
|
|
|
|
|
|
|
|
|
Building Instead of Buying: A Rebuttal |
|
|
479 | (6) |
|
|
|
|
|
Software Component Project Management |
|
|
485 | (14) |
|
|
|
|
|
The Trouble with Testing Components |
|
|
499 | (14) |
|
|
|
|
|
Configuration Management and Component Libraries |
|
|
513 | (14) |
|
|
|
|
|
The Evolution, Maintenance, and Management of Component-Based Systems |
|
|
527 | (26) |
|
|
|
|
|
|
541 | (8) |
|
|
549 | (4) |
PART VII: COMPONENT TECHNOLOGIES |
|
553 | (116) |
|
Overview of the CORBA Component Model |
|
|
557 | (16) |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
573 | (16) |
|
|
|
|
|
Overview of the Enterprise JavaBeans Component Model |
|
|
589 | (18) |
|
|
|
|
|
Bonobo and Free Software GNOME Components |
|
|
607 | (14) |
|
|
|
|
|
Choosing Between COM+, EJB, and CCM |
|
|
621 | (20) |
|
|
|
|
|
Software Agents as Next Generation Software Components |
|
|
641 | (28) |
|
|
|
|
|
|
659 | (4) |
|
|
663 | (6) |
PART VIII: LEGAL AND REGULATORY COMPONENT ISSUES |
|
669 | (70) |
|
Component-Based Software Engineering As a Unique Engineering Discipline |
|
|
673 | (20) |
|
|
|
|
|
|
|
|
|
|
|
|
|
The Future of Software Components: Standards and Certification |
|
|
693 | (16) |
|
|
|
|
|
|
|
|
|
Commercial Law Applicable to Component-Based Software |
|
|
709 | (10) |
|
|
|
|
|
The Effects of UCITA on Software Component Development and Marketing |
|
|
719 | (20) |
|
|
|
|
|
|
731 | (6) |
|
|
737 | (2) |
PART IX: CONCLUSION |
|
739 | (38) |
|
|
741 | (12) |
|
|
|
|
|
|
|
|
|
The Near-Term Future of Component-Based Software Engineering |
|
|
753 | (24) |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
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