Training:Short introduction to UML– class diagram

Short introduction to UML– class diagram

This page was created by Alexandra on 2017-05-13. Last edited by Wikiadmin on 2026-07-29.

You can use a UML class diagram to describe the important information in a domain before you build it in MDriven Designer; this introduction is for new modelers.

Information design starts by identifying the information a business handles. A UML (Unified Modeling Language) class diagram is the preferred way to describe that information in MDriven. It shows the concepts in the domain, the data held for each concept, and the relationships between concepts.

Start with a class and its objects

A class is a definition of a concept. An object is one individual instance of that class.

For example, Car is a class. Your car, another person's car, and the car with registration number ABC are objects of the Car class. One class can therefore have many objects.

Term	Meaning	Car example
Class	A definition of a concept.	`Car`
Object	One instance of a class.	The car whose registration number is `ABC`
Attribute	A named value stored on each object of a class.	`RegistrationNumber`
Attribute type	The kind of value an attribute can store.	`string` for `RegistrationNumber`

A class diagram normally displays a class as a box. The class name identifies the concept, and the box can show its attributes and operations. For the notation and role of class diagrams in MDriven, see Documentation:Class diagrams.

Add attributes to describe each object

An attribute is information that belongs to each object of a class. Every attribute has a type. Common types include String, Integer, Double, and Datetime.

For example:

Car
  RegistrationNumber : string

Each Car object has its own place to store a registration number. A car with registration number ABC and a car with registration number XYZ are separate objects with separate attribute values.

The terms attribute and property are often used for the same idea in this context.

Connect classes with associations

Classes usually relate to other classes. In UML, an association describes such a relationship. The terms relation, association, and link are often used interchangeably when discussing a class diagram.

Consider these two classes:

Car
  RegistrationNumber : string

Brand
  Name : string

A relationship between Car and Brand lets you state that a car has a brand and that a brand can identify its cars.

Read association-end names from the far side

An association has two ends. Each end has a name and a cardinality. When you follow an association from one class, read the name at the far end.

For a Car–Brand association, you might name the end at Brand BrandOfTheCar, and the end at Car CarsOfTheBrand.

You can then read the model in both directions:

From Car: “A car has a BrandOfTheCar.”
From Brand: “A brand has CarsOfTheBrand.”

Use endpoint names that make these sentences clear. Names such as BrandOfTheCar and CarsOfTheBrand communicate more than generic names such as Items or Links.

Use cardinality to state how many objects are allowed

Cardinality is the rule on an association end that states how many objects may occur at that end of the relationship.

Cardinality	Meaning	Example interpretation
`0..1`	Zero or one object is allowed.	A car may have no recorded brand, or one recorded brand.
`1`	Exactly one object is required.	Each car must have one brand.
`*`	An unlimited number of objects is allowed.	A brand can have any number of cars.
`0..*`	Zero to an unlimited number of objects is allowed.	A brand can currently have no cars or many cars.
`y..x`	From `y` through `x` objects are allowed.	`1..3` requires at least one and permits at most three objects.

For example, if each car must have one brand and a brand may be associated with many cars, the association has 1 at the Brand end and 0..* (or *) at the Car end. Read each value from the opposite class: a Car has one BrandOfTheCar; a Brand has zero or more CarsOfTheBrand.

Decide whether something should be an attribute or a class

The classes, attributes, and associations together constitute a model. A model is a simplified description of something real, made for a purpose. Judge it by whether it fulfills that purpose.

For example, you could model a car's brand as an attribute:

Car
  Brand : string

Or you could model Brand as its own class and associate Car with it:

Car -- Brand
Brand
  Name : string

The second option records a brand name once in a Brand object and lets many cars refer to that object. For example, one Brand object named Plymouth can be associated with many Car objects. In this situation, Brand acts as a value store: it holds a reusable set of brand values instead of repeating the same text on every car.

This does not make the class-based option universally more correct. Choose the representation that supports the information, rules, and behavior your system needs.

Use the language of the domain

Name classes and relationships after the concepts used by the people who work in the domain. If the domain says “Car”, model Car; if it says “Brand”, model Brand. This gives modelers and domain experts a shared, ubiquitous language.

Avoid making a model harder to read by replacing meaningful concepts with overly generic names. For example, naming the classes A and B instead of Car and Brand forces readers to find separate documentation before they can understand the model. Physical things, such as cars, and abstract concepts, such as brands, can both be valid classes.

Try it in MDriven Designer

Use this small exercise to turn the example into a model:

Create a new model and add a Car class.
Add the attribute RegistrationNumber with type string.
Add a Brand class and give it a Name attribute.
Create an association from Car to Brand.
Name the association ends so that they read clearly from the opposite class, for example BrandOfTheCar and CarsOfTheBrand.
Set the cardinalities that express your rule. For example, use 1 for the brand of each car and 0..* for the cars of a brand.
Read the association in both directions and confirm that both sentences describe the intended domain rule.

For guided MDriven Designer steps that create a Car class, add an association, name its ends, and set cardinalities, follow Training:Bootcamp:Chapter 1. The same training also explains the difference between a diagram and an auto diagram. In MDriven Designer, removing an item with Delete removes it from the current diagram, not from the model; use Ctrl+Delete when you intend to remove it from both the diagram and the model. See Training:Bootcamp:Chapter 2 for that workflow.

Continue learning

Class diagrams cover more than the basics introduced here. Use inheritance when one class is a specialized form of another, such as Apple being a specialized Fruit; see Training:UML Inheritance. Use an association class when the relationship itself needs information, such as a Booking between a Person and a Flight; see Training:Association classes.

Contents