Concepts: Component
Topics
Definition 
The software industry and literature use the term "component" to refer to many different things. It is often used in the broad sense to mean "a constituent part". It is also frequently used in a narrow sense to denote specific characteristics that enable replacement and assembly in larger systems.
In the RUP, we use the term "component" to mean an encapsulated part of a system, ideally a non-trivial, nearly independent, and replaceable part of a system that fulfills a clear function in the context of a well-defined architecture. This includes:
- design component — a significant encapsulated part of the design, and so includes Design Subsystems and sometimes significant Design Classes and Design Packages.
- implementation component — a significant encapsulated part of the implementation, generally code that implements a design component.
Ideally the design reflects the implementation, and so one can refer to just components, each component having a design and an implementation.
The UML defines component as
A modular, deployable, and replaceable part of a system that encapsulates implementation and exposes a set of interfaces. A component is typically specified by one or more classifiers (e.g., implementation classes) that reside on it, and may be implemented by one or more artifacts (e.g., binary, executable, or script files).
The RUP usage of the term component is broader than the UML definition. Rather
than define components as having characteristics such as modularity, deployability,
and replaceability, we instead recommend these as desirable characteristics
of components. See the section below on Component Replaceability.
Component Replaceability
In RUP and UML terminology, components should be replaceable. However, this may only mean that it exposes a set of interfaces that hide an underlying implementation.
There are other, stronger, kinds of replaceability. These are listed below.
Source-file replaceability
If two classes are implemented in a single source code file, then each of the classes cannot usually be separately versioned and controlled.
However, if a set of files fully implements a single component, and no other component, then the component is source-file replaceable. This characteristic makes it easier for component source code to be version-controlled, baselined, and re-used.
Deployment replaceability
If two classes are deployed in a single executable, then each class is not independently replaceable in a deployed system.
A desirable characteristic of larger granularity components is to be "deployment replaceable", allowing new versions of the component to be deployed without having to re-build the other components. This usually means there is one file or one set of files that deploy the component and no other component.
Run-time replaceability
If a component can be redeployed into a running system, then it is referred to as "run-time replaceable". This enables software to be upgraded without loss of availability.
Location transparency
Components with network addressable interfaces are referred to as having "location transparency". This allows components to be relocated to other servers, or to be replicated on multiple servers, to support fault tolerance, load balancing, and so on. These kinds of components are often referred to as "distributed" or "distributable" components.
Modeling of Components
The UML component is a modeling construct that, much like the UML subsystem, provides the following capabilities:
- can group classes to define a larger granularity part of a system
- can separate the visible interfaces from internal implementation
- can have instances that execute at run-time
The RUP definition of "component" is broader than that of the UML definition, and so other modeling constructs, such as class, package, and subsystem, are often referred to as representing components. RUP considers the UML component modeling construct as an alternative notation for Artifact: Design Subsystem. See Guidelines: Design Subsystem for details.
Note that in UML 1.3 and earlier versions of the UML, the "component" notation was used to represent files in the implementation. Files are no longer considered "components" by the latest UML definition. However, many tools and UML profiles still use the component notation to represent files. See Guidelines: Implementation Element for more discussion on representing files in the UML.
