BN.com Gift Guide

Documenting Software Architectures: Views and Beyond (SEI Series in Software Engineering Series) / Edition 2

Hardcover (Print)
Used and New from Other Sellers
Used and New from Other Sellers
from $45.81
Usually ships in 1-2 business days
(Save 38%)
Other sellers (Hardcover)
  • All (13) from $45.81   
  • New (10) from $45.81   
  • Used (3) from $47.24   
Close
Sort by
Page 1 of 2
Showing 1 – 10 of 13 (2 pages)
Note: Marketplace items are not eligible for any BN.com coupons and promotions
$45.81
Seller since 2008

Feedback rating:

(17849)

Condition:

New — never opened or used in original packaging.

Like New — packaging may have been opened. A "Like New" item is suitable to give as a gift.

Very Good — may have minor signs of wear on packaging but item works perfectly and has no damage.

Good — item is in good condition but packaging may have signs of shelf wear/aging or torn packaging. All specific defects should be noted in the Comments section associated with each item.

Acceptable — item is in working order but may show signs of wear such as scratches or torn packaging. All specific defects should be noted in the Comments section associated with each item.

Used — An item that has been opened and may show signs of wear. All specific defects should be noted in the Comments section associated with each item.

Refurbished — A used item that has been renewed or updated and verified to be in proper working condition. Not necessarily completed by the original manufacturer.

New
Brand New, Perfect Condition, Please allow 4-14 business days for delivery. 100% Money Back Guarantee, Over 1,000,000 customers served.

Ships from: Westminster, MD

Usually ships in 1-2 business days

  • Canadian
  • International
  • Standard, 48 States
  • Standard (AK, HI)
$45.82
Seller since 2008

Feedback rating:

(4532)

Condition: New
New Book. Shipped from UK within 10 to 14 business days. Established seller since 2000.

Ships from: Horcott Rd, Fairford, United Kingdom

Usually ships in 1-2 business days

  • Standard, 48 States
  • Standard (AK, HI)
$47.24
Seller since 2008

Feedback rating:

(17849)

Condition: Like New
Brand New, Perfect Condition, Please allow 4-14 business days for delivery. 100% Money Back Guarantee, Over 1,000,000 customers served.

Ships from: Westminster, MD

Usually ships in 1-2 business days

  • Canadian
  • International
  • Standard, 48 States
  • Standard (AK, HI)
$47.47
Seller since 2009

Feedback rating:

(127)

Condition: New
New Book from multilingual publisher. Shipped from UK within 4 to 14 business days. Please check language within??the description. Established seller since 2000.

Ships from: Fairford, United Kingdom

Usually ships in 1-2 business days

  • Standard, 48 States
  • Standard (AK, HI)
$47.60
Seller since 2002

Feedback rating:

(11864)

Condition: Good
May include moderately worn cover, writing, markings or slight discoloration. SKU:9780321552686-4-0

Ships from: Salem, OR

Usually ships in 1-2 business days

  • Canadian
  • International
  • Standard, 48 States
  • Standard (AK, HI)
  • Express, 48 States
  • Express (AK, HI)
$55.07
Seller since 2009

Feedback rating:

(10638)

Condition: New
New Book. Shipped from UK within 10 to 14 business days. Established seller since 2000.

Ships from: Secaucus, NJ

Usually ships in 1-2 business days

  • Standard, 48 States
  • Standard (AK, HI)
$58.47
Seller since 2007

Feedback rating:

(23567)

Condition: New
BRAND NEW

Ships from: Avenel, NJ

Usually ships in 1-2 business days

  • Canadian
  • International
  • Standard, 48 States
  • Standard (AK, HI)
$63.07
Seller since 2014

Feedback rating:

(0)

Condition: New
0321552687 Premium Publisher Direct Books are Like New or Brand New books direct from the publisher sometimes at a discount. Multiple copies are usually available. These books ... are not available for expedited shipping and may take up to 14 business days to receive. Read more Show Less

Ships from: Agoura Hills, CA

Usually ships in 1-2 business days

  • Standard, 48 States
  • Express, 48 States
$72.37
Seller since 2008

Feedback rating:

(104)

