Update 1-3-Modeling.md

PR-URL: #141
Co-authored-by: Timur Shemsedinov <timur.shemsedinov@gmail.com>

Author: mariana-shemsedinova

content/en/1-3-Modeling.md

@@ -1,3 +1,13 @@
 ## 1.3. Modeling: abstractions and reuse
 
-No translation
+The heart of programming is modeling, that is, the creation of a domain model or a model of objects and processes in the memory of the computers. Programming languages provide syntaxes for constructing constraints when creating models. Any construction and structure designed to expand functionality and introduced into the model leads to additional restrictions. Increasing the level of abstraction, on the contrary, can remove some of the restrictions and reduce the complexity of the model and the program code that expresses this model. We are constantly balancing between expanding functions and collapsing them into a more generalized model. This process can and should be iterative multiple times.
+
+Surprisingly people are able to successfully solve tasks with complexity exceeds of their memory and thinking abilities, with the help of building models and abstractions. The accuracy of these models determines their usefulness for decision-making and the development of managerial influences. The model is always inaccurate and reflects only a small part of reality, one or more of its sides or aspects. However, in limited conditions of use, the model can be identical to the real object of the subject area. There are physical, mathematical, simulation and other models, but we will be interested primarily in informational and algorithmic models.
+
+Abstraction is a method of generalization that reduces many different but similar cases to a single model. We are interested in data abstractions and abstract algorithms. The simplest examples of abstraction in algorithms are loops (iterative generalization) and functions (procedures and routines). With the help of a loop, we can describe many iterations with one block of commands, assuming its repetition several times, with different values of variables. Functions are also repeated many times with different arguments. Examples of data abstraction are arrays, associative arrays, lists, sets, etc. In applications there are abstractions need to be combined in layers, we call them abstraction layers. Low-level abstractions are built into the programming language (variables, functions, arrays, events). Higher-level abstractions are contained in software platforms, runtimes, standard libraries, and external libraries, or can be built independently from simple abstractions. Abstractions have such a name because they solve abstract generalized tasks (general purpose manipulations) not related to the subject area.
+
+Building abstraction layers is perhaps the most important programming task, the successful solution of which depends on the characteristics of the software solution, such as the flexibility, the cost of modification, the ability to integrate with other systems, and the life span of the solution. We will call all layers that are not tied to the subject area and specific applied tasks system. Above the system layers, the programmer superimposes application layers, the abstraction of which, on the contrary, decreases, the universality decreases, and the application becomes more specific, being tied to specific tasks.
+
+Abstractions of different levels can be both in the same address space (one process or one application) and in different ones. It is possible to separate them from each other and to implement interaction between them with the help of programming interfaces, modularity, component approach and simply by willpower, avoiding direct calls from the middle of one software component to the middle of another one, if the programming language or platform does not take care to prevent such an ability. This should be done even within one process, where any functions, components, and modules could be accessed from any other, even if they logically belong to different layers. The reason for this is the need to reduce the interdependence of layers and software components, ensuring their interchangeability, reuse and making their separate development possible. At the same time, it is necessary to increase the connectivity within the layers, components and modules, which ensures the growth of the productivity of the code, its ease of reading, understanding and modification. If we manage to avoid the connection between different levels of abstractions, and with the help of decomposition to ensure that one module can always be fully covered by the attention of one engineer, the development process becomes scalable, manageable and more predictable. A similar idea is the basis of microservices architecture, but the more general principle applies to any system, and it does not matter whether they are independently running microservices or modules running in the same process.
+
+We must note that the better distributed the system is the better centralized ones. Therefore, how to solve tasks in such systems are at adequate levels, where there is already enough information for decision-making, processing and obtaining a result, there is no rigid connection of models of different levels of abstraction. With this approach, there are no unnecessary escalations of the task to higher levels, "overheating" of decision-making nodes is avoided, data transfer is minimized and operational speed is increased.