Please enable JavaScript.
Coggle requires JavaScript to display documents.
11. Component-Based Software Architecture (Overview (vs Object-Oriented…
11. Component-Based Software Architecture
Overview
Divides a problem into
subproblems
each associated with component partitions
The
interfaces
of the components play
important
roles
Motivation
: component
reusability
a component
encapsulates
the functionality and behaviors of a software element into a reusable and self-deployable
binary unit
Designs can make use of existing reusable commercial off-the-shelf (
COTS
) components or ones
developed in-house
They may
produce reusable components
for future reuse
=> increases overall system reliability
A
component
is a deployable software package that can provide services to its clients
It may also itself require
services
from other
components
.
A component remains self-contained and substitutable as long as its interface is unchanged.
vs Object-Oriented design
Represents a
higher level of abstraction
than an equivalent object-oriented design; the former defines
components and connections between them
instead of classes and connections between classes
A
component
is a higher-level concept, usually incorporating
more than one class
=> in component-oriented design we
first identify all components and their interfaces
Advantages over OO design
:
reduced time in market
lower development costs by reuse of existing components
increased reliability with reuse of existing components
Challenge
: to design components in such a way as to make it possible to adapt existing components in order to reuse them
Standard component frameworks
: COM/DCOM, JavaBean, EJB, CORBA, .NET, web services, and grid services.
What Is a Component?
A component is a modular (cohesive), deployable (portable), replaceable (plug-and-play), and reusable
set of well-defined functionalities
that encapsulates its implementation and exports it as a
higher-level interface
UML component notation
:
The circle interface symbol, called
provided port
, represents the services the component provides
The cup-like interface symbol, called
required port
, represents the services the component requires from other components
Ports may be connected
synchronously
or
asynchronously
, or connected via I/O streams.
A UML component can be mapped to any target technology component. Example:
EBJ Component (.jar file)
Java Web Component (.war file)
What about MS .Net Component? => .dll file
Why use components?
reusability
productivity
composability
adaptability
scalability
reliability
many other features
Component Implementation
Usually consists of a set of class files
Abstract Interface
Concrete Implementation Classes
Why Interface & Implementation?
Separation of Interface and Implementation allows
changeability
!
Component must have a
clear functionality
and be
self-contained
.
Components must be designed and developed for
easy reuse
.
Components should be very
reliable
.
It should be
easy to replace
or adapt any existing components.
It should also be possible to scale the service capacity by replacing components to increase functionality in the system
Principles of Component-Based Design
Connections of Components
Connectors connect components, specifying and ruling their interaction.
Three categories of connections:
•
Ball and cup
(b2c or c2b) connection: connects two internal or two external components
•
Ball to ball
(b2b) or
cup to cup
(c2c) delegation: connects an external ball (cup) port to an internal ball (cup) port
•
I/O stream connection
Component-based software design is
design by contract
. The contract specifies the
interface
between the component and its clients.
we can substitute any component in the system
Component-Level Design Guidelines
Before the design phase, we have:
Use case modeling
Business concept modeling
Use case diagrams
describe user interactions with the system which indicate all necessary operations (interfaces) of the component
We can map use case diagrams to the provided service interfaces of the first-cut component specification
The business concept diagram
depicts the relationships of the business process entities in the domain.
We can
extract
the business process entities that can exist independently without any associated dependency on other entities.
We can
recognize and discover
these independent entities as
new components
A
collaboration
is any identifiable slice of functionality that describes a meaningful service involving, in general, several concepts
A collaboration can be seen as the
implementation of a use case
.
=> Thus, for each use case U, there will be a collaboration diagram “encapsulated” in a component C
Starts from Use Case Diagram. May also need business concept diagram
Mapping:
Use case 🡪 interface provider
Conceptual classes 🡪 modules of components
If necessary, big components can be further decomposed
Applicable Domain
Applications where the
interface contracts
between subsystems are clear
Applications that
require loose coupling
between the components and where many reusable components are available
Suitable for the
class library system
organization (.NET class library and Java API are built in component architecture)
Evaluation
Benefits
:
Reusability
of components.
System
maintenance and evolution
Independency
and
flexible connectivity
of components.
Independent development
of components by different groups in parallel.
Productivity
Many
OO design tools
can also be used for component-based software development.
Limitations
:
Difficult to find suitable available components to reuse.
Adaptation of components is an issue
Few component-oriented dedicated design tools are available.
