Member access modifier
All classes have different access levels depending on the access modifier.
- Public (+)
- Private (-)
- Protected (#)
- Package (~)
- Derived (/)
- Static (underline)
When there is no access modifier shown, it typically implies a default or package-private access level. It means the class member (attribute or method) is accessible within the same package. The notation for this access level is usually represented with a tiled (~).
Stereotype
A stereotype is used to tailor UML class diagram to introduce new elements that have additional properties. A stereotype is denoted using <<your_stereotype>>. Stereotype can be applied to almost any UML element, including classes, attributes, operations and even the entire diagram. They are used to indicate an element plays a specific role or properties that does not extends from the standard UML element. When a custom stereotype is used, it is a best practice to attach a note to describe the the stereotype.
Predefined stereotype
The UML class diagram comes with some predefined stereotype:
- <<interface>> This stereotype is used to indicate that a class is an interface rather than a typical class.
- <<abstract>> The abstract stereotype can be applied to abstract class to indicate its specialty.
- <<enumeration>> This stereotype is used for enumeration types, which are a special kind of data type consisting a set of named values.
There are some other useful stereotypes such as <<utility>>, <<boundary>>, <<control>> that are often used to adapt their own special needs to make the UML diagram more versatile and easier to understand.
Class notation
Class name
- The name of the class appears in the first partition.
Class attributes
- The class attributes are shown in the second partition. The attribute type is shown after the colon (:).
Class operations
- Operations are shown in the third partition.
- The return type of a method is shown after the colon at the end of the method signature.
- The return type of method parameters are shown after the colon following the parameter name. Operations map onto class methods in code
Relationship between classes
Inner class and enumeration
Inheritance
Inheritance incorporates two styles, they are semantically equivalent.
Abstraction
Interface
To represent an interface, the <<interface>> stereotype will be used
Abstract class
To represent an abstract class, the class name is written in italics or you can either use <<abstract>> stereotype.
Dependency
There are many types of dependencies, use stereotypes to differentiate them, such as <<call>>, <<use>>, <<parameter>>. You can refer to Dependency for details about dependency.
Association
Associations are relationships between classes in a UML Class Diagram. They are represented by a solid line between classes. Associations are typically named using a verb or verb phrase which reflects the real world problem domain.
Cardinality (multiplicity)
Cardinality represents the number of instances of one class that are related to the number of instances of another class in an association.
| Multiplicity | Meaning |
|---|---|
| * | Zero or more |
| 0..1 | Zero or one |
| 1..* | One or more |
| n | Exactly n |
Aggregation
A type of association, it represents a “part of” relationship.
In an aggregation relationship the child can exist independently of parent. And the objects of two classes have separate lifetimes.
In this example, the Student is part of a Class. When the class is deleted the student still exist.
Composition
A type of association, represents a stronger “part of” relationship.
In a composition relationship the child cannot exist independently of parent. The lifetime of the contained object(s) is controlled by the container or parent object.
In this example, there is strong life cycle dependency between the Person and its Head, Hand and Leg that the Head, Hand and Leg cannot exist on their own and have to rely on the Person to exist.
If the Person object is deleted, the Leg, Hand, and Head cannot exit anymore.
Generalisation VS Specialisation
Generalisation and specialisation are relationships between a more general (or parent) class or abstraction and a more specific (or child) class
Generalisation
It represent an “is a” relationship, where the child is a specialised version of the parent class. The child inherits attributes, operations, and behaviour from the parent class.
Specialisation
Specialisation is the process of creating a more specific class from a more general class or abstraction.
Realisation
Realisation is a relationship that represents the implementation of an interface by a class or component. It is often used to show that a class or a component provides a concrete implementation of an abstraction.
Back to parent node: UML Diagrams