UML Class and Package diagrams

Class diagrams are the most commonly used diagrams in UML. They represent a system’s notions (or the notions supported by a system), together 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.

Below, there are a few examples showing how to represent some basic systems using class/package diagrams.

The example on the right shows a conceptual view of Human society. This is a typical use of class diagrams, where we see classes, generalizations, associations and an operation. We also see constraints attached to some model elements.

The diagram on the right is a more complete example of a class diagram, showing 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.

The example diagram on the right presents a class diagram more oriented to "design" aspects. It could be used to produce equivalent Java code, for example.

In this example, we see the notions of interface, operations with a signature, and thrown exceptions.

In the diagram on the right, 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.

The model shown in the example on the right 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 then to connect these elements (parts) using a connector. This construction is called the “internal structure” of a class.

The example shown here presents some complex cases with n-ary associations and qualifiers on associations. This adds precision to associations for more accurate models.

In the example of a package diagram shown on the right, 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, and so on.

In UML2, a class can have many types of property. In the example shown on the right, 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, and so on.