To properly explain this, we need a short history lesson. In the early days of software engineering, an often used analogy was building a house. An architect and structural engineer discuss plans with a customer and come up with a design. Builders then follow that design to build the actual house. Writing code was seen as the equivalent to building the actual house. Thus, there was a perceived need for up front design before that build could take place. Various graphical design tools were created, with UML being one of them.
The idea originally with UML, was that one would fully design a system with UML, then hand it over to coders to translate that design into code. In reality, this just doesn't work, and led to years of programmers being seen as "implementers", rather than "designers", projects being late, the designs having to constantly change after they were supposed to be complete etc.
The reason is simple. Coding is design. With the house analogy, the code is the architect's drawings. The compiler is the builder who takes those designs and builds a program from them. This realisation then led to agile techniques, TDD etc being born: tools to help improve the quality of that code design.
Just as an architect might produce preliminary sketches to help her and her team visualise the overall design, so a developer might use UML, or other tools, to help visualise the design needed. Just as those sketches aren't blindly followed, so the UML should not be blindly followed. The code design should evolve out of agile iterations and using TDD. LIkewise, just as an architect might build a model of the house to help her and her team visualise the drawings, so UML can be used to help visualise the code structure.
As Uncle Bob says, you can't validate the UML, you can only validate the code. Therefore the code is the prime design documentation and UML, if used, is secondary documenation only.
