This page helps new MDriven modelers describe domain information with classes, attributes, and relations in a UML class diagram.
Model information with classes
A class is a description of a group of objects that share properties, relationships, and meaning. An object is one specific instance of that class.
For example, Car is a class: it represents the concept of a car. A red 2019 Honda Civic is an object of the Car class. Many Car objects can exist, and each object has its own values.
Class diagrams are the UML (Unified Modeling Language) diagrams that show classes and the relations between them. In MDriven, use them to model the information your application needs.
Add attributes to describe each object
An attribute is a typed property on a class. Every object of the class has storage for its own value of that attribute.
For example, a Car class can have an attribute named LicensePlate with type String. One Car object can have "ABC123", while another has "XYZ789".
Attributes must have types. Common types include String, Integer, Double, and Datetime.
| Class | Attribute | Type | Example value |
|---|---|---|---|
| Car | LicensePlate | String | "ABC123"
|
| Car | Mileage | Integer | 125000
|
| Car | PurchasedAt | Datetime | 2026-01-15
|
Property and attribute mean the same thing in this context.
Connect classes with relations
A relation, also called an association or link, connects two classes. It describes how objects of one class relate to objects of another class. An association also represents the connection between objects and the data tables in the underlying database.
For example, model the manufacturer as a separate Brand class rather than repeating a brand name on every Car:
Carhas an association end namedBrandOfTheCar.Brandhas an association end namedCars.Brandhas aNameattribute of typeString.
Read an association by following it to the far endpoint and using that endpoint's name:
- A Car has a
BrandOfTheCarwith aName. - A Brand has
Cars, each with aLicensePlate.
Choose endpoint names that make these sentences clear. Use plural endpoint names for collections where the name fits your domain, such as Cars. The name does not need to be plural when a different domain term is clearer.
Set cardinality on each endpoint
Cardinality is the rule on an association endpoint that states how many related object instances are allowed. Set cardinality for both ends of every relation.
In the Car and Brand example, a Car can have zero or one Brand, while a Brand can have many Cars:
| Endpoint | Cardinality | Meaning |
|---|---|---|
Car.BrandOfTheCar
|
0..1
|
A Car may have no Brand or one Brand. |
Brand.Cars
|
*
|
A Brand may have any number of Cars. |
Valid cardinality forms include:
| Cardinality | Meaning | Example |
|---|---|---|
0..1
|
Zero or one related object | A Car may have no assigned Brand. |
1
|
Exactly one related object is required | An order has one customer. |
*
|
An unlimited number of related objects | A Brand has many Cars. |
y..x
|
From y to x related objects, where y and x are numbers or x is *
|
A team has 2..10 members.
|
Decide whether data is an attribute or a class
Model data as an attribute when it is a value owned by one object. Model it as a separate class when it is a concept that you want to share, identify, or give properties and relations of its own.
For example, LicensePlate is an attribute because each Car stores its own string value. Brand can be a separate class because many Cars can refer to the same Brand object. You enter "Plymouth" once in Brand.Name instead of repeating it for every Car.
This approach is sometimes called the value store pattern: a class holds reusable values, and other objects refer to one of those values. It is a design choice, not a universal correctness rule.
Validate the model against its purpose
Your classes, attributes, and associations form a model: a simplified description of the real concepts relevant to your application. A model is correct when it fulfills its purpose.
For example, if you only need to display the manufacturer text and never manage manufacturers independently, a BrandName String attribute on Car may meet the purpose. If you need one managed list of brands and many Cars assigned to each brand, model Brand as a class and relate it to Car.