&gt; We already have a perfectly good way of representing the details of a system - it&#x27;s called source code.<p>Interestingly enough, that&#x27;s a bit of a false dichotomy.<p>Imagine it&#x27;s your first day on the team, and there&#x27;s thirty classes (or thirty functions) in this software package, and you want to understand their inheritance&#x2F;composition, what&#x27;s a good way to take a step back and just see how they relate to each other?  You can browse some interface files or some source files, accumulating a model in your head.  But the visual throughput into your brain is just so much better when you can see it in a diagram.<p>Regardless of whether a human draws the UML representation of the design in advance of the implementation or a machine deduces this from the existing source code, you can still benefit from a class diagram that will cut out the noise of the implementation itself.  As long as we&#x27;re drawing a diagram, why not have a common way to represent the concepts we use in software?