Design and Use of Software Architectures Adopting and Evolving a Product-Line Approach

by Bosch, Jan

• ISBN13: 9780201674941
• ISBN10: 0201674947
• Edition: 1st
• Format: Paperback
• Copyright: 2000-05-19
• Publisher: Addison-Wesley Professional

Summary

A practical guide to designing and implementing software architectures.

Author Biography

Jan Bosch is Professor of Software Engineering at the University of Karlskrona/Ronneby, Sweden.

Table of Contents

Preface	ix
Foreword	xi
Acknowledgements	xiii
Software architecture and product lines	1	(22)
The role of software	3	(6)
This book	9	(1)
Software architecture	10	(3)
Software components	13	(2)
Reading guide	15	(4)
Conclusion	19	(4)
PART I The designing of software architectures
Design of software architectures	23	(18)
Requirements	27	(2)
Architectural design method: overview	29	(4)
Functionality-based architectural design	33	(1)
Assessing quality attributes	34	(2)
Architecture transformation	36	(4)
Concluding remarks	40	(1)
Further reading	40	(1)
Software architectural design: case studies	41	(13)
Fire alarm systems	41	(3)
Measurement systems	44	(5)
Haemodialysis systems	49	(4)
Concluding remarks	53	(1)
Functionality-based architectural design	54	(25)
Defining the system context	55	(2)
Identifying the archetypes	57	(4)
Decomposing the architecture into components	61	(4)
Describing system instantiations	65	(2)
Illustrating functionality-based design	67	(9)
Summary	76	(2)
Further reading	78	(1)
Assessing software architectures	79	(30)
Introduction	79	(3)
Profiles	82	(9)
Scenario-based assessment	91	(4)
Simulation-based assessment	95	(5)
Mathematical model-based assessment	100	(3)
Experience-based assessment	103	(1)
Performing architecture assessment	104	(2)
Concluding remarks	106	(2)
Further reading	108	(1)
Transformation of software architectures	109	(52)
Introduction	109	(3)
The process of architecture transformation	112	(4)
Impose an architectural style	116	(15)
Impose an architectural pattern	131	(14)
Apply a design pattern	145	(6)
Convert quality requirements to functionality	151	(4)
Distribute requirements	155	(1)
Conclusion	155	(2)
Further reading	157	(4)
PART II Software product lines
Software product lines: an introduction	161	(15)
Three types of software architecture use	162	(1)
Decomposing software product lines	163	(3)
Initiating a product line	166	(3)
Applicability of software product-line concepts	169	(1)
Overview	170	(4)
Conclusion	174	(1)
Further reading	175	(1)
Software product lines: case studies	176	(13)
Axis Communications AB	176	(4)
Securitas Larm AB	180	(3)
Symbian	183	(5)
Concluding remarks	188	(1)
Designing a product-line architecture	189	(25)
Overview	189	(2)
Business case analysis	191	(3)
Scoping	194	(6)
Product and feature planning	200	(1)
Product-line architectural desing	201	(7)
Component requirement specification	208	(2)
Validation	210	(1)
Conclusion	211	(2)
Further reading	213	(1)
Developing components: traditional	214	(24)
Component development process	216	(1)
Components and domains	217	(3)
Component interfaces	220	(4)
Component variability	224	(3)
Component adaptation	227	(7)
Aspects, constraints and rules	234	(1)
Conclusion	235	(2)
Further reading	237	(1)
Developing components: object-oriented frameworks	238	(21)
Comparing the academic and industrial views	239	(1)
Object-oriented frameworks	240	(4)
Composing independently developed frameworks	244	(6)
Framework component models	250	(6)
Designing frameworks	256	(1)
Conclusion	257	(1)
Further reading	258	(1)
Family-based system development	259	(23)
Requirement specification	259	(2)
Product architecture derivation	261	(7)
Product-line component selection and instantiation	268	(5)
Develop product-specific components	273	(1)
Product integration	274	(4)
Validation	278	(1)
Packaging and release	279	(1)
Conclusion	279	(3)
Evolving product-line assets	282	(19)
Evolution in software product lines	282	(3)
New product line	285	(3)
Introduction of new product	288	(3)
Adding new features	291	(1)
Extend standards support	292	(1)
New version of infrastructure	293	(2)
Improvement of quality attributes	295	(2)
Post-fielding and run-time evolution	297	(1)
Conclusion	298	(2)
Further reading	300	(1)
Organizing for software product lines	301	(18)
Development department	302	(2)
Business units	304	(5)
Domain engineering unit	309	(3)
Hierarchical domain engineering units	312	(3)
Influencing factors	315	(2)
Conclusion	317	(2)
Industrial experiences	319	(17)
Organization	319	(4)
Process	323	(4)
Technology	327	(8)
Conclusion	335	(1)
References	336	(9)
Index	345

Excerpts

