You are on page 1of 40

COMPONENT-BASED

SOFTWARE ENGINEERING

Pradeep Tomar

12/11/20 School of Information and Communication Tech 1


nology
COMPONENT-BASED
SOFTWARE ENGINEERINIG
Development for Reuse
From Scratch

Development with Reuse


Development with modification
Development without modification

12/11/20 School of Information and Communication Tech 2


nology
COMPONENT
The term component is probably one of the most overloaded and therefore most
confusing terms in modern software engineering, and the .NET documentation has its
fair share of inconsistency in its handling of this concept. The confusion arises in
deciding where to draw the line between a class that implements some logic, the
physical entity that contains it (typically a DLL), and the associated logic used to
deploy and use it, including type information, security policy, and versioning information
(called the assembly in .NET). A component is a .NET class. For
example, this is a .NET component:

public class MyClass


{
public string GetMessage( )
{
return "Hello";
}
}

12/11/20 School of Information and Communication Tech 3


nology
COMPONENT
According to
(Philippe Krutchen, Rational Software)
A component is a nontrivial, nearly independent,
and replaceable part of a system that fulfills a
clear function in the context of a well-defined
architecture. A component conforms to and
provides the physical realization of a set of
interfaces.

12/11/20 School of Information and Communication Tech 4


nology
COMPONENT
According to
(Gartner Group)
A runtime software component is a dynamically
bindable package of one or more programs
managed as a unit and accessed through
documented interfaces that can be discovered at
runtime.

12/11/20 School of Information and Communication Tech 5


nology
COMPONENT
According to
(Clemens Szyperski )

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
third-party composition.

12/11/20 School of Information and Communication Tech 6


nology
COMPONENT
According to
(Wojtek Kozaczynski, SSA)
A business component represents the software
implementation of an “autonomous” business concept or
business process. It consists of the software artifacts
necessary to express, implement, and deploy the concept
as a reusable element of a larger business system.

12/11/20 School of Information and Communication Tech 7


nology
Components could be classified
into five different forms
Component Specification

Component Interface

Component Implementation

Installed Component

Component Object

12/11/20 School of Information and Communication Tech 8


nology
INSTALLED COMPONENT
The installed form is an installed (or deployed) copy of a
component implementation.

A component implementation is deployed by registering


it with the runtime environment.

This enables the runtime environment to identify the


installed component to use when creating an instance of
the component or when running one of its operations.

12/11/20 School of Information and Communication Tech 9


nology
COMPONENT OBJECT
A component object is an instance of an installed
component.
This is a runtime concept. Similar to OOP, a component
object in COP is an object with its own data and a unique
identity, which performs the implemented behavior.

An installed component may have multiple component


objects (which require explicit identification) or a single
one (which may be implicit).

12/11/20 School of Information and Communication Tech 10


nology
COMPONENT SPECIFICATION
This form represents the specification of a unit of
software that describes the behavior of a set of
component objects and defines a unit of implementation.

Behavior is defined as a set of interfaces.

A component specification is realized as a component


implementation.

12/11/20 School of Information and Communication Tech 11


nology
COMPONENT INTERFACE

The interface form presents a definition of a set of


behaviors that can be offered by a component object.

12/11/20 School of Information and Communication Tech 12


nology
COMPONENT
IMPLEMENTATION
The implementation form is a realization of component
specification, which is independently deployable.

This means it can be installed and replaced independently


of other components. It does not mean that it is
independent of other components – it may have many
dependencies.

It does not necessarily mean that it is a single physical


item, such as a single file.

12/11/20 School of Information and Communication Tech 13


nology
COMPONENT-BASED SOFTWARE
ENGINEERINIG

CBSE = COA + COD + COP + COM

COA : COMPONENT ORIENTED ANALYSIS


COD : COMPONENT ORIENTED DEVELOPMENT
COP : COMPONENT ORIENTED PROGRAMMING
COM : COMPONENT ORIENTED MANAGEMENT

12/11/20 School of Information and Communication Tech 14


nology
COMPONENT-ORIENTED
PROGRAMMING
Component-oriented programming enables
programs to be constructed from prebuilt
software components, which are reusable,
self-contained blocks of computer code.
These components have to follow certain
predefined standards including interface,
connections, versioning, and deployment.

12/11/20 School of Information and Communication Tech 15


nology
COMPONENT-ORIENTED
PROGRAMMING
Component-oriented application comprises a collection of
interacting binary application modules that is, its components
and the calls that to bind them.

Component-enabling technologies such as COM, J2EE,