Condition: New
0321552687 BRAND NEW W/FAST SHIPPING! This item is: Documenting Software Architectures: Views and Beyond, 2nd Ed., 2011, by Clements, Paul^Bachmann, Felix^Bass, Len^Garlan, ... David^Ivers, James^Little, Reed^Merson, Paulo^Nord, Robert^Stafford, Judith; FORMAT: Hardcover; ISBN: 9780321552686. Choose Expedited for fastest shipping! Our 98%+ rating proves our commitment! We cannot ship to PO Boxes/APO address. To avoid ordering the wrong item, please check your item's ISBN number! Read more Show Less

Ships from: Lawrence, KS

Usually ships in 1-2 business days

  • Standard, 48 States
  • Express, 48 States
$78.86
Seller since 2010

Feedback rating:

(10)

Condition: New
8-5-08 other 2 BRAND NEW! ONLY Expedited orders are shipped with tracking number! *WE DO NOT SHIP TO PO BOX* Please allow up to 14 days delivery for order with standard ... shipping. SHIPPED FROM MULTIPLE LOCATIONS. Read more Show Less

Ships from: San Jose, CA

Usually ships in 1-2 business days

  • Canadian
  • Standard, 48 States
  • Standard (AK, HI)
  • Express, 48 States
  • Express (AK, HI)
Page 1 of 2
Showing 1 – 10 of 13 (2 pages)
Close
Sort by

Overview

“This new edition is brighter, shinier, more complete, more pragmatic, more focused than the previous one, and I wouldn’t have thought it possible to improve on the original. As the field of software architecture has grown over these past decades, there is much more to be said, much more that we know, and much more that we can reflect upon of what’s worked and what hasn’t—and the authors here do all that, and more.”

—From the Foreword by Grady Booch, IBM Fellow

Software architecture—the conceptual glue that holds every phase of a project together for its many stakeholders—is widely recognized as a critical element in modern software development. Practitioners have increasingly discovered that close attention to a software system’s architecture pays valuable dividends. Without an architecture that is appropriate for the problem being solved, a project will stumble along or, most likely, fail. Even with a superb architecture, if that architecture is not well understood or well communicated the project is unlikely to succeed.

Documenting Software Architectures, Second Edition, provides the most complete and current guidance, independent of language or notation, on how to capture an architecture in a commonly understandable form. Drawing on their extensive experience, the authors first help you decide what information to document, and then, with guidelines and examples (in various notations, including UML), show you how to express an architecture so that others can successfully build, use, and maintain a system from it. The book features rules for sound documentation, the goals and strategies of documentation, architectural views and styles, documentation for software interfaces and software behavior, and templates for capturing and organizing information to generate a coherent package. New and improved in this second edition:

  • Coverage of architectural styles such as service-oriented architectures, multi-tier architectures, and data models
  • Guidance for documentation in an Agile development environment
  • Deeper treatment of documentation of rationale, reflecting best industrial practices
  • Improved templates, reflecting years of use and feedback, and more documentation layout options
  • A new, comprehensive example (available online), featuring documentation of a Web-based service-oriented system
  • Reference guides for three important architecture documentation languages: UML, AADL, and SySML
Read More Show Less

Product Details

  • ISBN-13: 9780321552686
  • Publisher: Addison-Wesley
  • Publication date: 10/19/2010
  • Series: SEI Series in Software Engineering Series
  • Edition description: Second Edition
  • Edition number: 2
  • Pages: 537
  • Sales rank: 713,967
  • Product dimensions: 6.40 (w) x 9.30 (h) x 1.40 (d)

Meet the Author

Paul Clements is a Senior Member of the Technical Staff at the Carnegie Mellon Software Engineering Institute (SEI), where he has worked since 1994 leading or coleading projects in software product-line engineering and software architecture documentation and analysis. Besides this one, Clements is the coauthor of two other practitioner-oriented books about software architecture: Software Architecture in Practice (Addison-Wesley, 1998; Second Edition 2003) and Evaluating Software Architectures: Methods and Case Studies (Addison-Wesley, 2001). He also cowrote Software Product Lines: Practices and Patterns (Addison-Wesley, 2001) and was coauthor and editor of Constructing Superior Software (Sams, 1999). In addition, Clements has authored dozens of papers in software engineering, reflecting his longstanding interest in the design and specification of challenging software systems. In 2005 and 2006 he spent a year as a visiting faculty member at the Indian Institute of Technology in Mumbai. He received a Ph.D. in computer sciences from the University of Texas at Austin in 1994. He is a founding member of the IFIP Working Group on Software Architecture (WG2.10).

