Business function modeling

Introduction

Three projections of one object on three different planes are not an object. This is his drawing. All three projections allow the engineer to present the part. For this it is necessary to correlate the points on the drawing with points in space. This skill contributes to learning descriptive geometry.

Exactly the same can be said about projection modeling . Only both projections on space and at the time allow us to present what the designer wanted to say. To do this, you need to learn how to correctly model 4-D space-time, and then correctly correlate these projections with each other. In this article I will give a practical example of this kind of modeling. For some, it will be quite unusual. Someone, on the contrary, will seem all too obvious.

Forest composition modeling

Let's start with modeling the object we are used to - let's try to model a forest. There is a 4-D volume, which Ivanov treats as an object of the forest type. To simulate this fact, an information object is created that simulates this 4-D volume. Next, an IO is created that models Ivanov’s representation of this 4-D volume. This object is associated with the 4-D volume model with a “what is” relationship, with Ivanov’s “who represents” model and with an object type model — the forest “as it represents”.
')


What would you do if I asked you to model the composition of the forest? You might suggest modeling each tree in this forest. Then I have a question for you: is the description more detailed than the first, and less detailed than the second?

This description is. It can be heard when children are told what forest is. They are told that the forest consists of trees. Let's try to describe it formally. Let us know that a particular forest consists of 30 percent of aspen and 70 percent of birch. To simulate this fact, we need: two IOs modeling the types of trees: birch and aspen (in the OOP they are classes), one IO modeling the 4-D volume representation in the form of a heap by Ivanov, and one IO modeling the heap composition. Next, let us associate the IO, the modeling compound, with the type of birch connection “consists of 70 percent” and with the type of aspen connection “consists 30 percent” (this cannot be done in the PLO).



We saw the forest as a pile of trees, but we could consider a pile of elements like forest — from parts of the forest that are also forest — a pile.



This modeling method is easier to understand using the example of solid modeling. Those who have gone through solid state physics remember that in order to model sound waves, one has to disassemble matter into matter.

The forest example may still seem strained, but models of this kind arise when the roll-call inventory turns into a group one. For example, if production takes into account each unit of goods (boxes), and the consumer keeps records of lots of boxes. Or, if there are a lot of consumers, they all represent nodes of a distribution network and each keeps records in batches of different volumes. If we want to make a system that could track the entire life cycle of a box from the moment of its creation to the moment of disposal, then we need to be able to simulate such batches.

In my articles, I have repeatedly told about the need for modeling this kind of cases through the modeling of sets and showed the impossibility of doing this with the help of standard modeling notations, or with the help of modern programming languages. I do not know why this happened, but I know for sure that this was a brake on the development of the science of modeling. I talk about what opportunities would open up to us, if we had a tool of this kind and invite interested persons to create such a tool.

Function modeling

An impressive example that demonstrates the possibility of modeling sets to us is the modeling of functions (not in the mathematical sense of the word, but in the sense of describing the functioning).

With functions, a rather curious situation arose when the impossibility of modeling sets led to the impossibility of correctly formulating the definition of a function. And since there is no definition of a function, analysts can neither imagine nor model it at all!

With the help of projection modeling, the task of defining and modeling a function is solved in the same way as forest modeling.

Let there is an enterprise for the production of locomotives. Assume that this interpretation of the 4-D volume was made by Ivanov. The company can be felt, seen, heard and localized in space.

Ivanov, can make a different interpretation of the same 4-D volume. He can interpret it as a function for the production of locomotives (one point of view does not contradict the other). For those who read me for the first time, I will say that this function, like the enterprise, can be touched, seen, heard and localized in space. If I ask you to describe this function, then you will most likely find it difficult to do so. Those who try to do this will most likely make the following mistakes:

1. Instead of describing a function, try to describe the construction of this function. For example, they would say that the function for the production of locomotives consists of the production of locomotives and the sale of locomotives.
2. Instead of describing the function, they will try to describe the construction in which this function is included: the production of locomotives is included in the production of spare parts for locomotives and the consumption of locomotives. Such an error occurs when they say that a function is a transformation.
3. Instead of describing a function, it will be stated that the function is an abstraction and cannot be touched or described.
4. The closest will be those who try to simulate the threads entering and exiting the function. This view of the function was imposed by the IDEF0 standard, and since then the appropriateness of this kind of description has not been questioned. However, it causes a certain kind of collision, which I repeatedly wrote about earlier.

A function is a heap, not just objects, but events (operations), functions, or elementary constructions of these elements.

Assume that Ivanov decided to describe the function for the production of locomotives. For this he can do in three ways.

First way

Ivanov can distinguish the class of events (operations) "release of the engine." Then the function for the production of locomotives can be represented as a class of events "release of the engine." The function is then modeled by the event class. These events can be seen on the diagram in IDEF0 notation in the form of an arrow coming out of the square.

Second way

Ivanov can distinguish the class of functions "release locomotives." From the first case, the difference is that in the subfunctions there are many releases of steam locomotives (how many are unknown). The function is then modeled by the class of functions. To support this kind of simulation, there is no tool yet, although this is how it is possible to simulate continuous functions such as motor shaft rotation.

Third way

Ivanov can distinguish a chain of events (operations): the purchase of spare parts, the production of a locomotive and the shipment of a locomotive. The function in this case will be described as a class of elementary structures - scenarios. This way of describing a function is implemented in software products for modeling the activities of an enterprise in the form of a “decomposition” of a function modeled in IDEF0 notation into a typical scenario modeled in IDEF3, EPC or BPMN notation.

All three methods of modeling correspond to the representation of a 4-D object in the form of a heap: events, functions, and chains of events.

Function Modeling Standards

Now, after I told you what a function is and how it is modeled, you can answer the question of what is the relationship between a function in IDEF0 notation and its “decomposition” in IDEF3, EPC or BPMN notation. This connection is implemented in software products for modeling the activities of enterprises: AllFusion ERwin Data Modeler and Business studio . This relationship is this: 4-D volume, modeled as a function of a heap of operations corresponding to the flows in IDEF0 notation, can be represented as a function in the form of a heap of similar scenarios described in IDEF3, EPC or BPMN notation.

Difficulties in understanding the text

When I give my text to people who are far from programming, they understand it quite easily, and often wonder: why write such obvious things? When programmers read this text, they do not understand anything. I formulated the difficulties that can become obstacles to understanding my articles:

1. It is difficult to learn the discipline of thinking, when the properties of the object and the properties of the structure are separated, and not mixed in one bottle.
2. It is difficult to understand that a function, like an object, is a different understanding of 4-D space, and that a function, like an object, can be felt.
3. It is difficult to understand why flow modeling is not correct. It is necessary to understand that it is possible to build event classes from streams, but on the contrary - it is not always possible to build streams from event classes.
4. It is necessary to overcome the stereotype of thinking, which says that the company is functioning. The model tells us that there are two points of view on the 4-D volume. On the one is an object, on the other - a function.
5. It is difficult to teach yourself to think in terms of the subject area, and not in terms of OOP. In the subject area there are operations and types of operations, and in OOP there are instances of operations and operations. When I say an operation, I mean the one that happened yesterday at 8-00. If I need to say about the type of operations, then I say so - the type of operations. In the PLO everything is mixed up. There, when it is necessary to say about the operation, they say: a copy of the operation, and when it is necessary to say about the type, they say - an operation.

In the next article I will talk about modeling events. This topic may also seem difficult to someone, but obvious to someone.