1. Term paper
Efficient Performance Models in Component
based software engineering
Submitted to-Preeti Sikka
Submitted by- Sukhdeep Singh (11114103)
Section- D1E09
Roll no- B58
Class roll no- 60

2. Introduction
Today’s software systems are becoming more and more complex, large
scale, and difficult to control. These things cause production costs to
skyrocket and higher risks to move to new technologies. As a result of
this there is a demand for a software development paradigm that will
lower cost and raise efficiency.
One of the most promising development models is component based
software engineering. This model is based on the notion that
developers can select appropriate off-the-shelf software components
and build them together using well defined software architecture .
Component based software engineering is concerned with the rapid
assembly of systems from components. These components and
frameworks have certified properties; which provide the basis for
predicting the properties of systems built from components. This kind
of software approach is very different from the traditional approach in
which the software is built from the ground up. Each of these
commercial off-the-shelf (COTS) components can be developed by
different companies using even different languages and platforms. If
you look at Figure 1 you can see how these COTS can be taken out of a
component repository and assembled into a target software system.

3. What is a Component?
A component is an abstract opaque implementation of functionality
subject to third-party composition that conforms to a component
model . In other words a component is a small system itself that can
fulfill one or more of the functionality requirements for a system. A
component includes the functionality that it was designed for and the
coordination of this small system works or how the component will
interact with the external world.
As stated previously components are COTS, which keeps the
implementation of the component hidden from the consumer. Each
component is viewed as intellectual capital that must be protected.
This form of information hiding also keeps the implementation details
from being changed during development.
Software components can be viewed in two different ways: as
implementation or as architectural abstractions. When viewed as
implementations the components can be deployed and assembled in to
larger systems or subsystems. When viewed as architectural

4. abstractions they are used to express design rules that impose a
standard coordination model that must be then followed by all
components. These design rules then take the form of a component
model, and all components must conform to this model .
Component Model
Component models specify the design rules that must be obeyed by the
components. These design rules are used to improve composition by
removing sources of interface mismatches, for example mismatched
assumptions. These rules ensure that the quality attributes in the
system are achieved and that components can be easily added into a
system or runtime environment.
Two components can only interact if they are sharing the same
assumptions and when components follow the component model it
establishes the assumptions that those components must use.
Obviously there will be some aspects of a component that will be
unique to that component; however the standardized assumptions are
put in place to protect against control flow and synchronization issues .
A physical example of a component assumption is Lego bricks. All of
the pieces are designed to fit together within the bumps or raises
located on the top of the bricks. The bottom has a female end and the
top a male end. These are easy to build together even with differing
pieces because they are designed with assumptions that make adding
additional parts easy.
In general it is agreed that the quality attributes of a system will
depend upon the software structure of a system. By standardizing the
types of components that are used in a system and their patterns of

5. interaction a system can meet the desired quality characteristics
because these are predictable and measureable.
Software Lifecycle Process Model:
Lifecycle processes include all activities of a product or a system during
its entire life, from the business idea for its development, through its
usage and its completion of use. Different models have been proposed
and exploit in software engineering, and different models have exhibit
their (in)abilities to efficiently govern all activities required for a
successful development and use of products. We can distinguish two
main groups of models: Sequential and evolutionary.
Software development activities
Planning
Planning is an objective of each and every activity, where we want to
discover things that belong to the project. An important task in creating
a software program is extracting the requirements or requirements
analysis. Customers typically have an abstract idea of what they want as
an end result, but do not know what software should do. Skilled and
experienced software engineers recognize incomplete, ambiguous, or
even contradictory requirements at this point. Frequently
demonstrating live code may help reduce the risk that the
requirements are incorrect.
Once the general requirements are gathered from the client, an
analysis of the scope of the development should be determined and
clearly stated. This is often called a scope document.
Certain functionality may be out of scope of the project as a function of
cost or as a result of unclear requirements at the start of development.
If the development is done externally, this document can be considered

