See discussions, stats, and author profiles for this publication at: https://www.researchgate.

net/publication/2862410

Component-Based Software Engineering: Technologies, Development

Frameworks, and Quality Assurance Schemes

Article · July 2001

Source: CiteSeer

CITATIONS READS

70 1,065

4 authors, including:

Michael R. Lyu Kam-Fai Wong

The Chinese University of Hong Kong The Chinese University of Hong Kong
886 PUBLICATIONS 41,744 CITATIONS 374 PUBLICATIONS 8,073 CITATIONS

SEE PROFILE SEE PROFILE

All content following this page was uploaded by Michael R. Lyu on 20 November 2014.

The user has requested enhancement of the downloaded file.

 Component-Based Software Engineering:
Technologies, Development Frameworks, and Quality Assurance Schemes

Xia Cai, Michael R. Lyu, Kam-Fai Wong Roy Ko

The Chinese University of Hong Kong Hong Kong Productivity Council
{xcai@cse, lyu@cse, kfwong@se}.cuhk.edu.hk [email protected]

software architecture [12]. This new software

Abstract development approach is very different from the
traditional approach in which software systems can only
be implemented from scratch. These commercial off-the-
Component-based software development approach is shelf (COTS) components can be developed by different
based on the idea to develop software systems by selecting developers using different languages and different
appropriate off-the-shelf components and then to assemble platforms. This can be shown in Figure 1, where COTS
them with a well-defined software architecture. Because components can be checked out from a component
the new software development paradigm is much different repository, and assembled into a target software system.
from the traditional approach, quality assurance (QA) for
component-based software development is a new topic in
Component 1
the software engineering community.
In this paper, we survey current component-based Component
software technologies, describe their advantages and Component 2 Software
repository
disadvantages, and discuss the features they inherit. We system
also address QA issues for component-based software. As
...
a major contribution, we propose a QA model for
component-based software development, which covers
Component n
component requirement analysis, component development,
component certification, component customization, and
system architecture design, integration, testing, and select assemb le
maintenance.
Commercial Off-the-shelf (COTS)
components
Figure 1. Component-based software
1. Introduction development
Modern software systems become more and more Component-based software development (CBSD) can
large-scale, complex and uneasily controlled, resulting in significantly reduce development cost and time-to-market,
high development cost, low productivity, unmanageable and improve maintainability, reliability and overall quality
software quality and high risk to move to new technology of software systems [13] [14]. This approach has raised a
[15]. Consequently, there is a growing demand of tremendous amount of interests both in the research
searching for a new, efficient, and cost-effective software community and in the software industry. The life cycle
development paradigm. and software engineering model of CBSD is much
One of the most promising solutions today is the different from that of the traditional ones. This is what the
component-based software development approach. This Component-Based Software Engineering (CBSE) is
approach is based on the idea that software systems can be focused.
developed by selecting appropriate off-the-shelf Up to now, software component technologies are an
components and then assembling them with a well-defined emerging technology, which is far from being matured.
There is no existing standards or guidelines in this new make it possible for their related languages, such as Visual
area, and we do not even have a unified definition of the Basic, C++, Java, and the supporting tools to share and
key item “component”. In general, however, a component distribute application pieces. But all of these approaches
has three main features: 1) a component is an independent rely on certain underlying services to provide the
and replaceable part of a system that fulfills a clear communication and coordination necessary for the
function; 2) a component works in the context of a well- application. The infrastructure of components (sometimes
defined architecture; and 3) a component communicates called a component model) acts as the "plumbing" that
with other components by its interfaces [1]. allows communication among components [1]. Among the
component infrastructure technologies that have been
To ensure that a component-based software system can
developed, three have become somewhat standardized:
run properly and effectively, the system architecture is the
OMG's CORBA, Microsoft's Component Object Model
most important factor. According to both research
(COM) and Distributed COM (DCOM), and Sun's
community [2] and industry practice [5], the system
JavaBeans and Enterprise JavaBeans [7].
architecture of component-based software systems should
be a layered and modular architecture. This architecture
2.1 Common Object Request Broker Architecture
(CORBA)
CORBA is an open standard for application
Application
App2 App3 Layer interoperability that is defined and supported by the
App1 Object Management Group (OMG), an organization of
over 400 software vendor and object technology user
Special business components companies [11]. Simply stated, CORBA manages details
Components
Layer of component interoperability, and allows applications to
Common components communicate with one another despite of different
locations and designers . The interface is the only way that
Basic components applications or components communicate with each other.
can be seen in Figure 2. The top application The most important part of a CORBA system is the
Figure 2. System architecture of component-based Object Request Broker (ORB). The ORB is the
software systems middleware that establishes the client-server relationships
between components. Using an ORB, a client can invoke a
layer is the application systems supporting a business. The
method on a server object, whose location is completely
second layer consists of components engaged in only a transparent. The ORB is responsible for intercepting a call
specific business or application domain, including and finding an object that can implement the request, pass
components usable in more than a single application. The
its parameters, invoke its method, and return the results.
third layer is cross-business middleware components The client does not need to know where the object is
consisting of common software and interfaces to other located, its programming language, its operating system,
established entities. Finally, the lowest layer of system
or any other system aspects that are not related to the
software components includes basic components that interface. In this way, the ORB provides interoperability
interface with the underlying operating systems and among applications on different machines in
hardware.
heterogeneous distributed environments and seamlessly
Current component technologies have been used to interconnects multiple object systems.
implement different software systems, such as object- CORBA is widely used in Object-Oriented distributed
oriented distributed component software [23] and Web-
systems [23] including component-based software systems
based enterprise application [13]. There are also some because it offers a consistent distributed programming and
commercial players involved in the software component run-time environment over common programming
revolution, such as BEA, Microsoft, IBM and Sun [7]. An
languages, operating systems, and distributed networks.
outstanding example is the IBM SanFrancisco project. It
provides a reusable distributed object infrastructure and an
2.2 Component Object Model (COM) and
abundant set of application components to application
developers [5].
Distributed COM (DCOM)
Introduced in 1993, Component Object Model (COM)
2. Current Component Technologies is a general architecture for component software [9]. It
provides platform-dependent, based on Windows and
Some approaches, such as Visual Basic Controls Windows NT, and language-independent component-
(VBX), ActiveX controls, class libraries, and JavaBeans, based applications.
 COM defines how components and their clients Software Systems
