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 non-promotional . None of the authors will discuss or even mention any software products in the context of their properties, functions, competitive advantages, emotional perception that appears in the head from repeated pronouncing of names etc. Below is a mention of the product and the company to determine the qualifications of invited experts. Simply put, who is interested in reading the opinion about UML of a certain “Vasya Pupkin” who developed the “best-xxx-dauloader-iksployt” program?

Company"Guarantor"It is known to many Russian IT specialists due to its key product - the IPO GARANT system. 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 requirements for stability, only the use of the most advanced technologies can ensure the quality of an evolving system. UML as a modeling tool, undoubtedly, is one of such “advanced” approaches, the application of which at Garant is characterized by a high level of automation with a significant share of strengthening its system role.

Proof of the lack of advertising - let's analyze what is written above. We just determined:
  • name of the company whose experts are employees;
  • The site of the company;
  • Company Profile;
  • what product the company produces;
  • technical parameters of the product (quantitative and qualitative), allowing to evaluate the scale of development;
  • the degree to which UML penetrates the software production process.


The company’s website is again not for advertising reasons. Even wikipedia, which is the standard of “ad-free”, does that. The above paragraph serves to give the publication a) completeness; b) responsibility to readers.

If you (in the broad sense - people, companies, specialists, experts) do not agree with the authors, we will be glad to see links to your publications on the subject. If you need help with this, please contact vsevolod.leonov@embarcadero.com.


Vsevolod : Tell us, was the use of UML originally accepted as one of the components of the development process?

Maksim: No, of course, when we arrived at the Guarantor, he was simply not there. But it seems that already in the year 97, our young and talented colleague (although we were all young at that time) brought a floppy disk with one of the first UML modeling tools. Around this point, we can assume that the introduction of UML within the walls of the "Guarantor" has begun. However, years passed before its use in our main projects, so to speak on an industrial scale.

Alexander : Moreover, the use of UML has been implemented for a long time and in several stages. As our development grows and we understand that without this tool there is a risk of not being able to cope with the increasingly complex code structure and internal architecture of projects.

Vsevolod: Was there no “ideological disagreement”? There are different coding styles, didn’t it work out that “everyone has their own UML”? Or is UML “combing everyone under one comb”?

Alexander : Of course, there were disagreements. And it was precisely in the ideological basis of the introduction that there was a desire to “comb” everything and unify existing approaches.

Maxim : By the time when the use of UML from the experiments of one or two enthusiasts moved to the stage of project implementation, we already had a pretty clear understanding of what it was and why and how to make it so that there were no “different UMLs”.

Vsevolod : At what point was the decision made to look towards UML?

Alexander: When it became clear that the projects were complex. That a lot of people are involved in them. What you need to somehow "negotiate." And that we need 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 a CORBA IDL from it. As a result, they came to the conclusion that it was almost impossible and wrote their own simple generator. Actually, this was the point of no return. After that, UML began to be used in most projects, and most importantly, it degenerated into something much more than just a set of pictures, we will talk about this later in more detail. But in the beginning, yes - just as an opportunity to negotiate faster and more efficiently.



Vsevolod: Were there cases when it was not possible to agree even with UML?

Maxim : In any teams 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, the presence of a universal language makes life very easy.

Alexander : UML is not a dogma or a “universal pill”, but a means. But work has become really better. Because it became possible to simply “glance” over the entire system, quickly changing the scope of the review. Then we look at UseCase, then after 5 minutes we have already gone down to bytes. Scaling is very fast. Say, as in Google Earth.

Vsevolod: Is not 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 agree, if it is possible to clearly distinguish who develops which classes / methods and who uses them? I make bolts, Vasya makes nuts, and Zhora makes two parts with them. What details? No matter, we clearly divided the areas of responsibility. Why doesn't this work in software development?

Alexander : Until some point, such a scheme worked for us. But I had to change roles. Replace others. And the complexity of the projects has increased.

Vsevolod : And how do you understand that the project has already become "complex"?

Maksim: It all depends on the number of bolt-nut-part chains, the versatility of each nut, the variability of the bolts and how to handle them. To write “hello, world” you do not need to negotiate with anyone and share responsibility. No need 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 diameter of the thread of his nuts, and Zhora can no longer screw them onto your bolt, and even worse they jump off them, already somewhere later. Or suddenly it turns out that at the end of the chain is a brand new Masha, who with incredible difficulty unscrews your nuts and bolts back, and exchanges them for rivets that come from a neighboring workshop. These are all primitive examples, but accumulating, mixing, forming fancy combinations, they create complexity, it is because of them that we lose quality,

