Software Design 2e - DIM

More documents

Recommendations

Info

part 2Transferring Design KnowledgeChapter 5 Describing a Design Solution 89Chapter 6 Transferring Design Knowledge 105Chapter 7 Some Design Representations 127Chapter 8 The Rationale for Method 175Chapter 9 Design Processes and Design Strategies 193Chapter 10 Design Patterns 213
Page 2 and 3:
Software Design
Page 4 and 5:
Software DesignDavid Budgen
Page 7 and 8:
viContentsChapter 4 Design Qualitie
Page 9 and 10:
viiiContentsChapter 16 Designing wi
Page 11 and 12:
xPreface to the second editiondescr
Page 13 and 14:
xiiPreface to the First EditionWhy
Page 15 and 16:
xivPreface to the first editionto t
Page 17 and 18:
xviPublisher’s AcknowledgementsWe
Page 20 and 21:
chapter 13The Nature of the Design
Page 22 and 23:
Design is just as important with so
Page 24 and 25:
Initialobservations7More systematic
Page 26 and 27:
development. However, it should als
Page 28 and 29:
From this relatively simple case st
Page 30 and 31:
nnWhere possible, the panels used i
Page 32 and 33:
It might well be argued that while
Page 34 and 35:
system being developed. Clearly, in
Page 36 and 37:
case study, the outline plan on squ
Page 38 and 39:
nnnWicked problems do not have an e
Page 40:
on to Pittsburgh. Airline B is the
Page 43 and 44:
262.1 What is software?The software
Page 45 and 46:
28nChangeability. Software suffers
Page 47 and 48:
30The software design processFigure
Page 49 and 50:
32The software design processthat a
Page 51 and 52:
34The software design processFigure
Page 53 and 54: 36The software design processFigure
Page 55 and 56: 38The software design processproces
Page 57 and 58: 40The software design processform p
Page 59 and 60: 42The software design processFigure
Page 61 and 62: 44The software design process2.3 De
Page 63 and 64: 463.1 A context for designDesign in
Page 65 and 66: 48Design in the software developmen
Page 71 and 72: 54A personal itchDesign in the soft
Page 77 and 78: 60nthe associated role of requireme
Page 80 and 81: chapter 463Design Qualities4.1 The
Page 82 and 83: is virtually impossible to modify i
Page 84 and 85: measurable characteristic that can
Page 86 and 87: 69Assessing design qualityFigure 4.
Page 88 and 89: nnnnreliabilityefficiencymaintainab
Page 90 and 91: Table 4.1The cognitive dimensions73
Page 92 and 93: system. The results of this study u
Page 94 and 95: nnnmodules are easy to replace;each
Page 96 and 97: Table 4.3The principal forms of coh
Page 98 and 99: Identifying attributes that are the
Page 100 and 101: Our study of the nature of the desi
Page 102: nTechnical design reviews can provi
Page 107 and 108: 905.1 Representing abstract ideasDe
Page 109 and 110: 92Describing a design solutionNor s
Page 111 and 112: 94Describing a design solutionFigur
Page 113 and 114: 96Describing a design solutionFigur
Page 115 and 116: 98Describing a design solutionnnnse
Page 117 and 118: 100Describing a design solutionDiag
Page 119 and 120: 102Describing a design solution5.3.
Page 122 and 123: chapter 6105Transferring Design Kno
Page 124 and 125: such deep and complex cognitive iss
Page 126 and 127: From the above, we can see that tra
Page 128 and 129: So that begs the question of whethe
Page 130 and 131: Finally, the rationale was intended
Page 132 and 133: 115The architecture conceptFigure 6
Page 134 and 135: 117‘Thin’ clientBrowserNetworkS
Page 136 and 137: provide actual guidance about exact
Page 138 and 139: This concept has been taken up for
Page 140 and 141: 123A unified interpretation?Figure
Page 142: (d) websites containing static page
Page 145 and 146: 1287.1 A problem of selectionSome d
Page 147 and 148: 130Some design representationsconsi
Page 149 and 150: 132Some design representationsFigur
Page 151 and 152: 134Some design representationsWhile
Page 153 and 154:
136Some design representationsrequi
Page 155 and 156:
138Some design representationsFigur
Page 157 and 158:
Page 159 and 160:
Page 161 and 162:
Page 163 and 164:
Page 165 and 166:
Page 167 and 168:
Page 169 and 170:
Page 171 and 172:
Page 173 and 174:
156Some design representationsprovi
Page 175 and 176:
1587.3 White box notationsSome desi
Page 177 and 178:
Page 179 and 180:
Page 181 and 182:
164Some design representationsFusio
Page 183 and 184:
Page 185 and 186:
168Some design representationsnnnPu
Page 187 and 188:
Page 189 and 190:
Page 191 and 192:
Page 193 and 194:
1768.1 What is a software design me
Page 195 and 196:
1782. procedural knowledge, consist
Page 197 and 198:
180The rationale for methodSystemat
Page 199 and 200:
182The rationale for methodnthe sys
Page 201 and 202:
184The rationale for methodFigure 8
Page 203 and 204:
186The rationale for methodto be aw
Page 205 and 206:
188The rationale for methodthe choi
Page 207 and 208:
190SummaryThe rationale for methodT
Page 210 and 211:
chapter 9193Design Processes and De
Page 212 and 213:
195The role of strategy in methodsF
Page 214 and 215:
197The role of strategy in methodsF
Page 216 and 217:
software design ideas and has descr
Page 218 and 219:
9.2.1 The D-Matrix formalismThe bas
Page 220 and 221:
⎛ bR ⎞⎜ fR ⎟⎜ d∅⎟⎜
Page 222 and 223:
9.3 Design by top-down decompositio
Page 224 and 225:
207Create newlist of recordsSort ex
Page 226 and 227:
programming languages, and therefor
Page 228 and 229:
At a technical level, in terms of t
Page 230 and 231:
chapter 10213Design Patterns10.1 De
Page 232 and 233:
of for loop is regarded as being th
Page 234 and 235:
orientation), within which such hig
Page 236 and 237:
219The design patternFigure 10.2Pat
Page 238 and 239:
Proxy221The GoF classify this patte
Page 240 and 241:
the proxy may offer few benefits an
Page 242 and 243:
10.2.4 The design anti-patternThink
Page 244 and 245:
5. Compare benefits and liabilities
Page 246 and 247:
Neither of these weaknesses invalid
Page 248:
part 3Design PracticesChapter 11 St
Page 251 and 252:
23411.1 The historical role of step
Page 253 and 254:
236mainSetpwise refinementconsiderf
Page 255 and 256:
238Setpwise refinementUndoubtedly o
Page 258 and 259:
chapter 12241Incremental Design12.1
Page 260 and 261:
nnnthere may be a need to demonstra
Page 262 and 263:
245PrototypingFigure 12.1Profile of
Page 264 and 265:
247An example - DSDMFigure 12.2An e
Page 266 and 267:
5. Iterative and incremental develo
Page 268 and 269:
nnCould have is the category of req
Page 270 and 271:
which can be regarded as explorator
Page 272 and 273:
process does then require a well-st
Page 274 and 275:
chapter 13257Structured Systems Ana
Page 276 and 277:
None of these points detracts signi
Page 278 and 279:
261Representation forms for SSA/SDF
Page 280 and 281:
13.3 The SSA/SD process263As alread
Page 282 and 283:
As might be gathered from their nam
Page 284 and 285:
nnnlabel carefully (following this
Page 286 and 287:
269Figure 13.8A simple example of a
Page 288 and 289:
implementation with a hierarchy of
Page 290 and 291:
⎛ b b b∅1 ∅2. . . ∅⎜ f f
Page 292 and 293:
the transformations generate a cert
Page 294 and 295:
277SSA/SD: an outline exampleFigure
Page 296 and 297:
Page 298 and 299:
Page 300 and 301:
Page 302 and 303:
Page 304 and 305:
an essential precursor, and provide
Page 306 and 307:
chapter 14289Jackson StructuredProg
Page 308 and 309:
14.2 JSP representation forms291Sin
Page 310 and 311:
14.3 The JSP process293The process
Page 312 and 313:
295The JSP processFigure 14.4Schema
Page 314 and 315:
297The JSP processFigure 14.6The fi
Page 316 and 317:
14.3.3 Step 3: List the operations
Page 318 and 319:
Step 2: Create the program Structur
Page 320 and 321:
In many ways this is a specific ins
Page 322 and 323:
305Some JSP heuristicsFigure 14.12S
Page 324 and 325:
307Figure 14.16The finance departme
Page 326 and 327:
309Figure 14.19Program inversion: r
Page 328 and 329:
311Figure 14.23Mapping records onto
Page 330:
Further reading313Jackson M. (1975)
Page 333 and 334:
31615.1 The JSD modelJackson System
Page 335 and 336:
31815.2 JSD representation formsJac
Page 337 and 338:
320Jackson System Development (JSD)
Page 339 and 340:
Page 341 and 342:
Page 343 and 344:
Page 345 and 346:
328prescriptive in the early analys
Page 347 and 348:
Page 349 and 350:
Page 351 and 352:
Page 353 and 354:
336(The latter point does require a
Page 355 and 356:
Page 358 and 359:
chapter 16341Designing with Objects
Page 360 and 361:
will promote his products as suppor
Page 362 and 363:
of a model for a solution, with fun
Page 364 and 365:
An object-oriented model adds a fra
Page 366 and 367:
exhibiting the behaviour-state mode
Page 368 and 369:
from these to identify the classes?
Page 370 and 371:
time when it is compiled and linked
Page 372 and 373:
process. Likewise, the pipe-and-fil
Page 374 and 375:
nnnabstraction, both in terms of da
Page 376 and 377:
Table 16.1Analysis and design metho
Page 378 and 379:
nnnObject-oriented analysis methods
Page 380 and 381:
does review a number of structured
Page 382 and 383:
Key observationsThe entry for this
Page 384 and 385:
One of the potential benefits from
Page 386 and 387:
369Figure 16.7Examples of white box
Page 388 and 389:
nn integration with legacy systems,
Page 390 and 391:
In order to explain the form of the
Page 392 and 393:
375Object-based designFigure 16.11
Page 394 and 395:
nnnnthe activities the designer sho
Page 396 and 397:
16.4.5 A summary of HOOD379In many
Page 398 and 399:
Class(a) Object modelClass nameattr
Page 400 and 401:
383Object-Oriented designFigure 16.
Page 402 and 403:
provide the required functionality,
Page 404 and 405:
⎛ b b b∅ ∅ ∅ ⎞1 2 . . . n
Page 406 and 407:
constrained from an early point, wh
Page 408 and 409:
Phase Inception Elaboration Constru
Page 410 and 411:
Although iteration of the workflow
Page 412 and 413:
etween these two stages of developm
Page 414 and 415:
employed.) A third such issue is th
Page 416 and 417:
provide a major challenge to the de
Page 418 and 419:
chapter 17401Component-Based Design
Page 420 and 421:
making it easy for the designer to
Page 422 and 423:
A slightly more evolved definition
Page 424 and 425:
407The component conceptFigure 17.2
Page 426 and 427:
409Designing with componentsFigure
Page 428 and 429:
411Designing with componentsFigure
Page 430 and 431:
complex aggregation rules. For soft
Page 432 and 433:
Some of the particular issues that
Page 434 and 435:
well incorporate redundant function
Page 436 and 437:
chapter 18419A Formal Approach to D
Page 438 and 439:
nnnfairly simple process parts;rela
Page 440 and 441:
unwittingly created a barrier to wi
Page 442 and 443:
A slightly different, but not wholl
Page 444 and 445:
the identifier of a set type, and t
Page 446 and 447:
18.2.3 The Z schema429The role of t
Page 448 and 449:
PassengerCountResSystResSyst′coun
Page 450 and 451:
this view is undoubtedly over-simpl
Page 452 and 453:
435Property-based strategiesFigure
Page 454 and 455:
437Property-based strategiesFigure
Page 456 and 457:
Summary439This chapter has only ski
Page 458 and 459:
chapter 19441Whither Software Desig
Page 460 and 461:
When reading the design literature
Page 462 and 463:
19.2.1 Codifying knowledge about fo
Page 464 and 465:
19.2.3 Using design toolsCASE tools
Page 466:
So, in terms of the question that i
Page 469 and 470:
452BibliographyBooch G.R. (1994) Ob
Page 471 and 472:
454BibliographyFichman R.G. and Kem
Page 473 and 474:
456BibliographyJones J.C. (1970). D
Page 475 and 476:
458BibliographyShapiro S. (1997). S
Page 478 and 479:
461Index 152, 1624+1 view 967 plus
Page 480 and 481:
design (continued )process 90(for)
Page 482 and 483:
measurement (of design properties)
Page 484 and 485:
state vector separation (in JSD) 33
show all

Software Design 2e - DIM

Create successful ePaper yourself

Delete template?

Save as template?