Why UML
Vsevolod Leonov - product manager, Embarcadero.
Alexander Lyulin - Lead Developer, "Garant"
Maxim Krylov - Project Manager, Garant
Attention, the information in the next paragraph is absolutely not advertising . None of the authors will discuss and even mention any software products in the context of their properties, functions, competitive advantages, emotional perception, appearing in the head from repeated pronouncing of names, etc. Below is a reference to the product and the company to determine the qualifications of invited experts. Simply put, who is interested in reading the opinion about the UML of a certain “washi puppkin” who developed the “best-xxx-dauloader-iksploit” program?
The company "Garant" is known to many Russian IT-specialists due to its key product - the IPO system GARANT. Most of the company's employees are engaged in software production, and the system itself has a 23-year history of development and has tens of millions of lines of code written in various programming languages. With such a scale, linguistic and technological heterogeneity, high production rates, very strict stability requirements, only the use of the most advanced technologies can ensure the quality of the evolving system. UML as a modeling tool is undoubtedly one of these “advanced” approaches, the use of which in Garant is characterized by a high level of automation with a significant share of strengthening its systemic role. Today, the leading developer of the GARANT system Alexander Lyulin and the project manager Maxim Krylov share their experience.
')
The proof of the lack of advertising - let's look at what is written above. We have just defined:
The site of the company is given again not for advertising reasons. So does even wikipedia, which is the benchmark of "ad-free". The above paragraph serves to add publication a) completeness; b) responsibility to the readers.
If you (in a broad sense - people, companies, specialists, experts) do not agree with the authors, we will be glad to see references to your publications on a subject. If you need help with this, contact vsevolod.leonov@embarcadero.com.
Vsevolod : Tell us, was the use of UML originally adopted as one of the components of the development process?
Maxim : No, of course, when we came to Garant, it was simply not there yet. But, it seems, already in the 97th year, our young and talented colleague (although at that time we were all young) brought a floppy disk with one of the first UML modeling tools. From about this point, we can assume that the introduction of UML within the walls of the “Guarantor” has begun. However, before its use in our main projects, so to speak on an industrial scale, more years passed.
Alexander : Moreover, the use of UML has been introduced for a long time and in several stages. With the growth of our development and understanding that without this tool there is a risk of not coping with the increasingly complex structure of the code and the internal architecture of projects.
Vsevolod : Were there “ideological differences”? There are different coding styles, did it not turn out that “everyone has their own UML”? Or does the UML “comb all one size fits all”?
Alexander : Of course, there were differences. And it was precisely in the ideological basis of the introduction that there was a desire to "comb" everything and unify the existing approaches.
Maxim : By the time when the use of UML from the experiments of one or two enthusiasts passed into the design implementation stage, we already had a fairly clear understanding of what it is and why and how to make it so that there are no “different UMLs”.
Vsevolod : At what point was it decided to look towards UML?
Alexander : When it came to the realization that projects are complex. That many people are involved in them. What you need to somehow "negotiate". And that it is necessary to somehow "see" the overall architecture of the projects.
Maxim : For a long time, its use was limited to personal sketches for consumption by a narrow group of "initiates." At some point, they tried to start generating CORBA IDL from it. As a result, they came to the conclusion that this is almost impossible and they wrote their own simple generator. Actually, this was the point of no return. After that, UML was used in most projects, and most importantly, it was reborn into something much more than just a set of pictures, we will tell you more about this later. But at the beginning, yes - just as an opportunity to reach an agreement faster and more efficiently.
Vsevolod : Were there cases when it was not possible to agree even with the UML?
Maxim : In any team, there are situations when someone loses the desire to negotiate. Neither UML nor anything else will help here. But when people take a constructive position, having a universal language makes life much easier.
Alexander : UML is not a dogma and not a “universal pill”, but a means. But work has become really better. Because it became possible to simply “glance” throughout the system, quickly changing the scope of the review. Then we look at UseCase, then in 5 minutes we have already gone down "to bytes". Scaling is done very quickly. Let's say, like in Google Earth.
Vsevolod : Is the use of such techniques and just the need to "negotiate" an indicator that there are problems in the distribution of "areas of responsibility" in the code? Why negotiate and harmonize, if you can clearly distinguish between who develops what classes / methods and who uses them? I make the bolts, Vasya - nuts, and Zhora screw them two parts. What details? Yes, no matter what, we clearly divided the areas of responsibility. Why is this in software development not working?
Alexander : Up to a certain point, such a scheme worked with us. But I had to change roles. Replace others. And the complexity of the projects has increased.
Vsevolod : And how to understand that the project has already become "difficult"?
Maxim : It all depends on the number of bolt-nut-part chains, on the versatility of each nut, on the variability of the bolts and their manipulations. To write “hello, world” you do not need to negotiate with anyone and share areas of responsibility. No need for UML and OOP, SOAP, XML and “flexible” methodologies. It all starts with the growth of the project. At some point, it turns out that Vasya changed the thread diameter of his nuts, and Zhora can no longer screw them onto your bolt, and even worse, they jump off of them themselves, already somewhere later on. Or suddenly it turns out that at the end of the chain there is a new Masha, who with incredible difficulty spins back your nuts with bolts, and changes them to rivets that come from the next shop. These are all primitive examples, but accumulating, mixing, forming bizarre combinations, they create complexity, it is because of them that we lose the quality of both the process and the result.
The use of any notation, understandable to all participants in the process, reduces the number of such surprises. A hypothetical production with bolts and nuts would be impossible without drawings and documentation. But this is not enough either. To build an efficient conveyor you need machines, CNC robots. They unequivocally and without liberties interpret input documentation and issue a guaranteed result. Therefore, one UML does not bring as much benefit as the UML that you can feed to the “machine” and get 100% valid, debugged code at the output, which then in manual mode turn into the final product.
Vsevolod : How is the modeling process? Is this how the group of “interested comrades” is going to come together and are they all at the same time “pointing fingers at the diagram” and drawing it? Or there is a clear distinction - master-slave. Those. one draws - the rest take note?
Alexander : It happens and that. And going, and poked. Master-slave separation also happens. But these are rather “roles” rather than positions. The “circle of specialists” is the initial one. We first communicate verbally. Then we read the requirements. Then ask questions about them. We get answers to them. We draw a prototype. Somewhere we immediately determine the “circle of specialists”. More narrow. Or wider. We run solutions. We find "pitfalls in the TK" or contradictions with the "existing architecture." Further, the process is generally cyclical.
Maxim : We, as a rule, draw everything, or almost everything. Depends on the project and specifics, of course. But theoretically, the “leading” model (namely, “no”) is “driven”, it seems to me more correct and viable, since allows you to best use the strengths of some and level the shortcomings of others. Those who are better "sharpened" to design, draw a model. Those who feel more confident in the implementation of algorithms generate code from them and fill it with business logic.
Vsevolod : What problems did you initially want to solve with UML?
Maxim : Initially, at the level of experimentation, just as a way to structure your thoughts. The very first experiments included only drawing classes and connections, there was no clearly articulated practical use, rather we liked it aesthetically, it was great and interesting, as if we were drawing illustrations to the books of the "classics." But by the time of the actual implementation, the main problem that I wanted to solve was the insufficient speed and quality of the manual coding of the “routine” code. Those. at the head of the corner was code generation.
Alexander : The complexity of taking connections. Their "imperceptibility" in the "bare" code. Design and coding rules. Using template solutions. Again, UML was seen as an opportunity to “agree” more formally.
Vsevolod : And why exactly UML?
Maxim : At that time, there simply was no alternative, UML was the only universal graphic notation that rather comprehensively described the subject area and had instrumental support, even with some kind of code generation. Therefore, we can say that it happened historically. And later, when we realized that it was not so important “how” to draw, how much “what and why”, then there was simply no point in changing the UML to something else (for example, DOT). By and large, UML for us is only a specific notation familiar to the majority, “the shape of arrows and small squares”, it is not important, but the principle of action, i.e. what we do with it and how.
Vsevolod : Classics are not deceived? Or did you have your own vision of the place and role of UML?
Maxim : The classics set the basis, and we used it. And they used it as the classics implied, as it seems to us, but they did not fully formulate it. First, the penetration of the model was not determined. Yes, everyone heard about MDA, but how many have seen it? We “fixed” this, for example, one of our versions of the metamodel implied the beginning of the system design from the description of the “problems” in the UML that it had to solve, of which the “possibilities” were born, of them the “precedents”, etc. to "servants", to "bytes". All this was one holistic model in which it was possible to say about each “byte” which user problem it solves. And for each "problem" - get all the source code associated with it.
Alexander : This is a similarity to the "dolls" and "assembly drawings." And at different levels, which can be arbitrarily many, and not just Class View, Deployment View, like the "classics". Drawing "enterprise level" and drawing "level containers in the style of STL." UML allows you to "logarithm" the complexity of the problem. For me personally, designing / coding / debugging / testing a fairly large UseCase is not much more complicated than debugging a "list of integers". Another thing is that debugging the “list of integers” can sometimes take months.
And so - "assembly drawings", matryoshka and "nomenclature of chips". These are the cornerstones. On the one hand, they “logarithmize” the complexity, and on the other hand, they allow the system to “quickly change the scale”.
And yet, the “classics” did not pay enough attention to stereotypes. And here it is - the cornerstone. << Stereotype >> is just an element of architecture and meta-model. The stereotype affects code generation methods and the final code.
Vsevolod : Let's discuss the concept of "stereotype"?
Maxim : The main problem of using UML in “classical” tools is that code generation is rigidly connected with a predefined static metamodel. You cannot change one or the other. Neither change, nor expand, nor change the rules or set new specific ones. The main thing is that the classics did not reveal to the public, and the “classical tools” did not realize, this is the potential of UML precisely from the point of view of meta-design. Creating your own metamodels with their own specific code generation. And here the concept of “stereotype”, which Alexander speaks of, begins to play a key role. The stereotype allows us to define a group of specific metaclasses with arbitrary code generation associated with them. In fact, with the help of stereotypes, you create an arbitrary meta-model, which automatically becomes your own DSL, transforming squares into code, according to any rules you implement. It is this aspect that allowed UML to become for us not only a tool for drawing pictures, but something that really simplifies the development process, sometimes making truly impossible things possible. And as it seems to us, the absence of this or a similar mechanism in commercial tools, and now leads to the fact that UML cease to use and look at it as the "fifth leg".
Alexander : I will add that UML has its own “meta-model,” drawn on UML itself. It has the concept of "class element". These are Class, Category, Operation, Attribute, Dependency, Port, UseCase, Actor, etc. From these classes are constructed "final diagrams." And code generation is usually tied in time for a class. But this is where the “classics” mistake is - there is neither flexibility nor extensibility. We have risen to a higher level. Actually, the UML describes our meta-meta-model, i.e. rules of formation of rules. Next, we define the meta-model, introducing into it any concepts we need. For example, we can determine for Delphi the possibility of multiple inheritance. Then we attach to this metamodel the rules for converting its elements into code (or any other artifacts, for example, into documentation, auxiliary files, etc.). In the example with multiple inheritance, this may be a transformation into a single inheritance plus aggregation, but at the same time, so that from the programmer’s point of view it will look like 100% inheritance. Finally, we create real models of our subject domain, but already by operating not with the fact that we were initially offered “classics”, but with all that arsenal that we ourselves invented at the meta level and we get from them ready-made code of arbitrary complexity.
Vsevolod : Tell me in detail, how did all this develop in your country - stepwise?
Maxim : At the beginning of work on the new version of “Guarantor” (“Platform F1”), we faced a problem: the server was developed in C ++ / CORBA, and the client was a shell in Delphi. For some reason, we couldn’t use it on a shell that is native to Delphi, VisiBroker, and we did not see the server side of the sane alternative. Then a solution was proposed to start an “adapter” (dll in C ++) on the client, which would work with the server using CORBA, additionally performing some internal transformations, caching and even containing some part of the client logic, while giving everything that is needed shell on Delphi in a clear and convenient form. I think it’s not worth saying that such a system as “Garant”, the range of interfaces through which the adapter and the shell interacted, quickly became rampant. Now imagine what is any object interface, between dll in C ++ and delphi? In short, this is “hell”: different type transfer rules, different memory management, lack of description control in the exported header and in Delphi, when absolutely any discrepancy leads to completely unpredictable results and super-nontrivial debugging, etc.
Taking into account, the number of interfaces that were and still promised to be, as well as the degree of their variability, we quickly realized that the task is in fact not feasible. That's actually at this moment for the first time and we used the UML "by purpose". We already had our own generator for CORBA IDL, and it has already been built on the principle of patterns describing a metamodel and code generation based on it. Actually, all that was needed was to define a new metamodel for adapter interfaces and, on its basis, describe code generation, which would yield 100% consistent descriptions for both C ++ and Delphi, taking into account all the features and subtleties.
In the end, everything was done fairly quickly, and it began to bring results. C ++ programmers who wrote the adapter no longer thought at all that something, Delphi programmers had to export somewhere, worked with the adapter as if it were written entirely in Delphi, according to their usual principles before naming methods and properties. Everyone simply drew the necessary interfaces on the model, generated the code and worked in a “native” way for both languages. By and large, this was the first success story, after which we actively began to develop the idea of ​​pattern generation and metamodeling. And in many directions (though not in all) achieved impressive results.
Vsevolod : How does a new person get involved in the development team? Is he given a heap of diagrams "under his breath?" Or does he begin with elementary operations that do not require “to see the system as a whole”?
Alexander : There is a list of non-key or secondary features. For starters - give them. But not very much. In order not to "discourage" routine. We look, as is involved. Along the way, we talk about the "infrastructure" and its own components. We consult orally and in writing. There is also a set of documentation that we recommend reading. Then, gradually, “real” tasks, model and everything else. Something like this. If there are “separate large tasks” on the agenda, then we start with them.
Vsevolod : Everyone knows that new approaches and methods are not always positively perceived by all team members. Were there any cases of active or passive opposition?
Maxim : Many people perceived “our UML” as an invasion of their privacy, a restriction on their freedom of action. After all, before that, everyone programmed as he wanted. There appeared some rules and restrictions even at the design level of implementation, and not just interfaces. Probably, we bent the stick a little and introduced too many restrictions. But this is a very powerful tool, you do not just define the metamodel and code generation, you can also describe arbitrary “constraints” associated with it. For example, from “it is impossible to transfer collections as a result by reference”, or “a method should not have more than 5 parameters”, to control architectural layers, and “traceability” to requirements. Of course, not all were in agreement with all the restrictions, and this frightened and repelled many of them.
Vsevolod : How did the implementation process go - was the reverse design carried out?
Alexander : Not implemented. At that moment there simply were no good tools. And now I have come to the deep conviction that this is not necessary. Sincein the process of “drawing an existing code”, it is rethought, ideas and ways of its refactoring appear (you shouldn’t just do refactoring in the process of drawing, it should go a separate step), and design / coding patterns are applied. No “automaton” will do this. All attempts to transfer something to the model of all kinds of “automata” looked depressing.
Maksim: Already at the stage of creating a template generator, it became clear to us: automatic reverse engineering is “evil”. And not because it is practically impossible to conduct it at a sufficiently high level, even if you have a primitive basic metamodel containing only native abstractions for the language, not to mention more complex specific metamodels for which, I think, it is impossible to make an automatic reverse even theoretically. The key point was another - the presence of a reverse breaks the very idea of ​​using UML for code generation. Our task was to learn ourselves and to teach others to think not in codes, but in abstractions, if possible to code not attached. This is a separate complex topic, and it was extremely important for us. Therefore, our generator by its architecture and by the way it generated the code, eliminated and at the same time made unnecessary the possibility of reverse,as such.
Vsevolod : We will take a step "back" to the PLO. Can you say that UML helps refactor?
Alexander : Yes. Promotes. But, I can say that you should not mix refactoring with the “implementation of requirements”. They need to "spread in time." And think about tests.
Maxim : Again, looking at "what" UML. If you just draw "dead" diagrams, it will not help much, although it may give a small positive effect. If you have a metamodel and patterned code generation, as in our case, then the refactoring capabilities are at a completely new level.
Vsevolod: Why do you have to refactor object code? Is it a lack of experience? Or are there objective reasons for the evolution of the system as a whole? Or just the natural "growth in width and depth" of the system?
Alexander : I think that all of the reasons listed take place here. Refactoring is a separate big topic. But refactoring helps couple - model + tests.
The model restricts the developer "from above", allowing you to remain "within the framework of the Architecture" (those metamodels) or to correctly modify it. And tests limit the developer “from below” allowing him to remain within the framework of the TK and regressing the errors already found. Those.the model, let's say, is the “tutor”, and the tests are the “validator”. Although there are colleagues to whom I said this phrase, and they took it with skepticism. Saying something like “no one will forbid a Krivoruk programmer to make business logic in View, and to make View elements in business logic”. And they are right. And usually the skeptics are just "straight-handed" programmers.
Why do you need refactoring? It is not a secret for anyone that the entire IT industry in the whole world has not learned how to plan development terms “in the sense of responsibility”. And if so, the dates begin to tighten. No matter how competent analysis at the initial stage was made, life is more difficult. And then decisions begin to be made "in the style of XP." What in my opinion, in general, is correct. “I will think about it tomorrow,” said one heroine. And for the time being, these decisions "have the right to life."
It often happens that the requirements for an already existing system change “explosively” or “avalanche-like”. And it becomes “cramped” within the framework of the architecture, which, although “flexible”, but not “rubber”. Here too - it is necessary to do refactoring. That the architecture "did not collapse".
Vsevolod : «», UML, DSL, ?
: Here is a real life example. We have defined interface factories on the metamodel - a method on an interface with a special stereotype that turns the code into a set of other interfaces and classes that implement several different patterns, which ultimately allows you to quite flexibly manage the implementation of interfaces with interfaces in a runtime. displace them, etc. I repeat, all this is one method, drawn on the model. At some point, when it has been used for a couple of years, and there were not a dozen or two of such factories, we suddenly realized that there is a nonoptimality in the code that affects performance. But to eliminate it, you need to change the structure of these generated classes. It is not easy to replace “a” with “b” with a search for the entire project, namely, to change the structure. In our case, it took a few hours toto rewrite the generation pattern and rewrite all projects. And if all this was written by hand, then in a hundred different places the implementation of these several patterns would be “pushed away”, a little different everywhere, and to change, and then debug it all - it would not be real in two hours or two months .
Alexander : In addition, it is easier for me to “refactor” the diagram, and not the code. It is easier to move “squares” from one place to another on models rather than pieces of code and files between folders. At the same time, it is still necessary to “properly maintain the architectural layers” with “hands”. And the model - “thinks for me.” She is a tutor. She will not let me make a "knowingly wrong decision." Or this decision will be at least deliberate.
Vsevolod : Is it possible to measure the quality of refactoring? No need to re-refactor?
Alexander: I'm afraid this is not a criterion. Although if, of course, we managed to achieve the absence of such a need, then refactoring is probably perfect. Another thing is that I did not see the code / architecture that would be perfect. If something is perfect “from above,” then it is imperfect “from below.” Or vice versa, “from below” is an ideal code, and “from above” - imperfect architectural solutions.
Vsevolod : We often talk about refactoring, and many perceive it negatively. For example, "everything worked, but then we did refactoring." Can we say that when using UML-modeling codes initially became a ray, and refactoring became less common?
Maksim: If everything works, and no external changes occur, then you do not need to do refactoring. Refactoring is not an end in itself, it is a way to achieve the goal more quickly and accurately, not allowing the code to turn into a “Russian salad”. The use of UML with code generation, even in the simplest version, automatically structures the code immediately. So, of course, yes.
Vsevolod : A painful question is the synchronization of UML diagrams and program code. Is 100% compliance achieved?
Alexander : Achieved. Due to the fact that there is 100% code generation from model to code. While it was not, I myself was a great opponent of modeling. I considered drawing diagrams as “monkey labor”.
MaksimA: Yes, due to the fact that there is no reverse, synchronization is always one way. And past it you will not pass.
Vsevolod : Ie Is code generation an essential condition for the effective implementation of UML in the development process?
Alexander : Of course. Moreover, if there is no code generation, and there is no constant generation, then at some point the diagram starts to be “just a picture”. She "foul." She is about nothing.
And of course, as we have said, code generation allows you to "encode" the code, I apologize for the tautology - much faster. Believe me, the above examples have already been cited, and I still have a million of them.
Maksim: I would say categorically, code generation is the key point of using UML. At least for us. Understand what the thing is, I will now say a strange thing that runs counter to the topic of our discussion: we do not use UML at all in the classical sense.
Vsevolod : Well, “arrived”, explain what you mean?
Maksim: Do not worry, I certainly exaggerate a little. As I have already hinted above, UML for us is only a form of “squares”, a specific graphical notation and nothing more. We took it as a set of primitives in a graphic editor, and built something substantially larger from them. The templates we talked about above allow us to describe any metamodel in terms of these UML primitives, Alexander already listed them above, “Class”, “Category”, “Communication”, etc. And as a result, to get new terms, new primitives, already a level higher and, moreover, recursively, if necessary, using which, a specific designer or programmer will create a specific model and receive code from it. Those. in fact, templates are what form a particular DSL and compile a model drawn on it into code, and UML is just a way of drawing this model. Those.a person, even well acquainted with the classic UML, may not immediately "enter" what he sees drawn with us.
Vsevolod : Are the “time lost” justifications for creating code in graphic notation increasing its quality?
Alexander : From my point of view, they are justified. Due to the possibility of stereotypes of a higher level. As soon as we see that the design decisions begin to repeat. Moreover, the model affects the development framework, and the framework affects the model. Well, in the presence of a model (and tests), refactoring moves to a completely different level of quality, as mentioned above.
Maksim: Alexander said about high-level stereotypes, this is a separate very important topic, and this is the most powerful mechanism that we now know. This is what allows turning atoms into mollecules, mollecules into alloys, parts, aggregates and, finally, into a finished product.
Vsevolod : You mentioned tests in the context of refactoring. Does this mean that in general, without tests, there is nothing to think about refactoring, and without refactoring and modeling is not particularly necessary?
Alexander: In my opinion, it is better, of course, first to test, and then UML, modeling, code generation. But here it has historically been the opposite. But I would certainly now prefer tests first. We are not "just thinking about tests." We know what they are. That they "will show errors tomorrow." And show. But of course - “we are thinking about tests.” We are writing "proactive" tests. We have “regression tests”. There are tests that test requirements. And they allow refactoring without much damage to quality.
Maxim : I do not agree with Alexander, it seems to me that these are complementary things, and where to begin is not so important. Rather, it should be determined by the internal culture and preferences of the team. I would have started all the same with modeling, in the end, tests can and should also be generated and not written by hand.
Vsevolod : Alexander, as I understood, initially you were an opponent of UML? Looking back (perhaps with a smile), is it possible to say that you thought this way: “why do I need UML, do I control my code anyway?”
Alexander : It was just me personally who, long ago, realized that “there are problems” . But without code generation and constant synchronization with the model, I did not understand how UML can personally help me. Now, I understand and use it every day, although it is certainly not easy for UML, as we have said above.
Vsevolod : Has “your UML” become another way to document software code?
Alexander : Yes, of course. Moreover, all our models are integrated into a common hypertext knowledge base. It also contains bug-tracking and requirements.
Maksim: ... and much more, that is our know-how. By the way, the integration is also built on the same templates: the html for the base is generated from the model, like the source code, and automatically placed on the server.
Vsevolod : In what form are UML models integrated? Not in the form of the same pictures!
Alexander : In the form of pictures with hyperlinks and explanatory documentation. But from the picture you can always go to the real diagram in the tool to work with UML.
Maxim : and vice versa, and also the changing tasks and commits to the repository are attached to them automatically.
Vsevolod : Are UML diagrams used to interact with non-programmers?
MaksimA: At the beginning of implementation, we tried to use UML for interaction. All requirements were designed as UseCase and Sequence diagrams. In the most understandable, as it seemed to us, for a non-specialist form. The first version of the F1 system, our colleagues, lawyers and marketers who set the task, honestly tried to read from the diagrams, and they even got it. But ..., let's say, the practice has not taken root.
Alexander : Still, not techies (not by education, but by vocation), do not really like all sorts of formal languages. They subconsciously easier in Russian literary, not UML. This is from the category of psychology.
Vsevolod : What UML-diagrams and in what volume are used?
Alexander : First of all, class diagrams and UseCases.
Vsevolod: Do you find other charts less useful? For example, are there enough “brains” of programmers to do without the diagram of “objects”?
Maxim : No. Sometimes we use state diagrams, describe them, and generate state machine code. But it is very rare.The use of finite automata, at the formal level, also requires a certain sharpening of the brain. In some places, sequence is used, but only as an illustration, i.e. as a “dead chart”, now nothing is generated from them, which means, as Alexander said above, her life time is very short.
Alexander : Perhaps, the Sequence is even more useful, just until you reach out to do the appropriate code generation for them. A diagram of "objects" is just those very chains of SAX-filters. When we operate not with classes, but with their instances.
Vsevolod : The classic RAD approach clamps the programmer into a fairly narrow frame. Database, interface, form, components, events, response procedures. How did you manage to expand this framework with UML?
Alexander: UML "pinches" in the framework of the "meta-model", which is developed. But this is partly sought. Compared to RAD, impurities and AOP elements are used much more actively. As well as a declarative, rather than an imperative approach to some parts of the projects. Those.on the model, a “data model” is drawn to the maximum divorced from what it should physically turn into, and it is transformed into an “active code” with the help of a code generator. For example, the "scheme of the document" or a set of "settings" of the project. All sorts of SAX filter chains, etc.
Maxim : It is important that he pinches where you decide. The metamadel does not impose any rules on its author; it imposes them only on the model and on the one who will create it. In one place you pinch, and in the other - give the unique flexibility and speed of the lego-designer.
Vsevolod : How does the use of models affect the architecture of the application and the structure of the program code?
Alexander: It's certainly not just models. The point is "brain hygiene." But the correct use of modeling enhances it. And, yes, the model is an assistant. I will make a reservation, if there is no desire to improve, then no models will help. As, however, and any other practice.
And the UML architecture and modeling have a positive effect :-) Logical layers appear. Parasitic cyclic dependences disappear, and so on.
Vsevolod : We will work in the "blitz" mode. When do you think you do not need to apply UML and modeling?
Alexander : For research and other studies. For the project "for two or three months," which then most likely will not have to be supported.
Maksim: If UML is used only for drawing, I agree with Alexander, but if for metamodeling and code generation, then I think that it is possible and necessary to use it always, especially if you are used to doing it. Of course, if this is not "hello world". Although it will probably be easier for me to generate “hello world”, at least I don’t need to remember how to make a new project in IDE :), because projects are also generated here.
Vsevolod : At what point of development and on what grounds can we say that the way you use UML is effective?
Alexander : It is enough to compare the time of writing some functionality "manually" or your way.
Maksim: The only thing is that there are still technical limitations of a specific instrument; sometimes they can have a very negative effect.
Vsevolod : How to gradually begin to introduce modeling into the production process?
Alexander : You can start at any time. The main thing is not to immediately try to “embrace the immense”.
Vsevolod : What part of the tasks can be closely integrated with UML and code generation, and what can be left "as is"?
Maxim : you can leave some not very structured, unique algorithms, something, in which there is no template, reuse, some kind of system that can be formalized and reproduced.
Alexander: I have not all the most transferred to the model. I first of all translate either new classes / entities. Or those that affect the process of alterations. Or those that "refactor."
Vsevolod : Probably, other approaches were tried. Is there an alternative to UML in the modern world of software development?
Maxim : For us, in the form in which we use it, it is not. But I have already said above that it is generally not very important in what concrete way to draw arrows with squares. The main thing that we do with it, and not what it looks like.
Alexander: I will clarify that in fact there are many alternatives to UML, and precisely because for us this is simply a way of describing a model. You can take any other graphical notation that has in the basis of the concepts we need, and use it. You can describe your own. It is possible in general, and I actively think about it, go to the text description of the model, i.e. create another DSL. There are many options and they can be combined.
Vsevolod : Are there any limits to the possibilities of your approach?
Maxim : as soon as you start to create your own meta-models, any restrictions disappear, you may lack only imagination and the ability to see the private in general.
Vsevolod : Is everything so wonderful, and there are no problems whatsoever? I want to shout in the best theatrical traditions: “I do not believe”!
Alexander : Of course, there is. First of all, the limitations of the tool. Insufficient generation rate on large models. Non-optimal UML interface editor, etc.
Maxim : the problem is not ideological, but technological. We gradually grow out of the tools that have been made for a long time and for many years retained their relevance. The generator requires updating, making modifications. But this is probably not a “problem”, but a “task”.
We also use a separate package as a UML scoop. Yes, it is already part of our "pipeline", but it would not hurt him to improve, update.
Vsevolod : your plans?
Alexander : Write your entire tool - model editor. So to say, to do "work on the bugs" in existing ones.
Maxim : And with that - cross-platform. In general, in this direction there are also a lot of ideas on how to make the modeling process even more efficient.
Vsevolod : In the next article we will discuss DSL?
Maxim : Yes, of course.
Alexander : With pleasure!
Vsevolod : As an employee of Embarcadero, using my official position, I ask ... Do you use Delphi?
Alexander: Yes, I use Delphi in development. I know about the contradictions between RAD and UML, and I try to use the strengths of each technology and achieve significant synergy. I do not use Delphi as a pure RAD tool for placing buttons on forms. This is one of the components of a rather complex technological chain. Now we are in the process of transition to Delphi XE4. There is a need for 64-bits.
Maksim: I grew up in C ++, but in a highly heterogeneous environment, in the projects in which I participated, Delphi, C ++, python, java, etc. were used at the same time, so I never supported holivars what is “better” - every time you wear a buckle. As a project manager, the main thing for me is the effectiveness of the solution as a whole. Our company uses Delphi for a long time and intensively, the main thing is to know the strengths and weaknesses of each tool, its potential, to correctly make on the basis of this decision, to build a technological cycle, to select professionals so that they would most closely match the tool. In this sense, Delphi is quite suitable for us.
PS Alexander and Maxim will respond under the Vsevolod account, adding their names to the top of the comment.
Alexander Lyulin - Lead Developer, "Garant"
Maxim Krylov - Project Manager, Garant
Attention, the information in the next paragraph is absolutely not advertising . None of the authors will discuss and even mention any software products in the context of their properties, functions, competitive advantages, emotional perception, appearing in the head from repeated pronouncing of names, etc. Below is a reference to the product and the company to determine the qualifications of invited experts. Simply put, who is interested in reading the opinion about the UML of a certain “washi puppkin” who developed the “best-xxx-dauloader-iksploit” program?
The company "Garant" is known to many Russian IT-specialists due to its key product - the IPO system GARANT. Most of the company's employees are engaged in software production, and the system itself has a 23-year history of development and has tens of millions of lines of code written in various programming languages. With such a scale, linguistic and technological heterogeneity, high production rates, very strict stability requirements, only the use of the most advanced technologies can ensure the quality of the evolving system. UML as a modeling tool is undoubtedly one of these “advanced” approaches, the use of which in Garant is characterized by a high level of automation with a significant share of strengthening its systemic role. Today, the leading developer of the GARANT system Alexander Lyulin and the project manager Maxim Krylov share their experience.
')
The proof of the lack of advertising - let's look at what is written above. We have just defined:
- the name of the company whose employees are experts;
- The site of the company;
- Company Profile;
- what product the company produces;
- technical parameters of the product (quantitative and qualitative), allowing to assess the scale of development;
- the degree of "penetration" of UML into the software production process.
The site of the company is given again not for advertising reasons. So does even wikipedia, which is the benchmark of "ad-free". The above paragraph serves to add publication a) completeness; b) responsibility to the readers.
If you (in a broad sense - people, companies, specialists, experts) do not agree with the authors, we will be glad to see references to your publications on a subject. If you need help with this, contact vsevolod.leonov@embarcadero.com.
Vsevolod : Tell us, was the use of UML originally adopted as one of the components of the development process?
Maxim : No, of course, when we came to Garant, it was simply not there yet. But, it seems, already in the 97th year, our young and talented colleague (although at that time we were all young) brought a floppy disk with one of the first UML modeling tools. From about this point, we can assume that the introduction of UML within the walls of the “Guarantor” has begun. However, before its use in our main projects, so to speak on an industrial scale, more years passed.
Alexander : Moreover, the use of UML has been introduced for a long time and in several stages. With the growth of our development and understanding that without this tool there is a risk of not coping with the increasingly complex structure of the code and the internal architecture of projects.
Vsevolod : Were there “ideological differences”? There are different coding styles, did it not turn out that “everyone has their own UML”? Or does the UML “comb all one size fits all”?
Alexander : Of course, there were differences. And it was precisely in the ideological basis of the introduction that there was a desire to "comb" everything and unify the existing approaches.
Maxim : By the time when the use of UML from the experiments of one or two enthusiasts passed into the design implementation stage, we already had a fairly clear understanding of what it is and why and how to make it so that there are no “different UMLs”.
Vsevolod : At what point was it decided to look towards UML?
Alexander : When it came to the realization that projects are complex. That many people are involved in them. What you need to somehow "negotiate". And that it is necessary to somehow "see" the overall architecture of the projects.
Maxim : For a long time, its use was limited to personal sketches for consumption by a narrow group of "initiates." At some point, they tried to start generating CORBA IDL from it. As a result, they came to the conclusion that this is almost impossible and they wrote their own simple generator. Actually, this was the point of no return. After that, UML was used in most projects, and most importantly, it was reborn into something much more than just a set of pictures, we will tell you more about this later. But at the beginning, yes - just as an opportunity to reach an agreement faster and more efficiently.
Vsevolod : Were there cases when it was not possible to agree even with the UML?
Maxim : In any team, there are situations when someone loses the desire to negotiate. Neither UML nor anything else will help here. But when people take a constructive position, having a universal language makes life much easier.
Alexander : UML is not a dogma and not a “universal pill”, but a means. But work has become really better. Because it became possible to simply “glance” throughout the system, quickly changing the scope of the review. Then we look at UseCase, then in 5 minutes we have already gone down "to bytes". Scaling is done very quickly. Let's say, like in Google Earth.
Vsevolod : Is the use of such techniques and just the need to "negotiate" an indicator that there are problems in the distribution of "areas of responsibility" in the code? Why negotiate and harmonize, if you can clearly distinguish between who develops what classes / methods and who uses them? I make the bolts, Vasya - nuts, and Zhora screw them two parts. What details? Yes, no matter what, we clearly divided the areas of responsibility. Why is this in software development not working?
Alexander : Up to a certain point, such a scheme worked with us. But I had to change roles. Replace others. And the complexity of the projects has increased.
Vsevolod : And how to understand that the project has already become "difficult"?
Maxim : It all depends on the number of bolt-nut-part chains, on the versatility of each nut, on the variability of the bolts and their manipulations. To write “hello, world” you do not need to negotiate with anyone and share areas of responsibility. No need for UML and OOP, SOAP, XML and “flexible” methodologies. It all starts with the growth of the project. At some point, it turns out that Vasya changed the thread diameter of his nuts, and Zhora can no longer screw them onto your bolt, and even worse, they jump off of them themselves, already somewhere later on. Or suddenly it turns out that at the end of the chain there is a new Masha, who with incredible difficulty spins back your nuts with bolts, and changes them to rivets that come from the next shop. These are all primitive examples, but accumulating, mixing, forming bizarre combinations, they create complexity, it is because of them that we lose the quality of both the process and the result.
The use of any notation, understandable to all participants in the process, reduces the number of such surprises. A hypothetical production with bolts and nuts would be impossible without drawings and documentation. But this is not enough either. To build an efficient conveyor you need machines, CNC robots. They unequivocally and without liberties interpret input documentation and issue a guaranteed result. Therefore, one UML does not bring as much benefit as the UML that you can feed to the “machine” and get 100% valid, debugged code at the output, which then in manual mode turn into the final product.
Vsevolod : How is the modeling process? Is this how the group of “interested comrades” is going to come together and are they all at the same time “pointing fingers at the diagram” and drawing it? Or there is a clear distinction - master-slave. Those. one draws - the rest take note?
Alexander : It happens and that. And going, and poked. Master-slave separation also happens. But these are rather “roles” rather than positions. The “circle of specialists” is the initial one. We first communicate verbally. Then we read the requirements. Then ask questions about them. We get answers to them. We draw a prototype. Somewhere we immediately determine the “circle of specialists”. More narrow. Or wider. We run solutions. We find "pitfalls in the TK" or contradictions with the "existing architecture." Further, the process is generally cyclical.
Maxim : We, as a rule, draw everything, or almost everything. Depends on the project and specifics, of course. But theoretically, the “leading” model (namely, “no”) is “driven”, it seems to me more correct and viable, since allows you to best use the strengths of some and level the shortcomings of others. Those who are better "sharpened" to design, draw a model. Those who feel more confident in the implementation of algorithms generate code from them and fill it with business logic.
Vsevolod : What problems did you initially want to solve with UML?
Maxim : Initially, at the level of experimentation, just as a way to structure your thoughts. The very first experiments included only drawing classes and connections, there was no clearly articulated practical use, rather we liked it aesthetically, it was great and interesting, as if we were drawing illustrations to the books of the "classics." But by the time of the actual implementation, the main problem that I wanted to solve was the insufficient speed and quality of the manual coding of the “routine” code. Those. at the head of the corner was code generation.
Alexander : The complexity of taking connections. Their "imperceptibility" in the "bare" code. Design and coding rules. Using template solutions. Again, UML was seen as an opportunity to “agree” more formally.
Vsevolod : And why exactly UML?
Maxim : At that time, there simply was no alternative, UML was the only universal graphic notation that rather comprehensively described the subject area and had instrumental support, even with some kind of code generation. Therefore, we can say that it happened historically. And later, when we realized that it was not so important “how” to draw, how much “what and why”, then there was simply no point in changing the UML to something else (for example, DOT). By and large, UML for us is only a specific notation familiar to the majority, “the shape of arrows and small squares”, it is not important, but the principle of action, i.e. what we do with it and how.
Vsevolod : Classics are not deceived? Or did you have your own vision of the place and role of UML?
Maxim : The classics set the basis, and we used it. And they used it as the classics implied, as it seems to us, but they did not fully formulate it. First, the penetration of the model was not determined. Yes, everyone heard about MDA, but how many have seen it? We “fixed” this, for example, one of our versions of the metamodel implied the beginning of the system design from the description of the “problems” in the UML that it had to solve, of which the “possibilities” were born, of them the “precedents”, etc. to "servants", to "bytes". All this was one holistic model in which it was possible to say about each “byte” which user problem it solves. And for each "problem" - get all the source code associated with it.
Alexander : This is a similarity to the "dolls" and "assembly drawings." And at different levels, which can be arbitrarily many, and not just Class View, Deployment View, like the "classics". Drawing "enterprise level" and drawing "level containers in the style of STL." UML allows you to "logarithm" the complexity of the problem. For me personally, designing / coding / debugging / testing a fairly large UseCase is not much more complicated than debugging a "list of integers". Another thing is that debugging the “list of integers” can sometimes take months.
And so - "assembly drawings", matryoshka and "nomenclature of chips". These are the cornerstones. On the one hand, they “logarithmize” the complexity, and on the other hand, they allow the system to “quickly change the scale”.
And yet, the “classics” did not pay enough attention to stereotypes. And here it is - the cornerstone. << Stereotype >> is just an element of architecture and meta-model. The stereotype affects code generation methods and the final code.
Vsevolod : Let's discuss the concept of "stereotype"?
Maxim : The main problem of using UML in “classical” tools is that code generation is rigidly connected with a predefined static metamodel. You cannot change one or the other. Neither change, nor expand, nor change the rules or set new specific ones. The main thing is that the classics did not reveal to the public, and the “classical tools” did not realize, this is the potential of UML precisely from the point of view of meta-design. Creating your own metamodels with their own specific code generation. And here the concept of “stereotype”, which Alexander speaks of, begins to play a key role. The stereotype allows us to define a group of specific metaclasses with arbitrary code generation associated with them. In fact, with the help of stereotypes, you create an arbitrary meta-model, which automatically becomes your own DSL, transforming squares into code, according to any rules you implement. It is this aspect that allowed UML to become for us not only a tool for drawing pictures, but something that really simplifies the development process, sometimes making truly impossible things possible. And as it seems to us, the absence of this or a similar mechanism in commercial tools, and now leads to the fact that UML cease to use and look at it as the "fifth leg".
Alexander : I will add that UML has its own “meta-model,” drawn on UML itself. It has the concept of "class element". These are Class, Category, Operation, Attribute, Dependency, Port, UseCase, Actor, etc. From these classes are constructed "final diagrams." And code generation is usually tied in time for a class. But this is where the “classics” mistake is - there is neither flexibility nor extensibility. We have risen to a higher level. Actually, the UML describes our meta-meta-model, i.e. rules of formation of rules. Next, we define the meta-model, introducing into it any concepts we need. For example, we can determine for Delphi the possibility of multiple inheritance. Then we attach to this metamodel the rules for converting its elements into code (or any other artifacts, for example, into documentation, auxiliary files, etc.). In the example with multiple inheritance, this may be a transformation into a single inheritance plus aggregation, but at the same time, so that from the programmer’s point of view it will look like 100% inheritance. Finally, we create real models of our subject domain, but already by operating not with the fact that we were initially offered “classics”, but with all that arsenal that we ourselves invented at the meta level and we get from them ready-made code of arbitrary complexity.
Vsevolod : Tell me in detail, how did all this develop in your country - stepwise?
Maxim : At the beginning of work on the new version of “Guarantor” (“Platform F1”), we faced a problem: the server was developed in C ++ / CORBA, and the client was a shell in Delphi. For some reason, we couldn’t use it on a shell that is native to Delphi, VisiBroker, and we did not see the server side of the sane alternative. Then a solution was proposed to start an “adapter” (dll in C ++) on the client, which would work with the server using CORBA, additionally performing some internal transformations, caching and even containing some part of the client logic, while giving everything that is needed shell on Delphi in a clear and convenient form. I think it’s not worth saying that such a system as “Garant”, the range of interfaces through which the adapter and the shell interacted, quickly became rampant. Now imagine what is any object interface, between dll in C ++ and delphi? In short, this is “hell”: different type transfer rules, different memory management, lack of description control in the exported header and in Delphi, when absolutely any discrepancy leads to completely unpredictable results and super-nontrivial debugging, etc.
Taking into account, the number of interfaces that were and still promised to be, as well as the degree of their variability, we quickly realized that the task is in fact not feasible. That's actually at this moment for the first time and we used the UML "by purpose". We already had our own generator for CORBA IDL, and it has already been built on the principle of patterns describing a metamodel and code generation based on it. Actually, all that was needed was to define a new metamodel for adapter interfaces and, on its basis, describe code generation, which would yield 100% consistent descriptions for both C ++ and Delphi, taking into account all the features and subtleties.
In the end, everything was done fairly quickly, and it began to bring results. C ++ programmers who wrote the adapter no longer thought at all that something, Delphi programmers had to export somewhere, worked with the adapter as if it were written entirely in Delphi, according to their usual principles before naming methods and properties. Everyone simply drew the necessary interfaces on the model, generated the code and worked in a “native” way for both languages. By and large, this was the first success story, after which we actively began to develop the idea of ​​pattern generation and metamodeling. And in many directions (though not in all) achieved impressive results.
Vsevolod : How does a new person get involved in the development team? Is he given a heap of diagrams "under his breath?" Or does he begin with elementary operations that do not require “to see the system as a whole”?
Alexander : There is a list of non-key or secondary features. For starters - give them. But not very much. In order not to "discourage" routine. We look, as is involved. Along the way, we talk about the "infrastructure" and its own components. We consult orally and in writing. There is also a set of documentation that we recommend reading. Then, gradually, “real” tasks, model and everything else. Something like this. If there are “separate large tasks” on the agenda, then we start with them.
Vsevolod : Everyone knows that new approaches and methods are not always positively perceived by all team members. Were there any cases of active or passive opposition?
Maxim : Many people perceived “our UML” as an invasion of their privacy, a restriction on their freedom of action. After all, before that, everyone programmed as he wanted. There appeared some rules and restrictions even at the design level of implementation, and not just interfaces. Probably, we bent the stick a little and introduced too many restrictions. But this is a very powerful tool, you do not just define the metamodel and code generation, you can also describe arbitrary “constraints” associated with it. For example, from “it is impossible to transfer collections as a result by reference”, or “a method should not have more than 5 parameters”, to control architectural layers, and “traceability” to requirements. Of course, not all were in agreement with all the restrictions, and this frightened and repelled many of them.
Vsevolod : How did the implementation process go - was the reverse design carried out?
Alexander : Not implemented. At that moment there simply were no good tools. And now I have come to the deep conviction that this is not necessary. Sincein the process of “drawing an existing code”, it is rethought, ideas and ways of its refactoring appear (you shouldn’t just do refactoring in the process of drawing, it should go a separate step), and design / coding patterns are applied. No “automaton” will do this. All attempts to transfer something to the model of all kinds of “automata” looked depressing.
Maksim: Already at the stage of creating a template generator, it became clear to us: automatic reverse engineering is “evil”. And not because it is practically impossible to conduct it at a sufficiently high level, even if you have a primitive basic metamodel containing only native abstractions for the language, not to mention more complex specific metamodels for which, I think, it is impossible to make an automatic reverse even theoretically. The key point was another - the presence of a reverse breaks the very idea of ​​using UML for code generation. Our task was to learn ourselves and to teach others to think not in codes, but in abstractions, if possible to code not attached. This is a separate complex topic, and it was extremely important for us. Therefore, our generator by its architecture and by the way it generated the code, eliminated and at the same time made unnecessary the possibility of reverse,as such.
Vsevolod : We will take a step "back" to the PLO. Can you say that UML helps refactor?
Alexander : Yes. Promotes. But, I can say that you should not mix refactoring with the “implementation of requirements”. They need to "spread in time." And think about tests.
Maxim : Again, looking at "what" UML. If you just draw "dead" diagrams, it will not help much, although it may give a small positive effect. If you have a metamodel and patterned code generation, as in our case, then the refactoring capabilities are at a completely new level.
Vsevolod: Why do you have to refactor object code? Is it a lack of experience? Or are there objective reasons for the evolution of the system as a whole? Or just the natural "growth in width and depth" of the system?
Alexander : I think that all of the reasons listed take place here. Refactoring is a separate big topic. But refactoring helps couple - model + tests.
The model restricts the developer "from above", allowing you to remain "within the framework of the Architecture" (those metamodels) or to correctly modify it. And tests limit the developer “from below” allowing him to remain within the framework of the TK and regressing the errors already found. Those.the model, let's say, is the “tutor”, and the tests are the “validator”. Although there are colleagues to whom I said this phrase, and they took it with skepticism. Saying something like “no one will forbid a Krivoruk programmer to make business logic in View, and to make View elements in business logic”. And they are right. And usually the skeptics are just "straight-handed" programmers.
Why do you need refactoring? It is not a secret for anyone that the entire IT industry in the whole world has not learned how to plan development terms “in the sense of responsibility”. And if so, the dates begin to tighten. No matter how competent analysis at the initial stage was made, life is more difficult. And then decisions begin to be made "in the style of XP." What in my opinion, in general, is correct. “I will think about it tomorrow,” said one heroine. And for the time being, these decisions "have the right to life."
It often happens that the requirements for an already existing system change “explosively” or “avalanche-like”. And it becomes “cramped” within the framework of the architecture, which, although “flexible”, but not “rubber”. Here too - it is necessary to do refactoring. That the architecture "did not collapse".
Vsevolod : «», UML, DSL, ?
: Here is a real life example. We have defined interface factories on the metamodel - a method on an interface with a special stereotype that turns the code into a set of other interfaces and classes that implement several different patterns, which ultimately allows you to quite flexibly manage the implementation of interfaces with interfaces in a runtime. displace them, etc. I repeat, all this is one method, drawn on the model. At some point, when it has been used for a couple of years, and there were not a dozen or two of such factories, we suddenly realized that there is a nonoptimality in the code that affects performance. But to eliminate it, you need to change the structure of these generated classes. It is not easy to replace “a” with “b” with a search for the entire project, namely, to change the structure. In our case, it took a few hours toto rewrite the generation pattern and rewrite all projects. And if all this was written by hand, then in a hundred different places the implementation of these several patterns would be “pushed away”, a little different everywhere, and to change, and then debug it all - it would not be real in two hours or two months .
Alexander : In addition, it is easier for me to “refactor” the diagram, and not the code. It is easier to move “squares” from one place to another on models rather than pieces of code and files between folders. At the same time, it is still necessary to “properly maintain the architectural layers” with “hands”. And the model - “thinks for me.” She is a tutor. She will not let me make a "knowingly wrong decision." Or this decision will be at least deliberate.
Vsevolod : Is it possible to measure the quality of refactoring? No need to re-refactor?
Alexander: I'm afraid this is not a criterion. Although if, of course, we managed to achieve the absence of such a need, then refactoring is probably perfect. Another thing is that I did not see the code / architecture that would be perfect. If something is perfect “from above,” then it is imperfect “from below.” Or vice versa, “from below” is an ideal code, and “from above” - imperfect architectural solutions.
Vsevolod : We often talk about refactoring, and many perceive it negatively. For example, "everything worked, but then we did refactoring." Can we say that when using UML-modeling codes initially became a ray, and refactoring became less common?
Maksim: If everything works, and no external changes occur, then you do not need to do refactoring. Refactoring is not an end in itself, it is a way to achieve the goal more quickly and accurately, not allowing the code to turn into a “Russian salad”. The use of UML with code generation, even in the simplest version, automatically structures the code immediately. So, of course, yes.
Vsevolod : A painful question is the synchronization of UML diagrams and program code. Is 100% compliance achieved?
Alexander : Achieved. Due to the fact that there is 100% code generation from model to code. While it was not, I myself was a great opponent of modeling. I considered drawing diagrams as “monkey labor”.
MaksimA: Yes, due to the fact that there is no reverse, synchronization is always one way. And past it you will not pass.
Vsevolod : Ie Is code generation an essential condition for the effective implementation of UML in the development process?
Alexander : Of course. Moreover, if there is no code generation, and there is no constant generation, then at some point the diagram starts to be “just a picture”. She "foul." She is about nothing.
And of course, as we have said, code generation allows you to "encode" the code, I apologize for the tautology - much faster. Believe me, the above examples have already been cited, and I still have a million of them.
Maksim: I would say categorically, code generation is the key point of using UML. At least for us. Understand what the thing is, I will now say a strange thing that runs counter to the topic of our discussion: we do not use UML at all in the classical sense.
Vsevolod : Well, “arrived”, explain what you mean?
Maksim: Do not worry, I certainly exaggerate a little. As I have already hinted above, UML for us is only a form of “squares”, a specific graphical notation and nothing more. We took it as a set of primitives in a graphic editor, and built something substantially larger from them. The templates we talked about above allow us to describe any metamodel in terms of these UML primitives, Alexander already listed them above, “Class”, “Category”, “Communication”, etc. And as a result, to get new terms, new primitives, already a level higher and, moreover, recursively, if necessary, using which, a specific designer or programmer will create a specific model and receive code from it. Those. in fact, templates are what form a particular DSL and compile a model drawn on it into code, and UML is just a way of drawing this model. Those.a person, even well acquainted with the classic UML, may not immediately "enter" what he sees drawn with us.
Vsevolod : Are the “time lost” justifications for creating code in graphic notation increasing its quality?
Alexander : From my point of view, they are justified. Due to the possibility of stereotypes of a higher level. As soon as we see that the design decisions begin to repeat. Moreover, the model affects the development framework, and the framework affects the model. Well, in the presence of a model (and tests), refactoring moves to a completely different level of quality, as mentioned above.
Maksim: Alexander said about high-level stereotypes, this is a separate very important topic, and this is the most powerful mechanism that we now know. This is what allows turning atoms into mollecules, mollecules into alloys, parts, aggregates and, finally, into a finished product.
Vsevolod : You mentioned tests in the context of refactoring. Does this mean that in general, without tests, there is nothing to think about refactoring, and without refactoring and modeling is not particularly necessary?
Alexander: In my opinion, it is better, of course, first to test, and then UML, modeling, code generation. But here it has historically been the opposite. But I would certainly now prefer tests first. We are not "just thinking about tests." We know what they are. That they "will show errors tomorrow." And show. But of course - “we are thinking about tests.” We are writing "proactive" tests. We have “regression tests”. There are tests that test requirements. And they allow refactoring without much damage to quality.
Maxim : I do not agree with Alexander, it seems to me that these are complementary things, and where to begin is not so important. Rather, it should be determined by the internal culture and preferences of the team. I would have started all the same with modeling, in the end, tests can and should also be generated and not written by hand.
Vsevolod : Alexander, as I understood, initially you were an opponent of UML? Looking back (perhaps with a smile), is it possible to say that you thought this way: “why do I need UML, do I control my code anyway?”
Alexander : It was just me personally who, long ago, realized that “there are problems” . But without code generation and constant synchronization with the model, I did not understand how UML can personally help me. Now, I understand and use it every day, although it is certainly not easy for UML, as we have said above.
Vsevolod : Has “your UML” become another way to document software code?
Alexander : Yes, of course. Moreover, all our models are integrated into a common hypertext knowledge base. It also contains bug-tracking and requirements.
Maksim: ... and much more, that is our know-how. By the way, the integration is also built on the same templates: the html for the base is generated from the model, like the source code, and automatically placed on the server.
Vsevolod : In what form are UML models integrated? Not in the form of the same pictures!
Alexander : In the form of pictures with hyperlinks and explanatory documentation. But from the picture you can always go to the real diagram in the tool to work with UML.
Maxim : and vice versa, and also the changing tasks and commits to the repository are attached to them automatically.
Vsevolod : Are UML diagrams used to interact with non-programmers?
MaksimA: At the beginning of implementation, we tried to use UML for interaction. All requirements were designed as UseCase and Sequence diagrams. In the most understandable, as it seemed to us, for a non-specialist form. The first version of the F1 system, our colleagues, lawyers and marketers who set the task, honestly tried to read from the diagrams, and they even got it. But ..., let's say, the practice has not taken root.
Alexander : Still, not techies (not by education, but by vocation), do not really like all sorts of formal languages. They subconsciously easier in Russian literary, not UML. This is from the category of psychology.
Vsevolod : What UML-diagrams and in what volume are used?
Alexander : First of all, class diagrams and UseCases.
Vsevolod: Do you find other charts less useful? For example, are there enough “brains” of programmers to do without the diagram of “objects”?
Maxim : No. Sometimes we use state diagrams, describe them, and generate state machine code. But it is very rare.The use of finite automata, at the formal level, also requires a certain sharpening of the brain. In some places, sequence is used, but only as an illustration, i.e. as a “dead chart”, now nothing is generated from them, which means, as Alexander said above, her life time is very short.
Alexander : Perhaps, the Sequence is even more useful, just until you reach out to do the appropriate code generation for them. A diagram of "objects" is just those very chains of SAX-filters. When we operate not with classes, but with their instances.
Vsevolod : The classic RAD approach clamps the programmer into a fairly narrow frame. Database, interface, form, components, events, response procedures. How did you manage to expand this framework with UML?
Alexander: UML "pinches" in the framework of the "meta-model", which is developed. But this is partly sought. Compared to RAD, impurities and AOP elements are used much more actively. As well as a declarative, rather than an imperative approach to some parts of the projects. Those.on the model, a “data model” is drawn to the maximum divorced from what it should physically turn into, and it is transformed into an “active code” with the help of a code generator. For example, the "scheme of the document" or a set of "settings" of the project. All sorts of SAX filter chains, etc.
Maxim : It is important that he pinches where you decide. The metamadel does not impose any rules on its author; it imposes them only on the model and on the one who will create it. In one place you pinch, and in the other - give the unique flexibility and speed of the lego-designer.
Vsevolod : How does the use of models affect the architecture of the application and the structure of the program code?
Alexander: It's certainly not just models. The point is "brain hygiene." But the correct use of modeling enhances it. And, yes, the model is an assistant. I will make a reservation, if there is no desire to improve, then no models will help. As, however, and any other practice.
And the UML architecture and modeling have a positive effect :-) Logical layers appear. Parasitic cyclic dependences disappear, and so on.
Vsevolod : We will work in the "blitz" mode. When do you think you do not need to apply UML and modeling?
Alexander : For research and other studies. For the project "for two or three months," which then most likely will not have to be supported.
Maksim: If UML is used only for drawing, I agree with Alexander, but if for metamodeling and code generation, then I think that it is possible and necessary to use it always, especially if you are used to doing it. Of course, if this is not "hello world". Although it will probably be easier for me to generate “hello world”, at least I don’t need to remember how to make a new project in IDE :), because projects are also generated here.
Vsevolod : At what point of development and on what grounds can we say that the way you use UML is effective?
Alexander : It is enough to compare the time of writing some functionality "manually" or your way.
Maksim: The only thing is that there are still technical limitations of a specific instrument; sometimes they can have a very negative effect.
Vsevolod : How to gradually begin to introduce modeling into the production process?
Alexander : You can start at any time. The main thing is not to immediately try to “embrace the immense”.
Vsevolod : What part of the tasks can be closely integrated with UML and code generation, and what can be left "as is"?
Maxim : you can leave some not very structured, unique algorithms, something, in which there is no template, reuse, some kind of system that can be formalized and reproduced.
Alexander: I have not all the most transferred to the model. I first of all translate either new classes / entities. Or those that affect the process of alterations. Or those that "refactor."
Vsevolod : Probably, other approaches were tried. Is there an alternative to UML in the modern world of software development?
Maxim : For us, in the form in which we use it, it is not. But I have already said above that it is generally not very important in what concrete way to draw arrows with squares. The main thing that we do with it, and not what it looks like.
Alexander: I will clarify that in fact there are many alternatives to UML, and precisely because for us this is simply a way of describing a model. You can take any other graphical notation that has in the basis of the concepts we need, and use it. You can describe your own. It is possible in general, and I actively think about it, go to the text description of the model, i.e. create another DSL. There are many options and they can be combined.
Vsevolod : Are there any limits to the possibilities of your approach?
Maxim : as soon as you start to create your own meta-models, any restrictions disappear, you may lack only imagination and the ability to see the private in general.
Vsevolod : Is everything so wonderful, and there are no problems whatsoever? I want to shout in the best theatrical traditions: “I do not believe”!
Alexander : Of course, there is. First of all, the limitations of the tool. Insufficient generation rate on large models. Non-optimal UML interface editor, etc.
Maxim : the problem is not ideological, but technological. We gradually grow out of the tools that have been made for a long time and for many years retained their relevance. The generator requires updating, making modifications. But this is probably not a “problem”, but a “task”.
We also use a separate package as a UML scoop. Yes, it is already part of our "pipeline", but it would not hurt him to improve, update.
Vsevolod : your plans?
Alexander : Write your entire tool - model editor. So to say, to do "work on the bugs" in existing ones.
Maxim : And with that - cross-platform. In general, in this direction there are also a lot of ideas on how to make the modeling process even more efficient.
Vsevolod : In the next article we will discuss DSL?
Maxim : Yes, of course.
Alexander : With pleasure!
Vsevolod : As an employee of Embarcadero, using my official position, I ask ... Do you use Delphi?
Alexander: Yes, I use Delphi in development. I know about the contradictions between RAD and UML, and I try to use the strengths of each technology and achieve significant synergy. I do not use Delphi as a pure RAD tool for placing buttons on forms. This is one of the components of a rather complex technological chain. Now we are in the process of transition to Delphi XE4. There is a need for 64-bits.
Maksim: I grew up in C ++, but in a highly heterogeneous environment, in the projects in which I participated, Delphi, C ++, python, java, etc. were used at the same time, so I never supported holivars what is “better” - every time you wear a buckle. As a project manager, the main thing for me is the effectiveness of the solution as a whole. Our company uses Delphi for a long time and intensively, the main thing is to know the strengths and weaknesses of each tool, its potential, to correctly make on the basis of this decision, to build a technological cycle, to select professionals so that they would most closely match the tool. In this sense, Delphi is quite suitable for us.
PS Alexander and Maxim will respond under the Vsevolod account, adding their names to the top of the comment.
Source: https://habr.com/ru/post/188604/
All Articles