Software Architecture in Practice

620 Pages·2012·5.6 MB·English

Bass.book Page i Thursday, March 20, 2003 7:21 PM
Software
Architecture
in Practice
STehcirodn Edd Eitdioitnio n
i
The SEI Series in
Software Engineering
Visit informit.com/sei for a complete list of available products.
The SEI Series in Software Engineering represents is a collaborative
undertaking of the Carnegie Mellon Software Engineering Institute (SEI) and
Addison-Wesley to develop and publish books on software engineering and
related topics. The common goal of the SEI and Addison-Wesley is to provide
the most current information on these topics in a form that is easily usable by
practitioners and students.
Books in the series describe frameworks, tools, methods, and technologies
designed to help organizations, teams, and individuals improve their technical
or management capabilities. Some books describe processes and practices for
developing higher-quality software, acquiring programs for complex systems, or
delivering services more effectively. Other books focus on software and system
architecture and product-line development. Still others, from the SEI’s CERT
Program, describe technologies and practices needed to manage software
and network security risk. These and all books in the series address critical
problems in software engineering for which practical solutions are available.
Software
Architecture
in Practice
Third Edition
Len Bass
Paul Clements
Rick Kazman
▲ Addison-Wesley
▼▼
Upper Saddle River, NJ • Boston • Indianapolis • San Francisco
New York • Toronto • Montreal • London • Munich • Paris • Madrid
Capetown • Sydney • Tokyo • Singapore • Mexico City
ThTTe hhSEeeI S SSerEiEesI I i nSS Seoefrtriweiaesres Ei ninng Si nSeoeorfitnfwtgwaarere E Engnignieneereinrigng
Many of the designations used by manufacturers and sellers to distinguish their products are claimed as trademarks. Where those
deMMsigaannnaytyi o oonffs t tahhpeep d edaeres siingig ntnhaiatsit oibononso sku ,s uaesnded d bt hybe y mp muabnaluinsfhuaefcrat ucwrtauesrr asew rasan raden osdfe alsl eetrlralsde etroms datoriks d tciinlsagtimiuni,gs thuh eits hdhee istrihg penirarot idpounrocs tdhsua avcrete sb ceaelranei mpcrleianditm ede wdi th ini-
tiaaal ssc attrpraiatddaele mlmetatarerkrkss s.o .rW Winh healerler ce at hpthoitosaelss e.d edseisgingantaiotinosn asp appepaer airn itnh itsh biso boko,o akn, da nthde t hpeu bpluisbhleisr hwear sw aawsa arwe oarf ea otrfa ad etr-ade-
CMmmMaar,r kkC cMcllaMaiimIm, C, ,t ahtpheae bd idleiestyisg iMgnnaattauitoriiontysn Msh ahovdaeev leb, Cebeaenpea npb ripliinrtyiten Mdte awdtu iwrtihtiy ti hnM iitonidaietll iicanalg pc, iaCtapalri tnlaeeltg tileeer tMst eoerlrsl o ionn,r a CilnEl RcaTal,lp aictnaadpl sCi.tEaRlsT. Coordination Center
areCC rMMegMiMst,e, r CeCdMM inMM thII,e , C UCa.Sap.p aPababitleiilntiytt y aMn Mda Ttaurtaruditreyimt yMa rMko dOoedflfi,e clCe, abCpya aCpbaairlbnitieylgi itMey M aMteulalrotinuty rU iMtnyi voMedresoiltdiyn.e gli, nCga, rCneagrniee gMiee lMlonel, lConE,R CTE, RT,
ATaaAnnMdd ; CCAErEcRhRiTtTe c CCtuooroeor Tdrdrianidnaeatoitofifon An Cn aCelynestniestr eM ra eratehr eore drg;e iCgsMtiesMrtee drIen idtne g itrnha tetiho Une; . USC.O. SPT.aS tP eUansttae ganent- Rdai nsTkdr aE Tdvarealmudaaetrimokn aO;r CkffiU OcReEf fi;b cEyeP ICbCay; r EnCveoaglruinet ieogniaer y
PrMoMceeesllsllo ofnonr U UInnntievigverearrtsisintiygty .C . OTS Based Systems; Framework for Software Product Line Practice; IDEAL; Interim Profile; OAR;
OCTAVE; Operationally Critical Threat, Asset, and Vulnerability Evaluation; Options Analysis for Reengineering; Personal Soft-
ATAM; Architecture Tradeoff Analysis Method; CMM Integration; COTS Usage-Risk Evaluation;
waAreT PAroMce;s sA; PrcLhTiPt;e Pcrtoudruec tT Lriandee Toefcfh nAicnaal lPyrsoibse ;M PSePt;h SoCdA; MCPMI; SMC AIMntPeIg Lreaatdio Anp;p CraOiseTr;S S CUAsMagPeI -LReaids kA sEsevsasolur;a StCioEn; ;S EI;
SECCPUGU;R RTEeEa;;m EE SPPoIfICtCw; ;aE rEev vPoorloulcuteitosison;n aaranyrd y PT rPSoPrco aecrsees ss sefor vfroi cIren Itmneagtrerkgastr ioanftg iCn Cagr OnCeTgOSieT MBSae Blsleoadns eUSdny isSvteeyrmssittsey;m. Fsr;a mFreawmoerwk oforkr Sfoorf tSwoafrtew are
Product Line Practice; IDEAL; Interim Profile; OAR; OCTAVE; Operationally Critical Threat, Asset,
SpPecrioald puecrtm Lisisnioen P troa rcetpircoed;u IcDe EpoArtLio;n Isn otfe CriMmM PI rfoofir Dlee;v OeloApRm;e nOt C(CTMAUV/ESE; IO-2p01e0ra-TtiRo-n03a5ll)y, ©C r2i0t1ic0a bl yT Charrenaetg,i eA Msseellto, n
Unaainnvdedr VsVituuyl,l nhneaersra abbbeieliinlti ytgy rE aEnvtvaealdul ubaytai totihnoe;n SO;o Ofpttwpioatirnoes nE Asn Angiannleyaeslryiisns gifs oI nrf osRtri etRuetneeg.eningeienreinergi;n Pge; rPsoenrsaol nSaolf Stwoaftrwe aPrreo cPersosc; ePsLsT; PPL; TP;
Product Line Technical Probe; PSP; SCAMPI; SCAMPI Lead Appraiser; SCAMPI Lead Assessor;
ThPer aoudthuocrts Lanind ep uTbelicshhneri chaalv eP traokbene ;c aPreS iPn; thSeC pAreMpaPraIt;i oSnC ofA thMisP bIo oLke, abdu tA mpapkera nios eerx;p SreCssAedM orP iIm Lpleieadd w Aarsrsaenstyso orf; a ny
kinSSdCC aEEn;d; S SaEsEsIuI;; mS SeEE nPPoG Gr;e ;sT pTeoeanamsmib Si lSoitfoyt fwftowar raeerr rePo rrPosr cooerc soesms; sais;n saidon nTdsS .T NPS oaP rl ieaa brseiel irstvyei ricsve ai csmseua mmrkeasdr okfofs r C oinaf crCindeaegrnniteael g Moiree c lMolonensel lUqounnei nvUteianrlsi vidtaeymr. saigtyes. in
coSnpneecctiiaoln p weirtmh iosrs aiorinsi ntog oreupt roof dthuec eu speo orft itohne sin ofof rwmoartikosn coor ppyroriggrhamt bs yc oCnatarinneegd ihee Mreienl.lon University, as listed
Special permission to reproduce portions of works copyright by Carnegie Mellon University, as listed
Thoen p puabgliesh 5e8r 8of,f eisr sg erxacnetleledn tb dyi stchoeu Sntosf otwn athreis Ebonogkin weheernin ogr dInersetdit uint eq.uantity for bulk purchases or special sales, which may
incolnud pea egleec t5ro8n8i,c ivse rgsrioannst eadn db/oyr tchues tSomof ctwovaerres aEnndg cionneteenritn pga rItincsutliatru ttoe .your business, training goals, marketing focus, and
Many of the designations used by manufacturers and sellers to distinguish their products are claimed
braaMns datirnnaygd eionmft eatrhreksets sd.. eWFsoihrg emnraeot riteho ionnssfoe ur mdseeasdtii ogbnny,a ptmileoaansnseu acfopanpctetauacrtr:e irns tahnisd bsoeollke,r sa ntod tdhies tpinugbuliisshhe trh weiars parwoadruec otsf aar ter acdlaei-med
masUa rt.Srka. cdCleoamripmao,rr aktthsee. a Wnddeh sGiegornevea trthnioomnsesen htd aSevasleieg sbneaetnio pnrsi natpedp ewarit hin i nthitiisa lb coaopki,t aaln ldet ttehres pour binli sahlle cr awpiatsa lasw. are of a trade-
m(a8r0k0 )c 3la8i2m-3,4 t1h9e designations have been printed with initial capital letters or in all capitals.
Thcoer pasuatlheos@rsp eaanrdso pntuebclhigsrhoeurp h.caovme taken care in the preparation of this book, but make no expressed or
FoiTrm hspaell eiase udot uhwtosairdrser aatnhnetdy U ponufit beadlni sSyht aektrei snh,d pa vlaeena sdtea cakosensnuta mcctae:r en oin r tehsep opnrseipbailriatyti ofno ro efr trhoirss boor ookm, ibsusito mnsa.k Ne on oli aebxiplirteys sies d or
aimsIsnputelmirenedadt iwofonarar lri Snaacnlietdyse notfa la noyr ckoinnsde qaunedn taiassl udmame angoe sr eins pcoonnsniebciltiitoyn fworit he rorro rasr iosirn go mouists oiof ntsh.e Nusoe loiafb tihleit y is
iansifnsoutremmrneaadttii oofnnoa rlo @ri nppecraiordsgeornnatemadl.s c oocrmo nctoaninseedq uheenretiianl. damages in connection with or arising out of the use of the
information or programs contained herein.
ViFsiot ru sin ofno rtmhea Wtioebn: ainbfoourmt bitu.cyoimng/a wthis title in bulk quantities, or for special sales opportunities (which may
LibiTnrhacrleyu dpoefu Cbeollinesgchrteersors noCifacft eavrloesgr sienixogc-niensl-;l Pecunubtls itcdoaimtsico noc uDonvattesar odne stihginss b; oaonkd wcohnetne not rdpearrteidcu ilna rq tuoa nytoituyr fbours ibnuelsks ,p turarcinhiansge s or
Chgsrpoisaeslcissi,,a Mlm saaarrlyke Beset,i twnhg.h ifcohc ums,a yo ri nbcrlaunddein egl eicnttreorneiscts v),e rpslieoansse acnodn/toarc tc uosutro cmo rcpoovreartes asnalde sc odnetpeanrtt mpaerntti cautl acro trop -your
sbCauMlesiMsn@Ie fsposer, a dtrresavoiennloeinpdgm.c egonomta :l ogsr,u (imd8e0al0rink)e e3st 8ifno2gr- 3 pf4roo1cc9ue.sss, ianntedg rbartaionnd ainngd pinrotedruecstts. For more information, please contact:
imFporor vgeomveeUnrtn. S/m M.e Canrtoy s rBapeloethrsa Citnehq rauisnisrdiise ,G sM, opivkleee arKnsoemn creoandnt,t aSScaantl dgeyos vSherrunmm.e—nt3sradl eesd@. pearsoned.com.
p. cm.
FInocrl uqdueess (tb8iio0bnl0iso) g a3rba8op2uh-ti3 csa4al1 lre9esf eoreuntscieds ea nthde i nUd.eSx.., please contact [e-mail].
VISiBsiNt u97s 8co-on0r- 3tph2se1a -lW7e1se1@b5:0p i-en2a f(orhsraomrdnictteo.cvcoehmrg :r/ aaolwku.p p.capoemr)
1. Capability maturity model (Computer software) 2. Software
For sales outside the United States, please contact:
enLgiinberearriny go. f3 C. oPrnogdruecstsio Cn aetnagliongeeinrign-gi.n 4-.P Mubalniucafatcitounr iDnga ptarocesses.
I. Konrad, MInikteer. nIIa. tSihornuaml ,S Saalnedsy . III. Title.
Bass, Len.
QA76.75i8n.Cte5r1n8a [e-mail]
Software architecture in practice / Len Bass, Paul Clements, Rick Kazman.—3rd ed.
005.1—dc22
Vi sitp u. s ocnm t.h—e (WSEebI :s einrifeosr mini ts.ocfotwma/arew engineering) 2010049515
Includes bibliographical references and index.
CoLpiybrrigahrty © o 2f 0C1o1 nPgeraerssosn C Eadtuaclaotigoinn, gIn-icn.-Publication Data
ISBN 978-0-321-81573-6 (hardcover : alk. paper) 1. Software architecture. 2. System
All rights reserved. Printed in the United States of America. This publication is protected by copyright, and permission must be
dBeassigs,n L. Ie.n C.lements, Paul, 1955– II. Kazman, Rick. III. Title.
obtained from the publisher prior to any prohibited reproduction, storage in a retrieval system, or transmission in any form or by
an y m eaQSnsAo, f7etlw6e.ca7trr5oe4n a.iBcr,c3 mh7ie t2ceh0ca1tnu2ircea li, np hportaocctoipcyei n/ gL, reenc oBrdaisnsg,, Pora luikl eCwliesem. Feonrt sin, fRorimcka tKiona zrmegaarnd.i—ng 3predrm eidss.ions, write to:
P ear0ps0o. n5 .E1cd—mucd.a—cti2o(3nS, EInIc s.eries in software engineering)
R ighItns canludd Ceosn btriabcltiso Dgerapparhtmiceanlt references and index. 2012023744
C 5o0 p1y rIBiSogByhlstN t©o n9 27S08tr1-e03et- ,P3 S2eua1irt-es8 o91n05 0E73du-6c a(thioanrd, cInocv.er : alk. paper) 1. Software architecture. 2. System
deBsoisgtonn. , IM. CA l0e2m11e6nts, Paul, 1955– II. Kazman, Rick. III. Title.
All rights reserved. Printed in the United States of America. This publication is protected by copy-
F ax:Q (6A177)6 6.7715-43.4B4377 2012
right, and permission must be obtained from the publisher prior to any prohibited reproduction, stor-
ISBa gNe- 1 i3n0: 0a 59r.e71t8—r-i0e-dv3ac2l21 s3-7y1s1te5m0-,2 or transmission in any form or by any means, electronic, mechanical, pho-
ISBt oNc-o1p0y:ing, re0c-o3r2d1i-n7g11, 5o0r- 5likewise. To obtain permission to use material from this w20o1rk2,0 p2l3e7a4se4 submit
Text printed in the United States on recycled paper at Courier in Westford, Massachusetts.
aC owpryitrtiegnh rt e©qu 2e0st1 3to P Peeaarsrsoonn E Edduuccaatitoionn, , InIncc.., Permissions Department, 200 Old Tappan Road, Old
First printing, March 2011
Tappan, New Jersey 07657, or you may fax your request to [phone].
All rights reserved. Printed in the United States of America. This publication is protected by copy-
IrSigBhNt,- a1n3d: 9p7e8r-m0-i3ss2i1o-n8 1m5u7s3t- 6b e obtained from the publisher prior to any prohibited reproduction, stor-
IaSgBe Nin- 1a0 r: e0t-r3ie2v1a-l8 s1y5s7t3em-4, or transmission in any form or by any means, electronic, mechanical, photo-
Tceoxpty pinrign,t eredc ionr dthien gU, noirt eldik Setwatiesse .o Tno r eocbytcaliend p pearpmeirs asti oCno tuor iuers ein m Wateesrtifaolr dfr, oMma sthsaisc hwuoserktt,s .p lease submit a
Fwifrtihtt epnri nretiqnuge, sSt etpot ePmeabresro 2n0 E15ducation, Inc., Permissions Department, One Lake Street, Upper Saddle
River, New Jersey 07458, or you may fax your request to [phone].
ISBN-13: 978-0-321-81573-6
ISBN-10: 0-321-81573-4
Text printed in the United States on recycled paper at Courier in Westford, Massachusetts.
Second printing, May 2013
00FMBass.indd 4 5/6/13 12:38 PM
Contents
Preface xv
Reader’s Guide xvii
Acknowledgments xix
Part ONE INtrOductION 1
cHaPtEr 1 What Is Software architecture? 3
1.1 What Software Architecture Is and What It
Isn’t 4
1.2 Architectural Structures and Views 9
1.3 Architectural Patterns 18
1.4 What Makes a “Good” Architecture? 19
1.5 Summary 21
1.6 For Further Reading 22
1.7 Discussion Questions 23
cHaPtEr 2 Why Is Software architecture Important? 25
2.1 Inhibiting or Enabling a System’s Quality
Attributes 26
2.2 Reasoning About and Managing
Change 27
2.3 Predicting System Qualities 28
2.4 Enhancing Communication among
Stakeholders 29
2.5 Carrying Early Design Decisions 31
2.6 Defining Constraints on an
Implementation 32
2.7 Influencing the Organizational Structure 33
2.8 Enabling Evolutionary Prototyping 33
v
vi Contents
2.9 Improving Cost and Schedule Estimates 34
2.10 Supplying a Transferable, Reusable
Model 35
2.11 Allowing Incorporation of Independently
Developed Components 35
2.12 Restricting the Vocabulary of Design
Alternatives 36
2.13 Providing a Basis for Training 37
2.14 Summary 37
2.15 For Further Reading 38
2.16 Discussion Questions 38
cHaPtEr 3 the Many contexts of Software
architecture 39
3.1 Architecture in a Technical Context 40
3.2 Architecture in a Project Life-Cycle
Context 44
3.3 Architecture in a Business Context 49
3.4 Architecture in a Professional Context 51
3.5 Stakeholders 52
3.6 How Is Architecture Influenced? 56
3.7 What Do Architectures Influence? 57
3.8 Summary 59
3.9 For Further Reading 59
3.10 Discussion Questions 60
Part tWO QualIty attrIbutES 61
cHaPtEr 4 understanding Quality attributes 63
4.1 Architecture and Requirements 64
4.2 Functionality 65
4.3 Quality Attribute Considerations 65
4.4 Specifying Quality Attribute
Requirements 68
4.5 Achieving Quality Attributes through
Tactics 70
4.6 Guiding Quality Design Decisions 72
4.7 Summary 76
Contents vii
4.8 For Further Reading 77
4.9 Discussion Questions 77
cHaPtEr 5 availability 79
5.1 Availability General Scenario 85
5.2 Tactics for Availability 87
5.3 A Design Checklist for Availability 96
5.4 Summary 98
5.5 For Further Reading 99
5.6 Discussion Questions 100
cHaPtEr 6 Interoperability 103
6.1 Interoperability General Scenario 107
6.2 Tactics for Interoperability 110
6.3 A Design Checklist for Interoperability 114
6.4 Summary 115
6.5 For Further Reading 116
6.6 Discussion Questions 116
cHaPtEr 7 Modifiability 117
7.1 Modifiability General Scenario 119
7.2 Tactics for Modifiability 121
7.3 A Design Checklist for Modifiability 125
7.4 Summary 128
7.5 For Further Reading 128
7.6 Discussion Questions 128
cHaPtEr 8 Performance 131
8.1 Performance General Scenario 132
8.2 Tactics for Performance 135
8.3 A Design Checklist for Performance 142
8.4 Summary 145
8.5 For Further Reading 145
8.6 Discussion Questions 145
cHaPtEr 9 Security 147
9.1 Security General Scenario 148
9.2 Tactics for Security 150
viii Contents
9.3 A Design Checklist for Security 154
9.4 Summary 156
9.5 For Further Reading 157
9.6 Discussion Questions 158
cHaPtEr 10 testability 159
10.1 Testability General Scenario 162
10.2 Tactics for Testability 164
10.3 A Design Checklist for Testability 169
10.4 Summary 172
10.5 For Further Reading 172
10.6 Discussion Questions 173
cHaPtEr 11 usability 175
11.1 Usability General Scenario 176
11.2 Tactics for Usability 177
11.3 A Design Checklist for Usability 181
11.4 Summary 183
11.5 For Further Reading 183
11.6 Discussion Questions 183
cHaPtEr 12 Other Quality attributes 185
12.1 Other Important Quality Attributes 185
12.2 Other Categories of Quality Attributes 189
12.3 Software Quality Attributes and System
Quality Attributes 190
12.4 Using Standard Lists of Quality Attributes—
or Not 193
12.5 Dealing with “X-ability”: Bringing a New
Quality Attribute into the Fold 196
12.6 For Further Reading 200
12.7 Discussion Questions 201
cHaPtEr 13 architectural tactics and Patterns 203
13.1 Architectural Patterns 204
13.2 Overview of the Patterns Catalog 205
13.3 Relationships between Tactics and
Patterns 238
Contents ix
13.4 Using Tactics Together 242
13.5 Summary 247
13.6 For Further Reading 248
13.7 Discussion Questions 249
cHaPtEr 14 Quality attribute Modeling and analysis 251
14.1 Modeling Architectures to Enable Quality
Attribute Analysis 252
14.2 Quality Attribute Checklists 260
14.3 Thought Experiments and
Back-of-the-Envelope Analysis 262
14.4 Experiments, Simulations, and
Prototypes 264
14.5 Analysis at Different Stages of the Life
Cycle 265
14.6 Summary 266
14.7 For Further Reading 267
14.8 Discussion Questions 269
Part tHrEE arcHItEcturE IN tHE lIfE
cyclE 271
cHaPtEr 15 architecture in agile Projects 275
15.1 How Much Architecture? 277
15.2 Agility and Architecture Methods 281
15.3 A Brief Example of Agile Architecting 283
15.4 Guidelines for the Agile Architect 286
15.5 Summary 287
15.6 For Further Reading 288
15.7 Discussion Questions 289
cHaPtEr 16 architecture and requirements 291
16.1 Gathering ASRs from Requirements
Documents 292
16.2 Gathering ASRs by Interviewing
Stakeholders 294
16.3 Gathering ASRs by Understanding the
Business Goals 296