UML class diagram is the preferred way to describe information.

A UML class diagram shows classes and their relations.

A Class differs from an Object. The Object is of a Class. The Class may have many instance objects each being of the Class.

Class can be regarded as the “Concept” of something. Like if I have class named “Car” – it is likely to symbolize the fact that there are Cars and Car is a concept that exists and that there are probably instance objects of this class as my car, your car and the car with license plate ABC.

A class typically has attributes. One attribute of Car might be License plate number. Attributes must have types. Typical types are string, integer, double and datetime.

This means that once we have objects of class Car – these objects will have a place to store the License plate number of just that car.

Classes typically has relations to other classes (relation, association, link are sort of synonyms and can be used interchangeably )

Relations has two endpoints. The endpoint has a name. When you read a class diagram and your eye follow a relation you should use the name on the far side of the relation. So in this example I would say: “There is the concept of Car. Cars has a LicensePlate string. Cars also has a BrandOfTheCar with a Name”. And if I was talking about brand: “There is the concept of Brand. Brands has a name. Brands also has Cars of the brand that in turn has LicensePlates”.

Relation endpoints also has Cardinality. Cardinality is a rule that describes how many instances there can be in the relation endpoint. The cardinality marking of star (*) means “unlimited”. Valid cardinality markings are: 0..1 (zero or one instance allowed), 1 (must always have 1 instance), y..x or x where y and x is any number or x is star (*).

This was the basics of UML – there are more of course – but this is what you need to get started.

How do I know if it is correct

The classes we have defined above – along with their attributes and associations – constitutes a model.

A model is always a model of something. A model is simplified version of true/reality concepts that you model. The model should have a purpose.  The validity of the model comes from if it fulfills its purpose or not.

There is no universal right or wrong – it all depends on what your needs are.

I could just as well have said that the Brand was an attribute of Car.

But I chose not to since I do not want to have the brand “Plymouth” repeated 10 million times  on each and every “Plymouth”(if there are 10 million plymouth car objects). Instead I rather just see “Plymouth” typed in once – in the brand class name property (property and attribute are essentially synonyms). This pattern – to classify attributes as being concepts of their own I often refer to as the value store pattern. The Brand being the ValueStore of brands and each Car instance gets tagged by at most 1 brand.

So for me – in this situation – this is better – but it is not more correct:

The process of modeling can be thought of as a process of describing the important things. As you model, you will have classes that represent physical objects, like Car, but also abstract things like Brand. This is perfectly normal.

This way of describing information does not dictate if you follow the language of the domain you are modeling or not. In principle, you could have named the class Car for “A” and the class Brand for “B”. You could then document someplace else that A is actually Car and B is actually Brand.

You may think that this was a very silly example but this is actually what is done and has been done in thousands of system implementations. Sometimes it is due to some limitation of the implementation tools and sometimes it is an ambition to make the resulting system more generic. Think of SAP for example – they call a class “Part” – and document someplace else that for this system instance Part means either a gear or a frame or a saddle.

So if the will to make systems more generic makes your model less readable and more abstract than your reality is – what is the alternative?

The alternative is called Domain Driven Design (or DDD for short) – this was defined in the book by Eric Evans. In short, it stipulates that you should use the language of the domain you are modeling. This way you – the modeler – and the people working in the domain – get a ubiquitous language and as a result, you understand each other.

My experience is that being so close as possible to the language used by the domain is beneficial to everyone. It makes everything much more clear and easier. Most information architects has done this long before it was given the DDD name.