Class diagrams are the most commonly used diagrams in UML: they represent the notions of a system (or supported by a system), along with their properties and inter-relations.

From a high level (conceptual) perspective, classes represent the concepts supported by a system, while from a low level (physical) perspective they can represent the classes implemented by an object language. The Figure shows a conceptual view of Human society. This is a typical use of class diagrams. Here we see classes, generalizations, associations and an operation. In addition, we see constraints attached to some model elements.

This more complete example shows the conceptual model of a travel agency. We recommend that attributes be typed by primitive classes (any class can be designated as being primitive) or by “data types”. Data types and enumerations are also represented in this diagram. Properties typed by complex classes must be modeled via associations

This figure presents a class diagram more oriented to “design” aspects. It could produce equivalent Java code for example. We see the notions of interface, operations with a signature, thrown exceptions.

Here, we see components, ports, parts and required and provided interfaces. From these specifications at the “typing” level, detailed models presenting the assembly of instances (parts) in a “container” class context, can be constructed.

This model expresses that in order to build a Video session, we need to connect (assemble) a PC to a video projector through a “VGA” port, and to connect these elements (parts) using a connector. This construction is called the “internal structure” of a class.

This diagram shows an SOA architecture using service components that are interconnected through services. The Objecteering EA profile is used here to extend UML for SOA. The use of internal class structure, component assembly and component modeling has greatly increased with the rise in SOA architecture based information system development.

The figure shows some complex cases with nary associations and qualifiers on associations. This adds precision to associations for more accurate models.

In this example of a package diagram, we see that a package can be developed to show its contents, which will probably consist not only of classes but also of a wide variety of elements such as processes (activities), actors, packages, interactions, etc.

In UML2, a class can have many types of property. In the example, we see that there is a zone dedicated to attributes within a class, another zone dedicated to operations, another to parts, and yet another dedicated to embedded elements, such as classes, actors, activities, interactions, etc. and all sort of authorized elements such as actors, activities, interactions, etc.