software engineering institute carnegie mellon university component-based software kurt c. wallnau...

Software Engineering InstituteCarnegie Mellon University

Component-Based Software

Kurt C. Wallnau

Software Engineering Institute

Carnegie Mellon University, USA

[email protected]


Overview

Why component-based software?

What are components? component frameworks?

WaterBeans: “rolling your own” framework

Practical considerations

Component resources


Why Component-Based Software?

Component-Based Software• adaptability through component

substitution and composition• platform/language interoperability• competitive marketplace for

component vendors

SW Products & Technology

Marketplace Imperatives Business Imperatives

Technology Enablers

COM

CORBAJava Beans

WebOO

IT = competitive edge

Elements of component technologyEnterprise Java Beans


Interlude: Components v. Objects

Object-orientation is neither necessary nor sufficient for component-based software--but it is a convenient place to start

Object Characteristics• abstraction (interfaces and

encapsulation)• inheritance (hierarchically

structured abstractions)• polymorphism (flexible

but type-safe run-time binding)

Component Characteristics• abstraction (interfaces and

encapsulation)• conformance to framework• independently deployable• composable • etc.


Components and Objects

Components and Objects are different kinds of abstractions• they are each good at different kinds of things• confusion sometimes arises because they share

some characteristics (e.g. encapsulation)


The Object-Oriented ParadigmObject-oriented systems are based upon domain models

• the types of entities (or concepts)• a type/subtype class hierarchy• the structure and operation of OO

software depends on this hierarchy

This works when the domain is well understood and stable

• otherwise significant delays in implementation are to be expected

• and the resulting system will be brittle and difficult to adapt (real world class hierarchies are notoriously complex and difficult to change)


The Component ParadigmComponents permit different approaches to structuring software systems

• for example, in ways that are not dependent upon the application domain (as with OO)

• i.e., frameworks based on “coordination model” rather than “domain model” are possible--as in WaterBeans

This is one way to get a broader market for commercial components than possible with objects

Coordination models allow integration of components without caring about what the components actually do individually or integrated.


Overview





Component resources


This is what the experts say...A component is a non-trivial, nearly-independent, and replaceable part of a system that fulfills a clear function in the context of a well-defined architecture. A component conforms to and provides the physical realization of a set of interfaces.

--Philippe Krutchen, Rational SoftwareA run-time software component is a

dynamically bindable package of one or more programs managed as a unit and accessed through documented interfaces that can be discovered at run time.

--Gartner Group

A software component is a unit of composition with contractually specified interfaces and explicit context dependencies only. A software component can be deployed independently and is subject to third-party composition

--Clemens Szyperski

A business component represents the software implementation of an autonomous business concept or business process. It consists of the software artifacts necessary to express, implement, and deploy the concept as a reusable element of a larger business system.

--Wojtek Kozaczynski, SSA

These definitions show common ground & different perspectives


Kruchten Szyperski Gartner Kozaczynski

Large-Grained Independent "nearly" ? Composable Architectural Abstraction

Run-time bind Introspection Deployable

What I think they really said...

There are some areas of agreement and some differences in perspectives among the experts


What they should have saidOne key to understanding component software is the relation between component and framework

• components are conformant with a framework

• a framework provides compose-time and run-time services

Not all frameworks are alike• they differ in scope and in the

kinds of interfaces they impose on components

Framework

Com

pon

en

ts

Component and Framework are inseparable concepts


Types of Component FrameworkFramework scope

• vertical: application specific• horizontal: application neutral

Framework constraints• function:

– several types of component

– type-specific interfaces

– interfaces express functionality

• coordination: – one type of component

– a standard component interface

– interface expresses coordination

vertical horizontal

coor

dina

tion

func

tion

Scope of Framework

Fram

ew

ork

Con

stra

ints

Narrow, focused features. See object-oriented frameworks. E.g. SEMATECH CIM Framework.

For large-scale systems integration. E.g. Enterprise Java Beans.

