How to confuse the analyst. Part Two: What is domain modeling?
In the last article, I talked about the errors that programmers are prone to and promised to tell you about errors that not only programmers, but also each of us, are prone to.
Let's do a mental experiment. Imagine two repositories of models. In one repository, classes were created for storing models of swimming facilities, in the other - classes for storing models of automobiles. Suppose that there is an object that in one storage is described as an object of the class of a floating craft, and in the second - as an object of a class of an automobile. Suppose that the task is to merge these repositories into one. How do you do this?
Perhaps you will create a subclass of cars, which is also a subclass of the class of boats, add the model to the subclass you created and delete, now become superfluous, the model from the class of cars and the model from the class of boats. Perhaps you will remove an object from the watercraft class, and you will simultaneously make an object from the car class an object of the watercraft class.
Whatever you do, I have a question: how do you call the simulated object now? Watercraft? And, if then there will be other classes to which this object belongs? Will you list their names with a hyphen, and say: car-craft-alpha-omega? If you ask the analyst this question, the answer will be: this is the same object, which is both a car and a watercraft. Literally, this means that there is an object of accounting, which can be simultaneously classified both as a car and as a watercraft. From this it follows that we are not modeling vehicles and boats, but accounting objects!
')
Since these two different operations are usually performed simultaneously, they are not distinguished. Because of this, there is a feeling that we are modeling cars and boats, although in fact - objects of accounting. This confusion contributes to our language.
Compare statements:
The second statement is correct, but too long to use in practice.
OOP inherits the result of this confusion, and it is impossible to separate the operation to create an object model from classification. Therefore, analysts often think that the modeling of the subject area lies in the modeling of machines and boats, and not objects of accounting.
In this sense, the OWL standard is more correct, because in it you can create an unclassified model of the accounting object. This allows you to separate the operation for modeling the accounting object from the operation for its classification.
When we say that the car is red, we assume that the car may have the property of being black, red, and so on. But can machines really have properties?
Let's continue our mental experiment. Let the two storages, which we considered earlier, have attributes of the same name: cars have a color attribute, and boats have a color attribute. Let there be an object that we described as a red car in one storage, and as a red watercraft in another. Let again the task of combining these repositories into one. What do you do?
Previously, you created a subclass of cars and boats for modeling an object. Now the task of modeling one color instead of two. To solve this problem, you can do it in different ways.
Perhaps you will create one superclass for the car class and the watercraft class for which you will create the color attribute. In classes of vehicles and boats, you will create color attributes inherited from the superclass. Then redo all the objects to fit the new vision.
Perhaps you define the interface "color" and run the implementation of this interface in each class.
Whatever you do, it is important to understand that the resulting attribute "color" will not belong to any vehicles or boats. This is something that exists outside of these classes. And this is correct, because the attribute is not associated with the type. An attribute is a way of dividing a set of objects into subsets in a different way than the type. I wrote about this earlier in the article Concepts: set, type, attribute.
.
Therefore, to be strict, it is impossible to talk about a property belonging to an object, we must talk about a property regardless of the type, or an object, for example, like this:
The accounting object is classified as a red object, that is, classified.
Although I am making these kinds of allegations are correct, in fact it’s too costly to speak in this way. The reason is in the language. When we transfer information to another subject, we seek to reduce the amount of work being done. Compare statements:
When did you do less work? Of course, in the first. But the trouble with this statement is that it suggests that the attribute belongs to a type, and the value of the attribute belongs to a classified object.
OOP has inherited this delusion. Using OOP, it is impossible to create an attribute separately from the class (although interfaces can be used for this). And again OWL to help us: in this standard, types and attributes exist separately from each other. Therefore, when we merge two models in OWL, we will not have to do as much work as we would have done in the PLO. To merge, you only need to declare two attributes identically equal and nothing more.
Suppose there are two repositories of models. In one repository are stored models of operations for the sale of tools. In another repository stored model operations for the purchase of tools. Let there be one operation classified in one store as a sale transaction, which Martynov was the executor of, and in another store it was also classified as a purchase transaction, the executor of which was Gavrilov. In the process of combining two repositories, the task is to combine these models into one. Question: how to present a model of this operation in the joint storage?
Soon comes the decision to create a new model that will simulate an operation called “sale and purchase”, which will be performed by Martynov and Gavrilov. But then the question arises: where did the sale of operations, whose executor was Martynov, go to, and where did the operation of purchase, of which Gavrilov went to? In the new model, this information was lost, and there was also a collision, because an operation is an action that should have a goal. The sale has a goal - to sell at a higher price, and Martynov worked for it. The purchase has a goal - to buy cheaper, and Gavrilov worked for it. And the sale has no purpose, because it has no stakeholder. How to save the information that was in the repositories prior to their merger, to avoid collisions and, at the same time, to combine operation models?
To do this, we need to do the same as we did with cars. It is necessary to create a model of the accounting object and relate it to two different classes at the same time: to the class of operations for sale and to the class of operations for purchase. In different classes there will be one attribute “performer”, the values ​​of which will depend on which class we are considering: the class of purchases, or the class of sales. And this is unexpected - it turns out that the values ​​of attributes of a single accounting object may depend on how we classified the accounting object.
It seems strange, but there is nothing surprising. Different people can classify the same object in different ways. Someone thinks that this is a machine, and someone thinks that this is a watercraft. For some, this is a sale transaction, and for someone it is a purchase transaction. Now the meaning of classification is clarified. The classification of the accounting object is an expression of a certain point of view on the accounting object. There are no cars, but there is an object of accounting and a subject that treats this object of accounting as a car. There is no sale transaction; there is a subject that treats the accounting object as a sale transaction.
Attribute values ​​have the same meaning. There is an accounting object and a subject that treats this accounting object as belonging to a certain class of attribute values.
Therefore, theses about the car and the craft should be clarified:
To say something about the object of accounting without reference to the subject who conducted the description of this object does not make sense. It seems obvious, but for some reason analysts forget about it.
How the OWL can be used to build a repository, which will take into account various points of view, is described in the article: Multi-viewpoint Ontologies for Decision-Making Support .
Domain modeling is the modeling of accounting objects by classifying them. Classification is always subjective and therefore requires an indication of the subject who conducted the classification.
Accounting object and the result of its classification (nouns)
Let's do a mental experiment. Imagine two repositories of models. In one repository, classes were created for storing models of swimming facilities, in the other - classes for storing models of automobiles. Suppose that there is an object that in one storage is described as an object of the class of a floating craft, and in the second - as an object of a class of an automobile. Suppose that the task is to merge these repositories into one. How do you do this?
Perhaps you will create a subclass of cars, which is also a subclass of the class of boats, add the model to the subclass you created and delete, now become superfluous, the model from the class of cars and the model from the class of boats. Perhaps you will remove an object from the watercraft class, and you will simultaneously make an object from the car class an object of the watercraft class.
Whatever you do, I have a question: how do you call the simulated object now? Watercraft? And, if then there will be other classes to which this object belongs? Will you list their names with a hyphen, and say: car-craft-alpha-omega? If you ask the analyst this question, the answer will be: this is the same object, which is both a car and a watercraft. Literally, this means that there is an object of accounting, which can be simultaneously classified both as a car and as a watercraft. From this it follows that we are not modeling vehicles and boats, but accounting objects!
')
- Creating an object in the repository is modeling the accounting object
- Placing the created object in a class is its classification.
Since these two different operations are usually performed simultaneously, they are not distinguished. Because of this, there is a feeling that we are modeling cars and boats, although in fact - objects of accounting. This confusion contributes to our language.
Compare statements:
- This is a tree
- This is an accounting object classified as a tree.
The second statement is correct, but too long to use in practice.
OOP inherits the result of this confusion, and it is impossible to separate the operation to create an object model from classification. Therefore, analysts often think that the modeling of the subject area lies in the modeling of machines and boats, and not objects of accounting.
In this sense, the OWL standard is more correct, because in it you can create an unclassified model of the accounting object. This allows you to separate the operation for modeling the accounting object from the operation for its classification.
Accounting object and the result of its classification (adjectives)
When we say that the car is red, we assume that the car may have the property of being black, red, and so on. But can machines really have properties?
Let's continue our mental experiment. Let the two storages, which we considered earlier, have attributes of the same name: cars have a color attribute, and boats have a color attribute. Let there be an object that we described as a red car in one storage, and as a red watercraft in another. Let again the task of combining these repositories into one. What do you do?
Previously, you created a subclass of cars and boats for modeling an object. Now the task of modeling one color instead of two. To solve this problem, you can do it in different ways.
Perhaps you will create one superclass for the car class and the watercraft class for which you will create the color attribute. In classes of vehicles and boats, you will create color attributes inherited from the superclass. Then redo all the objects to fit the new vision.
Perhaps you define the interface "color" and run the implementation of this interface in each class.
Whatever you do, it is important to understand that the resulting attribute "color" will not belong to any vehicles or boats. This is something that exists outside of these classes. And this is correct, because the attribute is not associated with the type. An attribute is a way of dividing a set of objects into subsets in a different way than the type. I wrote about this earlier in the article Concepts: set, type, attribute.
.
Therefore, to be strict, it is impossible to talk about a property belonging to an object, we must talk about a property regardless of the type, or an object, for example, like this:
The accounting object is classified as a red object, that is, classified.
Although I am making these kinds of allegations are correct, in fact it’s too costly to speak in this way. The reason is in the language. When we transfer information to another subject, we seek to reduce the amount of work being done. Compare statements:
- Red car
- Accounting object belongs to the class of cars and to the class of red objects
When did you do less work? Of course, in the first. But the trouble with this statement is that it suggests that the attribute belongs to a type, and the value of the attribute belongs to a classified object.
OOP has inherited this delusion. Using OOP, it is impossible to create an attribute separately from the class (although interfaces can be used for this). And again OWL to help us: in this standard, types and attributes exist separately from each other. Therefore, when we merge two models in OWL, we will not have to do as much work as we would have done in the PLO. To merge, you only need to declare two attributes identically equal and nothing more.
The meaning of the classification process
Suppose there are two repositories of models. In one repository are stored models of operations for the sale of tools. In another repository stored model operations for the purchase of tools. Let there be one operation classified in one store as a sale transaction, which Martynov was the executor of, and in another store it was also classified as a purchase transaction, the executor of which was Gavrilov. In the process of combining two repositories, the task is to combine these models into one. Question: how to present a model of this operation in the joint storage?
Soon comes the decision to create a new model that will simulate an operation called “sale and purchase”, which will be performed by Martynov and Gavrilov. But then the question arises: where did the sale of operations, whose executor was Martynov, go to, and where did the operation of purchase, of which Gavrilov went to? In the new model, this information was lost, and there was also a collision, because an operation is an action that should have a goal. The sale has a goal - to sell at a higher price, and Martynov worked for it. The purchase has a goal - to buy cheaper, and Gavrilov worked for it. And the sale has no purpose, because it has no stakeholder. How to save the information that was in the repositories prior to their merger, to avoid collisions and, at the same time, to combine operation models?
To do this, we need to do the same as we did with cars. It is necessary to create a model of the accounting object and relate it to two different classes at the same time: to the class of operations for sale and to the class of operations for purchase. In different classes there will be one attribute “performer”, the values ​​of which will depend on which class we are considering: the class of purchases, or the class of sales. And this is unexpected - it turns out that the values ​​of attributes of a single accounting object may depend on how we classified the accounting object.
It seems strange, but there is nothing surprising. Different people can classify the same object in different ways. Someone thinks that this is a machine, and someone thinks that this is a watercraft. For some, this is a sale transaction, and for someone it is a purchase transaction. Now the meaning of classification is clarified. The classification of the accounting object is an expression of a certain point of view on the accounting object. There are no cars, but there is an object of accounting and a subject that treats this object of accounting as a car. There is no sale transaction; there is a subject that treats the accounting object as a sale transaction.
Attribute values ​​have the same meaning. There is an accounting object and a subject that treats this accounting object as belonging to a certain class of attribute values.
Therefore, theses about the car and the craft should be clarified:
- The object of accounting from the point of view of Ivanov is classified as a watercraft.
- From the point of view of Sidorov, the same accounting object is classified as a watercraft.
- From the point of view of Ivanov and Sidorov, the same object is classified as a red object.
To say something about the object of accounting without reference to the subject who conducted the description of this object does not make sense. It seems obvious, but for some reason analysts forget about it.
How the OWL can be used to build a repository, which will take into account various points of view, is described in the article: Multi-viewpoint Ontologies for Decision-Making Support .
findings
Domain modeling is the modeling of accounting objects by classifying them. Classification is always subjective and therefore requires an indication of the subject who conducted the classification.
Source: https://habr.com/ru/post/332064/
All Articles