Downloadable Sample Chapter
Click below for Sample Chapter related to this title:
wallnauch1.pdf
wallnauch13.pdf
Table of Contents
Preface.
I: FUNDAMENTALS.
1. Components Everywhere. The Software Component Revolution.
Component Space.
Process, Method & Notation Assumptions.
Terminology and Acronyms.
Summary.
2. The Unfinished Revolution. The First Software Crisis.
The Software Factory Regime.
The Second Software Crisis.
The Market Regime.
Le Procés c'est mort! Vive le Procés!
Summary.
For Further Reading.
Discussion Questions.
3. Engineering Design & Components. Fundamental Ideas.
Impact of Software Components.
Designing With & For Components.
Summary.
Discussion Questions.
4. Requirements & Components. Fundamental Ideas.
Traditional Requirements Engineering.
Component-Based Requirements Engineering.
Summary.
Discussion Questions.
5. Ensembles & Blackboards. Fundamental Ideas.
The Ensemble Metamodel.
Modeling Ensembles with Blackboards.
Summary.
Discussion Questions.
6. Model Problems. Fundamental Ideas.
The Role of Toys.
From Toy to Model Problem.
Finding the Right Model Problems.
Repair and Contingency.
Summary.
For Further Reading.
Discussion Questions.
7. Managing the Design Space. Fundamental Ideas.
Ensembles, Blackboards, Relations.
Ensemble Management.
Component & Ensemble Composition.
Repository Structure.
Summary.
Discussion Questions.
8. Storing Competence. Fundamental Ideas.
Packaging With Ensemble Handbooks.
Automation.
Summary.
Discussion Questions.
9. The Multi-Attribute Utility Technique. Fundamental Ideas.
Evaluating Components with MAUT.
Summary.
For Further Reading.
Discussion Questions.
10. Risk-Misfit. Fundamental Ideas.
Feature and Repair Analysis.
Component Selection.
Why Risk/Misfit?
Experiences with Risk/Misfit.
Summary.
For Further Reading.
Discussion Questions.
11. Black Box Visibility. Fundamental Ideas.
Opportunities for Visibility.
Probing.
Snooping.
Spoofing.
Static Program Analysis.
Summary.
Discussion Questions.
II: CASE STUDY.
12. The DIRS Case Study. Sources of Complexity in DIRS.
A False Start.
Regrouping: The "DeepWeb" Approach.
Implications of DeepWeb.
Commitments.
Deceptive Simplicity.
Summary.
For Further Reading.
Discussion Questions.
13. Applet Ensemble: The Opening. Where are We?
Risk Analysis.
Model Problem.
Model Solutions.
Evaluation.
Summary.
Discussion Questions.
14. Public Key Infrastructure. Fundamental Ideas.
Non-Repudiation.
Confidentiality.
Integrity.
Summary.
For Further Reading.
Discussion Questions.
15. A Certificate Odyssey. Where are We?
Exploring Certificate Space.
Sustaining the Public Key Infrastructure.
Evaluation.
Summary.
Discussion Questions.
16. Applet Ensemble: The Middlegame. Where are We?
Repair Analysis.
Risk Analysis.
Summary.
Discussion Questions.
17. Secure Applet Ensemble. Where are We?
Model Problem.
Model Solutions.
For Further Reading.
Summary.
Discussion Questions.
18. Instrumented Model Problem. Where are We?
Model Problem.
Model Solutions.
Evaluation.
Summary.
Discussion Questions.
19. Sorbet: A Custom Ensemble. Where are We?
Model Problem.
Model Solution.
Evaluation.
Summary.
Discussion Questions.
20. Hardware Components. Where are We?
Risk Analysis.
Realize Confidentiality Model Problem.
Realize Authorization Model problem.
Repair Analysis.
Summary.
Discussion Questions.
21. Into the Black Box. Where are We?
Define Model Problem.
Model Solution.
Evaluation.
Summary.
Discussion Questions.
22. Applet Ensemble: The Endgame. Where are We?
Repair Analysis.
Risk Analysis.
Summary.
Discussion Questions.
23. Secure Applet Ensemble Redux. Model Problem.
Model Solution.
Evaluation.
Summary.
Discussion Questions.
24. Conclusion & Retrospective. Multi-Attribute Evaluation.
Conclusion.
Retrospective.
Summary.
Discussion Questions.
III: ONWARD.
25. Getting Started. Build a Competence Center.
Define Your Infrastructure.
Build an Enterprise Design Handbook.
Certify Designers and Lead Engineers.
Summary.
26. The Prophecies. Bibliography. Index.
Preface
There is a real and growing gap between the theory and practice of component-based software design.
There are, of course, books on component-based design. However, these books assume that the design task is to develop specifications for software components when most component-based design relies on preexisting components. There is room for both perspectives. However, preexisting components introduce new and novel design challenges, and their use is becoming increasingly prominent. Preexisting components mean preexisting component specifications, and these are constraints on--not artifacts of--a design.
Current component-based design methods are focused on the less interesting and less encountered design problem. The more common and more interesting aspects of the design process are those that are no longer under the control of the designer.
- Use of preexisting components involves a completely different class of design problem than arises from component specification. Preexisting components involve the designer in selection decisions, while the freedom to define component interfaces involves the designer in optimization decisions. The difference between these classes of design problem are only gradually becoming evident to software engineers, and design methods have not yet caught up with this growing awareness.
- Use of preexisting components involves a significant loss of control over fundamental design decisions: how a system is partitioned into components, what functionality is provided by components, and how components coordinate their activities. In software engineering theory, these are architectural (that is, design) decisions. This leads to the mistaken conclusion that aggressive use of preexisting components is antithetical to, or at least incompatible or disjunctive with, software design.
We have described briefly the state of component-based design methods today, but have not yet supported the assertion that there is a growing gap between the theory and practice of component-based development. In fact, the gap does exist and is self-evident, once you know where to look for it.
The trend toward component-based development has been well under way for more than fifteen years, and has its roots in the commercial software marketplace. Software products, such as relational database management systems, transaction monitors, message brokers, event managers, encryption services, Web browsers and servers, geographic information systems, product data management systems, ad infinitum, all satisfy the essential criteria of software component, at least as this term is coming to be understood by industry. That is, they all are implementations of functionality, are in binary form, are independently deployed, are described by a programmatic interface, and support third-party integration.
The commercial marketplace is the primary source of software components. This is true today, and will remain so for the indefinite future. Indeed, we believe that components and the software component marketplace are inextricably linked. Szyperski, in his influential book, shares this belief by observing that a component must be defined to fill a market niche. However, Szyperski's notion of market was largely (although not completely) metaphorical. In contrast, our use of the term component market refers to something that demonstrably exists today, complete with component suppliers, component infrastructure providers, third-party component integrators, and, ultimately, consumers.
Ignoring the effects of the marketplace on software engineering would be analogous to ignoring the effects of friction on mechanical engineering. In particular, there are three qualities of commercial software components that together account for a significant share of the challenges posed by software components.
- Commercial software components are complex. This complexity is needed to justify and sustain a component market. Many components are sufficiently complex that even experts in their use do not know all their features. There are invariably unknowns about component features and behavior.
- Commercial software components are idiosyncratic. Standards are useful, but innovative features attract consumers. This means component knowledge is vendor-specific, and integration difficulties arise due to mismatches among innovative (that is, nonstandard) features.
- Commercial software components are unstable. New features must be introduced to motivate upgrade, and are needed where competitors have copied successful features. Component knowledge has a short half-life, and design assumptions based on component features are fragile.
These qualities of software components, as they are found in the practice of building real systems, confound the assumptions of an orderly process that underlie traditional software design methods. However, these new complexities require a methodological response, since all component-based roads lead to the commercial component marketplace.
Methodological Response
A central proposition of our approach is that a principal source of risk in component-based design is a lack of knowledge about how components should be integrated, and how they behave when integrated. To mitigate this risk, component-based design inherently involves exploration and discovery. Acquiring and sustaining technology (component) competence is a principal motivation for this exploration.
This proposition may appear to some to be a heretical departure from the canons of software process improvement, which emphasize management skills over technical skills, and collective behavior over individual contributions. Indeed, phrases such as "that's just plumbing" in reference to component integration details, and "we need to get beyond individual heroics" in reference to reliance on software engineers with extraordinarily deep technology competence, are indicative of a mismatch between perceptions of what is important in software process, and the reality of what is needed in component-based development. In fact, the feasibility of a design is often dependent on "plumbing." Moreover, the overall design conception often depends on these low-level details. And there is no escaping the fact that deep technology competence is essential if these details are to be mastered.
The following are core elements of our methodological response:
- We introduce component ensemble as a fundamental design abstraction. Ensembles expose component dependencies, and shift the emphasis from selecting individual components to selecting sets of components that work together (that is, ensembles).
- We introduce blackboards as a fundamental design notation. Blackboards depict what is currently known about an ensemble and, just as important, what remains to be discovered. Blackboards serve to document a design and known areas of design risk.
- We introduce a risk-driven discovery process, called R3, for exposing design risk, and for defining ensemble feasibility criteria. We also introduce a prototyping process, called model problems, for generating situated component expertise, and for establishing ensemble feasibility.
- We introduce the design space, defined in terms of ensemble relations and predicates. The design space captures dependencies among ensembles that arise in response to anticipated market events such as new component releases, and design hedges where ensemble feasibility is in doubt.
The methodological challenge is to meet the challenge posed by the commercial component market without allowing a) the design process to degenerate into an exercise in hacking, and b) innovative but unstable technology features to dominate a design and result in excessive and unnecessary design risk. The approach we prescribe, we believe, meets this challenge.
About This Book
Goals of this book
Our goals are straightforward. Our first goal is to show that software components pose new methodological challenges for software engineering. In making this argument, we hope to clarify the nature of these challenges, with particular emphasis on those challenges rooted in the dynamics of the component market. Our second goal is to describe, in detail, processes and techniques that respond to these challenges. We believe these processes and techniques are a necessary foundation for any methodological response to software components. Our final goal is to illustrate, in a realistic case study drawn from our own experience in developing a large enterprise system, the complexity of component-based design, and the efficacy of our proposed processes and techniques.
Intended audience
This book is intended for individuals participating in a component-based development effort, and for students of software engineering. Although the whole of the book provides useful information for all of these roles, emphasis may vary.
System Architect.The lead designer will find ensembles, and the techniques for reasoning about ensemble repair and feasibility, welcome additions to his or her repertoire. The design space provides the system architect the conceptual language for managing the many layers of contingency and repair that characterize complex component-based systems.
Chief Engineer.While the system architect is responsible for the conceptual integrity of a design, the chief engineer is responsible for demonstrating its feasibility in practice. The chief engineer will find the R3 and model problem processes essential to exposing latent design risks that are otherwise masked by the complexity of components and their interactions.
Project Manager.Project management is concerned first and foremost with identifying and mitigating project risk. The aggressive search for technical risk that drives R3 (one of the Rs is Risk Identification) meets these concerns. The design space provides a concise snapshot of the status of a design, and provides a structure for allocating and tracking engineering effort versus project objectives.
Chief Technology Officer (CTO).Modern enterprise systems are universally composed from commercial components. Such large-scale and long-lived systems never leave the design phase and, in fact, inhabit all phases of the development life cycle at all times. The CTO will find all of the concepts and techniques we describe useful for managing technology refresh.
Software Engineers and Programmers.The frontline developer is the true unsung hero of component-based development. Project success depends upon developers to remain current with technology trends. This book provides ammunition for developers who wish to convince their management to invest in technology training in addition to the usual process training.
How to read this book
This book has three parts, as follows:
- Part I explores the engineering challenges posed by commercial components. We describe engineering techniques that meet these challenges, and describe, wherever possible, workflows for incorporating these techniques into an enclosing development process.
- Part II presents an extended case study of a project that we were involved with starting in 1998. Each chapter illustrates the challenges posed by commercial components and the techniques used to meet these challenges.
- Part III provides advice on how to get started using the techniques described in this book. We also dust off our crystal ball and make predictions about the future of component-based development.
Chapter 1 introduces the problems inherent in component-based development. Chapters 2 through 4 explain why it is necessary to abandon as unworkable some of the more staid precepts of software process. Chapter 5 describes component ensembles and blackboards, both essential concepts in their own right and for the material presented in this book. Chapter 6 defines process models for exploratory design and design risk reduction. Chapters 7 and 8 describe how design documentation developed by these processes can be managed and reused, respectively. The remaining chapters in Part I describe specific techniques (really, families of techniques) for developing component-based systems. These can be read in any order; you can also skip these and head straight for the case study and return to the techniques as needed.
The case study describes a chain of events and so these chapters are linked by a running narrative. However, the chapters are designed to be relatively stand-alone, although the motivation for the work described in each chapter may be less than clear if you read them out of order. Chapter 14, which provides a mini-tutorial on public key infrastructure (PKI) and security, is one exception. If you already understand PKI, skip this chapter. Otherwise, you will need to read it to understand the details of the case study.
0201700646P06252001
Index
Accordion effect, 87
Acronyms, listed, 373-377
Advocacy, Risk/Misfit analysis of, 148
Aggregate utility, 117
Aggregation, of ensembles, 91, 100-101
Alternative refinements, 91, 92-93
Alternative remedies, 95-96
Analysis, defined, 38
Analytic Hierarchy Process (AHP), 128
Applet ensemble
advantages and disadvantages of, 188
certificate use by, 338-340
to communicate with CORBA servers, 190
context of, 223
cost-benefit issues, 323-326
custom API wrapper for, 306
evaluation of, 342-344
feasibility of, 325
HTTP-based model solutions for, 191, 193-195
identification and authentication by, 223-225
IIOP-based model solutions for, 195-197
Internet Explorer compatibility of, 341-342
model problem for, 189-191
Netscape compatibility of, 340-341
object signing by, 225-229
repair analysis of, 240-242, 324-325
revised direct HTTP model solution for, 197-198
revised direct IIOP solution for, 198-199
risk analysis of, 188-189, 242-245, 326
security of, 247-261, 331-342
and SSL, 338, 339
Application mode, 289
Application programming interface (API), 55, 56
Applications, 8
spanning, 72-74
Architectural mismatch, 17
Architecture, reference, 106-107
Assembly ensembles, 107
Assumptions, specifying, 55-56
Assurance, defined, 204
Asymmetric key cryptography, 205-206
Asynchronous method invocation, 266
Attributes, 203
enumerated, 203-204
Auditing, 181
defined, 204
Authentication, 182-183
blackboard for, 182, 224
certificates and, 224-225
client, 279
Authorization, 181
blackboard for, 185
of Java applet, 253-257
of rights, 184
Authorization ensemble, 248
Autonomous mode, 289
Availability, defined, 204
Bandwagon effect, 147
Berkeley DB 1.85 database, 308
Best-fit component selection, 148
Bibliography, 367-372
Binary code
hacking of, 166
viewing and editing of, 164-166
Binding box, 222
Binding deconstruction, 106
described, 107
Binding predicate, 91, 97
Bindings, 91, 97-99
Black box, 153
visibility of, 33
Blackboards, 30, 49
as collaboration diagram, 62-66
contingency, 91
defined, 62
function of, 89-90
management of, 88-89
modeling of, 103-104
grand unified, 99
Browsers. See Web browsers
Buried design, 147-148
Business component virtual machine, 6
Business Component Factory, 4, 7
Business rule interpreter (BRI), 189
Capability classes
advantages and disadvantages of, 198
alternatives to, 199-200
CAPI (crypto-API), 343
Catalysis, 4, 7
Certainty
attributes of, 56-57
described, 56
Certificate authorities (CA), 211
certificates for, 211
enterprise, 212, 232
hierarchical, 250-252
trustworthiness of, 211-212
Certificate interoperability, 332-337
Certificate management, 232-234
infrastructure for, 252-253
software for, 234-236
Certificate signing requests, 211
Certificates. See Digital certificates
Certification
of designers and developers, 359-360
liability issues and, 363
Change, as design issue, 16-17
Classifiers, component, 54-55
Client authentication, 279
CMM (software capability maturity model), 12
Code signing, 217
process for, 219, 233
COM+ (Microsoft), 362
Commercial software components. See Software components
Commercialization, 11
Competence
as asset, 28
design to, 18
as diminishing asset, 18
gaps in, 82-83
just-in-time, 29
storing of, 32, 105-112
sustaining of, 18-19
toys and development of, 74-75
Competence center
building, 356
mission of, 357
Component adaptation, 126-127
Component binding, 66-67
Component classifiers, 54-55
Component ensembles. See Ensembles
Component evaluation, 115
using MAUT, 125-126
Component framework, 6
benefits of, 7
evolution of, 7
Component selection
component interdependency and, 126
strategies for, 148
using Risk/Misfit for, 144-146
Component space
dimensions of, 6-7
structure of, 8
Component standards, 6
consolidation of, 362
future trends in, 362-363, 364
niche-specific, 362-363
Component technologies, 54
Component-based design
classes of expertise for, 359
future trends in, 363
methods in, 355-356
nonlinear, 350-351
Component-based development, 6, 28, 30-33
basics of, 9-10
defined, 10
design of, 88
methods of, 4
as process, 28
Components. See Hardware components; Software components
Conditional feasibility, 95
Confidentiality, 181
of data transfer, 183-184
defined, 203
PKI and, 215-217
Configuration ensembles, 107
Constraints
associating with components, 66
defined, 60
minimum relevant, 77
in model problem, 79
notation of, 63, 64-65
Contingencies
described, 108
design, 85-86, 109
planning for, 31
process, 85-86
Contingency blackboards, 91, 93
Contingent feasibility, 95
CORBA
file transfer in, 263, 264-265
performance of, 271
replacement of, 194
transfer methods in, 266-268
Cost effectiveness, 348
Cost-to-risk ratio, 143-144
crash, probing tool, 157
Creative destruction, 11
Credentials
associating with components, 66
defined, 56
examples of, 57
illustrated, 58
notation of, 63-64
Crime, information technology-based, 366
Criteria
identifying, 136-138
per-component, 149-150
weighted, 149
Cryptography
aspects of, 204-205
legal issues in, 306
symmetric-key, 205
Custom software, drawbacks of, 8-9
Cycle time, 349
Data transfer
protocols for, 184
reliability of, 184
DBDump, 308
conversion into API, 329
development of, 310-321
limitations of, 337
DDESpy, snooping tool, 160
Debugging, 153
probing, 157-159
scientific method and, 154-155
snooping, 159-161
spoofing, 161-164
static program analysis, 164-169
Decisions
aids to making, 116, 122
objectifying of, 123-124
Decompilers, 168-169
sample, 169
Deconstruction, 105
binding, 106, 107-108
design, 105-107
Decryption, 204-205
Triple DES, 319, 321
Deferred synchronous method invocation, 266-267
DeJaVu decompiler, 168, 169
DES (Data Encryption Standard), 205
offshoots of, 205
DES-EDE, 205
Design
blackboard expressing intent of, 66-67
for change, 16-17
decision-making about, 32
documentation of, 87
as exploration, 19
knowledge gaps and, 5
market forces and, 5-6
and misfit, 17-18
and process singularity, 19-20
random elements in, 19
structured, 26
of supply chains, 17
to technology competence, 18
Design contingencies, 85-86
Design deconstruction, 105-106
described, 106-107
Design handbook, 108
building, 358-359
Design question, defined, 77
Design record, 148-149
Design space management, 31-32
blackboards and, 89-90
ensemble composition, 101-102
ensemble management, 91-101
fundamentals of, 88-89
repository structure, 103-104
Designers, certification of, 359
Developer certificates, 210
Diffie-Hellman algorithm, 281, 284
Digital certificates
authorities for, 211-212
and component choice, 222-223
generation of, 212
management of, 232-234
and object signing, 225-229
obtaining, 211
principal and target of, 198
self-generated, 233
software for managing, 234-236
types of, 210, 234
Digital signature, 208-209
Dilution of control, 42-43
Direct HTTP ensemble, 191, 193-195
revised, 197-198
Direct IIOP solution, 195-197
advantages and disadvantages of, 199
revised, 198-199
DirectoryServer, Netscape, 224, 225
DIRS (Distributed Image Retrieval System)
architecture of, 177
aspects of, 182-186
commitments in, 181-182
data flow and, 189-190
DeepWeb approach to, 176-179, 200
described, 173
history of, 173-174
moving large images in, 263-272
redesign of database in, 175-176
security requirements of, 181
sources of complexity in, 175
strategic decisions for, 179-180
technology selection for, 180-181
update objectives for, 174
Dis disassembler, 169
Documentation
characteristics of, 88
defined, 38
minimizing, 87
reuse of, 88
Domination analysis, 142-143
Drucker, Peter, 11
dumpasn1 utility, 314
Dynamic content, maintaining security of, 217
ELECTRE, 128
Encryption, 204-205
in Java, 330
using asymmetric key cryptography, 206-208
Engineering
problem solving in, 24-25
types of, 23-24
Engineers, certification of, 359
Ensemble blackboards. See Blackboards
Ensembles, 27, 30, 49
aggregation of, 91, 100-101
assembly, 107
blackboards and, 89-90
composition of, 101-102
configuration, 107
deconstruction of, 105-108
defined, 61
evaluation of, 349-350
functionality of, 50
management of, 91-101
metamodel of, 60-61
modeling of, 62-66
notation of, 92
packaging of, 108-110
reference, 107
refinements of, 92-93
supplier, 107
as types, 90
UML representation of, 91
as units of composition, 90
view of, 91
zero code assembly of, 365
Enterprise architecture standards, 32
Enterprise certificate authority, 212, 232
Enterprise JavaBeans (EJB) (Sun Microsystems), 8, 72, 73-74, 362
Environment, for software, 6
etherfind, snooping tool, 159, 160
Evaluation
a posteriori criteria for, 77, 80
a priori criteria for, 77, 79
identifying criteria, 136-138
setting goals, 124
Event channels, in CORBA, 267-268
Factory creation design pattern, 254
Feasibility, 81, 126
contingent, 95
remedies and, 95-96
represented on blackboard, 91
Feature/risk criterion mapping, 136-138
Featureitis, 147
File transfer
in CORBA, 263, 264-265
evaluation of, 270-272
methods of, 266-268
performance issues, 271, 277
test harness for, 269-270
Filemon, snooping tool, 160
First software crisis, 12-13
First-fit component selection, 148
Flex points, 109
depiction of, 110-111
Flexion, 109
Formative evaluation, 134-135
FTP (File Transfer Protocol), 184
performance issues, 264, 271
Functionality, weighted against sustainability, 346, 347
Fundamental ensemble feasibility predicate, 91, 93-94
Generic Enterprise Ensemble (GEE), 108, 109-110
configurer of, 111-112
structure of, 112
Grand unified blackboard, 99
Greenspan, Alan, 11
Hacking, of binary code, 166
Handbooks, 108
compilation of, 108
of design standards, 358
enterprise design, 358-359
HandleEx, probing tool, 157
Hardware components
case study of, 286-303
compared with software components, 285
evaluation of, 356
interfaces among, 155
Hash collisions, 210
Hashing, algorithms for, 209-210
HEdit, binary editor, 164, 165, 166
Heisenberg uncertainty principle, 161
hexdump, binary viewer, 164, 165
Hexedit, binary editor, 164, 165
HTTP, 184
disadvantages of, 265
revised direct, 195
HTTP browsers. See Web browsers
HTTP server approach, advantages and disadvantages of, 187-188
Hypothesis, for model problem, 79
IDA Pro disassembler, 169
IDEA (International Data Encryption Algorithm), 205
Identification and authentication (I&A), 213-215
bilateral, 277
out-of-box, 223-224, 249-250
unidirectional, 277
IIOP, 184
advantages of, 276
deployment of, 195-197
issues with, 189-190, 195
performance issues, 271
transfer sequence diagram for, 196
See also CORBA
ImageEdit, 184-185
blackboard for launch of, 185
Images
retrieval of, 189. See also DIRS
sending of, 183
Implementation, after analysis, 350
inetd, 158
Information technology revolution
aspects of, 11-12
crime related to, 366
first software crisis, 12-13
market regime, 15-16
second software crisis, 14-15
software factory regime, 13-14
Infrastructure
custom software and, 8-9
defining, 357-358
described, 6-7
framework-based components for, 8
low-level system skills in, 351
Integration misfit, 17, 148
Integrity
defined, 203
described, 217
PKI and, 217, 219
Interaction, components of ensemble metamodel, 63
Interfaces
API, 55
classes of, 155-156
defined, 55-56
exploitable, 156
importance of, 26
integration difficulties with, 3, 27
visibility of, 156-157
International Traffic in Arms Regulations (ITAR), 306
Internet Protocol Security Option (IPSO), 288, 289
ipcs, snooping tool, 159, 160
IROTVIEW, probing tool, 157
ISO-9000 software standards, 12
Iterative development, 70
jad decompiler, 168, 169
Java
applications in, 257-260
security infrastructure of, 329-330
Java Protection Domains, 200, 221, 241
Java 2 plug-in, 241, 325, 326
accommodation of, 329-330, 337-338
javakey, 225, 226
javap disassembler, 167, 168, 169
JCA (Java Cryptography Architecture), 329
JCE (Java Cryptography Extensions), 329, 330
JKS (Java KeyStore), 332
Just-in-time competence, 19
buying, 29
KAI compiler case study, 119
Key
asymmetric, 205-206
defined, 205
size of, 218
symmetric, 205
Key agreement, in Java, 330
Key database, in Netscape, 314-321
Key generation, in Java, 330
Lincoln, Abraham, 9
LiveConnect, 253
login, 158
Market regime, 15-16
MAUT (multi-attribute utility technique), 115
Analytic Hierarchy Process (AHP), 128
basic equation of, 117
component evaluation using, 125-126
for decision support, 150
ELECTRE techniques of, 128
fundamentals of, 116-117
geometric interpretation of, 132
hierarchical model of, 118-122
limitations of, 126-127
mathematical model of, 116-118
as normative tool, 134
OTSO (Off-the-Shelf-Option), 128
process view of, 122-125
Risk/Misfit and, 127, 131
steps in, 123
Maximum risk, quantifying, 140-141
MD5 hashing algorithm, 209, 210
Message authentication code (MAC), 339
Metaprocess, defined, 9
Microsoft, and IPs, 294
Middleware, programmable, 8
Minimum relevant constraints, 77
Misfit
design and, 17-18
integration, 148
quantification of, 132
removal of, 134
types of, 17
Mismatch, architectural, 17
Mocha decompiler, 168, 169
Model problems, 30-31, 127
aspects of, 77
construction of, 80-84
described, 76
realization of, 83-84
and risk analysis, 83
structure of, 76
workflow of, 78
Model solutions, 76, 77, 79-80
evaluation of, 77, 80
related to reality, 350
Mozilla, 308
MTS Spy, snooping tool, 160
Multi-attribute evaluation
conclusions from, 349
weighting of, 346-348
Multi-criteria evaluation, 32
NATO, and first software crisis, 12
Netscape, certificate management by, 233, 235
Netscape certificate database, 309
record format of, 310-313
Netscape Communicator, extraction of confidentiality information from, 306-307
Netscape key database, 314-321
Netscape Navigator, database mechanism of, 307-309, 337
Netscape Security Services library, 309
Network interface cards, 286
Network services, interfaces among, 155
NICNAK.com case study, 286
design questions, 291
model problems and solutions for, 291-302
repair analysis, 302-303
risk analysis, 287-291
Nixon, Richard, 116
Nonlinear design, 350-351
Nonrepudiation, 203
defined, 213
PKI and, 213-215
Nonrequirements, 41, 47
perceptions about, 45-47
Normative evaluation, 134-135
Object signing, 229
procedures for, 225-229
risk/misfit analysis of, 193
tools for, 225
Object-oriented analysis/design, 25-26, 355
compared to component-based methods, 355-356
Octets, 197
od, binary editor, 164, 165
Ongoing evolution, defined, 38
Open source software, 52-54
Operating system services, interfaces among, 155
Orbix 2.2, 194
Orblets, 190-191
OTSO (Off-the-Shelf-Option), for MAUT, 128
Packaging, ensemble, 108-110
PC, and information revolution, 14
Per-component criteria, 149-150
Persistent connections, risk/misfit analysis of, 193
Personal certificates, 210
generation of, 235
pfx, 226-227
Physical security, defined, 204
Piggybacking, 301
Plug-in editor support, risk/misfit analysis of, 193
Pmon, probing tool, 157
Portmon, snooping tool, 160
Postulates, defined, 58
Preference structure, 118, 120, 121
Principal, of digital certificate, 198
Privileges, defined, 198
Probing, 157
tools for, 157
Problems
forming of, 24
setting of, 25
solving of, 24, 25
Process, innovation in, 20-21
Process contingencies, 85-86
Process singularity, 19-20
Process Viewer, probing tool, 157
Product, defined, 54
Programmable middleware, 8
Programmers
demography of, 361
ideal characteristics of, 366
and technology change, 362
Prototyping, 69-71, 350
consumers of, 70
forms of, 70
motivation for, 70
and risk reduction, 70
ps, probing tool, 157, 158
PsList, probing tool, 157
Public key infrastructures (PKI), 101-102
certificate management and, 232-234
and confidentiality, 215-217
in I&A, 213-215
in object and code signing, 217, 219
process of, 235-236
Public/private key cryptography, 205-206
digital certificates and, 210-212
digital signatures and, 208-209
encryption using, 206-208
Pull consumer, 267
Pull producer, 267
Push consumer, 267
Push producer, 267
Qualified binding predicate, 91, 98
Quantification, 66
Quasi-component types
products, 54-55
technologies, 54
R[super-3] process, 31, 81
entry conditions of, 81
flowchart of, 82, 240
and risk analysis, 84-85
using, 81-83
Rapid application development (RAD), 70
Rational Unified Process (RUP), 45
Reasoning systems, 364
Reference architecture, 106-107
Reference ensembles, 107
Reference models, 137
Refinements, of ensemble, 91-93
Regmon, snooping tool, 160
Reliability, of data transfer, 184
Remedies, 95
active vs. passive, 96
alternative, 95-96
Repair analysis, 83, 135-136
cost estimates, 141-142
cost-to-risk ratio, 143-144
domination analysis, 142-143
feature/risk criterion mapping, 136-138
repair selection, 144
repair strategies, 139-140
risk mitigation, 139-140
risk quantification, 138, 140-141
Repair options, 31
evaluation of, 324
Repository structure, 103-104
Requirements
assessment of, 44-45
centrifuge model of, 45-47
market-driven aspects of, 35-36
minimization of, 46
prioritization of, 47
stakeholder perceptions of, 39
Requirements engineering, 36
aspects of, 38
component-based, 42-47
continuity of, 44
dealing with paradox, 47
described, 37
sphere of control of, 42-43
traditional, 38-40
Residual risk, 140, 141
Reuse, 15
Risk
balancing against features, 136-138
described, 132
economic analysis of, 143-144
mitigation of, 133-134, 139-140
prototyping and reduction of, 70
quantification of, 138, 140-141
residual, 140, 141
Risk analysis, 83
R[cubed] and, 84-85, 242-245
Risk factors, 138
Risk/Misfit, 32
applicability of, 150
component selection using, 144-146
formative evaluation using, 134-135
as offshoot of MAUT, 127, 150
per-component criteria and, 149-150
reasons for using, 146-148
repair analysis in, 136-144
utility/risk component of, 132-133
weighted criteria and, 149
RSA cryptography, 206
RUP (Rational Unified Software Process), 9
characteristics of, 9-10
Sandbox, defined, 198
SATAN security analysis tool, 162
Scientific method, 154-155
Second software crisis, 14-15
Secure applet ensemble
blackboards for, 247-248
criteria for, 249-250
Java applet authorization, 253-257
Java application, 257-260
model problem for, 249-253
model solutions for, 253-260
security policy for, 250-253
Secure hashing, 209-210
Secure sessions, 213-217, 230-232
Security, 181
cryptography, 204-209
digital certificates, 210-213
physical, 204
public key, 101-102, 203-220
secure hashing, 209-210
Sensitivity analysis, 118, 125
Server certificates, 210
Services
types of, 155
visibility of, 155-157
Set notation, 92
setuid(), 158
Severity, of risk, 138
SHA-1 hashing algorithm, 209, 210
signedApplet, blackboard for, 64-66
signtool, 225, 226, 229
Simon, Herbert, 116
sniffit, snooping tool, 159, 160
snoop, snooping tool, 159, 160, 161
Snooping, 159-161
tools for, 160
Socratic fallacy, 10
Software
open source, 52-54
and requirements engineering, 47-48
standards of, 12-13
Software capability maturity model, 12
Software components
attributes of, 51-52
bindings of, 97-99
complexity of, 3, 18
component-standard independent, 365
composition of, 101-102
defined, 52
designing with and for, 28, 30
determining features of, 73
development methods based on, 4, 27
dilution of control over, 42
ensembles vs. architectures, 27
environments of, 6
evaluation of, 20, 356
future distribution schemes of, 364-365
future trends in, 363
influence of, 25-28
inheritance structure of, 59
interactions among, 50-51, 59-60, 153
knowledge gaps about, 5
market differentiation of, 5
market growth for, 11-12, 14-15
mismatch of, 8
nonrequired functionality in, 41
problems associated with, 3
requirements for, 19
and requirements engineering, 47-48
sources of, 6
standards for, 26
types of, 5, 15
ubiquity of, 4
Software Engineering Institute (SEI), 12
Software factory regime, 13-14
Software methodology, 25
Sorbet, 325
blackboard for, 278
algorithm used by, 281
described, 278-283
evaluated, 283-284
methodology of, 280-281
optimization of, 282-283
Source code, 155
SourceAgain decompiler, 169
Sourcer disassembler, 169
Spanning applications, 72-74
Spiral development, 9, 19
advantages of, 70
Spoofing, 161-163
of commercial software, 163
information gained by, 163-164
SSJS (Server-Side JavaScript) ensemble, 188, 253
objects in, 255-257
SSL
custom, 276-284
described, 215-216
Netscape-compatible Visigenics pack, 325
risk/misfit analysis of, 193
Visigenics Pack, 241, 242, 275-277, 286, 304
SSLeay, 226, 315
Stakeholders, desires of, 39-40
Standards, as architecture, 26
Static program analysis
binary viewers/editors, 164-167
disassemblers, 167-168
sample, 169
strings, binary viewer, 165
Structured Analysis and Structured Design (SASD), 26
Substitution rates, 118
Supplier ensembles, 107
Supply chain, 17
Sustainability, importance of, 346, 347
Symmetric key cryptography, 205
Synchronous method invocation, 266
System architecture, 16
System failures, diagnosis of, 153-155
Systems
competing influences on, 43
as component streams, 17
dilution of control over, 42
market for, 12
Target, of digital certificate, 198
TCP
error processing by, 302
Microsoft and, 294
piggybacking in, 301-302
tcpdump, snooping tool, 159, 160
Technologies, 54
subclasses of, 59
telnet, monitoring of, 158, 159-160
Thawte, 232
Three-value logic, 94
Time to market, 349
TLS (Transport Layer Security), 216-217
Toys
implementing, 74
installation of, 71-72
limited usefulness of, 75
and prototyping, 70
and risk reduction, 70
role of, 71-75
using, 74-75
trace, probing tool, 157
Tradeoffs
in decision making, 118, 148-149
Risk/Misfit and, 148
Triple DES, 205
decryption of, 319, 321
key and initial value for, 319, 320
truss, probing tool, 157, 158
Truth table, 94
ttsnoop, snooping tool, 159, 160
UDP, Microsoft and, 294
UML (Unified Modeling Language), 10
Components, 4, 7
downside of, 103-104
Unrepaired risk, 140, 141
User factory, 254
Utility functions, 120-122
difficulties in using, 127
example of, 121
Vendor lock, 17
Verisign, 232, 233
View, of ensemble, 91, 99-100
VisiBroker, 254
Visigenics SSL Pack, 241, 242, 275, 286, 304
advantages of, 276-277
Netscape-compatible version of, 325
Web authentication, 182-183
blackboard for, 182, 224
certificates and, 224-225
Web browser(s)
advantages and disadvantages of, 178
blackboard for, 62-63
choice of, 185-186
evaluation of, 192-193
risk/misfit analysis of, 192-193
Web ensembles
bindings among, 98
blackboard view of, 99
Weighted criteria, avoidance of, 149
Weighting, 117-118
Windows Source disassembler, 169
Windump, snooping tool, 159
WingDis decompiler, 169
WinObj, probing tool, 157
Winsock 2.0, 294
Wizards, 111
Zero code assembly, 365
