What is a Class Diagram in UML?
A class diagram describes the structure of an object-oriented system by showing the classes in that system and the relationships between the classes. A class diagram also shows constraints, and attributes of classes.
Finding an online Class Diagram tool? Just click the Draw button below to create your Class Diagram online. Visual Paradigm Online is free* and intuitive. You can also go through this Class Diagram tutorial to learn about Class Diagram before you get started
Draw NowClass Diagram Notations
Class
Chapter 6: Class Diagram The Class Diagram Using the Class Diagram model, you describe the static structure of the symbols in your new system. This model allows you to graphically represent symbol diagrams containing classes. Classes are arranged in hierarchies sharing common structure and behavior and are associated with other classes. Sequence diagram from a use case 6 1. The user presses the “check email” button. The client first sends all unsent email to the server. After receiving an acknowledgement, the client asks the server if there is any new email. If so, it downloads the new email. Next, it deletes old thrashed email from the server.:Client:Server. Sample of UML Diagrams for ATM System. For Data: Class diagram. Class Diagram:- Class diagrams describe the static structure of a system, or how it is structured rather than how it behaves. These diagrams contain the following elements: 1. Classes, which represent entities with common characteristics or features. The class diagram is used to represent a static view of the system. It plays an essential role in the establishment of the component and deployment diagrams. It helps to construct an executable code to perform forward and backward engineering for any system, or we can say it is mainly used for construction.
The UML representation of a class is a rectangle containing three compartments stacked vertically, as shown in the Figure:
Attribute
The attribute section of a class lists each of the class's attributes on a separate line. The attribute section is optional, but when used it contains each attribute of the class displayed in a list format. The line uses this format: name : attribute type (e.g. cardNumber : Integer).
Operation
The operations are documented in the bottom compartment of the class diagram's rectangle, which also is optional. Like the attributes, the operations of a class are displayed in a list format, with each operation on its own line. Operations are documented using this notation: name (parameter list) : type of value returned (e.g. calculateTax (Country, State) : Currency).
Relationships
Association
Some objects are made up of other objects. Association specifies a 'has-a' or 'whole/part' relationship between two classes. In an association relationship, an object of the whole class has objects of part class as instance data.
In a class diagram, an association relationship is rendered as a directed solid line.
Unidirectional association - In a unidirectional association, two classes are related, but only one class knows that the relationship exists.
A unidirectional association is drawn as a solid line with an open arrowhead pointing to the known class.
Bidirectional (standard) association - An association is a linkage between two classes. Associations are always assumed to be bi-directional; this means that both classes are aware of each other and their relationship, unless you qualify the association as some other type.
A bi-directional association is indicated by a solid line between the two classes.
Multiplicity
Place multiplicity notations near the ends of an association. These symbols indicate the number of instances of one class linked to one instance of the other class. For example, one company will have one or more employees, but each employee works for one company only.
Visibility
Visibility is used to signify who can access the information contained within a class denoted with +, -, # and ~ as show in the figure:
Generalization
A generalization is a relationship between a general thing (called the superclass) and a more specific kind of that thing (called the subclass). Generalization is sometimes called an 'is a kind of' relationship and is established through the process of inheritance.
In a class diagram, generalization relationship is rendered as a solid directed line with a large open arrowhead pointing to the parent class.
Abstract Classes and methods
In an inheritance hierarchy, subclasses implement specific details, whereas the parent class defines the framework its subclasses. The parent class also serves a template for common methods that will be implemented by its subclasses.
The name of an abstract Class is typically shown in italics; alternatively, an abstract Class may be shown using the textual annotation, also called stereotype {abstract} after or below its name.
An abstract method is a method that do not have implementation. In order to create an abstract method, create a operation and make it italic.
Realization
A realization is a relationship between two things where one thing (an interface) specifies a contract that another thing (a class) guarantees to carry out by implementing the operations specified in that contract.
In a class diagram, realization relationship is rendered as a dashed directed line with an open arrowhead pointing to the interface.
Dependency
Dependency indicates a 'uses' relationship between two classes. In a class diagram, a dependency relationship is rendered as a dashed directed line.
If a class A 'uses' class B, then one or more of the following statements generally hold true:
- Class B is used as the type of a local variable in one or more methods of class A.
- Class B is used as the type of parameter for one or more methods of class A.
- Class B is used as the return type for one or more methods of class A.
- One or more methods of class A invoke one or more methods of class B.
When to Draw Class Diagram?
Most of the UML diagrams can not be mapped directly with any object-oriented programming languages except class diagrams. In other words, class diagram ideally can have one to one mapping to UML class diagrams. Besides, class diagrams are useful in the following situations:
- Describing the static view of the system.
- Modeling the collaboration among the elements of the static view.
- Describing the functionalities performed by the system.
- Construction of software applications using object oriented languages.
- Performing code forward engineering for the target systems
- Classifying classes or components as library for future reuses
How to Draw a Class Diagram?
- Identify the objects in the problem domain, and create classes for each of them. (e.g. Teacher, Student, Course for an enrollment system)
- Add attributes for those classes (e.g. name, address, telephone for the Student class)
- Add operations for those classes (e.g. addStudent(student) for the Course class)
- Connect the classes with appropriate relationships (e.g. Relate Teacher and Course with an association)
- Optionally specify the multiplicities for association connectors' ends (e.g. Input 0..3 for the Course side of the association that connects Teacher and Course, to signify that one teacher can teach multiple up to three courses)
You can also:
- Draw packages for logical categorization of classes
Class Diagram Examples
The class diagram example below shows the classes involved in a sales order system. Notice the use of <<enumeration>> class in the class model.
The class diagram example below shows a set of classes related to flight management. The classes are grouped under a package.
You've learned what a Class Diagram is and how to draw a Class Diagram step-by-step. It's time to get your hands dirty by drawing a Class Diagram of your own. Draw UML diagrams free* with Visual Paradigm Online. It's easy-to-use, intuitive.
Draw Now* The Free edition supports free usage of Visual Paradigm Online for non-commercial use only.
In class diagrams, as shown in Figure 4.30, we work with the following elements:
Class
A class represents a relevant concept from the domain, a set of persons, objects, or ideas that are depicted in the IT system:
Examples of classes are passengers, planes, or tickets.
Attribute
An attribute of a class represents a characteristic of a class that is of interest for the user of the IT system:
Characteristics of interest of a passenger, for example, are name and age.
Generalization
Generalization is a relationship between two classes: a general class and a special class:
Refer to Generalization, Specialization, and Inheritance.
Association
An association represents a relationship between two classes:
An association indicates that objects of one class have a relationship with objects of another class, in which this connection has a specifically defined meaning (for example, “is flown with”).
Multiplicity
A multiplicity allows for statements about the number of objects that are involved in an association:
Also see Figure 4.32.
Aggregation
An aggregation is a special case of an association (see above) meaning “consists of”:
The diamond documents this meaning; a caption is unnecessary.
Reading Class Diagrams
How Email Works For Dummies
Figure 4.31 shows a class diagram from our case study with the classes customer, ticket, and coupon, their attributes, and their associations:
Looking at the class diagram in Figure 4.31, you can read the association between the classes customer and ticket as follows:
- One (this sentence always begins with “one”) object of the first class has an association with a number of objects of the second class.
The appropriate values from the diagram have to be inserted into this first abstract formulation, which can be universally applied. The name of one class is customer (1); the name of the other class is ticket (4). The name of the association is owns (2):
- A customer (1) owns (2) * (3) ticket (4).
Statechart Diagrams
If the asterisk is exchanged with its meaning, a regular English sentence is created:
- A customer (1) owns (2) zero, one or several (3) ticket(s) (4).
Since associations usually are not directional, meaning usually go both directions, our association also has a meaning in the other direction:
- A ticket (4) is owned by (2) exactly one (5) customer (1).
The small triangle next to the name of the association (2) indicates in which direction the name of the association holds true. We can read all the associations in the class diagram in this way.
The specification of the number of objects of the second class (you always start with one object of the first class) is called the multiplicity. The course of action should always be according to the same pattern:
First, a statement of the lower limit (minimum number) followed by two periods (..) and a statement of the upper limit (maximum number).
Figure 4.32 shows the most common possibilities:
However, in UML it is also possible to insert any values as the lower and upper limits, e.g., 2 .. 4 or 6 .. *.
The association’s name is necessary for understanding the domain meaning of the association. In contrast to the association itself, which applies to both directions, the name of the association applies to only one direction, which is indicated by a black triangle. If the association is not labeled, its meaning has to be derived from the domain context, or it takes on a general meaning such as has or belongs to. In case of doubt it is better to label associations too much than too little. Many diagrams that we have encountered in our practical experience were incomprehensible because associations were not labeled.
Associations can also be viewed as the implementation of static business rules (see Static and Dynamic Business Rules). Statements such as “a ticket belongs to exactly one customer” are documented in the class diagram by associations.
Roles are another possible way in UML to give relationships between classes a domain meaning. In this way, we can state what role an object of one class plays for the objects of another class:
Looking at the class diagram in Figure 4.33, we can read the left association with roles between the classes flight number and airport as follows:
- An airport(1) is a start (location) (2) for one or more(3)flightnumbers(4).
There is another association between the two classes flight number and airport:
- An airport (1) is a destination (5) for one or more flight numbers (4).
These two associations also have inversions, even though roles are only stated for one direction:
- A flight number(4) has as start (location)(2)exactly one(7)airport(1).
- A flight number (4) has as destination (5) exactly one (8) airport (1).
This records that a certain flight number has a departure airport and a destination airport. An example of a flight number is LX317, a daily flight of the Swiss airline Crossair from London to Zurich.
Among the many domain meanings that an association can have there is one that can be signified with UML by its own symbol: the whole-part relationship or aggregation. This type of relationship is always used when objects of one class are a part of objects of another class.
In the class diagram in Figure 4.34 aggregation is used on the left side (the white diamond), which can be read as follows:
- A ticket (1) consists of (2) 1 to 4 (3) coupons (4).
or the other way around:
- A coupon (4) is part of (2) exactly one (5) ticket (1).
Email System Class Diagram
The example without a diamond, but with a name for the association, has exactly the same meaning! The last missing element of UML that we use to model class diagrams is generalization/specialization, which serves to depict the relationship between a superclass and a subclass. The generalization/specialization in Figure 4.35 can be read from top to bottom or bottom to top. If you begin at the top, you find a class Freight(1) with the attributes: Identification, Weight, and ID-number (2). This class has two specializations, Piece of Luggage(3) and Piece of Cargo(4). The class Piece of Cargo has an additional attribute: Degree of Hazardousness (5).
How Email Works Diagram
If you begin at the bottom you will find the classes Piece of Luggage (3) and Piece of Cargo (4). These have a superclass, the class Freight (1), which contains the shared attributes (and functions) of the subclasses.