9780321112293

An essential guide for software architects; explains key things they need to know and how to make their architectural designs successful.

Nick Rozanski is an enterprise technical architect at Marks and Spencer, where he focuses on integration and workflow. During his more than twenty years of experience he has worked for companies such as Logica, Capgemini, and Sybase. His technology experience covers enterprise application integration, relational databases, and object-oriented software development. He is also an experienced technical instructor and certified internal project auditor.

Eoin Woods is a principal consultant at Züehlke Engineering in London, where he works as a consultant software architect focusing on trading and investment management companies in the financial markets. He has worked in the software engineering field for fifteen years with a number of companies, including Ford Motor Company, Groupe Bull, InterTrust Technologies, and Sybase.

Preface

xv

Acknowledgments

xviii

About the Authors

xix

Nick Rozanski

xix

Eoin Woods

xix

Introduction

1

(8)

Stakeholders, Viewpoints, and Perspectives

1

(6)

The Structure of This Book

7

(1)

Who Should Read This Book

7

(1)

Conventions Used

8

(1)

Part I Architecture Fundamentals

9

(60)

Software Architecture Concepts

11

(16)

Software Architecture

11

(7)

Architectural Elements

18

(1)

Stakeholders

19

(3)

Architectural Descriptions

22

(2)

Interrelationships between the Core Concepts

24

(1)

Summary

24

(1)

Further Reading

25

(2)

Viewpoints and Views

27

(12)

Architectural Views

30

(1)

Viewpoints

31

(1)

Interrelationships between the Core Concepts

32

(1)

The Benefits of Using Viewpoints and Views

32

(2)

Viewpoint Pitfalls

34

(1)

Our Viewpoint Catalog

35

(2)

Summary

37

(1)

Further Reading

37

(2)

Architectural Perspectives

39

(16)

Quality Properties

39

(2)

Architectural Perspectives

41

(3)

Applying Perspectives to Views

44

(3)

Consequences of Applying a Perspective

47

(2)

Interrelationships between the Core Concepts

49

(1)

The Benefits of Using Perspectives

50

(1)

Perspective Pitfalls

50

(1)

Our Perspective Catalog

51

(1)

Summary

52

(1)

Further Reading

53

(2)

The Role of the Software Architect

55

(14)

The Architecture Definition Process

56

(4)

The Role of the Architect

60

(2)

Interrelationships between the Core Concepts

62

(1)

Architectural Specializations

63

(1)

The Organizational Context

64

(2)

The Architect's Skills

66

(1)

The Architect's Responsibilities

67

(1)

Summary

67

(1)

Further Reading

68

(1)

Part II The Process of Software Architecture

69

(140)

Introduction to the Software Architecture Process

71

(2)

The Architecture Definition Process

73

(18)

Guiding Principles

73

(1)

Process Outcomes

74

(1)

The Process Context

75

(2)

Supporting Activities

77

(3)

Architecture Definition Activities

80

(5)

Process Exit Criteria

85

(1)

Architecture Definition in the Software Development Lifecycle

86

(3)

Summary

89

(1)

Further Reading

90

(1)

Scope, Concerns, Principles, and Constraints

91

(18)

Business Goals and Drivers

93

(1)

Architectural Scope

93

(3)

Architectural Concerns

96

(4)

Architectural Principles

100

(5)

Other Architectural Constraints

105

(2)

Checklist

107

(1)

Summary

107

(1)

Further Reading

108

(1)

Identifying and Engaging Stakeholders

109

(12)

Selection of Stakeholders

109

(2)

Classes of Stakeholders

111

(4)

Examples

115

(2)

Proxy Stakeholders

117

(1)

Stakeholder Groups

118

(1)

Stakeholders' Responsibilities

118

(1)

Checklist

119

(1)

Summary

119

(1)

Further Reading

120

(1)

Identifying and Using Scenarios

121

(14)

Types of Scenarios

122

(1)

Uses for Scenarios

122

(1)

Identifying and Prioritizing Scenarios

123

(2)

Capturing Scenarios

125

(3)

Applying Scenarios

128

(3)

Effective Use of Scenarios

131

(1)

Checklist

132

(1)

Summary

133

(1)

Further Reading

133

(2)

Using Styles and Patterns

135

(22)

Software Patterns

135

(2)

Styles, Patterns, and Idioms

137

(3)

