Component
A component is a class representing a modular part of a system with encapsulated content and whose manifestation is replaceable within its environment.
A component has its behavior defined in terms of provided interfaces and required interfaces (potentially exposed via ports).
Component serves as a type whose conformance is defined by these provided and required interfaces (encompassing both their static as well as dynamic semantics). One component may therefore be substituted by another only if the two are type conformant.
Larger pieces of a system’s functionality may be assembled by reusing components as parts in an encompassing component or assembly of components, and wiring together their required and provided interfaces.
A component is modeled throughout the development life cycle and successively refined into deployment and run-time. A component may be manifested by one or more artifacts.
Indirectly instantiated component is defined at design time but does not exist as addressable object at execution time. Runtime behavior of the component and its ports is defined by the runtime behavior of classifiers or parts realizing it. Several standard stereotypes assume this attribute, e.g., «Specification», «Focus», «Subsystem».
Internals of component are hidden and inaccessible other than as provided by its interfaces. Although it may be dependent on other elements in terms of interfaces that are required, a component is encapsulated and its dependencies are designed such that it can be treated as independently as possible.
Notation
A component is shown as a classifier rectangle with the keyword «component».
WeatherServices component
Optionally, a component icon similar to the UML 1.4 icon can be displayed in the top right corner of the component rectangle. If the icon symbol is shown, the keyword «component» may be omitted.
UserServices component
A component may be manifested by one or more artifacts, and in turn, that artifact may be deployed to its execution environment. A deployment specification may define values that parameterize the component’s execution.
Provided Interface
A provided interface is the one that is either
- realized directly by the component itself, or
- realized by one of the classifiers realizing component, or
- is provided by a public port of the component.
Weather Services component provides (implements)
Weather Forecast interface
Required Interface
A required interface is either
- designated by usage dependency from the component itself, or
- designated by usage dependency from one of the classifiers realizing component, or
- is required by a public port of the component.
User Services component requires IOrderServices interface
External View of Component
A component has an external view or "black-box" view by means of interface symbols sticking out of the component box exposing its publicly visible properties and operations.
Optionally, a behavior such as a protocol state machine may be attached to an interface, port, and to the component itself, to define the external view more precisely by making dynamic constraints in the sequence of operation calls explicit. Other behaviors may also be associated with interfaces or connectors to define the "contract" between participants in a collaboration (e.g., in terms of use case, activity, or interaction specifications).
Alternatively, the interfaces and/or individual operations and attributes can be listed in the compartments of a component box (for scalability, tools may offer a way of listing and abbreviating component properties and behavior).
External view of User Services component - it provides
IUserServices interface and requires IOrderServices interface
For displaying the full signature of an interface of a component, the interfaces can also be displayed as typical classifier rectangles that can be expanded to show details of operations and events.
Standard Component Stereotypes
There are several standard UML stereotypes that apply to components:
| Name | Description |
|---|---|
| «BuildComponent» | A collection of elements defined for the purpose of system level development activities, such as compilation and versioning. |
| «Entity» |
A persistent information component representing a business concept.
Entity component Customer |
| «Implement» | Implement is a component definition that is not intended to have a specification itself. Rather, it is an implementation for a separate «Specification» to which it has a dependency. |
| «Process» | Process is a transaction based component. |
| «Realization» |
Realization is
a classifier
that specifies a domain of objects and that also defines the physical implementation of those objects.
For example, a component stereotyped by «Realization» will only have realizing classifiers that implement behavior specified by a separate «Specification» component. This differs from «ImplementationClass» because an implementation class is a realization of a class that can have features such as attributes and methods that are useful to system designers. |
| «Service» |
Service is a stateless, functional component.
Service component WeatherServices |
| «Specification» |
Specification is
a classifier
that specifies a domain of objects without defining the physical implementation of those objects.
For example, a component stereotyped by «Specification» will only have provided and required interfaces, and is not intended to have any realizing classifiers as part of its definition. This differs from «type» because a «type» can have features such as attributes and methods that are useful to analysts modeling systems. «Specification» and «Realization» are used to model components with distinct specification and realization definitions, where one specification may have multiple realizations. |
| «Subsystem» |
Subsystem is
a component representing unit of hierarchical decomposition for large systems,
and is used to model large scale components.
Definitions of subsystems may vary among different domains and software methods.
It is expected that domain and method profiles will specialize this element.
A subsystem is usually indirectly instantiated. A subsystem may have specification and realization elements. |
History
Component notation as a classifier rectangle with «component» keyword was introduced in UML 2.0.
In the previous versions of UML 1.x notation for component was a rectangle with two small rectangles protruding from its side. For backward compatibility reasons, this notation may still be used in UML 2.5.
CustomerEJB component
in UML 1.x notation.
In UML 1.4.2 stereotype «entity» represented a passive class, i.e. class whose objects do not initiate interactions on their own. «Entity» became a persistent information component in UML 2.0.
Stereotype «process» specified a classifier representing a heavy-weight flow of control in UML 1.4.2. «Process» became a transaction based component in UML 2.0.
In UML 1.4.2 «subsystem» is a special kind of a package used to represent a behavioral unit in the physical system, and hence in the model, and to serve as a specification unit for the behavior of its contained model elements. «Subsystem» became a component stereotype to represent unit of hierarchical decomposition for large systems in UML 2.0.
UML 2.0 also introduced standard component stereotypes «BuildComponent», «Implement», and «Service».
