What is UML? What is it for?

Question

A conceptual issue.

• What is UML?

• What good is?

• Is it really useful? Therefore, we must learn?

• Is widely adopted?

• What defects of this language?

• Is linked with object orientation?

Answer 1

UML or Unified Modeling Language, as the name says is a modeling language, that is, it should describe how a domain model should be.

It was standardized by the Object Management Group (OMG) to be used universally instead of several other separate and often competing forms, which created communication problems because people did not speak the same language, you had to learn a new way if you got into a project that adopted a different form than you were used to.

It allows documenting various forms and phases of software development while it comes to the model (it is possible to go a little further).

With it it is possible to create diagrams to demonstrate various aspects of what the software has, such as:

• Structure (component, class, deployment, object, package, profile, composition)

• Demeanor (activity, use case, state machine, timer)

• Interacting (sequence, communication, interaction summary) they are often considered behavior

Examples of diagrams.

One of the assets propagated is that the diagrams can be executed and you can see how it really looks what has been modeled, and it is even possible to generate the source code for some programming languages and theoretically would not need to program anything, this language would be universal. Of course it depends on implementation.

That at least is the theory. In practice it generates very bad code, disregard because there are so many languages and think it’s just different syntax. So the idea is wrong.

Usefulness and defects

The idea is not so wrong when it tries to provide a unique way to demonstrate how the solution is assembled, but there are too many diagrams, some with too much detail, others that lack certain things to be as complete as it is willing to be, and it is common to be very complicated for little benefit in certain cases. It bureaucratizes development, which can be good in some cases, but bad in others. Interestingly some proponents of methodologies called agile advocate the use of this mechanism, which goes against the original idea of Agile.

Some organizations do not live without, some abuse, others use where it really helps to give clarity to what is being done.

Using what is really useful can help you to plan and visualize what you are doing on time, and with this can give ideas to improve the design and who knows how to facilitate the execution of the project. One of his problems is the distance in terminology and way of working with certain aspects that is very different from the languages that people actually use.

She’s responsible, for example, for making people call attribute field. People don’t even know that.

Although it is possible to do with pen and paper almost everyone uses some software to create this. There are controversies about its use. Some people don’t live without it, but most people don’t. My experience is that it is not the use or non-use of it that makes the software better. The conscious, punctual use, according to the context, when there is real motivation, and not following a rule of doing everything always, can be useful.

Remember that whenever you have the same information in two different places violates the DRY (in this case of the project as a whole) and causes problem. So to use this as something that governs the entire development cycle, as opposed to using it to better understand something before you do it, that is, if it’s not used as documentation, it can become a problem. You change the code and don’t change the documentation, it’s gone.

So it was actually thought to replace the coding, which in practice "never" is done. In the way UML was thought, it is not usually a good one and goes against the modern form of software development. To use individual diagrams when necessary to help understanding is ok. But using this firm is not actually using UML. Worse than using, is to say you use and not even know you’re not using. A lot of organization makes believe you use.

Researching a little on the subject to answer I realize that a lot of people have positive opinions when they argue wrongly about, or fail to support what they say, are just opinions.

More and more people are accepting the fact that it’s a waste of time.

If someone wants you to use something, they should prove that it is good. We should not adopt something without the certainty that it brings more benefits than harm/cost.

Completion

Tends to be used with OOP, but in part can be used in any paradigm.

To brainstorming is good, for documentation can be useful here and there, but to guide the whole project is an insanity.

From my reply on Quora.