Object-Oriented Mammoth Hunt (Clerk Notes)
Object-oriented hunt for a mammoth (note by the clerk).
When writing an article, no mammoth was hurt.
“Mammoth Hunt” is one of the first abstractions created by the ancestors on the wall in the cave.
Admiring the masterpiece, the visionary leader probably thought about how to increase the effectiveness of the hunt. I myself thought, because there were no business analysts. If there were any attempts to optimize the hunt, we would now feed carrots on mammoths at the zoo, and the phrase “Russia is the birthplace of elephants” was not in doubt.
')
How would a business analyst describe a hunt for a mammoth if his wise ancestors hadn’t eaten him in time?
A phrase from two nouns, but describes the process, i.e. action (just like “format c:”).
A business analyst would look at the wall, talk to the main hunter, and ...:
There is input data (live mammoth), there is a business procedure with spears and arrows, there is a dead mammoth.
Now we will entrust the clerk with the same description:
1. There is a mammoth mining plan.
2. Based on the plan, a document “Application for hunting” is created.
3. The leader gives instructions.
4. Create a group "Search".
5. A group of "Hunters" is created.
6. Event "Processing".
7. Write to the archive.
The clerk is better. Why? Because the business analyst is bad.
Scold, remove the premium, we get:
Hunting, this is when the mammoth was killed, because before that they were tracked down, because the leader said so, and then they ate and then buried it, but in the plan it was.
Better, but still bad. Praise, give a bonus, we get:
Based on the “Plan” process, we create the associated “Mammoth” process.
The process may have status
"Under consideration of the leader / Search / Hunting / Use / Disposal."
Status is changed by business procedures.
"Send / Find / Kill / Eat / Bury."
Why did the clerk get it right away, but did the business analyst have a hard time?
Because the first builds a model based on objects, and the second based on processes.
Because the first one thinks with nouns, and the second one with verbs.
A process is an action, which means it is a verb (linguists are startled), and it is difficult to describe the model using verbs as the basis. It is simpler and clearer to use nouns as a basis, i.e. objects. The clerk does not have the function “Search”, he has an object of the class “Search”, in which the search methods are hidden.
Compare 2 famous phrases:
"Night, street, lantern, pharmacy"
and
“I came, I saw, I won”
The first with the help of 4 nouns convincingly enough transfers the objective reality to the area of abstract models of our consciousness and even adds emotional coloring.
If we design the system, then the framework of the model is ready, and the night is described as a separate object that affects the state of other objects.
The phrase of the three verbs is difficult, but can also be a description of the model. If you instruct the business analyst to describe himself, he will create a model: "He came, he saw, he described." I saw the actions of a specialist, connected the squares with arrows, transferred the object from state A to state B, and the business process began. Where he went, why he went from the model does not follow. Where necessary, go there and go.
We, clerks, have a regulation (set of rules) and instruction (sequence of actions). The regulation describes the life cycle of objects and the rules that provide this life cycle. The instruction describes which buttons to press in which sequence.
The rules have an object-oriented nature as opposed to a procedure-oriented instruction.
I consider the very principle of building a model based on business processes as vicious. It is like building a model based on a user’s manual, without reading the regulations. Moreover, I do not criticize the method, but the way of thinking (this is not forgiven), when the model is based on a process that changes its state, and there are no objects at all, or they are as properties of the process.
Recently, one professional in the construction of systems with full confidence stated to me that an account is not a document.
In our mercantile age it is difficult to imagine a person who would not hold a bill in his hands. How deeply should process-oriented thinking sit in the brain so that the basis for payment with a number, date, and signatures should not be considered a document, but should be considered one of the reporting forms of the process. And he does not just think, he designs the system in such a way and teaches others. Horror.
The example with a mammoth is somehow difficult and not convincing. Consider something more understandable, for example, the invasion of a bug (bug tracking, English - translated as I could).
You can consider each stage of the application as a change in the state of the process. There is a process that under the influence of business procedures acquires new properties and changes its status.
Each stage can be considered an object associated with other objects as either a host-slave relationship (owner-slave, English for solidity), or a ground-linked relationship.
It all starts with the application.
Business analyst: Application is a process.
Clerk: The application is a document.
User: I do not care, just to be fulfilled.
DP: The application may have a basis document: for example, an incoming letter signed by the executor with the resolution “Please expel the bug and give the answer to the applicant”. This means that the answer to the applicant will refer to it.
B-A: so what? This is our process.
DP: The process was created on the basis of the document, this is normal, but it’s strange to put the process in the answer as the basis.
B-A: nothing strange: incoming is a process, application is a process and an outgoing process too. They generate each other and are related to each other.
User: Inbound is a document. The boss said so. And the process is when he waved and shouted at them.
B-A: you don't understand. The incoming scan and attach, the status of the process is changing, the boss must impose a resolution ...
DP: resolution is also a document.
B-A: did you understand what you said?
The application is considered by the project manager and lists the performers.
DP: The resolution is quite a complex object: it contains text, names, timelines, urgency, etc. In addition, there may be several resolutions, and each will have its own life cycle. And I call it a document, because after saving it should become immutable. Do you remember the management of entries in ISO-9001? The document is considered to be unchangeable, not because it cannot be corrected (the term can be postponed), but because any normalization should be excluded from it. It should be immutable not at the level of the user interface, but at the database level, i.e. to be self-sufficient. The paperwork condemns the normalization: the head can change the position, the executor is the last name - everything in the document should remain as it was. Document is normalization-free zone (English for persuasiveness).
B-A: immutability means that when the value changes, the old value is transferred to history, and history cannot be changed.
User: immutability, this is when I poke, but it does not poke.
DP: resolution can be sent by e-mail. For the document is quite familiar.
B-A: the application has an associated “Resolution” entity. Sent no worse.
User: One has a related entity, another has a subordinate document. What do I need?
The performer begins work on the beetle.
Business analyst: Work is a process. Anyone ask.
User: You are right.
Clerk: it is not the work that is recorded in the database, but the work report (start, content, completion percentage) - and this is a document.
User: And you are right. All your differences in terms. What does it matter what word to call.
DP: For the ancients, the thought and word were denoted in the same way: Logos. Remember the documentation from Ivan: "At first there was a thought ...". This means that if the model is described crookedly, then the system will be a curve. And our models differ at the level of understanding (conceptual incompatibility). For me, “Work (Task)” is a document in the journal “Works”. It may be associated with the application (the journal "Applications"), or it may be with the service department (the journal Sluzhebki), or it may be proactive and not connected with anything at all.
The organization management system is a set of interrelated journals that form a single whole. Journal documents can be copied to other journals and begin a new life there, without losing their properties, but acquiring new properties in a new life.
There is a forest biocenosis, there is a bookcase. If you cut the mushroom in the forest and put it in the closet, it should not become a book about the mushroom.
A model of the world (no matter whether large or small) can only be implemented in a document-oriented database.
B-A: What is such a doko-bd-mongo-db? The base must be relational and normalized three times. Look around: most of the systems in the world are created by us.
DP: Look at these systems. Does it surprise you that after your optimization the staff increases, that according to American statistics, paperless technologies increase paper consumption by 40%?
User: I even have paperless objects, even paperless processes. Until the printer is taken away, I will still print everything.
BP: I heard what he said! So I won.
DP: Won, and calm down.
B-A: No, I won't calm down, no, I won't calm down, no, I won't calm down ... (D.Harms)
- Dear! Life is motion. It cannot be described in a declarative language.
- Life is the interaction of objects. Until scientists discovered microbes, the treatment was ineffective. The imperative part of the model should be secondary.
- A user is an object model?
- Of course. Properties are set by the administrator, the methods are specified in the instructions.
- Is the user difficult to debug?
- Not. It is much harder to debug a programmer. But the main trouble is a business analyst: it is not debugging.
- Goodbye.
- Happily.
When writing an article, no mammoth was hurt.
“Mammoth Hunt” is one of the first abstractions created by the ancestors on the wall in the cave.
Admiring the masterpiece, the visionary leader probably thought about how to increase the effectiveness of the hunt. I myself thought, because there were no business analysts. If there were any attempts to optimize the hunt, we would now feed carrots on mammoths at the zoo, and the phrase “Russia is the birthplace of elephants” was not in doubt.
')
How would a business analyst describe a hunt for a mammoth if his wise ancestors hadn’t eaten him in time?
A phrase from two nouns, but describes the process, i.e. action (just like “format c:”).
A business analyst would look at the wall, talk to the main hunter, and ...:
There is input data (live mammoth), there is a business procedure with spears and arrows, there is a dead mammoth.
Now we will entrust the clerk with the same description:
1. There is a mammoth mining plan.
2. Based on the plan, a document “Application for hunting” is created.
3. The leader gives instructions.
4. Create a group "Search".
5. A group of "Hunters" is created.
6. Event "Processing".
7. Write to the archive.
The clerk is better. Why? Because the business analyst is bad.
Scold, remove the premium, we get:
Hunting, this is when the mammoth was killed, because before that they were tracked down, because the leader said so, and then they ate and then buried it, but in the plan it was.
Better, but still bad. Praise, give a bonus, we get:
Based on the “Plan” process, we create the associated “Mammoth” process.
The process may have status
"Under consideration of the leader / Search / Hunting / Use / Disposal."
Status is changed by business procedures.
"Send / Find / Kill / Eat / Bury."
Why did the clerk get it right away, but did the business analyst have a hard time?
Because the first builds a model based on objects, and the second based on processes.
Because the first one thinks with nouns, and the second one with verbs.
A process is an action, which means it is a verb (linguists are startled), and it is difficult to describe the model using verbs as the basis. It is simpler and clearer to use nouns as a basis, i.e. objects. The clerk does not have the function “Search”, he has an object of the class “Search”, in which the search methods are hidden.
Compare 2 famous phrases:
"Night, street, lantern, pharmacy"
and
“I came, I saw, I won”
The first with the help of 4 nouns convincingly enough transfers the objective reality to the area of abstract models of our consciousness and even adds emotional coloring.
If we design the system, then the framework of the model is ready, and the night is described as a separate object that affects the state of other objects.
The phrase of the three verbs is difficult, but can also be a description of the model. If you instruct the business analyst to describe himself, he will create a model: "He came, he saw, he described." I saw the actions of a specialist, connected the squares with arrows, transferred the object from state A to state B, and the business process began. Where he went, why he went from the model does not follow. Where necessary, go there and go.
We, clerks, have a regulation (set of rules) and instruction (sequence of actions). The regulation describes the life cycle of objects and the rules that provide this life cycle. The instruction describes which buttons to press in which sequence.
The rules have an object-oriented nature as opposed to a procedure-oriented instruction.
I consider the very principle of building a model based on business processes as vicious. It is like building a model based on a user’s manual, without reading the regulations. Moreover, I do not criticize the method, but the way of thinking (this is not forgiven), when the model is based on a process that changes its state, and there are no objects at all, or they are as properties of the process.
Recently, one professional in the construction of systems with full confidence stated to me that an account is not a document.
In our mercantile age it is difficult to imagine a person who would not hold a bill in his hands. How deeply should process-oriented thinking sit in the brain so that the basis for payment with a number, date, and signatures should not be considered a document, but should be considered one of the reporting forms of the process. And he does not just think, he designs the system in such a way and teaches others. Horror.
The example with a mammoth is somehow difficult and not convincing. Consider something more understandable, for example, the invasion of a bug (bug tracking, English - translated as I could).
You can consider each stage of the application as a change in the state of the process. There is a process that under the influence of business procedures acquires new properties and changes its status.
Each stage can be considered an object associated with other objects as either a host-slave relationship (owner-slave, English for solidity), or a ground-linked relationship.
It all starts with the application.
Business analyst: Application is a process.
Clerk: The application is a document.
User: I do not care, just to be fulfilled.
DP: The application may have a basis document: for example, an incoming letter signed by the executor with the resolution “Please expel the bug and give the answer to the applicant”. This means that the answer to the applicant will refer to it.
B-A: so what? This is our process.
DP: The process was created on the basis of the document, this is normal, but it’s strange to put the process in the answer as the basis.
B-A: nothing strange: incoming is a process, application is a process and an outgoing process too. They generate each other and are related to each other.
User: Inbound is a document. The boss said so. And the process is when he waved and shouted at them.
B-A: you don't understand. The incoming scan and attach, the status of the process is changing, the boss must impose a resolution ...
DP: resolution is also a document.
B-A: did you understand what you said?
The application is considered by the project manager and lists the performers.
DP: The resolution is quite a complex object: it contains text, names, timelines, urgency, etc. In addition, there may be several resolutions, and each will have its own life cycle. And I call it a document, because after saving it should become immutable. Do you remember the management of entries in ISO-9001? The document is considered to be unchangeable, not because it cannot be corrected (the term can be postponed), but because any normalization should be excluded from it. It should be immutable not at the level of the user interface, but at the database level, i.e. to be self-sufficient. The paperwork condemns the normalization: the head can change the position, the executor is the last name - everything in the document should remain as it was. Document is normalization-free zone (English for persuasiveness).
B-A: immutability means that when the value changes, the old value is transferred to history, and history cannot be changed.
User: immutability, this is when I poke, but it does not poke.
DP: resolution can be sent by e-mail. For the document is quite familiar.
B-A: the application has an associated “Resolution” entity. Sent no worse.
User: One has a related entity, another has a subordinate document. What do I need?
The performer begins work on the beetle.
Business analyst: Work is a process. Anyone ask.
User: You are right.
Clerk: it is not the work that is recorded in the database, but the work report (start, content, completion percentage) - and this is a document.
User: And you are right. All your differences in terms. What does it matter what word to call.
DP: For the ancients, the thought and word were denoted in the same way: Logos. Remember the documentation from Ivan: "At first there was a thought ...". This means that if the model is described crookedly, then the system will be a curve. And our models differ at the level of understanding (conceptual incompatibility). For me, “Work (Task)” is a document in the journal “Works”. It may be associated with the application (the journal "Applications"), or it may be with the service department (the journal Sluzhebki), or it may be proactive and not connected with anything at all.
The organization management system is a set of interrelated journals that form a single whole. Journal documents can be copied to other journals and begin a new life there, without losing their properties, but acquiring new properties in a new life.
There is a forest biocenosis, there is a bookcase. If you cut the mushroom in the forest and put it in the closet, it should not become a book about the mushroom.
A model of the world (no matter whether large or small) can only be implemented in a document-oriented database.
B-A: What is such a doko-bd-mongo-db? The base must be relational and normalized three times. Look around: most of the systems in the world are created by us.
DP: Look at these systems. Does it surprise you that after your optimization the staff increases, that according to American statistics, paperless technologies increase paper consumption by 40%?
User: I even have paperless objects, even paperless processes. Until the printer is taken away, I will still print everything.
BP: I heard what he said! So I won.
DP: Won, and calm down.
B-A: No, I won't calm down, no, I won't calm down, no, I won't calm down ... (D.Harms)
- Dear! Life is motion. It cannot be described in a declarative language.
- Life is the interaction of objects. Until scientists discovered microbes, the treatment was ineffective. The imperative part of the model should be secondary.
- A user is an object model?
- Of course. Properties are set by the administrator, the methods are specified in the instructions.
- Is the user difficult to debug?
- Not. It is much harder to debug a programmer. But the main trouble is a business analyst: it is not debugging.
- Goodbye.
- Happily.
Source: https://habr.com/ru/post/236723/
All Articles