677

Index

Page numbers followed by an f or t indicate figures and tables.

AAbstract class, 101, 193, 427Abstraction analysis, 137Abstractions

in architecture functionality, 351encapsulations and, 51examples of, 47–50in hierarchy of complex systems, 4–5key

defined, 112, 138identifying, 139–41, 284tnaming, 140–41refining, 139–40in traffic management system, 395–96

levels of, in micro process, 274–76, 275f, 281–83

meaning of, 44–47in programming language evolution, 31by programming style, 43quality of, measuring, 112–14role of, 23–24, 200software flexibility and, 10static and dynamic properties of, 46–47viewers perspective in, 44–45in weather monitoring system, 467

Access, package, 161–63

Action abstraction, 45Activity diagram

actions in, 186black-box, 345fdecision and merge nodes in, 187–88fork and join nodes in, 188, 190object flows in, 190partitions in, 188, 189ffor satellite navigation system, 341f, 346fstarting and stopping points in, 186–87for traffic management system, 386f, 387fwhite-box, 356f, 367f

Actors, in use case diagram, 176Ad hoc approach, 125Affirmation class, 424–25, 426fAggregation

choice of, 196of classes, 109–11hierarchy in, 63–64of objects, 91–92, 92fas physical containment, 110–11vs. multiple inheritance, 110–11

Agile development process, 252–53, 255tAlgorithmic decomposition, 19

vs. object-oriented, 20–23Alphabet class, 428–29Alternatives interaction operator, 212

Booch.book Page 677 Wednesday, March 28, 2007 10:21 AM

678 INDEX

Analysis categories, 21–22Analysis/design model, 277–78

in vacation tracking system, 508–19Analysis process. See also Micro process

abstraction levels in, 273–76classes and objects in, 112element identification in, 284t–285tin iterative development, 270object-oriented. See Object-oriented analysis

Analyst role, 311Animals, complex structure of, 5–6Apache Struts framework, 518, 528–29Application engineers, 310Architect, project, 309–10Architectural design, 281, 285tArchitecture analysis, 281Architecture description, 277Architecture documentation, 278–80, 349Architecture of system, 16

defined, 248in design process, 248–49in satellite navigation system

activity definition, 348–50decomposing, 364–70deployment of, 361–64developing, 348nonfunctional requirements, 358–61validating, 350–57

time-frame-based processing in, 473–74in traffic management system

defining, 389–91system functionality and, 385–87

in vacation tracking system, 517–18in weather monitoring system, 473–74, 475fWeb-centric, 494

Arithmetic/logic unit (ALU), 4Artifact

defined, 171notation for, 171–72reuse of, 314–16

Artificial intelligence, 40. See also Cryptanalysis system

Assembly connectors, 166, 217Assertion class, 425Associations

among classes, 97–98among elements, 293–94classes and notes, 205–6directionality, 199

end names and qualifiers, 200–201one-to-many, 98fvisibility, 199

Assumption mechanism, 443–44Astronomy, 6

BBackward-chaining, 419Bandwidth, 535Behavior

in choice of class, 115in element collaboration, 291fundamental, 291of objects, 81–82

Behavior analysisdescription of, 132–33process of, 290–91

Behavior characterization, 11–12Behavior diagrams, 150f, 151Behavioral prototype, 260Biological classification, 123–24Black-box activity diagram, 345f, 365Blackboard framework

architecture of, 417, 418–20assumption mechanism in, 443–44integration of, 440–44knowledge sources in, 418–20, 444–45

Blackboard objectsclasses in, 421–23designing, 427–31topmost, 440–43

Block diagram, 389f, 392Botany, 5Boyle, Robert, 124Business function, 133Business logic, 533–34

CC++, 546–51C with Classes, 546CAD/CAM system, 77Canonical form of complex system, 15–17, 17fCapability-based architectures, 39Central processing unit (CPU), 4Chaos, prediction and, 11n

Booch.book Page 678 Wednesday, March 28, 2007 10:21 AM

INDEX 679

Chemical classification, 124Chunking, 23CK metrics, 320Class diagram

association classes and notes, 205–6association end names and qualifiers in,