Felix Bachmann is a Senior Member of the Technical Staff at the SEI, working in the Architecture Centric Engineering Initiative. He is coauthor of the Attribute-Driven Design Method, a contributor to and instructor for the ATAM Evaluator Training course, and a contributor to the book Software Architecture in Practice, Second Edition. Before joining the SEI, he was a software engineer at Robert Bosch GmbH in corporate research, where he worked with software development departments to address the issues of software engineering in small and large embedded systems.

Len Bass is a Senior Member of the Technical Staff at the SEI. He has coauthored two award-winning books in software architecture as well as several other books and numerous papers in a wide variety of areas of computer science and software engineering. He has been a keynote speaker or a distinguished lecturer on six continents. He is currently working on applying the concepts of ultra-large-scale systems to the smart grid. He has been involved in the development of numerous different production or research software systems, ranging from operating systems to database management systems to automotive systems. He is a member of the IFIP Working Group on Software Architecture (WG2.10).

David Garlan is a Professor of Computer Science and Director of Software Engineering Professional Programs in the School of Computer Science at Carnegie Mellon University (CMU). He received his Ph.D. from CMU in 1987 and worked as a software architect in industry between 1987 and 1990. His interests include software architecture, self-adaptive systems, formal methods, and cyber-physical systems. He is considered to be one of the founders of the field of software architecture and, in particular, formal representation and analysis of architectural designs. In 2005 he received a Stevens Award Citation for fundamental contributions to the development and understanding of software architecture as a discipline in software engineering.

James Ivers is a Senior Member of the Technical Staff at the SEI, where he works in the areas of software architecture and program analysis. He received a Master of Software Engineering from CMU in 1996 and has worked for and with a variety of development organizations, from start-up to multinational corporations. He has written numerous papers, contributed to the development of an international standard for distributed simulations, and has recently been working in a public-private collaboration to draft security recommendations for the smart grid.

Reed Little is a Senior Member of the Technical Staff at the SEI. He applies more than 35 years of experience in computer simulation, software architecture, software product lines, man-machine interface, artificial intelligence, and programming language design to various aspects of applied research and hands-on customer assistance for large (more than three million lines of code) software systems.

Paulo Merson has more than 20 years of software development experience. He works for the SEI in the areas of software architecture, service-oriented architecture, and aspect-oriented software development. He is also a practicing software architect in industry. One of his assignments at the SEI is to teach a two-day course in “Documenting Software Architectures” for industry and government practitioners. His speaking experience also includes tutorials at various conferences, such as SD Best Practices, Dr. Dobb’s Architecture & Design World, and JavaOne. Prior to joining the SEI, he was a Java EE consultant. Paulo holds a B.Sc. in Computer Science from University of Brasilia, and a Master of Software Engineering from CMU.

Robert Nord is a Senior Member of the Technical Staff in the Research, Technology, and System Solutions Program at the SEI, where he works to develop and communicate effective methods and practices for software architecture. He is coauthor of the practitioner-oriented book Applied Software Architecture (Addison-Wesley, 2000) and lectures on architecture-centric approaches. He is a member of the IFIP Working Group on Software Architecture (WG2.10).

Judith Stafford is a Senior Lecturer at Tufts University and a Visiting Scientist at the SEI. Before joining the faculty at Tufts University, she was a Senior Member of the Technical Staff at the SEI in the Product Lines Systems Program, working in the Software Architecture Technologies Initiative. She has authored several book chapters on the topic of software architecture analysis, software architecture support for software component composition, and software architecture documentation. Stafford has been an organizer and program committee member for several conferences and workshops, and a guest editor on several leading software engineering journal special issues. She received her Ph.D. and M.S. degrees in Computer Science from the University of Colorado at Boulder. She is a member of the IEEE Computer Society, ACM SIGSOFT and SIGPLAN, and the IFIP Working Group on Software Architecture (WG2.10).

Read More Show Less

Read an Excerpt

