軟件構(gòu)架實踐

內(nèi)容概要

《軟件構(gòu)架實踐(第3版?影印版)》是一本榮獲大獎且影響深遠的經(jīng)典，目前已經(jīng)全面修訂，充分體現(xiàn)了這一領(lǐng)域的最新進展?；谲浖_發(fā)的真實現(xiàn)狀，《軟件構(gòu)架實踐(第3版?影印版)》再次以全新的角度引入軟件構(gòu)架的相關(guān)概念和最佳實踐，闡述軟件系統(tǒng)是如何架構(gòu)的，軟件系統(tǒng)中的各個要素之間又是如何相互作用的。有別于實現(xiàn)細節(jié)、算法和數(shù)據(jù)表示，軟件構(gòu)架是達成高品質(zhì)軟件的關(guān)鍵，是一種可重用于后續(xù)軟件系統(tǒng)的資產(chǎn)，對軟件企業(yè)的商業(yè)策略至關(guān)重要。作者圍繞著軟件構(gòu)架影響周期的概念對《軟件構(gòu)架實踐(第3版?影印版)》前一版進行了重構(gòu)。每個周期都表明了軟件構(gòu)架是如何產(chǎn)生影響的，同時它又受哪些因素的影響。軟件構(gòu)架在特定的背景下發(fā)揮著關(guān)鍵性的作用。這些背景包括技術(shù)環(huán)境、項目的生命周期、組織的業(yè)務(wù)概況和架構(gòu)師的專業(yè)實踐。作者還進一步延展了質(zhì)量屬性，仍然以構(gòu)架理念為中心（用單獨—章內(nèi)容來專門介紹每個屬性），進一步拓寬了軟件構(gòu)架模式。

作者簡介

作者:(美)巴斯、克萊門茨、凱茲曼

書籍目錄

Preface  Reader's Guide Acknowledgments  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 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 PARTTWO 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 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 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 …… PARTTHREE ARCHITECTURE INTHE LIFE CYCLE 271 PART FOUR ARCHlTECTURE AND BUSlNESS 435 PART FIVE THE BRAVE NEWWORLD 501

章節(jié)摘錄

版權(quán)頁：   插圖：   Increase Cohesion Several tactics involve moving responsibilities from one module to another. The purpose of moving a responsibility from one module to another is to reduce the llkelihnnd of side effects affecting other responsibilities in the original module. Increase semantic coherence. If the responsibilities A and B in a module do not serve the same purpose, they should be placed in different modules. This may involve creating a new module or it may involve moving a responsibility to an existing module. One method for identifying responsibilities to be moved is to hypothesize likely changes that affect a module. If some responsibilities are not affected by these changes, then those responsibilities should probably be removed. Reduce CouDlina We now turn to tactics that reduce the couoling between modules. Encapsulate. Encapsulation introduces an explicit interface to a module. This interface includes an application programming interface (API) and its associated responsibilities, such as "perform a syntactic transformation on an input parameter to an internal representation." Perhaps the most common modifiability tactic, encapsulation reduces the probability that a change to one module propagates to other modules. The strengths of coupling that previously went to the module now go to the interface for the module. These strengths are, however, reduced because the interface limits the ways in which external responsibilities can interact with the module (perhaps through a wrapper). The external responsibilities can now only directly interact with the module through the exposed interface (indirect interactions, however, such as dependence on quality of service, will likely remain unchanged). Interfaces designed to increase modifiability should be abstract with respect to the details of the module that are likely to change that is, they should hide those details.

編輯推薦

《軟件構(gòu)架實踐(第3版?影印版)》主要特點：軟件構(gòu)架的背景：技術(shù)角度、項目角度、業(yè)務(wù)角度和專業(yè)角度；軟件構(gòu)架的競爭力：對于個人和組織的意義；業(yè)務(wù)目標(biāo)的依據(jù)及其對軟件構(gòu)架的影響；軟件構(gòu)架層面的重要需求及其確定方式；軟件生命周期中的構(gòu)架，包括以設(shè)計思維為前提的生成—測試，實現(xiàn)期間的軟件構(gòu)架—致性，構(gòu)架與測試，構(gòu)架與敏捷開發(fā)；構(gòu)架與當(dāng)前技術(shù)潮流（比如云計算，社交網(wǎng)絡(luò)和終端用戶設(shè)備）。

圖書封面

圖書標(biāo)簽Tags

無

評論、評分、閱讀與下載

---

    軟件構(gòu)架實踐 PDF格式下載

---