UML Class Diagram Tutorial
UML Class Diagram Tutorial
visual-paradigm.com/guide/uml-unified-modeling-language/uml-class-diagram-tutorial
The UML Class diagram is a graphical notation used to construct and visualize object
oriented systems. A class diagram in the Unified Modeling Language (UML) is a type of
static structure diagram that describes the structure of a system by showing the system's:
classes,
their attributes,
operations (or methods),
and the relationships among objects.
Free Download
What is a Class?
A Class is a blueprint for an object. Objects and classes go hand in hand. We can't talk
about one without talking about the other. And the entire point of Object-Oriented Design
is not about objects, it's about classes, because we use classes to create objects. So a class
describes what an object will be, but it isn't the object itself.
In fact, classes describe the type of objects, while objects are usable instances of classes.
Each Object was built from the same set of blueprints and therefore contains the same
components (properties and methods). The standard meaning is that an object is an
instance of a class and object - Objects have states and behaviors.
Example
A dog has states - color, name, breed as well as behaviors -wagging, barking, eating. An
object is an instance of a class.
1/9
UML Class Notation
A class represent a concept which encapsulates state (attributes) and behavior
(operations). Each attribute has a type. Each operation has a signature. The class
name is the only mandatory information.
Class Name:
Class Attributes:
2/9
Operations are shown in the third partition. They are services the class provides.
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
Class Visibility
The +, - and # symbols before an attribute and operation name in a class denote the
visibility of the attribute and operation.
Parameter Directionality
Each parameter in an operation (method) may be denoted as in, out or inout which
specifies its direction with respect to the caller. This directionality is shown before the
parameter name.
3/9
The choice of perspective depends on how far along you are in the development process.
During the formulation of a domain model, for example, you would seldom move past
the conceptual perspective. Analysis models will typically feature a mix of
conceptual and specification perspectives. Design model development will
typically start with heavy emphasis on the specification perspective, and evolve into
the implementation perspective.
The perspective affects the amount of detail to be supplied and the kinds of relationships
worth presenting. As we mentioned above, the class name is the only mandatory
information.
If you can't yet recognize them, no problem this section is meant to help you to
understand UML class relationships. A class may be involved in one or more relationships
with other classes. A relationship can be one of the following types:
4/9
Inheritance (or Generalization):
A generalization is a taxonomic relationship between a more general classifier and a more
specific classifier. Each instance of the specific classifier is also an indirect instance of the
general classifier. Thus, the specific classifier inherits the features of the more general
classifier.
The figure below shows an example of inheritance hierarchy. SubClass1 and SubClass2 are
derived from SuperClass. The relationship is displayed as a solid line with a hollow
arrowhead that points from the child element to the parent element.
The figure below shows an inheritance example with two styles. Although the connectors
are drawn differently, they are semantically equivalent.
5/9
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.
Simple Association
A structural link between two peer classes.
There is an association between Class1 and Class2
The figure below shows an example of simple association. There is an association that
connects the <<control>> class Class1 and <<boundary>> class Class2. The relationship
is displayed as a solid line connecting the two classes.
Cardinality
Cardinality is expressed in terms of:
one to one
one to many
many to many
6/9
Aggregation
A special type of association.
The figure below shows an example of aggregation. The relationship is displayed as a solid
line with a unfilled diamond at the association end, which is connected to the class that
represents the aggregate.
Composition
A special type of aggregation where parts are destroyed when the whole is
destroyed.
Objects of Class2 live and die with Class1.
Class2 cannot stand by itself.
Dependency
7/9
An object of one class might use an object of another class in the code of a method. If the
object is not stored in any field, then this is modeled as a dependency relationship.
Realization
Realization is a relationship between the blueprint class and the object containing its
respective implementation level details. This object is said to realize the blueprint class. In
other words, you can understand this as the relationship between the interface and the
implementing class.
For example, the Owner interface might specify methods for acquiring property and
disposing of property. The Person and Corporation classes need to implement these
methods, possibly in very different ways.
8/9
Class Diagram Example: GUI
A class diagram may also have notes attached to classes or relationships.
Free Download
9/9