Index

Information in figures and tables is denoted by f and t.

A

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

syntax, 478, 478t –480t, 480

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

behavior and, 158, 198

characteristics and, 37–38

choosing correct, 341–351

collaboration and, 396

conditionality and, 252

definition of, 37, 161–162

delegation and, 330–331

domain experts and, 163

emphasis and, 38

encapsulation and, 39

invariants and, 79, 231

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

to scalar, 193, 228

sequencing and, 396–397, 397f

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)

definition of, 379, 427–428

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

object-oriented, 32–33, 36f

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

example of, 130–145, 147–150

feedback to, 231

implementation hiding and, 108

importance of, 105–107

interfaces and, 108, 118

invariants and, 108

legacy replacement example of, 147–150

levels of abstraction and, 116–117, 117f

Liskov Substitution Principle and, 326

maintainability and, 82, 106

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

collaborations and, 270, 272

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

hierarchy and, 252–254, 253f

implementation and, 252

notation for, 240, 240f

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

notation for, 240, 240f

order and, 262

contracts and, 272

critical, 269

definition of, 234

dependency and, 273

directions of, 244

discriminator

in notation for, 239, 239f

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

importance of, 233, 270

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

navigation and, 235, 236

notation for, 233, 239–242, 239f

obscure, 269

obvious, 269

participation and, 260–261

path

definition of, 237

logical connections and, 242

navigation through, 237, 237f

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

roles and, 242, 244–246, 245f

selection and, 260–261

selection consistency and, 261

separation of concerns and, 236

specification and, 273

subject matter and, 269

supplementation of, 257–260

symmetric, 245, 245f

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

notation for, 283, 283f

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

methods and, 52, 197–207

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

B

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 and, 158, 198

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

self-containment of, 202, 221

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

model, 125–127, 126f

subsystems and, 122–127, 227

C

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

cohesion and, 307, 328–329

composition with, 317–323, 318f, 320f, 323f, 324f

definition of, 300

disadvantages of, 328–329

discriminator and, 300–301

disjoint, 315–317, 316f

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

problem space and, 308, 309

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

subclasses and, 307, 328–329

subject matter and, 121

of subsystems, 136

Collaboration(s)

abstraction and, 396

associations and, 270, 272

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

hierarchy and, 252–254, 253f

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

problem space, 263–264, 263f

sequencing, 397f, 398

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

“Create” event, 384, 384f

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

D

Daisy-chaining, of events, 446–447, 449

Data

coupling and, 16

flows, 25–27, 26f

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

redundancy and, 8–10, 9f

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

knowledge and, 334–335, 335f

problem space and, 166, 330

Dependency

associations and, 273

coupling and, 15

functional decomposition and, 10–11

management, 15

Dependent attributes

knowledge integrity and, 283–285, 283f, 284f

notation for, 283, 283f

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

patterns, 78, 231, 312

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

analysis in, 6, 32

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, 4–11, 5–6

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

E

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

“create,” 384, 384f

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

queue, 380–381, 431

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

F

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

events in, 380, 381

flow of control and, 401

garage door opener example of, 407–408, 409f

handshaking in, 361, 403–407

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

sequencing and, 357, 361

state in, 359, 378

state transition table and, 386, 386t

time slicing and, 368–369

transition in, 359, 378

Flawed requirements, 131

“Floating” transition, 384, 384f

Flow(s)

of control, 389, 401, 406, 417, 418

data, 25–27, 26f, 477

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

divisions in, 7, 7f

functional isolation in, 8

maintainability and, 10

power of, 7

programming by contract in, 8

redundancy and, 8–10, 9f

in structured development, 7–11

unit testing and, 11

Functional isolation

in functional decomposition, 8

in structured development, 6

G

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

disjoint, 303, 315–317, 316f

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

Genericity, 59–60, 61

“Go To Statement Considered Harmful” (Dijkstra), 12

Graphical C++, 29

Graphical representation, in structured development, 5

