You are on page 1of 13

1

COMPONENT BASED TECHNOLOGY


UNIT I
INTRODUCTION

SOFTWARE COMPONENTS:

Definitions:

“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 can be subjected to composition by third parties”
-Szyperski and Pfister, 1997.

Other definitions are

“A reusable software components is a logically cohesive ,loosely coupled module that


denotes a single abstraction”.
-Grady Booch , 1993.

“Components are units that are implemented already to enhance the programming
constructs”.
-Ivar Jacobson , 1993.

“Software components are defined as prefabricated. Pre-tested, Self-contained, reusable


software modules that perform specific functions”.
- Meta Group States, 1994.

“Reusable software components are self contained ,clearly identifiable pieces that
describe and perform specific functions , have clear interfaces appropriate documentation
and a defined reuse status”.
-Johannes Sametinger, 1997.

“Component is a physical, replaceable part of a system that packages implementation and


provides the realization of a set of interfaces”.
- UML 1.3 Standard , 1999.

“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”.
-Component Based Software, Engineering Handbook, 2001.

Properties of Components:

1 .A component is a unit of independent deployment.

A component needs to be well separated from its environment and other components.
2

It will be never deployed partially.

2.A component is a unit of third party composition.

A component needs to be self contained.


A component needs to encapsulate its implementation and interacts with its interfaces
by means of its well defined interfaces.

3.A component has no observable state.

A component must not be distinguished from the copies of its own.


Components are heavyweight units with exactly one instance of a system.

Example:

A payroll database server can be considered as a component.The payroll data may be an


instance.If components were allowed to have an observable state,then no two installations
of the same component would have the same properties.

OBJECT:

Definition:

Objects are real time entities that comes along with the associated information and set of
specific functions or operations.

Properties of objects :

1.An object is a unit of instantiation.

Object cannot be instantiated partially.

2.It has a unique identity.

Object has a unique identity to identify it despite the state changes for its entire life
time.

3.An object has an externally observable state.

A construction plan describing the state space, initial state and behavior of new object
is needed.

Such a plan can be explicitly available as a class or it can be implicitly available in the
form of objects that exist previously.

Such pre-existing object is called as a prototype object.


3

A newly instantiated object must be set to an initial state either by means of a


constructor which will have the code to control object creation and initialization or by
means of factory object with the help of factory methods .Factory objects are objects of
its own.

COMPONENTS AND OBJECTS:

A component act through object and it normally consists of one or more classes or
prototype objects.

 There is no need for a component to contain classes only or even to contain classes at
all.

 A component that does not maintain observable state cannot maintain references even
to the objects it created.

 A fully qualified name of a component cannot be used to retrieve any objects.

 A component may contain multiple classes , but a class is not confined to being part of
a single component.

 A component can depend on other components just like classes.

 The super class of a class do not necessarily need to reside in the same component as
class itself. It can be in another component .Hence the inheritance relationship exists
between the two components.

 This is an essential technique for establishing correctness.

FUNDAMENTAL PROPERTIES OF COMPONENT TECHNOLOGIES:

1. Components come from independent sources.

2. Components are integrated by third parties.

3. The module development and testing followed by systems integration and testing
leaves room for errors that are merely a result of composition and which are not
apparent at the level of individual components.

4. The reason for the above failure is the late integration.Hence integration testing is
no longer feasible.

5. Version checks are useful and essential at the stage of late integration.
4

6. Instead of full integration testing , testing against a few possible configuration is


the best that can be done.

7. Components need to be built in ways that allow modular checking.

8. Proper choice of programming languages and tools must be made.

9. A notion of component safety is important even if a component fails to function


properly,it must not violate system rules.

10. Functionality and performance requirements must be satisfied by a component.

11. Resources must be utilized properly by the component.

Example : Primary and secondary memory storage .

MODULES:

• A module is a set of classes and possibly procedures or functions.

• Modular languages are introduced in the late year 1970’s.

• The most popular modular languages are Ada, Modula-2, Modula-3,Pascal and
C#. In Ada ,Modules are packages.

• A class is seen as implementing an ADT with the additional properties of


inheritance and polymorphism .It is common to package ADT’s and classes into
one unit by means of modules.

• Modules can be used to form minimal components.

• A module with no class can also function as components.

Example : Traditional Math Libraries.

The differences between modules and the components are :

S.NO MODULES COMPONENTS


1. Modules use global or static variables to Components do not permit
expose observable state. observable state.
2. Modules depend on the implementations Component do not
in other modules by importing direct recommend the
interfaces from other modules. implementation
dependency.
5

So The component technology unavoidably leads to modular solutions.

COMPONENT ARCHITECTURE:

Need for an architecture:

To build any system that is complex , it is necessary to have rules for design and
implementation .Hence architecture is needed.