For all but the most trivial software system, success will be elusive if you fail to pay careful attention to its architecture: the way the system is decomposed into constituent parts and the ways those parts interact. Without an architecture that is appropriate for the problem being solved, the project will fail. Even with a superb architecture, if it is not well understood and well communicated—in other words, well documented—the project is likely to flounder.

Accordingly, software architecture is at the center of a frenzy of attention these days. A new book about it seems to pop out monthly. In response to industrial need, universities are adding software architecture to their software engineering curricula. It's now common for "software architect" to be a defined position in organizations, and professional practice groups for software architects are emerging. Software architecture has been the subject of major international conferences and workshops. The purveyors of the Unified Modeling Language (UML) promote their product by calling it "the standard notationfor software architecture," a claim that may say at least as much about the pervasiveness of architecture as about UML. The Software Engineering Institute of Carnegie Mellon University (SEI) maintains a bibliography of about 1,000 journal and conference papers on software architecture.

Rather surprisingly, practical guidance that is independent of language or notation for how to capture an architecture is lacking. To be sure, piles of books exist about how to use a particular language—again, UML comes to mind—but what an architect really needs is guidance in which architecture is a first-class citizen, with language relegated more appropriately to a supporting role.

First, let's agree on some basic context. The field has not anointed a single definition of software architecture, and so there are many, but we can specify the one we'll use, which is adapted from Bass, Clements, and Kazman (1998). Although much of this book is about the meaning of elements and relationships, we use this definition now to emphasize the plurality of structures that exist in architectures. Each structure is characterized by various kinds of elements and relationships, and each structure provides a view that imparts a particular kind of understanding of the architecture.

Definition: A software architecture for a system is the structure or structures of the system, which consist of elements, their externally visible properties, and the relationships among them.

"Externally visible properties" are those assumptions other components can make of a component, such as its provided services, quality attribute properties, shared resource usage, and so on.

The architecture serves as the blueprint for both the system and the project developing it, defining the work assignments that must be carried out by design and implementation teams. The architecture is the primary carrier of system qualities, such as performance, modifiability, and security, none of which can be achieved without a unifying architectural vision. Architecture is an artifact for early analysis to make sure that the design approach will yield an acceptable system. Architecture holds the key to post-deployment system understanding, maintenance, and mining efforts. In short, architecture is the conceptual glue that holds every phase of the project together for all its many stakeholders.

Documenting the architecture is the crowning step to crafting it. The perfect architecture is useless if it has not been expressed understandably. If you go to the trouble of creating a strong architecture, you must go to the trouble of describing it in enough detail, without ambiguity, and organized so that others can quickly find needed information. Otherwise, your effort will have been wasted, because the architecture will be unusable.

The audience for this book includes the people involved in the production and consumption of architectural documentation: the community of software developers. The goal of this book is to help you decide what information about an architecture is important to capture and to provide guidelines, notations, and examples for capturing it. We intend this book to be a practitioner-oriented guide to the various kinds of information that constitute an architecture. We give practical guidance for choosing what information should be documented and show—with examples in various notations, including but not limited to UML—how to describe that information in writing so that others can use it to carry out their architecture-based work: implementation, analysis, recovery, and so on. Therefore, we cover

  • Uses of software architecture documentation. How one documents depends on how one wishes to use the documentation. We lay out possible end goals for architecture documentation and provide documentation strategies for each.
  • Architectural views. We hold that documenting software architecture is primarily about documenting the relevant views and then augmenting this information with relevant information that applies beyond views. The heart of the book is an introduction to the most relevant architectural views, grouped into three major families, which we call viewtypes, along with practical guidance about how to write them down. Examples are included for each.
  • Packaging the information. Once the views have been understood, the problem remains of choosing the relevant views, including information not contained in a view, and packaging all the information as a coherent whole. We give practical advice for all these facets.

We believe strongly in the importance of architecture in building successful systems. But no architecture can achieve this if it is not effectively communicated, and documentation is the key to successful communication. We hope that we have provided a useful handbook for practitioners in the field.

—P.C.C.,
Austin, Texas
—F.B., L.B., D.G., J.I., R.L., R.N., J.S.,
Pittsburgh, Pennsylvania


Read More Show Less

Table of Contents

About the Cover xxi

Foreword to the Second Edition xxiii

Foreword to the First Edition xxv

Preface xxix

Acknowledgments xxxiii

Reader’s Guide xxxv