interact. This interaction is defined such that the client and
the component can connect without the need of any 3.1 The Life Cycle of Component-Based Software
intermediate system component. Specially, COM provides
a binary standard that components and their clients must
Systems
follow to ensure dynamic interoperability. This enables Component-based software systems are developed by
on-line software update and cross-language software reuse selecting various components and assembling them
[20]. together rather than programming an overall system from
As an extension of the Component Object Model scratch, thus the life cycle of component-based software
(COM), Distributed COM (DCOM), is a protocol that systems is different from that of the traditional software
enables software components to communicate directly systems. The life cycle of component-based software
over a network in a reliable, secure, and efficient manner. systems can be summarized as follows [12]: 1)
DCOM is designed for use across multiple network Requirements analysis; 2) Software architecture selection,
transports, including Internet protocols such as HTTP. construction, analysis, and evaluation; 3) Component
When a client and its component reside on different identification and customization; 4) System integration; 4)
machines, DCOM simply replaces the local interprocess System testing; 5) Software maintenance.
communication with a network protocol. Neither the client The architecture of software defines a system in terms
nor the component is aware the changes of the physical of computational components and interactions among the
connections. components. The focus is on composing and assembling
components that are likely to have been developed
2.3 Sun Microsystems’s JavaBeans and separately, and even independently. Component
Enterprise JavaBeans identification, customization and integration is a crucial
activity in the life cycle of component-based systems. It
Sun’s Java-based component model consists of two includes two main parts: 1) evaluation of each candidate
parts: the JavaBeans for client-side component COTS component based on the functional and quality
development and the Enterprise JavaBeans (EJB) for the requirements that will be used to assess that component;
server-side component development. The JavaBeans
and 2) customization of those candidate COTS
component architecture supports applications of multiple components that should be modified before being
platforms, as well as reusable, client-side and server-side integrated into new component-based software systems.
components [19].
Integration is to make key decisions on how to provide
Java platform offers an efficient solution to the communication and coordination among various
portability and security problems through the use of components of a target software system.
portable Java bytecodes and the concept of trusted and
Quality assurance for component-based software
untrusted Java applets. Java provides a universal systems should address the life cycle and its key activities
integration and enabling technology for enterprise to analyze the components and achieve high quality
application development, including 1) interoperating
component-based software systems. QA technologies for
across multivendor servers; 2) propagating transaction component-based software systems are currently
and security contexts; 3) servicing multilingual clients; premature, as the specific characteristics of component
and 4) supporting ActiveX via DCOM/CORBA bridges.
systems differ from those of traditional systems. Although
JavaBeans and EJB extend all native strengths of Java some QA techniques such as reliability analysis model for
including portability and security into the area of distributed software systems [21] [22] and component-
component-based development. The portability, security, based approach to Software Engineering [10] have been
and reliability of Java are well suited for developing studied, there is still no clear and well-defined standards
robust server objects independent of operating systems, or guidelines for component-based software systems. The
Web servers and database management servers. identification of the QA characteristics, along with the
models, tools and metrics, are all under urgent needs.
2.4 Comparison among Current Component
Technologies 3.2 Quality Characteristics of Components
Comparison among current component technologies As much work is yet to be done for component-based
can be found in [Brow98], [Pour99a] and [Szyp98]. Here software development, QA technologies for component-
we simply summarize these different features in Table 1. based software development has to address the two
inseparable parts: 1) How to certify quality of a
3. Quality Assurance for Component-Based component? 2) How to certify quality of software
 CORBA EJB COM/DCOM
