Diagrams in UML Notation

Abstract

UML diagrams and the way they are used, since the very beginning of this notation, have aroused emotions and waves of conflicting comments. The reason for this is the high level of abstraction of the analysis and modeling stage as a discipline, and a fairly widespread misunderstanding of the essence of this notation. This is compounded by the huge difference between what we call object-oriented analysis and design (OOAD) and object-oriented programming languages (OOP).
UML notation is mistakenly treated by many people as just another set of symbols for creating illustrations. Most developers I know believe that these diagrams don't help them at all, and they are generally right, because the quality and content of much of the documentation produced using UML, is poor, and such documentation is actually useless to the software vendor.
Why is this the case? In my opinion, it's a misunderstanding of what software is, especially when we're talking about software that supports so-called business, or information management in the broadest sense. This is compounded by a misunderstanding of the difference between a system's ontology and the system itself, and what its mechanism of operation really is.
I have written a great deal about modeling and information management, here I will describe the basic concepts of modeling and the key UML diagrams from the side of their classification and application