The use of any notation that is understandable to all participants in the process reduces the number of such surprises. Hypothetical manufacturing with bolts and nuts would not have been possible without drawings and documentation. But this is also not enough. To build an efficient conveyor, you need CNC machines and robots. They unambiguously and without liberties interpret the input documentation and give a guaranteed result. Therefore, UML alone does not bring as much benefit as UML that you can feed to the “machine” and get 100% valid, debugged code, which you then turn into the final product in manual mode.

Vsevolod: How is the simulation process? Is this how a group of “interested comrades” gathers and all at the same time “point fingers at a chart” and draw it up? Or there is a clear distinction - master-followers. Those. one draws - the others take note?

Alexander : It happens. And they gather and poke. Master-slave separation also happens. But this is more a "role" rather than a post. The "circle of specialists" is initial - there is some kind. First we communicate verbally. Then we read the requirements. Then we ask questions about them. We get answers to them. We draw a prototype. Somewhere right there we define the "circle of specialists." More narrow. Or wider. We run in solutions. We find “pitfalls in TK” or contradictions with “existing architecture”. Further, the process is generally cyclical.

Maksim: We, as a rule, draw everything, well, or almost everything. Depends on the project and the specifics, of course. But theoretically, the “leading” model (namely “ie”) - “led”, seems to me more correct and viable, because allows you to optimally use the strengths of some and offset the disadvantages of others. Those who are better "ground" on design draw models. 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 using UML?

Maksim: Initially still at the level of experiments, just as a way to structure your thoughts. The very first experiments included only drawing classes and connections, there was no clearly formulated practical benefit in it, rather we liked it aesthetically, it was cool and interesting, as if we were drawing illustrations for 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 manual coding of the "routine" code. Those. at the forefront was code generation.

Alexander : The complexity of the relationship. Their "imperceptibility" in the "bare" code. Design and coding rules. Use of template solutions. Again, UML was seen as an opportunity to “agree” more formally.

Vsevolod : And why exactly UML?

Maksim: At that time there simply were no alternatives, UML was the only universal graphical notation that comprehensively described the subject area and had instrumental support, even with some kind of code generation. Therefore, we can say that this happened historically. And later, when we realized that it was not so important “how” to draw, how much “what and why”, then changing the UML to something else (for example, DOT) simply did not make sense. By and large, UML is for us only a specific notation familiar to the majority, “the shape of arrows and squares”, it is not important, but the principle of action, that is, what we do and how.

Vsevolod : Classics are not deceived? Or do you have your own vision of the place and role of UML?

Maksim: The classics set the basis, and we used it. And used as the classics implied, as it seems to us, but not fully formulated. First, the penetration of the model was not determined. Yes, everyone heard about the MDA, but how many saw it? We “fixed” this, for example, one of our versions of the metamodel implied starting the system design with a description of the “problems” in UML that it should solve, “opportunities” should be born from them, “precedents” from them, etc. to “sideboards”, 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 kind of “nested doll” and “assembly drawings”. Moreover, at different levels, which can be arbitrarily many, and not just Class View, Deployment View, as in the "classics". An “enterprise-level” drawing and an “STL-style container level” drawing. UML allows you to "logarithm" the complexity of the task. For me personally, designing / coding / debugging / testing a sufficiently large UseCase is not much more difficult than debugging a “list of integers”. Another thing is that debugging the “list of integers” can sometimes take months.
And so - “assembly drawings”, nested doll and “nomenclature of microcircuits”. These are the cornerstones. On the one hand, they “logarithm” complexity, and on the other hand, they allow “quickly changing the scale” of system consideration.
And yet, the "classics" did not pay due attention to "stereotypes". And with us this is the cornerstone. << Stereotype >> is just an element of architecture and a meta-model. The stereotype affects the methods of code generation and the final code.

Vsevolod : Let's discuss the concept of “stereotype”?

