abb corporate research industrial software systems, chcrc.c2, naedele /00-08-23 / 1 abb 2000 abb...

ABB Corporate ResearchIndustrial Software Systems, CHCRC.C2, Naedele /00-08-23 / 1

2000 ABB Corporate Research Ltd, Baden, Switzerland

Component SoftwareAn Introduction

Martin NaedeleIndustrial Software Systems

CHCRC.C2



Objectives

“Get the feel” for the concept of component-based SWE What are components? What are components not? What are components good for?

Know the terminology and the important acronyms Know where the limits and problems are

Not How do I do “X” with technology of vendor “Y”? a programming course



Topic overview

Part

1 The challenges of SWE - how can component SW help?

2 What is component software?

3 Elements of a component infrastructure

4 Specific component models

5 Developing SW with components - some guidelines

6 Problems and research issues

7 Sources of further information



Part 1

The challenges of software engineering -

how can component software help?



Terms

component a piece of software, definition discussed later

component-based software (CBS), aka component software, aka componentware

application built from components

component-based development (CBD), aka component-based software engineering (CBSE)

the activity of building applications from components



Software engineering problems

The “software crisis” (1968) still exists:

SW is late SW is buggy SW is expensive

Component software - yet another “silver bullet”?

NATO conf 1968

SW crisis

SW engineering

components

NATO conf 1968

SW crisis

SW engineering

components



SWE problems and component SW

SW is late SW is buggy SW is expensive

… because too often applications are created instead of constructed, requiring re-invention re-coding re-testing

Component-based software engineering can help because it focuses on reuse of subsystems infrastructure

Also, applications are not adaptable to

changes

Also, applications are not adaptable to

changes



application

Component#1

Component #

2

Component#3

Component#4

components

Component-based software construction (1)

Component

#1

Component #

2

Component#3

Component#4

construction



application

Component#1

Component #

2

Component#3

Component#4

NewComponent

#4

component

update

Component-based software construction (2)



Side remark: OO and reuse

Object orientation is not primarily concerned with reuse, but with appropriate domain/problem representation

using the technological enablers objects classes inheritance polymorphism

[Wegener]

Experience has shown that the use of OO does not necessarily produce reusable SW fragile base class problem



Expectations from comp.-based development

Reuse of components should improve productivity, speed up development reduce risk improve robustness, increase quality generate additional income

Reuse has two forms

reuse of a component in a different application

fast construction

reuse of an application of which parts have changed

evolvability, extensibility



The promises of component SW - quotes

Microsoft:“Monolithic solutions won’t work No one vendor or one team of programmers can move fast enough Need to leverage others’ work and to build and ship smaller pieces

incrementally Need to evolve smaller pieces asynchronously without sacrificing the

whole”Gartner: “Component-based development is an evolving best practice”

“By 2002, 70 percent of all new applications will be deployed using component-based application building blocks.”

“... components can improve programmer productivity by 40 percent or more…”

“Through 2004, IS organizations that are mature in CBD methods and that use a model-driven or pattern-based application development framework containing a large inventory of business components have the potential to be 5 to 10 times more productive than those that do not.”



Part 1 - Summary

The challenges of SWE - how can component SW help?

Reuse is the solution to many problems in SWE

CBD focuses on SW reuse

CBD tries to avoid re-creation of code

OO is a technology that facilitates creation of new code (if necessary)



Part 2

What is a component?

What is component-based software?



The history

Structured Analysis functional decomposition, hierarchy

Object Orientation encapsulation of state and behavior domain modeling interactions inheritance

Frameworks domain-specific reusable infrastructure

Patterns reuse of abstract mechanisms, experience

Component-based SW ???

interfaces

Not really: 1968Not really: 1968



Component definitions

… are a hot academic research and dispute topic:

compositional

provided interfaces

binary

self-contained

independently deployable

COTS

reusable contracts

quality of service

visual programming

encapsulated

distributable

configurablerequired interfaces

connectors

events

boundaries

