This essay has been submitted by a student. This is not an example of the work written by our professional essay writers.
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 com- position." 
The type of `unit' is significant: Minimizing coupling with the out-side world and maximizing cohesion inside the unit is wanted. However, component-based software engineering has influence from both a management and a technical perspective.
1.1. Intention for Component-Based System Engineering
The intentions of component-based system engineering can be categorized as follows:
One significant aim of any development procedure is to be cost-effective in developing the applications.
Ease of Assembly:
Components need to be designed in a style that simplifies the later assembly procedure when components are combined together to develop software systems.
This deals with the component's possibility for reuse in multiple software. In component-based software engineering, reusability is the scope to which a component is reused during the assembly process in developing applications.
Customization and Flexibility:
In component-based application engineering, when a group of components are made usable to the software developers, they can implement their software by combining components according to their specific needs.
Maintainability is the facilitate with which application system functionalities can be added, removed, or changed in a component; according to new and up-and-coming requirements.
1.2. Technical Features of Component-Based Systems
The technical traits of component-based software can be described as follows:
In component-based software engineering, coupling for a component is described as the scope to which that component is combined with other parts. Minimum coupling is wanted.
Cohesion refers to the ability of association of components within a software. In component-based system development, cohesion of a component is the scope to which its contained elements are inter-related. High cohesion is wanted.
In component-based system development, the number of parts used to implement a specific software is an significant design parameter. The balance between many small parts and a few large parts must be considered in component and software design.
2. Basis for Components
The basic concept of object-oriented development is that a software system consists of a set of interacting objects . A class is defined as the structure and behavior of objects. Objects hides information (encapsulation). This ability is extremely related for component-based software design: client components are not focused in the specific implementation of server components, only the services that are specified in their interfaces should be necessary for utilizing those components. Therefore, objects are qualified for components, guaranteed that their granularity is sufficient.
The goal of Object-Oriented analysis is to understand the application domain and identifying requirements. Object-Oriented design and implementation aim at achieving the identified requirements in a specific environment. Table 1 illustrates the basic similarities and differences between objects and components (based on ). When objects are created, a `template' is needed for their instantiation, which is their class. The instantiation mechanism can be seen as a workshop that create individual objects with own property and state. Different to that, components are deployed at some places. Several objects could be controlled by deployed components. Granularity (size of components) is a significant problem within this context.
Object-oriented programming languages often do not support explicit `uses' relationships as they are available with module definition languages  and module interconnection languages [4, 5]. This condition has good reasons: `uses' describes implementation rather than abstraction in object-oriented programming. However, for implementing components, `uses' relationships are relevant. Similar to using a class in object-oriented programming, with component-based software engineering it is relevant what a component offers, not how it realizes offered services. Anyway, it is possible to realize components without employing object techniques. A well-organized library of functions in a procedural setting is a good basis for component- based development, too.
It is important to note that inheritance is problematic for component compo- sition, because it breaks encapsulation. Inheritance is an `open' relation among classes: the inheriting class usually has full access to the internals of the base class. This allows for extensibility and incremental construction of classes. Conversely, uses relationships among classes are `closed' relations: only the public interfaces are shared, the internal implementations is encapsulated to decouple the classes. This distinction is also called the open/closed principle . With inheritance, the fragile base class problem may emerge: the question whether a base class can evolve without breaking independently developed subclasses. This problem may cause un- acceptable dependencies (coupling) among components. As discussed earlier, in component-based software engineering, low coupling and high cohesion are desired. For a more detailed discussion of the fragile base class problem refer to.
3. Reuse of Components and Software Architectures We can distinguish two classes of concerns based on whether components are used as a design philosophy independent from any concern for reusing existing components, or seen as off-the-shelf building blocks used to design and implement a component- based system.
Reuse on the design level plays an important role in component-based software engineering. On the programming level, reuse is usually accomplished by means of high-level programming language constructs, function libraries, or object-oriented class frameworks. For well-understood domains, generators  may be used for assembling applications by automatically composing pre-written components. On the design level, design patterns and established software architectures are essen- tial. However, the borderline between design and programming cannot always be pinpointed precisely. 3.1. Domain Engineering The inability of software developers to achieve low costs, high productivity, and
consistent quality has often been attributed to a lack of software reuse. Re-creating4 Component-Based Software Engineering
Domain-Specific Software Architecture
Figure 1: Relations between some roles and artifacts in the DSSA engineering process. Hollow diamonds indicate part-of relations. We use the UML notation for actors to model the roles .
similar systems without capturing components for future development wastes time, money, and human resources. While a universal software reuse solution may prove
ective, signicant improvements can be realized by focusing on well-understood
domains. Architectures support domain-specic reuse by serving as frameworks for understanding families of systems, which may be called product lines [7, 8, 9, 10]. Domain engineering  is an activity for building reusable components, whereby
the systematic creation of domain models and architectures is addressed. Domain
engineering aims at supporting application engineering which uses the domain mod- els and architectures to build concrete systems. The emphasis is on reuse and prod- uct lines. The Domain-Specic Software Architecture (DSSA) engineering process was introduced to promote a clear distinction between domain and application re- quirements . A Domain-Specic Software Architecture consists of a domain model and a reference architecture, and guides in reusing components as modeled
in Figure 1. Appropriate management of component libraries is essential for suc- cessful reuse. The DSSA process consists of domain analysis, architecture modeling, design and implementation stages as illustrated in Figure 2. Domain models represent the set of requirements that are common to systems within a specic domain. Usually, those systems can be grouped into product
lines, for instance for the insurance or banking domain. Product lines cover both
commonality and variance for a family of systems. There may be many domains, or areas of expertise, represented in a single product line and a single domain may span multiple product lines. Domain analysis is the process of identifying, collecting, organizing, and representing the relevant information in a domain, based upon theComponent-Based Software Engineering 5