CSEE Department

This paper discusses the problem of characterizing a software component, which is essential to understand what components are and how they can be classified. First, we classify what should be characterized about a component into three categories: Informal Descriptions, Internals, and Externals. Then, using this classification, we derive a set of features to characterize a software component.

Introduction

CBSE is emerging as a beneficial software development paradigm because it delivers on many of the promises of software reuse.  Many would refer to components as Javabeans, CORBA or DCOM objects [12, 4], other would refer to components as fragments of source code or a functional procedure. Several definitions of a software component have emerged. A component can be considered an independent replaceable part of the application that provides a clear distinct function [1]. A software component is a unit of composition, with pre-defined dependencies on other components [13]. Business components represent reusable conceptual artifacts that can be implemented and deployed in large business systems. A component can be a coherent package of software that can be independently developed and delivered as a unit, and that offers interfaces by which it can be connected, unchanged, with other components to compose a larger system[6].

Brown and Wallnau acknowledge in their workshop summary [1] the multitude of definitions of software components and further analyze the variances in terms of granularity, context-dependencies, and autonomy.  Our position paper seeks to build on this analysis by proposing an orthogonal set of features that we submit as means to characterize a component for CBSE purposes. Han [15] proposed an object-oriented characterization of components, here we envisage that characterization of components could be further abstracted beyond object oriented definitions and include non-technical features as well.

This paper proposes a set of features to characterize a software component. This set is by no means exhaustive, and shall further mature based on peer discussions in the workshop. Given those features we can understand what are the different types of components, how they are involved in the development lifecycle, how they are reused, and what technologies are required to adopt a component in an application development.

Characterizing a Software Component

We distinguish what needs to be characterized about a component under three main categories: the Informal Description, Externals, and Internals. For each of those sections we define a set of features to characterize a component.

A) Informal Description

This section describes the component human-related issues. Components can be considered as mentally-driven building blocks of applications and hence they should be preserved as solution prescriptions to application development problems. This section would encompass the following characteristics:

1. Age
This is a characteristic of a component that reflects its stability and maturity. When a component is first introduced, there is a high risk associated with its usage. After several instances of usage, the component becomes more mature and hence the reuse risk decreases. This property is adopted in design patterns (or in the pattern community), the rule-of-three establishes the maturity of a pattern by defining three instances in which the pattern was instantiated.

2. Source
Components can be characterized by the source supplying the component, for example, Commercial Off the-Shelf (COTS), Military Off the-Shelf (MOTS), or Government Off the-Shelf (GOTS)

3. Level of Reuse
A component can be reusable at different phases of the development life cycle. The nature of the components plays an important role in determining where in the development phase is the component reusable. For example, a fragment of code is used during development, a Dynamic Link Library (DLL) is reused during run-time, and a static library is reused during integrating the application.

4. Context
The situations in which the component can be used. It is usually a difficult task to determine all situations, general and specific ones, for a component usage. Target domains and applications should be considered when characterizing the context for a component.

5. Intent
This characterizes the purpose for which this component is documented. This includes the problem (or set of problems) that the component solves (or participates in solving).

6. Related Component
This feature defines other well-known components that solve the same (or similar) problems.

B) Externals

Component external define its interactions with other application artifacts and with the platform on which the component resides. This section would encompass the following characteristics:

1. Interoperability
Interoperability characterizes Application Interfaces, i.e. how the component interacts with other components in the same system. A component should be interoperable because it lives with other components in an application environment. The interoperability property necessitates a clear interface definition. This property determines how to call/invoke a component and the interaction direction (Client/Server). We must be able to integrate components with each other and with legacy software to achieve application functionality. Components should be developed as independent as possible from other components, however, it is not usually the case because they are only meaningful in a given interaction context (interaction with other components). The autonomy of a component describes how independent are the components from each other (somehow a measure of de-coupling) which also characterizes the self-containment of the component.

2. Portability
Portability characterizes Platform Interfaces, i.e. how the component interact with the underlying platform(Hardware, operating system, communication subsystem, etc. ). It is the property of a component that specifies which platform the component runs on and how it can be ported to other platforms. For code components, it is necessary to specify the necessary language compiler. For executable components and link libraries it is essential to indicate the underlying operating system.

3. Role
A component is characterized by its role that identifies what it provides to (requires from) other application artifacts. There are two roles that can be played by a component:

• Active Role: Affect and is affected by other artifacts. ex: GUI
• Passive Role: Affected by/invoked by other artifacts. ex: Databases.

This characterization is essential in determining which component is in control of execution at a given instance of time, a characteristic that helps solving control issues as discussed by Garlan et. al.[8]

4. Integration Phase
This characterizes when a component is integrated to the application. A component can be integrated at the development phase or at run-time. In the development phase it is inserted in the application and compiled to produce the binary executable form of the application. At run-time, components can be loaded and unloaded from the application allowing a on-line replacement.

5. Integration Frameworks
Components are integrated together to form applications, sometimes components do not directly interact with one another but they interact through an underlying framework that virtually connect components with each other [examples 12, 4]. A component should be characterized by identifying the underlying framework on which it runs.

6. Technology
This characterizes the technology on which the component is dependent and the restrictions on the technology for developing the component and for reusing it in other applications. A specification component can be considered technology independent. A general-purpose design pattern as those in [7] are object-oriented technology dependent. Dependability on technology is further discussed in [10]

7. Non Functional Features
Sometime it is essential to denote the non-functional aspects[called ilities in 16] of a component specifically for mission-critical domains. Such characterization would include: the component security assumptions (access control, authentication), performance issues (processor requirements and run time requirements), and component reliability.

C) Internals

This section reflects the internal aspects of a component which encompass the following characteristics

1. Nature
The nature of a component determines where the component can be used in the development process. A component can abstract a function, data, package, cluster and system abstraction or a system structure [11]. A component can be a class, a fragment of code, a fragment of design, an executable module, a run time link library (Dynamic link libraries ex. DLLs), a static library, etc.. In general, we classify them components according to their nature as:

• Design Components: A component can be a design principle or idea. Design patterns like Observers, Strategy and others[7] can in fact be used as design building blocks in constructing object oriented frameworks [14].
• Specification Component: A specification can be considered a reusable component. Specifying the expected functionality and behavior of a component frees the developer to implement this component in a variety of programming languages. An example of using specifications as components was illustrated in [9].
• Executables: Executable components can be static libraries, dynamic link libraries (DLLs or VBXs), or executable pieces of an application. Many literatures refer to components of this nature. Usually the source code of those components is not available, and the executable components themselves are commercially available. Most vendors provide (sell) an executable component yet keep the design and implementation code as a proprietary product.
• Code: Components can also be code that has been tested and executed in other projects. In many cases, these components will be an in-house library of assets of code that have been used in other applications in the same domain or within the same organization.

The following table shows the development phases and the nature of the components used in each phase. The dependencies on platform, technology, implementation and specification languages are tabulated in each phase.

Table 1 Nature of a Component

2. Granularity
Digre [5] proposed a possible characterization of components granularity from the business perspective. He classified components as enterprise, domain subsystem, domain object and semantic primitives. Other granularity classification can be based on the size of a component or the phase in which they can be reused.

3. Encapsulation (Decision Hiding)
A non-trivial component should hide (encapsulate) one or more decisions. The decision can be a design decision (design component), an implementation decision (executable component), or a specification decision. A software component should have a significant aggregate functionality and complexity [2]

4. Structural Aspect
The component structure describes the internal participants of the component and how they collaborate. For example, a simple component in object oriented technology can be viewed as a class. For example, a larger grained component such as a design pattern is a macro-component [3] that has the structure of collaborating classes and objects.

5. Behavioral Aspect
The component behavior should characterize two aspects: stateless behavior (the component response to specific set of inputs), and retrospective behavior (the component response to sequence of actions, i.e. components with state)

6. Accessibility to Source Code
Many researchers advocate that components should not be modified because they lose a percentage of trust that was established by the component provider. However, the availability of the component source code is sometimes essential for verification and testing the component at the customer side (the party acquiring the component). The availability of source code determines the accessibility and modifiability of the component. How to use a component and the form of reuse also depend on what is available of the component, usually the question regarding availability of the code is an issue of concern. The following table shows possible reuse component nature and reuse methods depending on availability of code and possibility of modifications.

Table 2 How to use a component depending on the availability and modifiability of source code

Impacts of characterizing a software component

• Better Cataloguing: Understanding the characteristics of a component plays a major role in documenting, cataloging, and classifying the wide literature of available components.
• Better Usage: Understanding the characteristics and properties of a specific component means better usage and ensures usage of the correct component in particular application development.
• Better Retrieval from component libraries: Characterizing components could facilitate selection, acquiring, and acquaintance of components.
• Better Understanding of architecture problems: Identifying characteristics of components helps in solving architecture mismatch problems such as the nature of the component and its control mode [8].

References

[1] Brown, W., and K. Wallnau "The Current State of CBSE", IEEE Software, October 1998, pp37-46

[2] Brown, A., and K. Wallnau, "Engineering of Component-Bases Systems" in Component Based Software Engineering, Alan W. Brown (edt.) Software Engineering Institute, IEEE Computer Society, 1996

[3] Castellani, X., and S. Y. Liao, "Development Process for the Creation and Reuse of Object-Oriented Generic Applications and Components", Journal of Object Oriented Programming, June 1998, Vol 11, No.3, pp24-31

[4] Component Object Model home page http://www.microsoft.com/com/dcom.asp

[5] Digre, T.,"Business Object Component Architecture" IEEE Computer, Sept/Oct 1998, pp60-69

[6] D'Souza, D. F., and Alan C. Wills "Objects, Components, and Frameworks with UML : The Catalysis Approach" , ISBN 0-201-31012-0 Addison-Wesley, 1998

[7] Gamma, E., R. Helm, R. Johnson, and J. Vlissides, "Design Patterns: Elements of Object-Oriented Software," Addison-Wesley, 1995.

[8] Garlan, D., R. Allen, and J. Ockerbloom, "Architecture Mismatch or Why it’s Hard to Build Systems out of Existing Parts," Proc. 17th International Conference on Software Engineering, IEEE Computer Society Press, Los Alamitos, Ca., April 1995, pp179-185

[9] Iglesias, A., and J. Justo, "Building System Requirements with Specification Components", Proc. of Joint conference of Information and Computer Science, JICS'98 , Vol III, pp499-502, Oct. 1998

[10] Kroeker, K., "Component Technology", IEEE Computer, Vol 31,132-133, Jan 1998.

[11] Meyer, B. , "On To Components", IEEE Computer , Jan 1999, pp139-140

[12] OMG, Corba 2.0/IIOP Specification, OMG Formal/97-09-01, Sept. 1997, http://www.omg.org/corba/corbiiop.htm [Note: Because this document or Web site is no longer available online, the link to it was removed from this file.]

[13] Szyperski, C., "Component Software: Beyond Object Oriented Programming", Addison Wesley Longman, 1998

[14] Yacoub, S., and H. Ammar, "Towards Pattern Oriented Frameworks", To appear in Journal of Object Oriented Programming JOOP, 1999

[15] Han, J., "Characterization of Components", First Int'l Workshop on Component-Based Software Engineering, in conjunction with ICSE'98, Kyoto, 1998

[16] Thompson, C.,"System Wide Properties or Ilities" Workshop on Compositional software Architectures, Monterey, USA, Jan. 1998 , http://www.objs.com/workshops/ws9801/report.html#II-3