CORBA, and .NET provide the “plumbing” or infrastructure
needed to connect binary components in a seamless manner, and
the main distinction between these technologies is the ease with
which they allow you to connect those components.

12/11/20 School of Information and Communication Tech 16


nology
COMPONENT-ORIENTED
PROGRAMMING
Others may be highly specialized and developed specifically for
the application. An application implements and executes its
required business logic by gluing together the functionality
offered by the individual components.

Component-enabling technologies such as COM, J2EE,


CORBA, and .NET provide the “plumbing” or infrastructure
needed to connect binary components in a seamless manner, and
the main distinction between these technologies is the ease with
which they allow you to connect those components.

12/11/20 School of Information and Communication Tech 17


nology
COMPONENT-ORIENTED
PROGRAMMING
Component-oriented programming promotes black box reuse
instead, which allows you to use an existing component without
caring about its internals, as long as the component complies
with some predefined set of operations or interfaces.

Instead of investing in designing complex class hierarchies,


component-oriented developers spend most of their time
factoring out the interfaces used as contracts between
components and clients.

12/11/20 School of Information and Communication Tech 18


nology
COP vs. OOP
 Object Oriented Programming = Polymorphism + (Some) Late
Binding + (Some) Encapsulation + Inheritance

Java uses late-binding to support polymorphism; which means the


decision as to which of the many methods should be used is
deferred until runtime "
Java's use of late-binding which allows you to declare an
object as one type at compile-time but executes based on the actual
type at runtime "
 Component-Oriented Programming = Polymorphism + (Really)
Late Binding + (Real, Enforced) Encapsulation + Interface
Inheritance + Binary Reuse

12/11/20 School of Information and Communication Tech 19


nology
COP vs. OOP
COP is interface-based, while OOP is object-based.
COP is a packaging and distribution technology, while OOP
is an implementation technology.
COP supports high-level reuse, while OOP supports low-level
reuse.
COP, in principle, can be written in any language, while OOP
is bound to OO languages.
COP has loosely coupled components, while OOP has tightly
coupled objects dependent on each other through inheritance
implementation.

12/11/20 School of Information and Communication Tech 20


nology
COP vs. OOP
COP has large granularity components, while OOP has objects as fine-
grained units of composition.

COP supports multiple interfaces, and interface-oriented design, while


OOP does not provide clear relationship of interfaces among
superclasses and subclasses.

COP supports more forms of dynamic binding and dynamic discovery,


while OOP provides limited support for object retrieval and runtime
composition mechanisms.

COP has better mechanisms for third-party composition, while OOP


has limited forms of connectors (method invocation).

12/11/20 School of Information and Communication Tech 21


nology
COP vs. OOP
COP provides more support for higher-order services (security,
transactions, etc.), while OOP has limited sets of supported
services such as security, transactions, and so on.

COP components are designed to obey rules of the underlying


component framework, while OOP objects are designed to obey
OO principles.

12/11/20 School of Information and Communication Tech 22


nology
Principles of Component-Oriented
Programming
Separation of interface and implementation
Binary compatibility
Language independence
Location transparency
Concurrency management
Version control
Component-based security

12/11/20 School of Information and Communication Tech 23


nology
Separation of interface and
implementation
The fundamental principle of component-oriented programming
is that the basic unit in an application is a binary-compatible
interface.

The interface provides an abstract service definition between a


client and the object.

This principle contrasts with the object-oriented view of the


world that places the object rather than its interface
at the center.

12/11/20 School of Information and Communication Tech 24


nology
Separation of interface and
implementation

An interface is a logical grouping of method definitions that acts


as the contract between the client and the service provider.

Each provider is free to provide its own interpretation of the


interface—that is, its own implementation.

The interface is implemented by a black-box binary component


that completely encapsulates its interior. This principle is known
as separation of interface from implementation.

12/11/20 School of Information and Communication Tech 25


nology
BINARY COMPATIBILITY
Another core principle of component-oriented programming is binary
compatibility between client and server.
Traditional object-oriented programming requires all the parties
involved—clients and servers—to be part of one monolithic application.
During compilation, the compiler inserts the address of the server entry
points into the client code.
Component-oriented programming revolves around packaging code into
components, i.e., binary building blocks.
This binary compatibility is the basis for the contract between the
component and the client. As long as the new version
of the component abides by this contract, the client isn’t affected.

12/11/20 School of Information and Communication Tech 26


nology
BINARY COMPATIBILITY
Changes to the component code are contained in the binary unit
hosting it; you don’t need to recompile and redeploy the clients.

However, the ability to replace and plug in new binary versions