Maksim: The main problem with using UML in “classic” tools is that code generation is tightly coupled with a predefined static metamodel. You cannot change either one or the other. Neither change, nor expand, nor change the rules or set new specific ones. The main thing is that the classics were not disclosed to the general public, and the “classical tools” were not realized, this is the potential of UML precisely from the point of view of meta-construction. Creating your own metamodels with their own specific code generation. And here the concept of “stereotype”, about which Alexander speaks, begins to play a key role. The stereotype allows us to define a group of specific metaclasses with binding arbitrary code generation to them. In fact, with the help of stereotypes, you form an arbitrary meta-model that automatically becomes your own DSL, transforming squares into code, by any rules that you implement. It was this aspect that allowed UML to become for us not just a tool for drawing pictures, but one that really simplifies the development process, sometimes making the truly impossible impossible. And it seems to us that the absence of this or a similar mechanism in commercial tools now leads to the fact that UML is no longer used and look at it as the “fifth leg”.

Alexander: I’ll add, UML has its own “meta-model” drawn on UML itself. It has the concept of an “element class”. These are Class, Category, Operation, Attribute, Dependency, Port, UseCase, Actor, etc. From these classes “finite diagrams” are built. And code generation is usually tied to just the class. But this is the mistake of the "classics" - there is neither flexibility nor extensibility. We have risen, as it were, to a level higher. UML itself describes a meta-meta-model, i.e. rules for the formation of rules. Next, we define a meta-model by 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 can be a transformation into single inheritance plus aggregation, but at the same time so that from the point of view of the programmer it will look exactly like 100% inheritance. Finally, we are creating real models of our subject area, but already operating not on what the “classics” initially offered us, but on the whole arsenal that we ourselves invented at the meta level and get ready-made code of any complexity from them.

Vsevolod : Tell me in detail how it all developed for you - stepwise?

Maksim: At the beginning of work on the new version of “Guarantor” (“F1 Platform”), we faced a problem: the server was developed in C ++ / CORBA, and the client was a shell in Delphi. For certain reasons, we could not use VisiBroker on the shell native to Delphi, but we did not see a sane alternative for the server side. Then a solution was proposed, to create an “adapter” (dll in C ++) on the client that 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 you need Delphi shell in an understandable and convenient way. I think it’s not worth saying that such a system as “Garant”, the nomenclature of the interfaces through which the adapter and the shell interacted, quickly acquired alarming proportions. Now imagine what is any object interface between dlls in C ++ and delphi? In short, this is “real 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.

Given 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 was essentially not feasible. Actually, at this moment, for the first time, we used UML “for its intended purpose”. We already had our own generator for CORBA IDL, and it was already built on the principle of templates describing the metamodel and code generation based on it. Actually, all that was needed was to define a new metamodel for adapter interfaces and describe code generation based on it, the output of which would produce 100% consistent descriptions for both C ++ and Delphi, taking into account all the features and subtleties.

As a result, everything was done quickly enough, and began to bring results. The C ++ programmers who wrote the adapter no longer thought at all that they needed to export somewhere. Programmers in Delphi worked with the adapter as if it were written entirely in Delphi, according to their usual principles, right up to before naming methods and properties. All just 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 successful story, after which we actively began to develop the idea of ​​template generation and metamodeling. And in many areas (though not in all) they have achieved impressive results.

Vsevolod: How is a new person involved in the development team? He is given a “heap” of diagrams? Or does he start with elementary operations that do not require “seeing the whole system”?

Alexander : There is a list of non-key or minor features. For starters - give them. But not very much. In order not to “discourage” the routine. We look how it is drawn. Along the way, talk about the "infrastructure" and its own components. We advise orally and in writing. There is also a set of documentation that we recommend reading. Then, gradually, the “real” tasks, the model and everything else. Something like this. If there are “separate big 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. Have there been any cases of active or passive resistance?

Maksim: Many perceived “our UML” as an invasion of their personal lives, restriction of freedom of action. After all, before that, everyone programmed as they wanted. Some rules and restrictions appeared even at the level of designing an implementation, and not just interfaces. Perhaps we went a little too far and introduced too many restrictions. But this is a very powerful tool, you do not just define a metamodel and code generation, you can also describe arbitrary "constants" associated with it. For example, from “you cannot pass 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, far from all agreed with all the restrictions, many of them both frightened and pushed away.

Vsevolod: How did the implementation process go - did you reverse engineer it?

Alexander : Not done. At that moment, there were simply no good tools. And now I have come to the deep conviction that this is not necessary. Because in the process of “drawing an existing code”, it is rethought, ideas and ways of refactoring it appear (you should not just do refacoring in the drawing process, it should go as a separate stage), and design / coding templates are applied. No “machine” will do this. All attempts to transfer something to a model of any kind by “automatic machines” looked depressing.

