readerlin的博客

面向模式的软件体系结构 卷1：模式系统 一本适用于每一个软件构架师的著作。它确实能全我们缩短所需的设计时间。

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(TM) (EJB) system designed to support wearable computers - The financial aspects of architectures, including use of the Cost Benefit Analysis Method (CBAM) to make decisions

This book is especially for the software architect in the smaller, less mature software development organization (characterized as predominantly practicing ad hoc development). It provides practical guidance on the generation of effective software architectures.

Preface xv Acknowledgments xvii CHAPTER 1 Introduction 1 PART ONE Service-Oriented Life Cycle 29 CHAPTER 2 Service-Oriented Life Cycle Model 31 CHAPTER 3 Service-Oriented Life Cycle Perspectives 49 PART TWO Service-Oriented Conceptualization 69 CHAPTER 4 Attribution Analysis 75 CHAPTER 5 Conceptual Service Identification 87 PART THREE Service-Oriented Discovery and Analysis 111 CHAPTER 6 Service-Oriented Typing and Profiling Model 115 CHAPTER 7 Service-Oriented Discovery and Analysis: CHAPTER 8 Service-Oriented Analysis Modeling 155 PART FOUR Service-Oriented Business Integration 169 CHAPTER 9 Business Architecture Contextual Perspectives 177 CHAPTER 10 Business Architecture Structural Perspectives 191 CHAPTER 11 Service-Oriented Business Integration Modeling 211 PART FIVE Service-Oriented Design Model 229 CHAPTER 12 Service-Oriented Logical Design Relationship 233 CHAPTER 13 Service-Oriented Logical Design Composition 257 CHAPTER 14 Service-Oriented Transaction Model 283 PART SIX Service-Oriented Software Architecture CHAPTER 15 Service-Oriented Conceptual Architecture Modeling CHAPTER 16 Service-Oriented Logical Architecture Principles 341 Index 359

《架构之美》围绕5个主题领域来组织《架构之美》的内容：概述、企业应用、系统、最终用户应用和编程语言。《架构之美》让最优秀的设计师和架构师来描述他们选择的软件架构，剥开架构的各层，展示他们如何让软件做到实现功能、可靠、易用、高效率、可维护、可移植和优雅。

