COMPONENT-BASED SOFTWARE ENGINEERING
Ouvrage 9780201704853 : COMPONENT-BASED SOFTWARE ENGINEERING
Component-Based Software Engineering (CBSE) is now the
way to produce software fast, with less effort, of
high
quality--not just the first time a product is
released but for its
entire life. More and more it is being applied to
industrial
strength and mission-critical software. It is
becoming the indispensable element in the
mainstream of the software world....The book you are
now holding is the first handbook-like
volume to present this state of the art.
--Ivar Jacobson, from the Foreword
Building large-scale and complex software systems
from available parts is an emerging strategy in
industry. Its goals, among others, are to
consistently increase return on investment and time to
market, while assuring higher quality and
reliability than can be achieved through current software
development. Written by leading experts from around
the world, this book presents the latest
concepts and practices in CBSE. While detailing both
the advantages and the limitations of CBSE,
the book's underlying aim is to define this new
field, to frame the discussion, and to ensure that
managers and engineers have the background they need
to ask good questions and make informed
decisions about components.
Beginning with some carefully wrought definitions,
the book moves on to cover nearly every aspect
of component engineering--from software engineering
practices to the design of software
component infrastructures, technologies, and
systems. The book includes specific examples of
CBSE successes and failures, and provides a balanced
overview of the complexities of the
component-based software life cycle.
This timely and comprehensive volume:
Explains precisely what CBSE is and why it is
as important to software development as the
assembly line was to the industrial revolution
Shows how to avoid common mistakes while
succeeding with difficult and important cultural,
budgetary, and process issues
Presents new CBSE procedures to ensure good
software development practices
Describes a layered method for designing and
building complex distributed component
systems using the Unified Modeling Language
Covers common component technologies, such as
CORBA CCM, Transactional COM+,
EJB, and much more
Presents the legal and regulatory challenges of
marketing and purchasing components
Component-Based Software Engineering is the most
definitive collection of expertise ever
assembled on this growing technology, and a book
that must be read and referred to by anyone
working in CBSE or considering doing so. To provide
updates to this book, and to stimulate further
discussion of the issues it covers, the editors
maintain a Web site dedicated to CBSE
(http://www.cbseng.com).
Preface
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.
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 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.
Who Should Read This Book, And Why
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.
Our Goals
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.
Bill Councill
George T. Heineman
About the Authors
George T. Heineman
George T. Heineman is an Assistant Professor of
Computer Science at Worcester Polytechnic
Institute (WPI). He has worked as a Research
Scientist at IBM Center for Advanced Studies
(Toronto, Canada), Bull Electronics, and AT&T Bell
Laboratories. He has consulted for Genetics
Institute (Cambridge, MA).
Prof. Heineman received a prestigious National
Science Foundation (NSF) Early Faculty Career
Development Award (CAREER) in Software Engineering
in 1998. This research grant funds the
ADAPT project investigating the design of adaptable
software components. He also receives
funding from the Defense Advanced Research Projects
Agency (DARPA). Besides government
funding, his lab has received funding and hardware
donations from Natural Microsystems and
Intellution, Inc.
George Heineman has authored or co-authored over 20
articles and papers on software
engineering topics, including component adaptation
techniques, component-based software
engineering, software development environments, and
software process. He also has interests in
advanced concurrency control techniques.
Heineman received his Ph.D. (1996) and M.S. (1990)
from the Computer Science Department of
Columbia University. His advisor was Gail Kaiser,
Ph.D. George Heineman earned his BA (1989)
in Computer Science from Dartmouth College.
William T. Councill
Table of Contents
CHAPTER = Foreword. Introduction.
Methodology and Organization.
Preface.
Acknowledgments.
I. Component Definition.
1. Definition of a Software Component and Its
Elements.
Bill Councill.
George T. Heineman.
2. The Component Industry Metaphor.
Hedley Apperly.
3. Component Models and Component Services:
Concepts and Principles.
Rainer Weinreich.
Johannes Sametinger.
4. An Example Specification for Implementing a
Temperature Regulator Software
Component.
Janet Flynt.
Jason Mauldin.
Summary.
References.
II. The Case for Components.
5. The Business Case for Components.
John Williams.
. COTS Myths and Other Lessons Learned in
Component-Based Software Development.
Will Tracz, Ph.D.
7. Planning Team Roles for CBD.
Paul Allen.
Stuart Frost.
8. Common High-Risk Mistakes.
Wojtek Kozaczynski.
9. CBSE Success Factors: Integrating Architecture,
Process, and Organization.
Martin L. Griss, Ph.D.
Summary.
References.
III. Software Engineering Practices.
10. Practices of Software Engineering.
George T. Heineman.
11. From Subroutines to Subsystems: Component-Based
Software Development.
Paul C. Clements.
12. Status of CBSE in Europe.
Barry McGibbon, MBCS.
13. CBSE in Japan and Asia.
Mikio Aoyama.
Summary.
References.
IV. The Design of Software Component
Infrastructures.
14. Software Components and the UML.
Kelli Houston.
Davyd Norris.
15. Component Infrastructures: Placing Software
Components in Context.
Steve Latchem.
16. Business Components.
James Carey.
Brent Carlson.
17. Components and Connectors: Catalysis Techniques
for Designing Component
Infrastructures.
Alan Cameron Wills.
18. An OPEN Process for Component-Based
Development.
Brian Henderson-Sellers.
19. Designing Models of Modularity and Integration.
Kevin J. Sullivan.
Summary.
References.
V. From Software Component Infrastructures to
Software Systems.
20. Software Architecture.
Judith A. Stafford.
Alexander L. Wolf.
21. Software Architecture Design Principles.
Len Bass.
22. Product-Line Architectures.
Martin L. Griss, Ph.D.
Summary. References.
VI. The Management of Component-Based Software
Systems.
23. Measurement and Metrics for Software
Components.
Jeffrey S. Poulin.
24. Implementing a Practical Reuse Program for
Software Components.
Donald J. Reifer.
25.Selecting the Right COTS Software: Why.
Requirements Are Important.
Cornelius Ncube.
Neil Maiden.
26. Building Instead of Buying: A Rebuttal.
George T. Heineman.
27. Software Component Project Management.
Bill Councill.
28. The Trouble with Testing Components.
Elaine J. Weyuker.
29. Configuration Management and Component
Libraries.
Hedley Apperly.
30. The Evolution, Maintenance, and Management of
Component-Based Systems.
Mark Vigder.
Summary.
References.
VII. Component Technologies.
31. Overview of the CORBA Component Model.
Nanbor Wang.
Douglas C. Schmidt.
Carlos O'Ryan.
32. Overview of COM .
Tim Ewald.
33. Overview of the Enterprise JavaBeans Component
Model.
David Blevins.
34. Bonobo and Free Software GNOME Components.
Michael Meeks.
35. Choosing Between COM, EJB, and CCM.
Andy Longshaw.
36. Software Agents as Next Generation Software
Components.
Martin L. Griss, Ph.D.
Summary.
References.
VIII. Legal and Regulatory Component Issues.
37. Component-Based Software Engineering As a
Unique Engineering Discipline.
John Speed.
Bill Councill.
George T. Heineman.
38. The Future of Software Components: Standards
and Certification.
Janet Flynt.
Manoj Desai.
39. Commercial Law Applicable to Component-Based
Software.
Stephen Y. Chow.
40. The Effects of UCITA on Software Component
Development and Marketing.
Stephen Y. Chow.
Summary.
References.
IX. Conclusion.
41. Summary.
Bill Councill.
George T. Heineman.
42. The Near-Term Future of Component-Based
Software Engineering.
Hedley Apperly.
Ivar Jacobson.
Grady Booch.
Steve Latchem.
Bill Councill.
Barry McGibbon.
Martin Griss.
Davyd Norris.
George T. Heineman.
Jeffrey Poulin.
References.
Glossary and Acronyms.
About the Editors.
About the Authors.
Index. .
Auteur : HEINEMAN
Editeur : ADDISON WESLEY
Nombre de pages : 818
Date de publication : 06 2001
Toute la sélection
Toutes les sélections
Toute la sélection
Site réalisé en partenariat avec Courbis
(Courbis - alternate link), acteur de l'Internet depuis 1988...
Le Monde En Tique