Building Systems from Commercial Components

by Wallnau, Kurt; Hissam, Scott; Seacord, Robert C.

• ISBN13: 9780201700640
• ISBN10: 0201700646
• Edition: 1st
• Format: Paperback
• Copyright: 2001-07-25
• Publisher: Addison-Wesley Professional

Summary

Commercial software components can dramatically reduce the cost and time required to develop complex business-critical systems. However, integrating them offers stiff challenges that are not well understood by most software practitioners, and there have been many spectacular failures. Now, a team of authors from the Software Engineering Institute draws upon the lessons presented by both the failures and the successes, offering a start-to-finish methodology for integrating commercial components successfully. The authors examine failed integration projects, identifying key lessons and early warning signs, including the failure to account for loss of control over engineering design and production. Drawing upon both successes and failures, they present proven solutions for establishing requirements, evaluating components, creating flexible system designs that incorporate commercial components; and managing multiple concurrent design options linked to external market events and feasibility proofs. They also show how to build "just-in-time" competency with commercial components and integration.

Author Biography

Kurt C. Wallnau is a senior technical staff member at the Software Engineering Institute (SEI). He was team lead for the SEI's commercial off-the-shelf (COTS)-based systems project, and now leads the predictable assembly from certifiable components project. He designed and taught the CMU/MSE course in component-based development methods, and has over 20 years experience in research and industry.

Scott A. Hissam is a senior technical staff member at the SEI and adjunct faculty member at the University of Pittsburgh. He has over 15 years of software development experience, including project leadership positions at Lockheed Martin and Bell Atlantic.

Robert Seacord began programming (professionally) for IBM in 1982 and has been programming in C since 1985, and in C++ since 1992. Robert is currently a Senior Vulnerability Analyst with the CERT/Coordination Center at the Software Engineering Institute (SEI). He is coauthor of Building Systems from Commercial Components (Addison-Wesley, 2002) and Modernizing Legacy Systems (Addison-Wesley, 2003). The CERT/CC, among other security-related activities, regularly analyzes software vulnerability reports and assesses the risk to the Internet and other critical infrastructure.

Table of Contents