For application-level software. E.g., Java Beans, and Microsoft COM. Great competition here.

Not well explored. For application-level software with domain specific coordination. E.g., WaterBeans.A Notional Matrix for

Component Frameworks


Coordination Interfaces

Coordination interfaces are an option to functional interfaces• there are fewer models for coordinating the activities of components

than there are functions that we want our components to execute–harden coordination into programmable interfaces

–specify functionality via protocols to be interpreted by components

• leads to a more uniform concept for integration through composition

in data

out data

update

status

“push”

“100”

“ok”

instruction

signal223175213

100

Stack

logic

These are run-time coordination interfaces

• how component functions are executed

Build-time & install-time interfaces are possible

• registration & property editing, for example

Stack component


Overview





Component resources


Framework Scopes:• A: Urban Runoff Models• B: Loading Models• C: Receiving Models• D: Water Quality Models

The WaterBeans Framework

A

Agriculture

Mouse

SWMM

Urban

Silviculture

Mining

ConstructionB

WASP

QUAL2E

Estuary

WASP

QUAL2E

Lake

WASP

QUAL2E

River

C

D

The Environmental Protection Agency (EPA) develops software to model water quality

• lots and lots of models• poor integration• few standards

The SEI is demonstrating component software for EPA

• initial scope is Urban Runoff• to be extended to Loading Models

We illustrate WaterBeans to show practical feasibility of vertical coordination frameworks


WaterBeans and Components

Model

Application

Components

Based on scientific theories and mathematics

Computer tools for simulation and evaluation of models

Custom and “off-the-shelf” software elements

built from

implemented by

WaterBeans

imports

composes

simulates


The WaterBeans Specification

• Components implement ~20 (some trivial) interface calls• Coordinational interface: how to register and execute components

– WaterBeans does not know or care about what the components compute

• Coordination scheme: a cyclic executive with scheduling determined by data dependencies among components

Component interfaces to initialize, execute, and obtain input and output data

Component interfaces to register the component and its properties to the WaterBeans framework


The WaterBeans Composer

A standard coordination model supports compositional development and very high levels of program abstraction

Component

inspector

Registered Sewer Components

Composer

tools

Component

instances and typed data

connectorsData-driven component

semantics


WaterBeans in Another Domain...

WaterBeans framework was applied to another domain• although a trivial domain, it is a proof of generality

Wave form components

Wave combinations terminating in oscilloscope component


Overview





Component resources


Components: Not a Silver Bullet

Components (as in WaterBeans) do not solve integration and interoperability problems• these problems are “merely” moved from hardened

interfaces to data semantics– what properties does a component possess, and what do the

properties mean?– for this industry consensus is required

However, coordination-style frameworks offer intriguing benefits (abstraction, composition,…)


Components: An Expandable Idea

Component-based software is an emerging technology and discipline

This talk has focused on one set of theoretical issues--the marketplace is more expansive• there are many emerging component technologies

(COM/DCOM/ActiveX, Bean varieties , etc.)• there are a variety of emerging “methodologies,”

some as extensions of pure OO and UML


Components: A Competitive Field

There is tremendous industry demand for improvements in software technology• recall the introductory motivation to this talk

There are many component technology providers looking to exploit this demand• competition over infrastructure standards is “hot”

Bottom Line: Expect instability and innovation in commercially-available component technology


Component ResourcesNIST Advanced Technology Program in Component-Based Software http://www.atp.nist.gov/atp/focusprg.htmProceedings ICSE’98 Workshop on Component-Based Software Engineering http://www.atp.nist.gov/atp/focusprg.htm (cf Sept/Oct issue of IEEE Software for a summary of this workshop)Articles on Component-Based Software from OdaTeam http://www.odateam.com/cop/articles.htmlAn industry perspective on commercial tools for component-based development http://www.cool.sterling.com/cbd/

software engineering institute carnegie mellon university component-based software kurt c. wallnau...

Documents