Class diagram
A class diagram is a structural diagram of the Unified Modeling Language ( UML) for the graphical representation (modeling ) of classes, interfaces, and their relationships. A class is an abstract object-oriented generic term for the description of the common structure and common behavior of objects (classification). It is used to abstract objects. In combination with other classes they allow the modeling of a system defined in object-oriented analysis and design.
Since the 1990s, class diagrams are mostly represented in the notation of the UML. The class diagram is one of the 14 diagram types of UML, a modeling language for software and other systems.
- 2.1 generalization
- 2.2 Association
- 2.3 Composition and aggregation
- 3.1 Classes and Attributes
- 3.2 associations
- 3.3 operations
Notation in the Unified Modeling Language
Classes
Classes are represented by rectangles that have (in bold), or wear in addition also specifies attributes, operations, and properties either only the class name. Here, these three headings (English compartment ) are - class name, attributes, operations, and properties - each separated by a horizontal line. If the class has no attributes or operations, the bottom horizontal line can be omitted. Above the class name can Keywords (English keyword) in Guillemets and below the class name in braces additional properties (such as { abstract }) are.
The attributes are specified as follows:
[ Visibility] [/ ] name [: type] [ multiplicity ] [= default ] [{ property value } * ] It follows that in UML only the name of an attribute must be specified, and indeed unique within a class. Class attributes are underlined. Moreover, in attribute names allowed all the characters, even if in some programming languages , for example umlauts are prohibited.
Operations are specified in a similar way:
[ Visibility] name [ ({ parameters }) ] [: return type ] [{ property value } * ] In addition, a parameter is set up as follows:
[ Transfer direction ] name: type [ multiplicity ] [= default ] [{ property value } * ] The naming of characters and space are here, just as the attribute specifications. Class operations are also emphasized here. The " pseudo- type" void exists in the UML, therefore must be omitted in such a case, the return type. Otherwise all primitive types and user-defined classes or interfaces can be used as a type or return type for attributes and operations.
The visibility of the operations and attributes are identified as follows:
- " " For public - ( engl. public), unlimited access
- "# " For protected - (English only), access only on the class and subclasses ( classes that inherit )
- "-" For private - ( engl. private), only the class itself can see it
- "~" For package - ( implemented only in a few programming languages , such as Java and C # ) (English package) within the package visible
Possible properties are:
The transfer directions:
The following figures show two variants of graphical notation for a class. Depending on whether a class in a class diagram for a design or a model of analysis is drawn more or fewer details may be shown.
Abstract classes are classes that no instance can be created. See Abstract Classes in UML like normal classes. To distinguish them, below the class name is the word abstract in braces. Alternatively, the class name can also be written in italics, when this is clearly visible.
An active class is marked with a double left and right margins.
Some programming languages allow a parametrization of class templates ( class template ) to create objects based on this template parameters. The UML provides for the notation for template argument. The template parameters are entered in a dotted rectangle overlapping on the top right corner of the class. In the example, a class "vector " with the template parameter type "int" and the parameter name " T_VALUE " is entered.
Interfaces
An interface is represented similar to a class with a rectangle, but in order to distinguish with the interface keyword. Interfaces since the UML 2 also have attributes.
Key relationships
Generalization
Generalization in the UML is a directed relationship between a more general and a more specific class. Copies of the more specific class are thus copies of the more general class. Specifically, this means that the more specific class implicitly have all the features ( structural and behavioral characteristics) of the more general class has - implicitly because these characteristics are not explicitly declared in the more specific class. It is said that the more specific class she "inherits" from the more general class, or " derived ".
A generalization is shown as a solid line between the two involved classifiers. At the end with the more general classifier a closed, unfilled arrowhead is drawn.
In current object-oriented languages this corresponds to the concept of inheritance, with the arrow pointing to the upper class.
Association
An association describes a relationship between two or more classes. At the ends of associations multiplicities are frequently noted. These indicate how many of these objects are in relation to the other objects of this association.
Composition and aggregation
A relationship between the classes, which is relatively frequently modeled, the relationship between a whole and its parts. The UML provides for two special associations before: the composition and aggregation.
In the graphical representation of a composition filled diamond decorated at the end with the multiplicity 1, which is connected to the whole. In the case of aggregation, it is not a filled diamond.
The composition is a special case of aggregation and represents the case in which the parts can not exist without the whole ( existence dependency).
Formal semantics
Rumbaugh, Jacobson and Booch call for a rather minimal defined, set-theoretic semantics description. Accordingly, a configuration (english snapshot) of a UML class diagram, a set of objects existing in the graph classes. A configuration is consistent if all indicated in the diagram restrictions are complied with, such as multiplicities or OCL constraints.
Classes and Attributes
In each configuration, a class is described as a set of its objects. If the name of a class, then a lot. This quantity may be empty if there is no object.
If an attribute of a class with the class name type is, then is a partial function from the set of objects in the set of objects of the attribute type. The function must be partial, since it is undefined for (yet) uninitialized attributes. Class attributes are treated the same, but have the additional constraint that all objects of a class must be mapped to the same object of the attribute type.
A multiplicity of an attribute has been defined in addition to the interval, then a relation with, with the additional restriction that applies to each.
If a class name is a subclass of the class name, then:
Associations
An association between classes with the name and is interpreted as a relation between the quantities of the objects of the classes. The multiplicities must be treated as described in both directions as above. However, this representation does not allow treatment of the role names of the association ends. To enable this however, would a unique label function and its inverse to be introduced.
In this way of looking at the semantics does not distinguish between normal associations and their special characteristics ( aggregation, composition ).
Operations
In general, an operation initiates a transition from one configuration to another. In the case of non- deterministic operations, there are a lot of follow-up configurations. A special case query operations, but because these may have no side effects, there is no state transition in a different configuration. Operations correspond in many programming methods or functions.