BPMN: Modeling Physical Events
I often hear the thesis that there are terms: an event and an instance of this event, or a variable and an instance of this variable. Dear analysts, I kindly request those who use these terms, read the end of the article and think about what is written there. Perhaps you will understand that you can’t say that.
In this article, I continue the story about the physical and functional events. This time I will connect physical events with those objects that model them in information systems. In this article, the story goes about physical and physical events only:
')
First, let us recall what a physical and functional event in the subject area is .
An event is an extent plus a subjective point of view on it.
As a result, we have the following hierarchy of objects:
A physical event is often used to describe the change of states of a physical object. For example: the physical event “the descent vehicle at 10-00 entered the dense layers of the atmosphere” describes the beginning of that state of the device when it is inhibited. Functional events are often used to describe the change of state of a functional object. For example: the event “Extinguishing the fire is complete” from the example with the lighthouse describes the onset of the functional state of the lighthouse “Fire of the fire”. However, binding to a change of states is by no means obligatory. For example, a physical event 12-00 does not mark a change in the state of an object.
As a rule, the customer sets the task for the analyst in terms of a functional event. Based on the data obtained, the analyst formulates the requirements for the physical event. Remember the phrase we often hear? "In fact, the customer needs this ... And then a description of the physical event occurs." Then this physical event is executed, the parameters of this event are verified with the planned parameters and returned to the interpretation of the physical event as a functional one. For example, we see some kind of event (fireworks), but we are not interested in how the universes were created and destroyed. We are interested only in the appearance of fireworks.
Physical events form a set or class of physical events. Those who wish to recall mathematics can suggest what the power of many physical events is equal to. Further, from the entire set of physical events, one can choose the subset that the analyst is interested in. For example, a five-second time interval, followed by a beep, somewhere between 11 hours and 45 minutes and 12 hours and 15 minutes on March 12, 2014, from the point of view of the customer, can be considered a physical event “12 hours on March 12, 2014”. Many such events that take place on different days form a class of physical events, which can be called “12 o'clock”.
Thus, in the description of the domain, a new object appeared - a class of physical events.
In the BPMN notation, there is no symbol for the class of physical events. There is only a symbol for class events, an example of which (symbols) I gave at the beginning of the article. For the future I will leave a little intrigue. There is an activity description notation in which there is a graphic element for designating a class of functional events, but no notation for events of this class.
Let it be the task of developing the Sirius-12 software and hardware complex to emit a sound signal with a duration of 5 seconds at any time in the interval between 11-45 and 12-15. These events are considered by the customer as physical events of the “12-00” class. I deliberately stretched the time scale, because it may seem to many that we always determine 12-00 with absolute accuracy. But in fact, there is always an error in both measuring time and giving a signal about measured time. Let's take a close look at what classes of events are considered by the analyst when developing an information system.
And here is a very important point on which I would like to draw your attention. Actual events may be from the class of desired events, but they may not be 12-00 events in the view of the customer! Because, for example, two alarms on the same day can be considered false positives. That is, there are two ways to harm the customer: some signal from the class of actual events will not meet the requirements of the customer (triggered at 18-00) or the class of actual events will not match any of the desired sequences (double triggered signal). That is, customer requirements apply to both class events and event class. Let me remind you that in BPMN there is no possibility to impose requirements on the class of events.
Let's look at the implementation of the information system of the complex. The database of the complex creates tables , the entries of which model that :
It is clear that not every information system stores the data that I cited as an example. However, individually or collectively, they have the right to exist.
In passing, we note that the standard deviation from a given value is a class parameter, while the distribution of a random variable is a parameter of class objects.
If we have all the tables filled, then we can analyze the statistical data, apply the method called 6 sigma. And, if it turns out that the average duration of the signals is not 5 seconds, but 6, you can try to understand the causes of the discrepancy and eliminate them. Note that the 6 sigma method is designed to study not only processes, but also to study any parameters of any functional or physical object.
In our case, we gave a very precise and unambiguous definition of the concept 12-00 as applied to the modeled subject area. However, very often we see the following symbol on the diagrams:
But we do not see the definition of what 12-00 is in the area that the analyst modeled. The fact is that a priori, this definition is considered known. For example, 12-00 is defined as the system time, the measurement accuracy is 1 msk and the error of the signal supply is determined by the length of the electrical lines leading to the actuator and / or the synchronization accuracy of the clock frequencies of the executive and calculating devices. All this is not missed by us just because it seems insignificant. But in fact, at the most inappropriate moment, this error can play a cruel joke on us if we do not take it into account. For example, a transaction will be completed with an error just because we decided that it is instant. Therefore, when you see this element in the diagram, it is better to check with the analyst what he means by the events “12-00”.
I will briefly repeat the results obtained by us in the previous article . For a correct reasoning, we need to distinguish the following objects:
In the figure I have cited those entities that we will have to consider when applied to the model of physical events:
Let's see how this image is specified in our case. I must emphasize that the BPMN notation works only with the desired events and does not work with actual events. More precisely, it can work with anticipated actual events. The same events that actually occur are generally impossible to fit into the model. For example, an event when a beep was mistakenly buzzed at 6:00 pm is an actual event, but you cannot call it a 12:00 event. Another limitation of the notation is that the notation does not allow modeling the classes of desired events, but only the desired class events. Therefore, the remaining objects and classes of objects, if necessary, the analyst will have to be modeled manually.
First, a model of the desired events appears in the head of the customer. We know little about how this thing arises, and where it is stored. But we know that it is this model that becomes the basis for the further work of the analyst. The analyst's task is to understand the paradigm in which the customer argues, to understand how the model of desired events looks in this paradigm, to take its broader and consistent paradigm as its basis, to map the customer’s ideas along with its paradigm to its paradigm, to create a model of desired events in its paradigm. At the same time, the customer model is complemented and the internal contradictions are eliminated. Then, the analyst must otmappit this model back into the customer's paradigm and verify the data obtained. If the customer agrees with the corrected model of desired events, then you can either teach him your paradigm, which will save power on transfers from one paradigm to another and back, or you will have to go back and forth every time. This will create difficulties and risks of translation, but knowing these risks will help us cope with them. In our case, I use a paradigm that assumes that events are physical and functional, and all of them are extents of 4-D spacetime. To simulate the desired events, I use the BPMN notation.
Having approved the object model, you can proceed to the coordination of the object class model. For example, we agreed on a definition of what any 12-00 event is. This is the only beep sent for 5 seconds in the period from 11-45 to 12-15 any day. Now we need to understand what is the class of such events. The class of such events will be the set of all such signals. However, now we have new requirements. For example, you can specify the standard deviation from the nominal. Let it be the standard deviation of 7 minutes relative to 12-00. I hope you understand that this parameter belongs to the class of desired events, and not to the desired class events. (The same parameters can be discussed with the customer after the fact regarding the events that actually occurred). Unfortunately, there is no element in BPMN notation to indicate the class of desired events. Therefore, all that concerns the class of desired events, we have to model ourselves outside of the BPMN notation. The same applies to actual events and the class of actual events.
Consider the model presentation of any desired event 12-00 on the monitor screen. It will look like this:
Note that a lot of monitors and each of you will have its own image. Someone more, someone less, someone in some colors, someone in others. This is the set of various representations of the model of the desired events 12-00. That is why there are many representations of one model - each of you has his own.
When I created on my screen the first presentation of the model of desired events, the program simultaneously did another work. She created and saved the model representation of this and other views as a file with the XPDL extension. This file was created based on our understanding of the model as an information object. At the same time, the same BPMN notation was used to create the file. The point is that there are two parts to the notation. One describes what data describes the model (set of graphic primitives (event symbol), created objects and their parameters (objects of the Event class)), and the other describes the type of storage of this data (how to write in the XPDL file).
A representation of the BPMN notation can be found on my bookshelf. You can have it represented by pixels on the monitor.
So, to create a view of the 12-00 event model, I used the BPMN notation that was in my head. I took the notation of the desired events from the notation and, on the basis of this symbol, created the representation of the model of the desired events 12-00 on my screen. At the same time, I had created a model of representations of this model as a file with the XPDL extension.
We see that the number of entities that participate in the simulation of a simple event exceeds all expectations. But the way it is. Remember how much you had to work just to write the first word!
The task of the notation developers is to ensure that for the analyst the gap between the design of the object and its implementation is minimal. This desire is justified, and the developers did their best. However, at the same time, we received costs: there were deformations in the minds of analysts:
I will dwell on the last strain today. I often hear the thesis that there are terms: the event and a copy of this event.
For example, in the diagram:
analysts see the event. And the event 12-00 on January 1, 2015, they call a copy of this event!
I do not know how to explain to such analysts that they, to put it mildly, show their illiteracy. I understand where this deformation came from, but for some reason it is so strong that, even by showing it clearly, one cannot be sure that the analyst will understand his error. Therefore, I will try to dwell on this in detail.
So, let us have a definition of the term electron, and let there be a definition of the term electron instance. What do you think these two terms indicate? That's right: on any object of the class "electrons". In addition to these terms, there are terms "class of electrons" and "type of electrons". If we are talking about the types of particles, the electron instance is an electron particle instance (but not an electron instance). Perhaps this is an instance of this type of electrons. Similarly, an event instance is an instance of an event type object , but not an instance of this event. It may be an instance of this type of event. An instance of an elk - there is an instance of an animal of the elk type , but not an instance of this elk. Perhaps this is an instance of this type of moose. Please remember this! If you really want to use the term event instance instead of the term event, then remember that the BPMN chart element in this case models any instance of the event. So, the chart element models any event from the event class, or any event instance from the event instance class. No other way.
Another parasitic term that has penetrated our ranks is the term “instance of a class”. Do not forget that the term "class instance" refers to a class, and not to an object of this class. The object is indicated by the term “class element” consonant with it.
In the following articles, we will look at the modeling of functional events in BPMN notation.
In this article, I continue the story about the physical and functional events. This time I will connect physical events with those objects that model them in information systems. In this article, the story goes about physical and physical events only:
')
Event definition
First, let us recall what a physical and functional event in the subject area is .
An event is an extent plus a subjective point of view on it.
- An extent is any 4-D area from 4-D space-time. The fact is that our space is four-dimensional. Just one of the dimensions we experience in a specific way - as something that unfolds before us in one direction. But for modeling such a feature of our perception does not matter.
- It is believed that the extent, which we consider to be an event, from the point of view of the narrator has a zero temporary width. That is, from the point of view of the narrator, an event is a moment. However, there is always a point of view in which the width of the event can no longer be neglected and we will need to consider the temporal width of this extent.
- The event has a physical meaning - these are facts and nothing but facts. We consider such an event as a set of facts without their interpretations. For example, in the example with the lighthouse there is an event that the caretaker sits on the level and rests. Such an event we will call a physical event.
- In addition to the physical event, there are many interpretations of this physical event by different subjects. For example, when describing a beacon, the same physical event “Ranger Resting” can be described as: “Ignition is completed” and “Quenching started”. Such an event we will call a functional event.
As a result, we have the following hierarchy of objects:
A physical event is often used to describe the change of states of a physical object. For example: the physical event “the descent vehicle at 10-00 entered the dense layers of the atmosphere” describes the beginning of that state of the device when it is inhibited. Functional events are often used to describe the change of state of a functional object. For example: the event “Extinguishing the fire is complete” from the example with the lighthouse describes the onset of the functional state of the lighthouse “Fire of the fire”. However, binding to a change of states is by no means obligatory. For example, a physical event 12-00 does not mark a change in the state of an object.
Using a physical event in system design
As a rule, the customer sets the task for the analyst in terms of a functional event. Based on the data obtained, the analyst formulates the requirements for the physical event. Remember the phrase we often hear? "In fact, the customer needs this ... And then a description of the physical event occurs." Then this physical event is executed, the parameters of this event are verified with the planned parameters and returned to the interpretation of the physical event as a functional one. For example, we see some kind of event (fireworks), but we are not interested in how the universes were created and destroyed. We are interested only in the appearance of fireworks.
Defining a class of physical events
Physical events form a set or class of physical events. Those who wish to recall mathematics can suggest what the power of many physical events is equal to. Further, from the entire set of physical events, one can choose the subset that the analyst is interested in. For example, a five-second time interval, followed by a beep, somewhere between 11 hours and 45 minutes and 12 hours and 15 minutes on March 12, 2014, from the point of view of the customer, can be considered a physical event “12 hours on March 12, 2014”. Many such events that take place on different days form a class of physical events, which can be called “12 o'clock”.
Thus, in the description of the domain, a new object appeared - a class of physical events.
In the BPMN notation, there is no symbol for the class of physical events. There is only a symbol for class events, an example of which (symbols) I gave at the beginning of the article. For the future I will leave a little intrigue. There is an activity description notation in which there is a graphic element for designating a class of functional events, but no notation for events of this class.
Task setting for the development of software and hardware
Let it be the task of developing the Sirius-12 software and hardware complex to emit a sound signal with a duration of 5 seconds at any time in the interval between 11-45 and 12-15. These events are considered by the customer as physical events of the “12-00” class. I deliberately stretched the time scale, because it may seem to many that we always determine 12-00 with absolute accuracy. But in fact, there is always an error in both measuring time and giving a signal about measured time. Let's take a close look at what classes of events are considered by the analyst when developing an information system.
- The class of possible events is “12-00 specific day”. This is an ordered class of possible sound signals that are only possible on this particular day. Any event from this class can be considered an event 12-00, however, if and only if it is the only one in the sample. If we assume that there were two beeps in one day, then the customer has the right to consider one or both of them to be false.
- The events of all classes of possible events “12-00 of a specific day” (for different days) form the class of possible events “12-00”.
- We can choose from this class of possible events “12-00” any ordered sequence of events such that every day there will be one and only one desired event. Any sequence of desired events thus obtained will be desirable from the point of view of the customer. Let's call such a sequence of possible events - the desired sequence of events.
- The class of desired sequences of desired events.
- The class of actual events. This class consists of actual events when the beep was heard. It is clear that this class may not coincide with any of the desired sequences of events. The goal of the business analyst and developer of the complex is to ensure that the class of actual events matches one of the desired sequence of events.
And here is a very important point on which I would like to draw your attention. Actual events may be from the class of desired events, but they may not be 12-00 events in the view of the customer! Because, for example, two alarms on the same day can be considered false positives. That is, there are two ways to harm the customer: some signal from the class of actual events will not meet the requirements of the customer (triggered at 18-00) or the class of actual events will not match any of the desired sequences (double triggered signal). That is, customer requirements apply to both class events and event class. Let me remind you that in BPMN there is no possibility to impose requirements on the class of events.
The data structure of the software and hardware complex
Let's look at the implementation of the information system of the complex. The database of the complex creates tables , the entries of which model that :
- Classes of desired events . There, one entry 12-00 is created, which models the class of desired events using the parameter “tolerance from 12-00”. This is the minimum and maximum deviation from 12-00, sufficient for the event to be considered an event 12-00. Let the deviation be set at 15 minutes. The requirements for the standard deviation from 12-00 are also indicated. The required duration of the signal and permissible deviations from it are indicated.
- Desired events . An entry in this table models the desired event by specifying the date and time when the alarm should be given.
- Actual events . The entry in this table models the event actually performed (signaling) by specifying the actual signaling time and the actual signal duration.
- Classes of actual events . The entry in this table models the class of actual events by specifying the minimum and maximum actual deviations from 12-00, the actual standard deviation from 12-00, the average time of the signal and the standard deviation from the average duration.
Last normal form
It must be remembered that modeling the subject area with the help of tables very rarely preserves the correspondence between the objects of the subject area and the entries in the tables. More often in one record data at once about a set of objects of the subject area is stored. A data structure that fully satisfies the rule — one record stores data for one object, sometimes called the complete or last normal form. This structure arises if we consider the subject area from the point of view of the logical paradigm, which I have been talking about for many articles in a row, and not from the point of view of instances and types.
Comments to the data structure
It is clear that not every information system stores the data that I cited as an example. However, individually or collectively, they have the right to exist.
In passing, we note that the standard deviation from a given value is a class parameter, while the distribution of a random variable is a parameter of class objects.
If we have all the tables filled, then we can analyze the statistical data, apply the method called 6 sigma. And, if it turns out that the average duration of the signals is not 5 seconds, but 6, you can try to understand the causes of the discrepancy and eliminate them. Note that the 6 sigma method is designed to study not only processes, but also to study any parameters of any functional or physical object.
Comments on the definition of the term event 12-00
In our case, we gave a very precise and unambiguous definition of the concept 12-00 as applied to the modeled subject area. However, very often we see the following symbol on the diagrams:
But we do not see the definition of what 12-00 is in the area that the analyst modeled. The fact is that a priori, this definition is considered known. For example, 12-00 is defined as the system time, the measurement accuracy is 1 msk and the error of the signal supply is determined by the length of the electrical lines leading to the actuator and / or the synchronization accuracy of the clock frequencies of the executive and calculating devices. All this is not missed by us just because it seems insignificant. But in fact, at the most inappropriate moment, this error can play a cruel joke on us if we do not take it into account. For example, a transaction will be completed with an error just because we decided that it is instant. Therefore, when you see this element in the diagram, it is better to check with the analyst what he means by the events “12-00”.
Modeling the activity of the software and hardware complex
General remarks
I will briefly repeat the results obtained by us in the previous article . For a correct reasoning, we need to distinguish the following objects:
- The model of the object (class of objects) in the head of the subject,
- Representation of this model as an information object,
- The class of representations of this model as a class of information objects
- Model of representations of these information objects in the subject’s head
- Representation of this model as an information object
- The class of representations of this model as an information object.
- Notation
In the figure I have cited those entities that we will have to consider when applied to the model of physical events:
Let's see how this image is specified in our case. I must emphasize that the BPMN notation works only with the desired events and does not work with actual events. More precisely, it can work with anticipated actual events. The same events that actually occur are generally impossible to fit into the model. For example, an event when a beep was mistakenly buzzed at 6:00 pm is an actual event, but you cannot call it a 12:00 event. Another limitation of the notation is that the notation does not allow modeling the classes of desired events, but only the desired class events. Therefore, the remaining objects and classes of objects, if necessary, the analyst will have to be modeled manually.
Creating an activity model
First, a model of the desired events appears in the head of the customer. We know little about how this thing arises, and where it is stored. But we know that it is this model that becomes the basis for the further work of the analyst. The analyst's task is to understand the paradigm in which the customer argues, to understand how the model of desired events looks in this paradigm, to take its broader and consistent paradigm as its basis, to map the customer’s ideas along with its paradigm to its paradigm, to create a model of desired events in its paradigm. At the same time, the customer model is complemented and the internal contradictions are eliminated. Then, the analyst must otmappit this model back into the customer's paradigm and verify the data obtained. If the customer agrees with the corrected model of desired events, then you can either teach him your paradigm, which will save power on transfers from one paradigm to another and back, or you will have to go back and forth every time. This will create difficulties and risks of translation, but knowing these risks will help us cope with them. In our case, I use a paradigm that assumes that events are physical and functional, and all of them are extents of 4-D spacetime. To simulate the desired events, I use the BPMN notation.
Having approved the object model, you can proceed to the coordination of the object class model. For example, we agreed on a definition of what any 12-00 event is. This is the only beep sent for 5 seconds in the period from 11-45 to 12-15 any day. Now we need to understand what is the class of such events. The class of such events will be the set of all such signals. However, now we have new requirements. For example, you can specify the standard deviation from the nominal. Let it be the standard deviation of 7 minutes relative to 12-00. I hope you understand that this parameter belongs to the class of desired events, and not to the desired class events. (The same parameters can be discussed with the customer after the fact regarding the events that actually occurred). Unfortunately, there is no element in BPMN notation to indicate the class of desired events. Therefore, all that concerns the class of desired events, we have to model ourselves outside of the BPMN notation. The same applies to actual events and the class of actual events.
Consider the model presentation of any desired event 12-00 on the monitor screen. It will look like this:
Note that a lot of monitors and each of you will have its own image. Someone more, someone less, someone in some colors, someone in others. This is the set of various representations of the model of the desired events 12-00. That is why there are many representations of one model - each of you has his own.
When I created on my screen the first presentation of the model of desired events, the program simultaneously did another work. She created and saved the model representation of this and other views as a file with the XPDL extension. This file was created based on our understanding of the model as an information object. At the same time, the same BPMN notation was used to create the file. The point is that there are two parts to the notation. One describes what data describes the model (set of graphic primitives (event symbol), created objects and their parameters (objects of the Event class)), and the other describes the type of storage of this data (how to write in the XPDL file).
A representation of the BPMN notation can be found on my bookshelf. You can have it represented by pixels on the monitor.
So, to create a view of the 12-00 event model, I used the BPMN notation that was in my head. I took the notation of the desired events from the notation and, on the basis of this symbol, created the representation of the model of the desired events 12-00 on my screen. At the same time, I had created a model of representations of this model as a file with the XPDL extension.
We see that the number of entities that participate in the simulation of a simple event exceeds all expectations. But the way it is. Remember how much you had to work just to write the first word!
Business Intelligence Formations
The task of the notation developers is to ensure that for the analyst the gap between the design of the object and its implementation is minimal. This desire is justified, and the developers did their best. However, at the same time, we received costs: there were deformations in the minds of analysts:
- Analysts are no longer aware of all the steps in the process of identifying requirements for the designed system and have ceased to notice the many entities that are involved in this process.
- Analysts sometimes do not separate the objects of information systems and objects of the real world. They begin to think that contracts are stored in information systems, and not in accounting racks. Or vice versa, they consider that the event is information.
- Analysts have stopped noticing the difference between the class of desired events and the class of actual events.
- Analysts no longer distinguish between objects of the real world and the classes of these objects.
I will dwell on the last strain today. I often hear the thesis that there are terms: the event and a copy of this event.
For example, in the diagram:
analysts see the event. And the event 12-00 on January 1, 2015, they call a copy of this event!
I do not know how to explain to such analysts that they, to put it mildly, show their illiteracy. I understand where this deformation came from, but for some reason it is so strong that, even by showing it clearly, one cannot be sure that the analyst will understand his error. Therefore, I will try to dwell on this in detail.
So, let us have a definition of the term electron, and let there be a definition of the term electron instance. What do you think these two terms indicate? That's right: on any object of the class "electrons". In addition to these terms, there are terms "class of electrons" and "type of electrons". If we are talking about the types of particles, the electron instance is an electron particle instance (but not an electron instance). Perhaps this is an instance of this type of electrons. Similarly, an event instance is an instance of an event type object , but not an instance of this event. It may be an instance of this type of event. An instance of an elk - there is an instance of an animal of the elk type , but not an instance of this elk. Perhaps this is an instance of this type of moose. Please remember this! If you really want to use the term event instance instead of the term event, then remember that the BPMN chart element in this case models any instance of the event. So, the chart element models any event from the event class, or any event instance from the event instance class. No other way.
Another parasitic term that has penetrated our ranks is the term “instance of a class”. Do not forget that the term "class instance" refers to a class, and not to an object of this class. The object is indicated by the term “class element” consonant with it.
To be continued
In the following articles, we will look at the modeling of functional events in BPMN notation.
Source: https://habr.com/ru/post/247457/
All Articles