The class diagram is the heart of UML. It is based on the principles of object orientation (abstraction, encapsulation, heredity, etc.) and due to its versatility can be implemented in all phases of a project. In the analysis phase it appears as the domain model and attempts to provide an image of reality. The software is modeled with it in the design phase, and in the implementation phase source code is generated.
Classes and the relationships of classes to each other are modeled in class diagrams. The relationships can be roughly divided into three categories. The simplest and most general option is the association. A second relationship which can be modeled is the acceptance of one class into another class - the so-called Container class. Such relationships are called Aggregation or Composition. A third option is Specialization or Generalization.
Since a class must model the structure and the behavior of objects which are created from this class, it can be equipped with methods and attributes. Furthermore, the modeling of base classes and interfaces can be achieved via stereotypes. Template classes can be implemented in several programming languages. UML displays such classes as parametrisable classes in the class diagrams.
A class describes a number of instances which have the same attributes, constraints and semantics.
Classes are represented by rectangles which either carry only the name of that class, or also the attribute and operations. The three compartments - Class name, Attributes, Operations - are each divided by a horizontal line. Class names usually start with a capital letter and are mostly substantive in singular (collection classes, among others, in plural where applicable).
The attributes of a class are noted with at least their names, and can contain additional data pertaining to their type, an initial value, attribute values and constraints. Methods are also noted with at least their name, as well as with possible parameters, their type and initial values, as well as possible attribute values and constraints.
Fig. 30: Class Example
The Scope of class elements is labeled with a sign in front of the name. If an element is clearly visible, a "+" sign is shown in front of the name. Private elements are given the "-" sign. A "#" in front of a name means that the class element is labeled with the access attribute "protected". Protected is an extension of private; sub-(daughter) classes inherit attributes marked as protected. A "~" in front of the name means "package", a limitation of "public" - not unlimited public visibility, but rather limited to the package.
Instances are never created from an abstract class. This class is intentionally incomplete and constitutes the basis for further subclasses which can have instances. An abstract class is illustrated like a normal class, however the class name is set as cursive.
Abstract classes, for example, can be indicated with stereotypes. The specification of the stereotype appears over the class name in French quotations: " ". Stereotypes can also be made visible with various colors or by writing the class name in italics.
Fig. 31: Example Stereotypes
A special kind of class is the parameterized class. Here, the type of contained attribute has not yet been established. Definition takes place when an object in this class is instanced. The graphical appearance is modified for such classes. The classes rectangle is given a second rectangle with border at the top in which the variable type is shown.
Fig. 32: Parameterized Class
Objects are the operative units of an object-oriented application. They are created in memory according to a building plan - the class definition. Every object has its own identity. An object possesses a specific behavior which is defined by its methods. Two objects of the same class have the same behavior. Furthermore, objects have attributes which are the same as other objects in the same class. The state of an object is defined by its values which are saved in the attributes. Therefore, two objects in a class are equal when the values in their attributes correspond.
Like classes, objects are drawn in the diagram using a rectangle, although the name is emphasized to differentiate it from classes. The name of the object follows the class name separated by a colon. If the actual object name has no bearing for the case to be modeled, then it can also be omitted, whereby only a colon and the class name are shown. As the methods are not important for the object's presentation, they are not shown.
Fig. 33: Object Example
An Attribute is a data element which is similarly contained in every object of a class, and is represented in every object by an individual value.
In contrast to UML 1.x, UML 2.0 no longer strictly differentiates between Attribute and Association ends. This means that presentation as Attribute in a class or as navigable Associationis the same.
Every attribute is indicated by at least its name. In addition, type, visibility and an initial value can be defined. The full syntax is as follows:
A class must have a responsible Method for every message which it receives. A class provides other classes with functionality via a method. Using messages, or Method Calls, the objects instanced from the classes communicate with each other and achieve thereby coordination of their behavior. Objects and their communication via Method Calls are illustrated in the group of interaction diagrams.
There are four different kinds of Relationships between classes, whereby generalization is a special form which is very similar to the other three - association, aggregation and composition.
An Association represents the communication between two classes in a diagram. The classes are connected with a simple line. With the help of an arrow, a directional Association is shown.
Every association can be furnished with a name which provides a more detailed description. The name can also be furnished with a reading direction indicator - a small filled triangle. This indicator refers strictly to the name and has no relation to the navigability of the association.
On every page of an association, role names can be used to more precisely describe which role the current objects play in the relationship. Roles are the names of attributes which belong to the association or one of the involved classes.
In programming language, associations are generally realized in that the concerned classes contain relevant attributes.
A role therefore represents an attribute. Aside from role names, visibility specifications can be placed on every side of the association. If, for example, an association end is listed as private (-), then the object itself, or the object's operations, can utilize the association, whereby neighboring classes receive no access.
A Directional Association is noted like a typical association, except that on the side of the class to which navigation is possible - in the navigation direction - is an arrow with open point. Multiplicity and role names can theoretically also be noted on the side to which navigation is not possible. They describe a Property which does not belong to a class, but rather an association.
In the following example, the class Customer would receive an attribute "account" as reference to an object of the class CustomerAccount, and the class CustomerAccount would receive the private attribute "bpos" with a collection or subclass thereof which references the booking position objects.
Fig. 34: Association and Composition with all properties
Many modeling tools use the role names of the relationship for the corresponding automatically-generated attributes; role names in UML also correspond formally with the corresponding attributes. Association with navigability is an alternative notation for attribute presentation in the appropriate class.
Fig. 35: Associations
These relationships are read in the following way:
- An event has a seating plan.
- A seating plan is allocated to a venue.
The arrow shows that communication emerges predominantly from the seating plan (the class therefore receives a reference to the venue at implementation). The cardinalities are thereby read before the target classes.
The Multiplicity of an association indicates with how many objects the opposing class of an object can be instantiated. When this number is variable, then the bandwidth - or minimum and maximum - is indicated 3..7 . If the minimum is 0, this means that the relationship is optional (the relationship is still there, only the number of elements is 0). If the minimum is equal to the maximum, only one value is written.
In UML he term Cardinality is used to express the concrete number of instances.
Fig. 36: Multiplicity vs. Cardinality
The term cardinality has its origin in data modeling - there with the meaning of multiplicity of UML. Within UML both terms are used to distinguish between the possible number of instantiations and the concrete number of instantiations. The cardinality describes within an object diagram the number of associated objects.
Classes can also be arranged with each other in combination; when regarding the relationship of customer, account and bank card, then it becomes clear that a bank card exists for a combination of a customer and an account - and that is very different than associating the card directly with the customer and the account. UML provides Association Class notation for this:
Fig. 37: Association Class
A unique property of the association class is that it may only give precisely one instance of the associated class per reference. For example, there may only be one reference of bank card per combination of customer and account.
Should several classes be involved, then the association node (n-ary Association) is used:
Fig. 38: Association Node
The n-ary association has its beginnings in data modeling (Entity Relationship Models) and is implemented in UML semantically identical. All classes involved with the association form a single unit. This means, for example, that (ticket, date, flight, and passenger) all form a single component and as a sum have a significant meaning: a role in a specific flight. This significance is usually expressed in the name of the association (hash).
Important for n-ary association is the setting of multiplicities, or what combinations of object characteristics are valid. In order to correctly set multiplicities, think for n-1 elements a multiplicity of 1 and set the multiplicity of the n-th.
For example: A passenger has precisely one ticket for a flight on a specific date. If it is possible that the passenger may have more than one ticket for the same flight on the same date, then the multiplicity for Ticket must be greater than 1 (e.g. "*").
An aggregation is an association extended by the semantically non-binding commentary that the involved classes are not in an equal relationship, but rather represent a "part of" relationship. An aggregation should describe how something whole is logically made up of its parts.
Like an association, an aggregation is shown as a line between two classes and is given a small diamond. This diamond is on the side of the aggregation, or whole. It effectively symbolizes the container object in which the individual parts are collected. All association notation conventions are valid.
Fig. 39: Aggregation notation
The Company-Department-Employees example shows that a part (department) can at the same time also be an aggregation.
Fig. 40: Example Aggregation
A Composition is a strict form of aggregation whereby the existence of the parts depends on the whole. They describe how something whole is made up of individual parts. Like aggregation, composition is shown as a line between two classes and is given a small diamond on the side of the whole. Unlike that of aggregation, this diamond is filled in.
Fig. 41: Aggregation and Composition
When a class is defined as part of several compositions, such as in the following example, then this means that both cars and boats have a motor - a specific motor object but which can always only either belong to a car or to a boat. The decisive characteristic of a composition is that the aggregated parts will never be shared with other objects. This can also be written into the diagram using XOR constraint.
Fig. 42: Example Composition
Should the multiplicity for parts (Motor) start from zero (0..*), then the whole may exist without parts, or can contain as many parts as desired. Should the multiplicity of the whole (car/boat) be from zero to one (0..1), then that part may also exist without a whole; as soon as that part belongs to a whole it will no longer be separated and an existence-dependent relationship exists. Existence dependency means that the part without its whole cannot exist, and when the whole must be destroyed, then so must all of its parts.
In the following example, an aggregation is modeled between the class Event Plan and the class Seating Plan. A composition is defined between the classes Seating Plan and Seat. There is therefore no Seating Plan object without a Seat. The relationships are read in the following manner:
Fig. 43: Example Aggregation and Composition
- A seating plan has unlimited capacity, but usually only one seat.
- A seat belongs to one specific seating plan.
- Every seating plan belongs to one specific event.
- An event may contain an unlimited number of seating plans.
- The seating plan can also be assigned to another event (Aggregation), but must in any case always have one event.
- The seat is part of a seating plan; this relationship can never be changed (Composition).
A Generalization is a relation between a more general (parent) and a more specific (child) element, in which the specific element provides additional properties but is still compatible with its general element.
In generalization or specialization, characteristics are hierarchically arranged; this means that characteristics of general importance are assigned to elements of a more general nature, and more specialized characteristics are assigned to elements which are subordinate to more general elements. The characteristics of the parent elements are passed on ('handed down') to the appropriate sub-elements. A sub-element thus carries its specified characteristics as well as the characteristics of its parent elements. Sub elements therefore inherit all characteristics of their parent elements and can extend these further or overwrite them.
Hierarchical inheritance trees are modeled in this way. Inheritance trees are an important design element in the modeling of software architectures. The following example models how events can be modeled as in-house or external.
Fig. 44: Example Inheritance
A dependency is a relationship from one relationship of one (or more) source element(s) to one (or more) target element(s).
The target elements are required for the specification or implementation of the source elements.
A dependency is shown as a dashed-line arrow pointing from the dependent to the independent element. Additionally, the type of dependency can be more precisely specified using a key word or stereotype.
Since, in a dependency relationship, the source element requires the target element for its specification or implementation, without the element it's incomplete.
Dependencies can have differing causes. Some examples are:
- One package is dependent upon another. Here, for example, the cause can be due to the fact that one class in the one package is dependent upon another class in the other package.
- A class is using a specific interface of another class. When the provided interface is changed, the class using this interface also requires changes.
- One operation is dependent upon another class; for example, the class is used in an operation parameter. A change in the class of the parameter possibly requires a change in the operation itself.
The Abstraction relationship is a special dependency relationship between model elements on various abstraction levels. The relationship is noted as a dependency relationship. They cannot be confused, however, as the abstraction is always used together with a stereotype. UML defines the standard stereotypes «derive», «trace» and «refine».
A mapping also always belongs to an abstraction relationship showing how the involved elements interact (Mapping). Specification can be formal or informal. In spite of arrow direction, an abstraction relationship can also be bidirectional according to stereotype and mapping, e.g. the often-used «trace» relationship.
A special abstraction relationship is the Realization relationship. It is a relationship between an implementation and its specification element.
The Substitution relationship is a special realization relationship. It describes that examples of the independent elements can be substituted at run time from the dependent elements, for instance due to similar interface implementation.
The Usage relationship is a special dependency relationship. The difference to the dependency relationship is that the dependency limits itself only to the implementation and is not valid for the specification. This means that the dependent element requires the independent element for its implementation. Therefore, there can be no usage relationships between interfaces, but rather the dependency relationship.
The permission relationship is a special dependency relationship which issues the dependent element access rights to the independent element.
Stereotype for Usage Dependency (Usage)
The Call relationship is defined and specified from one operation to another operation so that the source operation calls up the target operation. A class may also be chosen as a source element. This means, then, that the class contains an operation which calls up the target operation.
Stereotype for usage dependency (Usage)
This dependent element creates copies of the independent element. The Create relationship is defined between classes.
Stereotype to define abstraction relations (Abstraction)
This dependent element is derived from the independent element.
Stereotype to define type instance relations (Usage)
This independent element created copies of the independent element. The relationship is defined between classes.
Keyword for the Permission relationship (Permission)
This independent element has the permission to use private attributes of the independent element.
Keyword for the Realization relationship (Realization)
This independent element implements the independent element, for example an interface or an abstract element; or an element must implement a requirement.
Stereotype to define semantic specialization (Abstraction)
This dependent element is on a more precise semantic level than the independent element.
Stereotype to define traces between semantic specializations (Abstraction)
This dependent element leads to an independent element to be able to follow semantic dependencies, for example from a class to a requirement or from a use case to a class.
Key word for Usage relationship
This dependent element uses the independent element for its implementation.
Interfaces are special classes which specify a selected part of the externally visible behavior of model elements (mainly of classes and components) with a set of characteristics (features).
The Implementation relationship is a special realization relationship between a class and an interface. This class implements the characteristics specified in the interface.
Interfaces are noted like classes; however, they incorporate the key word "interface".
A differentiation is made between available and required interfaces. An available interface is offered by a model element and can be used by others. A required interface is an interface which is requested by another model element.
Interfaces specify not only operations, but also attributes. Interfaces may also have appropriate associations to other interfaces or classes.
Classes which want to implement an interface must implement all operations defined in the associated interface. Concerning the attributes defined in the interface, the implementing class must behave in such a way as though it owns the attributes. In the simplest case, it actually implements the attributes. It is also enough, for example, to offer only the appropriate get() and set() methods.
A class can implement many interfaces and can furthermore contain additional properties, or put another way: As a rule, an interface describes a subset of the operations and attributes of a class.
A special realization relationship exists between the implementing class and the interface - the implementation relationship (key word "realize").
Fig. 45: Example interface
Given the current specification, it is not clear if, for the implementation relationship, the dashed arrow with keyword "realize" is to be used, or the dashed Generalization relationship as in UML 1.x. We assume here the latter, as this alternative is also much better for practical work.
The implementation relationship is noted with a special arrow. The other way to show the implementation of an interface is a small, unfilled circle connected by a line with the class that provides the interface. This should symbolize a plug. Next to this, the name of the interface is given; it corresponds to the name of the associated interface.
When drawing the arrow, the possibility exists to read the operations and attributes requested via the interface. The short notation does not indicate the operations and attributes requested by the interface, only the name of the interface. You may still use the 1.4 Notation, shown own the right side alternatively. The benefit: Available methods can be shown directly in the diagram.
Fig. 46: Notation for Available/Provided Interface
For a requested interface, the requesting element has a usage relationship to the interface. The existing short notation is an open semicircle on a stem which is intended to symbolize a grabbing hand.
Fig. 47: Notation for Requested/Used Interface
Allocation and request of an interface can be shown by the combination of both short notations by sticking the plug into the socket.
Fig. 48: Notation Options for Interfaces (Usage and Realize)
Warning: The last drawing version uses the symbol Assembly. But an assembly belongs to the category connector! You cannot use linking; the name can only be inserted textually! A connector cannot be an instance of an element, so there will be no feature to set the instance classifier! Avoid this kind of notation!
Since interfaces are special classes, all corresponding rules apply. Generalization is one option, for example.
Fig. 49: Extension of Interfaces
The following image shows that the class "Opel Astra" implements the "car" interface. The car interface requests four operations - steer(), shift(), brake() and accelerate() - as well as two attributes, "velocity" and "direction". The class "Opel Astra" fulfills the requirements for this interface, since it is has, among other things, the four requested operations.
Fig. 50: Example of Implementation of Interfaces
The following tables contain the symbols of the class diagrams.
A class is indicated on a diagram with a rectangle in which the name of the class is shown. The class symbol can be extended by an area to indicate the attributes and the methods. For parametrisable classes, the class symbol is extended by a rectangle which contains the name of the parameter.
Objects are indicated by a rectangle in which the name and the class of the object are underlined. Both are separated by a colon. The class name can be left off if the object can also be classified without a class name. An anonymous object (without name) is shown with only a colon and the class name.
Packages include multiple classes which are grouped there for a specific task. The graphic for a package symbolizes an index file card on which the package name is shown.
If two classes are in a relationship, this is shown by the connection of both classes by a solid line.
The cardinality can be entered on the line near the class symbol.
Furthermore, the names of the relationship and role can still be shown (Roles: Accused, Accuser; Relationship Name: Accuses).
You can indicate the preferred direction of communication using an arrow. (Navigation)
Aggregation is shown with a line, on the end of which is a diamond pointing to the container class (Class B can manage objects of Class A). The diamond is not filled. Roles, cardinality and desired direction of communication are entered at the association.
Unlike aggregation, composition is shown with a filled diamond. Further symbols correspond to aggregation.
The symbol is an arrow pointing to the base class and connecting it to the derived class. The arrow is not filled (class A inherits from class B).
When a class imports an interface, the link is shown by an arrow on a dashed line.
All performances in a theatre are managed using an event plan in a ticket system. The class event calendar is connected with the class seating plan via a composition. In this way, the event calendar class can manage objects of the seating plan class. Every seating plan contains the theatre's seats, and these are sold via the seating plan. The class seating plan manages the class seat via an additional composition. The navigation points in the direction of the class seat. The class seating plan communicates with the class event, where the data from the performances are stored, e.g. date and time. Entries for the venue, e.g. the name and the address, are stored in the class location. Navigation is carried out from the class seating plan.
Fig. 51: Example Class Diagram
A Package is a logical aggregation of model elements of any type, and with which the entire model is organized into smaller, more manageable units.
A package defines a namespace; i.e. the names of the elements contained within a package must be clear. Every model element can be referenced in other packages, but can belong to only one (home) package. Packages can contain various model elements, such as classes and use cases. They can be hierarchically organized; i.e. for their part contain packages again.
A model element such as a class can be used in various packages; however, every class has its home package. In all other packages, it is simply referred to by its qualified name
Dependencies thereby arise between the packages; i.e., a package utilises the classes of another package.
Fig. 52: Example Package Diagram
A package is shown in the form of a file register card. The name of the package is in this symbol. If modeling elements are shown within this symbol, the name is on the register tab; otherwise, within the large rectangle. Stereotypes can be noted above the package name.
If a task is to be distributed to several developer groups, a division into packages can be used and each group given such a package for handling. To ensure problem-free combination of the packages later on, an interface is stipulated whereby at first only the name of the interface is necessary. The functions contained within the package are called up via the interface. In this way, the package can be appropriately tested and subsequent cooperation can be guaranteed with additional packages. Guaranteed means here that the defined resulting values for the provided input parameter are delivered for the functions implemented in the package.
The interaction of system packages is shown in a package diagram in which one can also model the internal structure of a package.
This symbol for a package is reminiscent of a file register card. The package name is shown within this symbol. Should you wish to model inter-package communication, the package name can be placed in the rectangle attached to the top.
Communication among the packages is shown with an arrow which runs along a broken line. The arrow starts from the package from which communication predominantly originates.
Should one package inherit from another package, the symbol for generalization is applied. The involved packages are linked by an arrow, whereby the arrow points to the package from which is inherited.
Using this symbol, package arrangement can be modeled from the superordinate package, whereby the “Include” symbol is placed on the symbol of the superordinate package. The subordinate packages are linked with this symbol by a solid line.