UML Component Diagrams
Component diagram shows components, provided and required interfaces, ports, and relationships between them. This type of diagrams is used in Component-Based Development (CBD) to describe systems with Service-Oriented Architecture (SOA).
Component-based development is based on assumptions that previously constructed components could be reused and that components could be replaced by some other "equivalent" or "conformant" components, if needed.
The artifacts that implement component are intended to be capable of being deployed and re-deployed independently, for instance to update an existing system.
Components in UML could represent
- logical components (e.g., business components, process components), and
- physical components (e.g., CORBA components, EJB components, COM+ and .NET components, WSDL components, etc.),
along with the artifacts that implement them and the nodes on which they are deployed and executed. It is anticipated that profiles based around components will be developed for specific component technologies and associated hardware and software environments.
The following nodes and edges are typically drawn in a component diagram: component, interface, provided interface, required interface, class, port, connector, artifact, component realization, dependency, usage. These major elements are shown on the picture below.
The major elements of UML component diagram - component, provided interface, required interface, port, connectors.
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.
A component is shown as a classifier rectangle with the keyword «component».
Optionally, a component icon similar to the UML 1.4 icon can be displayed in the right hand corner.
For backward compatibility reasons, the UML 1.4 notation with protruding rectangles can still be used.
Component CustomerEJB in UML 1.x notation
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.
Standard Component Stereotypes
There are several standard UML stereotypes that apply to components:
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.
UML Standard Profile defines process as a transaction based component.
Service is a stateless, functional component.
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.
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 «implementation class» 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.
It seems to duplicate «realization».
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
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.
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.
Component Realization is specialized realization dependency used to (optionally) define classifiers that realize the contract offered by a component in terms of its provided interfaces and required interfaces.
A component’s behavior may typically be realized (or implemented) by a number of Classifiers. In effect, it forms an abstraction for a collection of model elements. In that case, a component owns a set of component realization dependencies to these classifiers.
A component realization is notated in the same way as the realization dependency, i.e., as a general dashed line from implementing classifiers to realized component with hollow triangle as an arrowhead.
Component UserService realized by UserServlet and UserDAO.
For the purpose of applications that require multiple different sets of realizations for a single component specification, a set of standard stereotypes are defined in the UML Standard Profile. In particular, «specification» and «realization» are defined there for this purpose.
Component could be shown using internal view or "white-box" view exposing its private properties and realizing classifiers. This view shows how the external behavior is realized internally. The realizing classifiers could be listed in an additional «realizations» compartment. Compartments may also be used to display a listing of any parts and connectors, or any implementing artifacts.
White box view of User Services component - it is realized by UserServlet and UserDAO and manifested by UserService.jar artifact
Alternatively, the internal classifiers that realize the behavior of a component may be displayed nested within the component shape.
White box view of User Services component - it is realized by UserServlet and UserDAO