Contents Preface xi Acknowledgments xvii 1 Introduction 1 1.1 What is Software Architecture 1 1.1.1 What software architecture is not 4 1.1.2 Attributes of software architecture 5 1.1.3 Definitions of other key architecture-related terms 7 1.1.4 Other types of architectures 8 1.2 Why Architect? 10 1.3 Architectural Viewpoint Summary 12 1.4 Other Software Architecture Approaches 16 1.4.1 The 4+1 Views 16 1.4.2 RM-ODP viewpoints 17 1.4.3 Bass architectural structures 1.4.4 Hofmeister software architecture views 1.5 Recommended Reading 2 RolesoftheSoftwareArchitect 21 2.1 Relationship to other key roles in development organization 25 Role: project management 25 Role: development team managers 25 Role: system architect/chief engineer 26 Role: chief software engineer 26 Role: hardware architect 27 Role: network architect 27 19 19 19 Role: technical leads of each release 28 Role: data architect 28 Role: systems engineering leads 28 Role: software systems engineering lead 29 2.2 Skills and Background for the Architect 29 2.3 Injecting Architecture Experience 31 2.4 Structuring the Architecture Team 32 2.5 Traps and Pitfalls Associated with the Role of Software Architect 33 2.5.1 Clear definition of leadership 34 2.5.2 Reporting structure for the software architect 34 2.5.3 Geographical location of software architect and technical leads 35 2.5.4 Architecture team size and composition 36 2.5.5 Software architect lifecycle participation 36 2.6 Recommended Reading 37 3 SoftwareArchitectureandtheDevelopment Process 39 3.1 Overview of Iterative Development 39 3.1.1 Overall process phases 40 3.1.2 Lifecycle stages 41 3.1.3 Architecture and agile processes 43 3.1.4 Start early, refine constantly 47 3.2 Requirements Management 48 3.2.1 Use cases and requirements engineering 48 3.2.2 Additional requirements that impact architecture 49 3.2.3 Requirements tracing 49 3.3 Management of the Technology Roadmap 50 3.3.1 External software products 50 3.3.2 Software technology management traps and pitfalls 53 3.3.3 Organizational technology roadmap 54 3.4 Effective Technical Meetings 55 3.4.1 Informal technical meetings 55 3.4.2 Peer reviews and inspections 56 3.4.3 Design reviews 57 3.4.4 Design communication meetings 57 3.4.5 Management meetings 57 3.4.6 Vendor presentations 58 3.4.7 Distributed technical meetings 58 3.5 Traps and Pitfalls of the Software Architecture Process Activities 59 The out-of-touch architect 59 Analysis paralysis 60 Design for reuse 60 Use cases 60 Schedule 60 3.6 Computer-Aided Software Engineering (CASE) Tools 61 3.7 Recommended Reading 62 vi Contents 4 ExampleSystemOverview 63 4.1 System Overview 64 4.2 Overview of System Interfaces 64 4.3 Constraints 67 4.4 Major Operational Requirements and Software Requirements 67 5 UMLQuickTour 69 5.1 UML Diagram Summary 69 5.2 General Diagramming Conventions 72 5.2.1 General UML features: stereotypes, tagged values, multi-instance 73 5.2.2 View labels 74 5.3 The Diagrams 75 5.3.1 Component instance diagrams 75 5.3.2 Class and subsystem diagrams 76 5.3.3 Interaction (sequence and collaboration) diagrams 77 5.3.4 Deployment diagrams 79 5.3.5 Statechart diagrams 80 5.3.6 Activity diagrams 81 5.4 Managing Complexity 81 5.4.1 Use Case focused modeling 82 5.4.2 Element focused modeling 82 5.4.3 Level of detail 83 5.4.4 Controlling the number of models 83 5.4.5 Use Supplemental Textural Information 85 5.5 Recommended Reading 85 6 SystemContext andDomainAnalysis 87 6.1 Conceptual Diagrams 87 6.2 Context Viewpoint 89 6.3 Domain Analysis Techniques 94 6.3.1 A formal analysis technique 95 6.3.2 Other techniques for finding domain entities 98 6.3.3 Analysis shortcuts 100 6.4 Analysis Viewpoints 101 6.4.1 Analysis Interaction Viewpoint 101 6.4.2 Analysis Focused Viewpoint 103 6.4.3 Analysis Overall Viewpoint 105 6.4.4 Candidate subsystem identification 107 6.5 Recommended Reading 108 7 Component DesignandModeling 111 7.1 Overview 111 7.1.1 Component-based development 111 7.1.2 Terminology 112 7.1.3 Communication and interfaces 115 7.1.4 Finding components 115 7.1.5 Qualities of component design 116 Contents vii 7.2 Component Viewpoint 116 7.2.1 Component communication 117 7.2.2 Component interfaces 118 7.2.3 Message-based component modeling 121 7.2.4 Combining interfaces and messaging 124 7.2.5 Comparison of interfaces and messaging 127 7.2.6 Mechanism and performance annotations 128 7.3 Component Interaction Viewpoint 131 7.3.1 Component to Component Interactions 131 7.4 Component State Modeling 133 7.5 Modeling Highly Configurable Component Architectures 137 7.6 Recommended Reading 137 8 SubsystemDesign 139 8.1 Terminology 139 8.2 Modeling Subsystems, Interfaces, and Layers 141 8.2.1 Subsystem Interface Dependency Viewpoint 141 8.2.2 Enhancing the Subsystem Dependency Views with layers 8.2.3 Top-level Dependencies 144 8.2.4 The Layered Subsystem Viewpoint 146 8.3 Mapping Subsystems and Layers to Implementation 151 8.3.1 Subsystems, layers, and build trees 151 8.3.2 Subsystems and components 8.4 Recommended Reading 154 9 TransactionandDataDesign 155 9.1 Logical Data Architecture 155 9.1.1 Logical data model stability 157 9.1.2 Effects of the stable logical data model 158 9.2 Logical Data Viewpoint 159 9.2.1 Logical Data View example 160 9.2.2 Logical Data View for messaging 9.3 Data Model Design – Other Considerations 9.3.1 Data models and layers 164 9.3.2 Data models and reflection 165 9.3.3 Mapping objects to relational database 166 9.4 Transaction Design 169 9.4.1 Transaction concepts 170 9.4.2 Modeling transaction dynamics 171 9.4.3 Transactions and interface design 173 9.5 Recommended Reading 174 10ProcessandDeployment Design 177 10.1 Physical Data Viewpoint 178 10.1.1 Modeling other storage attributes 179 10.1.2 Detailed physical storage modeling 181 10.2 Process Viewpoint 183 viii Contents 16 153 3 16 143 3 TEAMFLY Team-Fly ? 10.2.1 Processes and components 186 10.2.2 Process and component management 186 10.2.3 Process State Viewpoint 189 10.3 Deployment Viewpoint 193 10.3.1 Scalable node design 194 10.3.2 Backup/archive design 199 10.4 Recommended Reading 199 11ArchitectureTechniques 201 11.1 Architecture Development Techniques 201 11.1.1 Commonality and variability analysis 202 11.1.2 Design for change 203 11.1.3 Generative programming techniques 204 11.1.4 Building a skeleton system 205 11.1.5 Prototyping 206 11.1.6 Interface development – Design by Contract 206 11.1.7 Architectural description languages 208 11.1.8 Architecture evaluation 208 11.2 Software Partitioning Strategies – Separation of Concerns 208 11.2.1 Functional decomposition 209 11.2.2 Isolate donfiguration data 210 11.2.3 Isolate hardware-specific components 210 11.2.4 Isolate time-critical components 211 11.2.5 Separate domain implementation model from human interface 211 11.2.6 Separate domain implementation model from implementation technology 211 11.2.7 Separate main function from monitoring 212 11.2.8 Separate fault recovery processing 212 11.2.9 Adaptation of external interfaces 213 11.3 Software Changeability and Dependency Management 213 11.3.1 The stable dependencies principle (SDP) 214 11.3.2 Acyclic dependencies principle 215 11.3.3 Interface Separation Principle 216 11.4 Using Architectural Patterns 216 11.5 Integration Strategies 218 11.5.1 Data-only integration 219 11.5.2 Executable integration 220 11.6 Establishing Architecture to Support Development 221 11.6.1 Configuration and change management 221 11.6.2 Build management 222 11.6.3 Continuous integration 222 11.6.4 Anticipate multi-language development 223 11.6.5 Anticipate tactical development (scripting) 224 11.7 Recommended Reading 225 12ApplyingtheViewpoints 227 12.1 Bottom-Up Architecture Development 227 12.2 Top-Down Architecture Development 229 Contents ix 12.3 Message Protocol and Interface Development 231 12.4 Reengineering Existing Systems 233 12.5 Documenting the Architecture 233 12.6 Conclusions 235 12.6.1 Becoming an architect 235 12.6.2 State of the Practice 237 12.6.3 Looking forward 238 12.6.4 Final thoughts 240 12.7 Recommended Reading 241 Appendix:SummaryofArchitectural Viewpoints 243 Bibliography 251 Index 257

