Catalogue


Software architecture in practice /
Len Bass, Paul Clements, Rick Kazman.
edition
2nd ed.
imprint
Boston : Addison-Wesley, c2003.
description
xxii, 528 p. : ill. ; 25 cm.
ISBN
0321154959 (alk. paper)
format(s)
Book
Holdings
More Details
author
imprint
Boston : Addison-Wesley, c2003.
isbn
0321154959 (alk. paper)
catalogue key
7041877
 
Includes bibliographical references (p. 489-494) and index.
A Look Inside
About the Author
Author Affiliation
Len Bass is a senior member of the technical staff at the Software Engineering Institute (SEI) Paul Clements is a senior member of the technical staff at the SEI, where he works on software architecture and product-line engineering Rick Kazman is a senior member of the technical staff at the SEI. He is also an associate professor at the University of Hawaii
Excerpts
Introduction or Preface
Software architecture is an important field of study that is becoming more important and more talked about with every passing day. Nevertheless, to our knowledge, there exists little practical guidance on managing software architecture in a real software development organization, from both technical and managerial perspectives. This book has emerged from our belief that the coupling of a system's software architecture and its business and organizational context has not been well explored. Our experience with designing and analyzing large and complex software-intensive systems has led us to recognize the role of business and organization in the design of the system and in its ultimate success or failure. Systems are built to satisfy an organization's requirements (or assumed requirements in the case of shrink-wrapped products). These requirements dictate the system's performance, availability, security, compatibility with other systems, and the ability to accommodate change over its lifetime. The desire to satisfy these goals with software that has the requisite properties influences the design choices made by a software architect. In this book we demonstrate this coupling of software architecture and corporate context through the use of case studies drawn from real systems. Our examples include the following situations: The desire to share documents quickly and easily within an organization, with a minimum of centralized control, led to the software architecture of the World Wide Web. The extreme safety requirements of air traffic control led one company to build a system around an architecture for achieving ultra-high availability. The distribution of the subsystems of a flight simulator to remotely located developers led to an architecture geared to enable smooth integration of these subsystems. The need to satisfy simultaneous product deliveries led (in fact, forced) one company to adopt an architecture that enabled the company to build a set of complex related software systems as a product line. The need to standardize architectural approaches across organizations and in the community at large led to infrastructures such as J2EE and EJB. These and other case studies show that software architectures flow from the requirements of organizations and their business models, from the experience of the organization's architects, as well as from the prevailing design climate. In addition, we show how architectures themselves can be powerful vehicles for influencing all of the preceding. A successful product or set of products can influence the way other products are built. Certainly the case study about the software underlying the World Wide Web is a good example of this. Before this system existed, there was far less network awareness, less thought was given to accessibility of data, and security was the concern of only a few organizations, typically financial institutions and government agencies. Our book is aimed at software professionals--the people who design and implement large software-intensive systems, the managers of software professionals, and the students who are hoping to become software professionals. We believe that a software architecture is the development product that gives the highest return on investment with respect to quality, schedule, and cost. Because its architecture appears early in a product's lifetime, getting it right sets the stage for everything to come--the system's development, integration, testing, and modification. Getting it wrong means that the fabric of the system is wrong, and it cannot be fixed by weaving in a few new threads or pulling out a few existing ones, which often causes the entire fabric to unravel. Also, compared to other development activities, analyzing architectures is inexpensive. Thus, architectures give a high return on investment because decisions made for the architecture have substa
Introduction or Preface
Software architecture is an important field of study that is becoming more important and more talked about with every passing day. Nevertheless, to our knowledge, there exists little practical guidance on managing software architecture in a real software development organization, from both technical and managerial perspectives. This book has emerged from our belief that the coupling of a system''s software architecture and its business and organizational context has not been well explored. Our experience with designing and analyzing large and complex software-intensive systems has led us to recognize the role of business and organization in the design of the system and in its ultimate success or failure. Systems are built to satisfy an organization''s requirements (or assumed requirements in the case of shrink-wrapped products). These requirements dictate the system''s performance, availability, security, compatibility with other systems, and the ability to accommodate change over its lifetime. The desire to satisfy these goals with software that has the requisite properties influences the design choices made by a software architect. In this book we demonstrate this coupling of software architecture and corporate context through the use of case studies drawn from real systems. Our examples include the following situations: The desire to share documents quickly and easily within an organization, with a minimum of centralized control, led to the software architecture of the World Wide Web. The extreme safety requirements of air traffic control led one company to build a system around an architecture for achieving ultra-high availability. The distribution of the subsystems of a flight simulator to remotely located developers led to an architecture geared to enable smooth integration of these subsystems. The need to satisfy simultaneous product deliveries led (in fact, forced) one company to adopt an architecture that enabled the company to build a set of complex related software systems as a product line. The need to standardize architectural approaches across organizations and in the community at large led to infrastructures such as J2EE and EJB. These and other case studies show that software architectures flow from the requirements of organizations and their business models, from the experience of the organization''s architects, as well as from the prevailing design climate. In addition, we show how architectures themselves can be powerful vehicles for influencing all of the preceding. A successful product or set of products can influence the way other products are built. Certainly the case study about the software underlying the World Wide Web is a good example of this. Before this system existed, there was far less network awareness, less thought was given to accessibility of data, and security was the concern of only a few organizations, typically financial institutions and government agencies. Our book is aimed at software professionals--the people who design and implement large software-intensive systems, the managers of software professionals, and the students who are hoping to become software professionals. We believe that a software architecture is the development product that gives the highest return on investment with respect to quality, schedule, and cost. Because its architecture appears early in a product''s lifetime, getting it right sets the stage for everything to come--the system''s development, integration, testing, and modification. Getting it wrong means that the fabric of the system is wrong, and it cannot be fixed by weaving in a few new threads or pulling out a few existing ones, which often causes the entire fabric to unravel. Also, compared to other development activities, analyzing architectures is inexpensive. Thus, architectures give a high return on investment because decisions made for the architecture have substantial downstream consequences and because checking and fixing an architecture is relatively inexpensive. We also believe that re-use is achieved best within an architectural context. But components are not the only artifacts that can be re-used. Re-use of an architecture leads to the creation of families of systems, which in turn leads to new organizational structures and new business opportunities. We devote a large percentage of this book to presenting real architectures that were designed to solve the real problems of real organizations. We chose the cases presented here to illuminate the types of choices that architects must make to achieve their quality goals and to illuminate how organizational goals affect the final systems. In addition to the case studies, this book offers a set of techniques for designing, building, and evaluating software architectures. We look at techniques for understanding quality requirements in the context of an architecture, and for building architectures that meet these quality requirements. We look at architecture representation and reconstruction techniques as a means of describing and validating software architectures. We look at techniques for analyzing and evaluating an architecture''s fitness for its purpose. Each of these techniques is derived from our experience, and the experience of our colleagues at the Software Engineering Institute, with a variety of software systems. These systems range up to millions of lines of code and are large-team, multi-year development efforts. Although we discuss business issues throughout the book (for example, an architecture''s effects on an organization''s ability to compete in a market or a product family''s time-to-market), we present this material without going into great depth on the business issues, and without business jargon. We are, after all, software engineers. We present the technical sections of our book in more depth. These sections represent current work in the field of software architecture--the point where research meets practice. The case studies illuminate these technical foundations, and show how they are realized in practice. To benefit from the lessons illuminated by the case studies, you will need a reasonable background in computer science, software engineering, or a related discipline. However, we have written them in such a way that you will not need expertise in the application domain from which the case study was drawn. For example, you do need not be a pilot to understand either the air traffic control system or the flight simulation case studies. What''s New in the Second Edition Our goals for this second edition are the same as they were for the first, but the passage of time since the writing of the first edition has brought new developments in the field and new understanding of the important underpinnings of software architecture. We reflect the new developments with new case studies and our new understanding both through new chapters and through strengthening the existing chapters. Also, the writing of this second edition has been strongly influenced by several other books that we have collectively authored since the publication of the first edition--Documenting Software Architectures, Evaluating Software Architectures: Methods and Case Studies, and Software Product Lines: Principles and Practice. The creation of these books, along with other technical and research activities, has greatly influnced us in developing this book. This second edition reflects the fact that architecture analysis, design, reconstruction, and documentation have all had major developments since the first edition. Architecture analysis has developed into a mature field with industrial-strength methods--reflected here by a new chapter in Part Three about the Architecture Tradeoff Analysis Method (ATAMSM). Many industrial organizations have adopted the ATAM as a technique for eval
First Chapter

