Applied Software Architecture

Figure 1: A European starling (Sturnus vulgaris) and a Lockheed SR-71, two black birds that trave.........Page 4
Contents and Organization......Page 15
Stylistic conventions......Page 17
How to Read this Book; How to Use this Book......Page 19
Commercial Tools and Notations......Page 20
The Role of Architecture......Page 23
Uses of architecture documentation......Page 24
Seven Rules for Sound Documentation......Page 32
Views......Page 39
Figure 3: A documentation package for a software architecture is composed of several parts. The m.........Page 41
Viewtypes......Page 43
Styles......Page 44
Summary: Viewtypes, Styles, and Views......Page 46
Glossary......Page 49
For Further Reading......Page 50
Discussion questions......Page 52
References (to be moved to central Bibliography in back)......Page 53
1.1 Overview: What is the Module Viewtype?......Page 56
1.2 Elements, Relations, and Properties of the Module Viewtype......Page 57
Properties......Page 58
Figure 4: (a): Module C provides its own interface, hiding the interfaces of modules A and B......Page 60
Information notations......Page 61
Figure 6: Examples of relation notations in UML. From left to right the diagrams read as follows:.........Page 62
1.6 Glossary......Page 63
1.8 For Further Reading......Page 64
1.9 Discussion questions......Page 65
Overview of the Decomposition Style......Page 66
Elements, Relations, and Properties of the Decomposition Style......Page 67
What the Decomposition Style Is For and What It’s Not For......Page 69
UML......Page 70
Relation of the Decomposition Style to Other Styles......Page 71
Figure 8: The module decomposition view of the A-7E software architecture......Page 72
Mil-Std 498 CSCIs and CSCs......Page 75
What the Uses Style Is For and What It’s Not For......Page 76
UML......Page 77
Figure 9: (a): Example of uses relation mapped to decomposed modules. Here, the User Interface mo.........Page 78
Example of the Uses Style......Page 79
Figure 11: Using sandwiching to break loops in the uses relation. In the figure on the left, if a.........Page 84
Overview of the Generalization Style......Page 85
Elements/Relations/Properties of the Generalization Style......Page 86
What the Generalization Style Is For and What It’s Not For......Page 87
Figure 12: Documenting generalization in UML. UML provides two line styles to show generalization.........Page 88
Figure 13: UML shows interface and implementation inheritance in different ways. tbd: beef up thi.........Page 89
Examples of the Generalization Style......Page 90
Overview of the Layered Style......Page 91
Properties......Page 95
What the Layered Style Is For and What It’s Not For......Page 97
Informal Notations......Page 98
Figure 15: A 3-D or “toaster” model showing segmented layers. (placeholder for real figure, which.........Page 101
Figure 17: A simple representation of layers in UML.......Page 102
Relation of the Layered Style to Other Styles......Page 104
Example of the Layered Style......Page 106
2.8 Discussion Questions......Page 107
2.9 References [move to back of book]......Page 108
3.1 Introduction......Page 109
Figure 19: A bird’s-eye-view of the system as it might appear during run time. The system contain.........Page 110
3.2 Elements, Relations, and Properties of the C&C Viewtype......Page 111
Elements......Page 112
Components......Page 113
Connectors......Page 114
Figure 21: Two potential versions of a publish-subscribe system. In Version 1 all communication t.........Page 117
Relations......Page 118
Properties......Page 120
3.3 What the C&C Viewtype Is For, and What It’s Not For......Page 121
3.5 Relation of Views in the C&C Viewtype with Views in Other Viewtypes......Page 122
3.9 Discussion Questions......Page 123
4.1 Datastream Styles......Page 125
The Client-Server Style......Page 127
The Peer-to-Peer Style......Page 128
4.3 Shared-data Styles......Page 129
4.4 Publish-Subscribe Styles......Page 131
Confusion 1: Datastream styles and Dataflow Projections......Page 133
Between a non-process C&C view and Communicating Process views......Page 134
Between C&C and Module views......Page 135
Box and Arrow Diagrams......Page 136
Acme ADL......Page 137
UML......Page 138
Figure 26: Types as classes, instances as objects.......Page 139
Figure 27: Six ways to represent ports. Option 1 is to avoid the issue by not representing ports .........Page 140
Strategy 2: Classes & Objects – Types as Classes, Instances as Classes......Page 144
Figure 29: Types and instances as classes.......Page 145
Strategy 3: Classes & Objects – Types as Stereotypes, Instances as Classes......Page 146
Figure 31: Types as stereotypes, instances as stereotyped classes.......Page 147
Figure 32: Components as UML components.......Page 148
Figure 33: Components as subsystems.......Page 149
Strategy 6: Using the UML Real-Time Profile (UML-RT)......Page 150
Figure 34: UML-RT collaboration diagram for system simple: PF.......Page 152
4.11 For Further Reading......Page 155
4.13 References [move to back of book]......Page 156
5.1 Overview......Page 159
5.2 Elements, Relations, and Properties of the Allocation Viewtype......Page 160
5.3 What the Allocation Viewtype Is For and What It’s Not For......Page 161
UML......Page 162
5.8 Discussion Questions......Page 163
Elements, Relations, and Properties of the Deployment Style......Page 164
What the Deployment Style is For and What It’s Not For......Page 166
UML......Page 167
Examples of the Deployment Style......Page 168
Figure 37: Example view of the Deployment style, in an informal notation [key tbd] This example u.........Page 169
Figure 38: A deployment view in UML (tbd)......Page 170
Elements, Relations, and Properties of the Implementation Style......Page 171
Notation for the Implementation Style......Page 172
Examples of the Implementation Style......Page 173
Elements, Relations, and Properties of the Work Assignment Style......Page 174
Notations for the Work Assignment Style......Page 175
6.4 Glossary......Page 176
6.7 Discussion Questions......Page 177
View packets......Page 180
View packets from different views......Page 181
Refinement......Page 182
Figure 40: (a) A hypothetical system consists of elements A, B, and C with some relation (the nat.........Page 183
Figure 41: A cartoon for an imaginary system. A is related to B, B is related to C, and C is rela.........Page 184
Figure 42: A supplement to the previous cartoon, showing alternative relationships among the elem.........Page 185
Figure 43: A refinement to the cartoon of Figure 41, showing an additional element D.......Page 186
Top-level context diagrams......Page 187
Context diagrams and the other supporting documentation......Page 188
Informal......Page 189
UML......Page 190
Figure 45: An example of a context diagram [TAKEN FROM ONE OF THE 3 RUNNING EXAMPLES]......Page 191
7.3 Combining Views......Page 192
When might views be combined?......Page 193
Figure 46: Many-to-one mapping. Multiple elements from one view can be mapped to a single element.........Page 195
Figure 47: An element of one view can be mapped to multiple elements in another view. Althought t.........Page 196
Elements, relations, and properties of combined views......Page 197
Figure 48: Multiple elements from one view can be mapped to a single element of another view. Her.........Page 198
N-tier client-server......Page 199
Variability......Page 200
Recording information about variability and dynamism......Page 201
Informal notations......Page 202
Formal notations......Page 203
Documenting Styles......Page 205
Style-Patterns:......Page 206
7.7 Summary checklist......Page 207
7.10 References (move to back of book)......Page 208
8.1 Introduction: Beyond Structure......Page 209
8.3 Why Document Behavior?......Page 210
Driving Development Activities......Page 211
8.4 What to Document......Page 212
Constraints on Ordering......Page 213
8.5 How to Document Behavior: Notations and Languages......Page 214
Statecharts......Page 216
Figure 52: Statechart representation of JavePhone. Sequence is represented by an single-headed ar.........Page 218
SDL......Page 219
Figure 53: Hierarchical Structure in SDL. The structure of a system is decomposed into a hierarch.........Page 220
Z......Page 221
Trace-oriented representations......Page 222
Use Case Diagrams......Page 223
Figure 56: Use Case Diagram Example of JavaPhone.......Page 224
Figure 57: Sketch of activities through some components......Page 225
Figure 58: .Use Case Map “Establish Point-to-Point Connection”. Execution paths are represented a.........Page 227
Figure 59: Example sequence diagram. Instances have a “lifeline” drawn as a vertical line along t.........Page 228
Figure 60: Example sequence diagram of “Establish Point-to-Point Connection”. The lifeline is sho.........Page 229
Figure 61: Procedural sequence diagram of “Establish Point-to-Point Connection”. An arrow (solid .........Page 230
Collaboration Diagrams......Page 231
Figure 62: Example Collaboration diagram of “Establish Point-to-Point Connection”. The sequence o.........Page 232
Message Sequence Charts......Page 233
8.6 Summary......Page 234
8.7 Glossary......Page 235
8.9 For Further Reading......Page 236
8.10 Discussion questions......Page 238
8.11 References (to be moved to central Bibliography in back)......Page 239
9.1 Introduction......Page 241
9.2 Usage-based view selection......Page 242
Summary......Page 246
A-7E......Page 249
9.7 For Further Reading......Page 250
9.8 Discussion Questions tbd......Page 251
10.1 Documenting a view......Page 252
Figure 64: Documenting a view consists of documenting seven parts: (1) the primary presentation; .........Page 255
10.2 Documentation across views......Page 257
View Template......Page 258
View Catalog......Page 259
Mapping Between Views......Page 261
Project glossary......Page 262
3. Why the architecture is the way it is: Rationale......Page 263
Figure 67: Sample Issue Card (Source: Applied Software Architecture)......Page 266
10.5 For Further Reading......Page 267
10.6 Discussion Questions......Page 268
11.1 Introduction......Page 269
11.2 Documenting an interface......Page 271
11.3 A standard organization for interface documentation......Page 272
Figure 68: Documentation for an interface consists of the ten parts shown above.......Page 275
Figure 69: A taxonomy of exceptions associated with a resource on an element’s interface.......Page 278
11.4 Stakeholders of interface documentation......Page 280
Figure 70: Graphical notations for interfaces typically show a symbol on the boundary of the icon.........Page 282
Figure 11-2 (a): Does element E have one interface or two? This cartoon makes it difficult to det.........Page 283
Figure 71: Three ways to handle multiple actors interacting with an element. Figure (a) shows ele.........Page 284
Figure 72: An interface can be shown separately from any element that realizes it. This emphasize.........Page 285
Notations for conveying semantic information......Page 286
Summary of notations for interface documentation......Page 287
Interface Example #1: SCR-style Interface......Page 288
Figure 74: An example of IDL for an element in a banking application, from [Bass 98]. The element.........Page 301
Interface Example #3: An Interface in the HLA Style......Page 302
Figure 75: Example of documentation for an interface resource, taken from the HLA.......Page 304
Figure 76: This Statechart shows the constraints on the order of use of a specific set of the res.........Page 305
A Microsoft API......Page 306
11.7 Glossary......Page 307
11.10 Discussion Questions......Page 308
12.1 Introduction......Page 309
12.2 Active Design Reviews for Architecture Documenation [in progress]......Page 311
12.4 Summary checklist......Page 316
12.6 Discussion Questions......Page 317
13.1 Introduction......Page 318
13.2 Rational Unified Process / Kruchten 4+1......Page 319
The Deployment View......Page 320
The Use-Case View......Page 321
13.3 Siemens Four Views......Page 322
Figure 77: The Four Views of Software Architecture Source: Applied Software Architecture [redraw .........Page 323
Introduction......Page 328
Common Products......Page 329
13.6 Hewlett Packard......Page 332
Data flow views......Page 333
Control Flow Views......Page 338
13.8 Glossary......Page 339
13.12 References (move to back of book)......Page 340