Graphs, 21–22

H

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

Harel model, 375, 385

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

I

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

Inherent polymorphism, 59, 60

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

scope of, 279, 289

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)

abstraction and, 79, 231

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

problem space in, 79, 80

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

J

Johnson, Samuel, 333

Joint generalization, 303

K

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

delegation and, 334–335, 335f

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

L

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

object, 362–373, 396

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)

M

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

attributes and, 52, 197–207

collaborations and, 198

context and, 198

definition of, 168, 199

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

Harel, 375, 385

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

problem space in, 79, 80

remote POS entry example of, 99–103

requirements and, 80

rewards of, 81–84

Mealy, 374–376

Moore, 374–376, 434

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

Moore model, 374–376, 434

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

N

Naming conventions, for states and events, 433–435

Navigation

associations and, 235, 236

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

O

Object(s). See also Entity(ies)

abstraction of responsibilities, 399–400

anthropomorphization and, 206–207

blitz, 169–172

characteristics, 49–52

classes and, 51f

definition of, 37, 50

entities and, 51f

entities vs., 164

identifying candidate, 163

example, 174t–177t

instances and, 51f

instance vs., 50

life cycles, 362–373, 396

logical indivisibility and, 41

methods and, 197–207

operations and, 197–207

in reification, 268, 268f

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

definition of, 168, 199

implementation of, 200

Overload polymorphism, 59

P

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

example of, 130–145, 147–150

feedback to, 231

implementation hiding and, 108

importance of, 105–107

interfaces and, 108, 118

invariants and, 108

legacy replacement example of, 147–150

levels of abstract and, 116–117, 117f

Liskov Substitution Principle and, 326

maintainability and, 82, 106

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

navigation through, 237, 237f

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

Plug board, 4, 18

Point-of-sale (POS) entry, remote, as example of invariant modeling, 99–103

Polymorphic events, 426

Polymorphism

abstraction and, 59

ad-hoc, 59, 60, 80

behaviors and, 157

encapsulation and, 59

genericity, 59–60, 61

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

Precondition, 387, 434

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

constraint, 263–264, 263f

definition of, 67

delegation and, 166, 330

generalization in, 309

in invariant modeling, 79, 80

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 and, 308, 309

subclasses in, 311–312

subject matter and, 33, 111

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

Q

Queue, event, 380–381, 431

R

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

scope of, 279, 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

allocation, 130, 147

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

S

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

of behaviors, 202, 221

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

constraints, 397f, 398

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

Shakespeare, William, 53, 105

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

constraint, 263–264, 263f

definition of, 67

delegation and, 166, 330

entity, 163

generalization in, 309

in invariant modeling, 79, 80

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 and, 308, 309

subclasses in, 311–312

subject matter and, 33, 111

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

Starr, Leon, 154, 233, 320

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)

analysis in, 6, 32

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

cohesion and, 307, 328–329

composition with, 317–323, 318f, 320f, 323f, 324f

definition of, 300

disadvantages of, 328–329

discriminator and, 300–301

disjoint, 315–317, 316f

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)

abstraction and, 308, 345–349

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

problem space and, 33, 111

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

bridges between, 122–127, 227

characteristics of, 109–110

client/service relationships and, 147

cohesion, 136

common, 131

customer input for, 145–146

decoupling of, 124

definition of, 40, 109

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

Symmetric roles, 245, 245f

Synchronous implementation, 364

Synchronous knowledge access, 430

Synchronous services, 199, 204–206, 369–373

Synchronous wormhole, 124–125

T

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

engine, 45, 66, 238, 279–280

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

“floating,” 384, 384f

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

U

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

V

Value(s)

attribute vs., 52

transforms and, 205

Volatility, of requirements, 31

W

Wirfs-Brock, Rebecca, 21, 163, 421

Wirth, Nicolas, 25

Wormhole, synchronous, 124–125

Z

Zoological taxonomy, 8

..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset
3.147.13.192