Prologue: Software Architectures and Documentation 1

P.1: A Short Overview of Software Architecture 1

P.2: A Short Overview of Architecture Documentation 9

P.3: Architecture Views 22

P.4: Architecture Styles 25

P.5: Seven Rules for Sound Documentation 36

P.6: Summary Checklist 45

P.7: Discussion Questions 46

P.8: For Further Reading 47

Part I: A Collection of Software Architecture Styles 49

I.1: Three Categories of Styles 49

I.2: Style Guides: A Standard Organization for Explaining a Style 50

I.3: Choosing Which Element and Relation Properties to Document 52

I.4: Notations for Architecture Views 53

I.5: Examples 54

Chapter 1: Module Views 55

1.1: Overview 55

1.2: Elements, Relations, and Properties of Module Views 56

1.3: What Module Views Are For 59

1.4: Notations for Module Views 60

1.5: Relation to Other Views 63

1.6: Summary Checklist 63

1.7: Discussion Questions 64

1.8: For Further Reading 64

Chapter 2: A Tour of Some Module Styles 65

2.1: Decomposition Style 65

2.2: Uses Style 74

2.3: Generalization Style 82

2.4: Layered Style 87

2.5: Aspects Style 104

2.6: Data Model 109

2.7: Summary Checklist 120

2.8: Discussion Questions 120

2.9: For Further Reading 121

Chapter 3: Component-and-Connector Views 123

3.1: Overview 123

3.2: Elements, Relations, and Properties of C&C Views 126

3.3: What C&C Views Are For 136

3.4: Notations for C&C Views 139

3.5: Relation to Other Kinds of Views 148

3.6: Summary Checklist 150

3.7: Discussion Questions 151

3.8: For Further Reading 152

Chapter 4: A Tour of Some Component-and-Connector Styles 155

4.1: An Introduction to C&C Styles 155

4.2: Data Flow Styles 157

4.3: Call-Return Styles 161

4.4: Event-Based Styles 172

4.5: Repository Styles 178

4.6: Crosscutting Issues for C&C Styles 182

4.7: Summary Checklist 185

4.8: Discussion Questions 186

4.9: For Further Reading 187

Chapter 5: Allocation Views and a Tour of Some Allocation Styles 189

5.1: Overview 189

5.2: Deployment Style 191

5.3: Install Style 198

5.4: Work Assignment Style 202

5.5: Other Allocation Styles 206

5.6: Summary Checklist 213

5.7: Discussion Questions 213

5.8: For Further Reading 214

Part II: Beyond Structure: Completing the Documentation 215

Chapter 6: Beyond the Basics 217

6.1: Refinement 218

6.2: Descriptive Completeness 222

6.3: Documenting Context Diagrams 225

6.4: Documenting Variation Points 231

6.5: Documenting Architectural Decisions 239

6.6: Combining Views 250

6.7: Summary Checklist 258

6.8: Discussion Questions 259

6.9: For Further Reading 260

Chapter 7: Documenting Software Interfaces 261

7.1: Overview 261

7.2: Interface Documentation 265

7.3: A Standard Organization for Interface Documentation 271

7.4: Stakeholders of Interface Documentation 278

7.5: Conveying Syntactic Information 279

7.6: Conveying Semantic Information 280

7.7: Examples of Interface Documentation 281

7.8: Summary Checklist 285

7.9: Discussion Questions 286

7.10: For Further Reading 286

Chapter 8: Documenting Behavior 289

8.1: Beyond Structure 289

8.2: How to Document Behavior 290

8.3: Notations for Documenting Behavior 295

8.4: Where to Document Behavior 306

8.5: Why to Document Behavior 306

8.6: Summary Checklist 308

8.7: Discussion Questions 309

8.8: For Further Reading 311

Part III: Building the Architecture Documentation 313

Chapter 9: Choosing the Views 315

9.1: Stakeholders and Their Documentation Needs 316

9.2: A Method for Choosing the Views 326

9.3: Example 329

9.4: Summary Checklist 335

9.5: Discussion Questions 335

9.6: For Further Reading 335

Chapter 10: Building the Documentation Package 337

10.1: Documenting a View 337

10.2: Documentation Beyond Views 350

10.3: Documenting a Mapping to Requirements 357

10.4: Packaging the Architecture Documentation 362