Preface	xv
PART ONE Fundamentals	1	(170)
Components Everywhere	3	(8)
The Software Component Revolution	4	(2)
Component Space	6	(3)
Process, Method, & Notation Assumptions	9	(1)
Terminology and Acronyms	10	(1)
Summary	10	(1)
The Unfinished Revolution	11	(12)
The First Software Crisis	12	(1)
The Software Factory Regime	13	(1)
The Second Software Crisis	14	(1)
The Market Regime	15	(5)
System Architecture Reflects Technology Market	16	(1)
Design for Change	16	(1)
Designing Supply Chains	17	(1)
Design in the Face of Misfit	17	(1)
Design to Technology Competence	18	(1)
Sustaining Competence	18	(1)
Design as Exploration	19	(1)
Accommodating the Process Singularity	19	(1)
Le Proces c'est mort! Vive le Proces!	20	(1)
Summary	21	(1)
For Further Reading	21	(1)
Discussion Questions	21	(2)
Engineering Design & Components	23	(12)
Fundamental Ideas	23	(2)
Impact of Software Components	25	(3)
Designing with & for Components	28	(5)
Ensembles & Blackboards (Chapter 5)	30	(1)
Model Problems (Chapter 6)	30	(1)
R3 Cycle (Chapter 6)	31	(1)
Design Space Management (Chapter 7)	31	(1)
Storing Competence (Chapter 8)	32	(1)
Multi-Criteria Evaluation (Chapter 9) & Risk/Misfit (Chapter 10)	32	(1)
Black-Box Visibility (Chapter 11)	33	(1)
Summary	33	(1)
Discussion Questions	33	(2)
Requirements & Components	35	(14)
Fundamental Ideas	36	(2)
Traditional Requirements Engineering	38	(4)
Component-Based Requirements Engineering	42	(5)
Dilution of Control	42	(1)
Competing Influences on Systems	43	(1)
Continuous Character of Requirements Engineering	44	(1)
Requirements Discovery	44	(1)
The Requirements Centrifuge	45	(2)
The Requirements Paradox	47	(1)
Summary	47	(1)
Discussion Questions	48	(1)
Ensembles & Blackboards	49	(20)
Fundamental Ideas	50	(1)
The Ensemble Metamodel	51	(11)
Component	51	(3)
Quasi-Component Types: Technologies and Products	54	(1)
Component Interface: Properties and Credentials	55	(4)
Inheritance Structure	59	(1)
Interactions	59	(1)
The Ensemble Metamodel	60	(2)
Modeling Ensembles with Blackboards	62	(5)
Blackboard as Collaboration Diagram	62	(4)
Quantification and Component Binding	66	(1)
Summary	67	(1)
Discussion Questions	67	(2)
Model Problems	69	(18)
Fundamental Ideas	69	(2)
The Role of Toys	71	(5)
Install It	71	(1)
Imagine the Simplest Spanning Application Possible	72	(2)
Implement the Toy	74	(1)
Repeat {Observe, Modify} Until Satisfied	74	(1)
Throw It Away!	75	(1)
From Toy to Model Problem	76	(4)
Hypothesis	79	(1)
A Priori Evaluation Criteria	79	(1)
Implementation Constraints	79	(1)
Model Solution	79	(1)
A Posteriori Evaluation Criteria	80	(1)
Evaluation	80	(1)
Finding the Right Model Problems	80	(4)
Risk Analysis	83	(1)
Realize Model Problems	83	(1)
Repair Analysis	84	(1)
Repair and Contingency	84	(1)
Summary	85	(1)
For Further Reading	86	(1)
Discussion Questions	86	(1)
Managing the Design Space	87	(18)
Fundamental Ideas	88	(1)
Ensembles, Blackboards, Relations	89	(2)
Ensemble Management	91	(10)
Notational Conventions	92	(1)
Alternative Refinements	92	(1)
The Fundamental Ensemble Feasibility Predicate	93	(2)
Alternative Remedies	95	(2)
Component Bindings	97	(2)
View	99	(1)
Aggregation	100	(1)
Component & Ensemble Composition	101	(2)
Repository Structure	103	(1)
Summary	104	(1)
Discussion Questions	104	(1)
Storing Competence	105	(10)
Fundamental Ideas	105	(3)
Ensemble Deconstruction	106	(2)
Packaging with Ensemble Handbooks	108	(3)
Automation	111	(1)
Summary	112	(1)
Discussion Questions	113	(2)
The Multi-Attribute Utility Technique	115	(16)
Fundamental Ideas	116	(9)
A Mathematical View of MAUT	117	(1)
A Hierarchical Model View of MAUT	118	(4)
A Process View of MAUT	122	(3)
Evaluating Components with MAUT	125	(3)
Limitations of Maut	126	(1)
Beyond MAUT: Risk/Misfit, Model Problems, Ensembles	127	(1)
Summary	128	(1)
For Further Reading	128	(1)
Discussion Questions	128	(3)
Risk-Misfit	131	(22)
Fundamental Ideas	131	(4)
The Utility/Risk Complement	132	(1)
Repair Strategy as Risk Mitigator	133	(1)
Normative and Formative Evaluation with Risk/Misfit	134	(1)
Feature and Repair Analysis	135	(9)
Construct Feature/Risk Criterion Mapping	136	(2)
Quantify the Risk	138	(1)
Identify Repair Options (Risk Mitigation)	139	(1)
Quantify Maximum and Residual Risk	140	(1)
Estimate Repair Cost	141	(1)
Domination Analysis	142	(1)
Calculate Cost-to-Risk Ratio for Each Repair	143	(1)
Assign a Dollar Value to Risk and Select Repair	144	(1)
Component Selection	144	(2)
Why Risk/Misfit?	146	(2)
Bandwagon Effect	147	(1)
Featureitis	147	(1)
Buried Design	147	(1)
Experiences with Risk/Misfit	148	(2)
Avoidance of Weighted Criteria	149	(1)
Per-Component Criteria	149	(1)
Summary	150	(1)
For Further Reading	150	(1)
Discussion Questions	150	(3)
Black Box Visibility	153	(18)
Fundamental Ideas	153	(2)
Opportunities for Visibility	155	(2)
Probing	157	(2)
Snooping	159	(2)
Spoofing	161	(3)
Static Program Analysis	164	(6)
Binary Viewers and Editors	164	(3)
Disassemblers	167	(1)
Decompilers	168	(2)
Summary	170	(1)
Discussion Questions	170	(1)
PART TWO Case Study	171	(182)
The DIRS Case Study	173	(14)
Sources of Complexity in DIRS	175	(1)
A False Start	175	(1)
Regrouping: The ``DeepWeb'' Approach	176	(1)
Implications of DeepWeb	177	(2)
Commitments	179	(2)
Strategic Decisions	179	(1)
Technology Selection	180	(1)
Deceptive Simplicity	181	(5)
The HTTP Server Authenticates Users	182	(1)
Very Large Images	183	(1)
Confidential Data Transfer	183	(1)
Reliable Data Transfer	184	(1)
Authorization of Rights	184	(1)
Editing in ImageEdit	184	(1)
User Chosen Web Browser	185	(1)
Summary	186	(1)
For Further Reading	186	(1)
Discussion Questions	186	(1)
Applet Ensemble: The Opening	187	(16)
Where are We?	187	(1)
Risk Analysis	188	(1)
Model Problem	189	(2)
Model Solutions	191	(8)
Model Solution with Direct HTTP Ensemble	191	(4)
Model Solution with Direct IIOP Ensemble	195	(2)
Extending the Sandbox	197	(2)
Evaluation	199	(2)
Summary	201	(1)
Discussion Questions	202	(1)
Public Key Infrastructure	203	(18)
Fundamental Ideas	204	(9)
Cryptography	204	(2)
Encryption Using Public/Private Key Cryptography	206	(2)
Digital Signatures and Public/Private Key Cryptography	208	(1)
Secure Hashing	209	(1)
Whose Public Key Is That Anyway?	210	(1)
Digital Certificates	210	(1)
Certificate Authorities and Trust	211	(2)
Nonrepudiation	213	(2)
PKI in Identification and Authentication	213	(2)
Confidentiality	215	(2)
PKI in Secure Sessions	215	(2)
Integrity	217	(3)
PKI in Object and Code Signing	217	(3)
Summary	220	(1)
For Further Reading	220	(1)
Discussion Questions	220	(1)
A Certificate Odyssey	221	(18)
Where Are We?	221	(1)
Exploring Certificate Space	222	(10)
Component Choices	222	(1)
Ensemble Context	223	(1)
Identification and Authentication	223	(2)
Object Signing	225	(5)
Secure Sessions	230	(2)
Sustaining the Public Key Infrastructure	232	(4)
Certificate Management Policies	232	(2)
Certificate Management Software	234	(2)
Evaluation	236	(1)
Summary	237	(1)
Discussion Questions	238	(1)
Applet Ensemble: The Middlegame	239	(8)
Where Are We?	239	(1)
Repair Analysis	240	(2)
Risk Analysis	242	(3)
Summary	245	(1)
Discussion Questions	245	(2)
Secure Applet Ensemble	247	(16)
Where Are We?	247	(2)
Model Problem	249	(4)
Security Policy	250	(2)
Certificate Management Infrastructure	252	(1)
Model Solutions	253	(7)
Java Applet Authorization	253	(4)
Java Application	257	(3)
Evaluation	260	(1)
For Further Reading	260	(1)
Summary	261	(1)
Discussion Questions	261	(2)
Instrumented Model Problem	263	(12)
Where Are We?	263	(1)
Model Problem	264	(1)
Model Solutions	265	(5)
Ensemble Refinements	266	(3)
Instrumenting with the Test Harness	269	(1)
Evaluation	270	(2)
Summary	272	(1)
Discussion Question	273	(2)
Sorbet: A Custom Ensemble	275	(10)
Where Are We?	275	(1)
Model Problem	276	(2)
Model Solution	278	(5)
Evaluation	283	(1)
Summary	284	(1)
Discussion Questions	284	(1)
Hardware Components	285	(20)
Where Are We?	286	(1)
Risk Analysis	287	(4)
What is NICNAK?	287	(2)
Risk Analysis	289	(2)
Realize Confidentiality Model Problem	291	(2)
Define Model Problem	291	(1)
Build Model Solution	291	(1)
Evaluate Model Solution	292	(1)
Realize Authorization Model Problem	293	(9)
Define Model Problem	293	(1)
Build Model Solution	293	(9)
Repair Analysis	302	(1)
Summary	303	(1)
Discussion Questions	304	(1)
Into the Black Box	305	(18)
Where Are We?	305	(1)
Define Model Problem	306	(1)
Model Solution	307	(14)
Database Mechanism	307	(2)
Certificate Database	309	(5)
Key Database	314	(7)
Evaluation	321	(1)
Summary	322	(1)
Discussion Questions	322	(1)
Applet Ensemble: The Endgame	323	(6)
Where Are We?	323	(1)
Repair Analysis	324	(2)
Risk Analysis	326	(1)
Summary	326	(1)
Discussion Questions	327	(2)
Secure Applet Ensemble Redux	329	(16)
Model Problem	329	(2)
Model Solution	331	(11)
Certificate Interoperability Toy	332	(5)
Netscape Database (NDBS) Toy	337	(1)
Model Solution	337	(3)
Netscape Navigator Test	340	(1)
Internet Explorer Test	341	(1)
Evaluation	342	(2)
Summary	344	(1)
Discussion Questions	344	(1)
Conclusion & Retrospective	345	(8)
Multi-Attribute Evaluation	346	(3)
Conclusion	349	(1)
Retrospective	349	(3)
The Ensemble's the Thing	349	(1)
Implementation Supports Analysis	350	(1)
Nonlinear Design	350	(1)
Low-Level Systems Skills Are More, Not Less, Critical	351	(1)
Summary	352	(1)
Discussion Questions	352	(1)
PART THREE Onward	353	(14)
Getting Started	355	(6)
Build a Competence Center	356	(1)
Define Your Infrastructure	357	(1)
Build an Enterprise Design Handbook	358	(1)
Certify Designers and Lead Engineers	359	(1)
Summary	360	(1)
The Prophecies	361	(6)
Bibliography	367	(6)
Acronyms	373	(6)
Index	379

Excerpts

There is a realand growinggap 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 onpreexistingcomponents. 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 theless interestingandless encountereddesign problem. The more common and more interesting aspects of the design process are those that are no longer under the control ofthe designer. Use of preexisting components involves a completely different class of design problem than arises from component specification. Preexisting components involve the designer inselection decisions,while the freedom to define component interfaces involves the designer inoptimization 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 termcomponent marketrefers 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