Development Supported by a wide range
environment Underdeveloped Emerging of strong development
environments
Binary Not binary standards Based on COM; A binary standard for
interfacing Java specific component interaction is the
standard heart of COM
Compatibility Particularly strong in Portable by Java language Not having any concept of
& portability standardizing language specification; but not very source-level standard of
bindings; but not so compatible. standard language binding.
portable
Modification & CORBA IDL for defining Not involving IDL files, Microsoft IDL for defining
maintenance component interfaces, need defining interfaces between component interfaces, need
extra modification & component and container. extra modification &
maintenance Easier modification & maintenance
maintenance.
Services A full set of standardized Neither standardized nor Recently supplemented by a
provided services; lack of implemented number of key services
implementations
Platform Platform independent Platform independent Platform dependent
dependency
Language Language independent Language dependent Language independent
dependency
Strongest for traditional Strongest on general Web Strongest on the traditional
Implementation enterprise computing clients. desktop applications
Table 1. Comparison of current component technologies

while a too-complex component is hard to inherit

systems based on components? To answer the questions,
high quality.
models should be promoted to define the overall quality
control of components and systems; metrics should be 3) Reuse frequency. The number of incidences where a
found to measure the size, complexity, reusability and component is used is a solid indicator of its
reliability of components and systems; and tools should usefulness.
be decided to test the existing components and systems.
4) Reliability. The probability of failure-free
To evaluate a component, we must determine how to operations of a component under certain operational
certify the quality of the component. The quality scenarios [8].
characteristics of components are the foundation to
guarantee the quality of the components, and thus the 4. A Quality Assurance Model for
foundation to guarantee the quality of the whole Component-Based Software Systems
component-based software systems. Here we suggest a
list of recommended characteristics for the quality of Because component-based software systems are
components: 1) Functionality; 2) Interface; 3) Usability; developed on an underlying process different from that of
4) Testability; 5) Maintainability; 6) Reliability. the traditional software, their quality assurance model
should address both the process of components and the
Software metrics can be proposed to measure software process of the overall system. Figure 3 illustrates this
complexity and assure its quality [16] [17]. Such metrics view.
often used to classify components include [6]:
Many standards and guidelines are used to control the
1) Size. This affects both reuse cost and quality. If it is quality activities of software development process, such
too small, the benefits will not exceed the cost of as ISO9001 and CMM model. In particular, Hong Kong
managing it. If it is too large, it is hard to have high productivity Council has developed the HKSQA model to
quality. localize the general SQA models [4]. In this section, we
2) Complexity. This also affects reuse cost and quality. propose a framework of quality assurance model for the
A too-trivial component is not profitable to reuse component-based software development paradigm. The
 Initiators (Users, Customers,
Manager etc.)
System
Component Request for new development
or change
Format &
Requirement Requirements
Structure
Document Gathering and
Quality Template Definition
Assurance Current
Draft User Requirement
URD
Model Documentation (URD)
Requirement
Analysis