Preface Software has entered virtually all parts of society, ranging from basic utilities such as electricity generation and distribution and telecommunications to personal devices such as mobile phones and cars. Whereas traditionally the competitiveness of a company was defined by its ability to construct and maintain mechanical systems, and later on hardware systems, currently it is the ability to develop and evolve software systems efficiently and effectively which is central. These developments imply an increasing level of responsibility on the software engineering community. With the increase in integration between software systems, failures in one system may have effects which extend beyond the system itself and affect other systems, with possible consequences in the physical world that were not conceivable even a decade ago. On the other hand, software has allowed for unprecedented flexibility and agility in organizations and systems that have many positive effects on society, organizations and individuals. Despite the success of software, software engineering still has many challenges to address. In particular, the following primary objectives can be identified: to drastically decrease the cost of developing and maintaining software and the time-to-market of new software products and to improve (and manage) the quality attributes of software products. Although software systems have always had an architecture, during the last decade the notion of an explicit software architecture has been recognized as being important. One can identify three purposes for an explicitly defined software architecture. First, it allows for early assessment of and design for the quality attributes of a software system. Second, the software architecture represents a concrete artefact that can be used for discussions with and between stakeholders. Finally, it defines the architectural components and their interactions, which facilitates reuse in general and software product lines in particular. This book is concerned with two aspects of software architecture: the design of software architectures and software product lines. In Part I of the book, we present our software architectural design method. This method has been developed and refined through our involvement in a number of software architecture design projects. The three main projects are described as case studies in this book. In Part II of the book, we present the notion of software product lines and the process of adopting and evolving a product-line approach to software development. Again, our approach has been shaped by the co-operation projects that we have had with a number of companies which use software product lines. Consequently, the contents of Part II are shaped by the experiences from these co-operation projects. Foreword Our nice little puppy has really grow and now needs a doghouse. A few boards, some two-by-fours and leftover cedar shingles, a handful of nails, and voil#xE0;! Our puppy has a brand new home. Now, let''s say you didn''t get it quite right at first, so you made some adjustments along the way, then even more a week later. You could even imagine applying some of these techniques to your house if, like me, you live in an area where most houses are made of wood, but you''d be hard pressed to make a living at it. Some of the fixes along the way may have drastic consequences, or may violate the building codes. Now try taking this ''build and fix'' approach to a sky-scraper, and I''m afraid you''d have to completely rethink your strategy.1 If you think of the parallel between construction and software development, the fact is that most software today is still developed and built according to the ''code and fix'' approach - by writing the code, summarily testing it, and shipping it to the customer to use, or to finish the testing. Also in the software world, all doghouses and most log cabins have already been built, and now companies are mostly tackling the sky scrapers. The ''code and fix'' approach does not work and development organizations realize that they need to engineer their software intensive systems.2 They go from developing ''one-off'' systems, to multiple instances, to families of systems or product lines, to leveraging their efforts, as you cannot build these sky-scrapers from scratch all the time. This is where software architecture comes into play. All software intensive systems have an architecture, but, unlike building architecture, this architecture is often hidden, fuzzy, and seems to be produced more by black magic or by accident than by human intent or design. It was only five years ago that Mary Shaw and David Garlan published their book Software Architecture: Perspectives on an Emerging Discipline3 and although this discipline has made some progress, not much has been published since. It has been slow to emerge as a mature software engineering discipline. There are three main aspects where software architecture needs to make progress to establish itself: n Architecture representation - By defining how to represent the architecture of software intensive systems and reaching some industry-wide consensus, we''ll be able to communicate architectural designs or blueprints, to reason about them, and to evaluate and compare architectures. This is where the future standard IEEE 1471 on architecture representation will fill a void. This is also a place where the Unified Modeling Language (UML) has a role to play as a uniform notation for architectural blueprints. n Architectural process - By defining the methods to design and assess architectures, focusing on quality attributes (the non-functional or ''afunctional'' requirements), and addressing them in a systematic fashion. The architectural design approaches need to be supported by a matching organization that takes architecture as a key function, and understands its value and how it flows into other areas, such as planning, project management, product management, design or deployment. n Architectural assets - By collecting, cataloging, and presenting fragments of successful architectures, or even complete architectures, whether they are called patterns, frameworks, components, mechanisms or standards, we will enable software development organizations to design architecture without re-inventing the wheel. This will also foster better communication across the industry, allowing practitioners to simply name the pattern rather than describing it completely. However, as architectures are usually prized company assets, many companies are reluctant to exhibit their architectural assets in a public forum. They''d rather patent them or carefully hide them in their products. In this context, we really welcome this book Design and Use of Software Architectures, which represents a significant step forward in this discipline. Jan Bosch actually contributes to all three aspects - representation, process, and assets - with a good mix between an academic perspective and an industrial perspective. Most of Jan Bosch''s contribution is on the second point, though: the architectural design process, which is certainly the topic closest to my interests and daily concerns. Method and process are definitely areas where we can say there are many ways to achieve a goal, but at the same time areas where too little has been published yet to allow comparison and evolution. Here Jan Bosch does an excellent job of dishing out engineering wisdom to people who have to design architectures for families o