Software engineering is an area that uses specifications a lot. They may come in different forms, but one of the most common ones is UML diagrams. However, do developers need to know it, or this is just a useless piece of knowledge?

What is UML?

UML is a modeling language for software engineers. It is used to define application architecture, describe internal processes, and do many other things.

This language commonly used a part of the specification to explain how the component has to be built and behave. While the standard way to describe it in a text form is good enough, the addition of diagrams allows us to structure the information and give a better understanding of the requirements.

UML is also often used for prototyping. A developer can draw several diagrams that describe possible ways the application has to work and then select the best one. This approach is excellent because diagram drawing does not take much time, and created diagrams are easy to present and discuss with colleagues.

Diagram Types and Use Cases

There are two main types of UML diagrams — structural and behavioral.

Structural diagrams are used to describe the internal structure of the solution. These diagrams are used to describe an application architecture, structure both on the high and low level, and the way components relate each to other.

The component diagram describes the components the application is consists of and the interaction between them. Developers may use the package diagram to show the structure of code packages and how to build them. The class diagram defines the structure of classes, their relations, and their internal organization. Finally, the object diagram gives an example of real data inside the objects at any given moment.

Behavioral diagrams are showing an interaction between the parts of the application. They can show who should interact with the application, how input values are changing over time, and what is the expected outcome of these changes.

The use case diagram tells what kind of business logic is needed, who should be involved, and what high-level interaction application should perform. The activity diagram describes the expected workflow of this interaction in detail. The sequence diagram shows how an application works internally, defines the data flows, passed values, and results.

So, it is clear that UML diagrams are handy to describe the way an application has to work for software engineers. As a consequence, developers should be able to read and write these diagrams to build suitable applications, right? The real-life situation is a little different, though.

What is wrong with UML?

Surprisingly, it appears that only about 10% of the developer community knows the UML and can use the mentioned diagrams. So, what is wrong with the UML and why almost nobody uses it?

Well, nothing is wrong with it. UML diagrams are just tools that have their purpose — and they fulfill it well! An experienced developer can draw the diagram to describe the required logic. There is no need to write several pages of text description as a diagram already doing it much better. However, the question remains — why the developer community does not use it?

In my opinion, the issue here is in the lower experience standards set for developers. There are lots of newcomers in IT who do not have specialized education. They visited several training sessions in some programming language, and that is it. It is an excellent way to enter IT for a newcomer, but need to remember that these sessions cover only a minimal amount of knowledge. So, the developer should always continue learning new technologies, languages, development practices, etc.

Now we have a situation when most of the developers do not have extensive knowledge in IT — and this is the main issue! UML is not that complicated itself, and it is not hard to understand it even if a developer never used it before. However, if a developers team does not have a single person who knows UML — how other developers should be even aware of the existence of such a tool?

The question remains opened. Sooner or later, this situation in IT should be stabilized. Either developer has to learn the best practices of application architecture and development, or these best practices (and UML) will be history. Time will tell.