usable in unanticipated

contexts

client-centered



Component definitions

… are a hot marketing topic:

Corba

ActiveX

JavaBeans

EJB

COM

DCOM

.NET

COM+

platform independentbinary

language independent

builder tools

controls



Pragmatic definition of CBS

Components independently deployable SW entities with a certain functionality which can be composed into larger systems by means of dynamically

discoverable, immutable interfaces following standardized conventions.

Component-based software (CBS) consists of connected components on multiple levels which also extensively use services provided by the runtime infrastructure of the component model



Terminology

Component object, component instance: actual occurrence of a component in a running system

Component class: abstract template for the creation of component instances

Component: conceptual building block of a system, depending on context the term used for any of the above

Component model: conceptual and implementation framework for writing and working with components

languages, platforms

runtime infrastructure, functionality, and API

technical details of interface and distribution implementation

… more laterExamples: MS COM, Sun EJB, Corba



Interface

Group of related methods that specifies a contract between user and provider of the interface usually only syntax explicitly specified, semantics implicit concept of a contract also includes

semantics non-functional properties, quality of service negotiation

once public, it must be immutable with respect to functionality syntax semantics

implementation may change at any time

A component may provide / implement several interfaces

IBar

IFoo

IFoo2



Interface description: (M)IDL

(Microsoft) Interface Definition Language

[uuid(00112233-ABBA-ABBA-ABBA-BADBADBADBAD), object

]interface IAddressList {

HRESULT addAddress ([in] name, [in] address);HRESULT deleteAddress ([in] name, [in] address);

}

language independent interface specification can be compiled into language dependent code skeletons



Infrastructure“30 % of SW development effort is spent on infrastructure that adds no value”

Goal

Developer should concentrate fully on the application instead of spending time on reccurring side issues

Each commercial component model offers ready-made infrastructures for e.g. transactions distributed computing persistence, DB access security (access control)

“The COM+ philosophy: The runtime does all the grungy stuff” [Microsoft]

more later...



Multi-level programming

Performance oriented languages (C, C++) Application development languages (Java, C#) End-user languages/GUI builder (Visual Basic, visual

programming, scripting) Configuration (attribute based programming (ABP))

security rules, user roles database names distributed deployment feature set/available subsystems transaction requirements

… are set at installation time



Multi-level programming with application server

ServerComponent

TransactionSecurityResources...

ServerComponent

ApplicationServer

TransactionSecurityResources...

...

Attribute BasedProgramming

Client Client

ImperativeProgramming

An application server can be - a Web Server, - a Database Server - a CORBA Server - a TP-Monitor…



Multi-level programming

Bean Provider A

Bean Provider B

Application Assembler

plugs beans together

Deployer

puts beans into containers

Container Provider

Server Provider

System Administrator

configures and administrates enterprise environment

Here: EJB approach

[SUN]



CBS vs. subsystem structuring

Component-based system focus is on interfaces

between units multiple instances of one

component (class) in the running system

composition, bottom-up

System with subsystems focus is on functional

units subsystem is singleton

structuring, top-down



Component aspects

Depending on the point of view, components are units of functionality reusability purchase/outsourcing deployment maintainability quality management documentation …

When discussing CBSE it is important to ensure that everybody talks about the same aspect.



Part 2 - Summary

What is component-based software?

No clearly defined concept No revolutionary technology

Most important features can be summarized as interfaces infrastructure multi-level programming

CBSE is not really (only) about components



Part 3

Elements of a component infrastructure

What does it offer?

How does it work?



Infrastructure

All commercial component models offer runtime infrastructure support to allow the developer to concentrate on the business logic

infrastructure = middleware

certain architectural patterns can be found in all component models Knowing these

patterns will make it easier to

understand a particular vendors

component infrstructure

Knowing these patterns will

make it easier to understand a

particular vendors

component infrstructure



Component infrastructure functionality (1)

runtime component/memory management service/component discovery (naming, broker) transparent distributed computing security (access control) persistence, DB access transactions