oftware Systems Architecture: Working With Stakeholders Using Viewpoint Who the Book is For We wrote this book primarily for people like us: software architecture practitioners who need to get to grips with the development of practical architectures for their information systems that meet the needs of those they are intended to serve. We also hope the book will be of interest to people studying software architecture at university, and others involved in the software lifecycle, such as development managers, testers, software developers and technical specialists. The knowledge that you will gain by reading of the book includes: An understanding of what software architecture is, and why your role is vitally important to successful project delivery. How to determine who is interested in your architecture (your stakeholders), understand what is important to them (their concerns), and design an architecture that reflects and balances their different needs. How to communicate your architecture to your stakeholders in an understandable way that demonstrates that you have met their concerns (the architectural description). How to focus on what is architecturally significant, safely leaving other aspects of the design to your designers, without neglecting issues like performance, resilience, and location. What important activities you most need to undertake as an architect, such as identifying and engaging stakeholders, using scenarios, creating models, and documenting and validating your architecture. Key Concepts In order to help to organise the material in the book, we have identified three key architectural concepts that we use as themes throughout the text. Stakeholders are the people for whom we build systems. A key part of your role as an architect is knowing how to work with stakeholders in order to create an architecture that meets their complex, overlapping, and often conflicting needs. Viewpoints (and views) are an approach to structuring the architecture definition process and the architectural description, based on the principle of separation of concerns. Viewpoints contain proven architectural knowledge to guide the creation of an architecture, described in a particular set of views (each view being the result of applying the guidance in a particular viewpoint). Perspectives are a complementary concept to viewpoints that we introduce in this book. Perspectives contain proven architectural knowledge and help structure the architecture definition process by separating concerns but focusing on cross-structural quality properties rather than architectural structures. Structure The book is divided into five sections as follows. Part I provides an introduction to and review of the basic concepts we use throughout the book (e.g., stakeholder, architectural description, viewpoint, view, and perspective) and describes the role of the software architect. Part II describes the most important activities you need to undertake as an architect, such as agreeing on a project's scope, identifying and engaging stakeholders, using scenarios and patterns, creating models, and documenting and validating your architecture. Part III is a catalog of the six most important viewpoints you will need when creating your architectural description: the Functional, Information, Concurrency, Development, Deployment, and Operational viewpoints. Part IV is a catalog of the most important perspectives for information systems, including Security, Performance and Scalability, Availability and Resilience, Evolution, Location, Development Resource, Internationalization, and a number of others. Part V pulls these concepts together and explains how you can start to put our ideas into practice.

应用 queueing theory 去模拟构建通讯网络模型。 国外各大高校研究生课程用书