Software development organizations are now discovering the efficiencies that can be achieved by architecting entire software product families together. In Software Architecture for Product Families, experts from one of the world's most advanced software domain engineering projects share in-depth insights about the techniques that work -- and those that don't. The book offers a solutions-oriented, case-study approach covering the entire development lifecycle, based on advanced work done by three of Europe's leading technology companies and their academic partners. Discover the challenges that drive companies to consider architecting product families, and the new problems they encounter in doing so. Master concepts and terms that can be used to describe the architecture of a product family; then learn how to assess that architecture, and transform it into working applications. The authors also present chapter-length, real-world case studies of domain engineering projects at Nokia, Philips, and ABB.
"synopsis" may belong to another edition of this title.
This book presents a view of software architecture for product families. It
is addressed to researchers, engineers, and managers involved in the development
of software-intensive products. The book is based primarily on the experience
gained in the project ARES (Architectural Reasoning for Embedded Systems), carried
out by six partners, funded by the European Commission. The project was concerned
with the application of software architecture research results to practical
problems faced by the industrial partners.
The three industrial partners shared similar problems in coping with the management
of software product evolution in the presence of increasing feature requirements
and decreasing time-to-market requirements. Software architecture, particularly
applied to product families, appeared to offer some solutions, but there were
many approaches and methodologies from which to choose. The goal of the project
was to evaluate promising software architecture research results by applying
them to some typical software evolution problems in industrial settings. One
of the mottos of the project was "industry as laboratory."
The project was carried out by three industrial and three university partners:
Nokia Research Center, Philips Corporate Research, Asea Brown Boveri (ABB) Corporate
Research, Technical University of Vienna, Imperial College of Science and Technology
(London), and Polytechnic University of Madrid. During the project, we produced
many results that had impact on the industrial partners (in terms of practice)
and the university partners (in terms of curriculum development), as well as
a large number of publications and presentations in scientific conferences and
journals. Rather than collecting the many results already presented in journals
and conferences reporting on progress in the ARES project, we decided to integrate
the results gained in the project and present a comprehensive view of the approaches
we followed, of what worked and what didn't.
The purpose of this book is to bring some of the salient results together to
make the big picture accessible to a wider audience. In short, the book attempts
to give the reader the perspective gained by the project partners after three
years of experience in applying research results to practical problems of software
architecture for software-intensive systems. All chapters have been written
specifically for this book.
The Introduction introduces the background of the project and the case study-based
approach that we chose for running the project. It explains how the project
came about and how we decided on the particular foci for the project.
Chapter 1 presents a conceptual framework for software architecture. One of
the problems the field of software architecture faces is the lack of a widely
accepted terminology or even a set of concepts. In this chapter we present the
major concepts and define supporting terminology that allows us to discuss the
problems and solutions in a uniform way. Chapters 2 through 4 are the "technology"
chapters, each dealing with one major aspect of software architecture for product
families: architecture description, architecture assessment, and architecture
Then follow three "experience" chapters. Chapter 5 presents the experience
of Philips in applying software architecture in consumer electronics. Chapter
6 presents several experiments carried out at Nokia to deal with the documentation
and assessment of software architecture. Chapter 7 describes ABB's experience
in developing a software architecture for a family of train control systems,
starting with three existing systems. The experience chapters describe the case
studies in detail. Each chapter describes the state of the art at the start
of the project in the particular area, the problems we observed and tried to
address in that area, and some of the ARES results.
Software architecture, product lines, and product families are all active areas
of research and the subject of intense interest in industry. There are already
several good books available that present different views of software architecture
both for practitioners and researchers. Some present specific methodologies,
some present research approaches, some present practical experiences. Our book
may best be characterized as describing the application of research results
to practice. Its aim is to show the reader how current research results may
be applied and how to overcome the inevitable shortcomings of research results
For example, Chapter 2 introduces the concepts and approaches in software architecture
description and concentrates mostly on the language Darwin, which was invented
at Imperial College, one of the academic partners in the project. Chapter 5
describes how Darwin was applied at Philips and why the engineers at Philips
had to modify Darwin to use it in practice. Indeed, they ended up developing
their own tool, Koala, borrowing many of the concepts of Darwin but not the
language itself. Chapter 7 describes what happened when ABB tried to use Darwin
in architecture recovery. It worked for some things but not for others. ABB
also had to do its own customization. We expect these kinds of results to be
of interest to people concerned with software architecture both in academia
and in industry.
Chapter 8 concludes the book by providing a high-level summary of the results
and an outlook for future developments in the area of software architecture.
It also discusses the critical issue of technology transfer in such a rapidly
This is not the definitive work on software architecture families. No such
book exists and will not exist for several years to come. But we need different
views of the problem until eventually there will be enough understanding to
have a textbook. This book is a modest step in that direction.
How to Read This Book
The project ARES started in December 1995 and was completed in February 1999.
During this time, many people from all the partners worked on the project--some
for a limited period of time and others during the whole period. The focus of
the project was to produce results that could be exploited immediately by the
For example, we at the Technical University of Vienna started a software architecture
course relying heavily on the case studies from the ARES project. At Philips,
engineers developed new tools for documenting software architectures and automatically
generating code for module interconnection. At Nokia, engineers developed Web-based
tools for organizing the documentation of complex systems. At ABB, the results
of some of the ARES work drove the design of a new family architecture for train
control systems. At Imperial College, the feedback from engineers in the three
companies led to improvements in the Darwin tool set. At the Polytechnic University
of Madrid, the researchers developed techniques for architecture assessment
and response-time analysis that were used by the different industrial partners.
Although such results of the ARES project were useful and beneficial to the
partners, the goal of the project was much larger. As a research project, we
wanted to communicate our results to the larger research and industrial community.
This we did through many publications in conferences and journals. Toward the
end of the project we asked ourselves if there was anything else left to say
that our publications did not say. The answer was that indeed much was left
unsaid. The publications for the most part presented technological solutions
to particular problems encountered at the time of publication. What was missing
was any kind of integration--a larger conclusion, a bigger picture based on
more than three years of experience. We decided that a book with the focus on
the larger picture was the answer.
Rather than concentrating on point solutions to specific technical problems,
the book would give a perspective of a three-year experience. Each chapter tries
to look back three years and move forward to share a three-year perspective
with the reader. This was the best way we could imagine to communicate what
we learned in the project. This kind of presentation in each chapter gives the
reader the opportunity to see the whole picture: our assumptions, our starting
point, and where we ended up. As a reader, you can judge how our experiences
may or may not apply in your context.
The project investigated different aspects of software architecture. In Chapter
1, "ARES Conceptual Framework for Software Architecture," Alexander Ran tries
to abstract and summarize from these different aspects the project's collective
understanding of an architecture-oriented approach to software engineering.
In some ways, this chapter is the main result of the ARES project to be communicated
to the community. Experienced software engineers and architects may read this
chapter immediately and identify with many points it makes. Less experienced
engineers probably will find this chapter unconvincing or hard to read initially.
They will be better off reading the chapter quickly at the beginning and then
returning to read it more carefully after they have read the rest of the book.
The rest of the book contains three "technology" chapters and three "experience"
chapters. The technology chapters (2 through 4) abstract the technological aspects
of our experience in a particular area. For example, Chapter 4 ("Software Architecture
Recovery") tries to organize the processes that we used in applying architecture
recovery to the ABB case study. It is not a research presentation as much as
an attempt to document the approaches that worked in the case study. But rather
than presenting the details of the case study, it presents methodological approaches
that may be useful in other case studies of interest to the reader. Thus, in
reading one of the experience chapters (5 through 7), you can form your own
conclusions about the experiment and the experience. A technology chapter presents
our conclusions about the applicability of technology to real-world situations.
The technology and experience chapters may be read in any order if the reader
prefers to jump to a favorite subject.
0201699672P04062001From the Back Cover:
--Paul Clements, Software Engineering Institute
"The authors present a very knowledgeable presentation about software development and software architecture. There are good techniques here that would interest other software architects and designers." --Henry McNair, Hewlett-Packard
The fast pace of modern business is creating new challenges for software engineers. These professionals are faced with the daunting assignment of delivering more robust software for less money--and in less time. In addition, many must now learn to efficiently develop software for a suite, or family, of products. Research has shown that a product-line approach to creating software can be achieved, but where does a software practitioner turn for information and guidance on such a major, potentially difficult transition?
Using an example-based approach, Software Architecture for Product Families provides the software engineering community with a valuable resource for devising and, more importantly, implementing a successful product-family architecture. The concepts and technologies set forth in this book are based on the authors' cutting-edge experiences with the ARES (Architectural Reasoning for Embedded Systems) Project, a major European research initiative that proved that software reuse can be attained more easily through a product-family approach.
This book simplifies the intimidating process of learning how to design software for product-line engineering by focusing on three key aspects of architectural practice: architecture description, assessment, and recovery. Practitioners will learn how to pinpoint the source of their problems, focus on the big picture, and see what kinds of problems can be addressed with the product-family approach. With this book as a guide, software developers will be able to implement a sound product-family architecture that will result in better quality, reduced costs, and decreased time to market. 0201699672B04062001
"About this title" may belong to another edition of this title.
Book Description Addison-Wesley Pub (Sd), 2000. Hardcover. Book Condition: New. Bookseller Inventory # DADAX0201699672
Book Description Addison-Wesley Pub (Sd), 2000. Hardcover. Book Condition: New. book. Bookseller Inventory # M0201699672
Book Description Addison-Wesley Pub (Sd), 2000. Hardcover. Book Condition: New. Never used!. Bookseller Inventory # P110201699672