10.5: Summary Checklist 372

10.6: For Further Reading 373

Chapter 11: Reviewing an Architecture Document 375

11.1: Steps of the Procedure 376

11.2: Sample Question Sets for Reviewing the Architecture Document 382

11.3: An Example of Constructing and Conducting a Review 393

11.4: Summary Checklist 395

11.5: Discussion Questions 396

11.6: For Further Reading 396

Epilogue: Using Views and Beyond with Other Approaches 399

E.1: ISO/IEC 42010, née ANSI/IEEE Std 1471-2000 400

E.2: Rational Unified Process/Kruchten 4+1 406

E.3: Using the Rozanski and Woods Viewpoint Set 408

E.4: Documenting Architecture in an Agile Development Project 414

E.5: U.S. Department of Defense Architecture Framework 419

E.6: Where Architecture Documentation Ends 428

E.7: A Final Word 429

E.8: For Further Reading 429

Appendix A: UML—Unified Modeling Language 431

A.1: Introduction 431

A.2: Documenting a Module View 433

A.3: Documenting a Component-and-Connector View 438

A.4: Documenting an Allocation View 443

A.5: Documenting Behavior 449

A.6: Documenting Interfaces 460

Appendix B: SysML—Systems Modeling Language 465

B.1: Architecture Documentation 466

B.2: Requirements 466

B.3: Documenting a Module View 468

B.4: Documenting a Component-and-Connector View 469

B.5: Documenting an Allocation View 470

B.6: Documenting Behavior 471

B.7: Documenting Interfaces 472

B.8: Summary 472

Appendix C: AADL—The SAE Architecture Analysis and Design Language 473

C.1: Introduction 473

C.2: Documenting a Module Style 475

C.3: Documenting a Component-and-Connector View 478

C.4: Documenting a Deployment View 481

C.5: Documenting Behavior 482

C.6: Documenting Interfaces 484

C.7: Summary 484

Acronyms 487

Glossary 491

References 497

About the Authors 509

About the Contributors 513

Index 517

Read More Show Less

Preface

For all but the most trivial software system, success will be elusive if you fail to pay careful attention to its architecture: the way the system is decomposed into constituent parts and the ways those parts interact. Without an architecture that is appropriate for the problem being solved, the project will fail. Even with a superb architecture, if it is not well understood and well communicated—in other words, well documented—the project is likely to flounder.

Accordingly, software architecture is at the center of a frenzy of attention these days. A new book about it seems to pop out monthly. In response to industrial need, universities are adding software architecture to their software engineering curricula. It's now common for "software architect" to be a defined position in organizations, and professional practice groups for software architects are emerging. Software architecture has been the subject of major international conferences and workshops. The purveyors of the Unified Modeling Language (UML) promote their product by calling it "the standard notationfor software architecture," a claim that may say at least as much about the pervasiveness of architecture as about UML. The Software Engineering Institute of Carnegie Mellon University (SEI) maintains a bibliography of about 1,000 journal and conference papers on software architecture.

Rather surprisingly, practical guidance that is independent of language or notation for how to capture an architecture is lacking. To be sure, piles of books exist about how to use a particular language—again, UML comes to mind—but what an architect really needs is guidance in which architecture is a first-classcitizen, with language relegated more appropriately to a supporting role.

First, let's agree on some basic context. The field has not anointed a single definition of software architecture, and so there are many, but we can specify the one we'll use, which is adapted from Bass, Clements, and Kazman (1998). Although much of this book is about the meaning of elements and relationships, we use this definition now to emphasize the plurality of structures that exist in architectures. Each structure is characterized by various kinds of elements and relationships, and each structure provides a view that imparts a particular kind of understanding of the architecture.

Definition: A software architecture for a system is the structure or structures of the system, which consist of elements, their externally visible properties, and the relationships among them.

"Externally visible properties" are those assumptions other components can make of a component, such as its provided services, quality attribute properties, shared resource usage, and so on.

The architecture serves as the blueprint for both the system and the project developing it, defining the work assignments that must be carried out by design and implementation teams. The architecture is the primary carrier of system qualities, such as performance, modifiability, and security, none of which can be achieved without a unifying architectural vision. Architecture is an artifact for early analysis to make sure that the design approach will yield an acceptable system. Architecture holds the key to post-deployment system understanding, maintenance, and mining efforts. In short, architecture is the conceptual glue that holds every phase of the project together for all its many stakeholders.

Documenting the architecture is the crowning step to crafting it. The perfect architecture is useless if it has not been expressed understandably. If you go to the trouble of creating a strong architecture, you must go to the trouble of describing it in enough detail, without ambiguity, and organized so that others can quickly find needed information. Otherwise, your effort will have been wasted, because the architecture will be unusable.

The audience for this book includes the people involved in the production and consumption of architectural documentation: the community of software developers. The goal of this book is to help you decide what information about an architecture is important to capture and to provide guidelines, notations, and examples for capturing it. We intend this book to be a practitioner-oriented guide to the various kinds of information that constitute an architecture. We give practical guidance for choosing what information should be documented and show—with examples in various notations, including but not limited to UML—how to describe that information in writing so that others can use it to carry out their architecture-based work: implementation, analysis, recovery, and so on. Therefore, we cover

  • Uses of software architecture documentation. How one documents depends on how one wishes to use the documentation. We lay out possible end goals for architecture documentation and provide documentation strategies for each.
  • Architectural views. We hold that documenting software architecture is primarily about documenting the relevant views and then augmen this information with relevant information that applies beyond views. The heart of the book is an introduction to the most relevant architectural views, grouped into three major families, which we call viewtypes, along with practical guidance about how to write them down. Examples are included for each.
  • Packaging the information. Once the views have been understood, the problem remains of choosing the relevant views, including information not contained in a view, and packaging all the information as a coherent whole. We give practical advice for all these facets.

We believe strongly in the importance of architecture in building successful systems. But no architecture can achieve this if it is not effectively communicated, and documentation is the key to successful communication. We hope that we have provided a useful handbook for practitioners in the field.

—P.C.C.,
Austin, Texas
—F.B., L.B., D.G., J.I., R.L., R.N., J.S.,
Pittsburgh, Pennsylvania

Read More Show Less

Introduction

For all but the most trivial software systems, you cannot hope to succeed without paying careful attention to its architecture: the way the system is decomposed into constituent parts and the ways those parts interact with each other. Without an architecture that is appropriate for the problem being solved the project will fail. Even with a superb architecture, if it is not well understood and well communicated—in other words, well documented—the project will fail. Not may fail. Will fail.

Accordingly, software architecture is at the center of a frenzy of attention these days. A new book about it seems to pop out monthly. In response to industrial need, universities are adding software architecture to their software engineering curricula. It's now common for "software architect" to be a defined position in organizations, and professional practice groups for software architects are emerging. It has been the subject of major international conferences and workshops. The purveyors of the Unified Modeling Language promote their product by calling it "the standard notation for software architecture" (a claim that may say at least as much about the pervasiveness of architecture as about UML). The Software Engineering Institute maintains a bibliography of journal and conference papers about software architecture and its population is approaching 1000.

Rather surprisingly, there is a dearth of practical guidance available that is independent of language or notation for how to capture an architecture. To be sure, piles of books exist about how to use a particular language—again, UML comes to mind—but what an architect really needs is guidancein which architecture is a first-class citizen and language is relegated more appropriately to a supporting role.

First, let's agree on some basic context. The field has not anointed a single definition of software architecture, and so there are many, but we'll use this one:

A software architecture for a system is the structure or structures of the system, which comprise elements, their externally-visible behavior, and the relationships among them. (Adapted from Bass 98.)

Much of this book is about the meaning of elements and relationships, but for now we use this definition to emphasize the plurality of structures that exist in architectures. Each structure is characterized by different kinds of elements and relationships, and each structure provides a view of the architecture that imparts a particular kind of understanding.

The architecture serves as the blueprint for both the system and the project developing it. It defines the work assignments that must be carried out by design and implementation teams. The architecture is the primary carrier of system qualities such as performance, modifiability, and security, none of which can be achieved without a unifying architectural vision. Architecture is an artifact for early analysis to make sure that the design approach will yield an acceptable system. And architecture holds the key to post-deployment system understand-ing, maintenance, and mining efforts. In short, architecture is the conceptual glue that holds every phase of the project together for all of its many stakeholders.

