7.1 Characterizing the Component Problem

	The term software component has a broad meaning in the software community. A software package, a Web
	service, or a module that encapsulates a set of related functions (or data) is known as individual component.

	Components are modular and cohesive as all system processes are placed into separate components so that
	all of the data and functions inside each component are semantically related (just as with the contents of classes).

Characteristics of Components share the same theme as:

"Encapsulates functionality,"

"Communicates through well-defined interfaces,"

"Provides a simple plug-and- play model," and

"Allows easy replacement of system behaviors."

	Cheesman & Daniels presented a view of components from the complete software lifecycle and discussed
	components in the following "forms:"

Component interface: Defines a set of features offered; analogous to a CORBA or Java interface.

		Component specification: A software unit that describes behavior for a component as a set of Component
		Interfaces.

7.1 Characterizing the Component Problem

Component implementation: An assembly that implements a Component Specification

Installed component: A specific installation and configuration of a Component Implementation

Component object: A run-time instance of a component with unique state and identity.

7.1 Characterizing the Component Problem

Figure 7.1: Example component interface, specification and implementationBuild-Time vs. run-Time

7.1 Characterizing the Component Problem

	Software components are an independently deployable and enactable portion of a software system.

	Deploying and enacting a component (the run-time view of a component) can lead to issues.

	The 4+1 software architecture model (Krutchen) espoused by the rational unified process (RUP) addresses, at
	least through notation, the issues of deploying and enacting components.

Figure 7.2 shows the 4+1 model and its related views.

Figure 7.2 Rational unified process 4+1 architectural views