Evaluating Software Architectures Methods and Case Studies

by Clements, Paul; Kazman, Rick; Klein, Mark

• ISBN13: 9780201704822
• ISBN10: 020170482X
• Edition: 1st
• Format: Hardcover
• Copyright: 2001-10-22
• Publisher: Addison-Wesley Professional

Summary

The foundation of any software system is its architecture. Using this book, you can evaluate every aspect of architecture in advance, at remarkably low cost -- identifying improvements that can dramatically improve any system's performance, security, reliability, and maintainability. As the practice of software architecture has matured, it has become possible to identify causal connections between architectural design decisions and the qualities and properties that result downstream in the systems that follow from them. This book shows how, offering step-by-step guidance, as well as detailed practical examples -- complete with sample artifacts reflective of those that evaluators will encounter. The techniques presented here are applicable not only to software architectures, but also to system architectures encompassing computing hardware, networking equipment, and other elements. For all software architects, software engineers, developers, IT managers, and others responsible for creating, evaluating, or implementing software architectures.

Author Biography

Paul Clements is a senior member of the technical staff at the SEI, where he works on software architecture and product line engineering. He is the author of five books and more than three dozen papers on these and other topics.

Rick Kazman is a senior member of the technical staff at the SEI. He is also an Associate Professor at the University of Hawaii. He is the author of two books, editor of two more, and has written more than seventy papers on software engineering and related topics.

Mark Klein is a senior member of the technical staff at the SEI. He is an adjunct professor in the Masters of Software Engineering program at Carnegie Mellon and a coauthor of A Practitioner's Handbook for Real-time Analysis: Guide to Rate Monotonic Analysis for Real-Time Systems (Kluwer Academic Publishers, 1993).

020170482XAB01162003

Table of Contents

List of Figures	xiii
List of Tables	xv
Preface	xvii
Acknowledgments	xxi
Reader's Guide	xxiii
What Is Software Architecture?	1	(18)
Architecture as a Vehicle for Communication among Stakeholders	3	(8)
Architecture and Its Effects on Stakeholders	3	(1)
Architectural Views	4	(6)
Architecture Description Languages	10	(1)
Architecture as the Manifestation of the Earliest Design Decisions	11	(2)
Architectural Styles	12	(1)
Architecture as a Reusable, Transferable Abstraction of a System	13	(1)
Summary	14	(1)
For Further Reading	15	(1)
Discussion Questions	16	(3)
Evaluating a Software Architecture	19	(24)
Why Evaluate an Architecture?	23	(1)
When Can an Architecture Be Evaluated?	24	(2)
Who's Involved?	26	(1)
What Result Does an Architecture Evaluation Produce?	27	(3)
For What Qualities Can We Evaluate an Architecture?	30	(2)
Why Are Qualities Attributes Too Vague for Analysis?	32	(2)
What Are the Outputs of an Architecture Evaluation?	34	(3)
Outputs from the ATAM, the SAAM, and ARID	34	(1)
Outputs Only from the ATAM	35	(2)
What Are the Benefits and Costs of Performing an Architecture Evaluation?	37	(4)
For Further Reading	41	(1)
Discussion Questions	42	(1)
The ATAM---A Method for Architecture Evaluation	43	(44)
Summary of the ATAM Steps	44	(1)
Detailed Description of the ATAM Steps	45	(25)
Present the ATAM	45	(1)
Present the Business Drivers	46	(1)
Present the Architecture	47	(1)
Identify the Architectural Approaches	47	(3)
Generate the Quality Attribute Utility Tree	50	(6)
Analyze the Architectural Approaches	56	(3)
Brainstorm and Prioritize Scenarios	59	(9)
Analyze the Architectural Approaches	68	(1)
Present the Results	68	(2)
The Phases of the ATAM	70	(14)
Phase 0 Activities	71	(5)
Phase 1 Activities	76	(1)
Phase 2 Activities	77	(1)
Phase 3 Activities	78	(6)
For Further Reading	84	(1)
Discussion Questions	84	(3)
The Battlefield Control System---The First Case Study in Applying the ATAM	87	(22)
Preparation	88	(1)
Phase 1	89	(11)
Present the ATAM	89	(1)
Present the Business Drivers	89	(1)
Present the Architecture	89	(1)
Identify the Architectural Approaches	90	(2)
Generate the Quality Attribute Utility Tree	92	(1)
Analyze the Architectural Approaches	92	(8)
Phase 2	100	(3)
Brainstorm and Prioritize Scenarios	100	(2)
Analyze the Architectural Approaches	102	(1)
Present the Results	102	(1)
Result of the BCS Evaluation	103	(4)
Documentation	103	(2)
Requirements	105	(1)
Sensitivities and Tradeoffs	106	(1)
Architectural Risks	106	(1)
Summary	107	(1)
Discussion Questions	107	(2)
Understanding Quality Attributes	109	(18)
Quality Attribute Characterizations	110	(11)
Performance	111	(4)
Availability	115	(3)
Modifiability	118	(2)
Characterizations Inspire Questions	120	(1)
Using Quality Attribute Characterizations in the ATAM	121	(3)
Attribute-Based Architectural Styles	124	(1)
Summary	125	(1)
For Further Reading	126	(1)
Discussion Questions	126	(1)
A Case Study in Applying the ATAM	127	(84)
Background	128	(1)
Phase 0: Partnership and Preparation	129	(19)
Phase 0, Step 1: Present the ATAM	130	(2)
Phase 0, Step 2: Describe Candidate System	132	(2)
Phase 0, Step 3: Make a Go/No-Go Decision	134	(1)
Phase 0, Step 4: Negotiate the Statement of Work	135	(2)
Phase 0, Step 5: Form the Core Evaluation Team	137	(3)
Phase 0, Step 6: Hold Evaluation Team Kick-off Meeting	140	(2)
Phase 0, Step 7: Prepare for Phase 1	142	(5)
Phase 0, Step 8: Review the Architecture	147	(1)
Phase 1: Initial Evaluation	148	(35)
Phase 1, Step 1: Present the ATAM	149	(3)
Phase 1, Step 2: Present Business Drivers	152	(5)
Phase 1, Step 3: Present the Architecture	157	(5)
Phase 1, Step 4: Identify Architectural Approaches	162	(2)
Phase 1, Step 5: Generate Quality Attribute Utility Tree	164	(8)
Phase 1, Step 6: Analyze the Architectural Approaches	172	(11)
Hiatus between Phase 1 and Phase 2	183	(1)
Phase 2: Complete Evaluation	184	(18)
Phase 2, Step 0: Prepare for Phase 2	184	(3)
Phase 2, Steps 1-6	187	(1)
Phase 2, Step 7: Brainstorm and Prioritize Scenarios	187	(9)
Phase 2, Step 8: Analyze Architectural Approaches	196	(3)
Phase 2, Step 9: Present Results	199	(3)
Phase 3: Follow-Up	202	(7)
Phase 3, Step 1: Produce the Final Report	203	(1)
Phase 3, Step 2: Hold the Postmortem Meeting	204	(3)
Phase 3, Step 3: Build Portfolio and Update Artifact Respositories	207	(2)
For Further Reading	209	(1)
Discussion Questions	209	(2)
Using the SAAM to Evaluate an Example Architecture	211	(30)
Overview of the SAAM	212	(2)
Inputs to a SAAM Evaluation	213	(1)
Outputs from a SAAM Evaluation	213	(1)
Steps of a SAAM Evaluation	214	(6)
Step 1: Develop Scenarios	214	(2)
Step 2: Describe the Architecture(s)	216	(1)
Step 3: Classify and Prioritize the Scenarios	217	(1)
Step 4: Individuality Evaluate Indirect Scenarios	218	(1)
Step 5: Assess Scenario Interactions	218	(1)
Step 6: Create the Overall Evaluation	219	(1)
A Sample SAAM Agenda	220	(2)
A SAAM Case Study	222	(16)
ATAT System Overview	222	(1)
Step 1: Develop Scenarios, First Iteration	223	(1)
Step 2: Describe the Architecture(s), First Iteration	224	(1)
Step 1: Develop Scenarios, Second Iteration	225	(2)
Step 2: Describe the Architecture(s), Second Iteration	227	(1)
Step 3: Classify and Prioritize the Scenarios	228	(3)
Step 4: Individuality Evaluate Indirect Scenarios	231	(4)
Step 5: Assess Scenario Interactions	235	(1)
Step 6: Create the Overall Evaluation--Results and Recommendations	236	(2)
Summary	238	(1)
For Further Reading	239	(1)
Discussion Questions	239	(2)
ARID--An Evaluation Method for Partial Architectures	241	(14)
Active Design Reviews	242	(3)
ARID: An ADR/ATAM Hybrid	245	(1)
The Steps of ARID	245	(3)
Phase 1: Rehearsal	246	(1)
Phase 2: Review	246	(2)
A Case Study in Applying ARID	248	(4)
Carrying Out the Steps	249	(2)
Results of the Exercise	251	(1)
Summary	252	(1)
For Further Reading	252	(1)
Discussion Questions	253	(2)
Comparing Software Architecture Evaluation Methods	255	(20)
Questioning Techniques	257	(6)
Questionnaires and Checklists	257	(4)
Scenarios and Scenario-Based Methods	261	(2)
Measuring Techniques	263	(4)
Metrics	264	(1)
Simulations, Prototypes, and Experiments	265	(1)
Rate-Monotonic Analysis	265	(1)
Automated Tools and Architecture Description Languages	266	(1)
Hybrid Techniques	267	(4)
Software Performance Engineering	267	(1)
The ATAM	268	(3)
Summary	271	(2)
For Further Reading	273	(1)
Discussion Questions	273	(2)
Growing an Architecture Evaluation Capability in Your Organization	275	(12)
Growing Organizational Buy-in	276	(1)
Growing a Pool of Evaluators	276	(2)
Establishing a Corporate Memory	278	(7)
Cost and Benefit Data	278	(3)
Method Guidance	281	(2)
Reusable Artifacts	283	(2)
Summary	285	(1)
Discussion Questions	285	(2)
Conclusions	287	(10)
You Are Now Ready!	287	(1)
What Methods Have You Seen?	288	(1)
Why Evaluate Architectures?	288	(2)
Why Does the ATAM Work?	290	(6)
A Parting Message	296	(1)
Appendix A An Example Attribute-Based Architectural Style	297	(6)
Problem Description	297	(1)
Stimulus/Response	298	(1)
Architectural Style	298	(1)
Analysis	299	(3)
Reasoning	299	(1)
Priority Assignment	300	(1)
Priority Inversion	301	(1)
Blocking Time	301	(1)
For Further Reading	302	(1)
References	303	(4)
Index	307

Excerpts

The foundation of any software system is its architecture, that is, the way the software is constructed from separately developed components and the ways in which those components interact and relate to each other. If the system is going to be built by more than one personand these days, what system isn''t?it is the architecture that lets them communicate and negotiate work assignments. If the requirements include goals for performance, security, reliability, or maintainability, then architecture is the design artifact that first expresses how the system will be built to achieve those goals. The architecture determines the structure of the development project. It is the basis for organizing the documentation. It is the first document given to new project members, and the first place a maintenance organization begins its work. Schedules, budgets, and workplans all revolve around it. And the senior, most talented designers are paid to create it. A system''s longevityhow viable it remains in the face of evolutionary pressureis determined primarily by its architecture. Some architectures go on to become generic and adopted by the development community at large: three-tier client-server, layered, and pipe-and-filter architectures are well known beyond the scope of any single system. Today, organizations are recognizing the importance and value of architectures in helping them to meet corporate enterprise goals. An architecture can give an enterprise a competitive advantage and can be banked like any other capitalized asset. The right architecture is the first step to success. The wrong architecture will lead to calamity. This leads to an important question: If your organization is betting its futureor at least a portion of iton an architecture for a system or family of related systems, how can you be sure that you''re building from the right architecture and not the wrong one? The practice of creating an architecture is maturing. We can identify causal connections between design decisions made in the architecture and the qualities and properties that result downstream in the system or systems that follow from it. This means that it is possible to evaluate an architecture, to analyze architectural decisions, in the context of the goals and requirements that are levied on systems that will be built from it. And yet even though architecture is regarded as an essential part of modern system development, architecture evaluation is almost never included as a standard part of any development process. We believe it should be, and this book is an attempt to help people fill that gap. The time has come for architecture evaluation to become an accepted engineering practice for two reasons. First, architecture represents an enormous risk in a development project. As we''ve said, the wrong one leads to disaster. It makes good sense to perform an evaluation on such a pivotal artifact, just as you would plan risk-mitigation strategies for other sources of uncertainty. Second, architecture evaluation can be remarkably inexpensive. The methods described in this book add no more than a week to the project schedule, and some abridged forms require no more than a day or two. Architecture evaluation represents a very cheap insurance policy. Compared to the cost of a poor architecture, the modest expense of a software architecture evaluation makes all the sense in the world. What has been lacking up to this point is a practical method for carrying it out, which is where this book comes in. This is a guidebook for practitioners (or those who wish to become practitioners) of architecture evaluation. We supply conceptual background where necessary, but the intent of the work is to provide step-by-step guidance in the practice of architecture evaluation and analysis. To help put the methods into practice, we have included sample artifacts that are put into play during an architecture evaluation: viewgraph presentation outlines, scenarios, after-action surveys, final report templates, and so forth. The goal is that after reading this book, you will feel confident enough to try out the methods on an architecture in your own organization. We have tried to help answer the question, during an evaluation, "What should I do now?" While the book is written from the point of view of the evaluator, there are others involved in an evaluationproject managers, architects, other stakeholderswho will gain valuable insights by reading this book. They will come to understand how their products will be evaluated and thus can position themselves to make those products fare better with respect to the evaluation criteria. This is rather like scoring well on a test because you''ve seen an early copy of the test, but in this case it isn''t cheating but rather sound management and engineering practice. But know that when we use the word you in the text, we are speaking to the evaluator. The techniques in this book are based on actual practice in government and industry. Most of the methods were developed by ourselves and others at the Software Engineering Institute and applied by ourselves and others to our customers'' and collaborators'' systems. Other material was gleaned by holding industrial workshops whose participants were experts in the analysis and evaluation of architecture. In short, we have learned by doing, and we have learned from others'' doing. This book will not teach you how to become a good architect, nor does it help you become fluent in the issues of architecture. We assume that you already have a good grasp of architectural concepts that comes from practical experience. This book will not help you assess the job performance of any individual architect nor a project''s architecture (or development) process. What it will do is show you how to evaluate an architecture with respect to a broad spectrum of important quality attributes having to do with the architecture and the future system(s) that will be built from it. Finally, we should say a word about softwareversus systemarchitecturethat is, the architecture of software-intensive systems. This is a book about the evaluation of software architectures, but we often hear the question, "Well, what about the architecture of the system, not just the software? It''s just as vital." We couldn''t agree more. System architectures embody the same kinds of structuring and decomposition decisions that drive software architectures. Moreover, they include hardware/software tradeoffs as well as the selection of computing and communication equipment, all of which are completely beyond the realm of software architecture. System architectures hold the key to success or failure of a system every bit as much as the software architecture does for the software. Hence, they deserve to be evaluated every bit as much and for exactly the same reasons. The methods presented in this book will, we believe, apply equally well to system architectures as to software architectures. If modifiability is a concern, the methods can be used to gauge the expense of making changes over the system''s lifetime; if performance is a concern, the methods can be used to spot bottlenecks and problem areas in the system as well as the software; and so forth. Why, then, do we call it a book about softwarearchitecture evaluation? Because that is the realm in which the methods were invented, developed, tested, and matured. In the remainder of this book when we speak of architecture, you can always safely prefix it with software. You can prefix it with systemdepending on how applicable you feel the methods are to system architectures and how confident you are about our intuition in the matter. As a final word, we invite you to share your experiences with us. We would be keenly interested in kno