Component Requirement
Document (CRD)
Structure for
Figure 3. Quality assurance model for both Data naming & Component
components and systems Dictionary Describing Modeling

Updated CRD with

model included
System
Requirement Component
main practices relating to components and systems in Maintenance
Validation Current URD Development
User Requirement
this model contain the following phases: 1) Component Changes

requirement analysis; 2) Component development; 3)

Component certification; 4) Component customization; 5) Figure 4. Component requirement analysis
System architecture design; 6) System integration; 7) process overview
System testing; and 8) System maintenance.
Details of these phases and their activities are interfaces.
described as follows. The component development process overview
diagram is as shown in Figure 5. Component
4.1 Component Requirement Analysis development consists of four procedures:
Component requirement analysis is the process of implementation, function testing, reliability testing, and
discovering, understanding, documenting, validating and development document. The input to this phase is the
managing the requirements for a component. The component requirement document. The output should be
objectives of component requirement analysis are to the developed component and its documents, ready for
produce complete, consistent and relevant requirements the following phases of component certification and
that a component should realize, as well as the system maintenance, respectively.
programming language, the platform and the interfaces
related to the component. Developers

The component requirement process overview Techniques required

diagram is as shown in Figure 4. Initiated by the request

Component Requirements
of users or customers for new development or changes on Requirement Implementation

Document
old system, component requirement analysis consists of Existing
Draft Component
Fault
four main steps: requirements gathering and definition,
Self-Testing
requirement analysis, component modeling, and (Function)

requirement validation. The output of this phase is the Well-Functional Component

current user requirement documentation, which should be

Self-Testing
transferred to the next component development phase, ( Reliability)
and the user requirement changes for the system Reliable Component
maintenance phase. System
Development Component
Maintenance
Document Submit Certification
For Reference

4.2 Component Development

Component development is the process of
implementing the requirements for a well-functional, high Figure 5. Component development process
quality component with multiple interfaces. The overview
objectives of component development are the final
component products, the interfaces, and development 4.3 Component Certification
documents. Component development should lead to the
final components satisfying the requirements with correct Component certification is the process that involves:
and expected results, well-defined behaviors, and flexible 1) component outsourcing: managing a component
outsourcing contract and auditing the contractor
performance; 2) component selection: selecting the right requirements with other components in which the
components in accordance to the requirement for both components should work. The component customization
functionality and reliability; and 3) component testing: process overview diagram is as shown in Figure 7. The
confirm the component satisfies the requirement with input to component customization is the system
acceptable quality and reliability. requirement, the component requirement, and component
development document. The output should be the
The objectives of component certification are to
customized component and document for system
outsource, select and test the candidate components and
integration and system maintenance.
check whether they satisfy the system requirement with
high quality and reliability. The governing policies are: 1)
System Requirements & Other
Component outsourcing should be charged by a software Component Requirements

contract manager; 2) All candidate components should be Specific System & Other
Component Requirements
tested to be free from all known defects; and 3) Testing Component
Component
Document Component
should be in the target environment or a simulated Development
Customization
Document
environment. The component certification process Reject
Component Changed

overview diagram is as shown in Figure 6. The input to

Component
this phase should be component development document, Document

and the output should be testing documentation for New Component Document

system maintenance.
Component
Testing

System Requirements Component fit for the special

requirements

Specific Component System Acceptance System

Requirements Integration Assemble Component Maintenance
Component Document on
Component Functions Component
Development
Outsourcing
Document
Reject
Component Released

Component Figure 7. Component customization process

Testing
overview
Well-Functional Component

Component
Selecting
4.5 System Architecture Design
Component fit for the special
requirements System architecture design is the process of
Acceptance System evaluating, selecting and creating software architecture of
Contract Signoffs, Maintenance
Payments a component-based system.
The objectives of system architecture design are to
collect the users requirement, identify the system
Figure 6. Component certification process specification, select appropriate system architecture, and
overview determine the implementation details such as platform,
programming languages, etc.
4.4 Component Customization
System architecture design should address the
Component customization is the process that involves advantage for selecting a particular architecture from
1) modifying the component for the specific requirement; other architectures. The process overview diagram is as
2) doing necessary changes to run the component on shown in Figure 8. This phase consists of system
special platform; 3) upgrading the specific component to requirement gathering, analysis, system architecture
get a better performance or a higher quality. design, and system specification. The output of this phase
should be the system specification document for
The objectives of component customization are to
integration, and system requirement for the system testing
make necessary changes for a developed component so
phase and system maintenance phase.
that it can be used in a specific environment or cooperate
with other components well.
4.6 System Integration
All components must be customized according to the
operational system requirements or the interface
 System testing is the process of evaluating a system
to: 1) confirm that the system satisfies the specified
Initiators
requirements; 2) identify and correct defects in the
Requests for New Systems system implementation.
Format &
Requirement
Document
Structure System Requirement The objective of system testing is the final system
Gathering
Template
Current
integrated by components selected in accordance to the
Draft System Requirements
Document
Document system requirements. System testing should contain
System Requirement function testing and reliability testing. The process
Analysis
overview diagram is as shown in Figure 10. This phase
System Requirement Document
consists of selecting testing strategy, system testing, user
System Architecture acceptance testing, and completion activities. The input
Design System
Maintenance should be the documents from component development
System Architecure
and system integration phases. And the output should be
System System System the testing documentation for system maintenance.
Testing System Specification System Specification Integration
Requirement Document

System Design
Document

Figure 8. System architecture design process System

Testing Requirements

overview Maintenance Test

Testing
(Previous Dependencies
Software Life Strategy

System integration is the process of assembling Cycle)

System Testing Plan
components selected into a whole system under the System Test Component
Spec. Document
designed system architecture. System
Integration
System
Testing
Component
Development

The objective of system integration is the final system System Tested

composed by the selected components. The process User Acceptance

Test Spec.
Component
Document
User Acceptance
overview diagram is as shown in Figure 9. The input is Testing

the system requirement documentation and the specific User Accepted System

architecture. There are four steps in this phase: Test Completion System

integration, testing, changing component and re- Activities System Integration

Document
Maintenance

integration (if necessary). After exiting this phase, we

will get the final system ready for the system testing
phase, and the document for the system maintenance
phase. Figure 10. System testing process overview

System
Requirement 4.8 System Maintenance
Requirements for New
Systems System maintenance is the process of providing
System Architecture System
Architecture Integration service and maintenance activities needed to use the
Current software effectively after it has been delivered.
Component Draft System

Self-Testing
The objectives of system maintenance are to provide
an effective product or service to the end-users while
Fault Component correcting faults, improving software performance or
Component
Component
Requirement
Component
other attributes, and adapting the system to a changed
Changing Certification environment.
Selecting New Component
There shall be a maintenance organization for every
System Final System
Testing Final System System System Integration Maintenance
software product in the operational use. All changes for
Document the delivered system should be reflected in the related
documents. The process overview diagram is as shown in
Figure 11. According to the outputs from all previous
phases as well as request and problem reports from users,
Figure 9. System integration process overview system maintenance should be held for determining
support strategy and problem management (e.g.,
4.7 System Testing
 identification and approval). As the output of this phase, [8] M.R.Lyu (ed.), Handbook of Software Reliability
a new version can be produced for system testing phase Engineering, McGraw-Hill, New York, 1996.
for a new life cycle. [9] Microsoft:http://www.microsoft.com/isapi, Mar, 2000.
[10] J.Q. Ning, K. Miriyala, W. Kozaczynski,, “An
Architecture-Driven, Business-Specific, and Component-
Based Approach to Software Engineering,” Proceedings
5. Conclusion and Future Work Third International Conference on Software Reuse: Advances
in Software Reusability, 1994, pp. 84 -93.
Users
[11] OMG: http://www.omg.org/corba/whatiscorba.html,
Request and Problem Reports
Mar, 2000.
Documents,
[12] G. Pour, “Component-Based Software Development
All Previous Support
Phases
Strategies
Strategy
Approach: New Opportunities and Challenges,” Proceedings
Technology of Object-Oriented Languages, 1998. TOOLS
User Support Agreement 26., pp. 375-383.
Problem [13] G. Pour, “Enterprise JavaBeans, JavaBeans & XML
Management
Expanding the Possibilities for Web-Based Enterprise
Change Requests Application Development,” Proceedings Technology of
Object-Oriented Languages and Systems, 1999, TOOLS 31,
System New Version System
Maintenance Testing pp.282-291.
[14] G.Pour, M. Griss, J. Favaro, “Making the Transition to
Component-Based Enterprise Software Development:
Figure 11. System maintenance process
Overcoming the Obstacles – Patterns for Success,”
overview Proceedings of Technology of Object-Oriented Languages
and systems, 1999, pp.419 – 419.
[15] G.Pour, “Software Component Technologies: JavaBeans
and ActiveX,” Proceedings of Technology of Object-Oriented
In this paper, we survey current component-based Languages and systems, 1999, pp. 398 – 398.
software technologies and the features they inherit. We [16] C. Rajaraman, M.R. Lyu,"Reliability and Maintainability
propose a QA model for component-based software Related Software Coupling Metrics in C++ Programs,"
development, which covers both the component QA and Proceedings 3rd IEEE International Symposium on Software
the system QA as well as their interactions. As our future Reliability Engineering (ISSRE'92), 1992, pp. 303-311.
work we will apply the QA model to real world projects [17] C. Rajaraman, M.R. Lyu, "Some Coupling Measures for
C++ Programs," Proceedings TOOLS USA 92 Conference,
so that it can actually guide the practices of component-
August 1992, pp. 225-234.
based software development.
[18] C.Szyperski, "Component Software: Beyond Object-
Oriented Programming," Addison-Wesley, New York, 1998.
[19] SUN http://developer.java.sun.com/developer,Mar. 2000
[20] Y.M.Wang, O.P.Damani, W.J. Lee, “Reliability and
References Availability Issues in Distributed Component Ojbect Model
(DCOM),” Fourth International Workshop on Community
[1] A.W.Brown, K.C. Wallnau, “The Current State of CBSE,”
Networking Proceedings, 1997, pp. 59 –63.
IEEE Software , Volume: 15 5, Sept.-Oct. 1998, pp. 37 – 46. [21] S.M. Yacoub, B. Cukic, H.H. Ammar, “A Component-
[2] M. L. Griss, “Software Reuse Architecture, Process, and Based Approach to Reliability Analysis of Distributed
Organization for Business Success,” Proceedings of the
Systems,” Proceedings of the 18th IEEE Symposium on
Eighth Israeli Conference on Computer Systems and
Reliable Distributed Systems, 1999, pp. 158 –167.
Software Engineering, 1997, pp. 86-98.
[22] S.M.Yacoub, B. Cukic, H.H.Ammar, “A Scenario-Based
[3] P.Herzum, O.Slims, "Business Component Factory - A Reliability Analysis of Component-Based Software,”
Comprehensive Overview of Component-Based Development Proceedings 10th International Symposium on Software
for the Enterprise," OMG Press, 2000.
Reliability Engineering, 1999, pp. 22 –31.
[4] Hong Kong Productivity Council,
[23] S.S.Yau, B. Xia, “Object-Oriented Distributed
http://www.hkpc.org/itd/servic11.htm, April, 2000.
Component Software Development based on CORBA,”
[5] IBM:http://www4.ibm.com/software/ad/sanfrancisco, Proceedings of COMPSAC’98. The Twenty-Second Annual
Mar, 2000. International, 1998, pp. 246-251.
[6] I.Jacobson, M. Christerson, P.Jonsson, G. Overgaard,
"Object-Oriented Software Engineering: A Use Case Driven
Approach," Addison-Wesley Publishing Company, 1992.
[7] W. Kozaczynski, G. Booch, “Component-Based Software
Engineering,” IEEE Software Volume: 155, Sept.-Oct. 1998,
pp. 34–36.

View publication stats