Software Architecture in Practice word 网盘 高速 下载地址大全 免费

The award-winning and highly influential Software Architecture in Practice, Third Edition, has been substantially revised to reflect the latest developments in the field. In a real-world setting, the book once again 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. The authors have structured this edition around the concept of architecture influence cycles. Each cycle shows how architecture influences, and is influenced by, a particular context in which architecture plays a critical role. Contexts include technical environment, the life cycle of a project, an organization's business profile, and the architect's professional practices. The authors also have greatly expanded their treatment of quality attributes, which remain central to their architecture philosophy-with an entire chapter devoted to each attribute-and broadened their treatment of architectural patterns. If you design, develop, or manage large software systems (or plan to do so), you will find this book to be a valuable resource for getting up to speed on the state of the art. Totally new material covers * Contexts of software architecture: technical, project, business, and professional * Architecture competence: what this means both for individuals and organizations * The origins of business goals and how this affects architecture * Architecturally significant requirements, and how to determine them * Architecture in the life cycle, including generate-and-test as a design philosophy; architecture conformance during implementation; architecture and testing; and architecture and agile development * Architecture and current technologies, such as the cloud, social networks, and end-user devices

part one: introduction chapter 1: what is software architecture? 1.1 what software architecture is and what it isn’t 1.2 architectural structures and views 1.3 architectural patterns 1.4 what makes a “good” architecture? 1.5 summary 1.6 for further reading 1.7 discussion questions chapter 2: why is software architecture important? 2.1 inhibiting or enabling a system’s quality attributes 2.2 reasoning about and managing change 2.3 predicting system qualities 2.4 enhancing communication among stakeholders 2.5 carrying early design decisions 2.6 defining constraints on an implementation .2.7 influencing the organizational structure 2.8 enabling evolutionary prototyping 2.9 improving cost and schedule estimates 2.10 supplying a transferable, reusable model 2.11 allowing incorporation of independently developedcomponents 2.12 restricting the vocabulary of design alternatives 2.13 providing a basis for training 2.14 summary 2.15 for further reading 2.16 discussion questions chapter 3: the many contexts of software architecture 3.1 architecture in a technical context 3.2 architecture in a project life-cycle context 3.3 architecture in a business context 3.4 architecture in a professional context 3.5 stakeholders 3.6 how is architecture influenced? 3.7 what do architectures influence? 3.8 summary 3.9 for further reading 3.10 discussion questions part two: quality attributes chapter 4: understanding quality attributes 4.1 architecture and requirements 4.2 functionality 4.3 quality attribute considerations 4.4 specifying quality attribute requirements 4.5 achieving quality attributes through tactics 4.6 guiding quality design decisions 4.7 summary 4.8 for further reading 4.9 discussion questions chapter 5: availability 5.1 availability general scenario 5.2 tactics for availability 5.3 a design checklist for availability 5.4 summary 5.5 for further reading 5.6 discussion questions chapter 6: interoperability 6.1 interoperability general scenario 6.2 tactics for interoperability 6.3 a design checklist for interoperability 6.4 summary 6.5 for further reading 6.6 discussion questions chapter 7: modifiability 7.1 modifiability general scenario 7.2 tactics for modifiability 7.3 a design checklist for modifiability 7.4 summary 7.5 for further reading 7.6 discussion questions chapter 8: performance 8.1 performance general scenario 8.2 tactics for performance 8.3 a design checklist for performance 8.4 summary 8.5 for further reading 8.6 discussion questions chapter 9: security 9.1 security general scenario 9.2 tactics for security 9.3 a design checklist for security 9.4 summary 9.5 for further reading 9.6 discussion questions chapter 10: testability 10.1 testability general scenario 10.2 tactics for testability 10.3 a design checklist for testability 10.4 summary 10.5 for further reading 10.6 discussion questions chapter 11: usability 11.1 usability general scenario 11.2 tactics for usability 11.3 a design checklist for usability 11.4 summary 11.5 for further reading 11.6 discussion questions chapter 12: other quality attributes 12.1 other important quality attributes 12.2 other categories of quality attributes 12.3 software quality attributes and system qualityattributes 12.4 using standard lists of quality attributes–or not 12.5 dealing with “x-ability”: bringing a new quality attributeinto the fold 12.6 for further reading 12.7 discussion questions chapter 13: architectural tactics and patterns 13.1 architectural patterns 13.2 overview of the patterns catalog 13.3 relationships between tactics and patterns 13.4 using tactics together 13.5 summary 13.6 for further reading 13.7 discussion questions chapter 14: quality attribute modeling and analysis 14.1 modeling architectures to enable quality attributeanalysis 14.2 quality attribute checklists 14.3 thought experiments and back-of-the-envelope analysis 14.4 experiments, simulations, and prototypes 14.5 analysis at different stages of the life cycle 14.6 summary 14.7 for further reading 14.8 discussion questions part three: architecture in the life cycle chapter 15: architecture in agile projects 15.1 how much architecture? 15.2 agility and architecture methods 15.3 a brief example of agile architecting 15.4 guidelines for the agile architect 15.5 summary 15.6 for further reading 15.7 discussion questions chapter 16: architecture and requirements 16.1 gathering asrs from requirements documents 16.2 gathering asrs by interviewing stakeholders 16.3 gathering asrs by understanding the business goals 16.4 capturing asrs in a utility tree 16.5 tying the methods together 16.6 summary 16.7 for further reading 16.8 discussion questions chapter 17: designing an architecture 17.1 design strategy 17.2 the attribute-driven design method 17.3 the steps of add 17.4 summary 17.5 for further reading 17.6 discussion questions chapter 18: documenting software architectures 18.1 uses and audiences for architecture documentation 18.2 notations for architecture documentation 18.3 views 18.4 choosing the views 18.5 combining views 18.6 building the documentation package 18.7 documenting behavior 18.8 architecture documentation and quality attributes 18.9 documenting architectures that change faster than you candocument them 18.10 documenting architecture in an agile developmentproject 18.11 summary 18.12 for further reading 18.13 discussion questions chapter 19: architecture, implementation, and testing 19.1 architecture and implementation 19.2 architecture and testing 19.3 summary 19.4 for further reading 19.5 discussion questions chapter 20: architecture reconstruction and conformance 20.1 architecture reconstruction process 20.2 raw view extraction 20.3 database construction 20.4 view fusion 20.5 architecture analysis: finding violations 20.6 guidelines 20.7 summary 20.8 for further reading 20.9 discussion questions chapter 21: architecture evaluation 21.1 evaluation factors 21.2 the architecture tradeoff analysis method 21.3 lightweight architecture evaluation 21.4 summary 21.5 for further reading 21.6 discussion questions chapter 22: management and governance 22.1 planning 22.2 organizing 22.3 implementing 22.4 measuring 22.5 governance 22.6 summary 22.7 for further reading 22.8 discussion questions part four: architecture and business chapter 23: economic analysis of architectures 23.1 decision-making context 23.2 the basis for the economic analyses 23.3 putting theory into practice: the cbam 23.4 case study: the nasa ecs project 23.5 summary 23.6 for further reading 23.7 discussion questions chapter 24: architecture competence 24.1 competence of individuals: duties, skills, and knowledge ofarchitects 24.2 competence of a software architecture organization 24.3 summary 24.4 for further reading 24.5 discussion questions chapter 25: architecture and software product lines 25.1 an example of product line variability 25.2 what makes a software product line work? 25.3 product line scope 25.4 the quality attribute of variability 25.5 the role of a product line architecture 25.6 variation mechanisms 25.7 evaluating a product line architecture 25.8 key software product line issues 25.9 summary 25.10 for further reading 25.11 discussion questions part five: the brave new world chapter 26: architecture in the cloud 26.1 basic cloud definitions 26.2 service models and deployment options 26.3 economic justification 26.4 base mechanisms 26.5 sample technologies 26.6 architecting in a cloud environment 26.7 summary 26.8 for further reading 26.9 discussion questions chapter 27: architectures for the edge 27.1 the ecosystem of edge-dominant systems 27.2 changes to the software development life cycle 27.3 implications for architecture 27.4 implications of the metropolis model 27.5 summary 27.6 for further reading 27.7 discussion questions chapter 28: epilogue references about the authors index

