Basic Concepts in Component-Based
Software Engineering
Page 1
Overview
The Component
Interfaces
Contracts
Patterns
Frameworks
Component Maturity Levels
Component Based Develoepment & Maturity Levels
Conclusion
Page 2
What is a Component?
We can find several definitions of a component in
literature, however everyone agrees that a component is
a piece of software.
These definitions begin from the consideration of CBSE
from different viewpoints and focus on different aspects
of software engineering such as:
Different phases (design, implementation and run-time
phases),
Business aspects,
Architectural issues.
Page 3
The Component : Peter Herzum
Peter Herzum and Oliver Sims [A Comprehensive
Overview of Component-Based Development for the
Enterprise”] defines a component as, “Business
Components Factory”:
A software package which offers service through
“interfaces”
A component is a self-contained software construct that
has a defined use, has a run-time interface, can be
autonomously deployed and is built with foreknowledge
of a specific component socket.
A component socket is software that provides a well
defined and well known run-time interface to a
supporting infrastructure into which the component will
fit.
Page 4
The Component : Peter Herzum
The industry today however is still focused on the
component as a single pluggable software module.
The component user may not have the skills or tools
necessary to create the component. This means that
there is a hierarchy of component-ware, such that one
person’s end product is a component for someone else.
The person who creates a component will not normally
create the socket, the infrastructure into which it fits.
Page 5
The Component: Szyperski
Szyperski [Author of ‘Beyond Object Oriented
Programming’] defines a component precisely by
enumerating its characteristic properties as follows:
A software component is a unit of composition with
contractually specified interfaces and explicit context
dependencies only.
A component is built for composition and collaboration
with other components.
A software component can be deployed independently
and is subject to composition by third party.
Page 6
Implications of Szyperski’s Definition
The following implications arise as a result of
Szyperski’s definition [Author of ‘Beyond Object
Oriented Programming’]:
For a component to be deployed independently, a clear
distinction from its environment and other components is
required.
A component must have clearly specified interfaces.
The implementation must be encapsulated in the
component and is not directly reachable from the
environment .
Page 7
The Component: D'Souza and Wills
D'Souza and Wills define a component as, [Author of
‘Objects, Components, And Frameworks with UML – The
Catalysis Approach’]
A reusable part of software, which is independently
developed, and can be brought together with other
components to build larger units. It may be adapted but
may not be modified.
A component can be, for example, a compiled code
without a program source, or a part of a model and/or
design.
A coherent package of software artifacts that
can be independently developed and
delivered as a unit and that can be composed,
unchanged, with other components to build
something larger
Page 8
Views of Components
Developers and information system designers view:
Components can be used to build their own server-based
information system.
Example is a invoice management system.
Views components as enterprise distributed components.
Page 9
Views of Components
End Users, business analysts and marketers view:
Large chunks of systems as being components.
Properly defined interfaces and satisfying all the above
characteristics, can be considered as components.
Call these system-level components.
Page 10
What is not a component ?
A business model
A business model is not a component as it is normally
not made as a component.
It is not reusable even if a small granularity is
considered.
A language class
A language class does not have a run time interface.
User Interface components
As JavaBeans, ActiveX controls or OpenDocs, are of
small granularity.
Page 11
Objects:
An Object is a unit of instantiation
An Object has state; this state can be
persistent state
An Object encapsulates its state and
behavior
Difficult to address portability and
interoperability
Page 12
Components
A component is a unit of independent
deployment
A component is a unit of third party
composition
A component has no persistent state
Page 13
Objects and Components Continued
The following are other important distinctions between
objects and components:
Components have a more extensive set of
intercommunication mechanisms than objects which
usually use the messaging mechanism.
Components are often larger units of granularity than
objects, and have complex actions at their interfaces.
Page 14
Objects vs. Components – Cont’d
• Class
Component
•Single interface, multiple
Multiple interfaces operations
Does not have to be
•Construct within an OO
implemented in OO
language language
Encapsulated •Encapsulated
Independently deliverable •Difficult to separate from
Reuse of service program embedded in
•Reuse of implementation
Page 15
Interfaces
An interface of a component can be defined as a
specification of its access point, offering no
implementation for any of its operations.
This seperation makes it possible to:
Replace the implementation part without changing the
interface;
Add new interfaces (and implementations) without
changing the existing implementation,
Page 16
Describing an Interface
Interfaces defined in standard component technologies
using techniques such as Interface Definition Language
(IDL) are:
Sufficient in describing functional properties.
Insufficient in describing extra-functional properties such
as quality attributes like accuracy, availability, latency,
security, etc.
Page 17
Contracts
A more accurate specification of a component's
behavior can be achieved through contracts.
A contract is comprised of:
The Invariant, the global constraints which the
component will maintain;
The Pre-condition, the constraints which need to be met
by the client;
The Post-condition, the constraints which the
component promises to establish in return.
Page 18
Patterns
Patterns define recurring solutions to recurring
problems capturing non-obvious solutions, not just
abstract principles or strategies.
The solutions should be proven to solve the problem
rather than being theories or speculations.
Patterns describe relationships between deeper system
structures and mechanism.
A component, as a reusable entity, can be seen as a
realization of some design pattern.
Page 19
Three Categories of Patterns
Patterns can be classified into three major categories:
Architectural Patterns, capture the overall structure and
organization of a software system.
Design Patterns, refine the structure and the behavior of
the subsystems as well as the components of a software
system, and the relationships which exist between them.
Idioms, are low-level patterns which are dependent on
the chosen paradigm and the programming language
used.
Page 20
Software Frameworks
CBSE means that we build software by "putting pieces
together". Frameworks provide the context in which the
pieces can be used.
A framework may be seen as:
A reusable design of a system,
A skeleton of an application which can be customized by
an application developer.
Page 21
Component Frameworks
While frameworks in general describe a typical and
reusable situation at a model level, a component
framework describes a “circuit-board” with empty slots
into which components can be inserted to create a
working instance.
Component
Coordination Services (transactions, persistence..) Framework
Page 22
Relationships Between Concepts
Interface that satisfies contracts
Component-type Component
Specific interface implementation
Independent Component
deployment model
Component
Coordination Services (transactions, persistence..) Framework
Page 23
Supporting Technology
Component technologies provide a runtime environment within which
the assembled application can operate as well as tools that assist with
the assembly and deployment of components.
COM+
EJB
CORBA
Services
Transaction management Interface that satisfies contracts
Security management
Component-type Component
Persistent management Specific interface implementation
Instance management
Independent
Database connection pooling deployment
Component
model
Threading
Coordination Services (transactions, Component
State management persistence..) Framework
etc Page 24
Component Maturity Level
Page 25
Traditional Development
Used SAD and was deployed on mainframes like Cobol &
RPG languages
The end user would receive a monolithic application built,
say, using COBOL
The object-oriented approach is at the service of the
functional developer, not the end use
Page 26
Traditional and OO Development Vision
Page 27
Evolution of Component Development
B: Bleem M: Mature
Page 28
L: Leading
What is Component Based Development ?
Some practitioners define component-based development
(CBD) as an approach in which all artifacts—including
Executable code
Interface
Specifications
Architectures
Business model
Scaling from complete applications and systems down
to individual components—
Can be built by assembling, adapting, and “wiring”
together existing components into a variety of
configurations.
Page 29
What is Component Based Development ?
Component-based development is a software development
approach where all aspects and phases of the development
lifecycle, including requirements analysis, architecture,
design, construction, testing, deployment, the supporting
technical infrastructure, and also the project management,
are based on components.
Page 30
Benefits Of CBD
CBD changes the nature of the information system:
Changes to the point where the whole concept of what an
application is needs redefinition Components become
highly visible at run-time, and this affects the way software
is built, assembled, deployed, tested, evolved, marketed,
and sold.
Component-based development is not only a
development approach but also a deployment approach,
and this leads to a new way to market and buy software
solutions.
Page 31
Benefits Of CBD
CBD masters deployment complexity:
A modification request may conceptually affect only one
module, but implementation of the modification usually
ends up impacting several modules. Furthermore, in
many cases the whole application needs to be
redeployed.
Page 32
Benefits Of CBD
CBD masters deployment complexity:
Using a component-based approach the modification
usually impacts only the component that is affected by the
modification request, and it is possible to redeploy only
the impacted component. This is a benefit that is
particularly important for large systems. Of course, the
achievement of this level of modularization requires an
appropriate set of architectural and design principles and
techniques across the development lifecycle and software
lifecycle.
Page 33
Conclusion
Component specifications are essential for component
users who are focused on the component features,
functional and non-functional
The main purpose of frameworks is to support the
process of component composition
Component developers must obey the rules and formats
specified by the framework to develop and to specify
the component, while component users will use
frameworks to compose systems from components in a
more efficient and accurate way.
Page 35
Conclusion Continued
Patterns give an abstract and more general view of a
function, procedure or similar, which can be
implemented in the form of systems or components
Component designers will use patterns in the design
process to design components more efficiently
Page 36