200–201constraints in, 201–4, 203felement visibility in, 198–200, 199fnotation in, 192–93relationships in, 194–97, 195fin schedule planning, 401ftemplate classes in, 197–98in traffic management system, 398, 399f

Class library tool, 323Class lifecycle, 96Class promotion, 140Class structure, 15–17, 17fClass(es). See also specific classes

abstract, 101, 193, 427affirmation, 424–25alphabet, 428–29assertion, 425association among, 97–98behavior in choice of, 115in blackboard framework, 421–23collection, 477concrete, 101defined, 92–94dependencies among, 111, 423–26design quality of, 112–14identifying, 126–38implementing, 94–95inheritance among, 98–102interface of, 94–95, 476interplay of, with objects, 111–12leaf, 101relationships among, 96–97, 204sources of, 131–32template, 197–98for time and date, 452–54vs. type, 64n

Classical analysis, 131–32Classical categorization, 126–27Classification

approaches toapplication of, 130–31classical categorization, 126–27

conceptual clustering, 127–29prototype theory, 130

defined, 121difficulty of, 122–24importance of, 121–22incremental and iterative nature of, 124–26

Client state management, 499CMP beans, 519, 520Cohesion, 113, 354Coincidental abstraction, 45Collection class, 477Commonality, in complex structures, 5Communication diagram, 238–43

in vacation tracking system, 514–15, 516fCommunication gap, 9Completeness, 114Completion transition, 221Complex systems

attributes of, 12–15behavior characterization in, 11–12canonical form of, 15–17, 17fdesigning, 24–28hierarchical nature of, 4–5structure of, 4–7

Complexityabstraction of, 23–24, 44arbitrary, 7external, 9human limitations and, 17–18

Component analysis, 281Component design, 281–82Component diagram

defined, 163interfaces in, 166–68, 167finternal structure of, 169–71, 170fnotation for, 164–65, 164frealizations in, 168, 169ffor satellite navigation system, 362ffor traffic management system, 408f

Component lead, 310Composite design, 21Composite state, 224, 225fComposite state notation, 226Composite structure diagram, 215–18

for cryptanalysis system, 441fComposition, 110, 125Computer languages. See Programming languagesConceptual clustering, 127–29

Booch.book Page 679 Wednesday, March 28, 2007 10:21 AM

680 INDEX

Conceptual model, 152Concerns, separation of

in complex system, 13–14encapsulation in, 52in temperature measurement abstraction, 49

Concrete classes, 101Concurrency

examples of, 68–69heavyweight, vs. lightweight, 67meaning of, 66–68in state machine diagram, 225–30

Concurrent synchronization, 91Configuration management, 312–13Connectors, in composite structure diagram, 217Constraint

association, 203defined, 201placement of, 202t

Construction phasein cryptanalysis, 427description of, 266in satellite navigation system, 371in traffic management system, 396–97in vacation tracking system, 506in weather monitoring system, 474

Constructor operation, 82Context diagram, for satellite navigation system, 337fContract model of programming, 46Control constructs, 210–12Control flow notation, 226Control objects, 76Control system. See Traffic management systemController object, 89

in knowledge source activation, 438–39in vacation tracking system, 528–29

Coupling, 113CRC cards, 135–36Cryptanalysis system

blackboard framework inarchitecture of, 417, 418–20assumption mechanism in, 443–44integration of, 440–44knowledge sources in, 418–20, 444–45

blackboard objectsclasses in, 421–23designing, 427–31

construction phase in, 427controller design in, 438–39, 440fdefined, 414

dependencies in, 423–26, 426fknowledge sources in

in blackboard framework, 418–20, 444–45designing, 431–34generalizing, 435–37implementing, 445

post-transition phase in, 446–47problem-solving process in, 416–18requirements for, 414–15

changes in, 448substitution cipher, 414–15system enhancements, 446–47

DDarwin, Charles, 123Data abstraction, 35Data acquisition system, 449. See also Weather

monitoring systemData-driven design, 22Data member, 95Decision nodes, 187–88Decomposable hierarchic systems, 13Decomposition

