In its entirety? No. Never go "full UML", it will annihilate productivity and produce abominable software. It also is taught wrong, it tends to be taught as a design tool, but there's such a tremendous impedence mismatch between the diagramming tools and the way the code actually gets written that it ends up doing more harm than good. (not to mention that the people who usually end up creating the UML might be many organizational layers away from the developers).
But there's some goodness in there. The principal of using diagramming as a descriptive documentation and communication solution is highly worthwhile, but again it should be limited to pieces of the system that need such things. And in addition, the level of detail should be just as much as is sufficient to communicate what's necessary -- don't "prematurely optimize" by trying to document every bit of the system in excruciating detail.
There's also often better, simpler ways to document many aspects of a system, a few boxes and arrows work well for many things. Lightweight versions of the Archimate style work well for describing complete systems. Protocols are well described by a lightweight treatment of sequence diagrams, etc.
They'll often go out of date as quickly as you make them, so keeping them up to date and well versioned turns into a challenge.
Because it's free and provides cross platform compatibility (and the diagrams are supposed to be communication devices), we tend to use yEd for most things.
Indeed, I only use UML for documentation of existing code. Having a standard allows for consistent reverse-engineering, and a class diagram is still the best way to visualize an OOP class hierarchy.
Keeping them up to date with the code is an issue, as with all documentation. I actually wrote my own Java class diagrammer [1] for that purpose so I can just re-run a project file to create updated diagrams of the current code base, with little or no editing required.
But there's some goodness in there. The principal of using diagramming as a descriptive documentation and communication solution is highly worthwhile, but again it should be limited to pieces of the system that need such things. And in addition, the level of detail should be just as much as is sufficient to communicate what's necessary -- don't "prematurely optimize" by trying to document every bit of the system in excruciating detail.
There's also often better, simpler ways to document many aspects of a system, a few boxes and arrows work well for many things. Lightweight versions of the Archimate style work well for describing complete systems. Protocols are well described by a lightweight treatment of sequence diagrams, etc.
They'll often go out of date as quickly as you make them, so keeping them up to date and well versioned turns into a challenge.
Because it's free and provides cross platform compatibility (and the diagrams are supposed to be communication devices), we tend to use yEd for most things.