Subject-event approach to modeling complex systems
Alexander Boldachev, 2015
Traditional thinking, which is characteristic of the world as a multitude of spatially localized objects-things, is traditional for modern man, both in everyday life, in science, and in philosophy. The things themselves are determined through a set of predicates. The relationship of objects is described through relationships and classifications, which is formally recorded in the form of tables and graphs. Modern methods of describing / modeling complex systems adhere to a real ontology: first, decomposition is the selection of objects, then their classification with attributing properties to objects and establishing relations between them (“part-whole”, “gender-type”, “depends”, etc. )
However, in philosophy, in addition to the traditional proprietary ontology, there is another, although not so widespread, approach to describing the world — event-driven. Event view at the level of logical, language systems adhered to Ludwig Wittgenstein. At the beginning of his famous Logical and Philosophical Treatise, he stated: "The world is a totality of facts, not objects. ... What is happening, a fact is the existence of co-existence." Extremely radical event-based approach, at the level of the foundations of ontology, was first proposed by Bertrand Russell, stating: “the world consists of a certain number, perhaps finite, possibly infinite, entities ... Each of these entities can be called an“ event ”.” Yes, we can describe, say, a biological organism as a spatial structure of molecules. But, on the other hand, it can also be presented as a system of events of chemical interactions of these molecules, distributed over a certain period of time. At the same time, it is clear that the event description will give us a more complete understanding of the organism compared to purely structural analysis. Moving further into the depth of things, it is possible to describe molecules not as “balls on sticks”, but as a set of events of interaction of atoms - it’s clear that the structure, the spatial position of the elements of the molecule are secondary to the events of electronic exchanges. Well, the atoms themselves should be described as a system of event-interaction of particles. In the end, Russell, analyzing the ideas of quantum theory on the structure of matter, comes to the conclusion: "matter is just convenient ways of grouping events." And to the legitimate question of “the events of what? events happening with what? ”replies:“ events that just happen, and not happen “with” matter or “with” something else ”.
To understand the essence of the event ontology, a computer analogy can help us. What is the "world" of the computer at the elementary (processor) level? A continuous stream of simple events: 0100100100010010010 ... And nothing more. But at another level - the interface level - some sequences of this stream look like quite a thing: interface elements, letters, characters of the game. Each “thing” shown to us on the screen corresponds to a certain, not necessarily continuous, sequence of the flow of processor events (ones and zeros). And what do we do when we want to change these things? Correctly, we add new events to the initial stream. So, we only have events: event systems and event change event systems, from which new things can be formed at the interface level. Let us fix it in particular: there are no things at the level of the elementary stream — they arise only when templates are attached to this stream. Which, by the way, are themselves the structures of events of the same stream distributed in time, since there is nothing else in the world of the computer.
From this philosophical introduction, we must take a simple thought: our world can be viewed both as a multitude of things and as a stream of events, while things are determined through the sets of these events.
')
Of course, when we address the applied problems of describing a complex system, say, a large modern enterprise, we should not be concerned about the deep (at the level of events of interaction of elementary particles) event ontology of each bolt. First of all, we should be interested in the participation of the bolt in the functioning of the system, that is, the events: “delivered to the warehouse”, “brought to the place of assembly”, “screwed”. And not just the fact of participation, but its substantial content, with a description of those properties that were essential for each event. For example, for the realization of the event “brought to the place of assembly” the weight of the bolt is important - do you need a trolley or can you bring it to the box of bolts in your pocket. The “screw” event is feasible if the bolt thread corresponds to the part thread. And it turns out, if we fix all the events in which the bolt participated, then we get a full description of it. And not an abstract, but a concrete and comprehensive description of how the bolt “looks” for a particular system, what properties, at what moments and how it participates in the functioning of the system. If there is no event in which the bolt color would be recorded, it means that in the description of the bolt (for this system) there will be no such property as “color”. Thus, using the proposed event approach, that is, fixing all the events in which appeared, measured, moved, applied, changed, etc. objects, we get a complete description of these objects in the analyzed system.
At first glance, it may seem that we are talking only about a certain kind of accounting form, a way to optimize the recording of the parameters of objects. However, let us consider what lies behind the seemingly simple phrase “fixing an event”. Take, for example, the event "screwed the bolt." Here it is important to pay attention to the fact that not only the bolt (A) participates in this event, but also such objects as the connected parts (B and C) and the subject (S), which implements this event. (Here it is necessary to clarify that this is not about an act, not about a procedure, not about an action, but about the event “screwed the bolt”, that is, about fixing the fact of achieving the result.) That is, our event should be called “ Subject S connected bolts A with parts B and C. ” This means that the recording of each system event contains not only information about the objects involved, but also data about their relationships (objects A, B and C from the moment of the specified event form the whole D) and plus a description of the subject (S produced object D).
So, fixing all the events implemented in a certain complex system should give us an exhaustive (within the framework of this system) description of each object, each subject and their relationship. In fact, the received event stream contains complete information about the system.
It is clear that to analyze the functioning of a complex system, say, the same enterprise, there is no need to fix each event at the level of technological processes. For example, the bolt tightening by a specific subject in the event flow must be represented by two events: “getting A, B and C”, “passing detail D”, and not the events of each turn of the key. You can specify the following formal conditions, the fulfillment of which determines the necessity and sufficiency of including some event in the event flow:
From the above conditions it follows that the event is determined by specifying the object (s) with which it occurs, and the subject who performed or registered it. The subject can be a specific person, role, team, as well as software agents, sensors, etc. Events that affect the behavior of the system, but not connected with any of its subjects should be attributed to the absolute subject. Just because any event in the system is such only under the condition of its connection with a specific subject, the described approach is called not just event-based, but subject-event-driven .
The most important and interesting point of the subject-event approach is the principle of unification of the description: all subjects and all objects included in the enterprise are exhaustively described as sets of events . If we select from the event flow of the system all the events implemented by a certain subject, including filling in each item of the questionnaire when it arrives for work, then we get a full description of the subject. And, similarly, if we collect all the events generated by all the subjects with respect to a certain object (property registration events, changes in properties, inclusion in other objects), then we get an exhaustive description of the object - exactly as an object in a particular complex system. To maintain the homogeneity of the description of the object (as a set of events), the initial attribution of properties to it also needs to be recorded as an event related to the past, say, at the time the object was included in the system (supply of materials, equipment, new order, etc.). Such events are attributed to the absolute subject. That is, in the event approach, any statement about any object is made out as a statement about an event, fixed or initiated by a specific subject.
What has been said about objects in the framework of the event-based approach can also be formulated in terms of data: any data in the subject-event approach is generated by events and recorded as events . The data can either be input to the system (incoming resources, order conditions) or generated in the system (modification of resources) - in any case, they are described as predicate attribution events to an object performed by a particular subject.
So, in the subject-event approach, the main and only element of the description of systems is the event: an enterprise is represented as a stream of events performed by subjects on objects, and the subjects and objects themselves are fixed in the system as sets of related events, most of which occur during the operation of an enterprise , and the part is fixed at the time of inclusion of objects and subjects in the system.
The proposed principle of fixation of subjects and objects (as sets of events) eliminates the absolutization of their description inherent in the real approach. Each object is included in the actions of the subject with that set of parameters that are distinguishable in this action (it is clear that the object "bolt" for the worker, engineer and accountant has different descriptions, and for the director does not exist). Similarly, relations between the subjects are fixed only to the extent that their event sets intersect: the subjects are connected with one object, are included in one action.
It is clear that the change in the state of objects is of a relative, subject character. If a subject did not distinguish a change event (or this change is not significant for him, for example, for a designer, correcting a grammatical error in the text of a booklet is not an event), then for him the object did not change state.
An event-based approach removes the problem of unambiguous classification of objects: resources, artifacts, documents, products, etc. Since all objects distinguished by subjects are thought of as sets of events, there is no need to absolutely fix their types: depending on the level and role of the subject, from the total set of events related with some object, different subsets can be allocated, which will be recorded as different types - for example, as a product, a document or even garbage (for a cleaner).
The noted relative principle in the definition of objects and subjects is important both for the unification and minimization of the description, and for the optimization of relations between the subjects and objects. And most importantly, it allows producing and analyzing a lot of essentially non-concurring, however, coordinated at the lower level (at the level of the event flow) system descriptions made from the perspective of various subjects.
At the initial stage of system modeling, registration of the event flow is possible through both the compilation of lists of all events related to each subject and the analysis of changes in objects. Ultimately, the arrays of events detected by the indicated registration methods should coincide. And their discrepancy should be taken as an indication of the presence of problems in the organization of the system: meaningless events that have no consequences, or events that are not strictly fixed for a specific subject.
With a sufficient level of enterprise informational equipment, events can be recorded automatically by parsing the activities of the subjects.
(Continued in the next publication .)
Property (object) ontology
Traditional thinking, which is characteristic of the world as a multitude of spatially localized objects-things, is traditional for modern man, both in everyday life, in science, and in philosophy. The things themselves are determined through a set of predicates. The relationship of objects is described through relationships and classifications, which is formally recorded in the form of tables and graphs. Modern methods of describing / modeling complex systems adhere to a real ontology: first, decomposition is the selection of objects, then their classification with attributing properties to objects and establishing relations between them (“part-whole”, “gender-type”, “depends”, etc. )
Event ontology
However, in philosophy, in addition to the traditional proprietary ontology, there is another, although not so widespread, approach to describing the world — event-driven. Event view at the level of logical, language systems adhered to Ludwig Wittgenstein. At the beginning of his famous Logical and Philosophical Treatise, he stated: "The world is a totality of facts, not objects. ... What is happening, a fact is the existence of co-existence." Extremely radical event-based approach, at the level of the foundations of ontology, was first proposed by Bertrand Russell, stating: “the world consists of a certain number, perhaps finite, possibly infinite, entities ... Each of these entities can be called an“ event ”.” Yes, we can describe, say, a biological organism as a spatial structure of molecules. But, on the other hand, it can also be presented as a system of events of chemical interactions of these molecules, distributed over a certain period of time. At the same time, it is clear that the event description will give us a more complete understanding of the organism compared to purely structural analysis. Moving further into the depth of things, it is possible to describe molecules not as “balls on sticks”, but as a set of events of interaction of atoms - it’s clear that the structure, the spatial position of the elements of the molecule are secondary to the events of electronic exchanges. Well, the atoms themselves should be described as a system of event-interaction of particles. In the end, Russell, analyzing the ideas of quantum theory on the structure of matter, comes to the conclusion: "matter is just convenient ways of grouping events." And to the legitimate question of “the events of what? events happening with what? ”replies:“ events that just happen, and not happen “with” matter or “with” something else ”.
Computer analogy
To understand the essence of the event ontology, a computer analogy can help us. What is the "world" of the computer at the elementary (processor) level? A continuous stream of simple events: 0100100100010010010 ... And nothing more. But at another level - the interface level - some sequences of this stream look like quite a thing: interface elements, letters, characters of the game. Each “thing” shown to us on the screen corresponds to a certain, not necessarily continuous, sequence of the flow of processor events (ones and zeros). And what do we do when we want to change these things? Correctly, we add new events to the initial stream. So, we only have events: event systems and event change event systems, from which new things can be formed at the interface level. Let us fix it in particular: there are no things at the level of the elementary stream — they arise only when templates are attached to this stream. Which, by the way, are themselves the structures of events of the same stream distributed in time, since there is nothing else in the world of the computer.
From this philosophical introduction, we must take a simple thought: our world can be viewed both as a multitude of things and as a stream of events, while things are determined through the sets of these events.
')
Event description of complex systems
Of course, when we address the applied problems of describing a complex system, say, a large modern enterprise, we should not be concerned about the deep (at the level of events of interaction of elementary particles) event ontology of each bolt. First of all, we should be interested in the participation of the bolt in the functioning of the system, that is, the events: “delivered to the warehouse”, “brought to the place of assembly”, “screwed”. And not just the fact of participation, but its substantial content, with a description of those properties that were essential for each event. For example, for the realization of the event “brought to the place of assembly” the weight of the bolt is important - do you need a trolley or can you bring it to the box of bolts in your pocket. The “screw” event is feasible if the bolt thread corresponds to the part thread. And it turns out, if we fix all the events in which the bolt participated, then we get a full description of it. And not an abstract, but a concrete and comprehensive description of how the bolt “looks” for a particular system, what properties, at what moments and how it participates in the functioning of the system. If there is no event in which the bolt color would be recorded, it means that in the description of the bolt (for this system) there will be no such property as “color”. Thus, using the proposed event approach, that is, fixing all the events in which appeared, measured, moved, applied, changed, etc. objects, we get a complete description of these objects in the analyzed system.
At first glance, it may seem that we are talking only about a certain kind of accounting form, a way to optimize the recording of the parameters of objects. However, let us consider what lies behind the seemingly simple phrase “fixing an event”. Take, for example, the event "screwed the bolt." Here it is important to pay attention to the fact that not only the bolt (A) participates in this event, but also such objects as the connected parts (B and C) and the subject (S), which implements this event. (Here it is necessary to clarify that this is not about an act, not about a procedure, not about an action, but about the event “screwed the bolt”, that is, about fixing the fact of achieving the result.) That is, our event should be called “ Subject S connected bolts A with parts B and C. ” This means that the recording of each system event contains not only information about the objects involved, but also data about their relationships (objects A, B and C from the moment of the specified event form the whole D) and plus a description of the subject (S produced object D).
So, fixing all the events implemented in a certain complex system should give us an exhaustive (within the framework of this system) description of each object, each subject and their relationship. In fact, the received event stream contains complete information about the system.
Principle of event selection
It is clear that to analyze the functioning of a complex system, say, the same enterprise, there is no need to fix each event at the level of technological processes. For example, the bolt tightening by a specific subject in the event flow must be represented by two events: “getting A, B and C”, “passing detail D”, and not the events of each turn of the key. You can specify the following formal conditions, the fulfillment of which determines the necessity and sufficiency of including some event in the event flow:
- the event is executed or registered by one of the subjects of the system;
- an event is executed on one of the system objects;
- the fact of the presence (or absence) of an event is a condition for the event to be carried out by another subject or by the same subject, but with a different object.
From the above conditions it follows that the event is determined by specifying the object (s) with which it occurs, and the subject who performed or registered it. The subject can be a specific person, role, team, as well as software agents, sensors, etc. Events that affect the behavior of the system, but not connected with any of its subjects should be attributed to the absolute subject. Just because any event in the system is such only under the condition of its connection with a specific subject, the described approach is called not just event-based, but subject-event-driven .
Principle of unification
The most important and interesting point of the subject-event approach is the principle of unification of the description: all subjects and all objects included in the enterprise are exhaustively described as sets of events . If we select from the event flow of the system all the events implemented by a certain subject, including filling in each item of the questionnaire when it arrives for work, then we get a full description of the subject. And, similarly, if we collect all the events generated by all the subjects with respect to a certain object (property registration events, changes in properties, inclusion in other objects), then we get an exhaustive description of the object - exactly as an object in a particular complex system. To maintain the homogeneity of the description of the object (as a set of events), the initial attribution of properties to it also needs to be recorded as an event related to the past, say, at the time the object was included in the system (supply of materials, equipment, new order, etc.). Such events are attributed to the absolute subject. That is, in the event approach, any statement about any object is made out as a statement about an event, fixed or initiated by a specific subject.
What has been said about objects in the framework of the event-based approach can also be formulated in terms of data: any data in the subject-event approach is generated by events and recorded as events . The data can either be input to the system (incoming resources, order conditions) or generated in the system (modification of resources) - in any case, they are described as predicate attribution events to an object performed by a particular subject.
So, in the subject-event approach, the main and only element of the description of systems is the event: an enterprise is represented as a stream of events performed by subjects on objects, and the subjects and objects themselves are fixed in the system as sets of related events, most of which occur during the operation of an enterprise , and the part is fixed at the time of inclusion of objects and subjects in the system.
Principle of relativity
The proposed principle of fixation of subjects and objects (as sets of events) eliminates the absolutization of their description inherent in the real approach. Each object is included in the actions of the subject with that set of parameters that are distinguishable in this action (it is clear that the object "bolt" for the worker, engineer and accountant has different descriptions, and for the director does not exist). Similarly, relations between the subjects are fixed only to the extent that their event sets intersect: the subjects are connected with one object, are included in one action.
It is clear that the change in the state of objects is of a relative, subject character. If a subject did not distinguish a change event (or this change is not significant for him, for example, for a designer, correcting a grammatical error in the text of a booklet is not an event), then for him the object did not change state.
An event-based approach removes the problem of unambiguous classification of objects: resources, artifacts, documents, products, etc. Since all objects distinguished by subjects are thought of as sets of events, there is no need to absolutely fix their types: depending on the level and role of the subject, from the total set of events related with some object, different subsets can be allocated, which will be recorded as different types - for example, as a product, a document or even garbage (for a cleaner).
The noted relative principle in the definition of objects and subjects is important both for the unification and minimization of the description, and for the optimization of relations between the subjects and objects. And most importantly, it allows producing and analyzing a lot of essentially non-concurring, however, coordinated at the lower level (at the level of the event flow) system descriptions made from the perspective of various subjects.
Event stream registration
At the initial stage of system modeling, registration of the event flow is possible through both the compilation of lists of all events related to each subject and the analysis of changes in objects. Ultimately, the arrays of events detected by the indicated registration methods should coincide. And their discrepancy should be taken as an indication of the presence of problems in the organization of the system: meaningless events that have no consequences, or events that are not strictly fixed for a specific subject.
With a sufficient level of enterprise informational equipment, events can be recorded automatically by parsing the activities of the subjects.
(Continued in the next publication .)
Literature
- Wittgenstein L. The Logical and Philosophical Treatise // Wittgenstein L. Philosophical Works / Trans. with him. M. S. Kozlova. - M .: Gnosis, 1994. - Part 1.
- A. Boldachev. Temporality and the philosophy of absolute relativism - Moscow: Lenand, 2011.
- Boldachev A. Introduction to temporal ontology . Who today makes philosophy in Russia. Volume III / Author compiler A. S. Nilogov. - M .: Sam Polygraphist LLC, 2015
- Russell, B. History of Western Philosophy: in 2 t. –M .: MYTH, 1993
Source: https://habr.com/ru/post/256509/
All Articles