6. a legal document so that if there are ever disputes, any ambiguity of
what was promised to the client can be clarified.
Implementation, testing and documenting
Implementation is the part of the process where software
engineers actually program the code for the project.
Software testing is an integral and important phase of the software
development process. This part of the process ensures that defects are
recognized as soon as possible.
Documenting the internal design of software for the purpose of future
maintenance and enhancement is done throughout development. This
may also include the writing of an API, be it external or internal. The
software engineering process chosen by the developing team will
determine how much internal documentation (if any) is necessary.
Plan-driven models (e.g., Waterfall) generally produce more
documentation than Agile models.
Deployment and maintenance
Deployment starts directly after the code is appropriately tested,
approved for release, and sold or otherwise distributed into a
production environment. This may involve installation, customization
(such as by setting parameters to the customer's values), testing, and
possibly an extended period of evaluation.
Software training and support is important, as software is only effective
if it is used correctly.
Maintaining and enhancing software to cope with newly discovered
faults or requirements can take substantial time and effort, as missed
requirements may force redesign of the software.

7. CORBA Component Model (CCM):
CORBA Component Model (CCM) is an addition to the family of CORBA
definitions. It was introduced with CORBA 3 and it describes a standard
application framework for CORBA components. Though not dependent
on "language independent Enterprise Java Beans (EJB)", it is a more
general form of EJB, providing four component types instead of the two
that EJB defines. It provides an abstraction of entities that can provide
and accept services through well-defined named interfaces called ports.
The CORBA Component Model (CCM) is a current example of
component middleware that addresses limitations with earlier
generations of DOC middleware. The CCM specification extends the
CORBA object model to support the concept of components and
establishes standards for implementing, packaging, assembling, and
deploying component implementations. From a client perspective, a
CCM component is an extended CORBA object that encapsulates
various interaction models via different interfaces and connection
operations. From a server perspective, components are units of
implementation that can be installed and instantiated independently in
standard application server runtime environments stipulated by the
CCM specification. Components are larger building blocks than objects,
with more of their interactions managed to simplify and automate key
aspects of construction, composition, and configuration into
applications.
A component is an implementation entity that exposes a set of ports,
which are named interfaces and connection points that components
use to collaborate with each other. Ports include the following
interfaces and connection points:

8. Facets, which define a named interface that services method
invocations from other components synchronously.
Receptacles, which provide named connection points to
synchronous facets provided by other components.
Event sources/sinks, which indicate a willingness to exchange
event messages with other components asynchronously.
Components can also have attributes that specify named parameters
that can be configured later via metadata specified in component
property files.
A container provides the server runtime environment for component
implementations called executors. It contains various pre-defined
hooks and operations that give components access to strategies and
services, such as persistence, event notification, transaction,
replication, load balancing, and security. Each container defines a
collection of runtime strategies and policies, such as an event delivery
strategy and component usage categories, and is responsible for
initializing and providing runtime contexts for the managed
components. Component implementations have associated metadata
written in XML that specify the required container strategies and
policies.
Advantages and Disadvantages of CBSE
What are the advantages of using the CBSE model? The following
reasons are some of the significant advantages that component based
development offers. The first being independent extensions. Legacy
software is plagued by a lack of flexibility, components are units of
extension and the component model describes exactly how an

9. extension can be made. The component model allows easy extensions
for systems. Another advantage of component based development is
the component market . The component models provide standards
that independently developed components can follow and this will
provide large system developers with fewer unanticipated interactions
between software components. This allows independent developers to
develop components for niche markets. A big advantage of component
based software development is the reduced time to market. Using
already developed components means less design, coding, and testing
which in turn lowers production time as well as production costs .
As with everything there are some disadvantages to component based
development. The time and effort it takes to develop a software
component is large and thus the cost to develop a component can be
high. The software components may have more functionality than a
developer may need for a project that they are working on. In some
cases a component may have to be used up to 5 times before the cost
of purchasing a component can be justified or recovered. Another
disadvantage is that requirements in some component based
technologies are lacking, however with the three current big
technologies it is becoming less of a problem. There also could be a
conflict between the usability and reusability aspects of components.
Components need to be general and adaptable which leads to
components costs that are more expensive and more complicated to
use . The last disadvantage of CBSE is that the maintenance cost
decreases for the application but can increase for the component,
depending on the complexity of the encompassing system. The

10. separate life-cycles together with different requirements for the
application and component could be problematic.
Conclusion
Component based software engineering is a very interesting and useful
software development model. It provides an easy way to assemble
software using components that have been previously developed. It
offers a quick and cheap way to develop software systems. As its
popularity grows the market for already development software
components grows and offers an interesting direction for software
evolution. In order for this type of model to see success there is a great
need for well defined standards for components. These standards
would make it possible to assume quality for software components and
make it easy for large system developers to fit components into their
software frameworks. It is an exciting technology and it will be
interesting to see it progress in the future.