Component-Based Software Engineering: Putting the Pieces Together [Hardcover]

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:

1. 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.
2. 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.
3. 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?
4. 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.
5. 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.
6. 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?
7. 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?
8. 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.

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 or a book than to condense and refine a well known subject to a few pages. Nevertheless, the authors contributed their chapters, presenting just enough information--that is, the essence of their work--for you to make well-informed decisions about CBSE.

Henry Petroski, in his Engineering of Dreams (Vantage Books, 1995), described the work of James Buchanan Eads, a pioneer in the engineering and construction of highly complex bridges. As editors, we have been inspired by the following quote attributed to this nineteenth-century bridge builder to his company's board:

I have deemed it proper that everything of interest connected with my department should be placed in such form as to be clearly understood, not alone by your stockholders, but also by every person of ordinary intelligence in the community.

The book is divided into parts consisting of a part introduction, a few chapters, and the editors' summary. Each section is intended to be a model of conciseness and clarity of the particular CBSE-related subject. All sections of the book are relevant for those interested in CBSE. No section serves as precursor for any other section. Sections are self-contained; that is, they can be read independently and provide usable information without the need to read any other section. Some chapters within the sections are contentious and two or more authors present radically different views. Therefore, you may need to read multiple chapters to understand both sides of an argument. By comparing and contrasting the range of CBSE perspectives, your options are increased, thus enabling you to make decisions that are more effective.

We expect that you will read a section, or a chapter or two, and then, subsequently, pick up the book again to learn and metabolize more. Similar to a handbook, it is not a text that most will read from cover to cover over a few days or weeks. Therefore, the path you take as you use the book is the one that makes most sense for you or your organization at the particular period when you read it.

We strongly recommend that you read Part I, a section that was developed by a consensus of experts who had previously used various definitions of software component. There are many definitions concerning the term, software component. You might have your favorite, but the book uses one set of definitions throughout the book. Since this section served as the starting point for all authors, you will benefit by understanding the term as discussed and negotiated tirelessly by the authors who struggled to achieve a consensus definition.

We have designed the book for the following, diverse audiences, listed alphabetically:

• Business analysts and software designers will learn how to make and support software component-based build versus buy decisions. Methods for diagramming and communicating rich semantics concerning components are provided. We believe that analysts and designers are most likely to use the book most frequently. Therefore, this book was not developed as a "how-to" text for building software components Rather it was designed to assist those involved throughout the life cycle to determine collectively when and whether CBD can be reasonably implemented and how to communicate correctly and effectively to managers and developers the most adept component structure that will meet users' needs. Part VI, The Management of Component-Based Software Systems, is an excellent place to start your adventure in CBSE.
• Chief executives and senior technology executives of independent software vendors, as well as chief information officers, have been sold new technologies repeatedly. Generally, none of the new methods, processes or applications was a panacea. This book does not promote component-based technologies. While most authors and the co-editors believe that implementation of software components development is beneficial, you will discover the many "ifs" required to make software component-based development work for you, and under what conditions it can be successfully completed. We recommend that executives and managers will benefit most by initially reading Part II, The Case for Components, and Part VI, The Management of Component-Based Software Systems.
• Computer science and software engineering academicians can use this book to teach current CBSE practices and to develop directions for research on CBD or CBSE. Each part's summary describes areas required for research to enhance the state-of-the-art, as well as to enable the discipline of software engineering to advance as an engineering profession. Additionally, the editors shall present opportunities for research that will lead to the successful implementation of CBSE by students and their future employers. The book can also be used as a supplementary text on CBSE. As educators, your diverse interests will determine where you start to read and what you desire to acquire from your reading.
• Software developers can learn the strengths and pitfalls of CBD and CBSE, as well as how to make effective decisions about what component technologies to implement and when and how to influence management to adopt an appropriate component-based project plan. Both Part VI, The Management of Component-Based Software Systems, and Part VII, Component Technologies, will assist you most initially as you consider implementing or revising a CBD project.
• Software engineers and project managers can gain broad knowledge of the complexities of the component-based software life cycle. In reality, this book is written especially for you. Since software engineering as a profession is insufficiently immature to support a comprehensive handbook, this edited text serves as a precursor for the discipline, because it explores only a segment of the field in an extensive state-of-the-art manner. We anticipate that you will use this book as a reference both before and repeatedly during the implementation your first component-based project, as well as throughout your experience with CBD. Prior to this book, you were forced to read many books and numerous articles to learn about CBSE. We have collected all this expertise to enable you to learn what you need from one place.
• Software testers and quality assurance analysts often have a limited set of concerns and that is covered in Part VI, The Management of Component-Based Software Systems. We believe, however, that software testers should be involved in every phase of an iterative and incremental life cycle. Therefore, knowledge of all phases of the life cycle will enable you to become a more informed and competent tester of software components, as well as to know what issues will arise that present particular test-related problems.

As editors, we had two primary goals. The first, naturally, was to inform you as clearly and concisely about the state-of-the-art of CBSE. The second goal was considerably more difficult, but just as important. Both of us agreed that the book should read as if it were written by one author. With 45 authors and 42 chapters, assuring a single style was a considerable task. We strongly believed, however, that you would be able to learn more about the field of CBSE if we ensured that consistent terms were used, and a consistent writing style was used throughout. We hope that you find your reading experience a useful and informative one.