algorithmic, 19vs. object-oriented, 20–23

object-oriented, 20role of, 19–23of system architecture, 364–70in traffic management system, 409

Defect density, 317Defect-discovery rates, 266Delegation, 98Delegation connectors, 171, 217Demeter, Law of, 116–17Dependency class, 111, 423–26, 426fDependency relationships, 424–25

in package diagrams, 158–59Deployment diagrams

artifact notation in, 171–72connections in, 173–75, 174fnode notation in, 172–73in traffic management system, 394fin vacation tracking system, 494–96, 495f

Derivation, 125Descartes, René, 124Descriptor-based architectures, 39Design method categories, 21–22

Booch.book Page 680 Wednesday, March 28, 2007 10:21 AM

INDEX 681

Design methodologies, 26–27Design metrics, 318Design model, in vacation tracking system,

508–19, 521f, 522fDesign process. See also Micro process

abstraction levels in, 275–76classes and objects in, 112of complex systems, 24–28element identification in, 284t–285tin iterative development, 270purpose of, 25–26

Destruction events, 208Destructor operation, 82Development legacy, 320–21Development process. See also Object-oriented

developmentagile, 252–53, 255t

phases in, 267–68architectural vision in, 248–49choice of, 254in design methodology, 27iterative

advantages of, 251analysis and design in, 270duration for, 269focus shifts in, 268f

macroconstruction phase in, 266disciplines in, 259, 261elaboration phase in, 264–66inception phase, 262–64iterations in, 268–69milestones and phases in, 261–68purpose of, 257release planning in, 270–73transition phase in, 267

microabstraction levels in, 274–76, 275f, 280–83activities in, 276–77element collaborations in, 288–92element identification in, 283–88element relationships in, 292–95macro process and, 273fproducts of, 277–78semantic detail in, 296–300

plan-driven, 253, 255tprototyping in, 260software architecture documentation, 278–80

Development reviews, 306–7

Development team roles, 309–12Device, 172Diagram notation

activity, 185–91behavior, 150f, 151class, 192–206communication, 238–43component, 163–71composite structure, 215–18deployment, 171–75, 174finteraction, 150finteraction overview, 213–15object, 235–38package, 156–63sequence, 206–12state machine, 218–31structure, 149–50, 150ftiming, 231–35use case, 175–85, 178f

Diagrams. See also specific typesconnectivity among, 154context, 337fpractical use of, 151–52state transition, 440f

Discrete systems, behavior characterization in, 11–12

Display mechanism, in weather monitoring system, 482–83

Do activity, 222Documentation, 320–22Documenter, 311Domain analysis, 133–34Domain expert, 134Domain-specific issues, 324–25Drawing mechanism, 143Duration timer, 223Dynamic typing, 66

EEarly binding, 66Elaboration phase

of cryptanalysis system, 421description of, 264–66of satellite navigation system, 347–48of traffic management system, 385of vacation tracking system, 494of weather monitoring system, 463

Booch.book Page 681 Wednesday, March 28, 2007 10:21 AM

682 INDEX

Elementsassociations among, 293–94collaborations among, 288–92

milestones in, 291–92identification of, 283–88, 284t–285t

milestones in, 288pattern scavenging, 291protocols of, 297relationships among, 292–95semantics of, 296–300visibility of, 157–58

Encapsulationin architecture functionality, 351examples of, 52–54meaning of, 50–52separation of concerns in, 52

Energy management system, 390Engineering, 25English description, in object-oriented analysis,

136Entities

finders in filtering, 528persistent, 519–20in vacation tracking system, 519–23

Entity abstraction, 45Entity bean, 521

primary key generation for, 525Entry activity, 222Environmental control system

component notation in, 164fdeployment diagram for, 174finternal structure of, 170fspecification of two interfaces for, 167f

Exclude relationships, 180–84Execution environment, 172Execution specification, 209Exit activity, 222Extend relationships, 181–83

FFaçade object, 523, 524fFactorization, 125Federal Bureau of Investigation, 303Field, 95Final node, 187Final state, 219–20Finder methods, 528

