Introduction to DSL. Part 0. Analysis of existing IT as a means of solving the problem of knowledge representation on subject areas

In the comments to the previous topic a lot was said that the article was dry, academic and badly chewed. And in general - why do we need DSL and what problems can it solve? In this regard, I have prepared a small introductory overview of the possibilities for representing knowledge about subject areas in general, in order to consider what place DSL occupies in it and why it is still convenient to use them.



To date, there are various ways to represent knowledge about subject areas. Among them are:
- textual representation;
- graphic representation;
- tabular presentation;
- formula representation.
Classification of ways of presenting knowledge about subject areas is presented in Figure 1.1.
Textual representation is the most common type of representation of knowledge about the subject area. Methods of textual representation of knowledge about subject areas are highlighted in Figure 1.2.
')




Figure 1.1 - Ways to represent knowledge of subject areas





Figure 1.2 - Methods of textual representation of knowledge about the subject area

Graphic representation is the most informative for a person; it allows you to see the structural elements of the subject area, the relationship between them and the processes occurring in the subject area. Methods of graphical representation of knowledge about subject areas are shown in Figure 1.3.



Figure 1.3 - Graphical ways of representing knowledge of the subject area

Tabular representation is convenient for subsequent processing on a computer, since most formalized of all the above. The most commonly used rectangular tables, consisting of rows and columns (graph). The top row of the table usually contains column headings. Table 1.1 is an example of a rectangular table containing weather information for several days.

Table 1.1 - An example of a table of type "Object-property"

date	Precipitation	Temperature (degrees C)	Pressure (mmHg)	Humidity (interest)
03/15/97	Snow	-3,5	746	67
03/16/97	No rain	0	750	62
03/17/97	Fog	1.0	740	100
03/18/97	Rain	3.4	745	96
03/19/97	No rain	5.2	760	87

This table is an example of an object-property type table.   Each row of such a table refers to a specific object. In the example above, this is a specific day given by the date. The first column usually identifies this object, the subsequent columns reflect the properties (characteristics) of the object.
Another type of table is called an object object.   Such tables reflect the relationship between different objects. An example is a table of student achievement in different subjects - table 1.2

Table 1.2 - Table of student achievement in different subjects

Pupil	Russian	Algebra	Chemistry	Physics	Story	Music
Alikin Peter	four	five	five	four	four	five
Botov Ivan	3	3	3	3	3	four
Volkov Ilya	five	five	five	five	five	five
Galkina Nina	four	four	five	2	four	four

This table reflects the relationship between the two types of objects: students and disciplines studied. Evaluation is a characteristic of such a relationship. In such a table, lines and graphs can be swapped: in the rows - objects, in the columns - students.
Formula representation is most often used when creating a mathematical domain model and stands apart from the previously presented ways of representing knowledge about subject areas.
Let us consider the text and graphic representations in more detail as the most natural and convenient for perception.
The textual representation is divided into a structured description and an unstructured description. Unstructured description is presented in plain text. The structured, in turn, is subdivided into executable (in one way or another executed on a computer) and non-executable. Non-executable tasks include a technical task (a structured and even a guest document containing general information about the subject area) and a set of business requirements (a structured document containing extended information about the subject area).



Executable textual ways of presenting knowledge about subject areas are already more technologies than ways from the point of view of a programmer. However, if you look at the DSL, XML and domain ontologies presented in this classification by the domain expert, these methods are much closer to the natural language of describing processes taking place in the subject domain than many others. In addition, due to its structuring, these ways of representing knowledge of subject areas are convenient for execution into program code.
Graphical presentation can also be divided into structured and unstructured. The unstructured presentation includes drawings, graphs and photographs that describe the subject area visually well, but are not sufficiently formalized for further work with them. Structured, in turn, can be divided into a representation in the form of diagrams and in the form of object models.
The diagrams are represented by UML, SADT, Data Flow and associative maps (Mind Map). This way of describing the subject area is constantly dynamically developing, new specifications and possibilities for their construction appear. It is fairly formalized and is currently the basis for the design of software systems.
Object models include graphs and graphical languages ​​of the domain description. The latter are closest to the natural description of the subject area and allow you to express an idea of ​​the subject area in terminology inherent in a particular subject area.
As we see from the classification, among the structured knowledge representation models that a user who is an expert in the subject area but who is not a programmer at all, can operate with are:

1. Terms of Reference
2. A set of business functions
3. DSL

EVERYTHING. To create other models, it is necessary to have an additional set of knowledge that does not belong to the subject area of ​​the expert. And if we now take for granted the fact that the technical task and a set of business functions are not executable models, it turns out that at present DSL is the only way to describe their knowledge of the subject area by an expert who has no training in programming. And this is the only way for the subsequent reduction into the program code of the finished product, which requires a slight doping on the part of the programmer.
If you have an alternative point of view, you do not agree with any thoughts or you want to express your opinion on this matter - I ask in the comments, I like constructive criticism and useful discussion on the matter.