Component infrastructure functionality (2)

message queues event handling fault tolerance error isolation load balancing, pooling WWW connectivity data exchange over open protocols



Generic component runtime

EJB

SecurityService

CO

M

CO

RB

A

Servlets

TransactionService

Lifecycle Management

Load balancing- Multi-Process- Multi-Thread

DB

Object Cache

Object Cache

NamingService

Business Logic(Components)

WebIntegration

StateManagement

LegacyIntegration

DB Connection

Pool

Communication

Request/Reply(HTTP,IIOP,RMI, DCOM)

Publish/SubscribeMessage Queue

Eventing

Data Streaming



Architectural pattern (1)Proxy, aka proxy-stub, aka stub-skeleton

used for location transparency, distributed components, inter-process component access

serverclient

remote object

„skeleton“ (remote proxy)„stub“ (local proxy)

Data packaging (marshalling) and transfer transparent for the user



Generation of proxies from IDL

Interfacespecification

inIDL

IDL CompilerIDL Compiler

ClientStub

ClientStub

ServerSkeleton

ServerSkeleton

Part of CORBA, JavaIDL, or COM implementation

Programming language dependent source code to be compiled into client and server application

Proxies



Location transparency

aka distributed computing

Goal Realization with proxy

naming service/ broker

client server



Architectural pattern (2)Serializationused for storage or transmission

the component writes/reads itself to/from a stream serialization is started using a specific interface of the

component

Allows object/compone

nts to “hibernate”

Allows object/compone

nts to “hibernate”

IBarISerialize

IFoo2serialization IBarISerialize

IFoo2

IBarISerialize

IFoo2deserialization



Architectural pattern (3)

Inheritance by delegation used for implementation reuse

components do not use implementation inheritance to avoid dependencies and anomalies

a call to a method of an interface of a component is passed on (delegated) to a different component that implements the actual functionality

IFoo

IFoo2

IFoo

delegation




Interceptionused to give the runtime infrastructure control over calls to a

component’s interface, e.g. for access control instrumentation and logging location transparency (see proxy) ...

Server processServer process

ApplicationApplicationclientclient IFooIFoo

ApplicationApplicationServerServer

SecuritySecurityserviceservice

IFooIFoo




Dynamic connections, aka eventsused for communication between partners that are only known at

runtime follows publish-subscribe pattern notification may be asynchronous <<Interface>>

MyEventListener

myEventOccured()

aReceiveraSender

addMyEventListener(this)

myEventOccurred(...)

removeMyEventListener(this)



Part 3 - Summary

Elements of a component infrastructureWhat does it offer? How does it work?

All component models offer similar runtime infrastructure services, though under very different names

These services are implemented using certain architectural patterns



Part 4

Specific component models



Component model Conceptual and implementation framework for writing and

working with components interface structure interaction mechanisms guidelines on implementation

or A vendor’s approach towards writing components and

providing infrastructure

Presented here: Microsoft COM / ActiveX Microsoft .NET OPC

Definition

Sun EJB Sun JavaBeans Corba



Purpose

Not all component models have the same purpose (D)COM, EJB, Corba:

distributed computing infrastructure for multi-tier systems, integrated with middleware components usually business objects

JavaBeans, ActiveX controls: creation of GUIs visual programming using builder tools have design-time and run-time user-interface have properties communicate with events



COM



Microsoft COM (Component Object Model)

General purpose component model Basic technology behind multiple marketing names

COM, DCOM, COM+, ActiveX, OLE, Automation

History developed in 1995 since W2K COM+ with enhanced infrastructure since 7/00 future unclear because of .NET

Design goals simplicity (of concept, not use!) performance (zero sacrifice if used in process) binary compatibility



Microsoft COM: key features

infrastructure ‘COM runtime’ built in on Win OS

‘binary compatibility’, language independent

requires implementation of interface ‘IUnknown’

uses ‘GUIDs’ (globally unique IDs) to name interfaces etc