An Example of an Architectural Style

140

(2)

The Benefits of Using Architectural Styles

142

(2)

Styles and the Architectural Description

144

(1)

Common Architectural Styles

145

(7)

Design Patterns and Language Idioms in Architecture

152

(1)

Checklist

153

(1)

Summary

154

(1)

Further Reading

154

(3)

Producing Architectural Models

157

(18)

Why Models Are Important

158

(3)

Types of Models

161

(3)

Modeling Languages

164

(2)

Guidelines for Creating Effective Models

166

(5)

Agile Modeling Techniques

171

(1)

Checklist

171

(1)

Summary

172

(1)

Further Reading

172

(3)

Creating the Architectural Description

175

(16)

Properties of an Effective Architectural Description

176

(5)

Glossaries

181

(1)

The IEEE Standard

182

(1)

Contents of the Architectural Description

183

(5)

Checklist

188

(1)

Summary

189

(1)

Further Reading

189

(2)

Validating the Architecture

191

(18)

Why Validate the Architecture?

192

(1)

Validation Techniques

193

(6)

Scenario-Based Evaluation Methods

199

(5)

Validation during the Software Lifecycle

204

(2)

Recording the Results of Validation

206

(1)

Checklist

207

(1)

Summary

208

(1)

Further Reading

208

(1)

Part III The Viewpoint Catalog

209

(152)

Introduction to the Viewpoint Catalog

211

(4)

The Functional Viewpoint

215

(26)

Concerns

216

(2)

Models

218

(14)

Problems and Pitfalls

232

(7)

Checklist

239

(1)

Further Reading

239

(2)

The Information Viewpoint

241

(28)

Concerns

242

(10)

Models

252

(10)

Problems and Pitfalls

262

(6)

Checklist

268

(1)

Further Reading

268

(1)

The Concurrency Viewpoint

269

(24)

Concerns

271

(4)

Models

275

(12)

Problems and Pitfalls

287

(3)

Checklist

290

(1)

Further Reading

290

(3)

The Development Viewpoint

293

(14)

Concerns

294

(2)

Models

296

(7)

Problems and Pitfalls

303

(2)

Checklist

305

(1)

Further Reading

305

(2)

The Deployment Viewpoint

307

(18)

Concerns

308

(3)

Models

311

(9)

Problems and Pitfalls

320

(2)

Checklist

322

(1)

Further Reading

323

(2)

The Operational Viewpoint

325

(28)

Concerns

326

(6)

Models

332

(16)

Problems and Pitfalls

348

(3)

Checklist

351

(1)

Further Reading

352

(1)

Achieving Consistency Across Views

353

(8)

Relationships between Views

354

(1)

Functional and Information View Consistency

355

(1)

Functional and Concurrency View Consistency

356

(1)

Functional and Development View Consistency

356

(1)

Functional and Deployment View Consistency

357

(1)

Functional and Operational View Consistency

357

(1)

Information and Concurrency View Consistency

358

(1)

Information and Development View Consistency

358

(1)

Information and Deployment View Consistency

358

(1)

Information and Operational View Consistency

359

(1)

Concurrency and Development View Consistency

359

(1)

Concurrency and Deployment View Consistency

360

(1)

Deployment and Operational View Consistency

360

(1)

Part IV The Perspective Catalog

361

(144)

Introduction to the Perspective Catalog

363

(2)

The Security Perspective

365

(32)

Applicability to Views

367

(1)

Concerns

367

(2)

Activities: Applying the Security Perspective

369

(10)

Architectural Tactics

379

(8)

Problems and Pitfalls

387

(6)

Checklists

393

(1)

Further Reading

394

(3)

The Performance and Scalability Perspective

397

(30)

Applicability to Views

398

(1)

Concerns

398

(6)

Activities: Applying the Performance and Scalability Perspective

404

(8)

Architectural Tactics

412

(8)

Problems and Pitfalls

420

(5)

Checklists

425

(1)

Further Reading

426

(1)

The Availability and Resilience Perspective

427

(26)

Applicability to Views

428

(1)

Concerns

428

(4)

Activities: Applying the Availability and Resilience Perspective

432

(9)

Architectural Tactics

441

(5)

Problems and Pitfalls

446

(4)

Checklists

450

(1)

Further Reading

451

(2)

The Evolution Perspective

453

(20)

Applicability to Views

454

(1)

