did-you-know? rent-now

Amazon no longer offers textbook rentals. We do!

did-you-know? rent-now

Amazon no longer offers textbook rentals. We do!

We're the #1 textbook rental company. Let us show you why.

9780201703726

Documenting Software Architectures Views and Beyond

by ; ; ; ; ; ; ;
  • ISBN13:

    9780201703726

  • ISBN10:

    0201703726

  • Edition: 1st
  • Format: Hardcover
  • Copyright: 2002-09-26
  • Publisher: Addison-Wesley Professional
  • View Upgraded Edition
  • Purchase Benefits
  • Free Shipping Icon Free Shipping On Orders Over $35!
    Your order must be $35 or more to qualify for free economy shipping. Bulk sales, PO's, Marketplace items, eBooks and apparel do not qualify for this offer.
  • eCampus.com Logo Get Rewarded for Ordering Your Textbooks! Enroll Now
List Price: $74.99

Summary

Helps you decide what information to document and then, with guidelines and examples, shows you how to express an architecture in a form that everyone can understand. An important reference on the shelf of the software architect.

Author Biography

Paul Clements, Felix Bachmann, Len Bass, David Garlan, James Ivers, Reed Little, Robert Nord, and Judith Stafford are all influential members of the software architecture community. They work as a team within the Software Engineering Institute to develop and communicate effective methods and practices for software architecture. Each has worked to build systems architectures and, among them, they are the authors of a number of leading-edge books on the topic

Table of Contents

