Components-based architecture

Course Support Prepared By:

Mr. BELGROUN Brahim
Assistant Master A
Department of Mathematics and Computer science
Faculty of Science and Technology
Khenchela University
September 2019
Email: b_belgroune@esi.dz
 Introduction

The deployment of computer tools in all fields (industry, administration, communication, scientific
researches,…), makes the software more and more complicated. Developers must consider the requirements
of each domain and its specifications. The software does not become a secondary tool for users. But it’s in
the heart of any society and system.

This trend increases the requirements of software products such as robustness, flexibility, adaptability,
and simplified installation and deployment. As these requirements become stronger, the complexity of the
processes that the software manages increases the demand for process integration from different domains. As
consequence, the software is coming more and more voluminal and complex. The main challenge for
developers is to cope with complexity and adapt to change. Traditionally, software development has
responded to the challenge of increasing complexity, to the dependence on external software by focusing on
a system at a time and meeting the delivery deadline. An inlay, to the budget requirement without
considering the evolving needs of the system.

The key to solving this problem is reusability. The idea is not new. But, despite some success,
reusability has not become a top solution in software development. Most unsuccessful reusability approaches
did not meet the basic requirements of reusability [1]:

1. Reusability requires a modification of the object being reused.

2. Reusability must be integrated into specific software development.

In many approaches, reusability is not inherent in the development process. What will be reused or not
is precisely defined? And how changes can be introduced into reusable parties is not formalized. The fast
emerged approach called component-based development (CBD) restores the idea of reusability and
introduces new elements. In CBD, software systems are built by assembling components already developed
and prepared for integration. It has many advantages. It includes more effective management of complexity,
reduced time to market, increased productivity, improved quality, greater consistency, and more wide range
of usability [2].

However, CBD has several disadvantages and risks that can compromise its success:

1. Time and effort required for component development: Among the factors that can discourage the
development of reusable components, there is the time and the effort required to build reusable
units [3, 4].
Introduction

2. Ambiguous requirements: in general, requirements management is an important and complex

phase of the development process, its main objective being to define consistent and
comprehensive component requirements. One of the major problems of software development
comes from imprecise, ambiguous, incomplete, and insufficient requirements specifications.
Reusable components are, by definition, used in different applications, some of which may be
unknown and whose requirements cannot be predicted. This applies to both functional and non-
functional requirements. This makes it more difficult to correctly identify the requirements and
therefore the successful design and construction of the component [5, 6].

3. The conflict between usability and reusability: To be largely reusable, a component must be
sufficiently general, scalable, and adaptable; it will be more complex (therefore more complicated
to use) and more demanding computing resources (therefore more expensive to use). A reuse
requirement may lead to another development approach, such as a more abstract design, which
may reduce its ultimate flexibility and ability to be refined, but it will be more simple [3, 4].

4. Component maintenance costs: Although application maintenance costs can be reduced, the
component maintenance costs can be very high because the component must fit the different
requirements of different applications operating in different environments, with different
reliability requirements and possibly requiring a different level of maintenance support [3].

5. Reliability and sensitivity to changes: Because components and applications have separate life
cycles and different types of requirements, there is a risk that a component may not fully meet the
particular requirements of certain applications or may have characteristics unknown to the
developer. When we change the application environment (such as updating an operating system,
updating other components, and modifying the application), developers may suffer a system
failure.

Both developers and their customers expect a lot from CBD, but their needs have not always been
satisfied. Experience has shown that CBD requires a systematic approach to focus on the constituent aspects
of software development [3]. Traditional software engineering techniques need to be adapted to the new
approach, and new procedures need to be developed. Component-based software engineering (CBSE) is
recognized as a new approach to software engineering.

In this document, we will present our chapters:

Chapter I: Basic concepts of Component-Based Software Engineering: In this chapter, we will

define a set of terms that describe the best practices of component-based software engineering
(CBSE). The term “software component” and its constituent elements will be described in detail to
provide clear, unambiguous, and rational meanings to the terms used to describe CBSE.

2
 Chapter I: Basic concepts of
Component-based software
engineering
Content
I.1. Introduction ............................................................................................................................................... 4

I.2. Software Components & Component Based Software Engineering ........................................................... 4

I.2.1. Component ........................................................................................................................................ 4

I.2.2. Component interfaces ........................................................................................................................ 5

I.2.3. Contracts ............................................................................................................................................ 6

I.2.4. Patterns .............................................................................................................................................. 6

I.2.5. Framework ......................................................................................................................................... 7

I.2.6. Recapitulation .................................................................................................................................... 7

I.3. Conclusion ................................................................................................................................................. 8

Chapiter I : Basic concepts of Component-based software engineering

I.1. Introduction
In this chapter, we will define a set of terms that describe the best practices of component-based
software engineering (CBSE). The term “software component” and its constituent elements will be
described in detail to provide clear, unambiguous, and rational meanings to the terms used to describe
CBSE.