Concerns

455

(2)

Activities: Applying the Evolution Perspective

457

(4)

Architectural Tactics

461

(7)

Problems and Pitfalls

468

(3)

Checklists

471

(1)

Further Reading

472

(1)

Other Perspectives

473

(32)

The Accessibility Perspective

474

(5)

The Development Resource Perspective

479

(6)

The Internationalization Perspective

485

(4)

The Location Perspective

489

(6)

The Regulation Perspective

495

(4)

The Usability Perspective

499

(6)

Part V Putting It All Together

505

(12)

Working as a Software Architect

507

(10)

The Architect in the Project Lifecycle

507

(6)

The Architect in Different Types of Projects

513

(4)

Appendix Other Viewpoint Sets

517

(6)

Kruchten ``4+1''

517

(1)

RM-ODP

518

(1)

Siemens (Hofmeister, Nord, and Soni)

519

(1)

SEI Viewtypes

520

(1)

Garland and Anthony

520

(3)

Bibliography

523

(8)

Index

531

What is included with this book?

The New copy of this book will include any supplemental materials advertised. Please check the title of the book to determine if it should include any access cards, study guides, lab manuals, CDs, etc.

The Used, Rental and eBook copies of this book are not guaranteed to include any supplemental materials. Typically, only the book itself is included. This is true even if the title states it includes any access cards, study guides, lab manuals, CDs, etc.

The authors of this book are both practicing software architects who have worked in this role, together and separately, on information system development projects for quite a few years. During that time, we have seen a significant increase in the visibility of software architects and in the importance with which our role has been viewed by colleagues, management, and customers. No large software development project nowadays would expect to go ahead without an architect--or a small architectural group--in the vanguard of the development team. While there may be an emerging consensus that the software architect's role is an important one, there seems to be little agreement on what the job actually involves. Who are our clients? To whom are we accountable? What are we expected to deliver? What is our involvement once the architectural design has been completed? And, perhaps most fundamentally, where are the boundaries between requirements, architecture, and design? The absence of a clear definition of the role is all the more problematic because of the seriousness of the problems that today's software projects (and specifically, their architects) have to resolve. The expectations of users and other stakeholders in terms of functionality, capability, time to market, and flexibility have become much more demanding. Long system development times result in continual scope changes and consequent changes to the system's architecture and design. Today's systems are more functionally and structurally complex than ever and are usually constructed from a mix of off-the-shelf and custom-built components. Few systems exist in isolation; most are expected to interoperate and exchange information with many other systems. Getting the functional structure--the design--of the system right is only part of the problem. How the system behaves (i.e., its quality properties) is just as critical to its effectiveness as what it does. Technology continues to change at a pace that makes it very hard for architects to keep their technical expertise up-to-date. When we first started to take on the role of software architects, we looked for some sort of software architecture handbook that would walk us through the process of developing an architectural design. After all, other architectural disciplines have behind them centuries of theory and established best practice. For example, in the first century A.D., the Roman Marcus Vitruvius Pollio wrote the first ever architectural handbook,De architectura libri decem("Ten Books on Architecture"), describing the building architect's role and required skills and providing a wealth of material on standard architectural structures. In 1670, Anthony Deane, a friend of diarist Samuel Pepys, a former mayor of the English town of Harwich and later a member of Parliament, published a ground-breaking textbook,A Doctrine of Naval Architecture,which described in detail some of the leading methods of the time for large ship design. Deane's ideas and principles helped systematize the practice of naval architecture for many years. And in 1901, George E. Davis, a consulting engineer in the British chemical industry, created a new field of engineering when he published his textA Handbook of Chemical Engineering.This text was the first book to define the practical principles underpinning industrial chemical processes and guided the field for many years afterward. The existence of such best practices has a very important consequence in terms of uniformity of approach. If you were to give several architects and engineers a commission to design a building, a cruise liner, or a chemical plant, the designs they produced would probably differ. However, the processes they used, the ways they represented their designs on paper (or a computer screen), and the techniques they used to ensure the soundness of their designs would be v

Amazon no longer offers textbook rentals. We do!

Software Systems Architecture Working With Stakeholders Using Viewpoints and Perspectives

Software Systems Architecture Working With Stakeholders Using Viewpoints and Perspectives

0321112296

Summary

Author Biography

Table of Contents

Supplemental Materials

Excerpts