Course Outline

Basic Concepts in CBSD

What is CBSE?
Why CBSE?
Components and Objects
Interfaces, Contracts, and Patterns
Specification of Components
Architectural styles in CBSD

Component Oriented Programming 3
Major Topics
Define COP and its major objectives
Discuss the importance of COP
Define components and their characteristics
Distinguish hardware components and software
components
Investigate the differences between OOP and COP
Introducing component-based software
engineering
Component Oriented Programming 4
What is a Component?
Dictionary definition
A unit of, part of a model
We can find several definitions of a component in literature,
however everyone agrees that a component is a piece of software
Hardware components
Software components
SD
1 2 3 4 5 6 7 8 9 10 11 12
Differences?
Component Oriented Programming 5
What is a component? (1)
1. 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. (Philippe Krutchen,
Rational Software)
2. 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. (Clemens Szyperski)

Component Oriented Programming 6
What is a component? (2)
3. 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.

--- D'Souza and Wills
Component Oriented Programming 7
What is a component? (3)
4. 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.

--- Councill and Heineman
Component Oriented Programming 8
What are in common?
A piece of software
Independently deployable
Composable
Self-contained
Reusable
A set of interfaces provided to, or required from the
environment.
An executable code, which can be coupled to the code of
other components via interfaces.
Component Oriented Programming 9
What is CBSE
CBSE: Component-Based Software Engineering
How to create reusable components
How to create software products with reusable
components
Analysis, Design, Programming, Testing, Maintenance
of component-based software
Requirements, Specification, Provisioning, Assembly of
component-based software

COP: Component-Oriented Programming
Component Oriented Programming 10
Why CBSE?
Object orientation has failed but component software is
succeeding Udell, 1994
Object technology does not include the notions of independence or
late composition, mostly used to construct monolithic application.
Configuring and integrating an individual object into some given
system is not normally possible.
Object technology tends to ignore the aspects of economies and
markets. Today only small amount of catalogs of class, class
libraries, and frameworks exist.
Components are independent units of deployment!
Component Oriented Programming 11
Commonality and Difference
SP (Structured Programming)
OOP (Object-Oriented Programming)
COP (Component-Oriented Programming)

What are common?
What are different?

Component Oriented Programming 12
SP OOP COP
Divide and conquer
for managing complexity
break a large problem down into smaller pieces
Yes Yes Yes
Unification of data and function
a software entity combines data and the functions
processing those data.
improve cohesion
Yes Yes
Encapsulation
The client of a software entity is insulated from
how that software entitys data is stored or how its
functions are implemented.
Reduce coupling
Yes Yes
Identity
Each software entity has a unique identity
Yes Yes
Interface
represent specification dependency
divide a component specification into interfaces
restrict inter-component dependency
Yes
Component Oriented Programming 13
COP vs OOP and SP
Other differences?
Component Oriented Programming 14
Composability
Software entity and its ability of being integrated with
other entities

SP functions, procedures: low

OOP classes, objects: high

COP components: very high
Component Oriented Programming 15
The Interchangeability
SP: Two different implementations can never be
interchangeable.
OOP: Two different objects implementing the
same specification are interchangeable.
COP: Two different components with different
specifications are interchangeable as long as they
satisfy those interface requirements for all client
components.
Definitions
Interfaces
Contracts
Patterns
Describing a Component
To be able to describe a component completely, the
component should consist of the following elements:

A set of interfaces provided to, or required from the
environment.

An executable code, which can be coupled to the code of
other components via interfaces.
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 separation makes it possible to:
Replace the implementation part without changing the
interface
Add new interfaces (and implementations) without
changing the existing implementation
Describing an Interface
Interfaces defined in standard component
technologies using techniques such as Interface
Definition Language (IDL)
Export and Import Interfaces
We can distinguish two kinds of interfaces.
Components can export/import interfaces to/from
environments which may include other components.

