There are several definitions of the component-based approach. [BRJ99] define a component as a "physical and replaceable part of a system that conforms to and provides the realization of a set of interfaces." This definition is broad and considers the component to be an organizational concept representing a set of functionalities that can be reused as a unit. According to this definition documents, executables, files, libraries and tables could be considered as components. The emphasis in this definition is on reuse.

Microsoft Corp. has a slightly different definition. In "Component Definition Model," [BBC99] define a component as a "software package which offers services through interfaces." The emphasis in this definition is on service provider. The service provider approach considers a component to be a piece of software that provides a set of services to its users. Services are grouped into coherent, contractual units referred to as interfaces [Bro99]. Users can utilize services offered by knowing the component's interface specification, or contract.

Both the reuse and service provider perspectives of a component introduce the important distinction between its public interface (what the component does) and its implementation in a particular programming environment (how the component does it). This distinction addresses the issue of how the component should be designed in order to be an independent and replaceable piece of software with minimal impact on the users.

In other words, components are reusable pieces of software code that serve as building blocks within an application framework. [BW98] conclude that although components fit better with the object-oriented technology, they are often used in non object-oriented programming environments representing a chunk of functionalities that a system should provide. Most such environments provide an ad hoc way of defining an interface, limiting its scope and use. The object-oriented paradigm provides formal languages for defining an interface and its contract, broadening its scope and reutilization opportunities.

In traditional programming, most of the times the focus is developing a single stand-alone system, where all variables and procedures are located in a single container, referred to as the main program. In contrast, the component-

based approach has as its focus the building of a set of reusable components from which a family of applications can be assembled [Bro99]. The component-based paradigm addresses a number of important questions related to the optimal size of a component, the kind of documentation that needs to be provided so others can use components, and how the assembly of existing components needs to be performed.

Every component has a name that distinguishes it from other components. The name is a textual string. The UML symbol for a component is shown in Figure 3-9.



Figure 3-9. The UML symbol for a component.

There are three types of software components [BRJ99].

Deployment Components

Deployment components include components that can form an executable system, such as dynamic libraries (DLLs) and executables (EXEs). Included in this category are other object models such as COM+, CORBA and Enterprise Java Beans or object models such as dynamic Web pages and database tables.

Work Product Components

Work product components are created from source code files or data files. They do not directly participate in an executable system but are the work product of development that is used to create an executable system.

Execution Components

These components are created as a consequence of an executing system, such as COM+ object, which is instantiated from a DLL.

There is a great similarity between the concepts of component and class. The most important one is that both components and classes may implement a set of interfaces. They both can be used as modeling artifacts, i.e., participate in relationships, have dependencies, etc. [BRJ99].

The fundamental difference between components and classes is that a component usually offers its services only through interfaces, whereas a class may or may not implement any interfaces. A component is designed to be part of a system; it is a physical entity that offers its services through interfaces. A component may be reused across many systems. The process of creating components as modeling entities uses the principle of encapsulation.

0 0

Post a comment