Component Diagram Usage

Question

I’m a bit confused about this type of UML diagram which I’ve seen used in non-consistent ways.

Component diagrams often represent some sort of architecture level snapshot of the application in development, they are very close to deployment diagrams, just a bit more abstract (i.e. without the node details). Some people even put annotations on them with indication of specific files or dlls. So basically they consider components as instances.

But if I’m not wrong these are classifiers, so they shouldn’t exist run-time. So is it correct to view these diagram as composed by concrete instances?

For example, let’s say that I have some sort of distributed database accessed by a middleware layer. In the class/package diagram I have one datasource class/package and one middleware class/package. In the deployment diagram I have one middleware artifact/node and more than one datasource artifacts/nodes. In the component diagram do I have to put one or more datasource components?

Answer 1

According to the UML 2.5 normative specification document that can be found here, a component is a classifier (section 11.6.4. Notation):

A Component is shown as a Classifier rectangle [...]. The attributes, operations and internal structure compartments all have their normal meaning.

It even says that you can depict "component realizations" in the same way you depict interface realizations in a Class Diagram:

A ComponentRealization is notated in the same way as a Realization dependency (i.e., as a general dashed line with a hollow triangle as an arrowhead).

(Note: Some care needs to be taken here as the same notation is used in explicit representation of provided interfaces, so this may lead to confusion if both are used on the same diagram.)

I didn't find anything specific on Component instances, but I suppose it is possible to represent those as well in the usual way.

BTW, they describe the semantics of the notion of a Component in the following way:

A Component represents a modular part of a system that encapsulates its contents and whose manifestation is replaceable within its environment.

A Component is a self-contained unit that encapsulates the state and behavior of a number of Classifiers. A Component specifies a formal contract of the services that it provides to its clients and those that it requires from other Components or services in the system in terms of its provided and required Interfaces.

A Component is a substitutable unit that can be replaced at design time or run-time by a Component that offers equivalent functionality based on compatibility of its Interfaces.