UML Modeling - At some point, becomes a voodoo practice in practice?

Question

I am looking for modeling information. I had an intro-course on design patterns and basic class diagrams, sequence diagrams, and use cases.

Class diagrams that I found invaluable as an organization tool in my programming. Use cases are currently moderately useful.

In this semester, I participate in a class that goes deeper into UML, that is, in the areas of domain analysis, requirements analysis, software development and software development, etc.

There is a certain feeling that this is starting to be more voodoo-scientific or non-seasonal when we start trying to be accurate with uncertainties in the scenarios and changing requirements. Are UML past base class diagrams and hands-on diagrams practically useful in performance in most applications?

Answer 1

It started with voodoo. Diagram software development has always been like that. This is a way to show in photographs what you want to say about design in human language. If it were accurate enough to generate the code, we would go further, do it, and get around the coding step in general.

The only thing that UML brings to older versions is the standard. Even then, there are so many different “standard” diagrams that I should smile a little at, calling it standard.

However, the activity of the project itself is extremely important for all but the most trivial tasks. The question is whether you intend to spend some time developing your system, or if you intend to do this on the fly by writing a lot of incorrect or illogical code. If you want everything to be done quickly and / or well, you do the design in advance.

This applies not only to writing BTW software. This is an integral part of any complex creative activity. My father-in-law, a retired teacher who writes long cards to his children when he goes on vacation, actually writes the outlines of his cards. Most masters and sculptors first conduct test drawings.

Answer 2

No.

All types and forms of documentation are only useful as a means of communication. Documentation for documentation is a complete waste of time.

Writing UML is useful and productive only when it comes with a document that explains (in words) what you want, why, and how. only then can UML help illustrate what you are trying to say in a document.

Software teams that produce an infinite amount of UML just for the sake of drawing squares just waste time.

Answer 3

You started with modeling, and this is great, especially in the field of computer science - you model all the time. Keep in mind that UML is the standard for modeling notation for software systems, nothing more (for example, it is not an analysis or development methodology) and no less (for example, developers cannot look productive by drawing senselessness).

You are on the right track, always remember what is actually useful and gives you some value. This is not entirely relevant to your question, but examples of litigation are not examples of use, much more, they are written and can help you in most of what you described in your next course.

As for your concern, modeling is about abstracting from non-essential details, so some ambiguities may arise. The fact is that they must be unimportant for the purpose of modeling. For example, it doesn't really matter if you include all the properties of your classes if you want to show the design structure, for example. use of some pattern. You can also use public properties that are not relevant to yourself if they are private fields with getters and setters (Java), properties (C #), or generated object methods using metaprogramming (Ruby). The same applies to scenarios shot using precedents - of course, you cannot (and should not try) to grab alternative branches using UML, but you can describe the conditions in the descriptions of random cases enough to avoid ambiguity, without having to first develop a system and after that he is mistaken.

As far as voodoo materials are concerned, the problem is that UML is large and many developers do not know how to use it correctly and often create more mess than meaning. Do not confuse the general disrespect for UML, the problem lies in tool providers, commits and lazy developers ... Formal models supported by academic scientific work, for example, are well-known for many concepts in UML. state diagrams come from Harel state graphs (http://linkinghub.elsevier.com/retrieve/pii/0167642387900359). Therefore, in my opinion, this is not so much voodoo, in principle, it is just oversold with tools that do not support the standard, and the standard also tries to be and combine everything (this is a single language ...), but it is slowly improving.

My advice for you will be trying to find out what is important - these formalisms, methods of analysis and design, try them in practice and decide for yourself which is useful. If not for any other reason, study UML, because it is a language for analysis and design, although large, it is still better than its predecessors ~ 50 together :).

Answer 4

From my experience: Not really.

I have never come across a really useful sequence diagram. Sequential diagrams cease to be useful when the documented process becomes too complex because it is not easy for you to follow all the lines. But to understand the trivial process, I do not need a sequence diagram. When used as a design tool, you will spend ridiculous time adjusting charts, swearing at MS Visio or what you use.

However, the notation can be useful for a small snapshot when discussing something on the board. But this is true for any notation style; UML has just been installed, which increases the likelihood that you understand correctly.

Class diagrams are useful both in design and in posterior documentation. But IMHO, you should not be too pedantic about them.

Answer 5

Not in MHO. This is completely useless, as far as I know.