An exported interface describes the services provided by
a component to the environment.

An imported interface specifies the services required by
a component from the environment.
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.
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.

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.
Design Patterns
Design patterns are widely used in the process of
designing component-based systems in which the
reusable units must be identified.

By using design patterns, it is easier to recognize those
reusable parts and either find them in the form of pre-
existing components, or develop them as reusable
units.
Concepts: Summary
Component specifications are essential for component
users who are focused on the component features,
functional and non-functional.

Patterns give an abstract and more general view of a
function, procedure or similar

Patterns can be implemented in the form of systems or
components

Component designers will use patterns in the design process
to design components more efficiently

A Component Comprised of?
Some code
The code represents the operations that the component
will perform when invoked
An interface
The interface tells the component-user everything he
needs to know in order to deploy the component
The interface of a component should provide all the
information needed by its users
The specification of a component is therefore the
specification of its interface
Component Specification
For users
The specification provides a definition of its interface,
viz. its operations and context dependencies.
Since it is only the interface that is visible to users, its
specification must be precise and complete.

For developers
The specification of a component also provides an
abstract definition of its internal structure.
Components and Interfaces
A component provides:
The implementation of a set of :
named interfaces
types
Each interface being a set of named operations
The following diagram is a UML metamodel
This model allows an interface to be implemented by
several different components, and an operation to be
part of several different interfaces
Components and Interfaces
IDL Example
interface ISpellCheck : IUnknown
{
HRESULT check([in] BSTR *word, [out] bool *correct);
};
interface ICustomSpellCheck : IUnknown
{
HRESULT add([in] BSTR *word);
HRESULT remove([in] BSTR *word);
};
library SpellCheckerLib
{
coclass SpellChecker
{
[default] interface ISpellCheck;
interface ICustomSpellCheck;
};
};
Interfaces
A component:

Implements a set of interfaces that each consists of a set
of operations

In addition, a set of pre-conditions and post conditions
is associated with each operation
Interface Specification







This model allows the same state to be associated with
several interfaces
Semantic Specification in a
UML Meta-Model
Interface Specification
context ISpellCheck::check(in word : String, out correct :
Boolean): HRESULT
pre:
word <>
post:
SUCCEEDED(result) implies correct = words->including(word)
context ICustomSpellCheck::add(in word : String) : HRESULT
pre:
word <>
post:
SUCCEEDED(result) implies words = words@pre->including (word)
context ICustomSpellCheck::remove(in word : String) : HRESULT
pre:
word <>
post:
SUCCEEDED(result) implies words = words@pre->exluding(word)
Component Specification Diagram
Similarly to interface specification diagrams,
components specification diagrams are used to specify
which interfaces components provide and require.
Specifying a component that provides interfaces
Conclusion
A component has two parts
an interface
some code

In current practice, component specification
techniques specify components only syntactically

The use of UML and OCL to specify components
represents a step towards semantic specifications

Benefits of Styles
Design reuse
well-understood solutions applied to new problems

Code reuse
shared implementations of invariant aspects of a style

Understandability of system organization
a phrase such as client-server conveys a lot of information

Interoperability
supported by style standardization
components can be independently developed with a particular style in mind

Visualizations
style-specific depictions matching engineers mental models
Some Architectural Styles
Learning the following domain/platform-independent
styles:
Pipes and Filters
2-Tiered (Client/Server)
N-Tiered
Layered
Pipes and filters were easy
The rest require a deeper understanding of
connections
Style 1: Pipes and Filters
Components are filters
transform input messages into output messages
All components of a pipe and filter architecture use the same interface
Input through provided interface
Output through required interface
Usually one provided (input) interface and one required (output) interface
Connectors are pipes
simple connections between filters provided and required interfaces
Style invariants
filters are independent
a filter has no knowledge of up- and down-stream filters
Each filter exposes a very simple interface: it receives messages on the inbound
pipe, processes the message, and publishes the results to the outbound pipe.
Style 1: Pipes and Filters
Advantages
easy understanding of the system's behavior as the composition of
filters
filter addition, replacement, and reuse
Disadvantages
batch organization of processing
interactive applications
lowest common denominator on data transmission
Commonly seen in
UNIX shells
Compilers
Signal Processing
Parallel Programming
But also useful style for Enterprise Systems
Style 1: PF Example
In many enterprise integration scenarios, a single event
triggers a sequence of processing steps, each performing a
specific function.