location independence (in-process, cross-process, cross-machine)

supports distributed computing with DCOM wire protocol

component deployment as DLL or EXE programming languages HTML/ASP, VB and VC++



ServerServerClientClient

Microsoft COM: location transparency (1)

CO

M o

ver

DC

OM

CO

M o

ver

DC

OM

Remote object onRemote object onany server any server

Object runningObject runningon clienton client

Object runningObject runningon clienton client

COM



Microsoft COM: infrastructure

transactions: MTS message queues: MSMQ database wrapping: OLE DB, ADO, ... security functionality using WinOS multi-user functionality using WinOS broker/discovery: runtime + registry multithreading



Microsoft COM: ActiveX

ActiveX controls: GUI component model on top of COM certain additional conventions visual programming with builder tools, e.g. VB properties and events downloadable code (web scripting)

security issues! (no sandbox, codesigning only)



Microsoft COM: summary

very flexible

very low level programming necessary to use all features high learning threshold

requires use of higher level support ATL (active template libray): class template library with wizards

successful in the market “… a market currently sized at $410 million dollars just for third party

components. This number excludes Microsoft built components and is projected to grow at 65 percent a year, to approximately 3 billion dollars by 2001”

“Choose today from over 1,000 controls from hundreds of vendors” [Giga Information Group]



.NET



Microsoft .NET recently announced (7/00)

not yet clear how much of it is only marketing basic plumbing still COM

focus on ‘Web Services’ application integration using internet technology

new programming languages ASP+ and C# C# very similar to Java C++ deprecated VB gets OO extensions

SOAP (simple object access protocol) replaces DCOM XML-based can get through firewalls

infrastructure called CLR (common language runtime) includes language independent type system all ‘runtime aware’ languages can use it



OPC



OPC (OLE for Process Control)

industry standard for communication between components in field devices, automation equipment and business applications (generic driver) data access historical data access event & alarm handling

data model set of interfaces for COM

server interfaces callback interfaces

managed by OPC Foundation (www.opcfoundation.org)



OPC: Why is OPC needed?

SoftwareDriver

SoftwareDriver

SoftwareDriver

SoftwareDriver

DisplayApplication

TrendApplication

ReportApplication



OPC: How does OPC Solve the Problem?

SoftwareDriver

SoftwareDriver

SoftwareDriver

SoftwareDriver

OPC OPC OPC OPC

DisplayApplication

TrendApplication

ReportApplication

OPC OPC OPC



OPC: application

Field Bus

EthernetInterbay Bus

OPC Server

BusDriver

ClientAppli-cation

ClientAppli-cation

BayUnit

BayUnit

FieldUnit

FieldUnit

Variant A

OPC Server

BusDriver

Station PC

PC

Variant B



EJB



Sun EJB (Enterprise Java Beans)

component model for middle-tier applications (no GUI) part of the Java 2 Platform, Enterprise Edition

History EJB 1.0 (3/1998) EJB 1.1 (1999) EJB 2.0 currently in draft state

Design goals isolate the business logic developer from the infrastructure

plumbing vendor independence for middleware (infrastructure) platform independence scalability

COM: full power to the

programmer, EJB:

convenience for the programmer

COM: full power to the

programmer, EJB:

convenience for the programmer



Sun EJB: J2EE

Overview: Java 2 Platform, Enterprise Edition

EJB enterprise java beans

JSP Java server pages

JMS Java messaging services

Servlets

JTA/JTS Java transaction API/services

JavaIDL (Corba interface)

RMI remote method invocation)

JDBC Java database connectivity

JNDI Java naming and directory services

XML



Sun EJB: key features (1)

infrastructure provided by component server/container server/container available from middleware vendors containers are specified/standardized RMI/IIOP (Corba inter-ORB protocol) used for distribution components deployed as compiled Java classes &

resources in JAR (Java archive) format two flavors

session beans (non-persistent), e.g. shopping cart entity beans (persistent), e.g. bank account