Software architecture is an important field of study that is becoming more important and more talked about with every passing day. Nevertheless, to our knowledge, there exists little practical guidance on managing software architecture in a real software development organization, from both technical and managerial perspectives. This book has emerged from our belief that the coupling of a system's software architecture and its business and organizational context has not been well explored.

Our experience with designing and analyzing large and complex software-intensive systems has led us to recognize the role of business and organization in the design of the system and in its ultimate success or failure. Systems are built to satisfy an organization's requirements (or assumed requirements in the case of shrink-wrapped products). These requirements dictate the system's performance, availability, security, compatibility with other systems, and the ability to accommodate change over its lifetime. The desire to satisfy these goals with software that has the requisite properties influences the design choices made by a software architect.

In this book we demonstrate this coupling of software architecture and corporate context through the use of case studies drawn from real systems. Our examples include the following situations:

  • The desire to share documents quickly and easily within an organization, with a minimum of centralized control, led to the software architecture of the World Wide Web.
  • The extreme safety requirements of air traffic control led one company to build a system around an architecture for achieving ultra-high availability.
  • The distribution of the subsystems of a flight simulator to remotely located developers led to an architecture geared to enable smooth integration of these subsystems.
  • The need to satisfy simultaneous product deliveries led (in fact, forced) one company to adopt an architecture that enabled the company to build a set of complex related software systems as a product line.
  • The need to standardize architectural approaches across organizations and in the community at large led to infrastructures such as J2EE and EJB.