Architecture needs to create simultaneously the basis for independence and co-operation.

Independence is required to enable multiple sources of solution parts. Cooperation


between these individual components is a major part.

Properties of an Architecture:

It prescribes proper frameworks for all the involved mechanisms.


It includes all decision policies required to enable interoperations .

The principal considerations are:

1. Functionality
2. Performance
3. Reliability
4. Security

Component Architectural Terminology:

A component system architecture consists of platform decisions, a set of component


frameworks and an interoperation design for the component framework.

A platform is the base for the installation of components and component framework. A
platform can be concrete or virtual.Concrete platforms provide direct physical support
(hardware) .Virtual platforms emulate a platform on the top of the other.

An interoperation design for the component frameworks comprises the rules of the
interoperations among all the frameworks joined by the system architecture.

Tiered Component Architecture:

A traditional software architecture is notated by a set of layers. Layering remains very


useful in component systems.

To handle the complexity of larger components , the architecture itself must be layered .It
is called as a meta architecture.
6

The differences between tiers and the layers are :

Tiers Layers
1.Tiers are seen from top-down. 1.Layers are seen from bottom-up.
2.It increases the structured relevance. 2.It increases the abstract nature.
3.It decreases the application-specific 3.It increased the application specific
nature. nature.
4.It has decreasing performance. 4.It has increasing performance and
resource relevance.

A component system architecture arranges an open set of component framework as


follows.

The higher tiers provide shared lower layers to accept lower tiers.Tiers are existing side
by side while layers sit on top of the each other.

The lower layer starts with components.Above this is the component system which is the
framework of component frameworks.But the components themselves have the objects
and class frameworks.

To introduce the component application , light weight components must be constructed


with restrictive assumptions in mind.

Advantages of Light weight components:

1.They are not economical.

Light weight components can be made possible by two ways..


1.Using multiple specialized component frameworks.
2. Allowing componens to leave the unimplemented features that are not required for
them.
7

Communication between component instance:

A component instance can be specified as CI.CI can communicate with other component
instance either directly by CORBA or JAVA Beans events or indirectly through a
component framework that mediates and regulates component interaction.

COMPONENTS AND MIDDLEWARE:

• Middleware is a set of software that sits between various OS ,and a higher


distributed programming platform.

• Components and middleware are closely related since components resided in any
OS in a distributed system. By means of middleware bus components can be
accessed and communicate with one another. Components can also reuse
middleware components.

Services provided by middleware:

1. Identifiers
2. Authentication
3. Directories
4. Certificates and public-key infrastructures
5. Location transparency
6. Object Invocation
7. Passing messages.
8. Remote calls etc.,

TYPES:

Two categories of middleware exist namely

1.Object oriented middleware(OOM)


2.Message oriented middleware(MOM)

Object oriented Middleware:

• OOM offers synchronous, typed communication between components of a


distributed program .

• It is developed to extend the Object-Oriented programming paradigm to


distributed systems, the middleware typically consists of a mechanism to allow
methods to be invoked on remote objects and services to support the naming and
location of objects in a system – wide manner.
8

• Examples of OOM : Java, RMI and CORBA.

Message oriented Middleware:

• MOM can be seen as a natural extension of the packet paradigm of


communications in the lower layers of the OSI network model.

• Unlike object orientation it is an asynchronous form of communication i.e., the


sender does not block waiting for the recipient to participate in exchange.

• In MOM, messages are generally untyped and the internal structure of messages
is the responsibility of the application.

• In traditional MOM, messages are addressed to their recipients, although sender


and the receiver are loosely coupled and need not synchronise to communicate.

• A typical way of designing this is publish –subscribe systems ,where sources


publish to the entire network and interested sinks ”subscribe” to messages. The
network then only forwards them downstream if there is at least on subscriber on
that path. This requires the message transport service to understand the message
internals, although some systems are ”topic based” where each message has a
subject line which the transport reads and can ignore the rest of the message.

Example of MOM : IBM’s MQseries.

INTERFACES:

An interface must define the components access points.These points allow clients of a
component to access the services provided by a component.

Interface specification must be contractual because, the component and its clients are
developed in mutual ignorance (they do not know about each other).Therefore it forms a
middle ground for successful interactions.

The following are the non-technical aspects that are to be obeyed by a contractual
interface.
• The economy of scale must be kept in mind.
• Redundant introductions of similar interfaces must be minimized.
• A common media is needed to publish and advertise interfaces and components.
9

Example: International standard book number which will reveal the publisher author and
country code without revealing the books contents.It is also a need to have abstract names
to refer the interfaces.

Explicit Context Dependencies :

In addition to the specification of provides interfaces, it is required to specify what the


deployment environment needs to provide for proper functioning of a component.These
needs are called explicit dependencies or context dependencies .

