Software Component Engineering

v1.0, April 24, 2002

Frode L. Ødegård

Ødegård Labs, Inc.

http://www.odegard.com © 2002 Ødegård Labs, Inc. All Rights Reserved.

Ødegård Labs, Inc.

Presentation Overview

• Where did the idea of software components come from?• What motivates software components?

• Software components today (April 2002)– The good, the bad and the ugly

• Software Component Engineering as a discipline• What can we expect in the near-term future (2-4 years)?

• Questions

“Software components (…),to be widely applicable todifferent machine and users,should be available in families arranged according to precision, robustness, generality and time-space performance.”

M. D. McIlroy, “Mass produced software components”NATO Conference on Software Engineering,Garmish, Germany, October 1968

http://www.cs.ncl.ac.uk/people/brian.randell/home.formal/NATO/index.html

Motivation for components• System design benefits

– Parcel up understanding of how the system works, maintained by teams/people

– Can reduce risks in system design due to improved knowledge management

– Prediction of system performance can be easier

– Modifying system design can be easier

• Program/project management benefits

– Improved prediction of effort and rework

– Improved prediction of schedule

• Reuse savings

– Internal components can be reused to save on cost/effort/schedule

– External components can be licensed (cheaper and better than do-it-yourself)

Your mileage may vary!

Evolution of “component” idea

1968 1970s, 1980s 1985 1997

subroutines(McIlroy)

modules, classes(Simula-67/C++ classes,Modula-2 modules,Ada packages)

Software ICs(Brad Cox,BYTE Magazine)

“components are binaryunits of… deployment”(Clemens Szypersky,“Component Software:Beyond O-O Programming”)

Modern definition of components

Clemens Szypersky, “Component Software: Beyond O-O Programming”, 1997

“Software components are binary units ofindependent production, acquisition anddeployment that interact to form a functioning system.”

“A Software Component is a software element that conforms to a component model and can be independently deployed and composed without modification according to a composition standard.”

Another definition of components..

George T. Heineman and William T. Councill. Component Based Software Engineering. Addison Wesley, 2001

Commercial use of components• Widespread component models

– OMG: CORBA– Microsoft: COM DCOM .NET– Sun: Java EJB J2EE

• Early marketplace for components– www.componentsource.com– www.flashline.com– http://www.vbxtras.com/– …

• Trend towards certification– ASQ: Certified Software Quality Engineer– IEEE: Certified Software Development Professional – Sun: Sun Certified Programmer/Developer/Web Component Developer for Java 2– Microsoft: Microsoft Certified Application Developer (MCAD) and Solution

Developer (MCSD)

The good

Commercial use of components

• Marketing and Engineering not on the same page w.r.t. Components

– Components require an investment:• Licensing of external IP

• Design of good interfaces for reusable components

• Selection of component model (“Packaging technology”)

• Design for use in (speculative?) future products

– How do we know that it’s worth it?• Do we understand the risks?

• Will the ROI be sufficient?

The bad

Commercial use of components

• Poor software development practices– Component design in actual practice has not progressed much since 1968– Components have weak specifications– Validation of components is uneven– Companies struggle with spaghetti legacy systems– “Reuse” by cut-n-paste still very common, causes severe problems

• Transitioning to Component Based Software Engineering is hard– Many new standards developing, how do we pick the “right” one(s)?– Companies need to invest in education– Companies need to invest in tools– In spite of risk and cost, the alternative may be worse!– Management often does not understand that this is a paradigm shift

The ugly

Paradigm shift: component reuse

Before After

Culture Project-focused Component-focused

How we work Craftsmanship Engineering

What we make Project-specific Programs

Components withPredictable Quality

Strategy Top-down Bottom-up?

Planning Horizon Length of project

Lifetime of product platform

A New Discipline?

• Division of labor driven by economic considerations– Interchangeable parts caused revolution in manufacturing– Reuse of software components motivated by speed-to-market– Industries organize to maximize ROI– Professional roles shaped by needs of organization

• Software Professionals likely to continue specializing– Project/Program Management– Quality/Process– Testing– Usability– Programmer– Analyst– Architect

•Software Component Engineer•Software Architect•Software Requirements Engineer

Software Component Engineer KSAs

• Knowledge– Software Engineering Best Practices– Relevant industry and technical standards– Component technologies– Programming languages and development tools

• Skills– Write precise and complete component interface specifications– Design components using appropriate development tools– Validate component design using static checking tools, Inspection, etc.– Write implementation code using appropriate tools– Verify implementation against design using Inspection, testing etc.– Validate implementation against specification– Write and execute quality/test plans

• Abilities– Critical thinking– Problem solving– Sees the big picture

What Should We Expect From aComponent Engineering Method/Process?

• Independent of particular component model• Extensible – adaptable to future technologies and techniques• Well-defined activities for component specification, design,

implementation, verification and validation• Well-defined list of artifacts that are consumed and produced• Well-defined metrics for activities and artifacts• Standardized templates, rule sets and checklists• Tool support for improved productivity• Supporting documentation and courseware

Some Existing Methods/Processes

• Product-line oriented methods– FODA – FAST– PuLSE– KobrA

• Object-oriented method frameworks– Rational Unified Process – OPEN– Catalyst

• Other methods– Clean Room– Ødegård Labs: Darwin Process Framework

Darwin: Component Engineering Process

Identify ComponentRequirements

Architecture

Component Concept Doc.

Component Interface Spec.

Component Interface Spec.

Component Design Spec.

Component Design Spec.

Source code

Verification Report

Validation Report

Specify Component Interface

Validate Component Interface

Design Component

Validate Component Design

Implement Component Design

Verify Component Implementation

Validate Component Implementation

Requirements Capture

Design/Select Architecture

High-level evolutionary plan

Select and plannext step

Execute planned step

Deliver to real users

Evaluate feedback

“micro-projects”

Darwin: Evolutionary Delivery

Identify

Analyze

Plan

Track

Resolve

Learn

risks

risks

Darwin: Domain Engineering Process

Domain Engineers

Architecture Groups

Common understanding of domain requirements

Spawns new architectures

Anticipated future product family needs

ProductMarketing

EngineeringProduct Family Architecture

Feedback from product teams

Product Family Requirements

Architecture support, training, documentation, …

Near-Term Future of SCE• Certification trend will extend to software architects and software component engineers

• Design/development tools will support better specification and verification– Contract-based interface specifications will be everywhere– Architecture-level design tools will let you plug components together safely– Architecture and Component Design tools will become collaborative– Static checking tools will improve (see ESC Project)– Model checking will be used for verification of many components

• Component technologies will continue to improve– Load-time proof-checking (proof-carrying code)– Improved support for fault-tolerance and mobility

• Abstraction levels will continue to rise, but so will complexity

• Marketing and Engineering will develop a better understanding of component tradeoffs

Conclusions

• Software components are motivated by economic factors similar to those that have influenced other engineering disciplines

• Software component “packaging technology” has improved vastly since 1968, but design and implementation is still mostly ad-hoc

• Software component engineering evolving as a distinct discipline

– Implications for career planning

• Software components raise challenging questions for executives

– Is your company an intelligent customer of component vendors?

– Is your company going to offer components to its customers?

– Is there a software component capability gap between you and your competitors?

Questions?

Speaker: Frode L. Ødegård (frode@odegard.com)Organization: Ødegård Labs, Inc. (http://www.odegard.com)