Sun EJB: key features (2)

EJB spec prescribes certain coding rules (naming and semantics) for components

EJBHome (home interface, lifecycle management by container)

EJBObject (remote interface, accessible for client) Bean class (implementation of functionality)



Sun EJB: infrastructure

Container/Server manage object lifetime, persistence, DB access (JDBC), security

transactions: JTS, JTA message queues: JMS database wrapping: JDBC persistency (entity beans)

container managed bean managed

security functionality built into container/server, JAAS multi-user functionality built into container/server broker/discovery: container/server + JNDI multithreading Corba interface built into container/server



Sun EJB: container and server

transactions, access control, communication, lifecycle management, persistency

One server may contain multiple containers

low-level communications, load balancing, directory services



Sun EJB: summary

transaction services not quite as mature as MS MTS designed as server component technology considered promissing for n-tier applications

“...IDC believes that EJB is well on the way to becoming a de facto standard for heterogeneous, multiplatform environments"

[IDC, 4/1999]



JavaBeans



Sun JavaBeans

component model for GUIs and client-side applications visual programming with builder tools, e.g. JBuilder properties and events (JDK 1.1 event model) require (only) certain coding rules (design patterns)

some helper classes exist interfaces for design time and run time built on top of Java



Sun JavaBeans

interface and property lookup by builder tool implicit: needs only class files, based on built-in

introspection and “design patterns” explicit: optionally BeanInfo class per component

automatic serialization support deployed in JARs property editors (also beans) and customizer events can be adapted using automatically generated

adapterscan be written manually w/o wizards additional APIs: InfoBus, JAF; BeanContext



Corba



CORBA (Common Object Request Broker Architecture)

server-side component model standard for distributed computing defined by members of the Object Management Group (OMG)

History started in 1991 (Corba 1.1) current version: Corba 3 (1999)

Design goals comprehensiveness interoperability infrastructure services as components



CORBA: key features implemented by various vendors central concept: ORB (object request broker)

provides location transparency provides platform, language independence

wire protocol IIOP (Internet inter-ORB protocol) interface definition in OMG IDL

bindings for many languages exist produces proxy pattern

spezialized Corba real-time CORBA, minimal CORBA for embedded systems fault-tolerant CORBA.



Corba: Object Management Architecture

Non-standardizedapplication-specific interfaces

Application Objects

Domain Objects

Vertical domain-specific interfaces

CORBAFacilities

Horizontal facilityinterfaces

CORBAServices

General service interfaces

Object Request Broker (ORB)

Transportation andCommunication

Corba is based on the Object Management Architecture (OMA)reference model:



Corba: infrastructure - Corba services

Collection Service Concurrency Service Event Service Externalization Service Licensing Service Life Cycle Service Naming Service Notification Service Persistent Object Service Property Service Query Service

Relationship Service Security Service Time Service Trading Object Service Transaction Service



Corba: summary

oldest distribution standard, mature carefully designed architecture incorporates middleware experts’ experience OMG provides only specification, implementations must

be bought from various vendors contains all features, but is complex and slow

current trend: integration of Java and Corba (JavaCorba)



Part 5

Developing software with components -

some guidelines



Component documentation

Idea: building SW systems like HW systems ...

a11

a22

3a3

4a4

b1

b2

b3

b4

5

6

7

8

Vcc1

0

G ND

0

SoftwareCHIP

IBar

IFoo

IFoo2

… the rest of the analogy is often neglected:

Knowledge about the pinout (interface methods) is not enough, also needed are specifications of behavior tolerances dependencies environmental requirements application notes

Point: components are more than SW

Point: components are more than SW



“Three questions of software contracts” [Meyer]

What does it expect?

What does it maintain?

What does it guarantee?



Requirements for successful CBSE [Gartner]

Create components of appropriate scope

Make each component independent

Require minimum inputs

Check all inputs for validity

Design related components simultaneously

Adhere to one methodology and one component model

Validate the design early get early feedback from potential (re)users