Context dependences include:

1.Component model defining the rules of composition and


2.Component platform defining the rules of deployment , installation and activation of
components.

Component model:

A component is said to be useful if it offers right set of interfaces and it can function in
all component worlds without requiring any interface beyond the availability of interfaces
provided by different component worlds.

Example : Java virtual machine.

Reason: Java uses “ write once use everywhere” concept.A java file is converted into
class files which are collection of byte cores allowing a component to run everywhere.

Instead of constructing a component with everything built in, it is wise to use the reuse
concept.

Disadvantage :

Explosion of context dependencies. Because of its deployment environments for a


component are different providing different configurations and different versions, it is
necessary to have large number of context dependencies.

So maximize the reuse and minimize the use.

Justification:

Increasing the reuse increase the context dependencies and increase the leanness and
components .It also makes smaller markets.
10

Components and interfaces:

• Components gets connected with each other by means of interfaces.

• An interface is a set of named interfaces that are involved by clients .Each


operations meaning is specified and the specifications plays a dual role.

• It acts a middleman between client and the component since they do not know
each other.

Types of interfaces:

1. Direct interface
2. Indirect interface.

Direct interface:

An interface provided by a component directly is known as direct interface.It is similar


to procedural interfaces of traditional libraries.

Indirect interface:

• An interface provided by an object that exists inside a component is known as


indirect interface.

• The direct and the indirect interfaces can be grouped into a single concept.This
concept is achieved using static objects that can be a part of component.

• An indirection introduced by object interface.

• A method invocation is resolved at run time.

• The targets object class is retrieved and the method call is directed to the method
call is directed to the method definition in that class.

• This method involve third party.

• The client and component do not know about the third party.

Example:
11

• Text services is a component offering an interface IcheckGrammar.


• It also offers a mediator to select a default grammar checker.
• An object that implements the IcheckGrammar interface is passed to the
TextServices mediator to select the default grammar checker.

Therefore a client asking for a grammar checker might get the one that is implemented
outside TextServices.

Order of acquiring objects:

1-Grammar checker knows about the text service.


2-Mediator knows only about the Icheckgrammar.
3-Word processor knows about the mediator.
4-Word processor acquires a reference to the current default checker from the mediator.

This concept is similar to the late binding.

Versions:

• Versions of components can be in a component world.

• Some problem regarding versioning arises when moving from direct to indirect
interfaces because indirect interfaces involve third parties.
• It is advisable to avoid indirect coupling of parties that are of invompatible
versions.

• It is necessary to ensure that older and newer components are either compatible or
clearly detected as incompatible.

• If an interface is published , it will never change again.

• There is no problem in passing a reference of a particular interface version to


other component. Because the receiving components may either accept it or reject
it due to version problems.
12

• The main solution to the version problem .

• It can be concluded that multiple versions of a component can be loaded and


initialized in the same space.

• Components that should be used in the latest versions should be distinguished


from the components that should be always used in the same version with which
client is used with.

Interfaces as contracts:

• Interfaces can be viewed as contract between the client of an interface and a


provider of an implementation of the interface.
• Contract states
• What must be done by the client in order to use the interface.
• What the provider has to implement to meet the services that can be offered by
the interface.
• A contract must be re-definable and re-negotiable.
• A two sided contract can be specified by specifying
• Precondition for the operation .
• Post condition for the operation.
• A precondition is established by the client before calling the operation and the
provider relies on that precondition.
• A post condition is established by the provider before retuning to the client and
the client relies on it.
The other issues that influence the notation of contracts and interfaces are
• Safety and progress.
• Extra functional requirements
• Specifying time and space requirements.

Safety and progress:

Safety:

• Separation of pre and the post condition from the concrete operations is needed.
• A common “leads to “ operator can be used to represent the progress conditions
in a contract.
• This style is introduced by Helm.
• Another approach is to use abstract non-deterministic statement sequences to
specify safety and progress implicitely as abstract programs.(eg ADT’s)

Extra functional requirements:


13

• The above approaches like conditions, abstract statement sequences ,state what is
done under which provisions.
• They do not state how long it would take , what resources are utilized or
consumed.
• If a provider is extremely slow in performing a function , the client will also
slowdown its duty and hence the entire systems will fail to function properly.
• If a provider uses excessive heap storage , it affects the entire system.
• They should be regulated by contracts,Else it is not easy to pinpoint
underperforming and misbehaving components.Hence there will not be any
wastage of time and system resources.

Specifying time and space requirements:

• The specification of both average and worst time and space requirements or
bounds in a contract could add some practical value of that component.
• A contract remains successfully and sufficiently universal where reference to
platform specific bounds is avoided.
• To fill this gap, a component must come with the additional information required
to determine absolute bounds.

You might also like