Fine-grained operations, 115Finite state machine, 485–86Firing the transition, 220Fork node, 188, 190Fork vortex, 228Forward-chaining, 419Found message, 2084+1 architecture view model, 279–80Frames

in interaction overview diagrams, 213in weather monitoring system, 474–79in web applications, 535

Frameworks, 143Function points, 133Functional semantics, of operation, 115Functionality allocation, 353Fuzzy set theory, 128

GGlobal Positioning System (GPS), 334, 335Glossary, 338Grainsize conflict, 140Guard conditions, 243Guarded synchronization, 91

HHardware

post-transition changes to, 372–73in weather monitoring system, 451, 452f

Heavyweight concurrency, 67Hierarchical structure

aggregation, 63–64in architecture functionality, 352class and object in, 15–17in complex system, 4–5, 12inheritance in

multiple, 61–63repeated, 62single, 58–61

of knowledge source class, 434fmeaning of, 58–64role of, 24in weather monitoring sensor class, 460f

HTML browsers, 518HTTP state management mechanism, 499

Booch.book Page 682 Wednesday, March 28, 2007 10:21 AM

INDEX 683

Human intelligence, 40Hydroponics gardening system

communication diagram for, 240fcomposite structure diagram for, 216fpackage import in, 162fpackage notation for, 156f, 160ftransitions in, 221

Hyperlinks, 534

IIdentity

defined, 85of object, 85–87, 86f

Idioms, 142–43Implementation model

choosing, 117–18of class, 94–95mechanisms of, 112in vacation tracking system, 501

Import package, 161–63Inception phase

of cryptanalysis system, 414description of, 263–64of satellite navigation system, 334of traffic management system, 376in vacation tracking system, 490

Include relationships, 180–84Incremental development approach, 250–52

integration events in, 313–14Information display, 404–5Informational capacity

abstraction in transcending, 23of human, 18

Inheritanceelement semantics and, 299metrics of, 319multiple

among classes, 106–9name collisions in, 107–8in object model, 61–63vs. aggregation, 110–11

polymorphism and, 102–3repeated, 62, 109single

among classes, 100–102defined, 100in object model, 58–61

Initial node, 186Initial state, 219–20Instance variable, 95Integrated development environment (IDE), 323Integration events, 313–14Integration manager role, 311Intelligent system. See CryptanalysisInteraction operator loop, 210–12Interaction overview diagram, 213–15

for traffic management system, 388fInteraction use, 210Interface

of class, 94–95in vacation tracking system, 529–34in weather monitoring system, 476f, 483–87

Interface connectors, 166, 217Intermediate form stability, 14Invariance, 46Iteration clause, 242–43Iteration release, 272Iterative development

advantages of, 250–52duration in, 269, 270–71focus shifts in, 268fintegration events in, 313–14in macro process, 268–69

Iterator operation, 82

JJava, 551–56Java scripting, 535Java Server Pages (JSP), 517, 532J2EE technologies, 518Join node, 188, 190Join vertex, 228JSF, 518

KKey abstractions

defined, 112, 138identifying, 139–41, 284tnaming, 140–41refining, 139–40in traffic management system, 395–96

Booch.book Page 683 Wednesday, March 28, 2007 10:21 AM

684 INDEX

Knowledge sourcesanalysis of, 420–21in blackboard framework, 418–20, 444–45dependencies among, 423–26designing, 431–34generalizing, 435–37implementing, 445pattern-matching, 433

LLate binding, 66

polymorphism and, 103Lavoisier, Antoine, 124Law of Demeter, 116–17Leaf classes, 101Legacy system, 325Lifeline, 206, 232Lightweight concurrency, 67Links

in communication diagrams, 239defined, 88between objects, 88–91, 89f

Linnaeus, Carolus, 123Logical model, 152

for satellite navigation system, 341fin satellite navigation system, 368fin vacation tracking system, 496–98, 497f

Lorenz design metrics, 319

MMachines, objects as, 84–85Macro process

construction phase in, 266disciplines in, 259, 261elaboration phase in, 264–66inception phase, 262–64iterations in, 268–69milestones and phases in, 261–68purpose of, 257release planning in, 270–73transition phase in, 267