Maintain the documentation

Create and maintain an inventory



Component granularity

wrapped (legacy) application

functional block

functional piece (e.g. control)

Small enough to learn easily, but large enough to be worth learning

reusability

reuse gain



Requirements for successful reuse [Gartner]

Inventory (something to reuse ...) Catalog/repository & search Reuse administrator and facilitator A&D methodology incorporates reuse and design for reuse Design standards ensure consistency Measurement of reuse effectiveness Quality assurance Incentives to encourage reuse



CBSE - reasons for failure [Gartner] “Between 1999 and 2003 under 30 percent of first-generation corporate component

investments will deliver the expected productivity improvements.”

Common component reuse mistakes: Undefinded goals of reuse Conflicts of purpose of components Uncertain future (business & technology) Inflexible components Turf wars Inadequate reuse infrastructure



Sources of components “Through 2002, components will be available from a wide variety of sources in an immature and exploding market with no dominant

leaders.” [Gartner]

“We expect the market [for prebuilt components] to grow from about $1.4 billion in 1997 to more than $8 billion in 2002” [Gartner]

SW-builder tool vendors modeling tool vendors open source community component standard groups component consortiums books web sites

www.openavenue.comwww.pparadise.comwww.qbssoftware.comwww.sourceforge.comwww.theorycenter.comwww.xtras.com...

java.sun.com/beans/marketing.htmlwww.alphaworks.ibm.comwww.cbop.gr.jpwww.componentsource.comwww.developer.comwww.flashline.comwww.devtools.de



Part 6

Problems and research issues



CBSE research and the SW life-cycle

AnalysisDesign

ImplementationTesting

Deployment

AnalysisDesign


Deployment

AnalysisDesign


Deployment

Quality Management

Project Management

ComponentsApplication

- assembly- finding - trusting - distribution- glue code

- design for customization/ variability- wrapping- specification/contracts

- development methods- notations- frameworks- storage

- documentation

- run-time infrastructures

- configuration management

- certification- SW development process

- team structure



Contracts and documentation

Are more than interface method definitions How to specify?

interfaces behavior (pre-/post conditions, invariants) dependencies (required interfaces) quality of service ???

How to test/verify component specifications? How to document component specifications? How to negotiate service levels between components at

runtime? How to automatically connect components in builder tools

using their specification? How to verifiy the correctness of a composite system? ...



Design for reuse

Design for reuse requires additional effort

What is the best level of reuse (component granularity)? How can the benefit of reuse be measured? Development and documentation of component usage

patterns



Repositories

are an enabling technology for CBSE

How to store components? How to classify and describe components? How to find components?

fast different aspects

interfaces functionality component model certification level previous usage, trust

multiobjective optimization negotiable requirements



Software development process

Current approachrequirements - analyse - design - implementation - test

CBSE approach must include reuse component selection component test requirements reconciliation component mining for reuse

CBSE must be supported by modeling formalisms and tools development tools



Organizational changes

New mind-set: create -> construct Allocate reuse management staff (repository, training) Accept short term productivity reduction Accept new business model: first use of a component

designed for reuse may not recover production cost More interdepartmental cooperation and trust necessary

“Through at least 2002, most IS organizations will be unable to achieve anticipated CBD payback due to factors such as undefined goals, conflicts of purpose, inflexibility in component design, domain scope or turf wars, and inadequate reuse infrastructure” [Gartner]



Developing a component market

Imperative feature for component success

Have to establish framework for …? legal aspects (licensing and warranties) technical abilities economic forces

Proven business case Repositories, precise descriptions and search engines Documentations and application support



Versioning and configuration management

Is more complex than usually (DLL hell) especially in dynamic environments

Dependencies and composition constraints have to be resolved almost automatically consider systems comprising thousands of components

How to do safe exchange of components e.g. upgrade, without contractual specification and proof?

All of the issues above are prerequisite for uploading and downloading of components



Security

Requires trust and certification complicated by large group of (small) vendors ‘mobile code security’ important

