rect rect rect rect rect rect rect
You are viewing an archived version of CBSE 1999. This page has been archived via the Internet Archive Wayback Machine for the ICSA conference series history. Some links on this page might not work.
← return to the ICSA homepage.
General Navigation Buttons - Home | Search | Contact Us | Site Map | Whats New
engineering graphic
white space
engineering
Welcome
Architecture Tradeoff Analysis
CERT Coordination Center
COTS-Based Systems
Overview
Activity Areas
Products and Services
CBS Team
References
Events
Opportunities to work with us
Briefings, Courses, and Workshops
CURE (COTS Usage Risk Evaluation)
TIDE
Spiral workshops
COTS-Based Systems Monographs
COTS_Spot Column
Little Red Book
Performance - Critical Systems
Information Repositories
Team & Personal Software Process
Product Line Practice
Software Engineering Measurement & Analysis (SEMA)
Complete Technical Project List
Common Acronyms
Technical Initiatives
Conferences
Education & Training
white space
About SEI|Mgt|Eng|Acq|Collaboration|Prod.& Services|Pubs
pixel
Rollover Popup Hints for Topic Navigation Buttons above
pixel
Introduction


Next: CBSE Framework Previous: Issues in Component-Based

Introduction

Software reuse is generally considered as one of the most effective ways of increasing productivity and improving quality of software. To make software reuse happen, however, there should be a change in the way we develop software: software must be developed for reuse and with reuse, and there must be a paradigm shift from the notion of specific application "development" to that of "integration." Component-based software engineering (CBSE)[3] is an emerging software engineering paradigm in which applications are developed by integrating existing components. Here, components refer to any units of reuse or integration, including computational (i.e., functional) components, interface components, communication components, and architectures.

In order to maximize the productivity gain and cost reduction, CBSE must be based on domain-oriented components as well as generic components. In general, the productivity increase from the reuse of domain-oriented components is higher than the productivity increase from the reuse of generic components, although reusability of domain-oriented components might be lower than that of generic components. Therefore, CBSE should happen in the context of domain-orientation. SAP R/3 [7], Baan IV [1], and Oracle Applications [6] are good examples of domain-oriented CBSE.

Domain-oriented CBSE is not for any application domains. In immature and unstable domains, there may not be much domain-oriented components to reuse and CBSE may be limited to the reuse of generic components. Therefore, CBSE should be applied in mature and stable application domains, or in an organization where a family of closely related products is produced.

To develop an application by integrating components, there must be components that can solve the problems of the given application. Therefore, CBSE must address not only the issues of how to integrate components but also the issues of how to produce integratable components. CBSE can only be successful when the issues of both producer's and consumer's are resolved.

In section 2, a CBSE framework is presented in which major activities of both producing and using components are identified. Section 3 summarizes some of the important component engineering principles. Some of non-technical but important issues underlying CBSE are discussed in section 4. Section 5 concludes this position paper.



Next: CBSE Framework Previous: Issues in Component-Based


Tue Apr 13 16:40:22 KST 1999
 

 

 

 

download the PDF file
contact the organizers


The Software Engineering Institute (SEI) is a federally funded research and development center sponsored by the U.S. Department of Defense and operated by Carnegie Mellon University.

Copyright 2004 by Carnegie Mellon University
URL: http://www.sei.cmu.edu/papers/43/node1.html
Last Modified: 10 March 2003