I.2. Software Components & Component-Based Software Engineering

It is very important to clarify the concepts related to the CBD. At first glance, component-based
software development appeared to be an extension of object-oriented development, while several arguments
such as granularity, composition, and deployment as well as the development process distinguish the
components of objects. In this section, we present the concepts of component, interface, contract, patterns,
and frameworks that present very important concepts related to CBSE.

I.2.1. Component
Simply, we can consider a schematized component in Figure I. 1 as a reusable unit for composition and
deployment. In the literature, several definitions have been attributed to this concept, which is at the heart of
the CBSE. We present some definitions which cover all the ways according to which this concept can be
seen.

Interfaces of adjustment

Provided Interfaces
Required Interfaaces Component

Figure I. 1: Software Component.

Szypersky (Szyperski, 1998) defines a component as: "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 composition by the third party".

According to this definition, the component communicates with its environment through interfaces, so
these must be specified clearly while encapsulating the implementation in the component. This separation
between specification and implementation is not similar to that which we can see in object-oriented
programming languages where class definitions are separated from their implementations, the difference lies
in the integration needs of the component in an application, the integration of the component must be
independent of its life cycle, in other words, it is not necessary to recompile an application when adding a
new component. For the component to be deployed independently, it is necessary to make a clear distinction
between the component and its environment as well as between the component and the other components.

4
Chapiter I : Basic concepts of Component-based software engineering

Another definition according to which it is possible to use the concept of the component in abstraction
levels other than the level of implementation has been proposed where the component is defined as "A
design unit (of any abstraction level) identified by a name, with a defined structure and design guidelines
in the form of documentation to support its reuse ".

In this definition, we have two different physical aspects to appear: the implementation component
which is a program or a part of a program, and the design component that is a model.

According to D'Souza and Wills (D, et al., 1998), "a component is a reusable part of an application;
it is developed independently and can be combined with other components to build larger units. A
component can be adapted but cannot be modified”. The specificity of this definition lies in the fact that it
is noted that a component cannot be modified.

Brown (Brown, 2000) and Bill Councill & George T. Heineman (Councill, et al.) propose the
following definition: " a software component is a software element that conforms to a component model
and can be independently deployed and composed without modification according to a composition
standard". In this definition, the authors mentioned that a component must conform to a component model.
This definition is very close to the vision of the industry that is different from how the components are seen
in academic circles.

To conclude, we return to the starting point. There are several definitions for the component, each one
focus on one or more aspects. Everyone agrees on a few points, a component is a composition unit, it must
be specified to be composed with other components or integrated into applications; the components are
reusable, the reuse in component-based software engineering is different from what we can find in object-
oriented technology or other technologies related to traditional software engineering. This difference lies in
the fact that a component can be used at run-time without the need for recompilation. The second argument
of this difference appears because the component detaches its interfaces from its implementation which
allows the composition without having to know any detail about the implementation of the component.

I.2.2. Component interfaces

An interface of a component is defined as the specification of its access points. These points are used
by the component's clients to access services provided by the component. An interface does not provide any
implementation details of its operations. Instead, in an interface, we simply name a collection of operations
and provide descriptions and protocols for these operations. This mechanism increases the adaptability of the
component as well as its performance in the sense that we can add new interfaces and implementations
without modifying existing implementations or even replace the implementation part without rebuilding the
system.

Interfaces are also used to allow the customization of a component. The interfaces defined in
standardized technologies can express functional properties in which are included: the signatures of the
operations as well as the behaviors of the components. Most of the techniques for describing interfaces as

5
Chapiter I : Basic concepts of Component-based software engineering

definition languages only focus on the signature part (syntactic aspects). These techniques also suffer from
certain disabilities to describe non-functional properties such as accuracy, precision, availability, security,
and latency. The interfaces of a component are partitioned into (1) the provided interfaces that describe the
services provided by the component, and (2) the required interfaces that specify the services required by the
component.

I.2.3. Contracts
Contracts are a technique that makes it possible to have more precise specifications for the contract
behaviors found their reasons to exist in the need to describe the overall behavior of a component and by the
limitation of the majority of interfaces description techniques like IDLs that only treat signatures with a
purely syntactic view. The contracts are introduced in the development of the systems; a contract specifies
the global (invariant) constraints that the component must maintain.

For each transaction, the contract specifies the pre-conditions that customers must meet as well as the
post-conditions promised in return by the component. The set of pre-conditions, post-conditions and the
invariants to maintain constitute the specification of the behavior of a component.

In addition to their uses for specifying component behaviors individually, contracts are also used to
specify interactions between a set of components. This specification relates to the set of components; the
roles of each component across a set of obligations and their types; and a set of invariants to maintain by the
components. The use of contracts, in this case, favors the realization as well as the refinement of software
unit based on high granularity component, this is due to the following factors:

 Contracts allow software developers to explicitly isolate and specify with a high level of
