How to confuse the analyst. Part one
- The army learned to combine space and time.
- How?
- Very simple! The ensign gives the task: "Today we will dig from the fence to lunch"
In this article I’ll start a story about confusions that occur regularly and that migrate into information models without any critical analysis.
In the last article I gave the definition of the type and attribute. I will remind them:
')
It was the definition of the type and the definition of the attribute based on the analysis - we divided the heap into parts. In fact, it was a type construction using analysis. Now I will show how you can build types and attributes based on synthesis.
You can take a lot of boats, a lot of inflatable mattresses, a lot of seaplanes, combine them into one set and get a lot of swimming facilities. So many boats will be obtained by synthesizing several sets.
Earlier, I argued that the type "object" is not output. By deducibility we mean the selection of a subset from a superset. However, the type of "object" can be synthesized. To do this, there must be an expert who determines whether a new accounting object is related to the type of objects or not. In this way, the type of "object" can be synthesized. Synthesis can be done in the following ways:
You can do the same with an attribute. You can take a few piles, assign values ​​to them, combine them together and call it all an attribute.
Let us generalize to any operations on sets:
You can say that operating in heaps is too primitive. After all, we are able to work with such abstractions as graphs, logic, algebra. However, the introduction of new abstractions without a deep understanding of what is behind this, quickly leads to the fact that we are becoming confused. At the same time, mathematicians, using their tools, do not make logical mistakes, because, on the one hand, they adhere to a rigid discipline of reasoning, which they are taught to study the fundamentals of mathematics, and, on the other hand, by creating models for solving specific problems, they do not burden themselves by combining these models among themselves. We, building models of different subject areas, often do not possess the necessary mathematical apparatus, for example, we do not know what Jordan's measure is, or what scaling is, but at the same time we solve the most complicated tasks of docking of different models. For example, you can easily encounter models, in one of which color is expressed by the wavelength, in the other - by the frequency of oscillation of electromagnetic waves, and in the third - by words like “red”. Or it may happen that “collie” in one model is an attribute of the class “dogs”, in the other it is a separate class of objects. Of course, you can build a conversion from one model to another. But how do you do it, and what is behind it?
In order not to be confused, you can use a simple method - to rely on what we all can do at the genetic level: divide piles into pieces, put piles together. Therefore, my story about types and attributes, although it seemed so naive, pursued a very important goal: to demonstrate how to build models based on this basis. I tried to introduce the concepts of type and attribute as they would have introduced their mathematics, but in a language understandable for the applied person.
To understand what confusions I'm talking about, you need to ask simple questions:
The answer is simple: mathematics is nothing more than a modeling tool. But the question is: what? The accounting object, the type of accounting objects, the class to which the accounting object belongs, or the accounting object model? Using numbers, formulas, graphs, etc., you can easily get confused and not give an exact answer to this simple question. When on one canvas there are models of objects of accounting, models of types and models of models, working with this canvas will require great care. My experience suggests that errors in this case are guaranteed.
Let's start with the accounting object model. The object of accounting is what the subject singled out as part of the real world, but not yet classified and not named, for example, a four-dimensional space-time volume. Further, this accounting object goes through the stage of modeling in the subject's mind using a metamodel. Metamodel is a person's idea of ​​how to produce modeling. For example, for all of us, there is a common notion that there are objects, there are actions performed by objects, there are types of objects, types of actions they perform and properties. This metamodel was noticed and well described by Aristotle. He has only one question left unanswered: if there is an attribute “height” in trees, and there is an attribute “height” in buildings, is it the same attribute, or are they different attributes? We do not know what Aristotle thought about this topic, but we know what we think about it: everything depends on the point of view of the subject and the tasks to be solved - this may be one attribute, and there may be different attributes.
Metamodel, which Aristotle noticed, and on the basis of which our consciousness works, has severe limitations. This is due to the fact that the language with which we express our models, balances on the verge between completeness and brevity. If the language is complete, the statements in this language will be so heavy that in the real world a person will not survive. If the language is brief, it will be a narrow specialized contextual language inapplicable to all occasions. A universal language is located between these extremes, therefore it is neither complete nor short.
Mathematicians faced the limitations of the meta model, on the basis of which we build models in our consciousness and tried to develop our own meta model, devoid of these shortcomings. This metamodel consists of objects and sets. The advantage of this metamodel is that it allows you to build consistent and extensible models. The disadvantage is that models built using this metamodel are poorly translated into ordinary human language and are rather cumbersome.
If there was a modeling standard built on sets and objects, then using this standard it would be possible to build models in which types would be modeled by sets, attributes would be sets of sets, and the model itself would be infinitely extensible. But so far this standard does not exist. Perhaps the fact is that the models built on this metamodel would be quite plump in volume, since for each attribute value in the model one would have to create a separate class of objects. It is possible that on the way to the creation of such a standard, we are constrained by the habit of thinking with types and attributes. Anyway, there is no such standard yet and this is bad. Bad in terms of modeling theory.
In practice, the existing standards of modeling try to sit on two chairs at once, simultaneously simulating types, sets and attributes.
So for modeling of types in OOP "classes" are used. They are modeled by a set of attributes embedded in them. You can also specify the name of the objects of this type. But nothing more to describe the type in the PLO is not provided.
To model attributes in OOP, attributes of these "classes" are created. If you need to model attributes common to several types of objects in OOP, you will need to create an empty “superclass” whose “heirs” will model these types of objects. It is clear that without multiple legacy is not enough.
Suppose that in OOP it is still necessary to model other properties of a type, for example, to indicate the unique features of objects of a given type. To do this, you can cheat. You can create a “class” whose objects are types, that is, create a “class” of types whose “instances” are object types. Thus, two objects simulating one type will appear simultaneously in the model: the “class” of objects and, the associated “instance” of the “class” of types. At the same time, there are no regular mechanisms in the PLO, which would preserve the integrity of this model. Now the integrity of the model will depend on the accuracy of the programmer.
If you want to simulate a lot, then OOP uses various methods: lists, collections, and so on. But this modeling is only the composition of the set. The set itself can not be modeled using standard methods in OOP, just like set operations. To create a model of a set, it is necessary to create a “class” of sets, an “instance” of which will model the set. Then the collection and this object associated with it will together model one object - the set. And again, the integrity of the model in the hands of the programmer.
Programmers often think that object type modeling and object modeling are one and the same. For example, a class in OOP is for some reason persistently referred to as an object, for example, a cup, and not a type of objects, and an object for some reason is persistently called an “instance of this cup” and not a “cup. Because of this, standards are born with conflicts already embedded in them.
Have you ever heard that a process can be modeled using a directed graph? Here is an example . You know that a directed graph may or may not have cycles. It is clear that if we are talking about a sequence of operations, the graph modeling the sequence of operations cannot have cycles, since time always moves forward and cannot move backwards. A graph that satisfies this requirement is called a network. But a model built in BPMN notation may contain loops. Therefore, it is possible to make a logical conclusion that in the BPMN notation we model not a sequence of operations, but something else. Personally, this seems obvious to me, but there are very few programmers who understand this. Numerous examples of this can be found in the discussions of my articles.
Another confusion arises from the fact that programmers often do not make a difference between object types and sets of objects. For example, it is believed that a class in OOP is a model of a set. But alas, it is a model of the type of objects, but not a model of a set. Because of this confusion, when it is necessary to model a set of structural elements consisting of objects and connections between them, programmers succumb. It is difficult for them to imagine how objects of different types can get into one set.
These were examples of common confusions, but beyond the circle of programmers not going out. There are those that are much more common. In the following articles we will try to talk about them.
- How?
- Very simple! The ensign gives the task: "Today we will dig from the fence to lunch"
In this article I’ll start a story about confusions that occur regularly and that migrate into information models without any critical analysis.
In the last article I gave the definition of the type and attribute. I will remind them:
')
- A type is the selection of a handful (subset) from a heap (set) and the endowment of the objects of this handful with a unique name - a noun.
- The attribute divides the heap (set) into heaps (subsets) and endows the objects of these heaps with different adjectives.
It was the definition of the type and the definition of the attribute based on the analysis - we divided the heap into parts. In fact, it was a type construction using analysis. Now I will show how you can build types and attributes based on synthesis.
You can take a lot of boats, a lot of inflatable mattresses, a lot of seaplanes, combine them into one set and get a lot of swimming facilities. So many boats will be obtained by synthesizing several sets.
Earlier, I argued that the type "object" is not output. By deducibility we mean the selection of a subset from a superset. However, the type of "object" can be synthesized. To do this, there must be an expert who determines whether a new accounting object is related to the type of objects or not. In this way, the type of "object" can be synthesized. Synthesis can be done in the following ways:
- listing all accounting objects of this type
- listing all types of accounting objects that belong to this type.
You can do the same with an attribute. You can take a few piles, assign values ​​to them, combine them together and call it all an attribute.
Let us generalize to any operations on sets:
- Type - a common property of the objects of the set and the common name for these objects. In this case, the identification of the composition of the set is possible in any convenient way.
- An attribute is a set of subsets, each subset of which corresponds to a unique attribute value.
You can say that operating in heaps is too primitive. After all, we are able to work with such abstractions as graphs, logic, algebra. However, the introduction of new abstractions without a deep understanding of what is behind this, quickly leads to the fact that we are becoming confused. At the same time, mathematicians, using their tools, do not make logical mistakes, because, on the one hand, they adhere to a rigid discipline of reasoning, which they are taught to study the fundamentals of mathematics, and, on the other hand, by creating models for solving specific problems, they do not burden themselves by combining these models among themselves. We, building models of different subject areas, often do not possess the necessary mathematical apparatus, for example, we do not know what Jordan's measure is, or what scaling is, but at the same time we solve the most complicated tasks of docking of different models. For example, you can easily encounter models, in one of which color is expressed by the wavelength, in the other - by the frequency of oscillation of electromagnetic waves, and in the third - by words like “red”. Or it may happen that “collie” in one model is an attribute of the class “dogs”, in the other it is a separate class of objects. Of course, you can build a conversion from one model to another. But how do you do it, and what is behind it?
In order not to be confused, you can use a simple method - to rely on what we all can do at the genetic level: divide piles into pieces, put piles together. Therefore, my story about types and attributes, although it seemed so naive, pursued a very important goal: to demonstrate how to build models based on this basis. I tried to introduce the concepts of type and attribute as they would have introduced their mathematics, but in a language understandable for the applied person.
To understand what confusions I'm talking about, you need to ask simple questions:
- Why as a result of multiplying 3 apples and 4 baskets, it turns out 12 apples, and not 12 baskets, or 12 apple-baskets?
- Why do 3 Amperes multiplied by 4 Volts give 12 Watts, not 12 Amperes, or 12 Volts?
- Why does 3 meters multiplied by 4 meters give 12 square meters?
- Why does Pascal go to the bar and see that there are 100,000 Pascals?
- Why do models of linear space transformation and linear basis transformation look exactly the same: as a matrix? Although the physical meaning of these actions is completely different?
The answer is simple: mathematics is nothing more than a modeling tool. But the question is: what? The accounting object, the type of accounting objects, the class to which the accounting object belongs, or the accounting object model? Using numbers, formulas, graphs, etc., you can easily get confused and not give an exact answer to this simple question. When on one canvas there are models of objects of accounting, models of types and models of models, working with this canvas will require great care. My experience suggests that errors in this case are guaranteed.
Let's start with the accounting object model. The object of accounting is what the subject singled out as part of the real world, but not yet classified and not named, for example, a four-dimensional space-time volume. Further, this accounting object goes through the stage of modeling in the subject's mind using a metamodel. Metamodel is a person's idea of ​​how to produce modeling. For example, for all of us, there is a common notion that there are objects, there are actions performed by objects, there are types of objects, types of actions they perform and properties. This metamodel was noticed and well described by Aristotle. He has only one question left unanswered: if there is an attribute “height” in trees, and there is an attribute “height” in buildings, is it the same attribute, or are they different attributes? We do not know what Aristotle thought about this topic, but we know what we think about it: everything depends on the point of view of the subject and the tasks to be solved - this may be one attribute, and there may be different attributes.
Metamodel, which Aristotle noticed, and on the basis of which our consciousness works, has severe limitations. This is due to the fact that the language with which we express our models, balances on the verge between completeness and brevity. If the language is complete, the statements in this language will be so heavy that in the real world a person will not survive. If the language is brief, it will be a narrow specialized contextual language inapplicable to all occasions. A universal language is located between these extremes, therefore it is neither complete nor short.
Mathematicians faced the limitations of the meta model, on the basis of which we build models in our consciousness and tried to develop our own meta model, devoid of these shortcomings. This metamodel consists of objects and sets. The advantage of this metamodel is that it allows you to build consistent and extensible models. The disadvantage is that models built using this metamodel are poorly translated into ordinary human language and are rather cumbersome.
If there was a modeling standard built on sets and objects, then using this standard it would be possible to build models in which types would be modeled by sets, attributes would be sets of sets, and the model itself would be infinitely extensible. But so far this standard does not exist. Perhaps the fact is that the models built on this metamodel would be quite plump in volume, since for each attribute value in the model one would have to create a separate class of objects. It is possible that on the way to the creation of such a standard, we are constrained by the habit of thinking with types and attributes. Anyway, there is no such standard yet and this is bad. Bad in terms of modeling theory.
In practice, the existing standards of modeling try to sit on two chairs at once, simultaneously simulating types, sets and attributes.
So for modeling of types in OOP "classes" are used. They are modeled by a set of attributes embedded in them. You can also specify the name of the objects of this type. But nothing more to describe the type in the PLO is not provided.
To model attributes in OOP, attributes of these "classes" are created. If you need to model attributes common to several types of objects in OOP, you will need to create an empty “superclass” whose “heirs” will model these types of objects. It is clear that without multiple legacy is not enough.
Suppose that in OOP it is still necessary to model other properties of a type, for example, to indicate the unique features of objects of a given type. To do this, you can cheat. You can create a “class” whose objects are types, that is, create a “class” of types whose “instances” are object types. Thus, two objects simulating one type will appear simultaneously in the model: the “class” of objects and, the associated “instance” of the “class” of types. At the same time, there are no regular mechanisms in the PLO, which would preserve the integrity of this model. Now the integrity of the model will depend on the accuracy of the programmer.
If you want to simulate a lot, then OOP uses various methods: lists, collections, and so on. But this modeling is only the composition of the set. The set itself can not be modeled using standard methods in OOP, just like set operations. To create a model of a set, it is necessary to create a “class” of sets, an “instance” of which will model the set. Then the collection and this object associated with it will together model one object - the set. And again, the integrity of the model in the hands of the programmer.
Confusion of types and objects
Programmers often think that object type modeling and object modeling are one and the same. For example, a class in OOP is for some reason persistently referred to as an object, for example, a cup, and not a type of objects, and an object for some reason is persistently called an “instance of this cup” and not a “cup. Because of this, standards are born with conflicts already embedded in them.
Have you ever heard that a process can be modeled using a directed graph? Here is an example . You know that a directed graph may or may not have cycles. It is clear that if we are talking about a sequence of operations, the graph modeling the sequence of operations cannot have cycles, since time always moves forward and cannot move backwards. A graph that satisfies this requirement is called a network. But a model built in BPMN notation may contain loops. Therefore, it is possible to make a logical conclusion that in the BPMN notation we model not a sequence of operations, but something else. Personally, this seems obvious to me, but there are very few programmers who understand this. Numerous examples of this can be found in the discussions of my articles.
Confusion of types and sets
Another confusion arises from the fact that programmers often do not make a difference between object types and sets of objects. For example, it is believed that a class in OOP is a model of a set. But alas, it is a model of the type of objects, but not a model of a set. Because of this confusion, when it is necessary to model a set of structural elements consisting of objects and connections between them, programmers succumb. It is difficult for them to imagine how objects of different types can get into one set.
These were examples of common confusions, but beyond the circle of programmers not going out. There are those that are much more common. In the following articles we will try to talk about them.
Source: https://habr.com/ru/post/331882/
All Articles