Maksim: Already at the stage of creating the 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 quality level, even if you have a primitive basic metamodel containing only abstractions native to the language, not to mention more complex specific metamodels for which, I think, it is impossible to do automatic reverse even theoretically. The key point was different - the presence of a reverse breaks the very idea of ​​using UML for code generation. Our task was to learn for ourselves and teach others to think not in codes, but in abstractions, if possible not related to code. This is a separate complex topic, and it was extremely important for us. Therefore, our generator, in its architecture and in the way it generated the code, excluded and at the same time made it unnecessary to reverse,

Vsevolod : Let's take a step "back" to the OOP. Can you say that UML promotes refactoring?

Alexander : Yes. Promotes. But, I can say that you should not mix refactoring with the "implementation of requirements." They must be "spread in time." And think about the tests.

Maxim : Again, looking at what UML. If you simply draw “dead” diagrams, this will not help much, although it may have a small positive effect. If you have a metamodel and boilerplate code generation, as in our case, then refactoring capabilities are at a whole new level.

Vsevolod: Why do I have to refactor object code? Is this a lack of experience? Or objective reasons due to the evolution of the system as a whole? Or just the natural “growth in breadth and depth" of the system?

Alexander : I think that all of the above reasons apply here. Refactoring is a separate big topic. But steam - model + tests helps refactoring.

The model limits the developer "from above", allowing you to stay "within the Architecture" (those metamodels) or competently modify it. And tests limit the developer from the bottom, allowing him to remain within the framework of the TOR and regress already found errors. Those. the model, let’s say, is “tutor,” and the tests are “validator”. Although there are colleagues to whom I said this particular phrase, and they took it with skepticism. Saying something like “no one will forbid the curved-handed programmer to do business logic in View, and to do View elements in business logic”. And they are right. And usually “direct-handed” programmers are usually skeptics.

Why is refactoring necessary? It’s not a secret for anyone that the entire IT industry all over the world has not learned to “sanely” plan development timelines. And if so, the timing begins to run out. No matter how competent the analysis at the initial stage is, life is more difficult. And then decisions begin to be made "in XP style." Which, in my opinion, is generally 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 existing system change “explosively” or “avalanche-like”. And it becomes “crowded” within the framework of architecture, which, although “flexible”, but not “rubber”. Here too - you need to do refactoring. So that the architecture doesn’t fall apart.

Vsevolod: And how much easier has it become for you to “refactor”, with all this set of UML, DSL, code generation?

Maksim: Here is a real life example. We have defined interface factories on our metamodels — a method on an interface with a special stereotype that, using a template, turns into a set of other interfaces and classes in the code that implement several different patterns, which ultimately allows you to quite flexibly manage runtime binding of an implementation to interfaces and cache them, displace, etc. I repeat, all this is one method drawn on the model. At some point, when it was used for a couple of years, and there were not a dozen or two such factories, we suddenly realized that the code has non-optimality that affects performance. But to eliminate it, you need to change the structure of these generated classes. Do not just replace “a” with “b” by searching the entire project, namely, change the structure. In our case, it took several hours for to rewrite the generation template and re-render all projects. And if all this had been written by hand, then in a hundred different places the implementations of these several patterns would be “crammed”, everywhere slightly different, and changing and then debugging all this would be impossible in two hours or two months .

Alexander : In addition, it’s easier for me to “refactor” the diagram, not the code. It’s easier to transfer squares to models from place to place than pieces of code and files between folders. At the same time, “hands” must correctly “preserve the architectural layers”. 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 informed.

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 it was possible to achieve the absence of such a need, then refactoring is probably ideal. Another thing is that I have not seen code / architecture that would be perfect. If something is ideally “from above”, then it is not ideal “from below”. Or vice versa, “below” is an ideal code, and “above” are imperfect architectural solutions.

Vsevolod : We often talk about refactoring, and many perceive this negatively. For example, "everything worked, but then we did refactoring." Is it possible to say that when using UML modeling, codes initially became a ray, and refactoring became less frequent?

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 to allow the code to turn into a "salad Olivier." Using UML with code generation, even in the simplest case, immediately automatically structures the code. 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 she was gone, I myself was a great opponent of modeling. I thought drawing charts was "monkey labor."

Maxim : Yes, due to the fact that there is no reverse, synchronization is always one way. And you will not pass by it either.