of the server implies binary compatibility between the client and
the server, meaning that the client’s code must interact at
runtime with exactly what it expects as far as the binary layout
in memory of the component entry points.

12/11/20 School of Information and Communication Tech 27


nology
LANGUAGE INDEPENDENCE

Unlike traditional object-oriented programming, in component-


oriented programming, the server is developed independently of
the client. Because the client interacts with the server only at
runtime, the only thing that binds the two is binary
compatibility.

12/11/20 School of Information and Communication Tech 28


nology
LANGUAGE INDEPENDENCE
Language independence means exactly that: when you
develop and deploy components your choice of
programming language should be irrelevant.

Language independence promotes the interchangeability


of components, and their adoption and reuse.

.NET achieves language independence through an


architecture and implementation called the Common
Language Runtime (CLR)

12/11/20 School of Information and Communication Tech 29


nology
LOCATION TRANSPARENCY
A component-based application contains multiple binary
components.

These components can all exist in the same process, in different


processes on the same machine, or on different machines on a
network.

Recently, with the advent of web services, components can also


be distributed across the Internet.

12/11/20 School of Information and Communication Tech 30


nology
LOCATION TRANSPARENCY
The underlying component technology is required to
provide a client with location transparency, which
allows the client code to be independent of the actual
location of the object it uses.

Location transparency means there is nothing in the


client’s code pertaining to where the object executes.
The same client code must be able to handle all cases of
object location

12/11/20 School of Information and Communication Tech 31


nology
CONCURRENCY MANAGEMENT
A component developer can’t possibly know in advance all the possible ways
in which a component will be used and particularly whether it will be accessed
concurrently by multiple threads.

The safest course is for you to assume that the component will be used in
concurrent situations and to provide some mechanism inside the
component for synchronizing access.

However, this approach has two flaws. First, it may lead to deadlocks; if every
component in the application has its own synchronization
lock, a deadlock can occur if two components on different threads try to
access each other.
Second, it’s an inefficient use of system resources for all components
in the application to be accessed by the same thread.

12/11/20 School of Information and Communication Tech 32


nology
CONCURRENCY MANAGEMENT
The underlying component technology must provide a
concurrency management service—way for components to
participate in some application-wide synchronization
mechanism, even when the components are developed
separately.

In addition, the underlying component technology should allow


components and clients to provide their own synchronization
solutions for fine-grained control and optimized performance.

12/11/20 School of Information and Communication Tech 33


nology
VERSIONING SUPPORT
Component-oriented programming must allow clients and
components to evolve separately.

Component developers should be able to deploy new versions


(or just fixes) of existing components without affecting existing
client applications.

Client developers should be able to deploy new versions of the


client application and expect it to work with older versions of
components.

12/11/20 School of Information and Communication Tech 34


nology
VERSIONING SUPPORT
The underlying component technology should support
versioning, which allows a component to evolve along
different paths, and for different versions of the same
component to be deployed on the same machine, or side
by side.

The component technology should also detect


incompatibility as soon as possible and alert the client.

12/11/20 School of Information and Communication Tech 35


nology
COMPONENT-BASED
SECURITY
In component-oriented programming, components are developed
separately from the client applications that use them.

Component developers have no way of knowing how a client


application or end user will try to use their work.

A component could be used maliciously to corrupt data or


transfer funds between accounts without proper authorization or
authentication.

12/11/20 School of Information and Communication Tech 36


nology
COMPONENT-BASED
SECURITY
Similarly, a client application has no way to know whether it’s
interacting with a malicious component that will abuse the
credentials the client provides.

In addition, even if both the client and the component


have no ill intent, the end application user can still try to hack
into the system or do some other damage

12/11/20 School of Information and Communication Tech 37


nology
Components Represent Decomposition and Abstraction

Reusability Should Be Achieved at Various Levels

Component-Based Software Development Increases the Software


Dependability

Component-Based Software Development Could Increase the


Software Productivity

Component-Based Software Development Promotes Software


Standardization

12/11/20 School of Information and Communication Tech 38


nology
Components Represent
Decomposition and Abstraction
To solve the complex problem in computer science we use “divide
and conquer.”
One major idea in component-based software development is to
create software modules that are themselves self-contained and
independently deployable.
Thus different developers will be able to work on different
components independently, without needing much communication
among themselves, and yet the components will work together
seamlessly.
In addition, during software maintenance phase, it will be possible to
modify some of the components without affecting all of the others.

12/11/20 School of Information and Communication Tech 39


nology
THANKS

Pradeep Tomar

12/11/20 School of Information and Communication Tech 40


nology

You might also like