If you said that the stool has 4 legs, then you made a simple statement. If you said that any stool has 4 legs, this statement is not simple. This statement is made in the predicate logic, in which it is possible to talk about the general properties of objects of one set.
The first mistake is due to the fact that analysts do not know how to separate these statements. Suppose that the analyst drew a diagram in BPMN notation: two small boxes connected with each other by an arrow. He called the first square “to fix the workpiece in the machine”, he called the second square: “to cut a part”. At the same time, the analyst said: after the operation “fix the workpiece in the machine”, the operation “turn the part” should follow. What did he mean? He meant that after an operation like “fix the workpiece in the machine”, an operation like “turn the part” should follow. That is, he constructed a statement in first-order predicates. However, the analyst confuses simple statements with statements in the predicate logic and thinks he has made a simple statement.
The consequence of the first misconception: in the IT industry appeared a crutch covering this error. This crutch is a copy word. When you hear the word "instance of something" from the analyst's mouth, you know, he is confusing simple statements with statements in the logic of predicates.
For the vast majority of cases with which the analyst works, a class is a common mathematical set. Sets are built by man for different purposes. One of them is the unification of objects according to common features. For example, all those who are fed milk are called mammals. The sign, or a set of these signs, with the help of which the objects are classified, is called a type. Then a class of objects, united by one set of features, is associated with a type (feature set). Some sets do not have a common feature and are set by listing their elements. An analyst who does not distinguish between class and type often confuses words: instance and element. From such an analyst you can often hear: "an instance of a class", with the help of which he tries to indicate an object - an element of this set. He confuses two theses: "instance of type" and "element of set". An instance of an elephant type is an elephant (they often write: an instance of an elephant, skipping the word type). An instance of a class type is a class (skipping the word type, we get: an instance of a class). But analysts confusing types and classes may say an instance of a class, but in this case it is not the class that is meant, but its element. This error is aggravated by the consonance of the words “instance” and “element” and OOP, in which the type of objects is called a class.
Often the analyst thinks that the attribute is what belongs to the type of objects. For example, by creating a table "trees" that simulates the type of objects "trees", he creates an attribute "height" and considers that this attribute belongs to this type. This is suggested by its relational database structure, in which the concept "type" is associated with a table, and the concept "attribute" is associated with the name of a column in this table. But in the subject area, the term "attribute" has a completely different meaning. If a type is a set of attributes that allow selecting from a set of objects those that satisfy these characteristics, then an attribute is a set of such sets. A type was created in order to select a subset of a set of objects, an attribute — to divide a set of objects into non-intersecting subsets with their values. If we draw an analogy, then the type corresponds to the value of the attribute. At the same time, the attribute is in no way associated with the type. An attribute is a separate way of classifying objects that is not associated with a type. However, objects of the same type can be divided into groups according to attribute values. And then the idea that most analysts have is born: the attribute belongs to the type. True, the height of the trees - is it the same attribute as the height and buildings? In a relational model, these are different attributes; in OWL, they are one.
I recommend watching lectures about attributes
Native language does not help us in any way to build domain models. For example, when I say that a car is white, an object appears in the analyst’s mind with a sticker stuck to it, where the name of the property is written: white. However, as we found out, neither the attribute nor its value has anything to do with the type. The attribute value is one of the ways to classify a four-dimensional space-time volume on a par with a type. The type classifies the selected four-dimensional space-time volume as a machine, the attribute value classifies this volume as white. Combining two points of view, we find that, on the one hand, the chosen volume can be classified as a machine, on the other hand - as white. But white is not a property of the machine, as the machine is not a property of white. A car with a sticker on board is an image that makes us think that one of the classification methods is more significant than the other. This leads to collisions with which all analysts are familiar: we begin to refine the model, and what previously seemed to be an attribute value, now we need to make a separate class, what was previously modeled by a field in the table, now we need to separate it into a separate table. Everyone faced this, but no one understands the reason. And the reason is that the analyst still uses ideas about the sticker glued to the object. To overcome the habit of thinking in this way, I used the following technique: I learned to sculpt a car sticker on the white property. Try it, it's fun.
Often, the belonging of two objects to the same type is taken by analysts for their identity. It seems that this is impossible, but I constantly encounter such a collision. For example, if an analyst is shown two similar bicycles, he will not hesitate to say that these are two different objects, but if he is shown two similar operations, he will no longer be so quick with the answer and most likely will say that everything depends on the point of view . If the analyst shows two similar properties, for example, two white ones, then the analyst will not hesitate for a second and say that these are identical properties.
Identical for objects, properties, and operations are the attributes that unite them, but not the objects, properties, or operations themselves. The analyst must learn to understand the difference between the type of objects, properties and operations and objects, properties and operations of these types. Then he will be able to do the following requests: show me the information about all operations like "pack the part into the container", performed from 18-00 to 19-00 in this workshop. But for some reason the analyst calls the type of operation an operation, and the operations of a given type call it an instance of the operation, and therefore, in the request, instead of information about operations of one type, he asks for information about unknown beasts: some instances of the operation.
If you can somehow cope with the copies of the operation (in the sense you can close your eyes to the non-Russian language used by the analyst when he says “a copy of this operation”), then the number will not work with the properties. If the identification of the operation in the business analysis is associated with the word "instance", then the identification of the property is impossible in principle! For a long time I tried to understand the reason for this, and the only clue I received in psychology. It turns out that primitive man, distinguishing objects, did not distinguish between actions and properties. For him, yesterday's hunting trip was identical to that of today. That is, physically identical, because in the mind of a primitive man, time flowed cyclically, not linearly, as it is now.
It is clear that the process of creating a function for assessing the properties of one type, through which the concept of an attribute and its values ​​is born, also remains beyond the knowledge of the analyst. A pity, because it starts to confuse a property with the value of an attribute that classifies this property.
Activity implies the existence of a rational actor, goal, instrument of activity, object of activity, act of activity, result of activity. All this set as a copy is copied from our language, in which there is a subject, predicate, addition. We no longer animate the Sun or the car, but use the language in which for every change in the world the actor responsible for this change must be found. For example, if we are talking about the glow, then there must be someone who shines, for example, the Sun, if he goes, then the car is responsible for driving. But there is another method for modeling change. This method is associated with the concept of activity. Activity is a description of changes in the physical world in which there is no actor.
For example, the statement “the car travels from 18-00 to 19-00” is perceived by the analyst as an object making a movement. At the same time, the analyst thinks that the machine is actually doing something, to the extent that it makes efforts to move! Such a picture is imposed by language. However, from the point of view of describing the activity, there is a road, a car, an observer, the atmosphere and other participants in the movement. In this paradigm, the car does not travel, it participates in the movement along with other road users.
To describe the activity, we have another copy in our language: impersonal sentences. Unfortunately, this copy is not fully developed. Therefore, the native language in modeling the activity is not our assistant. If, while modeling an activity, we are looking for the performers of the roles of the actor, instrument, object of activity and result, then by modeling the activity, we forget about the roles, and only the participants of the activity remain. Modeling activities, we say: in order to buy products, you have to go to the store by car. Modeling activity, we say: the purchase of products consists of a trip to the grocery store. Modeling of activity allows us to understand the physics of what is happening, replacing the subjective cause-and-effect relationships with objective "part-whole" and "preceding-should." This language involves the description of facts without their subjective interpretation.
Along with the understanding of what activity is, comes the understanding of the physical meaning of such concepts as operation and function. These are space-time volumes, interpreted by us as operations, or as functions. In the theory of activity there is no concept of space-time scope, therefore, being within the framework of this paradigm, it is impossible to understand the physical meaning of operations or functions. If, in an activity model, an operation or function falls into a set of sub-operations or sub-functions, then this means that one space-time volume has split into several (usually intersecting). In the theory of activity, such decomposition is modeled in the mind of the analyst by cause-and-effect relationships, about which one can argue infinitely, because they are subjective and unprovable.
From the point of view of modeling activity, there is a fact: the road, the car, the atmosphere, the observer, who tells us that the car is driving along the road. The motion function is a space-time volume that includes all of the above. In terms of activity, the machine is part of the motion function along with its other parts.
So let's summarize.
The physical meaning of an object for the analyst is a piece of space that he can touch, or see.
The physical meaning of the property for the analyst is a sticker with the name of the property glued to the object.
The physical meaning of the operation for the analyst is a film in which someone does something.
If there is a property, but there is no object (light), then why make a sticker? Then the sticker can be stuck on the space as a whole and say that the property is an interpretation of the space made by the observer.
If there is an operation, but no actor (supernova explosion), then who does it? The analyst says: let's divide the operations into those that have an actor (business operations) and those that do not have it (natural operations). The analyst believes that there is something in the universe that is different from natural operations. Further, it establishes the rule that in any business transaction there must be an actor, even if it is an inanimate object, such as an information system, or a printer. Thus, having gotten out of one collision, the analyst creates another: an inanimate actor. In addition, it is not clear whom to appoint an actor, when there are more than one applicants for his place. The solution to this problem is. It is to abandon the search for actors, and, instead of modeling activities, do modeling activities. And in the activity model, let everyone decide for himself who the actor is and who is not.
It turns out that the object, property, operation - all these are different interpretations of the space-time volumes made by the observer. This thesis was the basis for the modeling paradigm proposed by Chris Partridge and Matthew West, on the basis of which the ISO 15926 continuous cycle enterprise modeling standard was created.
I suggested a model for interpreting the four-dimensional space-time volume in my work .
To understand it at one time is impossible, they say that understanding comes from the fourth reading. In theory, after understanding this article, there should come an understanding of the inseparability of space and time, as well as the ability to represent them together.
Source: https://habr.com/ru/post/420795/
All Articles