Vsevolod : i.e. 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, moreover, constant, then at some point the diagram starts to be “just a picture”. She is "rotten." She is "about nothing."

And of course, as we have said, code generation allows you to "encode" a code, I apologize for the tautology - much faster. Believe me, the above examples have already been cited, and I have a million more.

Maxim : I would say more categorically, code generation is the key point of using UML. At least for us. You see, what’s the thing, now I’ll say a strange thing that goes against the topic of our discussion: we don’t use UML in the classical sense at all.

Vsevolod: well, "come", explain what you mean?

Maksim: Don’t be scared, I’m certainly exaggerating a little. As I already hinted above, UML for us is just a form of "squares", a specific graphical notation, and nothing more. We took it as a set of primitives in a graphical editor, and built something much larger from them. The patterns we talked about above allow us to describe any metamodel in terms of these UML primitives; Alexander has already listed them above, “Class”, “Category”, “Communication”, etc. And as a result, get new terms, new primitives, already at a higher level and, moreover, recursively, if necessary, using which a specific designer or programmer will create a specific model and get 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 to draw that model. Those. human,

Vsevolod : Are "time wasted" justifying the creation of code in graphic notation justified by an increase in its quality?

Alexander : From my point of view, they make excuses. Due to the possibility of stereotypes of a higher level. As soon as we see that design decisions begin to repeat. Moreover, the model affects the development framework, and the framework affects the model. Well, refactoring in the presence of a model (and tests) goes to a completely different quality level, as mentioned above.

Maxim : 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 just what allows you to turn atoms into molecules, molecules into alloys, parts, assemblies 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, modeling is not particularly necessary?

Alexander : In my opinion, it is better, of course, first to test, and then UML, modeling, code generation. But for us, this has historically been the opposite. But now I would certainly prefer tests first. We are not "just thinking about the tests." We know what they are. That they will "make mistakes tomorrow." And show. But of course - "we think about the tests." We write proactive tests. We have "regression tests." There are tests that test the requirements. And they allow you to refactor without severe damage to quality.

Maksim: I do not agree with Alexander, it seems to me that these are complementary things, and where to start is not so important. Rather, it should be determined by the internal culture and preferences of the collective. I’d start with modeling anyway, in the end, tests can and should be generated, and not written manually.

Vsevolod : Alexander, as I understand it, initially you were an opponent of UML? Looking back (perhaps with a smile), can you say that you thought like this: “Why do I need UML, am I already controlling my code?”

Alexander : It was just I personally, long ago, had the realization that "there are problems." But without code generation and constant synchronization with the model, I did not understand how UML could personally help me. Now - I understand and use it every day, although it is certainly not easy UML, as we said above.

Vsevolod : Has “your UML” become another way to document program code?

Alexander : Yes of course. Moreover, we have all the models integrated into a common hypertext knowledge base. It also contains bug-tracking and requirements.

Maxim : ... and much more that our know-how is. By the way, the integration is also built on the same templates: html for the database 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 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 for working with UML.

Maksim: and vice versa, and changing tasks and commits to the repository are also automatically bound to them.

Vsevolod : Are UML diagrams used to interact with "non-programmers"?

Maxim : At the beginning of the 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 succeeded. But ..., let's say, practice has not taken root.

Alexander: Still, not techies (not by education, but by vocation), they don’t really like all sorts of formal languages. It is subconsciously easier for them in Russian literary rather than in UML. This is already from the category of psychology.

Vsevolod : What UML diagrams are used and to what extent?

Alexander : First of all, class diagrams and UseCases.

Vsevolod : Do you find other diagrams less useful? For example, are the "brains" of programmers enough to dispense with the "objects" diagram?

Maksim: Not. Sometimes we use state diagrams, describe them and generate state machines code. But this is very rare. The use of finite state machines, on a formal level, also requires a certain sharpening of the brain. Here and there, sequence is used, but only as an illustration, i.e. like a “dead chart", now nothing is generated from them, which means, as Alexander said above, her life time is very short.

Alexander : Perhaps, Sequence is even more useful, just until you got around to making the appropriate code generation for them. And the 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 pinches the programmer into a fairly narrow framework. Database, interface, form, components, events, response procedures. How much did you expand this framework with UML?

Alexander : UML "pinches" in the framework of the "meta-model" that is developed. But this was partly sought. Compared to RAD, impurities and AOP elements are used much more actively. As well as a declarative rather than imperative approach to some parts of the projects. Those. the “data model” is drawn to the model to the maximum divorced from what it should physically turn into, and it can be transformed into an “active code” using a code generator. For example, a “document outline” or a set of “settings” for a project. Different chains of SAX filters, etc.

