Information in figures and tables is denoted by f and t.
AAL. See Abstract Action Language (AAL)
Abstract Action Language (AAL)
abstraction and, 475–476
Action Data Flow Diagram and, 373, 476–478
ATM example for, 484–488
garage door opener example for, 480–484
3GLs vs., 475–476
methods and, 52
Abstract data type (ADT), 168, 192, 195–197, 333, 335–336
Abstraction
abstract action languages and, 475–476
of aggregates, 335–341
anthropomorphization and, 206–207, 343–344
application partitioning and, 116–117, 117f
of associations, 236
basic, 332
of behavior, 203–204
characteristics and, 37–38
choosing correct, 341–351
collaboration and, 396
conditionality and, 252
delegation and, 330–331
domain experts and, 163
emphasis and, 38
encapsulation and, 39
levels of, 35, 36f, 116–117, 117f, 350–351, 396–397, 397f
Liskov Substitution Principle and, 326
logical indivisibility and, 396
of methods, 197–198
Model-Based Development and, 35
modification of reality by, 37–38
in object-oriented paradigm, 35, 36f
of object responsibilities, 399–400
of people’s actions, 343–344
polymorphism and, 59
as proactive, 162
problem space, 31–32, 37–39, 108, 162
of problem space entities, 163
representation and, 161–167
of roles, 163
in state machine design, 438
subclasses and, 309
subject matter and, 308, 345–349
subsystem implementation and, 110
of subsystems, 128
transitions and, 422
Access constraint, associations and, 238, 272
Accessor(s)
knowledge, 204
as synchronous service, 371
Action(s)
as dynamic, 427
entity and, 427
external behavior dependencies and, 428
in finite state machines, 380
responsibilities combined in, 440
self-contained, 429
timing of execution, 381–382
Action Data Flow Diagram (ADFD), 373, 476–478
Action languages, 373–374
Addresses, memory, 163
ADFD. See Action Data Flow Diagram (ADFD)
Ad-hoc polymorphism, 59, 60, 80
ADT. See Abstract data type (ADT)
Aggregates, abstraction of, 335–341
Air traffic control example, of finite state machines, 410–411
Allocation, requirements, 130, 147
Alphabet
definition of, 378
in finite state machines, 378–379
knowledge and, 379
ALU. See Arithmetic Logic Unit (ALU)
Analysis
domain
maintainability and, 69–71
object-oriented analysis and, 70
traditional view of, 69–70
domain analysis and, 70
finite state machines and, 377
static model and, 154–155
translation and, 46
problem, 32
of requirements, 70–71
semantic, of subsystems, 146–147
in structured development, 6, 32
Anthropomorphizing, 206–207, 333–334, 343–344, 409
AOP. See Aspect-Oriented Programming (AOP)
API. See Application programming interfaces (API)
Application partitioning, 72. See also Subsystem(s)
basic concepts of, 107–118
bridge definitions and, 227
client/service relationships and, 108–109, 114–116, 115f
cohesion and, 108
feedback to, 231
implementation hiding and, 108
importance of, 105–107
invariants and, 108
legacy replacement example of, 147–150
levels of abstraction and, 116–117, 117f
Liskov Substitution Principle and, 326
pet care center example of, 130–145
problem space abstraction and, 108
static nature of, 158
subject matter and, 109–113
subsystems and, 106, 127–128, 227
synchronous services and, 369–370
Application programming interfaces (API), in structured development, 6
Architecture, 13–14
Arithmetic Logic Unit (ALU)
Basic Assembly Language and, 19
early instructions to, 18
“Artwork,” 90
Aspect-Oriented Programming (AOP), 238
Association(s)
abstraction of, 236
access constraint and, 238, 272
ATM as example for identification of, 273–277
as binary, 236
cardinality in notation for, 239, 239f
classes
associations appropriate for, 267
problem space and, 264–265
reification and, 267–268, 268f
value of, 265
classes and, 234
commonality of superset and, 261, 272
in composition, 319
conditionality in
abstraction and, 252
access and, 254–255
in association identification, 271
definition of, 250
elimination of, 252
encapsulation and, 254
implementation and, 252
problem space and, 252
problems with, 250–251
superclasses and, 254
constraints
association identification and, 270–271
attributes and, 262
instances and, 261–262
loops and, 262
order and, 262
contracts and, 272
critical, 269
definition of, 234
dependency and, 273
directions of, 244
discriminator
referential attribute and, 291
subclasses and, 300–301
of events with transitions, 424, 449–450
examples in identification of, 273–278
explicit relations and, 272–273
explicit selections and, 273
identification of, 269–273
implementation and, 235
instantiation and, 234, 235f, 238
locality of scope and, 261
logical connections and, 242–250
loops
constraints and, 262
referential integrity and, 292–295, 293f
multi-class, 236–237
multiple, collaborations and, 242–243, 243f
multiplicity
in association identification, 271
notation for, 239, 239f, 241, 241f
problem space and, 256
notation for, 233, 239–242, 239f
obscure, 269
obvious, 269
participation and, 260–261
path
definition of, 237
logical connections and, 242
pet care center as example for identification of, 277–278
physical connections and, 272
problem space and, 236
questions for identification of, 270
responsibilities and identification of, 270
role in notation for, 240, 240f
selection and, 260–261
selection consistency and, 261
separation of concerns and, 236
specification and, 273
subject matter and, 269
supplementation of, 257–260
ternary, 236–237
as underutilized, 233
use cases in identification of, 269
Asymmetry, of association roles, 245
Asynchronicity, 42–43
Asynchronous behavior communication, 363–369
Asynchronous implementation, 364
Asynchronous processing, 364
ATM
as Abstract Action Language example, 484–488
as association identification example, 273–277
as class identification example, 173–181
as invariant modeling example, 84–89
as responsibility identification example, 209–222
as state machine design example, 451–473
Attribute(s)
in Abstract Action Languages, 480
abstract data types and, 192, 195–197
abstraction-to-scalar and, 193
accessors and, 205
association constraints and, 262
contracts and, 196
data storage vs., 193
definition of, 168
dependent
knowledge integrity and, 283–285, 283f, 284f
as dependent on key, 24
identifier, 24
introduction of term, 23
key and, 24
knowledge obligations and, 192
knowledge vs., 191–192
as members of simple domains, 24
non-key, 24
normalization of, knowledge integrity and, 285–289, 287f, 288f
notation, 191–193
object characteristics and, 50–52
operations and, 197–207
problem space entities and, 192
referential
association discriminator and, 291
definition of, 290
identity and, 290–292, 291f, 292f
responsibility and, 50
state and, 194–195
static model and, 192–193
strong typing and, 197
value vs., 52
Automata, finite state, 378–390
Automated home kitchen, as finite state machine example, 409–410
BAL. See Basic Assembly Language (BAL)
Balcer, Marc, 154
Bank ATM software
as class identification example, 173–181
as invariant modeling example, 84–89
as responsibility identification example, 209–222
Basic Assembly Language (BAL)
Arithmetic Logic Unit and, 19
in history of software development, 4
instruction mnemonics in, 53
introduction of, 18–19
Behavior(s). See also Responsibility(ies)
abstraction of, 203–204
anthropomorphization and, 206–207
asynchronous communication, 363–369
checking steps, 219
cohesion in identification of, 202–203
collaboration between, 361
complementarity of, 202
context and, 157
coupling and, 16
by data, 16
finite state machines and, 391–395
identifying, 201–206
identifying errors with, 221–222
importance of, 358–361
knowledge attributes and, 344–345
knowledge integrity and, 281
knowledge vs., 156–158, 391–395
Liskov Substitution Principle and, 325
logical cohesion and, 202
navigation to, 244
perspective and asynchronous, 366
polymorphism and, 157
preconditions and, 388
by reference, 16
responsibilities, 198
sequencing and, 362
specificity of, 203
state machine design and, 438–439
states and, 428–429
subclasses and, 314–315
in synchronous services, 369–370
testability of, 221
time slicing and, 368–369
transitions and constraints on, 360–361
Behavioral state machine, 382
Blitz
object, 169–172
for responsibility identification, 208–209
for subsystem identification, 146
Block structuring, procedural, 20
Booch notation, 29
Boundaries, subsystem, 121
Branch, in Turing Machine, 17
Breadth-first processing
in object-oriented paradigm, 44–52
Bridge(s)
defining, 147
descriptions, 129
C++, 29
Cardinality, in association notation, 239, 239f
Categorization
subclasses and, 307–312, 310f, 311f
Characteristics
abstraction and, 37–38
attributes and, 50–52
coalescence of, 38
de-emphasization of, 37
elimination of, 37
generalization of, 37–38
object, 49–52
Class(es)
association
associations appropriate for, 267
problem space and, 264–265
reification and, 267–268, 268f
value of, 265
associations and, 234
ATM example in identification of, 173–181
attributes, 168 (See also Attribute(s))
in class diagram, 155
definition of, 49
delegation and, 165–167
diagram, 155–156, 186–189, 187f, 189f
embedding of, in other classes, 322
entities and, 51f
examples for identification of, 172–186
identification of, 169–172
instances and, 51f
Liskov Substitution Principle and, 323–328, 328f
logical indivisibility and, 164–165
method, 168
notation, 167–168
objects and, 51f
operation, 168
pet care center example in identification of, 181–186
responsibilities of, 169–172
subclasses
abstraction and, 309
behaviors and, 314–315
categorization and, 307–312, 310f, 311f
composition with, 317–323, 318f, 320f, 323f, 324f
definition of, 300
disadvantages of, 328–329
discriminator and, 300–301
generalization and, 306–307
inclusion polymorphism and, 312–315, 313f, 314f
instantiation of, 303
member characteristics, 303
multidirectional, 303, 304f, 317–323, 318f, 320f, 323f, 324f
notation, 300–303
in problem space, 311–312
properties and, 300
reasons for, 310–311
rules, 300–303
semantic connection with superclasses, 308–309
simplicity in, importance of, 307
specialization and, 304–307
in superclasses, 303
superclasses as, 302
superclasses
conditionality and, 254
definition of, 300
Harel view of, 385
polymorphic events addressed to, 426
problem space and, 308
semantic connection with subclasses, 308–309
subclasses as, 302
subclasses in, 303
Client
definition of, 119
in object-oriented context, 203
as state, 204
Client/service relationships
application partitioning and, 108–109, 114–116, 115f
subsystems and, 147
COBOL, introduction of, 19
Codd’s Relational Data Model, 22–25
Code
hacker, 4
size, invariant modeling and, 83–84
Coff, E. F., 22
Cohesion
application partitioning and, 108
in behavior identification, 202–203
bleeding of, across subsystems, 86, 226
composition and, 321–322
design and, 40
lack of, in software development history, 14
logical, behaviors and, 202
in object-oriented paradigm, 40
separation of concerns and, 34
subject matter and, 121
of subsystems, 136
Collaboration(s)
abstraction and, 396
asynchronous model for, 363–369
asynchronous services and, 372
between behaviors, 361
definition of, 237
diagrams, 186–189, 187f, 189f, 208, 213f, 440, 446–447
handshaking and, 441
instantiation vs., 235–236
multiple associations and, 242–243, 243f
referential integrity and, 279
state machine design and, 439
transitions and, 360–361
Commonality of superset, associations and, 261, 272
Communication models
asynchronous, 42–43
in object-oriented paradigm, 42–44
Compiler, introduction of, 19
Complex Number library class, 38
Composition, 317–323, 318f, 320f, 323f, 324f
Computing space
definition of, 68
as deterministic, 22
as disciplined, 22
hardware computational models as basis of, 22
invariants in, 78
as mathematically based, 68–69
problem space vs., 63–69
responsibilities in, vs. problem space, 340–341
Concerns, separation of
cohesion and, 34
decoupling and, 35
isolation and, 34
in object-oriented paradigm, 34–35
subject matter and, 34
Concurrent implementation, 364
Concurrent processing, 281
Conditionality
abstraction and, 252
access and, 254–255
in association identification, 271
in association notation, 240, 240f
definition of, 250
elimination of, 252
encapsulation and, 254
implementation and, 252
problem space and, 252
problems with, 250–251
relationships and, 251
superclasses and, 254
Connections, logical, 242–250
Consistency
concurrent processing and, 281
knowledge integrity and, 281
of selection, associations and, 261
Constraints
association identification and, 270–271
association loops and, 262
in association notation, 240, 240f
attributes and, 262
finite state machines and, 395–396
instances and, 261–262
order and, 262
Context
behavior and, 157
dynamic, 157
event, 425
functional decomposition and, 10
knowledge integrity and, 280
knowledge value and, 157
Liskov Substitution Principle and, 326
methods and, 198
problem, 448
receiver, in event naming, 434
for requirements, 129
sender, in event naming, 435
state and, 416
static models and, 154
transition, 425
Contract(s)
abstract data types and, 196
associations and, 272
design by, 203–204, 280–281, 387–390
programming by
functional decomposition and, 8
in structured development, 6
Control, flow of, 389, 401, 406, 417, 418
Coupling, 14–17
behavior by reference and, 16
behavior by value and, 16
data by reference and, 16
data by value and, 16
dependency and, 15
interfaces and, 118
logical, 15
message identifier and, 15
physical, 15
Critical associations, 269
Cromwell, Andrew, 415
Customer
definition of, 67–68
environment, 70
input for subsystem identification, 145–146
invariant modeling and, 79
solution, 70
space
abstraction and, 162
notation for, 22
Daisy-chaining, of events, 446–447, 449
Data
coupling and, 16
invariant modeling and, 80–81
knowledge vs., 334
by reference, 16
in relational vs. object-oriented paradigms, 296–297
storage, attributes vs., 193
by value, 16
Data Flow Diagram (DFD), 476–477. See also Action Data Flow Diagram(ADFD)
DbC. See Design by contract (DbC)
Decomposition, functional
appeal of, 7–8
context and, 10
dependency and, 10–11
functional isolation in, 8
maintainability and, 10
power of, 7
programming by contract in, 8
in structured development, 7–11
unit testing and, 11
Decoupling
message paradigm and, 49
separation of concerns and, 35
of subsystems, 124
Delegation, 165–167
abstraction and, 330–331
as alternative to generalization, 329–331, 331f
definition of, 329
Dependency
associations and, 273
coupling and, 15
functional decomposition and, 10–11
management, 15
Dependent attributes
knowledge integrity and, 283–285, 283f, 284f
Depreciation, as example of invariant modeling, 93–98
Design
cohesion and, 40
history of, 4–5
instances and, 231
object-oriented
definition of, 33
elaboration and, 45
levels of abstraction and, 36f
reuse, 66
role-based, 421
of state machines, 437–450
in structured development, 6
subsystem, 110–111
Design by contract (DbC), 203–204, 280–281, 387–390
Deterministic, computing space as, 22
Development, structured
application programming interfaces in, 6
characteristics of, 5–6
design in, 6
functional decomposition in, 7–11
functional isolation in, 6
graphical representation in, 5
maintainability and, 6
problems in, 8
programming by contract in, 6
reliability and, 5
top-down development in, 6
DFD. See Data Flow Diagram (DFD)
Diagram(s)
action data flow, 373, 476–478
class, 155–156, 186–189, 187f, 189f
collaboration, 186–187, 208, 213f, 440, 446–447
data flow, 476–477
sequence, 214f
state transition, 358, 383, 383f
Dijkstra, E., 12
Disciplined, computing space as, 22
Discriminator
in association notation, 239, 239f
referential attribute and, 291
subclasses and, 300–301
Disjoint generalization, 303, 315–317, 316f
Domain, simple, attributes as members of, 24
Domain analysis
maintainability and, 69–71
object-oriented analysis and, 70
traditional view of, 69–70
Domain expert, definition of, 163
Domain Modeling, 70–71
Drum memory, 4
Duplication, of subsystems, elimination of, 146
Dynamic context, 157
Dynamic models, 73–75
definition of, 355
learning curve with, 376
Elaboration
breadth-first processing and, 45–47
stages of, 45
translation vs., 45–47
Embedding, of classes in classes, 322
Encapsulation
abstraction and, 39
conditionality and, 254
in object-oriented paradigm, 39
polymorphism and, 59
synchronous services and, 199
Engine, transformation, 45, 66, 238, 279–280
Entity(ies). See also Object(s)
actions and, 427
classes and, 51f
complexity of, 165
components of, 165–166
defining, example of, 177–179
definition of, 38
gathering of candidate, 169
example, 174
instances and, 51f
intangible, 163
objects and, 51f
objects vs., 164
problem space
abstraction of, 163
attributes and, 192
definition of, 163
problem space abstraction and, 37
roles as, 163
scrubbing, example of, 177–179
Entry action, 374
Environment
customer, 70
distributed, 121
Event(s)
assigning, 425–426
association of, with transitions, 424, 449–450
context, 425
daisy-chaining of, 446–447, 449
definition of, 380
in finite state machines, 380, 381
generators, 205–206
ignoring, 424
messages, 381
as messages, 423
naming conventions for, 433–435
polymorphic, 426
receiver context in naming of, 434
self-directed, 381, 400–403, 400f, 402f
sender context in naming of, 435
serialization of, 432–433
superstates and, 385
transitions and, 423–424
transition vs., 381
Executable UML: How to Build Class Models (Starr), 154, 233, 320
Executable UML (Mellor & Balcer), 154
Execution model, 430–433
Expert, domain, definition of, 163
Explicit relations, associations and, 272–273
Falkland, Lord, 77
Finite State Automata (FSA), 378–390
Finite state machines (FSMs), 27–28, 28f
action execution timing in, 381–382
action in, 380
air traffic control example of, 410–411
alphabet in, 378–379
basic automata, 378–390
behavior and, 391–395
collaborations and, 361
constraints and, 395–396
event queue in, 380–381
flow of control and, 401
garage door opener example of, 407–408, 409f
identifying, 390–407
kitchen example of, 409–410
knowledge and, 391–395
Mealy, 382
Moore, 382
notation for, 383–386
object life cycles and, 362–373
object-oriented analysis and, 377
object-oriented practice and, 360t
postconditions in, 387–388
reasons for use of, 357–358
rock example of, 410–413
self-directed events and, 400–403, 400f, 402f
sequence management and, 395–407
state transition table and, 386, 386t
time slicing and, 368–369
Flawed requirements, 131
“Floating” transition, 384, 384f
Flow(s)
of control, 389, 401, 406, 417, 418
FORTRAN, introduction of, 19
FSA. See Finite State Automata (FSA)
FSM. See Finite state machine (FSM)
Functional decomposition
appeal of, 7–8
context and, 10
dependency and, 10–11
functional isolation in, 8
maintainability and, 10
power of, 7
programming by contract in, 8
in structured development, 7–11
unit testing and, 11
Functional isolation
in functional decomposition, 8
in structured development, 6
Garage door opener example
of Abstract Action Languages, 480–484
of finite state machine, 407–408, 409f
Generalization
alternatives to, 328–332
of characteristics, 37–38
in class diagram, 155
definition of, 299
delegation as alternative to, 329–331, 331f
inclusion polymorphism and, 60
inheritance and, 56
joint, 303
parametric polymorphism as alternative to, 331–332
in problem space, 309
problem-space abstraction and, 56
properties and, 304–305
in set theory, 54–56, 54f, 55f
specialization and, 304–307, 305f, 306f
subclasses and, 306–307
Generators, event, 205–206
“Go To Statement Considered Harmful” (Dijkstra), 12
Graphical C++, 29
Graphical representation, in structured development, 5
Graphs, 21–22
Hacker, history of term, 4
Hacker code, 4
Hacker Era, 4
Handshaking, 361, 403–407, 441–442
Hardware computational models, 18, 22
Hardware interface, as example of invariant modeling, 89–93
Hardware register, knowledge and, 393
Harris, Sydney J., 29
Hierarchy, association conditionality and, 252–254, 253f
HiPO charts, 21
History
of software development, 3–5
of structured development, 5–6
Identification
of association roles, 245
of associations, 269–273
of behaviors, 201–206
of candidate objects, 163
of classes, 169–186
of finite state machines, 390–407
of invariants, 70
of responsibilities, 209–222, 222–231
of subsystems, 119–122, 145–147
Identifier attributes, 24
Identity, referential attributes and, 290–292, 291f, 292f
Implementation
associations and, 235
asynchronous, 364
concurrent, 364
conditionality and, 252
hiding, application partitioning and, 108
polymorphism vs., 57
synchronous, 364
Inclusion polymorphism, 59, 60, 312–315, 313f, 314f, 323
Indicator, 392–393
Indivisibility, logical
abstraction and, 396
classes and, 164–165
levels of, 40–41
object and, 41
in object-oriented paradigm, 40–41
object responsibility and, 41
power of, 41
process and, 41
subsystem and, 40
Industrial Revolution, 3
Inheritance
generalization and, 56
generalization vs., 57
multiple, 317–323, 318f, 320f, 323f, 324f
polymorphism vs., 57
as rule, 56
Instance(s)
association constraints and, 261–262
classes and, 51f
definition of, 50
design patterns and, 231
entities and, 51f
objects and, 51f
object vs., 50
Instantiation
associations and, 234, 235–236, 235f, 238
collaboration vs., 235–236
of subclasses, 303
Instantiators
attributes and, 205
as synchronous service, 371
Instruction mnemonics, in BAL, 53
Intangible entities, 163
Integrity
assumptions in, 279
knowledge
attribute normalization and, 285–289, 287f, 288f
behaviors and, 281
consistency and, 281
context and, 280
dependent attributes and, 283–285, 283f, 284f
scope of, 279
snapshots and, 282
timeliness and, 280–281
transformation engine and, 279–280
practices in, 279
referential
association loops and, 292–295, 293f
collaborations and, 279
identity and, 290–292, 291f, 292f
participants and, 289
referential attributes and, 290–292, 291f, 292f
selection and, 289
transformation engine and, 279–280
transformation and, 280
Interfaces
application partitioning and, 108, 118
coupling and, 118
large-scale reuse and, 118
Invariant(s)
application partitioning and, 108
in computing space, 78
definition of, 78–79
in design by contract, 387
identification of, 70
Liskov Substitution Principle and, 326
modeling, 71
ATM example of, 84–89
customer and, 79
data side in, 80–81
definition of, 78–81
depreciation example of, 93–98
examples of, 84–103
hardware interface example of, 89–93
importance of, 77
invariant side in, 78–80
maintainability and, 82
reduced code size and, 83–84
remote POS entry example of, 99–103
requirements and, 80
rewards of, 81–84
from problem space, extraction of, 342–343
in subsystem descriptions, 128
Isolation
functional
in functional decomposition, 8
in structured development, 6
separation of concerns and, 34
Iteration, in Turing Machine, 18
Johnson, Samuel, 333
Joint generalization, 303
Kettering, Charles F., 3
Key
definition of, 24
dependence on, 24
Kitchen, automated, as finite state machine example, 409–410
Knowledge
abstraction, subsystem abstraction and, 333
accessors, 204
aggregate, abstraction of, 335–341
alphabet and, 379
anthropomorphization and, 333–334
attributes vs., 191–192
behavior and, 344–345
behavior vs., 156–158, 391–395
classification of, 333–334
data vs., 334
finite state machines and, 391–395
hardware register and, 393
integrity
attribute normalization and, 285–289, 287f, 288f
behaviors and, 281
consistency and, 281
context and, 280
dependent attributes and, 283–285, 283f, 284f
scope of, 279
snapshots and, 282
timeliness and, 280–281
transformation engine and, 279–280
as intrinsic, 334
level of abstraction and, 350–351
Liskov Substitution Principle and, 327–328
nature of, 334–335
navigation to, 244
obligations, attributes and, 192
requirements and, 346
responsibilities, 167–168
as static, 157
subject matter and, 345–349
synchronous access of, 430
synchronous services and, 371
underlying entity and, 344–345
Lamb, Charles, 233
Languages, action, 373–374
Large-scale reuse, 82, 105, 118, 124
Legacy replacement, as example of application partitioning, 147–150
Lichtenberg, G. C., 475
Life cycles
finite state automata, 379f
Liskov, Barbara, 324
Liskov Substitution Principle (LSP), 323–328, 328f
Locality of scope, associations and, 261
Logical cohesion, behaviors and, 202
Logical connections, 242–250
Logical coupling, 15
Logical indivisibility
abstraction and, 396
classes and, 164–165
levels of, 40–41
object and, 41
in object-oriented paradigm, 40–41
object responsibility and, 41
power of, 41
process and, 41
subsystem and, 40
Lombardi, Vince, 30
Loops, association
constraints and, 262
referential integrity and, 292–295, 293f
LSP. See Liskov Substitution Principle (LSP)
MacPherson, James, 333
Maintainability
application partitioning and, 82, 106
delegation and, 166
domain analysis and, 69–71
functional decomposition and, 10
history of term, 4
importance of, 30
invariant modeling and, 82
object-oriented paradigm and, 29, 30–31
structured development in, 6
subclass simplicity and, 307
Mapping, 425
Marvel, Andrew, 415
Mealy finite state machine, 382
Mealy model, 374–376
Mellor, Steve, 77, 123, 124, 154
Memory
addresses, 163
drum, 4
Merchant of Venice, The (Shakespeare), 53
Message identifier, coupling and, 15
Message paradigm, 47–49
Methods
abstraction of, 197–198
collaborations and, 198
context and, 198
preconditions and, 388
Midsummer Night’s Dream, A (Shakespeare), 105
Mnemonics, in BAL, 53
Model(s)
communication
asynchronous, 42–43
in object-oriented paradigm, 42–44
domain, 70–71
dynamic, 73–75
definition of, 355
learning curve with, 376
execution, 430–433
invariant, 71
ATM example of, 84–89
code size and, 83–84
customer and, 79
data side in, 80–81
definition of, 78–81
depreciation example of, 93–98
examples of, 84–103
hardware interface example of, 89–93
importance of, 77
invariant side in, 78–80
maintainability and, 82
remote POS entry example of, 99–103
requirements and, 80
rewards of, 81–84
Mealy, 374–376
static
abstraction of behavior in, 158
attributes in, 192–193
class diagram and, 155–156
context and, 154
definition of, 154
knowledge vs. behavior in, 156–158
maintainability and, 72–73, 72t
object-oriented analysis and, 154–155
state in, 194
subject matter and, 153
Model-Based Development (MBD)
abstraction and, 35
as object-oriented, 1
road map, 63–75
Moore finite state machine, 382
Multi-class associations, 236–237
Multidirectional subclassing, 303, 304f, 317–323, 318f, 320f, 323f, 324f
Multiple associations, collaborations and, 242–243, 243f
Multiple inheritance, 317–323, 318f, 320f, 323f, 324f
Multiplicity
in association identification, 271
in association notation, 239, 239f, 241, 241f
participation and, 260–261
problem space and, 256
selection and, 260–261
Naming conventions, for states and events, 433–435
Navigation
to behavior, 244
to knowledge, 244
in relational paradigm, 296
through association paths, 237, 237f
NF. See Normal form (NF)
Normal form (NF), 22–25
Normalization, attribute, knowledge integrity and, 285–289, 287f, 288f
Notation
associations, 233, 239–242, 239f
attribute, 191–193
Booch, 29
class, 167–168
for customer space, 22
finite state machine, 383–386
responsibility, 199–201
subclass, 300–303
Object(s). See also Entity(ies)
abstraction of responsibilities, 399–400
anthropomorphization and, 206–207
blitz, 169–172
characteristics, 49–52
classes and, 51f
entities and, 51f
entities vs., 164
identifying candidate, 163
example, 174t–177t
instances and, 51f
instance vs., 50
logical indivisibility and, 41
methods and, 197–207
operations and, 197–207
responsibilities and, 165–166
subsystem implementation with, 110
Object Constraint Language (OCL), 262
Object Design: Roles, Responsibilities, and Collaborations (Wirfs-Brock), 421
Object-oriented analysis (OOA), 32–33, 36f
domain analysis and, 70
finite state machines and, 377
static model and, 154–155
translation and, 46
Object-oriented design (OOD)
definition of, 33
elaboration and, 45
levels of abstraction and, 36f
Object-oriented (OO) paradigm
basic philosophy of, 30–44
breath-first processing in, 44–52
client in, 203
cohesion in, 40
communication models in, 42–44
encapsulation in, 39
hardware computational model vs., 18
levels of abstraction in, 35, 36f
logical indivisibility in, 40–41
maintainability and, 29, 30–31
problem space abstraction and, 31–32, 37–39
relational vs., 295–297
separation of concerns in, 34–35
service in, 203
subject matter in, 33–34
Object-oriented programming (OOP)
definition of, 33
elaboration and, 45
Object responsibility, logical indivisibility and, 41
Obligations, knowledge, attributes and, 192
Obvious associations, 269
OCL. See Object Constraint Language (OCL)
OO. See Object-oriented (OO)
OOA. See Object-oriented analysis (OOA)
OOD. See Object-oriented design (OOD)
Operation(s)
attributes and, 197–207
implementation of, 200
Overload polymorphism, 59
Parametric polymorphism, 59–60, 61, 331–332, 342–343
Partitioning, application, 72
basic concepts of, 107–118
bridge definitions and, 227
client/service relationships and, 108–109, 114–116, 115f
cohesion and, 108
feedback to, 231
implementation hiding and, 108
importance of, 105–107
invariants and, 108
legacy replacement example of, 147–150
levels of abstract and, 116–117, 117f
Liskov Substitution Principle and, 326
pet care center example of, 130–145
problem space abstraction and, 108
static nature of, 158
subject matter and, 109–113
subsystems and, 106, 127–128, 227
synchronous services and, 369–370
Path, association
definition of, 237
logical connections and, 242
Patterns, design, 78, 231, 312
Peer-to-peer collaboration
in object-oriented paradigm, 44–52
Pellor, Clara, 78
Pet care center
as application partitioning example, 130–145
as association identification example, 277–278
as class identification example, 181–186
as responsibility identification example, 222–231
Petri Nets, 358
Physical connections, associations and, 272
Physical coupling, 15
PLA. See Product Line Architectures (PLA)
Platform, 66
Point-of-sale (POS) entry, remote, as example of invariant modeling, 99–103
Polymorphic events, 426
Polymorphism
abstraction and, 59
behaviors and, 157
encapsulation and, 59
implementation vs., 57
inclusion, 59, 60, 312–315, 313f, 314f, 323
inherent, 59
inheritance vs., 57
Liskov Substitution Principle and, 326–327
overload, 59
overview of, 58
parametric, 59–60, 61, 331–332, 342–343
subclasses and, 312–315, 313f, 314f
Postcondition, 387–388
Preliminary scrub, for subsystem identification, 146
Problem analysis, 32
Problem context, 448
Problem space
abstraction of, 31–32, 37–39, 108, 162
application partitioning and, 108
association classes and, 264–265
associations and, 236
computing space vs., 63–69
conditionality and, 252
definition of, 67
generalization in, 309
invariants from, extracting, 342–343
logical connections and, 243
multiplicity and, 256
object-oriented analysis and, 32
reification and, 268
responsibilities in, vs. computing space, 340–341
subclasses in, 311–312
subject matter as unique, 156
Problem space entity
abstraction of, 163
attributes and, 192
definition of, 163
Procedural block structuring, 20
Procedural message passing, introduction of concept, 19
Procedures, introduction of concept, 19
Process
in Action Data Flow Diagram, 477
logical indivisibility and, 41
Product Line Architectures (PLA), 123
Protocol state machine, 382
RDM. See Relational Data Model (RDM)
Redundancy, functional decomposition and, 8–10, 9f
Referential attributes
association discriminator and, 291
definition of, 290
identity and, 290–292, 291f, 292f
Referential integrity
association loops and, 292–295, 293f
attributes and, 290–292, 291f, 292f
collaborations and, 279
identity and, 290–292, 291f, 292f
participants and, 289
selection and, 289
transformation engine and, 279–280
Registers, hardware, 18
Reification
association classes and, 267–268, 268f
definition of, 267
problem space and, 268
Relational Data Model (RDM), 22–25
Relational paradigm
navigation in, 296
object-oriented vs., 295–297
Relationship(s)
association identification and, 272–273
conditionality and, 250–251
definition of, 234
descriptions, 129
Reliability, structured development and, 5
Remote POS entry, as example of invariant modeling, 99–103
Representation, abstract, 161–167
Requirements
analysis of, 70–71
context for, 129
delegation and, 166–167
elicitation of, 70–71
flawed, 131
invariant modeling and, 80
knowledge and, 346
object-oriented analysis and, 32
problem analysis and, 32
roles and, 249–250
specification of, 70–71
subject matter and, 158
subject matter example, 173–174
subsystem descriptions and, 129
volatility of, 31
Responsibility(ies). See also Attribute(s)
abstract data type and, 168
abstraction of object, 399–400
anthropomorphization and, 207
association identification and, 270
asynchronicity and, 42–43
ATM example for identification of, 209–222
attributes and, 50
behavior, 198
in class diagram, 155
of classes, 169–172
in class notation, 167
combined in action, 440
definition of, 50
delegation and, 166
fleshing out of, 132
as intrinsic, 334
knowledge, 167–168
level of abstraction and, 350–351
logical indivisibility and, 41
modified object blitz for identification of, 208–209
notation, 199–201
object life cycle and, 362
pet care center example for identification of, 222–231
preconditions and, 388
in problem space vs. computing space, 340–341
splitting, 165–166
state machine design and, 439
states and, 428–429
substituting knowledge for behavior, 342–343
subsystem, 128
testability of, 202
Reuse
design, 66
large-scale, 82, 105, 118, 124
Rock example, of finite state machine, 410–413
Role(s)
in association notation, 240, 240f
associations and, 242, 244–246, 245f
asymmetry in, 245
as entities, 163
as explanatory, 246
information added by, 245
naming of, 246
precision vs. brevity in, 246
requirements and, 249–250
in state naming, 434
states and, 421
subject matter and, 245
Role-based design, 421
Sampling, 282
Scalar, abstraction to, 193, 228
Scope
locality of, associations and, 261
stack-based, 20
Scrub, preliminary, for subsystem identification, 146
SD. See Structured development (SD)
Self-containment
of actions, 429
Self-directed events, 381, 400–403, 400f, 402f
Semantic analysis, of subsystems, 146–147
Separation of concerns
associations and, 236
cohesion and, 34
decoupling and, 35
isolation and, 34
in object-oriented paradigm, 34–35
subject matter and, 34
Sequence(s)
behaviors and, 362
finite state machines and, 357, 361
level of abstraction and, 396–397, 397f
managing, 395–407
rules, 362–363
in Turing Machine, 17
Sequence diagrams, 186–189, 187f, 189f, 214f
Serialization, of events, 432–433
Service(s)
definition of, 119
event generators, 205–206
instantiators, 205
knowledge accessors, 204
in object-oriented context, 203
in subsystem descriptions, 128
synchronous, 199, 204–206, 369–373
tests, 204
transforms, 205
Service oriented architecture (SOA), 116
Set theory
generalization in, 54–56, 54f, 55f
overview of, 21–28
Shlaer-Mellor methodology, 77, 123, 154
Situation, condition vs., 422–423
Size, code, invariant modeling and, 83–84
Snapshots, knowledge integrity and, 282
SOA. See Service oriented architecture (SOA)
Software design, history of, 4–5
Solution, customer, 70
Space
computing
definition of, 68
as deterministic, 22
as disciplined, 22
hardware computational models as basis of, 22
invariants in, 78
as mathematically based, 68–69
problem space vs., 63–69
responsibilities in, vs. problem space, 340–341
customer
abstraction and, 162
notation for, 22
problem
abstraction of, 31–32, 37–39, 108, 162
application partitioning and, 108
association classes and, 264–265
associations and, 236
computing vs., 63–69
conditionality and, 252
definition of, 67
entity, 163
generalization in, 309
invariants from, extracting, 342–343
logical connections and, 243
multiplicity and, 256
object-oriented analysis and, 32
reification and, 268
responsibilities in, vs. computing
space, 340–341
subclasses in, 311–312
subject matter as unique, 156
Specialization
definition of, 299
generalization and, 304–307, 305f, 306f
generalization vs., 56
subclasses and, 304–307
Specification
associations and, 273
of requirements, 70–71
Stack-based scope, 20
State(s)
adding, 441
attributes and, 194–195
behaviors and, 428–429
of being, 420–421
client as, 204
as condition of being, 415
context and, 416
definition of, 359
dynamic view of, 194
in finite state machines, 378
mapping of, 417f
naming conventions for, 433–435
preconditions and naming of, 434
responsibilities and, 428–429
roles and, 421
roles in naming of, 434
static view of, 194
superstates, 384–385
variables, 194
Statechart, 383
State machines. See also Finite state machines (FSMs)
abstraction in design of, 438
adding transitions to, 447–449
behavioral, 382
behaviors and design of, 438–439
collaborations and design of, 439
designing, 437–450
examples for design of, 450–473
handshaking and design of, 441–442
protocol, 382
responsibilities and design of, 439
State Transition Diagrams (STD), 358, 383, 383f
State Transition Tables (STT), 358, 386, 386t
Static model
abstraction of behavior in, 158
attributes in, 192–193
class diagram and, 155–156
context and, 154
definition of, 154
knowledge vs. behavior in, 156–158
maintainability and, 72–73, 72t
object-oriented analysis and, 154–155
state in, 194
subject matter and, 153
STD. See State Transition Diagrams (STD)
Storage, data, attributes vs., 193
Strong typing, attributes and, 197
Structure, 13–14
Structured development (SD)
application programming interfaces in, 6
characteristics of, 5–6
design in, 6
functional decomposition in, 7–11
functional isolation in, 6
graphical representation in, 5
history of, 5–6
maintainability and, 6
problems in, 8
programming by contract in, 6
reliability and, 5
top-down development in, 6
STT. See State Transition Tables (STT)
Subclass(es)
abstraction and, 309
behaviors and, 314–315
categorization and, 307–312, 310f, 311f
composition with, 317–323, 318f, 320f, 323f, 324f
definition of, 300
disadvantages of, 328–329
discriminator and, 300–301
generalization and, 306–307
inclusion polymorphism and, 312–315, 313f, 314f
instantiation of, 303
Liskov Substitution Principle and, 323–328, 328f
member characteristics, 303
multidirectional, 303, 304f, 317–323, 318f, 320f, 323f, 324f
notation, 300–303
in problem space, 311–312
properties and, 300
reasons for, 310–311
rules, 300–303
semantic connection with superclasses, 308–309
simplicity in, importance of, 307
specialization and, 304–307
as superclass, 302
in superclasses, 303
Subject matter(s)
application partitioning and, 109–113
association identification and, 269
cohesion and, 121
definition example, 173
definition of, 33
knowledge and, 345–349
level of abstraction and, 350–351
Liskov Substitution Principle and, 326
in object-oriented paradigm, 33–34
requirements and, 158
requirements example, 173–174
roles and, 245
separation of concerns and, 34
static model and, 153
subsystems and, 121
trivial, 132
as unique problem space, 156
Substitution principle, Liskov, 323–328, 328f
Subsystem(s). See also Application partitioning
abstraction and, 110
application partitioning and, 106, 127–128, 227
bleeding of cohesion across, 86, 226
blitz technique for identification of, 146
boundaries of, 121
bridge model for, 125–127, 126f
characteristics of, 109–110
client/service relationships and, 147
cohesion, 136
common, 131
customer input for, 145–146
decoupling of, 124
describing, 127–130
design of, 110–111
distributed environment for, 121
eliminating duplication of, 146
event queues and, 431
example of, 130–145
identification of, 119–122, 145–147
input interface for, 125–126, 126f
interfaces in, 118
invariants in description of, 128
“is” vs. “how” descriptions of, 128
large-scale reuse and, 124
level of abstraction in description of, 128
logical indivisibility and, 40
message problem with, 123–125
mission in descriptions of, 128
as objects, 123
objects in implementation of, 110
output interface for, 125–126, 126f
pet care center example for, 130–145
preliminary scrub technique for, 146
relationship descriptions, 129
responsibilities, 128
reuse of, 121
semantic analysis of, 146–147
services in description of, 128
as skeleton, 153
subject matter and, 121
text tags for, 127–128
Superclasses
conditionality and, 254
definition of, 300
Harel view of, 385
Liskov Substitution Principle and, 323–328, 328f
polymorphic events addressed to, 426
problem space and, 308
semantic connection with subclasses, 308–309
subclasses as, 302
subclasses in, 303
Superset commonality, associations and, 261, 272
Superstates, 384–385
Synchronous implementation, 364
Synchronous knowledge access, 430
Synchronous services, 199, 204–206, 369–373
Synchronous wormhole, 124–125
Tags, text, for subsystems, 127–128
Taxonomy, zoological, 8
Technical innovation, in history of object-oriented programming, 17–28
Ternary associations, 236–237
Tester, as synchronous service, 371
Testing, unit, functional decomposition and, 11
Tests, as synchronous service, 204
Text tags, for subsystems, 127–128
Timeliness, knowledge integrity and, 280–281
Time slicing, 368–369
Top-down development, structured development, 6
Transformation
definition of, 69
integrity and, 280
reification and, 267–268, 268f
Transformer, as synchronous service, 371
Transforms, 205
Transition(s)
abstraction and, 422
adding, in state machine design, 447–449
association of, with events, 424, 449–450
behavior constraints and, 360–361
collaborations and, 360–361
context, 425
definition of, 422
events and, 423–424
event vs., 381
in finite state automata, 380
in finite state machines, 378
as sequencing constraint, 421–422
situations vs. conditions in, 422–423
in state machines, 359
in State Transition Diagram, 383
in state transition table, 386, 386t
Translation
advantages of, 46
in breadth-first processing, 45–47
definition of, 69
disadvantages of, 47
elaboration vs., 45–47
Turing, Alan, 17
Turing Machine, 17–18
Types, introduction of concept, 19–20
UML. See Universal Modeling Language (UML)
Unit testing, functional decomposition and, 11
Universal Modeling Language (UML), 21
Use cases
association identification and, 269
Model-Based Development and, 71
USER/CRUD processing, 25
Value(s)
attribute vs., 52
transforms and, 205
Volatility, of requirements, 31
Wirfs-Brock, Rebecca, 21, 163, 421
Wirth, Nicolas, 25
Wormhole, synchronous, 124–125
Zoological taxonomy, 8
3.147.13.192