Information Technology Reference
In-Depth Information
7.4.1 Component-Based Design
Component-based software engineering (CBSE) is commonly considered the next
step after object-oriented programming. It is not surprising that components are
often related to objects and sometimes the term component is simply used as a
synonym for object. However, the concepts of components and objects are inde-
pendent, although most component models are based on object-oriented concepts.
To avoid further confusion we will briefly characterize objects and components
and outline their differences.
7.4.2 Components and Objects
Objects are entities that encapsulate state and behavior, and have a unique identity.
The behavior and structure of objects are defined by classes. A class serves
multiple purposes: First, it implements the concept of an abstract data type (ADT)
and provides an abstract description of the behavior of its objects. Class names are
often used as type names in strongly typed systems. Second, a class provides the
implementation of object behavior. Third, a class is used for creating objects, that
is, instances of the class.
Nearly all modern component models are based on the object-oriented pro-
gramming paradigm. The basic premise of object-orientation is to construct pro-
grams from sets of interacting and collaborating objects. This does not change with
component based approaches. Components are similar to classes. Like clas-
ses, components define object behavior and create objects. Objects created by
means of components are called component instances. Both components and
classes make their implemented functionality available through abstract behavior
descriptions called interfaces.
Unlike classes, the implementation of a component is generally completely
hidden and sometimes only available in binary form. Internally, a component may
be implemented by a single class, by multiple classes, or even by traditional
procedures in a non-object-oriented programming language. Unlike classes,
component names may not be used as type names. Instead, the concept of type
(interface) and the concept of implementation are completely separated. Finally,
the most important distinction is that software components conform to the stan-
dards defined by a component model.
7.4.3 Component Models
A component model defines a set of standards for component implementation,
naming, interoperability, customization, composition, evolution, and deployment.
A component model also defines standards for associated component model