Maintenance of software, 10, 258–59Management, project, 304–8Many-to-many relationships, 98Matter, structure of, 6

Mechanismsdefined, 112, 138examples of, 143–44identifying, 140–44in object structure, 24as patterns, 142–43in relationship choice, 117

Member function, 46Mendeleyev, Dmitry, 124Merge nodes, 187–88Message dictionary, 105Message passing

between objects, 88–89in traffic management system, 397–400, 400f

Messagesin communication diagram, 239defined, 81found, 208guard conditions in, 243notation for, 206–7

Methodselection of, 104–6as term, 46vs. methodology, 21

Method-dispatch algorithm, 105–6Metrics, object-oriented, 317–20Milestones

in construction phase, 266in elaboration phase, 265–66in inception phase, 264in micro process

element collaboration, 291–92element identification, 288element relationships, 295element semantics, 299–300

in transition phase, 267Minsky, Marvin, 331Mission use case, 339–43Mixin classes, 61, 109Model building

importance of, 26in micro process, 277Unified Modeling Language and, 148–49

Model-view-controller paradigm, 143Modeling language. See Unified Modeling

LanguageModifier operation, 82Modularity

in architecture functionality, 352

Booch.book Page 684 Wednesday, March 28, 2007 10:21 AM

INDEX 685

defined, 56examples of, 57–58guidelines for, 56meaning of, 54–57size limitations in, 57

Monomorphism, 66Multiple inheritance

among classes, 106–9name collisions in, 107–8in object model, 61–63vs. aggregation, 110–11

Multiplicity among classes, 98Multivalue set theory, 128MVC pattern, 143

NName collisions, 107–8Navigation. See Satellite Navigation SystemNearly decomposable hierarchic systems, 13Nested state, 224, 225fNode

defined, 172notation for, 172–73

Notation. See also Diagram notation; Unified Modeling Language

in design methodology, 27purpose of, 147–48

Noun-verb analysis, 508

OObject-based programming languages, 32

topology of, 35–36, 36f, 37fvs. object-oriented, 41

Object diagram, 235–38in vacation tracking system, 514–15, 515f

Object flows, 190Object Management Group (OMG), 148Object model

application of, 71–72benefits of, 71–72elements of, 43–44evolution of, 29–37, 39foundations of, 37–43as principle, 18in programming language evolution, 538

Object nodes, 191fObject-oriented analysis

approaches tobehavioral, 132–33classical, 131–32CRC cards, 135–36domain analysis, 133–34structured analysis, 136–38use case analysis, 135

defined, 42–43Object-oriented decomposition, 20

vs. algorithmic, 20–23Object-oriented design

defined, 38, 42models of, 27in object-oriented decomposition, 42

Object-oriented development. See also Development process

adoption of, 325–26benefits of, 326–27documentation in, 320–22domain specific issues in, 324–25failures in, 303management of

development reviews, 306–8risk management, 304–5task planning, 305–6

metrics in, 317–20quality assurance and in, 316–17release management in, 312–14reuse in, 314–16risks of, 327–29staffing in

development team roles, 309–12resource allocation, 308–9

tools in, 322–24Object-oriented metrics, 317–20Object-oriented operating systems, 39Object-oriented programming (OOP)

defined, 41languages in support of, 41–42

Object structure, 15–17, 17fObjects

aggregation of, 91–92, 92fbehavior of, 81–82in communication diagrams, 239control, 76defined, 76–78design quality of, 112–14

Booch.book Page 685 Wednesday, March 28, 2007 10:21 AM

686 INDEX

Objects (continued)façade, 523, 524fidentity of, 85–87, 126–38interplay of, with classes, 111–12links between, 88–91as machines, 84–85operation of, 82relationships among, 88–92roles and responsibilities of, 83–84sources of, 131–32state of, 78–81

One-to-one relationships, 98One-to-many relationships, 98Operations

choosing, 114–16defined, 81functional semantics of, 115of objects, 82as term, 46time and space semantics of, 115–16

Organizational relationships, 7Orthogonal hierarchies, 15, 22Overloading, 103Ownership, in aggregation, 63–64

PPackage diagrams

benefits of, 155–56dependency relationships in, 158–59element visibility in, 157–58import and access, 161–63notation for, 156–57, 156ffor satellite navigation system, 341fin use case organization, 160f

Package export, 161–63Package import, 161–63Package interface, 94Packaging, in relationship choice, 118Parameter formatting, 497Parameterized classes, 197–98Partitions, 188, 189fPattern commonality, 14Pattern-matching knowledge source, 433Pattern scavenging, 291Patterns

mechanisms as, 142–43MVC, 143

Persistence, 69–71

Persistent data storage, 519Personal computers, 4–5Petroski, Henry, 145Physical model, 152Plan-driven process, 253, 255tPlants, complex structure of, 5–6Polymorphism

ad hoc, 103defined, 102–3late binding and, 103method selection and, 104–6in type theory, 66

Ports, in component notation, 164–65Post data formatting, 497Post-transition phase

in cryptanalysis system, 446–47hardware changes in, 372–73in satellite navigation system, 371–73in traffic management system, 411–12in vacation tracking system, 534–35in weather monitoring system, 487–88

Postconditions, 46in weather monitoring system, 472–73

Preconditions, 46Preservation of software, 10Primary keys, 525Primitive components, 113Primitiveness, 114Principle of least astonishment, 44Principle of least commitment, 44Private interface, 94Private visibility, 157Problem domain, complexity of, 8–10Process metrics, 317Process view, in Web applications, 498–501Product metrics, 318Products

of construction phase, 266of elaboration stage, 264of element collaboration definition, 288–89of element identification, 284of element relationship definition, 293of inception phase, 264of micro process, 277–78of semantic detailing, 296–97of transition phase, 267

Programming-in-the-large, 34Programming languages

C++, 546–51decomposition in, 21

Booch.book Page 686 Wednesday, March 28, 2007 10:21 AM

INDEX 687

evolution of, 30–32genealogy of, 539fidioms in, 142–43Java, 551–56object-based, 32

topology of, 35–36, 36f, 37fvs. object-oriented, 41

object-oriented, 32adoption of, 326criteria for, 41evolution of, 537–39, 539fpersistence support in, 70topology of, 35–36, 36f, 37fvs. object-based, 41

popularity index for, 538, 540tSmalltalk, 541–42topology of

defined, 32first- and early second-generation, 32–33,

33flate second- and early third-generation,

33–34, 34flate third-generation, 34–35, 35fobject-based and object-oriented, 35–36,

36f, 37fProgramming styles

contract model of, 46main kinds of, 43

Project architect, 309–10Project management, 304–8Project manager role, 311Project metrics, 317Project staffing, 308–12Property

in classical categorization, 127defined, 79of object, 78–79value of, 79

Protected interface, 94Protocol

defined, 46of object, 83semantics of, 297

Prototype theory, 130Prototypes, 260

in weather monitoring system, 459Proxy object, 89Public interface, 94Public visibility, 157

QQualifier, 238Quality assurance, 311, 316–17

RRailroads. See Traffic management systemReal-time, 324–25Realizations, component, 168, 169fReflexive association, 194Relationships

among classes, 96–97among elements, 292–95among object, 88–92choosing, 116–17include and exclude, 180–84independent and direct, 513fone-to-one, 98one-to-many, 98many-to-many, 98organizational, 7

Release planningin macro process, 270–73in object-oriented development, 312–14for traffic management system, 406–7for weather monitoring system, 479–80

Repeated inheritance, 62, 109Representation, in implementation choice, 117–18Requirement changes, 9–10Requirements analysis, 135Resource allocation, 308–9Responsibilities

in behavior analysis, 133of object, 83

Reuse, 314–16Reuse engineer role, 311, 323Risk management, 304–5Role

defined, 83in interaction overview diagram, 218

SSatellite Navigation System (SNS)

architecture foractivity definition, 348–50

Booch.book Page 687 Wednesday, March 28, 2007 10:21 AM

688 INDEX

Satellite Navigation System (SNS) (continued)decomposing, 364–70deployment of, 361–64developing, 348functionality allocation, 353interface specifications, 358–61logical, 341fnonfunctional requirements, 358–61validating, 350–57

component diagram for, 362fcontext definition of, 336–39, 337flaunch time allocations for, 360fpackage diagram for, 341fpost-transition phase, 371–73requirements for, 334–36use cases for

mission, 339–43system, 343–47

Scenario, 281nin weather monitoring system, 462–63

Schedule planning, 401–4SCRUM lifecycle, 268Segment use case, 357t–358tSelector operation, 82Semantic dependencies, 97–98Semantics

of associations, 294detailing, 297–99of elements, 296–300

abstraction level in, 299inheritance and, 299

functional, 115time and space, 115–16in Unified Modeling Language, 154–55in weather monitoring system, 471f

Sensor data acquisition, 405–6Sensor mechanism, in weather monitoring system,

480–82Separation of concerns

in complex system, 13–14encapsulation in, 52in temperature measurement abstraction, 49

Sequence block strategy, 525–26Sequence diagram

control constructs in, 210–12destruction events in, 208execution specification in, 209interaction use in, 210in knowledge source evaluation, 436f

lifelines and messages in, 206–7purpose of, 206scripts in, 209, 210fin traffic management system, 392f

Sequence expression, 239–41Sequential sychronization, 91Server object, 89Service Data Objects (SDO), 520, 523–24, 525fSet theory, 128Short-term memory capacity, 18Simple name, 163Simple state, 219–20Simula, 39, 538Single inheritance

among classes, 100–102defined, 100in object model, 58–61

Smalltalkdevelopment of, 541–42feature index of, 543tmethod dispatch in, 105MVC paradigm in, 143purpose of, 542

SNS. See Satellite Navigation SystemSocial institutions, structure of, 7Software architecture documentation, 278–80Software complexity

defining, 7–8development process management in, 10discrete system behavior characterization in,

11–12problem domain in, 8–10

Software development, 250–52. See also Development process

Software evolution and maintenance, 10, 258–59Software flexibility, 10–11Software maintenance, 10Software quality assurance, 316–17Species diversity, 124Staffing, 308–12State

activity in, 222client, management of, 499composite, 224, 225fdefined, 219nested, 224, 225fnotations for, 220–21of object, 78–81

State machine, finite, 485–86

Booch.book Page 688 Wednesday, March 28, 2007 10:21 AM

INDEX 689

State machine diagramactivities in, 222concurrency in, 225–30control in, 225–30initial, final, and simple states in, 219–20purpose of, 218–19submachine state in, 230transition control in, 222–24transitions and events in, 220–22in vacation tracking system, 510fin weather monitoring system, 471f

State transition diagram, 440fStatic binding, 66Static typing, 66Steady state, 149Strong typing, 66Structure diagrams, 149–50, 150fStructured analysis, 136–38Structured design, 21–22Style sheets, 535Subclass

defined, 100purpose of, 101–2

Submachine state, 230Subprograms, in composite design, 21Substitution cipher, 414–15Subsystems

defined, 170for traffic management system, 408–10

Success scenario, 341–42Sufficiency, 113Superclass

collection, 477defined, 100in weather monitoring system, 457–58

Supplementary specification, 338Synchronization

in communication diagram, 242between objects, 91

Synchronous message, 208Syntax, of Unified Modeling Language, 154–55System administrator, 311System architecture. See also Satellite Navigation

Systemfor traffic management system, 407–8

System functions, in behavior analysis, 133System use cases, 343–47Systems engineering, 334

TTask planning, 305–6Team meetings, 305Team roles, 309–12Technology adoption, 325–26Telemetry data, 99Temperature measurement

abstraction in, 47–50in weather monitoring system, 454–55

Template classes, 197–98Testing, 314Thomas Aquinas, 126Time and space semantics, of operation, 115–16Time-frame-based processing, 473–74, 474fTiming diagrams, 231–35TIOBE Programming Community Index, 538, 540tTools

in design methodology, 27kinds of, 322–23organizational implications of, 323–24role of, 153visual. See Diagrams and diagram notation

