Component diagram shows components and dependencies 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.
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.
Connector in components extends connector from internal structures. It specifies a link that enables communication between two or more instances. Connector was extended in the components to include contracts and specific notation.
Connector linking components could be either:
Kind of connector attribute is derived: a connector with one or more ends connected to a port that is not on a part and that is not a behavior port is a delegation; otherwise it is an assembly.
Connector's contract is set of behaviors that specify the valid interaction patterns across the connector.
A delegation connector is a connector that links the external contract of a component (as specified by its ports) to the realization of that behavior. It represents the forwarding of events (operation requests and events): a signal that arrives at a port that has a delegation connector to one or more parts or ports on parts will be passed on to those targets for handling.
A delegation connector is a declaration that behavior that is available on a component instance is not actually realized by that component itself, but by one or more instances that have “compatible” capabilities. These situations are modeled through a delegation connector from a Port to compatible Ports or Parts.
Delegation connectors can be used to model the hierarchical decomposition of behavior, where services provided by a component may ultimately be realized by one that is nested multiple levels deep within it. The word delegation suggests that concrete message and signal flow will occur between the connected ports, possibly over multiple levels. It should be noted that such signal flow is not always realized in all system environments or implementations (i.e., it may be design time only).
A port may delegate to a set of ports on subordinate components. In that case, these subordinate ports must collectively offer the delegated functionality of the delegating port. At execution time, signals will be delivered to the appropriate port. In cases where multiple target ports support the handling of the same signal, the signal will be delivered to all these subordinate ports.
A delegation connector is notated as a connector from the delegating port to the handling port or part.
Delegation connector from the delegating port to the UserServlet part
If the delegation is handled by a simple port, then the connector may optionally be shown connected to the single lollipop or socket.
Delegation connector from the delegating port to the simple port of SearchEngine
Delegation connector from the simple port of Authentication component to the delegating port
An assembly connector is a connector between two or more parts or ports on parts that defines that one or more parts provide the services that other parts use.
The execution time semantics for an assembly connector are that signals travel along an instance of a connector. Multiple connectors directed to and from different parts, or n-ary connectors where n > 2, indicates that the instance that will originate or handle the signal will be determined at execution time.
The interface compatibility between ports that are connected enables an existing component in a system to be replaced by one that (minimally) offers the same set of services. Also, in contexts where components are used to extend a system by offering existing services, but also adding new functionality, connectors can be used to link in the new component definition.
Assembly connector is notated as a connector between two or more parts or ports on parts.
Assembly connector between ports of Authentication and Customers components
When an assembly connector connects simple ports (ports that provide or require a single interface), it may be notated by a "ball-and-socket" connection between a provided interface and a required interface.
Assembly connector between simple ports of Authentication and Customers components
Ball-and-socket notation may not be used to connect "complex" ports or parts without ports.
Where multiple components have simple ports that provide or require the same interface, a single symbol representing the interface can be shown, and lines from the components can be drawn to that symbol. This presentation option is applicable whether the interface is shown using "ball-and-socket" notation, or just using a required or provided interface symbol.
Assembly connector that assembles three parts
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. In effect, it forms an abstraction for a collection of model elements. In that case, a component owns a set of 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