How to draw a class diagram correctly?

Question

Programming

I read the book by Edison Wesley "Object-Oriented Design", and it would seem, according to the recommenders, that all questions should disappear.
But I don’t understand anything about what rules the class diagram is built on, because I’m designing a project for the tenth time, which I still started writing “it will be seen as it is implemented”, and this model was written on the board for the view, in fact it was drawn after the code was written.
I completely understand the difference in programming between a trait, an abstract class, an interface, just a class, a namespace, an exception, and all the instructions. It is incomprehensible to me in life - why so many concepts have been introduced, give me some NLP map to understand this.
Here he describes the situation - an electrical circuit: there is one microcircuit, there is another microcircuit, they have legs, which means that the leg of one is connected to the leg of the other, for some reason forming a bus (I suppose radio engineering understands several circuits as a bus, I can’t say for sure), total he draws the model:
Left element - Leg - Bus - Leg - Right element
Yes, in short, here: https://www.screencast.com/t/oLlvyP36mJ
The central part of the leg-tire-leg is repeated several times in the picture. After that, it begins to draw up a class diagram:
Abstract class Abstract Chain contains the "Rules" property
The Chain class inherits from Abstract Chain contains the Bus property
and as a result, this scheme is obtained
https://www.screencast.com/t/1iJgtfqTdv2
As he understood that it should look like this. It's just "there is a house", let's draw a project "so, if the bedroom, then - the project is ready, otherwise - the project without the bedroom is ready." Why - it's not clear how it turned out - it's not clear, why bother with an abstract class, if the class itself is an abstraction from an object?
How did he understand that the Rule method should be in an abstract, but just a class - a bus method? Why aren't both in an abstract, or why aren't both in a simple class?
True, he writes either in Java or in C, but what is the essence of the concepts?

Answer 1

In general, this is the correct approach to diagrams. )
Here's what Bob Martin wrote:
"Make it a habit to throw away unneeded UML diagrams.
Better yet, don't create them on a permanent medium. Draw on the board or
on scraps of paper. Erase the board often and throw away those scraps
. Don't get used to CASE tools or graphics
editors. There is a time and a place for such tools, but
most UML diagrams don't last long."
Although, further, it is useful to save some. The general design of the system (idea) or those points that will be difficult to understand from the text of the program.
Simplified, you can approach the selection of classes and interfaces in this way.
There are two real objects. They belong to different classes. With their own characteristics. But they have some of the same properties. For example function templates. In general, quicksort is a template that implements an algorithm, but this template does not know how to actually compare objects. That is, it is an abstract class that combines specific quick sorts of specific objects. We can say that an abstract class is the removal of common methods and fields from their descendants. Despite the fact that in reality we will never create an instance of this class.
Interface selection. It is usually used to separate systems into separate dependent parts. For example, a button turns on a lamp. In the program it is implemented like this
The button has a lamp field. those. the implementation of the button depends on the lamp. If the type (or code) of the lamp has changed, then the part of the code responsible for the button also changes. Should at least be tested. But you can agree to separate all devices that can turn on something (buttons) and can be turned on (lamps, motors, TVs ...) and indicate how they interact.
Those. something like this:
The button controls devices.
The device must have an "enable" method.
Lamps, TVs, engines must implement this method in their own.
In total, the same button (without changing the code) controls a whole group of heterogeneous devices (but implementing common rules of interaction)
From the pictures:
we have objects
connection 0, connection 1, ... connection 3
also a bus object from links.
what they all have in common is that they all have a name.
also they have some signaling rules.
This gives us two classes Net and Bus. In addition, Bus includes a lot of Net.
Further, I would like these classes to be independent of the rules. i.e. that we could assign the rules ourselves. perhaps dynamically. Therefore, net and bus have a method that assigns rules rule (with a common interface) (which can be changed, and not change the implementation of net, bus ).
Total Selected common properties from net, bus into the AbstractNet abstract class. bus includes many net. Moved the rules (which will change often and which we may not yet know) for a common interface.
more or less like this. simplified.