Len Bass is a Senior Principal Researcher at National ICT Australia Ltd (NICTA). He joined NICTA in 2011 after twenty-five years at the Software Engineering Institute (SEI) at Carnegie Mellon University. He is the coauthor of two award-winning books in software architecture, including Documenting Software Architectures: Views and Beyond, Second Edition (Addison-Wesley, 2011), as well as several other books and numerous papers in computer science and software engineering on a wide range of topics. Len has almost fifty years’ experience in software development and research in multiple domains, such as scientific analysis systems, embedded systems, and information systems. Paul Clements is the Vice President of Customer Success at BigLever Software, Inc., where he works to spread the adoption of systems and software product line engineering. Prior to this position, he was Senior Member of the Technical Staff at the SEI, where, for 17 years, he lead or co-lead projects in software product line engineering and software architecture documentation and analysis. Other books Paul has coauthored include Documenting Software Architectures: Views and Beyond, Second Edition (Addison-Wesley, 2011) and Evaluating Software Architectures: Methods and Case Studies, (Addison-Wesley, 2002), and Software Product Lines: Practices and Patterns (Addison-Wesley, 2002). In addition, he has also published dozens of papers in software engineering reflecting his long-standing interest in the design and specification of challenging software systems. Paul was a founding member of the IFIP WG2.10 Working Group on Software Architecture. Rick Kazman is a Professor at the University of Hawaii and a Visiting Scientist (and former Senior Member of the Technical Staff) at the SEI. He is a coauthor of Evaluating Software Architectures: Methods and Case Studies, (Addison-Wesley, 2002). Rick’s primary research interests are software architecture, design and analysis tools, software visualization, and software engineering economics. He is also interested in human-computer interaction and information retrieval. Rick was one of the creators of several highly influential methods and tools for architecture analysis, including the SAAM (Software Architecture Analysis Method), the ATAM (Architecture Tradeoff Analysis Method), the CBAM (Cost-Benefit Analysis Method), and the Dali architecture reverse engineering tool.

暂无其它内容！

暂时还没有人为这本书评论！