not user access control but code access control current mechanisms

sandboxing: restricted functionality, restricted availability codesigning: not necessarily suitable to establish trust

prove of problem origin difficulty of persecution



Component models for embedded systems

real-time requirements limited processing resources higher reliability requirement hot-swapping non-mainstream OSes definition of component (HW included?)



Problems and research issues

Contracts and documentation Design for reuse Repositories Software development process Organizational changes Developing a component market Versioning and configuration management Security Component models for embedded systems



Part 7

Information sources



Books

Ivar Jacobson, Martin Griss, Patrik Jonsson: Software Reuse : Architecture, Process, and Organization for Business Success (1997)

Desmond Francis D'Souza, Alan Cameron Wills: Objects, Components, and Frameworks With Uml : The Catalysis Approach (1998)

Clemens Szyperski: Component Software : Beyond Object-Oriented Programming: (1998)

Peter Herzum and Oliver Sims: Business Component Factory : A Comprehensive Overview of Component-Based Development for the Enterprise (1999)

Alan W. Brown: Large-Scale Component-Based Development (2000) Betrand Meyer: Object-Oriented Software Construction, 2nd Edition

(2000)



Journals

IEEE Computer IEEE Software IEEE Internet Computing IEEE Transactions on Software Engineering IEEE Transactions on Computers ACM Transactions on Programming Languages and Systems languages and

programming systems. ACM Transactions on Software Engineering and Methodology ACM Transactions on Computer Systems Software Development (www.sdmagazine.com) MSDN Magazine (msdn.microsoft.com/msdnmag) … all major SW development magazines



ConferencesScientific ACM Conference on Object-Oriented Programming, Systems, Languages, and

Applications (OOPSLA) (oopsla.acm.org) International Workshop on Component-Based Software Engineering

(www.sei.cmu.edu/cbs/cbse2000/index.html) International Workshop on Component-Oriented Programming (WCOP)

(ecoop2000.unice.fr) IEEE Symposium on Engineering of Computer-Based

Systems (ECBS) (www.dcs.napier.ac.uk/ecbs) Symposium on Generative and Component-Based Software Engineering (www-

stja.transit-online.de/gcse/) Technology of Object-Oriented Languages and Systems (TOOLS) (www.tools-

conferences.com) International Conference on Software Engineering (ICSE) International Workshop on Software Specification and Design (IWSSD)

(www.ics.uci.edu/IRUS/iwssd) International Conference on Software Reuse (ICSR)

Trade Component Computing (www.tieturi.fi/coco99) Component Developer's and User's Forum (CDUF) (www.componentdevelopment.com)



Others

http://www.cetus-links.org/

http://www.designbycontract.com/



Key researchersBertrand Meyer (Interactive Software Engineering; Monash University)

Eiffel, design-by-contract, trusted components http://www.sd.monash.edu.au/~bertrand/

Clemens Szyperski (Oberon Microsystems; Microsoft; QUT) Book: “Component Software” http://www.research.microsoft.com/users/cszypers/

Jan Bosch (University of Karlskrona/Ronneby) SW architecture, product lines http://www.ipd.hk-r.se/bosch/

Heinz Schmidt (Monash University) trusted components http://www.csse.monash.edu.au/~hws/

Kurt Wallnau (SEI/CMU) COTS-based systems http://www.sei.cmu.edu/staff/kcw/

Oscar Nierstrasz (Uni Bern) SW composition; coordination models http://www.iam.unibe.ch/~oscar/

Oliver Sims Business objects



Thanks!!

Slides and content of this tutorial have partly been stolen from Microsoft Sun OPC Foundation OMG O. Preiss, ABB CHCRC C. Zeidler, ABB DECRC various unidentifiable sources

abb corporate research industrial software systems, chcrc.c2, naedele /00-08-23 / 1 abb 2000 abb...

Documents

switzerland component

component sw sw

component software help

expensive component

component infrastructure

component sw help

concept of component

new component