About biology, mega constructions and magical animals
The story in many parts with the continuation and still unknown to anyone (but always happy) end.
Task: there is a Bank with a huge range of banking products and services for each of the products (for more, visit www.sberbank.ru ). It is necessary to automate all frontal scenarios for each of the products, for each of the channels for different groups of customers (yes, yes - different categories of customers may have different service scenarios for the same channel).
While it sounds boring and incomprehensible. However, those who had to automate the financial sector, can estimate the number of frontal scenarios for automation and the required number of functional elements. Simple engineering estimates will give approximately the following indicators:
')
Already better. We have some kind of texture, but for now this is some kind of frozen ecosystem without dynamics and without evolution.
But,
But there are also factors that have a favorable effect on the growth in the amount of functionality:
It seems that the frontal functionality tends to multiply and evolve as bacteria in a nutrient medium and any external influence, except for obsolescence of the service channel, only bends the growth of exponents. Barrel Petri for the front office functionality of Sberbank should be a single frontal system or abbreviated as ESF .
Naturally, the automation of such a scale on one knee does not build or support subsequent changes. The solution that derives the total number of knees of the builders to the horizontal asymptote is not so obvious. Besides the fact that there are a lot of bricks and they need to be very quickly folded up, you also need to be able to replace the floors of the lower floors without collapsing the upper ones.
Since the computational complexity of the target solution is low and the functionality is mainly decomposed into typical, like Lego bricks, the high speed of construction will give RAD.
RAD itself is available in almost all front-end industry solutions. However, it is built around a configuration kernel or a weakly granular architecture, which does not allow us to solve the above problem with overlaps. Naturally, with the configuration kernel so it is impossible, the extraction or replacement of any supporting structure will lead to the collapse, restructuring of the entire application functionality, along with the mandatory regression.
In addition, the configuration kernel does not allow us to satisfy the expectations of an exponential growth in the amount of the functional mentioned earlier. RAD is faster for typical functionality, but RAD does not allow “to generate” a new butt based on an existing one.
The decision came from the MDD (Model Driven Development). It is only at first glance “subject-oriented language” - it is something abstract and abstruse. Nobody bothers us to create a "domain-oriented language" of the configurations themselves. Moreover, the configurations of different floors of the tower: architecture, functionality, the banking area itself can transform into each other and, finally, into executable code. We relied on the following MDD benefits:
So we came to an understanding of how to make a tower, which at some point should start to build itself.
Actually, it is this magical beast
dwells on the button to start the process of generation. How does the user's workplace, presented in the screenshots below.
ARM Architect
ARM System Analyst
ARM System Analyst
Yes, we planted our system analysts for Eclipse + Papyrus. The overall configuration model is still built on the basis of the rendered tree of UML objects and allows you to configure: general requirements decomposition, process configuration artifacts, visual forms, integration points, entities and their attributes, reference books and a bunch of system objects of the ESF platform itself. A little later, there will be a JasperReport editor.
The overall target generation model is shown in the diagram below. The first, while absent, level is the level of the designers of the domain. Objects of the domain model are transformed into objects of the functional model. For example, plans include the implementation of a designer of an application for a banking product, including a status model. The latter will have its own magic button and generate at the level of the functional model a prototype of the process to work with the application.
General code generation model
The second level is the actual level of the model of functional elements. It allows you to generate the first useful artifact for an IT project - the complete specification of functional elements.
The next stage of generation is the generation of the component model. As seen on the first screenshot, the model looks pretty boring: just orange and white squares. These are components (in our terminology, application modules), which are transformed into the final code in the next stage. Within each module, key classes are designated with a corresponding role — a typical interaction pattern. All this, in the end, turns into executable code.
Naturally, when you press the magic button with the unicorn, at the level of the functional model, the entire transformation pipeline passes at once. But the presence of such stepwise generation allows us to:
As mentioned in the previous two sections, the last point is especially important. It will then allow to convert 10 4 visual forms into 10 5 for the tasks of automating A / B tests or outputting a script to a new channel. At the same time, labor costs do not increase even twice.
An important element of the functional model is a huge amount of validations. For users who are not professional developers, the reason why the code is not compiled, or if the NPE pops up, will be a secret. For similar reasons, the standard functionality for step-by-step debugging of frontal scripts processes has been added to the system.
Any final code must be able to be corrected and modified manually. Corrections of this kind, especially if the question concerns the need to add a small feature or fix bugs during functional / integration testing, often pass by other participants - they are not reflected in the specification or, as in our case, in the model.
To ensure the completeness of the configurations, we have developed a functional that automates reverse engineering (Reverse engineering). We build the Java Model of a dedicated block of functionality corresponding to a separate application module (the orange box in the first screenshot), and try to recognize the patterns of the code, comparing them with what is in the component model. While this magic more or less successfully works for application entities, public API, key system objects.
That's all for now. And in order to understand in more detail the internal mechanics of the instrument, the requirements for it and the architecture, in the next article we will talk about what is common between electricians and architects from IT.
Front office biology
Task: there is a Bank with a huge range of banking products and services for each of the products (for more, visit www.sberbank.ru ). It is necessary to automate all frontal scenarios for each of the products, for each of the channels for different groups of customers (yes, yes - different categories of customers may have different service scenarios for the same channel).
While it sounds boring and incomprehensible. However, those who had to automate the financial sector, can estimate the number of frontal scenarios for automation and the required number of functional elements. Simple engineering estimates will give approximately the following indicators:
')
- Number of scenarios (frontal processes): ~ 10 3
- Number of visual forms in scripts: ~ 10 4
- Number of print forms in scenarios: ~ 2 10 3
Already better. We have some kind of texture, but for now this is some kind of frozen ecosystem without dynamics and without evolution.
But,
- Those who depend on the total number of products and their service scenarios agree on a new sales plan once a quarter and release new products and promotions requiring replacement of old scenarios and selection of additional “hybrid” scenarios as part of cross-sales. For the year, all the old functionality can be replaced with a new one.
- those who depend on the design of visual forms periodically tend to radically change either the design or the principles of form filling, then assuming the replacement of the entire population of scenarios, forms, accompanying functionality, then demanding its increase by an order of magnitude to ~ 10 5
- The Central Bank of the Russian Federation, as a meteorite that killed dinosaurs, can affect everyone by demanding a revision and revision of the entire functionality with its new provisions.
But there are also factors that have a favorable effect on the growth in the amount of functionality:
- Business expectations regarding the possibility of building segment-oriented or personalized service processes, which is good ground for the growth of the number of service scenarios to ~ 10 4
- Naturally, all the scenarios need to be tested for the effectiveness of either the landing page or the convenience of the operator’s workplace, which, if it does not produce again the number of scenarios themselves, then it increases the population of visual forms up to ~ 10 5-6
- There are also long-term trends of intraspecific struggle. For example, remote maintenance displaces office space, and front-end functionality over remote channels grows on its own. At the same time, the office does not give up - it tries to get part of the “gene pool of the remote” and create new omnichannel (Omni channel) service scenarios - ~ 10 5-∞
It seems that the frontal functionality tends to multiply and evolve as bacteria in a nutrient medium and any external influence, except for obsolescence of the service channel, only bends the growth of exponents. Barrel Petri for the front office functionality of Sberbank should be a single frontal system or abbreviated as ESF .
Not the Babylonian system
Naturally, the automation of such a scale on one knee does not build or support subsequent changes. The solution that derives the total number of knees of the builders to the horizontal asymptote is not so obvious. Besides the fact that there are a lot of bricks and they need to be very quickly folded up, you also need to be able to replace the floors of the lower floors without collapsing the upper ones.
Since the computational complexity of the target solution is low and the functionality is mainly decomposed into typical, like Lego bricks, the high speed of construction will give RAD.
RAD itself is available in almost all front-end industry solutions. However, it is built around a configuration kernel or a weakly granular architecture, which does not allow us to solve the above problem with overlaps. Naturally, with the configuration kernel so it is impossible, the extraction or replacement of any supporting structure will lead to the collapse, restructuring of the entire application functionality, along with the mandatory regression.
In addition, the configuration kernel does not allow us to satisfy the expectations of an exponential growth in the amount of the functional mentioned earlier. RAD is faster for typical functionality, but RAD does not allow “to generate” a new butt based on an existing one.
The decision came from the MDD (Model Driven Development). It is only at first glance “subject-oriented language” - it is something abstract and abstruse. Nobody bothers us to create a "domain-oriented language" of the configurations themselves. Moreover, the configurations of different floors of the tower: architecture, functionality, the banking area itself can transform into each other and, finally, into executable code. We relied on the following MDD benefits:
- The final executable code can always redefine or add functionality without touching the transformation algorithms and get an important particular solution.
- The transformation algorithms themselves can be replaced and extended without changing the already generated code. As we said above, the target life of his life is not big
- And the most important thing. Already ready application functionality is just one type of model and only then the final code. So, it is possible to invent an algorithm for it, which will, if necessary, overtake it into another model when replacing the architecture, requirements of the Central Bank, the need to automate A / B tests, generating specialized service scenarios by channels and consumer segments.
So we came to an understanding of how to make a tower, which at some point should start to build itself.
The magical beast and where it dwells
Actually, it is this magical beast
dwells on the button to start the process of generation. How does the user's workplace, presented in the screenshots below.ARM Architect
ARM System Analyst
ARM System Analyst
Yes, we planted our system analysts for Eclipse + Papyrus. The overall configuration model is still built on the basis of the rendered tree of UML objects and allows you to configure: general requirements decomposition, process configuration artifacts, visual forms, integration points, entities and their attributes, reference books and a bunch of system objects of the ESF platform itself. A little later, there will be a JasperReport editor.
The overall target generation model is shown in the diagram below. The first, while absent, level is the level of the designers of the domain. Objects of the domain model are transformed into objects of the functional model. For example, plans include the implementation of a designer of an application for a banking product, including a status model. The latter will have its own magic button and generate at the level of the functional model a prototype of the process to work with the application.
General code generation model
The second level is the actual level of the model of functional elements. It allows you to generate the first useful artifact for an IT project - the complete specification of functional elements.
The next stage of generation is the generation of the component model. As seen on the first screenshot, the model looks pretty boring: just orange and white squares. These are components (in our terminology, application modules), which are transformed into the final code in the next stage. Within each module, key classes are designated with a corresponding role — a typical interaction pattern. All this, in the end, turns into executable code.
Naturally, when you press the magic button with the unicorn, at the level of the functional model, the entire transformation pipeline passes at once. But the presence of such stepwise generation allows us to:
- Finally, add a layer of business constructors regardless of the organization of the functional layer and component architecture.
- Expand the composition of functional elements and add channel-specific functional elements
- Manage component architecture regardless of functionality
- Limit the complexity of the transformation code of a group of related configuration elements of one level into another group of another element with a volume of 1K-2K lines of code.
- Solve problems in detail, but not globally. For example, the task of transforming VO-> DTO-> VO very often has a particular solution with the volume “okay, for this weekend I’ll get it right."
- To have on each layer a little excess number of configurations to automate the generation of special cases of configurations and “automate automation of automation”. For example, for a channel frontal scenario, generating a set of its variation for A / B testing can be performed automatically. Well, mapping, mapping, mapping.
As mentioned in the previous two sections, the last point is especially important. It will then allow to convert 10 4 visual forms into 10 5 for the tasks of automating A / B tests or outputting a script to a new channel. At the same time, labor costs do not increase even twice.
An important element of the functional model is a huge amount of validations. For users who are not professional developers, the reason why the code is not compiled, or if the NPE pops up, will be a secret. For similar reasons, the standard functionality for step-by-step debugging of frontal scripts processes has been added to the system.
Any final code must be able to be corrected and modified manually. Corrections of this kind, especially if the question concerns the need to add a small feature or fix bugs during functional / integration testing, often pass by other participants - they are not reflected in the specification or, as in our case, in the model.
To ensure the completeness of the configurations, we have developed a functional that automates reverse engineering (Reverse engineering). We build the Java Model of a dedicated block of functionality corresponding to a separate application module (the orange box in the first screenshot), and try to recognize the patterns of the code, comparing them with what is in the component model. While this magic more or less successfully works for application entities, public API, key system objects.
That's all for now. And in order to understand in more detail the internal mechanics of the instrument, the requirements for it and the architecture, in the next article we will talk about what is common between electricians and architects from IT.
Source: https://habr.com/ru/post/324626/
All Articles