And documenting the architecture is the crowning step to crafting it. The perfect architecture is useless if it has not been expressed understandably. If you go to the trouble of creating a strong architecture, you must go to the trouble of describing it in enough detail, without ambiguity, and organized so that others can quickly find needed information. Otherwise your effort will have been wasted, because the architecture will be unusable.

The goal of this book is to help you decide what information about an architecture is important to capture and to provide guidelines and notations (and examples) for capturing it. We intend this book to be a practitioner- oriented guide to the different kinds of information that constitute an architecture. We wanted to give practical guidance for choosing what information should be documented, and show (with examples in various notations, including but not limited to UML) how to describe that information in writing so that others can use it to carry out their architecture-based work: implementation, analysis, recovery, etc. Therefore, we cover:

  • Uses of software architecture documentation. How one documents depends on how one wishes to use the documentation. We lay out possible end goals for architecture documentation, and provide documentation strategies for each.
  • Architectural views. We hold that documenting software architecture is primarily about documenting the relevant views, and then augmenting this information with relevant information that applies across views. The heart of the book is an introduction to the most relevant architectural views, grouped into three major families (which we call viewtypes) along with practical guidance about how to write them down. Examples are included for each.
  • Pack information. Once the views have been understood, there is still the problem of choosing the relevant views, including information not contained in a view, and packaging all of the information as a coherent whole. has been created, We give practical advice for all of these facets.

The audience for this book includes the people involved in the production and consumption of architectural documentation, which is to say the community of software developers.

We believe strongly in the importance of architecture in building successful systems. But no architecture can achieve this if it is not effectively communicated, and documentation is the key to successful communication. We hope we have provided a useful handbook for practitioners in the field.

PC—Austin, Texas
FB, LB, DG, JI, RL, RN, JS—Pittsburgh, Pennsylvania


Read More Show Less

Customer Reviews

Be the first to write a review
( 0 )
Rating Distribution

5 Star

(0)

4 Star

(0)

3 Star

(0)

2 Star

(0)

1 Star

(0)

Your Rating:

Your Name: Create a Pen Name or

Barnes & Noble.com Review Rules

Our reader reviews allow you to share your comments on titles you liked, or didn't, with others. By submitting an online review, you are representing to Barnes & Noble.com that all information contained in your review is original and accurate in all respects, and that the submission of such content by you and the posting of such content by Barnes & Noble.com does not and will not violate the rights of any third party. Please follow the rules below to help ensure that your review can be posted.

Reviews by Our Customers Under the Age of 13

We highly value and respect everyone's opinion concerning the titles we offer. However, we cannot allow persons under the age of 13 to have accounts at BN.com or to post customer reviews. Please see our Terms of Use for more details.

What to exclude from your review:

Please do not write about reviews, commentary, or information posted on the product page. If you see any errors in the information on the product page, please send us an email.

Reviews should not contain any of the following:

  • - HTML tags, profanity, obscenities, vulgarities, or comments that defame anyone
  • - Time-sensitive information such as tour dates, signings, lectures, etc.
  • - Single-word reviews. Other people will read your review to discover why you liked or didn't like the title. Be descriptive.
  • - Comments focusing on the author or that may ruin the ending for others
  • - Phone numbers, addresses, URLs
  • - Pricing and availability information or alternative ordering information
  • - Advertisements or commercial solicitation

Reminder:

  • - By submitting a review, you grant to Barnes & Noble.com and its sublicensees the royalty-free, perpetual, irrevocable right and license to use the review in accordance with the Barnes & Noble.com Terms of Use.
  • - Barnes & Noble.com reserves the right not to post any review -- particularly those that do not follow the terms and conditions of these Rules. Barnes & Noble.com also reserves the right to remove any review at any time without notice.
  • - See Terms of Use for other conditions and disclaimers.
Search for Products You'd Like to Recommend

Recommend other products that relate to your review. Just search for them below and share!

Create a Pen Name

Your Pen Name is your unique identity on BN.com. It will appear on the reviews you write and other website activities. Your Pen Name cannot be edited, changed or deleted once submitted.

 
Your Pen Name can be any combination of alphanumeric characters (plus - and _), and must be at least two characters long.

Continue Anonymously

    If you find inappropriate content, please report it to Barnes & Noble
    Why is this product inappropriate?
    Comments (optional)