Consider an order processing system -- new orders arrive
from a client component in the form of a message.

Requirement 1: the message is encrypted to prevent
eavesdroppers from spying on a customer's order.

Requirement 2: the messages contain authentication
information in the form of a digital certificate to ensure that
orders are placed only by trusted customers.
Style 1: PF Example
Requirement 3: duplicate messages could be sent from
external parties (remember all the warnings on the popular
shopping sites to click the 'Order Now' button only once?).

To avoid duplicate shipments and unhappy customers, we
need to eliminate duplicate messages before subsequent order
processing steps are initiated.

To meet these requirements, we need to transform a
stream of possibly duplicated, encrypted messages
containing extra authentication data into a stream of
unique, simple plain-text order messages without the
extraneous data fields.
Style 1: PF Example
Style 2: 2-Tiered Client/Server
One of the most common styles in distributed systems
Components are clients and servers
Application logic is divided between clients and servers two tiers
E.g., client could handle presentation logic, while the server handles business
rules and the database
Clients and servers may be composite
Constraints
Server provides services to the client, but doesnt require
Clients require services of the server
A larger number of clients than servers
Semantics (meaning and implementation)
Servers do not know the number or identities of clients
Clients know servers identity
Clients and servers are often distributed
Useful whenever there is a need to separate application logic into two tiers
Style 2: 2 Tiered Client/Server
Example..
Google offers its search engine as a webservice

A range of clients use SOAP to use the provided interface of the
webservice
A webpage servlet client uses the webservice as part of its webpages
A .NET based b-2-c middleman application uses the web service to search
for best buys of products

Different clients have very different purposes but the web service
server has the same functionality

It makes sense to keep web searching and client functionality separate
to both maximize on possible uses of the server and also to enable
better maintenance

Multiplicities of usage are written on the sides of connected
interfaces
In this example, the webservice can have many clients, so we put * on the
clients required interfaces
Style 3: N-Tiered
Similar to client/server, but with a set of components,
acting as both clients and servers: servers can also be clients
of other servers
Application logic is divided between the chain of components
e.g., client could handle presentation logic, while one server
handles business rules, connected to another server that
handles the database
Clients and servers may be composite
Constraints
Servers provides services to their clients, but doesnt require
Clients require services of the server
Style 3: N-Tiered
Semantics
Servers do not know the number or identities of their
clients
Clients know servers identity
Components are usually distributed
Useful whenever there is a need to separate application
logic into software packages
Example Typical 3 Tiered Architecture
Style 3: N-Tiered
Advantages
Separation of concerns, divide and conquer approach to
solving large scale software problem
Maintenance
Disadvantages
Performance (especially if distributed components)
Style 4: Layered Architectures
Hierarchical system organization
multi-level client-server
Components are classified by layers
each layer exports an interface to be used by above layers
Constraints
Each layer acts as a 1-1 relation between each layer
Each layer communicates only with its neighbors below it
Connectors are protocols of layer interaction
Examples
Operating Systems
Network Communications
Style 4: Layered Architectures Example
HTTP Protocol Stack
Style 4: Layered Architectures
Advantages
increasing abstraction levels
Maintainability each layers role is defined
Reuse
Portability (replacing layers to work within a different
context)
Disadvantages
not universally applicable some components may be spread
around different layers
Performance
determining the correct abstraction level
In practice layer bridging may be required a layer might
need to communicate directly with a non- neighbor
Thank You