About the Coverp. xix
Forewordp. xxi
Prefacep. xxv
Acknowledgmentsp. xxix
Reader's Guidep. xxxi
Prologue: Software Architectures and Documentationp. 1
The Role of Architecturep. 1
Coming to Terms: Software Architecturep. 2
Perspectives: What's the Difference Between Architecture and Design?p. 5
Coming to Terms: Documentation, Description, Representation, Specificationp. 8
Uses of Architecture Documentationp. 10
Interfacesp. 12
Viewsp. 13
Coming to Terms: Architectural Viewsp. 15
Viewtypes and Stylesp. 18
Viewtypesp. 18
Stylesp. 18
Summary: Viewtypes, Styles, and Viewsp. 20
Coming to Terms: Module, Componentp. 21
Seven Rules for Sound Documentationp. 24
Rule 1: Write Documentation from the Reader's Point of Viewp. 24
Rule 2: Avoid Unnecessary Repetitionp. 25
Rule 3: Avoid Ambiguityp. 25
Rule 4: Use a Standard Organizationp. 26
Rule 5: Record Rationalep. 27
Rule 6: Keep Documentation Current But Not Too Currentp. 27
Rule 7: Review Documentation for Fitness of Purposep. 28
Perspectives: Quivering at Arrowsp. 28
Summary Checklistp. 30
Discussion Questionsp. 31
For Further Readingp. 32
Software Architecture Viewtypes and Styles
Viewtypes and Style Catalogp. 35
Module Viewtypep. 35
Component-and-Connector Viewtypep. 36
Allocation Viewtypep. 38
Style Guides: A Standard Organization for Documenting a Stylep. 39
The Module Viewtypep. 41
Overviewp. 41
Elements, Relations, and Properties of the Module Viewtypep. 42
Elementsp. 43
Relationsp. 43
Propertiesp. 44
Coming to Terms: Substitutabilityp. 46
What the Module Viewtype Is For and What It's Not Forp. 47
Notations for the Module Viewtypep. 48
Informal Notationsp. 48
UMLp. 48
Relation to Other Viewtypesp. 48
Summary Checklistp. 50
Discussion Questionsp. 50
For Further Readingp. 51
Styles of the Module Viewtypep. 53
Decomposition Stylep. 53
Overviewp. 53
Elements, Relations, and Propertiesp. 54
What the Decomposition Style Is For and What It's Not Forp. 55
Notations for the Decomposition Stylep. 56
Relation to Other Stylesp. 57
Examples of the Decomposition Stylep. 57
Coming to Terms: Subsystemp. 62
Uses Stylep. 64
Overviewp. 64
Elements, Relations, and Propertiesp. 65
What the Uses Style Is For and What It's Not Forp. 65
Notations for the Uses Stylep. 65
Relation to Other Stylesp. 67
Example of the Uses Stylep. 67
Coming to Terms: Usesp. 68
Generalization Stylep. 71
Overviewp. 71
Elements, Relations, and Propertiesp. 72
What the Generalization Style Is For and What It's Not Forp. 73
Notations for the Generalization Stylep. 74
Relation to Other Stylesp. 74
Coming to Terms: Generalizationp. 76
Examples of the Generalization Stylep. 77
Layered Stylep. 77
Overviewp. 77
Elements, Relations, and Propertiesp. 80
What the Layered Style Is For and What It's Not Forp. 82
Notations for the Layered Stylep. 83
Relation to Other Stylesp. 88
Examples of the Layered Stylep. 91
Coming to Terms: Virtual Machinesp. 93
Perspectives: Upwardly Mobile Softwarep. 94
Perspectives: Levels of Distractionp. 95
Perspectives: UML Class Diagrams: Too Much, Too Littlep. 97
Summary Checklistp. 99
Discussion Questionsp. 99
For Further Readingp. 100
The Component-and-Connector Viewtypep. 103
Overviewp. 103
Elements, Relations, and Properties of the C&C Viewtypep. 106
Elementsp. 107
Relationsp. 110
Propertiesp. 111
Perspectives: Are Connectors Necessary?p. 112
Perspectives: Choosing Connector Abstractionsp. 114
What the C&C Viewtype Is For and What It's Not Forp. 116
Perspectives: Data Flow and Control Flow Projectionsp. 117
Notations for the C&C Viewtypep. 118
Relation to Other Viewtypesp. 118
Summary Checklistp. 120
Discussion Questionsp. 121
For Further Readingp. 123
Styles of the Component-and-Connector Viewtypep. 125
The Pipe-and-Filter Stylep. 126
Overviewp. 126
Elements, Relations, and Propertiesp. 126
What the Pipe-and-Filter Style Is For and What It's Not Forp. 127
Relation to Other Stylesp. 127
Examples of the Pipe-and-Filter Stylep. 128
Shared-Data Stylep. 129
Overviewp. 129
Elements, Relations, and Propertiesp. 129
What the Shared-Data Style Is For and What It's Not Forp. 131
Relation to Other Stylesp. 131
Example of the Shared-Data Stylep. 132
Publish-Subscribe Stylep. 132
Overviewp. 132
Elements, Relations, and Propertiesp. 133
What the Publish-Subscribe Style Is For and What It's Not Forp. 134
Relation to Other Stylesp. 134
Examples of the Publish-Subscribe Stylep. 135
Client-Server Stylep. 135
Overviewp. 135
Elements, Relations, and Propertiesp. 136
What the Client-Server Style Is For and What It's Not Forp. 137
Relation to Other Stylesp. 138
Examples of the Client-Server Stylep. 138
Peer-to-Peer Stylep. 139
Overviewp. 139
Elements, Relations, and Propertiesp. 139
What the Peer-to-Peer Style Is For and What It's Not Forp. 140
Relation to Other Stylesp. 141
Examples of the Peer-to-Peer Stylep. 141
Communicating-Processes Stylep. 142
Overviewp. 142
Elements, Relations, and Propertiesp. 142
What the Communicating-Processes Style Is For and What It's Not Forp. 143
Relation to Other Stylesp. 143
Examples of the Communicating-Processes Stylep. 143
Notations for C&C Stylesp. 143
Informal Notationsp. 144
Formal Notationsp. 145
Perspectives: Using Classes to Represent Component Types and Instancesp. 159
Coming to Terms: Components Versus UML Componentsp. 161
Summary Checklistp. 163
Discussion Questionsp. 164
For Further Readingp. 165
The Allocation Viewtype and Stylesp. 167
Overviewp. 167
Elements, Relations, and Properties of the Allocation Viewtypep. 168
Deployment Stylep. 169
Overviewp. 169
Elements, Relations, and Propertiesp. 170
What the Deployment Style Is For and What It's Not Forp. 172
Notation for the Deployment Stylep. 173
Relation to Other Stylesp. 175
Examples of the Deployment Stylep. 175
Implementation Stylep. 175
Overviewp. 175
Elements, Relations, and Propertiesp. 177
What the Implementation Style Is For and What It's Not Forp. 178
Notation for the Implementation Stylep. 178
Relation to Other Stylesp. 179
Example of the Implementation Stylep. 179
Work Assignment Stylep. 179
Elements, Relations, and Propertiesp. 179
What the Work Assignment Style Is For and What It's Not Forp. 180
Notations for the Work Assignment Stylep. 181
Relation to Other Stylesp. 181
Example of the Work Assignment Stylep. 182
Summary Checklistp. 183
Discussion Questionsp. 183
For Further Readingp. 184
Software Architecture Documentation in Practice
Advanced Conceptsp. 187
Chunking Information: View Packets, Refinement, and Descriptive Completenessp. 188
View Packetsp. 188
Refinementp. 191
Descriptive Completenessp. 192
Using Context Diagramsp. 195
Top-Level Context Diagramsp. 196
Content of a Context Diagramp. 197
Context Diagrams and Other Supporting Documentationp. 197
Notations for Context Diagramsp. 198
Example of a Context Diagramp. 200
Combined Viewsp. 200
When to Combine Viewsp. 201
Types of Mappingp. 203
Elements, Relations, and Propertiesp. 205
Documenting Combined Viewsp. 206
Examples of Combined Viewsp. 207
Other Examplesp. 208
Documenting Variability and Dynamismp. 209
Variabilityp. 209
Dynamismp. 210
Recording the Informationp. 211
Notations for Variability and Dynamismp. 212
Perspectives: What Time Is It?p. 213
Creating and Documenting a New Stylep. 215
Coming to Terms: Styles, Patternsp. 217
Summary Checklistp. 219
Discussion Questionsp. 220
For Further Readingp. 220
Documenting Software Interfacesp. 223
Overviewp. 223
Interface Specificationsp. 226
A Standard Organization for Interface Documentationp. 228
Coming to Terms: Exceptions and Error Handlingp. 233
Stakeholders of Interface Documentationp. 237
Notation for Interface Documentationp. 239
Showing the Existence of Interfacesp. 239
Conveying Syntactic Informationp. 241
Conveying Semantic Informationp. 242
Summaryp. 242
Perspectives: Multiple Interfacesp. 242
Coming to Terms: Signature, Interface, APIp. 245
Examples of Interface Documentationp. 246
SCR-Style Interfacep. 246
IDLp. 252
Custom Notationp. 253
XMLp. 255
Summary Checklistp. 257
Discussion Questionsp. 257
For Further Readingp. 258
Documenting Behaviorp. 259
Beyond Structurep. 259
Where to Document Behaviorp. 260
Why to Document Behaviorp. 260
System Analysisp. 261
Driving Development Activitiesp. 262
What to Documentp. 263
Types of Communicationp. 264
Constraints on Orderingp. 264
Clock-Triggered Stimulationp. 265
How to Document Behavior: Notations and Languagesp. 266
Tracesp. 268
Static Modelsp. 275
Summary Checklistp. 284
Discussion Questionsp. 285
For Further Readingp. 285
Choosing the Viewsp. 289
Stakeholders and Their Documentation Needsp. 290
Perspectives: Architecture Trade-off Analysis Methodp. 302
Making the Choicep. 305
Two Examplesp. 306
A Small Project: A-7Ep. 306
A Large Project: ECSp. 308
Summary Checklistp. 312
Discussion Questionsp. 312
For Further Readingp. 313
Building the Documentation Packagep. 315
One Document or Several?p. 315
Perspectives: What the Meaning of "Is" Isp. 316
Documenting a Viewp. 317
Perspectives: Presentation Is Also Importantp. 321
Documentation Beyond Viewsp. 323
How the Documentation Is Organized to Serve a Stakeholderp. 324
What the Architecture Isp. 326
Why the Architecture Is the Way It is: Background, Design Constraints, and Rationalep. 328
Perspectives: Global Analysisp. 332
Validating Software Architecture Documentationp. 335
Perspectives: A Glossary Would Have Helpedp. 339
Summary Checklistp. 340
Discussion Questionsp. 340
For Further Readingp. 341
Other Views and Beyondp. 343
Overviewp. 343
Rational Unified Process/Kruchten 4+1p. 344
UMLp. 349
Class and Object Diagramsp. 349
Component Diagramsp. 350
Deployment Diagramsp. 351
Behavioral Diagramsp. 352
Siemens Four Viewsp. 352
Global Analysisp. 352
Conceptual Architecture Viewp. 353
Module Architecture Viewp. 354
Execution Architecture Viewp. 355
Code Architecture Viewp. 355
Summaryp. 356
C4ISR Architecture Frameworkp. 356
Common Architectural Views of the C4ISR Frameworkp. 357
Common Productsp. 358
ANSI / IEEE-1471-2000p. 361
Data Flow and Control Flowp. 363
Data Flow Viewsp. 364
Control Flow Viewsp. 365
Perspectives: You're All Just Guessing!p. 367
RM-ODPp. 372
Where Architecture Documentation Endsp. 373
Architecture Description Languagesp. 374
Commercial Componentsp. 376
Hypertext Documentationp. 378
Configuration Managementp. 378
A Final Wordp. 379
For Further Readingp. 380
Excerpts from a Software Architecture Documentation Packagep. 381
ECS Software Architecture Documentation Beyond Viewsp. 383
ECS Software Architecture Viewsp. 410
Glossaryp. 469
Referencesp. 473
Indexp. 483
Table of Contents provided by Syndetics. All Rights Reserved.

Supplemental Materials

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.

Excerpts

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 communicatedin other words, well documentedthe 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 languageagain, UML comes to mindbut 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 ofsoftware 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:Asoftware architecturefor 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.

Rewards Program