These and other case studies show that software architectures flow from the requirements of organizations and their business models, from the experience of the organization's architects, as well as from the prevailing design climate.

In addition, we show how architectures themselves can be powerful vehicles for influencing all of the preceding. A successful product or set of products can influence the way other products are built. Certainly the case study about the software underlying the World Wide Web is a good example of this. Before this system existed, there was far less network awareness, less thought was given to accessibility of data, and security was the concern of only a few organizations, typically financial institutions and government agencies.

Our book is aimed at software professionals--the people who design and implement large software-intensive systems, the managers of software professionals, and the students who are hoping to become software professionals.

We believe that a software architecture is the development product that gives the highest return on investment with respect to quality, schedule, and cost. Because its architecture appears early in a product's lifetime, getting it right sets the stage for everything to come--the system's development, integration, testing, and modification. Getting it wrong means that the fabric of the system is wrong, and it cannot be fixed by weaving in a few new threads or pulling out a few existing ones, which often causes the entire fabric to unravel. Also, compared to other development activities, analyzing architectures is inexpensive. Thus, architectures give a high return on investment because decisions made for the architecture have substantial downstream consequences and because checking and fixing an architecture is relatively inexpensive.

We also believe that re-use is achieved best within an architectural context. But components are not the only artifacts that can be re-used. Re-use of an architecture leads to the creation of families of systems, which in turn leads to new organizational structures and new business opportunities.

We devote a large percentage of this book to presenting real architectures that were designed to solve the real problems of real organizations. We chose the cases presented here to illuminate the types of choices that architects must make to achieve their quality goals and to illuminate how organizational goals affect the final systems.

In addition to the case studies, this book offers a set of techniques for designing, building, and evaluating software architectures. We look at techniques for understanding quality requirements in the context of an architecture, and for building architectures that meet these quality requirements. We look at architecture representation and reconstruction techniques as a means of describing and validating software architectures. We look at techniques for analyzing and evaluating an architecture's fitness for its purpose. Each of these techniques is derived from our experience, and the experience of our colleagues at the Software Engineering Institute, with a variety of software systems. These systems range up to millions of lines of code and are large-team, multi-year development efforts.

