If I understand the UML 2.5.1 spec correctly, the definitions and constraints for UMLClassDiagram and UMLComponentDiagram are identical and furthermore the set of things those diagrams may show are identical.

So whether I call a diagram a class or component diagram is a matter of taste and clarity.

Have I missed something?

The diagrams themselves, and their constraints, are defined concisely in Annex B:

Page 728

B.7.10 UMLComponentDiagram [Class]

B.7.10.1 Description
  See Annex A.
B.7.10.2 Generalizations
B.7.10.3 Constraints
  • no_modelElement
  inv: modelElement->isEmpty()

Page 726

B.7.6 UMLCLassDiagram [Class]

B.7.6.1 Description
  See Annex A.
B.7.6.2 Generalizations
  UMLStructure Diagram
B.7.6.3 Constraints
  • no modelElement
  UMLClassDiagrams must have no modelElements.
  inv: modelElement->isEmpty ( )

Annex A does not disambiguate them. They both realise Structure Diagram, and (Annex A, page 685) they may both contain Structured Classifiers.

Anything that can be shown for a component on a component diagram, can also be shown of a class on a class diagram: any StructuredClassifier can have internal structure (p 183), Ports, Provided and Required Interfaces with multiplicity=*, and show those as lollipops and sockets (pages 185-186).

2 Answers 2


The key sentence about diagrams in the specification is:

the primary graphical symbols define the type of the diagram

That means the diagram type doesn't depend on the heading, only on the shown symbols.

About the heading it says:

The heading of a diagram represents the kind, name, and parameters of the namespace enclosing or the model element owning elements that are represented by symbols in the contents area.

That means, since the element owning classes and components is usally a package, component and class diagrams alike would have pkg as kind of the diagram frame. This is true for all diagrams that don't have a modelElement (class, component, object, package, deployment, use case and profile). For all these diagrams, it doesn't really matter, what you call it, since all elements have unique shapes. They can appear on any of these diagrams, without creating ambiguity. More relevant is a name, that conveys the purpose of the diagram, such as "system context".

A composite structure diagram however, could have class or cmp.

  • Ah, thanks, well spotted. You have also as a side effect clarified for me how Sparx EA chooses what to put in a frame header :-) May 26 at 16:25

The UML specifications define in detail modelling elements, such as classes, structured classifiers and components on over 680 pages, without anything about the diagrams in which these elements should appear.

The kind of diagrams is on contrary described very synthetic (4 pages), although the interchange format describes a little more the expectations, adding some 56 pages.

So indeed, in theory nothing prevents you from having a class diagram with mainly components and vice-versa. However, in practice:

  • Modelling tools will promote via their toll palette components in component diagrams, and lower class level elements for class diagrams.
  • Moreover, the good practice of working at one level of abstraction in one diagram, makes that most often, you'll have only components in a component diagram (using structured classifier diagrams to bridge component and class levels).
  • When there is a mix, it's indeed up to you to decide, based on the focus you want to give to the diagram.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.