abstraction the roles of all components in particular contexts.

 The presence of several contracts makes it possible to modify the roles of each component
independently or to extend the roles.

 New contracts can be obtained through the association of different participants with different
roles.

Since a component can participate in multiple contracts, its overall behavior can be quite complex.
Moreover, contracts specify the conditions under which components interact with other components in terms
of pre-and post-conditions.

I.2.4. Patterns
The concept of the pattern was introduced in the late 70s. A pattern defines a recurring solution for a
recurring problem. In a pattern capturing the solutions of a problem, the solutions provided are not theories
or abstractions of principles and strategies. The patterns describe, in detail, the relationships between system
structures and mechanisms.

6
Chapiter I : Basic concepts of Component-based software engineering

One can ask the question about the relation between the two concepts patterns and components. On
the one hand, design patterns can be used for the design and documentation of a component, especially the
components in which the reusable units are to be identified. On the other hand, components as reusable
entities can be considered as implementations of some design patterns. Design patterns can be used as a
means to describe the low-level implementation details of a component at a time for its behavior and
structure. Patterns can also describe the relationships between components in the context of a particular
programming language.

Design patterns can also be used for composition description, which is, describing assemblies that
combine multiple components.

I.2.5. Framework
The frameworks can be defined according to several points of view at different levels of abstraction.
The frameworks can be considered reusable designs in which the design consists of representing the system
to design in abstract classes and interactions between their instances. The frameworks can also be defined as
skeletons of applications that can be customized by the developers. From an architectural point of view, a
Framework represents a micro-architecture that provides an incomplete template for a system in a given
domain.

The main idea around which the concept of Framework revolves is that one can extract abstract results
from the design effort of a system. These results can be used in other situations. The frameworks make the
description of which can be used with some modifications in similar situations in the same field or the same
space of problems.

The CBSE proposes to develop software by "assembling parts" in such situations, it is essential to
have a context in which parts can be used. The frameworks can play the role of this context. The frameworks
can act as a motherboard with empty slots to which components can be dynamically inserted to create a
functional instance. The main contribution of the frameworks lies in the fact that the frameworks force the
components to complete their tasks through mechanisms controlled by the frameworks. The Microsoft
Visual Studio is a good example where forms are built by adding components (controls) to an initially empty
form; the developer adds behaviors to the controls through an interface of messages and events exchanged
between the components.

I.2.6. Recapitulation
The relationships between component, interface, contract, pattern, and framework concepts are
schematized in Figure I. 2 (Crnkovic, et al., 2002). A component (1) is a software implementation performing
a set of services described by one or more interfaces (2) of the contracts (3) describe conditions and
obligations that the components must meet. Contracts ensure that independently developed components obey
interaction rules, and can be deployed in a standard build and run environment (4). The components have
types (5). A set of component types and their interfaces as well as design patterns describing the interactions

7
Chapiter I : Basic concepts of Component-based software engineering

between different types of components form a component model (6). An Application Framework (7)
provides a set of deployment and execution criteria (8) as support for component models.

03 mplementing interfaces and

satisfying contracts

02 Component interfaces 01 Implementing component

06 Component model

04 Independent deployment

Types of components and

05
contracts

08 Coordination Service

07 Component Framework

Figure I. 2: The relationship between component, interface, contract, pattern, and Framework.

I.3. Conclusion
In this chapter, we have introduced the basic concepts of CBSE, summarized as follows. A component
is a reusable unit of deployment and composition that has no persistent state. It can be composed at run time,
with no need for compilation and its implementation details, but it cannot be modified. The specification of
the services provided by a component is the role of interfaces, which are useful in the processes of
customization and composition of components. Design patterns can be used to describe the low-level
implementation details of the behavior and structure of components or the relationships between the
components in the context of a particular programming language. Contracts or frameworks can be used to
permit the construction and reuse of larger grained software components. Frameworks constitute a group of
participants and specify relations and the interactions between them that could be reused in any isomorphic
situation. Contracts and frameworks may at first look quite similar, but there are notable differences. A
framework defines a set of rules for different services (e.g., transaction, persistence, and deployment) and an
infrastructure of the component model. Contracts are used for the specification of a component and the
concrete interaction between components, and in this sense, it is a different form of framework. A
component can be implemented in different component models, and they will utilize different internal
mechanisms of framework services, but all the implementations may have the same interface or the same
contract.

8
Chapiter I : Basic concepts of Component-based software engineering

Patterns are also often used in combination with frameworks in that they define smaller parts of a
system than frameworks define. However, the main difference between frameworks and patterns is that
frameworks concretely describe a set of rules and services, whereas patterns describe behavior more
abstractly. A framework can be constructed using several patterns.