Maksim: It is important that it pinches where you decide. The metamadel does not impose any rules on its author; it imposes them only on the model and the one who will create it. In one place you clamp, and in another you give unique flexibility and speed to the lego constructor.

Vsevolod : How did the use of models affect the architecture of the application and the structure of the program code?

Alexander : The point, of course, is not only in the models. The point is "brain hygiene." But the proper 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 practices.
And the UML architecture and modeling are positively affected :-) Logical layers appear. Spurious cyclic dependencies disappear, and so on.

Vsevolod : We’ll work in the “blitz” mode. When do you think it is not necessary to apply UML and modeling?

Alexander : For research and other studies. For the “two-three months” project, which then most likely will not have to be supported.

Maxim : If UML is used only for drawing, then I agree with Alexander, but if for metamodeling and code generation, then I think that you can and should always use it, especially if you are used to doing it. Of course, if it's not a "hello world". Although it’s probably easier for me to generate “hello world”, at least I don’t need to remember how to make a new project in the IDE :), because projects are also generated here.

Vsevolod: At what point in 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.

Maxim : The only thing is that there are still technical limitations of a particular instrument, sometimes they can have a very negative effect.

Vsevolod : How to stage by stage the introduction of modeling in 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”?

Maksim: you can leave some not very structured, unique algorithms, something that does not have a template, reuse, some kind of system that can be formalized and reproduced.

Alexander : I myself have far from everything translated into a model. I primarily translate either new classes / entities. Or those that affect in the process of remaking. Or those that are "refactored."

Vsevolod : Probably, other approaches have been tried. Is there an alternative to UML in today's world of software development?

Maxim : For us, in the form in which we use it, no. But I have already said above that it is not very important at all how to draw arrows with squares in a concrete way. The main thing that we do with him, and not how it looks.

Alexander: I’ll clarify, in fact, there are many alternatives to UML, and precisely because for us it’s just a way to describe the model. You can take any other graphic notation that has the concepts we need in the basis and use it. You can describe your own. It is possible in general, and I actively think about it, go to the textual 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 started to create your own meta-models, any restrictions disappear, only imagination and the ability to see in a particular general may be lacking.

Vsevolod : Is everything really so wonderful, and there aren’t any problems right there? I would like to shout in the best theatrical traditions: “I do not believe”!

Alexander: Of course have. First of all, the limitations of the tool. Insufficient generation speed on large models. Non-optimal UML editor interface, etc.

Maxim : the problem is not ideological, but technological. We are gradually growing out of tools that were made long ago and for many years remained relevant. The generator requires updating, modification. But this is more likely not a “problem”, but a “task”.
We use a separate package as a UML scriber. Yes, it is already part of our "conveyor", but it would not hurt to improve it, to update it.

Vsevolod : your plans?

Alexander : Write your own tool completely - model editor. So to speak, to do "work on mistakes" in existing ones.

Maksim: And at the same time - cross-platform. In general, in this direction there are also a bunch of ideas on how to make the modeling process even more effective.

Vsevolod : In the next article we will discuss DSL?

Maxim : Yes, of course.

Alexander : With pleasure!

Vsevolod : As an employee of Embarcadero, taking advantage of 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 of the technologies 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. We are now in the process of switching to Delphi XE4. There is a need for 64 bits.

Maksim: I grew up in C ++, but in a very heterogeneous environment, in the projects I participated in, Delphi, C ++, python, java and so on were used at the same time, so I have never been a supporter of “holivars” which is “better” - each clothes has a fastener. As a project manager, the main thing for me is the effectiveness of the solution as a whole. Our company has been using Delphi for a very long time and intensively, the main thing is to know the strengths and weaknesses of each tool, its potential, make the right decisions on the basis of this decision, build the technological cycle, select professionals so that they match the tool as much as possible. In this sense, Delphi suits us perfectly.

PS Alexander and Maxim will answer under the Vsevolod account, adding their names to the beginning of the comment.

Only registered users can participate in the survey. Please come in.

What do I think of UML?

  • 36.7% Interested, thinking about using 50
  • 22.7% Tried, did not understand 31
  • 28.6% I am already well encoded 39
  • 16.1% There is no good tool 22
  • 21.3% I use 29

Also popular now: