Component-Based Software

David S. Rosenblum(ed. By Richard N. Taylor)

ICS 221Fall 2002

Components and Reuse

n Develop systems of components of areasonable size and reuse themn Repeated use of a componentn Adapting components for use outside their

original context

n Extend the idea beyond code to otherdevelopment artifacts

Goals of Reusen Goals of reuse are primarily economic

n Save cost/time/effort of redundant work, increaseproductivity

n Decrease time to marketn Improve systems by reusing both the artifact and

the underlying engineering experience

n Economic goals achieved only when units ofreuse reach critical mass in size, capabilityand uniformity

n But quality is another motivation

Historical Originsn Idea originally due to Doug McIlroy

“Mass Produced Software Components”, 1968 NATOConference on Software Engineering

n Reusable components, component libraries

n Named as a potential “silver bullet” by FredBrooks (1987)

n Much research interest in the ’80s and ’90sn Technical and managerial barriers have

prevented widespread successn This led McIlroy to believe he had been wrong!

Musings on McIlroy…

n Granularityn Degrees of variationn Means of achieving specializationn Means of composition, and reasoning

about composed systems

From Reuse to Component-Based Developmentn The term reuse is a misnomer

n No other engineering discipline uses the termn Systematic design and use of standard

components is accepted practice in otherengineering disciplines

n The term will (eventually) become obsolete

n The important ideas behind reuse arecentered on the notion of componentsn Design of components for use in multiple contextsn Design of families of related componentsn Design of components with standardized

packaging

Different Flavors ofComponentsn (Reusable) Third-Party Software Piecesn Plug-ins/Add-insn Appletsn Frameworksn Open Systemsn Distributed Object Infrastructuresn Compound Documentsn Legacy Systems

Software EngineeringImplications

n Traditional software systemsn are developed by a single organizationn undergo a phased development processn have a synchronized release schedulen have a proprietary design and proprietary

component interfacesn have a monolithic code basen go through a painful evolution

Lifecycle Model of TraditionalSystems

RequirementsRequirements

DesignDesign

ImplementationImplementation

DeploymentDeployment

ValidationValidation

IntegrationIntegration

Component-BasedDevelopment

A Possible Lifecycle Model forComponent-Based Software

SystemRequirements

SystemRequirements

SystemDesign

SystemDesign

SystemIntegrationSystem

Integration

ComponentValidation

ComponentValidation

……

“Integrate-Then-Deploy”System

ValidationSystem

Validation

SystemDeployment

SystemDeployment

Another PossibleLifecycle Model

SystemRequirements

SystemRequirements

SystemDesign

SystemDesign

SystemIntegrationSystem

Integration

ComponentDeployment

ComponentDeployment

……

“Deploy-Then-Integrate”

Implications of the LifecycleModels

A Challenge for Component-Based Software: Testing

Unit testing alone won’t cut it

Nor will static analysis techniques

New dynamic analysis methods areneeded

Another View of the Problem

n Single vendorn White-box artifacts

n code, specs, test cases,analysis support, docs

n Multiple vendorsn Many black-box artifacts

n code, internal specs, testcases, analysis support

Old-Style Development Component-Based Development

A (Partial) Solution:Component Metadata

n Metadata = “data about data”n Abstracted information about component internals and

development historyn Can be accessed via metamethods

n Component developer supplies metadatan Application builder exploits metadata

n Design time and runtime

+

Component Developer ApplicationBuilder

DevelopmentTools

Kinds of Metadata forSE Tasks (I)n Information on customizing the component

n Component propertiesn Constraints on properties

n Information to integrate the componentn Interface syntax

n Java reflection, COM QueryInterface, CORBA DIIn Generated and consumed events

n Interface semanticsn Pre/post conditions and invariantsn Protocol specs

Many of these are “traditional” kinds of component metadata

Kinds of Metadata forSE Tasks (II)n Information to evaluate the component

n Static and dynamic metricsn Cyclomatic complexityn Test coverage achieved by developer

n QoS informationn Pricing/leasing information

n Information to test and debug the componentn Exported state machine representationn Embedded test suite with coverage informationn Input/output dependencies at interfacen Dynamically computed coverage information

Kinds of Metadata forSE Tasks (III)n Information to analyze the component

n Summary flow informationn Control dependenciesn Data dependencies

n Graph modelsn Call graphn Control-flow graph

n Other information to support softwareengineering tasks

An Example:Program Slicing

n Suppose we want backward slice w.r.t. total at Bn Do saving, amount, and/or state of checking

influence balance at A?n Dependency metadata for BankingAccount could tell us!

public boolean checkingToSavings (String cAccountCode String sAccountCode, float amount) { BankingAccount checking(cAccountCode); BankingAccount saving(sAccountCode); float balance, total; . . . checking.open(); saving.open(); . . . balance = checking.moveFunds(saving, amount); // A . . . total = balance + additionalFunds; // B . . .}

Implementation Issues:Metadata Format and Namingn Need uniform format for text and non-text

metadatan XML

n DTDs specify format

n Need uniform way of identifying purpose ofmetadata to usersn MIME-like tags describe purpose

n Example: analysis/data-dependency for data flowinformation

n Who establishes naming scheme?n How do new metadata get established?

Implementation Issues:Metadata Addition & Retrievaln Need uniform way for a component to expose

its particular collection of metadatan Two metamethods

n QueryMetadatan Like QueryInterface in COM

n GetMetadata(tag, parameters)n Selects metadata according to “tag”n Returns statically-embedded or dynamically computed

valuen Could operate as an iterator for complex piecewise

metadata

Metadata and Testing ofDistributed Componentsn Metadata can be used to aid application of

existing testing techniques in distributedobject systems

n But how should existing testing techniques bechanged for distributed components anddistributed object systems (and how canmetadata help)?n Coverage criteria, reliability modelsn Testing infrastructuren Test monitoring and oracles

Conclusion

n Component-based software is the waveof the future

n But there are many softwareengineering challenges to address

n Metadata may provide a solution