UML Class Diagram Template

About the UML Class Diagram Template

A UML class diagram is a static model of an object-oriented system that defines objects by their classes, attributes, and functions. Using a class diagram, a programmer should be able to implement code to build the described system without needing any additional information.

Read on to learn more about UML class diagrams and how you can make your own using Miro’s template.

What is a UML class diagram?

You can think of a UML class diagram as a “recipe” for an object-oriented system. Much like a recipe includes ingredients, amounts, and directions, a class diagram explains the system in terms of what object classes are involved, what attributes they hold, and what operations they should perform.

Class diagrams are a part of UML (Unified Modeling Language), a set of tools for modeling software designed to help developers express their ideas. It consists of a whole family of diagrams, divided into those that model structure and those that model behavior.

The class diagram is a structural diagram, part of the family that models the static relationships of a system in a steady state. It’s a vital tool for object-oriented programming (OOP).

Classes are the basic model elements of this object-oriented design diagram. A class is a set of attributes, the variable traits that define the class as an object, and operations, which are the functions that object performs.

For example, the class “refrigerator” could have the attributes height, capacity, and number of doors, and it would have the operations refrigerate, freeze, and dispense water. The class is a blueprint that doesn’t exist in itself, but any object that fulfills its attributes and operations must be a refrigerator.

A UML class diagram is a set of classes with instructions on how they relate to form a full system. It looks unassuming — just several boxes with lists in them, all connected with lines — but you can use it to model almost any software system in the world.

Benefits of a UML class diagram

Object-oriented programming was originally developed in response to procedural programming, which defined software entirely in terms of instructions. This made it extremely hard to isolate any single aspect of the program.

OOP thinks of programs like machines with interlocking parts. Each object is defined as a class with attributes and operations, making it easy to understand how it works and relates to other objects. Using the object as your main building block makes it easier to design and improve systems.

A UML class diagram is one of the most important tools for facilitating object-oriented design and development. It’s useful for building conceptual models of software systems and for actually writing the code.

Like all UML diagrams, it’s simple enough that you can use it to plan a system, but it carries enough detail to provide instructions on how to implement it in reality. One developer can come up with an idea, plan it with a class diagram, then hand that diagram off to another coder — and get back something very close to what they envisioned.

Create your own UML class diagram

Miro’s online whiteboard tool is the perfect canvas to create and share UML class diagrams with your team. Get started by selecting this UML class diagram template. Then, follow these steps:

Step 1: Define the system you want to model.

As always, the first step is to clarify your objectives. Whether you’re modeling a system that hasn’t been created yet or illustrating an existing system for troubleshooting purposes, you’ll need to define a scale — which details you’ll illustrate and which ones you’ll leave out. This is also referred to as your diagram’s level of abstraction.

Step 2: Add rectangles for each object, and label it with a class.

Each object starts with a rectangle, which should be divided into three segments with two horizontal lines. The top section should be the smallest. Add the name of each object’s class in boldface text, and center it in the top division of each rectangle.

Step 3: Label each class with its attributes and operations.

Attributes should go in the second division and operations in the third. Start each attribute or operation with a symbol denoting whether it’s public (+), private (-), or protected (#). Then add the name of the attribute, a colon, and the type of attribute or operation it is.

For example, ‘+(attribute name): int’ is a public instance attribute called (attribute name).

Step 4: Draw the relationships between classes.

When all your objects are defined in the diagram with classes, attributes, and operations, your next step is to illustrate how they work together. UML recognizes several forms for the relationship between classes in a structural diagram. The most common are:

• Association: An equal relationship. The two objects require each other to fully execute their functions. Illustrated with a solid line.

• Inheritance/generalization: One object is a specific example of another more abstract class. Illustrated with a solid arrow with an unshaded head pointing at the parent class.

• Realization: One object specifies instructions and then transmits them to another object for implementation. Illustrated with a dotted arrow with a shaded head pointing at the implementing object.

• Dependency: One object changes its execution depending on the status of another object. Illustrated with a dotted arrow with an unshaded head pointing at the object depended on.

Once you’ve illustrated every type of association at your desired abstraction level, you should have enough information in your diagram for any coder (with the right skills) to build the system. Look over your diagram one more time to see if you’ve left any critical data to inference or assumption.

Step 5: Update the class diagram as you implement the system design.

Real-world implementations never look exactly like the design. As you build and/or debug the system, revise the class diagram to reflect reality.

You can also share your diagram with your team and key stakeholders to get feedback and update your diagram accordingly.

Common use case of an effective UML class diagram

Suppose a company is adding a fulfillment system for orders to their online shop. Since the shopping system is already well-established and documented, the team decides to represent it at a high level of abstraction with one object.

They create classes for the customer and the moment of ordering (leaving out the payment system, which is defined elsewhere), then add another object to represent individual items, and a fourth to represent delivery.

Next, they add attributes and operations. The class “order” gets attributes date, quantity, and delivery status, and “type” and “weigh” operations that depend on the “item ordered” class. The “item ordered” class gets attributes type and weight. The main attribute of the “delivery” parent class is distance and a binary value noting whether it crosses international borders.

The team realizes they need more objects here and creates three to represent delivery by air, sea, and land.

They finish up by adding relationships. Customer and order are an equal association. The operations of the order are dependent on the attributes of the item ordered. The three shipping methods are specific instances of delivery, the parent class.

Now that it’s complete, the object diagram serves as a recipe for building a complete shipping system that organizes and delivers goods bought online.