Components

Alexey Golubev, 20.06.2004

What is a component?

The father of components?

Components and their promise

Requirements of component based development environments

Difference between a component and an object

Disadvantages and risks in using CBD

Component-Based System Development Lifecycle

UML and Component-Based Systems Modelling

Future of Component-Based Software Engineering



Alexey Golubev, 20.06.2004
Contents:
Definitions:

- software components are (binary) units of independent production,
acquisition, and deployment that interact to form a functioning system.

- a software component is a unit of composition with contractually
specified interface and explicit context dependencies only. A software
component can be deployed independently and is subject to composition
by third parts.

- components are black boxes. Application developer that make use of
components need not understand the implementation of those
components. They are reusable code in its simplest form.

Alexey Golubev, 20.06.2004
What is a component ?

Structure of a component:

- Publoc parts are light
- Privat parts are dark

Alexey Golubev, 20.06.2004
What is a component ?
provided
required
Reseources
Classes and Private interfaces
Self-Description
Instantiation
Public Interfaces
The father of components ?
Alexey Golubev, 20.06.2004
1798 federal procurement for muskets
component-based mass production
higher output (10.000 in 28 months)
Improved quality
Lowered skill requirements
Improved maintainability based on the
concept of the interchangeable parts
Eli Whitney (1765 - 1825)
CBD has the same goal for the software
that Eli Whitley wanted for muskets
Alexey Golubev, 20.06.2004
Components and their promise (1)
expected advantages:

flexibility
Run-time components can work independently, and, if designed properly, are much less
dependent on their environment (hardware, system software, other applications or
components). Therefore, component-based systems are much more adaptable and
extendable than systems traditionally designed and built.
- hardware and system software.
Component-based systems are less sensitive to changes in the foundation (for example:
the operating system) than traditional systems.
- functionality
Component-based systems are at a functional level much more adaptable and extendable
than traditional systems, because most of the new functionality can be reused some way or
another or derived from already existing components.

reuse
Such components can be used everywhere. Functionality, be it technical or business
oriented, has to be developed and implemented just once, instead of several times,
as is now typically the case.

Alexey Golubev, 20.06.2004
Components and their promise (2)
expected advantages:

maintainability
In a component-based system a piece of functionality ideally is implemented just once. It
is self-evident this results in easier maintenance, which leads to lower cost, and a longer
life for these systems.

more rapid development/higher productivity of the developers
In the long run, this higher productivity will be realised. However, in the short run the
fruits of reuse will be smaller than the cost of the introduction of a new way of system
development.

distribution
CBD makes it possible to design systems for distribution (on a LAN, or the Internet, or
whatever).
Alexey Golubev, 20.06.2004
Requirements of component based development environments

Accepted rules of modular design should be supported explicitly. The environment
should support a separation between the private and public parts of a component.

The environment should support and exploit component selfdescription,
meta-information that is stored directly inside of the component.

Components should be defined and accessed within a global namespace of interfaces,
which provides a method to name interfaces in a globally (worldwide) unique way.

The environment should support two methods of configuration: connection
and adaptation.

A CBDE should support multiple views.

The maintenance problems associated with component technology should be
addressed by the environment through reuse by reference, which is supported via
access to remote, searchable component repositories.

Alexey Golubev, 20.06.2004
Difference between a component and an object
a component is meant to be a runtime entity, whereas an object is an instance of a class.

objects are usually not thread-secure, because the designer knows (or thinks he knows)
how the objects are going to be used.

So in a component,interface design is more important than it usually is in object-oriented
design, and encapsulation of the state is enforced.

Objects exist at runtime, but classes are really design entities.

Components are deployed independently, and it is impossible to predict how the
component is going to be used.


Alexey Golubev, 20.06.2004
Disadvantages and risks in using CBD
Time and effort required for development of components.
Efficient reuse of real-time components, made by engineers at Siemens that, as a rule
of thumb, the overhead cost of developing a reusable component, including design plus
documentation, is recovered after the fifth reuse. Similar experience at ABB shows that
reusable components are exposed to changes more often than non-reusable parts of
software at the beginning of their lives, until they reach a stable state.

Unclear and ambiguous requirements.
Reusable components are, by definition, to be used in different applications, some of
which may yet be unknown and the requirements of which cannot be predicted.

Conflict between usability and reusability.
To be widely reusable, a component must be sufficiently general, scalable and adaptable
and therefore more complex (and thus more complicated to use).

Component maintenance costs.
While application maintenance costs can decrease, component maintenance
costs can be very high since the component must respond to the different
requirements of different applications running in different environments, with
different reliability requirements and perhaps requiring a different level of
maintenance support.

Alexey Golubev, 20.06.2004
Component-Based System Development Lifecycle
Find components which may be used in the system.

Select the components which meet the requirements of the system.

Alternatively, create a proprietary component to be used in the system.

Adapt the selected components so that they suit the existing component model or
requirement specification.

Compose and deploy the components using a framework for components.

Replace earlier with later versions of components.


The development cycle compared with the waterfall model.

Alexey Golubev, 20.06.2004
UML and Component-Based Systems Modelling
UML can be used for both component and system modeling. Component-driven design concentrates on
interface definitions and collaboration between the components through the interfaces. The design
process continues with the modeling of the system with physical components, which do not necessarily
match the logical structure.. One logical component, identified in the first phase of design, may consist
of several physical components. Finally, there is a deployment aspect, the components being executed
on different computers in a distributed application. In a non-component-base approach the first, the
design phase is important, while mapping between the conceptual and implementation level is a direct
mapping, and the deployment phase is the same for the whole application. In principle, UML can be
utilized to provide support for designing component-based systems covering all these aspects.
Interfaces are presented as multiple subsystems (also multiple interfaces may be realized by a
subsystem), which indicate the possibility of changing the implementation without replacing the
interface. An interface can be presented in two ways, the second alternative being the more common
presentation.

Uml Component - Interface representation

Alexey Golubev, 20.06.2004
Future of Component-Based Software Engineering
It is obvious that CBD and CBSE are in the very first phase of their lives. CBD is
recognized as a new, powerful approach that will, if not revolutionize, at least
significantly change the development of software and software use in general. We can
expect that components and component-based services will be widely used by non-
programmers for building their applications. Tools for building such applications by
component assembly will be developed. Automatic component update over the Internet,
already present today in many applications, will be a standard means of application
improvement.

Alexey Golubev, 20.06.2004
Sources:
Component Based Development -- M. Huizing

WREN An Environment for Component-Based Development -- Chris Ler, David S. Rosenblum

Component-based Software Engineering New Challenges in Software Development -- Ivica Crnkovic