Although we discuss business issues throughout the book (for example, an architecture's effects on an organization's ability to compete in a market or a product family's time-to-market), we present this material without going into great depth on the business issues, and without business jargon. We are, after all, software engineers. We present the technical sections of our book in more depth. These sections represent current work in the field of software architecture--the point where research meets practice. The case studies illuminate these technical foundations, and show how they are realized in practice. To benefit from the lessons illuminated by the case studies, you will need a reasonable background in computer science, software engineering, or a related discipline. However, we have written them in such a way that you will not need expertise in the application domain from which the case study was drawn. For example, you do need not be a pilot to understand either the air traffic control system or the flight simulation case studies.

What's New in the Second Edition

Our goals for this second edition are the same as they were for the first, but the passage of time since the writing of the first edition has brought new developments in the field and new understanding of the important underpinnings of software architecture. We reflect the new developments with new case studies and our new understanding both through new chapters and through strengthening the existing chapters. Also, the writing of this second edition has been strongly influenced by several other books that we have collectively authored since the publication of the first edition--Documenting Software Architectures, Evaluating Software Architectures: Methods and Case Studies, and Software Product Lines: Principles and Practice. The creation of these books, along with other technical and research activities, has greatly influnced us in developing this book. This second edition reflects the fact that architecture analysis, design, reconstruction, and documentation have all had major developments since the first edition.

Architecture analysis has developed into a mature field with industrial-strength methods--reflected here by a new chapter in Part Three about the Architecture Tradeoff Analysis Method (ATAMSM). Many industrial organizations have adopted the ATAM as a technique for evaluating software architectures.

Architecture design has also had major developments since the first edition. The capturing of quality requirements, their achievement through small-scale and large-scale architectural approaches (tactics and patterns, respectively), and a design method that reflects knowledge of how to achieve them are all discussed in various chapters. Three new chapters treat understanding quality requirements, achieving qualities, and the Attribute Driven Design Method (ADD).

Architecture reconstruction, or reverse engineering, is an essential activity for capturing undocumented architectures. It can be used as a portion of a design project or as an analysis project, or as input into a decision regarding what to use as a basis for reconstructing a system. In the first edition, we briefly mentioned a tool set (Dali) and its uses in the re-engineering context, but in this edition the topic merits its own chapter.

Documenting software architectures is another topic that has matured considerably in the recent past. When the first edition was published, the Unified Modeling Language (UML) was just arriving on the scene. Now it is firmly entrenched, a reality reflected here with all-new diagrams. More important, an understanding of the kind of information to capture about an architecture, beyond which notation to use, has emerged. A new chapter covers architecture documentation.

The application of software architecture to enable organizations to efficiently produce a variety of systems based on a single architecture is summarized in a totally rewritten chapter on software product lines. This chapter reinforces the link between architecture and an organization's business goals, in view of the fact that product lines (based around a software architecture) can enable order-of-magnitude improvements in cost, quality, and time-to-market.

In addition to the architectural developments, the technology for constructing distributed and Web-based systems has become prominent in today's economy. We reflect this trend in our updated chapter on the World Wide Web by using Web-based examples in the chapter on the ATAM and the chapter on building systems from components, by replacing the case study on Common Object Request Broker Architecture (CORBA) with one on Enterprise JavaBeans (EJBs), and by introducing a case study on a wireless EJB system designed to support wearable computers for maintenance technicians.

Finally, we have added a chapter that looks more closely at the financial aspects of architectures. In this chapter, we introduce a method--the Cost Benefit Analysis Method (CBAM)--for basing architectural decisions on economic criteria, in addition to the technical criteria that we discussed previously.

As in the first edition, we use the Architecture Business Cycle (ABC) as a unifying motif. All of the case studies are described in terms of the quality goals that motivated the system's design and how the system's architecture achieves those goals.

In writing the second edition, as with the first, we were very aware that our primary audience is practitioners, and so we have focused on material that has been found useful in many industrial applications as well as what we expect practice to be in the near future.

We hope that you enjoy reading this second edition at least as much as we enjoyed writing it.



0321154959P03252003
Reviews
This item was reviewed in:
SciTech Book News, September 2003
To find out how to look for other reviews, please see our guides to finding book reviews in the Sciences or Social Sciences and Humanities.
Summaries
Main Description
This award-winning book, substantially updated to reflect the latest developments in the field, introduces the concepts and best practices of software architecture--how a software system is structured and how that system's elements are meant to interact. Distinct from the details of implementation, algorithm, and data representation, an architecture holds the key to achieving system quality, is a reusable asset that can be applied to subsequent systems, and is crucial to a software organization's business strategy. Drawing on their own extensive experience, the authors cover the essential technical topics for designing, specifying, and validating a system. They also emphasize the importance of the business context in which large systems are designed. Their aim is to present software architecture in a real-world setting, reflecting both the opportunities and constraints that companies encounter. To that end, case studies that describe successful architectures illustrate key points of both technical and organizational discussions. Topics new to this edition include: Architecture design and analysis, including the Architecture Tradeoff Analysis Method (ATAM) Capturing quality requirements and achieving them through quality scenarios and tactics Using architecture reconstruction to recover undocumented architectures Documenting architectures using the Unified Modeling Language (UML) New case studies, including Web-based examples and a wireless Enterprise JavaBeans (EJB) system designed to support wearable computers The financial aspects of architectures, including use of the Cost Benefit Analysis Method (CBAM) to make decisions If you design, develop, or manage the building of large software systems (or plan to do so), or if you are interested in acquiring such systems for your corporation or government agency, use Software Architecture in Practice, Second Edition, to get up to speed on the current state of software architecture.
Main Description
bull; A thorough introduction to all aspects of software architecture bull; Shows how the knowledge and application of software architecture can help an organisation achieve the quality goals of its systems bull; The field of software architecture continues to grow, and this book is the leading introduction
Back Cover Copy
This award-winning book, substantially updated to reflect the latest developments in the field, introduces the concepts and best practices of software architecture--how a software system is structured and how that system's elements are meant to interact. Distinct from the details of implementation, algorithm, and data representation, an architecture holds the key to achieving system quality, is a reusable asset that can be applied to subsequent systems, and is crucial to a software organization's business strategy. Drawing on their own extensive experience, the authors cover the essential technical topics for designing, specifying, and validating a system. They also emphasize the importance of the business context in which large systems are designed. Their aim is to present software architecture in a real-world setting, reflecting both the opportunities and constraints that companies encounter. To that end, case studies that describe successful architectures illustrate key points of both technical and organizational discussions. Topics new to this edition include: Architecture design and analysis, including the Architecture Tradeoff Analysis Method (ATAM) Capturing quality requirements and achieving them through quality scenarios and tactics Using architecture reconstruction to recover undocumented architectures Documenting architectures using the Unified Modeling Language (UML) New case studies, including Web-based examples and a wireless Enterprise JavaBeans (EJB) system designed to support wearable computers The financial aspects of architectures, including use of the Cost Benefit Analysis Method (CBAM) to make decisions If you design, develop, or manage the building of large software systems (or plan to do so), or if you are interested in acquiring such systems for your corporation or government agency, use Software Architecture in Practice, Second Edition, to get up to speed on the current state of software architecture. 0321154959B03262003
Bowker Data Service Summary
A thoughtful architecture saves time and money, as well as meeting the needs of all end-users, developers and administrators. This book shows how to develop a sound software architecture in a typical business setting.
Table of Contents
Prefacep. xi
Acknowledgmentsp. xv
Reader's Guidep. xvii
Envisioning Architecturep. 1
The Architecture Business Cyclep. 3
Where Do Architectures Come From?p. 6
Software Processes and the Architecture Business Cyclep. 12
What Makes a "Good" Architecture?p. 14
Summaryp. 17
Discussion Questionsp. 17
What Is Software Architecture?p. 19
What Software Architecture Is and What It Isn'tp. 19
Other Points of Viewp. 23
Architectural Patterns, Reference Models, and Reference Architecturesp. 24
Why Is Software Architecture Important?p. 26
Architectural Structures and Viewsp. 35
Summaryp. 42
For Further Readingp. 42
Discussion Questionsp. 45
A-7E Avionics System: A Case Study in Utilizing Architectural Structuresp. 47
Relationship to the Architecture Business Cyclep. 48
Requirements and Qualitiesp. 49
Architecture for the A-7E Avionics Systemp. 54
Summaryp. 66
For Further Readingp. 67
Discussion Questionsp. 68
Creating an Architecturep. 69
Understanding Quality Attributesp. 71
Functionality and Architecturep. 72
Architecture and Quality Attributesp. 73
System Quality Attributesp. 74
Quality Attribute Scenarios in Practicep. 78
Other System Quality Attributesp. 94
Business Qualitiesp. 95
Architecture Qualitiesp. 96
Summaryp. 97
For Further Readingp. 97
Discussion Questionsp. 98
Achieving Qualitiesp. 99
Introducing Tacticsp. 100
Availability Tacticsp. 101
Modifiability Tacticsp. 105
Performance Tacticsp. 111
Security Tacticsp. 116
Testability Tacticsp. 118
Usability Tacticsp. 121
Relationship of Tactics to Architectural Patternsp. 123
Architectural Patterns and Stylesp. 124
Summaryp. 125
Discussion Questionsp. 127
For Further Readingp. 127
Air Traffic Control: A Case Study in Designing for High Availabilityp. 129
Relationship to the Architecture Business Cyclep. 132
Requirements and Qualitiesp. 132
Architectural Solutionp. 135
Summaryp. 150
For Further Readingp. 151
Discussion Questionsp. 151
Designing the Architecturep. 153
Architecture in the Life Cyclep. 153
Designing the Architecturep. 155
Forming the Team Structurep. 167
Creating a Skeletal Systemp. 170
Summaryp. 171
For Further Readingp. 173
Discussion Questionsp. 173
Flight Simulation: A Case Study in an Architecture for Integrabilityp. 175
Relationship to the Architecture Business Cyclep. 176
Requirements and Qualitiesp. 177
Architectural Solutionp. 182
Summaryp. 196
For Further Readingp. 199
Discussion Questionsp. 199
Documenting Software Architecturesp. 201
Uses of Architectural Documentationp. 202
Viewsp. 204
Choosing the Relevant Viewsp. 205
Documenting a Viewp. 207
Documentation across Viewsp. 215
Unified Modeling Languagep. 218
Summaryp. 229
For Further Readingp. 230
Discussion Questionsp. 230
Reconstructing Software Architecturesp. 231
Introductionp. 231
Information Extractionp. 234
Database Constructionp. 237
View Fusionp. 239
Reconstructionp. 241
Examplep. 248
Summaryp. 257
For Further Readingp. 258
Discussion Questionsp. 259
Analyzing Architecturesp. 261
The ATAM: A Comprehensive Method for Architecture Evaluationp. 271
Participants in the ATAMp. 272
Outputs of the ATAMp. 274
Phases of the ATAMp. 275
The Nightingale System: A Case Study in Applying the ATAMp. 288
Summaryp. 304
For Further Readingp. 304
Discussion Questionsp. 305
The CBAM: A Quantitative Approach to Architecture Design Decision Makingp. 307
Decision-Making Contextp. 308
The Basis for the CBAMp. 310
Implementing the CBAMp. 314
Case Study: The NASA ECS Projectp. 317
Results of the CBAM Exercisep. 324
Summaryp. 324
For Further Readingp. 325
Discussion Questionsp. 325
The World Wide Web: A Case Study in Interoperabilityp. 327
Relationship to the Architecture Business Cyclep. 328
Requirements and Qualitiesp. 329
Architectural Solutionp. 334
Another Cycle through the ABC: The Evolution of Web-Based E-Commerce Architecturesp. 340
Achieving Quality Goalsp. 346
The Architecture Business Cycle Todayp. 346
Summaryp. 348
For Further Readingp. 349
Discussion Questionsp. 349
Moving from One System to Manyp. 351
Software Product Lines: Re-using Architectural Assetsp. 353
Overviewp. 353
What Makes Software Product Lines Work?p. 355
Scopingp. 357
Architectures for Product Linesp. 360
What Makes Software Product Lines Difficult?p. 363
Summaryp. 367
For Further Readingp. 367
Discussion Questionp. 367
Celsius Tech: A Case Study in Product Line Developmentp. 369
Relationship to the Architecture Business Cyclep. 370
Requirements and Qualitiesp. 387
Architectural Solutionp. 390
Summaryp. 398
For Further Readingp. 399
Discussion Questionsp. 399
J2EE/EJB: A Case Study of an Industry-Standard Computing Infrastructurep. 401
Relationship to the Architecture Business Cyclep. 402
Requirements and Qualitiesp. 403
Architectural Solutionp. 406
System Deployment Decisionsp. 419
Summaryp. 425
For Further Readingp. 425
Discussion Questionsp. 425
The Luther Architecture: A Case Study in Mobile Applications Using J2EEp. 427
Relationship to the Architecture Business Cyclep. 429
Requirements and Qualitiesp. 432
Architectural Solutionp. 434
How Luther Achieved Its Quality Goalsp. 451
Summaryp. 452
For Further Readingp. 452
Discussion Questionsp. 452
Building Systems from Off-the-Shelf Componentsp. 453
Impact of Components on Architecturep. 455
Architectural Mismatchp. 456
Component-Based Design as Searchp. 462
ASEILM Examplep. 466
Summaryp. 476
Further Readingp. 476
Software Architecture in the Futurep. 477
The Architecture Business Cycle Revisitedp. 479
Creating an Architecturep. 479
Architecture within the Life Cyclep. 481
The Impact of Commercial Componentsp. 482
Summaryp. 484
Acronymsp. 485
Referencesp. 489
Indexp. 495
Table of Contents provided by Ingram. All Rights Reserved.

This information is provided by a service that aggregates data from review sources and other sources that are often consulted by libraries, and readers. The University does not edit this information and merely includes it as a convenience for users. It does not warrant that reviews are accurate. As with any review users should approach reviews critically and where deemed necessary should consult multiple review sources. Any concerns or questions about particular reviews should be directed to the reviewer and/or publisher.

  link to old catalogue

Report a problem