Scribd
Upload
12 views5 pages

Week 2

This document discusses definitions of software components. It provides definitions from Szyperski, Meyer, and Heineman and Councill. Szyperski defines a component as a unit of composition with contractually specified interfaces and explicit context dependencies. Meyer defines a component as a modular unit that can be used by other units and has a usage description. Heineman and Councill define a component as a software element that conforms to a component model and can be independently deployed and composed. The document concludes that a generally accepted view is that a component has provided and required services that constitute its interface.

Uploaded by

Fizza Shahzadi
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
12 views5 pages

Week 2

This document discusses definitions of software components. It provides definitions from Szyperski, Meyer, and Heineman and Councill. Szyperski defines a component as a unit of composition with contractually specified interfaces and explicit context dependencies. Meyer defines a component as a modular unit that can be used by other units and has a usage description. Heineman and Councill define a component as a software element that conforms to a component model and can be independently deployed and composed. The document concludes that a generally accepted view is that a component has provided and required services that constitute its interface.

Uploaded by

Fizza Shahzadi
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 5

Chapter 2

What are Software Components?

What exactly are software components? This question is clearly fundamental to


CBD and has been discussed thoroughly (see e.g. [Broy et al. (1998)]). The most
widely adopted definition of a software component is the following by Szyperski
[Szyperski et al. (2002)]:
“A software component is a unit of composition with contractually
specified interfaces and explicit context dependencies only. A software
component can be deployed independently and is subject to composi-
tion by third parties.”

This defines a software component as a unit of composition, with an interface;


this definition has been universally accepted. Independent composition and de-
ployment (by third parties) is in line with the idealised component life cycle (as
discussed in Section 1.1). However, Szyperski’s definition does not say anything
about composition or context dependencies, in particular how they are defined.
Another component definition is due to Meyer [Meyer (2003)]:
“A component is a software element (modular unit) satisfying the fol-
lowing conditions:
1. It can be used by other software elements, its ‘clients’.
2. It possesses an official usage description, which is sufficient for a
client author to use it.
3. It is not tied to any fixed set of clients.”

Here, the notion of a component as a modular unit that can be used by other
modular units harks back to the pre-CBD days of modular software development.
In those days, composition was predominantly viewed as linking software units
that are parametrised structures such as modules (see Chapter 3), and units were
combined via usage links and parameters, the latter constituting their interfaces. In
contrast, in CBD composition is not limited to linking modules (again see Chapter
3), since there are other kinds of components than modules.

15
16 An Introduction to Component-Based Software Development

Meyer’s definition does not explicitly mention component interfaces. Instead


it stipulates an official page of usage description for a component, which could
serve as its ‘interface’. As for the idealised component life cycle, it is not clear
how well this definition aligns with it, since clients here are software elements
(not third-party developers), referred to here as ‘client authors’.
Yet another component definition is the following by Heineman and Councill
(2001):
“A [component is a] software element that conforms to a component
model and can be independently deployed and composed without mod-
ification according to a composition standard.”
This definition relies on a component model to define both components and com-
position. However, it does not say explicitly what a component model is, but only
hints that it includes a composition standard.
The definition by Heineman and Councill offers the fullest scope for defining
components and composition properly. So we believe components and composi-
tion should be defined in the context of a component model, and we have defined
component models as follows [Lau and Wang (2007)]:
A software component model is a definition of:
• the semantics of components, i.e. what components are meant to
be;
• the syntax of components, i.e. how they are defined, constructed
and represented;
• the composition of components, i.e. how they are composed or
assembled.

We will discuss component models in Chapter 4.

2.1 Generic Software Components

Apart from the aforementioned component definitions, there are many others.
From all these definitions, a generally accepted view of a software component
has emerged: it is a software unit with provided services and required services

Required Service Provided Service

Fig. 2.1 A generic software component.

(Fig. 2.1). The provided services (represented by lollipops) are operations per-
formed by the component. The required services (represented by sockets) are the
What are Software Components? 17

services needed by the component to produce the provided services. Roughly


speaking, the provided services of a component are its output, while the required
services are its input. Required services are typically input values for parameters
of the provided services.
The provided and required services of a component constitute its interface.
The interface is the only point of access to the component; therefore it should
provide all the information that is necessary to use the component. It should give
the specifications of its provided and required services. It should also specify any
dependencies between its provided and required services. To specify these depen-
dencies precisely, it is necessary to match the required services to the correspond-
ing provided ones. This matching could be expressed by listing corresponding
services as ordered pairs r1 , p1 , . . . , rn , pn , where each ri and pi is a set of
services.
Note that according to some definitions in the literature, a component can have
multiple interfaces, with each interface as a different set of services. Here we have
used a single interface as a collective entity for all such interfaces.
Generic components can be composed via their services. A provided service
can be ‘composed’ with a matching required service, and vice versa. Precisely
how services are ‘composed’ depends on how services are defined. The interface
of a composite component, and hence a system, can be derived from the services
of the sub-components. Again, precisely how this interface is derived depends on
how component composition is defined in terms of service ‘composition’.
With generic components and their composition defined above, the basic idea
for CBD (Fig. 1.1) can be depicted as in Fig. 2.2. Composites, and eventually

Fig. 2.2 Component-based software development with generic components.

complete systems, are composed from repository components, and successively


from the resulting intermediate composites.
An example of a system built form generic components is the ATM system in
Fig. 2.3. In this system, the ATM component provides the customers with a card
reader and a keypad to enter their PINs and make requests such as ‘withdraw’
18 An Introduction to Component-Based Software Development

Fig. 2.3 ATM system using generic components.

and ‘deposit’, and passes the customer request on to the Bank component. The
bank component provides the service (withdraw or deposit) that the customer has
requested, by passing these requests on to the Account component, which provides
these services.

2.2 Types of Components in Current Practice

There are three main types of components that are currently used in practice: (i)
objects (Fig. 2.4(a)), as in object-oriented programming; (ii) architectural units
(Fig. 2.4(b)), as in software architectures [Shaw and Garlan (1996); Bass et al.
(2012)]; and (iii) encapsulated components (Fig. 2.4(c)), as in components with
no external dependencies.

in1 out1
Provided in2 out2
method
(a) An object (b) An architectural unit (c) An encapsulated component

Fig. 2.4 The three main types of components that are currently used in practice.

Each of these types is a variation of the generic component. An object’s meth-


ods are its provided services, but an object has no visible required services (hence
the blurring out in Fig. 2.4(a)). An architectural unit has input ports as required
services, and output ports as provided services. An encapsulated component has
only provided services but no required ones.
Objects as components will be discussed in Chapter 5, architectural units as
components in Chapter 6, and encapsulated components in Chapter 7.
What are Software Components? 19

Discussion and Further Reading

Doug McIlroy [McIlroy (1968)] is credited with introducing the notion of software
components. In fact he promulgated mass produced software components, even
product lines (or families of related products). He considered components to be
routines (or procedures) that can be used together in building a system. He also
described components as modules, interchangeable parts and black boxes.
In [Cox (1986)], Cox defined software integrated circuits as components in
object-oriented software development. These software units with pins or plugs as
in silicon chips are of course a form of architectural units.
An extensive discussion about what components are, or should be, can be
found in [Broy et al. (1998)], which lists definitions offered by many contrib-
utors. Definitions include: ‘a group of related classes’, ‘data capsule’, ‘binary
unit’, ‘self-contained entity’. The discussion in this book provides the widely ac-
cepted desiderata for CBD that underpin the idealised component life cycle (see
Section 1.1).

You might also like