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

IntroductionToday’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.

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

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 ModelComponent 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 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

PlanningPlanning 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

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 documentingImplementation 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 maintenanceDeployment 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.

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:

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 CBSEWhat 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 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 separate life-cycles together with different requirements for the application and component could be problematic.

ConclusionComponent 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.