What do you think?
Rate this book
Design and Use of Software Architectures: Adopting and Evolving a Product-Line Approach
A practical guide to designing and implementing software architectures.
The author proposes a method for designing software architectures, and product-line architectures, which is based on his experience in industry and research.
The first part of the book introduces the design method. examining its three key phases -functionality-based architecture design, architecture assessment and architecture transformation software product lines, incorpora- in detail. The second half of the book explores the concept of software product lines, incorporating elements of architectural design, component-based software engineering and reuse. It takes you through the process of designing, developing and evolving a product-line approach, including the develoment of software architecture and components for the family, instantiation of family members and evolution of assets. It also examines the pros and cons of a number of organizational models that can be applied when putting a software product-line approach into practice.
Contents
Preface
Forward
Acknowledgements
1. Software architectures and product lines
PART I: The designing of software architectures
2. Design of software architectures
3. Software architectural design: case studies
4. Functionality-based architectural design
5. Assessing software architectures
6. Transformation of software architectures
PART II: Software product lines
7. Software product lines: An introduction
8. Software product lines: case studies
9. Designing a product-line architecture
10. Developing components: traditional
11. Developing components: object-oriented frameworks
12. Family-based system development
13. Evolving product-line assets
14. Organizing for software product lines
15. Industrial experiences
The author proposes a method for designing software architectures, and product-line architectures, which is based on his experience in industry and research.
The first part of the book introduces the design method. examining its three key phases -functionality-based architecture design, architecture assessment and architecture transformation software product lines, incorpora- in detail. The second half of the book explores the concept of software product lines, incorporating elements of architectural design, component-based software engineering and reuse. It takes you through the process of designing, developing and evolving a product-line approach, including the develoment of software architecture and components for the family, instantiation of family members and evolution of assets. It also examines the pros and cons of a number of organizational models that can be applied when putting a software product-line approach into practice.
Contents
Preface
Forward
Acknowledgements
1. Software architectures and product lines
PART I: The designing of software architectures
2. Design of software architectures
3. Software architectural design: case studies
4. Functionality-based architectural design
5. Assessing software architectures
6. Transformation of software architectures
PART II: Software product lines
7. Software product lines: An introduction
8. Software product lines: case studies
9. Designing a product-line architecture
10. Developing components: traditional
11. Developing components: object-oriented frameworks
12. Family-based system development
13. Evolving product-line assets
14. Organizing for software product lines
15. Industrial experiences
- GenresArchitecture
366 pages, Paperback
First published May 29, 2000
2 people are currently reading
33 people want to read
Ratings & Reviews
Friends & Following
Create a free account to discover what your friends think of this book!
Community Reviews
Displaying 1 of 1 review
July 21, 2022
Attempts to design and implement program families (sometimes referred to software product lines) have quite a long history in software engineering. In 1986 I had a shot at it for my doctoral thesis (An Application of Formal Specification Techniques) using formal specification languages (Z to specify a framework and its components and CSP to specify some aspects of the user interface).
Bosch provides an excellent text that introduces, for the early 2000s, a state of the art informal software engineering development method for designing software product lines centered on designing, assessing and adjusting product line architectures in order to comply with requirements for functional and quality attributes. The framework was developed by RISE (Research in Software Engineering), a research group at the University of Karlskrona/Ronneby, Sweden in collaboration with industrial partners. He also provides three main real-life industrial case studies to illustrate key aspects of the method: the development of fire-alarm systems, measurement systems and haemodialysis systems.
The method starts by capturing requirements specifications, distinguishing functional specifications from quality requirements. Quality requirements are broadly divided into development quality requirements (e.g. maintainability, reusability, flexibility, demonstrability -which means making it easy to show that new versions of software products comply with certification institutions' requirements) and operational quality requirements (e.g. performance, reliability, robustness, fault-tolerance). It then focuses on designing the product line's architecture by identifying its context (interfaces to other systems and humans), archetypes (core abstractions) and the architectural structure in terms of its decomposition into main components and component relations. Archetypes is a rather ill-defined term introduced by Bosch and corresponds to key domain patterns or class clusters. The method to identify archetypes and define an architecture first focuses only on satisfying the functional requirements. It then proposes assessing the architecture in order to evaluate how well it probably complies with the quality attributes. Architectural transformations are then carried out to improve compliance with unsatisfied quality attributes, until all quality requirements are met or it is deemed impossible to comply with them all, in which case discussions with the customers must be carried out in order to either abandon the project as infeasible or relax or rethink quality requirements -in this latter case new iterations of assessment and transformations may have to be carried out. A sequence of architectural transformations may lead to a dead end, in which case it may prove necessary to undo some of the transformations to attempt others. Finally system instances must be described using the archetypes and the system interfaces, to mke sure specific product architectures can be derived from the product-line architecture allows.
Bosch analyzes at some length the problems of quality attribute assessment of an architecture and overviews evaluation approaches such as scenario-based evaluation, simulation of the architecture, the use of mathematical modeling and experience-based evaluation.
Architectural transformations are categorized into:
Bosch proposes the following steps for product derivation:
It is worth mentioning that unfortunately Bosch confuses interoperability with maintainability and that his section on “run-time evolution”is quite dated and does not cover hot or warm version deployment strategies.
Bosch steers clear of formal specification techniques and uses a small set of very informal diagrams such as component and archetype diagrams whose semantics and relationship are not always clear. More recently model-based software engineering approaches to product-line development have based on UML diagrams and models have become more prevalent. I believe Bosch's ideas may also be profitably complemented by ideas on join points from aspect-oriented development methods as well as developments in service-oriented architectures.
Perhaps the main shortcomings of this book which was published in 2000 as regards the state of the art in 2022 is that it barely mentions testing, that is was written before model-driven software engineering took off and that it, in spite of its excellent case studes, it covers domain engineering very cursorily – for the latter, I would recommend reading Eric Evans' 2003 Domain-driven Design: Tackling Complexity in the Heart of Software (see my review at https://www.goodreads.com/book/show/1...). I believe Evans' use of metaphors and aggregates can be considered an interesting alternative to Bosch's archetypes and his treatment of multiple domains more sophisticated. Bosch's approach, unlike Evan's, also appears to preclude agile development approaches.
In spite of al these caveats, Bosch's book still remains an interesting introductory book on product-line software development, a still plausible and relevant general method for such developments and some very practical and down to earth intuitions and recommendations for the reader who is not put off by coming across occasionally dated material.
Bosch provides an excellent text that introduces, for the early 2000s, a state of the art informal software engineering development method for designing software product lines centered on designing, assessing and adjusting product line architectures in order to comply with requirements for functional and quality attributes. The framework was developed by RISE (Research in Software Engineering), a research group at the University of Karlskrona/Ronneby, Sweden in collaboration with industrial partners. He also provides three main real-life industrial case studies to illustrate key aspects of the method: the development of fire-alarm systems, measurement systems and haemodialysis systems.
The method starts by capturing requirements specifications, distinguishing functional specifications from quality requirements. Quality requirements are broadly divided into development quality requirements (e.g. maintainability, reusability, flexibility, demonstrability -which means making it easy to show that new versions of software products comply with certification institutions' requirements) and operational quality requirements (e.g. performance, reliability, robustness, fault-tolerance). It then focuses on designing the product line's architecture by identifying its context (interfaces to other systems and humans), archetypes (core abstractions) and the architectural structure in terms of its decomposition into main components and component relations. Archetypes is a rather ill-defined term introduced by Bosch and corresponds to key domain patterns or class clusters. The method to identify archetypes and define an architecture first focuses only on satisfying the functional requirements. It then proposes assessing the architecture in order to evaluate how well it probably complies with the quality attributes. Architectural transformations are then carried out to improve compliance with unsatisfied quality attributes, until all quality requirements are met or it is deemed impossible to comply with them all, in which case discussions with the customers must be carried out in order to either abandon the project as infeasible or relax or rethink quality requirements -in this latter case new iterations of assessment and transformations may have to be carried out. A sequence of architectural transformations may lead to a dead end, in which case it may prove necessary to undo some of the transformations to attempt others. Finally system instances must be described using the archetypes and the system interfaces, to mke sure specific product architectures can be derived from the product-line architecture allows.
Bosch analyzes at some length the problems of quality attribute assessment of an architecture and overviews evaluation approaches such as scenario-based evaluation, simulation of the architecture, the use of mathematical modeling and experience-based evaluation.
Architectural transformations are categorized into:
- Applying architectural styles to the system or its subsystems;As Bosch points out and emphasizes, it is also very important to verify that the product-line architectures allows for sufficient variability by defining multiple system instantiations, representing different products.
- Applying architectural patterns;
- Applying design patterns;
- Converting quality requirements to functionality. This extends the architecture with functionality not related to the problem domain but used to fulfill the requirement. Exception-handling is a well-known example that adds functionality to a component to increase the fault-tolerance of the component.
Bosch proposes the following steps for product derivation:
- Specify product requirements, preferably in terms of product-line requirements;The book is organized into two parts. The first part focuses on the design of software architectures with an eye to product-line architectures. The second part of the book delves into product line architectural design and product instantiation with special emphasis on components development. It includes a very nice chapter (13) on the challenges and management of product-line assets evolution and two chapters on managerial aspects of product line development, chapter 14 on organizational business structures for product line development and chapter 15 which sums up some organizational, process and technological aspects of such developments. The books structure may seem a little repetitive to some readers, but I found the changes in perspective from a general architectural, a more specific product-line architecture, and product architecture and development viewpoints helpful and thorough.
- Remove the parts of product-line architecture that are not needed for this product;
- Add features and requirements specific to the product i.e. Carry out architectural extensions;
- Resolve possible requirements conflicts;
- Assess product architecture assessment (if necessary).
It is worth mentioning that unfortunately Bosch confuses interoperability with maintainability and that his section on “run-time evolution”is quite dated and does not cover hot or warm version deployment strategies.
Bosch steers clear of formal specification techniques and uses a small set of very informal diagrams such as component and archetype diagrams whose semantics and relationship are not always clear. More recently model-based software engineering approaches to product-line development have based on UML diagrams and models have become more prevalent. I believe Bosch's ideas may also be profitably complemented by ideas on join points from aspect-oriented development methods as well as developments in service-oriented architectures.
Perhaps the main shortcomings of this book which was published in 2000 as regards the state of the art in 2022 is that it barely mentions testing, that is was written before model-driven software engineering took off and that it, in spite of its excellent case studes, it covers domain engineering very cursorily – for the latter, I would recommend reading Eric Evans' 2003 Domain-driven Design: Tackling Complexity in the Heart of Software (see my review at https://www.goodreads.com/book/show/1...). I believe Evans' use of metaphors and aggregates can be considered an interesting alternative to Bosch's archetypes and his treatment of multiple domains more sophisticated. Bosch's approach, unlike Evan's, also appears to preclude agile development approaches.
In spite of al these caveats, Bosch's book still remains an interesting introductory book on product-line software development, a still plausible and relevant general method for such developments and some very practical and down to earth intuitions and recommendations for the reader who is not put off by coming across occasionally dated material.
Displaying 1 of 1 review