Toolsmith, 311, 323–34Top-down structured design, 21Topology of programming languages

defined, 32first- and early second-generation, 32–33, 33flate second- and early third-generation, 33–34,

34flate third-generation, 34–35, 35fobject-based and object-oriented, 35–36, 36f,

37fTraffic management system

architecture forblock diagram in, 389f, 392defining, 389–91deployment diagram in, 394fhardware and software allocations, 391–94sequence diagram in, 392fsystem functionality and, 385–87

class diagram in, 398, 399fconstruction phase in, 396–97decomposition in, 408–10elaboration phase of, 385inception phase of, 376information display in, 404–5key abstractions in, 395–96

Booch.book Page 689 Wednesday, March 28, 2007 10:21 AM

690 INDEX

Traffic management system (continued)message passing in, 397–400post-transition phase in, 411–12release management in, 406–7requirements for, 377–79schedule planning in, 401–4sensor data acquisition in, 405–6software design for, 407–8subsystem specification fin, 408–10use cases determination, 378–84

Transition phase, 267Transitions

completion, 221controlling, 222–24defined, 220

Type, vs. class, 64nType consistency, 66Typing

benefits of, 65–66meaning of, 64–66static and dynamic, 65–66

UUnified Modeling Language (UML)

background of, 148classification of, 149–51, 150fdefined, 148diagrams in. See Diagramsevolution of, 154models in, 148–49, 152–53purpose of, 147–48resources on, 155subset use in, 151–52syntax and semantics of, 154–55

Unqualified name, 163URL redirection, 499U.S. Global Positioning System (GPS), 334, 335Use case model, 135

actors in, 176, 493generalization in, 185include and exclude relationships in, 180–84noun-verb analysis in, 508purpose of, 175–76for satellite navigation system, 346f

mission, 339–43segment, 357t–358tsystem, 343–47

specifying details in, 177–80success scenario and, 341–42for traffic management system, 378–84, 380ffor vacation tracking system, 492–93, 501–6for weather monitoring system, 464–73Web-centric systems and, 492–93

User experience model, 506–8, 507fUser interface mechanism

in vacation tracking system, 529–34in weather monitoring system, 483–87

UX model, 506, 530

VVacation tracking system. See also Web

applicationsanalysis and design models in, 508–19communication diagram in, 516fconstruction phase in, 506controllers in, 528–29deployment view in, 494–96, 495felaboration phase in, 494entities in, 519–23finder methods in, 528implementation view of, 501logical view in, 496–98, 497fobject diagram in, 514–15, 515fpost-transition phase in, 534–35primary key generation in, 525–27process view in, 498–501requirements of, 490–92rule types in, 511service data objects in, 523–24, 525fstate machine diagram in, 510ftechnologies in, 517use case model in, 492–93user experience model in, 506–8

Version control, 312–13Virtual case file system, 303Virtual machine abstraction, 45Visibility

in class diagram, 198–200, 199fin class interface, 95of elements, 157–58between objects, 89–91in package diagram, 157–58in relationship choice, 117

von Neumann architectures, 39

Booch.book Page 690 Wednesday, March 28, 2007 10:21 AM

INDEX 691

WWeak typing, 66Weather monitoring system

architectural framework of, 473–74, 475fconstruction phase in, 474display mechanism in, 482–83elaboration phase of, 463frame mechanism in, 474–79hardware platform for, 451, 452fpost-transition phase in, 487–88release planning for, 479–80requirements for, 450scenarios of use in, 462–63sensor class hierarchy in, 460fsensor mechanism in, 480–82superclass in, 457–58temperature sensors in, 454–55time and date class in, 452–54timer class in, 461–62, 462fuse cases in, 464–73user interface mechanism in, 470f, 483–87

Web applications, 489–90. See also Vacation tracking system

architecture of, 494business logic in, 533–34changes in, 535client state management in, 499logical components in, 496processes in, 498server-side software in, 535user interface in, 529–34

Web page design, 529–34White-box activity diagram, 356f, 365, 367f

XXP lifecycle, 267–68

ZZooming in and out, 225

Booch.book Page 691 Wednesday, March 28, 2007 10:21 AM