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.
The Unified Modeling Language [UML05] defines component as follows:
A modular part of a system that encapsulates its contents and whose manifestation is replaceable within its
environment. A component defines its behavior in terms of provided and required interfaces. As such, a
component serves as a type, whose conformance is defined by these provided and required interfaces
(encompassing both their static as well as dynamic semantics).
A component is defined as a subtype of structured class. Therefore, a component has attributes and
operations, is able to participate in associations and generalizations, and has internal structure and ports.
Here, we use the term component in a broader way than the UML definition. Rather than defining
components as having characteristics, such as modularity, deployability, and replaceability, we instead recommend these
as desirable characteristics of components. We use component to mean an encapsulated part of a
system that is nontrivial, nearly independent, and replaceable part of a system that fulfills a clear function
in the context of well-defined architecture. This includes two types of components:
Design component. A significant encapsulated part of the design that 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; therefore, you can simply refer to components, with each
component having a design and an implementation.
Components interact through interfaces and may be composed of successively smaller components and interfaces.
In UML terminology, components should be replaceable. However, this may mean only that the component exposes a set of
interfaces that hide an underlying implementation.
There are other, stronger, kinds of replaceability: .
Source file replaceability: If two classes are implemented in a single source code file,
then those 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 source files are replaceable.
This characteristic makes it easier to use version control, to use the file as a baseline, and to reuse the
Deployment replaceability: If two classes are deployed in a single executable file, then
each class is not independently replaceable in a deployed system. It is desirable for larger-granularity
components to be replaceable during deployment, which allows new versions of the component to be deployed
without having to rebuild the other components. This usually means that 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 you to upgrade software without loss of
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.
A component may or may not be directly instantiated at run time.
An indirectly instantiated component is implemented, or realized, by a set of classes, subcomponents, or parts. The
component itself does not appear in the implementation; it merely serves as a design that an implementation must
follow. The set of realizing classes, subcomponents, or parts must cover the entire set of operations specified in the
provided interface of the component. The manner of implementing the component is the responsibility of the implementer.
A directly instantiated component specifies its own encapsulated implementation. It is instantiated as an addressable
object, which means that a design component has a corresponding construct in the implementation language; therefore, it
can be referenced explicitly.
The UML component is a modeling construct that provides the following capabilities:
Group classes to define a larger granularity part of a system
Separate the visible interfaces from internal implementation
Execute instances run-time
A component includes provided and required interfaces that form the basis for wiring
components together. A provided interface is one that is either implemented directly by the component
or one of its realizing classes or subcomponents, or it is the type of a provided port of the component. A
required interface is designated by a usage dependency of the component or one of its realizing
classes or subcomponents, or it is the type of a required port.
A component has an external view (or black box view) through its publicly visible properties and operations
.Optionally, a behavior such as a protocol state machine may be attached to an interface, a port, and the component
itself to define the external view more precisely by making dynamic constraints in the sequence of operation calls
explicit. The wiring between components in a system or other context can be structurally defined by using dependencies
between component interfaces (typically on component diagrams).
Optionally, you can make a more detailed specification of the structural collaboration by using parts and connectors in
composite structures to specify the role or instance-level collaboration between components. That is the component's
internal view (or white-box view) through its private properties and realizing classes or subcomponents. This
view shows how the external behavior is realized internally. The mapping between external and internal views is by
dependencies on components diagrams or delegation connectors to internal parts on composite structure diagrams.
A number of UML standard stereotypes exist that apply to components, including <<subsystem>> to model
large-scale components, and <<specification>> and <<realization>> to model components with
distinct specification and realization definitions, where one specification may have multiple realizations.
The recommendation is to use components as the representation for design subsystems.
UML Definitions -- A History
The definition of component with the UML has changed over time with the release of different versions. The
version of UML you use may be constrained by the capabilities of the modeling tools you use. That is why the
definitions from 1.3 to 2.0 are provided here.
UML 2.0 defined component as the following:
...a modular part of a system that encapsulates its contents and whose manifestation is replaceable within its
A component defines its behavior in terms of provided and required interfaces. As such, a component serves as a
type whose conformance is defined by these provided and required interfaces (encompassing both their static as
well as dynamic semantics).
UML 1.5 defined component as the following:
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 classes or subcomponents that reside on it and
may be implemented by one or more artifacts (e.g., binary, executable, or script files).
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 definitions. However, many
tools and UML profiles still use the component notation to represent files.