Class diagram

Structure diagrams of the UML
Class diagram
Component diagram
Composition structure diagram
Object diagram
Package diagram
Profile diagram
Distribution diagram
UML behavioral diagrams
Activity diagram
Use case diagram
Interaction overview diagram
Communication diagram
Sequence diagram
Timing diagram
State diagram

A class diagram is a structure diagram of the Unified Modeling Language (UML) for the graphic representation ( modeling ) of classes , interfaces and their relationships. In object orientation, a class is an abstract generic term for describing the common structure and behavior of objects ( classification ). It serves to abstract objects . In conjunction with other classes, they enable the modeling of a delimited system in object-oriented analysis and design .

Since the 1990s, class diagrams have mostly been represented in the UML notation. The class diagram is one of the 14 types of diagram in UML, a modeling language for software and other systems.

Notation in the Unified Modeling Language

Classes

Classes are represented by rectangles that either only have the name of the class (printed in bold) or have also specified attributes , operations and properties. These three categories ( compartment ) - class name, attributes, operations / properties - are each separated by a horizontal line. If the class has no properties or operations, the bottom horizontal line can be omitted. Above the class name can keywords (Engl. Keyword ) in Guillemets and below the class name in braces additional properties (such as {abstrakt}) are.

The attributes are specified as follows:

[Sichtbarkeit] [/] name [: Typ] [ Multiplizität ] [= Vorgabewert] [{eigenschaftswert*}]

From this it follows that in the UML only the name of an attribute has to be specified, and clearly within a class. Class attributes are underlined. In addition, all characters are permitted in attribute names, even if umlauts, for example, are prohibited in some programming languages.

Operations are specified in a similar way:

[Sichtbarkeit] name [({Parameter})] [: Rückgabetyp] [{eigenschaftswert*}]

In addition, a parameter is structured as follows:

[Übergaberichtung] name : Typ [ Multiplizität ] [= Vorgabewert] [{eigenschaftswert*}]

The naming and the character space are the same as for the attribute specifications. Class operations are also underlined here. The “pseudotype” void does not exist in the UML, so the return type must be omitted in such a case. Otherwise, all primitive types as well as self-defined classes or interfaces can be used as type or return type for attributes and operations.

The visibility of operations and attributes is indicated as follows:

"+" For public - (English public), unrestricted access
"#" For protected , access only from the class and subclasses (classes that inherit)
"-" for private - (private), only the class can see it
"~" For package , visible within the package (can only be implemented in a few programming languages, such as Java and C #)

Possible properties are:

ordered: the data are returned in an orderly manner
redefines <operation name> (only for operations): this operation overwrites the inherited operation <operation name>
read-only: this variable can only be accessed for reading

The handover directions:

in: The transferred parameter is only read (standard, if nothing was specified).
out: The transferred parameter is written without reading it beforehand.
inout: The transferred parameter is read or processed and written, for example to return the result.

The following figures show two variants of the graphical notation for a class. Depending on whether a class is drawn on a class diagram for a design model or for an analysis model, more or less detail can be displayed.

Simplest form of presentation for a class
Additional representation of attributes and operations

Detailed representation of a class

Abstract classes are classes of which no instance can be created. Abstract classes look like normal classes in UML. To distinguish them, the word abstractin curly brackets is placed below the class name . Alternatively, the class name can also be written in italics if this is easy to recognize.

Example of an active class with two signal receivers

An active class is drawn with double left and right margins.

Class template

Some programming languages allow parameterization of class templates in order to create objects based on these template parameters . The UML offers the notation for template arguments for this. The template parameters are entered in a dashed rectangle overlapping in the upper right corner of the class. In the example, a “Vector” class is entered with the template parameter type “int” and the parameter name “T_VALUE”.

Interfaces

An interface is similar to a class indicated by a rectangle, but to distinguish with the keyword interfaceidentified. Since UML 2, interfaces can also have attributes.

An interface is marked with the keyword <<interface>>
Offered interface, represented with an interface realization relationship

Important relationships

Generalization

A generalization in UML is a directed relationship between a more general and a more specific class. Copies of the more specific class are therefore also copies of the more general class. In concrete terms, this means that the more specific class implicitly has all the characteristics (structural and behavioral characteristics) of the more general class - implicitly because these characteristics are not explicitly declared in the more specific class. It is said that the more specific class “inherits” or “derives” it from the more general class.

A generalization is shown as a solid line between the two classifiers involved. At the end of the more general classifier, a closed, empty arrowhead is drawn.

In common object-oriented programming languages, this corresponds to the concept of inheritance, with the arrow pointing to the superclass.

Generalization applied in an example

association

An association describes a relationship between two or more classes . Multiplicities are often noted at the ends of associations . These express how many of these objects are in relation to the other objects in this association.

Example of a binary association
Example of a reflexive association

Composition and Aggregation

Examples of composition and aggregation

One relationship between classes that is needed quite often is the relationship between a whole and its parts . The UML provides two special associations for this: the aggregation and the more specific composition . The relationship of the parts to their whole is described by the choice of aggregation or composition.

In the graphic representation of a composition , a filled diamond decorates the end with the multiplicity 1 (or 1..1), which is connected to the whole. In the case of aggregation , it is an empty diamond with a cardinality of 0 .. *.

The composition is a special case of aggregation and depicts the case in which the parts cannot exist without the whole . One also speaks of the fact that the parts of the whole are existentially dependent (existential dependency). In contrast to this, parts can very well exist in an aggregation, even if the whole does not (yet) exist. The parts are not existentially dependent on the whole.

If such a relationship is modeled, this always means that the whole has a cardinality of 0..1 or 1..1; the parts are part of exactly one whole or (still) free-standing - but they never belong to several "whole". The focus here is more on the parts. The modeler wants to state through an aggregation / composition that the parts are dependent on their whole.

The difference in cardinality (0 .. * or 1..1) defines whether there is an aggregation or the special case of composition. A composition is present when the cardinality on the whole is 1..1, or, as in the picture, just 1. An aggregation is present when the cardinality is 0 .. *.

For the example, the existence dependency is as follows:

(Composition :) A room cannot exist without a building.
(Aggregation :) A student can exist without a lecture.

However, the left entities consist of the right entities:

A building consists of rooms. (In the example of at least one room; if 0 rooms are also permissible as cardinality, the relationship is still a composition.)
A lecture consists of students. (In the example of at least three students; if 0 students are also permitted as cardinality, the relationship is still an aggregation.)

In terms of a “consists of” relationship, there is no difference between composition and aggregation. This is exactly what unites them. However, they differ in the “can exist without its whole” relationship.

If there is a composition, one also speaks of a referential integrity , which indicates for a part that it depends on the whole.

The "whole" may have additional relationships to other classes or further attributes of its own - it does not have to consist exclusively of parts of a class.

Formal semantics

Rumbaugh, Jacobson and Booch demand a rather minimally defined, set theoretical description of semantics. Accordingly, a configuration (English snapshot ) of a UML class diagram is a set of objects of the classes present in the diagram. A configuration is consistent if all restrictions specified in the diagram are observed, such as: B. Multiplicities or OCL Constraints. ${\ displaystyle \ sigma}$

Classes and attributes

In each configuration, a class is described as a set of its objects. If the name is a class, then a lot. This set can also be empty if there is no object. ${\ displaystyle cname}$ ${\ displaystyle \ sigma (cname)}$

If an attribute is of the type of a class with the class name , then it is a partial function of the set of objects in the set of objects of the attribute type . The function must be partial because it is undefined for attributes that have not (yet) been initialized. Class attributes are handled in the same way, but have the additional restriction that all objects of a class must be mapped to the same object of the attribute type. ${\ displaystyle attribn}$ ${\ displaystyle typn}$ ${\ displaystyle cname}$ ${\ displaystyle \ sigma (attribn)}$ ${\ displaystyle \ sigma (cname)}$ ${\ displaystyle \ sigma (typn)}$

If a multiplicity of an attribute was also defined with the interval , then there is a relation with , with the additional restriction that applies to each . ${\ displaystyle I}$ ${\ displaystyle \ sigma (attribn)}$ ${\ displaystyle \ sigma (attribn): \ sigma (cname) \ times \ sigma (typn)}$ ${\ displaystyle a \ in \ sigma (cname)}$ ${\ displaystyle Card (\ {b | \ langle a, b \ rangle \ in \ sigma (attribn) \}) \ in I}$

If a class with a name is a subclass of the class with a name , then: ${\ displaystyle cname1}$ ${\ displaystyle cname}$ ${\ displaystyle \ sigma (cname1) \ subseteq \ sigma (cname)}$

Associations

An association between classes with the names and is interpreted as a relation between the sets of objects in the classes . The multiplicities must be treated as described above in both directions. However, this representation does not allow the role names to be treated at the association ends. In order to still make this possible, a clear label function and its inverse could be introduced. ${\ displaystyle r}$ ${\ displaystyle cname1}$ ${\ displaystyle cname2}$ ${\ displaystyle \ sigma (r)}$ ${\ displaystyle \ sigma (r): \ sigma (cname1) \ times \ sigma (cname2)}$

In this way of considering semantics, no distinction is made between normal associations and their special characteristics (aggregation, composition).

Operations

In general, an operation triggers a transition from one configuration to another. In the case of non-deterministic operations, there are a number of successor configurations. Query operations are a special case. As these must not have any side effects, there is no status transition to another configuration. In many programming languages, operations correspond to methods or functions .

Example diagram

literature

Heide Balzert: Textbook of Object Modeling - Analysis and Design with UML 2 . Elsevier Spectrum Academic Publishing House, 2005, ISBN 3-8274-1162-9 .

Christoph Kecher: UML 2.0 - The comprehensive manual . Galileo Computing, 2006, ISBN 3-89842-738-2 .

Chris Rupp, Stefan Queins, Barbara Zengler: UML 2 crystal clear . Hanser Verlag, 2007, ISBN 978-3-446-41118-0 .

James Rumbaugh , Ivar Jacobson , Grady Booch : The Unified Modeling Language Reference Manual . Addison-Wesley, 1998, ISBN 978-0-201-30998-0 .

Web links

Commons : class diagram - collection of images, videos and audio files

Individual evidence

↑ Heide Balzert: Textbook of Object Modeling: Analysis and Design with UML 2 . 2nd Edition. Spektrum Akademischer Verlag, Heidelberg 2005, ISBN 978-3-8274-2903-2 , p. 543 .
↑ James Rumbaugh, Ivar Jacobson, Grady Booch: The Unified Modeling Language Reference Manual . Addison-Wesley, 1998, ISBN 978-0-201-30998-0 .

[1] Heide Balzert: Textbook of Object Modeling: Analysis and Design with UML 2 . 2nd Edition. Spektrum Akademischer Verlag, Heidelberg 2005, ISBN 978-3-8274-2903-2 , p. 543 .

[2] James Rumbaugh, Ivar Jacobson, Grady Booch: The Unified Modeling Language Reference Manual . Addison-Wesley, 1998, ISBN 978-0-201-30998-0 .